Ask HN: Do you still use MongoDB?
41–50 of 243 posts
Re: Ask HN: Do you still use MongoDB?
#42I like SQL because it is way more expressive and helps you answer questions you didn’t know you would have. I find that incredibly valuable. Pretty tough to do in mongo. Generally BQ is good for this (in addition to your app DB) but if you use mongo you’re gonna have a hell of a time stuffing that sloppy schema into any column-oriented dB.
I like some of the serverless GCP dbs like datastore and firestore over mongo. They Index every field and force you to add composite indices on first query run by spitting out an error with a link to create it. If you understand their unique but simple API, limits, and quotas, they work predictably and scale nearly limitlessly.
Re: Ask HN: Do you still use MongoDB?
#43Re: Ask HN: Do you still use MongoDB?
#44MongoDB is a pretty good database IMO. I've used it at several companies in the past and wouldn't mind using it again. My favorite DB is RethinkDB. It's a shame that the company behind it fizzled out and was absorbed by Stripe. I still cannot wrap my mind around why it's not more popular. It's similar to MongoDB but much better. It's the perfect database. It adds constraints which improve the quality of your code. Al…
back when mongo was around 2.6x, they had a global write lock. Also, you'll encounter more problems with mongodb if in case you need transaction. You should check out more discussion here on db systems. http://www.redbook.io/
It's possible to use two-phase commits instead. Two-phase commits can scale without limit but you have to be more careful when designing your tables and specifying your indexes.
For tables which need atomicity, you can add a 'state' column/field which is either 'pending' or 'settled'. You can have a separate parallel subroutine (or process) in your code to handle settlement. You have to design it in such a way that if the system fails at any point, it will re-process all 'pending' entries in an idempotent way.
It's a bit more work, but it scales without limit. You can add a shard key (or use account IDs) so that you can have multiple processes/hosts working in parallel to insert pending transactions and also multiple processes to settle them in parallel.
In financial transactions, I would separate it into two parts: A debit entry and a credit entry which are initially inserted into the DB as 'pending'. The settlement routine will match them up together - Making sure to process/settle the debit side of the transaction first and only once the debit is in the settled state, it will process/settle the credit side.
If the settlement engine sees any conflict (e.g. user tries to spend more money than they have by submitting many transactions in parallel), it will accept all the transactions as 'pending' but mark the later ones as canceled (they will not settle) so the credit entry will never be created on the other account.
Re: Ask HN: Do you still use MongoDB?
#45I haven't used it for a while and I've been planning on learning Postgres after much praise from a friend (and the internet at large). I find DB design and migrations quite difficult though, any book/course recommendation?
Re: Ask HN: Do you still use MongoDB?
#46Earlier quoted context omitted.
Postgres's jsonb format is definitely not "essentially" a string. You can get native indexes on json fields in Postgres, and you can query fields however you like.
https://www.postgresql.org/docs/9.5/functions-json.html they are surrounded by quotes, is that not a string ?
Re: Ask HN: Do you still use MongoDB?
#47No - Postgres is faster and it has JSONB. (It also has tables and SQL and GIS and ...)
Can you provide benchmarks showing PostgreSQL is faster ? Because from my experience MongoDB was at least 10x faster and all of the benchmarks I've seen were using pre-WiredTiger storage engine.
You can take a particular application and compare performance when using two different databases on the back-end, but then the database itself might not necessarily be your bottleneck, it might also be the way the application is written. Because the database is only a part of the equation, the comparison also doesn't tell you anything about the performance of any other application.
Re: Ask HN: Do you still use MongoDB?
#48Yes, use it with Atlas for every one of my companies' projects. - The document model is a no-brainer when working with JS on the front-end. I have JSON from the client, and Dictionaries on the backend (Flask), so it's as easy as dumping into the DB via the pymongo driver. No object relational mapping. - Can scale up/down physical hardware as needed so we only pay for what we use - Sharding is painfully easily, with o…
This is a great testimonial. Would you care to share what Atlas is/which software package Atlas is?
Re: Ask HN: Do you still use MongoDB?
#49No, I had a sour experience in 2009 where it ate my data, the devs were rather cavalier with "there's a warning on the download page" (I got it through apt), it ate my data again when the OOM killer killed its process. I didn't like the project attitude of a database being so lax with persistence, so I never used it again.
I'm the most popular non-MongoDB-employee answer at 'to what extent are 'lost data' criticisms still valid of MongoDB?' My answer contains a history of my experiences with MongoDB that is pretty similar to yours: https://stackoverflow.com/a/18269939/123671 I feel like MongoDB now is actually a pretty stable product simply through time and investment, however I will never trust the company for using our data to beta t…
Re: Ask HN: Do you still use MongoDB?
#50Earlier quoted context omitted.
Atlas makes sharding easier, it's just one button where you define your partition key.
No offense, but if I wanted to have managed MongoDB I might as well use AWS DocumentDB. I honestly believe that this is a key differentiating feature for many databases. ElasticSearch, ScyllaDB, others too work the same way: Every node is equal and in order to scale you just keep adding more boxes, end of story. Compare that with what you have to do with MongoDB.
DocumentDB is a great DB, but in the end of the day it's a forked version of 3.6-ish so it's missing a ton of new features like multi-collection ACID guaratneees. Plus, whenever you use DocumentDB you're accessing it via the MongoDB official drivers, so you'll be handling that compatibility mess yourself.