Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OPTIMIZATION: Support for omitting specific graph objects from file storage #404

Merged
merged 3 commits into from
Dec 27, 2020

Conversation

austinkelleher
Copy link
Contributor

@austinkelleher austinkelleher commented Dec 26, 2020

Some entities and relationships do not need to be stored on the
file system at all. We only need to store graph objects on the file
system if we later intend to fetch the data from the job state or
iterate over the _type. This PR introduces support for specifying
metadata in each step that can be used by the FileSystemGraphObjectStore
that will be used to omit specific data from being written to disk
entirely. The data will still get uploaded.

A longer term optimization would be actually leveraging the dependency graph to automatically generate this information. We can also make a follow-up improvement that removes the entire locking behavior during these cases because no step will rely on the unindexed data, so there is no reason to lock.

Some entities and relationships do not need to be stored on the
file system at all. We only need to store graph objects on the file
system if we later intend to fetch the data from the job state or
iterate over the `_type`. This PR introduces support for specifying
metadata in each step that can be used by the `FileSystemGraphObjectStore`
that will be used to omit specific data from being written to disk
entirely. The data will still get uploaded.
aiwilliams
aiwilliams previously approved these changes Dec 27, 2020
});

if (indexable.length) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think it would be worthwhile to add a test for the scenario when there are no indexable types?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do!

 - @jupiterone/cli@5.3.0
 - @jupiterone/integration-sdk-cli@5.3.0
 - @jupiterone/integration-sdk-core@5.3.0
 - @jupiterone/integration-sdk-dev-tools@5.3.0
 - @jupiterone/integration-sdk-private-test-utils@5.3.0
 - @jupiterone/integration-sdk-runtime@5.3.0
 - @jupiterone/integration-sdk-testing@5.3.0
@austinkelleher austinkelleher merged commit 8061b53 into master Dec 27, 2020
@austinkelleher austinkelleher deleted the 1991-index-metadata branch December 27, 2020 01:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants