-
-
Notifications
You must be signed in to change notification settings - Fork 570
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
Does db.load() put all the data in memory ? #381
Comments
The oplog is not kept all in memory if I understand correctly, but all of the Stores that are available by default keep the Index entirely in memory. The Load operation is O(n) unfortunately and has to be done at every application startup. This means that the load time of your application will grow linearly with the amount of data (ouch). There is no quick fix to this yet that I know of. Then, you have the Store/Index problem where the Index is kept all in memory. You can solve this by writing your own custom Store that uses an external database, localstorage, IndexedDB or some other not-in-memory solution to keep the data. I suggest you check out how the kvstore is written (it's pretty simple really) so that you undestand how you can write your own Store that could either be a more efficient implementation of an existing store or something new. |
@fazo96 I'm not sure if I'm looking at the right thing - but it looks like the oplog is kept in memory. My understanding is that upon calling This is not ideal (especially on mobile). It appears you can pass an For replication to work properly, only the heads and multihashes of entries are needed to exchange entries properly. However, I'm not sure what I'm going to do a bit more digging and see if I can limit it to just keeping the heads and entry hashes in memory and read the rest from disk. |
Hi @mistakia @fazo96 @maroodb TypeError: Cannot read property 'getPublic' of nullwhere i am running local ipfs daemon without '--enable-pubsub-experiment' option |
Hi @its-VSP. Sorry this got buried. "--enable-pubsub-option" is simply required for OrbitDB, there's no way around it. For more information about how data is marshalled between a storage layer, memory, and replication, please check out the new OrbitDB Field Manual and feel free to open issues there if you have more questions! |
I want to know if db.load() put all data in memory or not, if yes how can we deal with a huge amount of data?
The text was updated successfully, but these errors were encountered: