I am storing ~2500 images as attachments in same doc in CouchDB. These images occupy roughly about 15MB in hard drive and resultant CouchDB is roughly 17MB.
When I push this document to my client through PouchDB I saw that resultant database is over 40 MB. I made some tests following these steps:
upload X images attachments to CouchDB document.
Compact CouchDB
Clear client cache fully
Reload client (in my app I replicate data on reload).
This is the result:
number of attached files | Total size (KB) in HD | Inc | Size in Indexed DB | Inc
17 129 207
27 168.2 39.2 267 60
37 219.6 51.4 335 68
47 275.5 55.9 414 79
57 327.7 52.2 493 79
67 384.9 57.2 579 86
77 428.5 43.6 654 75
So, it seems that:
PouchDB adds roughly 2K control data to each attachment.
This control data increases when more attachments are added. (1.6K -> 2.3K -> 2.6K -> 2.8K...)
Images have content_type:image/png both in CouchDB and PouchDB. I understood that this should prevent storing them as base64. Am I correct?
Has anyone seen this earlier? Has anyone been able to workaround it? This is a big problem when aiming to fit an app within iOS 50MB space limitation.
EDIT
I went ahead and checked the size of some images in pouchDB vs original files:
File 1: orig size = 7.4K / PouchDB size = 10.2K
File 2: orig size = 5.1K / PouchDB size = 6.8K
So I think the increase of size when storing attachments in PouchDB does not come from any control data (at least it is not relevant) but from the way the binary file is stored in browser IndexedDB (I am using Chrome for these calculations).
So, is anything additional that needs to be done in order to avoid this increase of binary sizes in PouchDB?
MongoDB is faster than CouchDB. MongoDB provides faster read speeds. It follows the Map/Reduce query method. It follows Map/Reduce creating a collection and object-based query language.
Scalability. The architectural design of CouchDB makes it extremely adaptable when partitioning databases and scaling data onto multiple nodes. CouchDB supports both horizontal partitioning and replication to create an easily managed solution for balancing both read and write loads during a database deployment.
Quite the opposite: CouchDB is slower than many people expect. To some degree it has room to improve and optimize; but primarily CouchDB has decided that those costs are worthwhile for the broader good it brings. CouchDB fails the benchmarks, and aces the college of hard knocks.
Apache CouchDB is an open-source document-oriented NoSQL database that uses multiple formats and protocols to store, transfer, and process its data, it uses JSON to store data, JavaScript as its query language using MapReduce, and HTTP for an API.
A very good question, but the answer depends on which adapter you're using, which is not clear from the description.
Edit: just realized you did say Chrome, but I'm keeping the original answer for posterity :)
I'm going to guess you're testing in Chrome. So the reason you're seeing bad performance is because we have to store everything in base64 as a workaround (source).
On the bright side, that Chromium bug is pretty active (last comment was 48 hours ago), so presumably the Chrome team is on it and will publish the fix shortly. When they do, PouchDB will automatically detect that blob support is available and start using it.
Update: the Chrome team fixed this, and Blobs are supported in PouchDB as of Chrome v43. :)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With