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

Does db.load() put all the data in memory ? #381

Closed
maroodb opened this issue Jun 10, 2018 · 4 comments
Closed

Does db.load() put all the data in memory ? #381

maroodb opened this issue Jun 10, 2018 · 4 comments
Labels

Comments

@maroodb
Copy link

maroodb commented Jun 10, 2018

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?

@fazo96
Copy link

fazo96 commented Jul 6, 2018

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.

@mistakia
Copy link
Contributor

mistakia commented Jul 8, 2018

@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 load(), the entire oplog (from ipfs-log constructor) and a store specific index are kept in memory.

This is not ideal (especially on mobile). It appears you can pass an amount to load() but I'm not sure what thats for and this will affect the completeness of the index?

For replication to work properly, only the heads and multihashes of entries are needed to exchange entries properly. However, I'm not sure what ipfs-log needs to be able to join logs (after exchanging entries) and append new entries.

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.

@thecipherBlock
Copy link

Hi @mistakia @fazo96 @maroodb
I got into a context where i could able to create db but running into below error when i am trying to load it

TypeError: Cannot read property 'getPublic' of null

where i am running local ipfs daemon without '--enable-pubsub-experiment' option
Can you help me in solving it and explain why that option is required if that is causing above error

@aphelionz
Copy link
Member

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants