3 ms·
Excellent read performance if you don’t want real time data. I had millions of documents and search/read was super fast, just that we were okay with 1 minute la
by girishso 4y ago
Excellent read performance if you don’t want real time data. I had millions of documents and search/read was super fast, just that we were okay with 1 minute late data for our use case.
We had terrible experience with mongodb (very early version) even with 100k docs.
Cons:
- Large disk space required for indexes
- Indexing is somewhat slow
Go with “smaller” document ids, you can thank me later.
- _448 4y ago> Go with “smaller” document ids What size would you recommend? UUID is 16 bytes? > you can thank me later. Thank you! :)
- girishso 4y ago> What size would you recommend? UUID is 16 bytes? The thing is, document ids are used for indexing. So taking a simple eCommerce store as an example (assuming you have 100s of thousands of products) Product.id will be used extensively in indexes, you would want products to be displayed in a particular order, categorize them, sort/filter by price/listing date etc and so on. Which means lots of map-reduce views (which create these indexes). So you would want product ids to be as small as possible. Seller.id, Review.id won't be used as extensively, you can then go for UUIDs. But Ids can be used creatively for filtering or sorting `prod-{yyyy-mm-dd}-iphone13`, if that's your use case, you should forget about the id length. Id length matters mostly for disk usage in indexes.