Mongodb can make your simple problems more complicated and you may notice this too late
Ask HN: Do you still use MongoDB?
181–190 of 243 posts
Re: Ask HN: Do you still use MongoDB?
#182Yes, we are using it at iFunny (20М+ installs on iOS + Android). 180 virtual servers in 12 clusters. Reasons are scalability and reliability. We can turn off any baremetal host under those virtual servers and system won't even notice that (it actually happens 2-3 times a year). We can add/remove replicas to scale reading load and add/remove shards to scale writes.
Re: Ask HN: Do you still use MongoDB?
#183Earlier quoted context omitted.
While there are many people here who are sharing their bad experience with MongoDB, just curious if you all find the experience with DynamoDB similar? Since they are both of the NoSQL family.
DynamoDB is a completely different beast and would use no other data store unless I had to. It can pretty much handle any transactional workload I need. It's cheap, its fast and it scales super high. Don't need much more
DynamoDB is consistent and scalable, not fast and cheap.
DDB is great for storing data that is required to be scalable and never needs to be joined. Add in DAX, developer time necessary to orchestrate transactions, calculate the scaling costs and...that's how AWS gets you.
Plus, local development requires half-complete emulators or a hosted database you're charged for.
No, maybe people should think twice about DynanoDB.
Re: Ask HN: Do you still use MongoDB?
#184Earlier 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.
SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @> '{"tags": ["qui"]}'; vs db.api.find({tags:"qui"}, {guid:1, name:1})
Not sure what you are trying to show here, but only SQL statement helped me to understand that {guid: 1, name: 1} is to show these fields.
Re: Ask HN: Do you still use MongoDB?
#185Earlier quoted context omitted.
I never understood the appeal of the JSON to SQL columns workflow. At least with the ORM(-ish) tools I worked with, it always felt much more straightforward to just change classes within the application code and automatically generate the respective migrations files to be run on the relational database, than having to interact as a human with json (for the app as well as for business intelligence and reporting/monito…
> At least with the ORM(-ish) tools I worked with, it always felt much more straightforward to just change classes within the application code and automatically generate the respective migrations... There's your answer, no? You've got specific tools and workflows you've designed to work with your database in a specific way. You can't just take one workflow and substitute a piece of another workflow and expect it to a…
Sure, but almost all the times (I'm not specifically referring to person in the comment I'm responding to and should have been more clear on that) people were making it fundamentally an sql vs. non-sql argument.
As in you need to switch your entire database system or make a bet on this completely new player instead of battle proven tech, because with relational databases schema migrations are hard. Among a bunch of other questionable claims.
Sure if you take the vanilla databases without their ecosystem, there is some merit to that, but I don't find it a very practical argument to ignore all the tooling and workflows that do exists and are used by people.
When MongoDB first came out, I was eager to check it out. I was using mainly Django with Postgres at the time, but had my career start on ZODB, an object-oriented non-sql database created in the late 90s. So I was hopeful that MongoDB could give me the best of both worlds. One of the reasons I backed of Mongo very quickly was the lack of tooling as soon as you have something resembling a schema or relationship and you'd want to change it.
Re: Ask HN: Do you still use MongoDB?
#186MongoDB 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…
much of the anti-mongo sentiment is around people who used it in 2009-ish. it's useful to point out that when using the early version of any software, there will be bugs. that's a trade-off early adopters always need to contend with. unfortunately, it hasn't sat well over time despite every one of the concerns being addressed since.
At that point it was webscale ready. The problem was that MongoDB lied in their documentation what guarantees it provided. It took them a decade to improve, and now that data is safer (still not completely) it no longer offers performance edge over its competition.
Originally it was super fast, because it kept everything in RAM and didn't worry about writing data to disk, which caused many people to lose data.
Re: Ask HN: Do you still use MongoDB?
#187Yes. I've been using mongo for various projects for 8+ years. I like the flexibility of the document model. No migration headaches. The query language is powerful and intuitive. I haven't used the graph features yet, but it is nice to know that Mongo can support it if that need ever comes up. I use mongo Atlas as a managed database for peace of mind. I use Redis in addition for caching. For testing/TDD i use mongo-me…
How do you handle issues around data integrity? From http://jepsen.io/analyses/mongodb-4.2.6 > Jepsen evaluated MongoDB version 4.2.6, and found that even at the strongest levels of read and write concern, it failed to preserve snapshot isolation. Instead, Jepsen observed read skew, cyclic information flow, duplicate writes, and internal consistency violations. Weak defaults meant that transactions could lose writes…
Interesting. I haven't had a usecase where data integrity is critial yet.
A project i'm working on now will have credits and accounts. To accomplish that in mongo. I create a transaction with with "pending" status. Then i try to debit the source account, and credit the destination account and I add the pending transaction to the accounts. If that works I set the transaction to "committed" and I remove the pending transactions from the accounts.
https://gist.github.com/exoer/eee2aa37c86c06190f12ef4e2c6bd1...
Re: Ask HN: Do you still use MongoDB?
#188Earlier quoted context omitted.
That's my attitude as well. RethinkDB, in comparison, had a much better attitude of "reliable first, fast later". Unfortunately, it turned out that when you're a database, it doesn't matter how much data you lose, only how fast you are while losing it.
> "Unfortunately, it turned out that when you're a database, it doesn't matter how much data you lose, only how fast you are while losing it." Ahh yes, just like the dialogue of the never-stale "Mongodb is Webscale" meme video: https://www.youtube.com/watch?v=b2F-DItXtZs http://www.mongodb-is-web-scale.com/ > MySQL is slow as a dog. MongoDB will run circles around MySQL because MongoDB is web scale. > "MongoDB does h…
Those videos (that being the most infamous) will never stop being hilarious. The node.js one is also pretty amazing:
Re: Ask HN: Do you still use MongoDB?
#189Earlier quoted context omitted.
Yep, just regret and misery. Back in 2010 when the MongoDB hype was high, the well-known company where I was working at the time decided to build the next version of the product using MongoDB. I was on the analytics team and had to code a whole bunch of intricate map-reduce jobs to extract summary data out of Mongo. I'd repeatedly head to the product team and ask them to explain the edge cases I was seeing in the dat…
While there are many people here who are sharing their bad experience with MongoDB, just curious if you all find the experience with DynamoDB similar? Since they are both of the NoSQL family.
DynamoDB is a lot more explicit about its tradeoffs. Much of the backlash against Mongo was because it basically claimed to be well-suited to any use case, when its sweet spot was really far narrower. To be successful with Mongo, you need to design the entire app around its limitations, but those limitations were initially downplayed and obscured.
People were convinced that Mongo was a good choice as a default, general purpose db, when it clearly wasn’t for about a million reasons.
I don’t think DynamoDB is marketed or viewed in the same way. The docs are pretty clear about needing to design your data model to specifically work well with Dynamo. People using it seem to generally be aware of its limitations, and deliberately choose to accept them for the sake of performance and scalability. At least that’s my perception.
Re: Ask HN: Do you still use MongoDB?
#190Earlier quoted context omitted.
> much of the anti-mongo sentiment is around people who used it in 2009-ish. So? I think this is a very plausible way of measuring how much you should trust something. There had to be a downside to the "move fast and break things" that mongodb subscribes to (i.e., add features now, think about reliability later). As it turns out, they moved fast and broke their reputation.
You make technical decisions based on what happened a decade ago? Do you make all decisions based on ten year old information?
> You make technical decisions based on what happened a decade ago? Do you make all decisions based on ten year old information?
Yes?
The problem was not that MongoDB was young, the problem was that authors of it had no idea about databases when they started their work. They stored data in RAM and get fastest benchmarks, because they didn't worry about persisting the data on disk. They outright lied in their documentation about the guarantees.
It wasn't the being early product part, it was the misrepresenting the truth part that hurt their credibility.
DynamoDB for example is much younger than MongoDB, and doesn't suffer from this.