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

feature-request - add appendFile capability to overcome nedb performance-bottleneck #260

Closed
kaizhu256 opened this issue Mar 28, 2019 · 7 comments

Comments

@kaizhu256
Copy link

nedb emulates appendFile by re-saving its entire database as a blob to indexedb whenever a row insert/delete/update is performed [1]. this performance-hit makes it impractical for persisting largish datasets (> 20mb).

adding some kind of incremental appendFile feature would help.

[1] https://github.com/louischatriot/nedb/blob/v1.6.0/browser-version/browser-specific/lib/storage.js#L49

@kaizhu256 kaizhu256 changed the title add appendFile capability to overcome nedb performance-bottleneck feature-request - add appendFile capability to overcome nedb performance-bottleneck Mar 28, 2019
@kaizhu256
Copy link
Author

this feature-request originated from tc39/proposal-built-in-modules#16 (comment)

@inexorabletash
Copy link
Member

There are plans for a rebooted FileSystem API with both native and sandboxes support, which is probably a better fit, with the addition of locking primitives.

@pwnall
Copy link

pwnall commented Mar 28, 2019

Typical databases have some sort of block cache, and need to write modified blocks to disk. The sub-system is sometimes called the page cache or the pager.

If nedb has something similar, it should use a Blob for each block / page, instead of writing the entire database in a single Blob. Each block would be a Blob in an object store keyed by block ID. You can use this approach to build a database or a filesystem on top of IndexedDB. There's still overhead, but at least it's constant, not O(database size).

If you need something working soon, the approach above should give you some relief until we're able to build and ship the future APIs mentioned by @inexorabletash. I hope this helps!

@vweevers
Copy link

Off-topic: where can I follow progress on that rebooted FileSystem API? Thanks!

@inexorabletash
Copy link
Member

https://github.com/WICG/native-file-system

@inexorabletash
Copy link
Member

TPAC 2019 Web Apps Indexed DB triage notes:

We agree with advice in #260 (comment) - implementations could also optimize blob storage using e.g. ropes.

There are explorations by Google Chrome of WASM-friendly storage APIs happening, which would allow running sqlite in the browser directly. Will add links if we can find them. And the people working on native-file-system would probably appreciate feedback too.

Mutable files doesn't seem to align well with the rest of Indexed DB and given the other possible approaches above, closing this out.

@kaizhu256
Copy link
Author

cool, interested in links on sqlite3 when available.

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

No branches or pull requests

4 participants