Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Do you still use MongoDB?

news.ycombinator.com

Post reply on HN
Print view View original

151–160 of 243 posts

Re: Ask HN: Do you still use MongoDB?

#151

Post by derivagral »

daneel_w wrote: post #141

I can't help noticing that the majority - not all, but the majority - of "No." responses here summarize identically: someone used MongoDB a long time ago (between 5 and 11 years) and ran into a problem, so they stopped using it and will never try or re-evaluate it again. I'm a bit surprised that developers and systems engineers get burned to the point that they disconnect from the daily reality of their occupation, t…

I don't think this is limited to devs or databases. You see it sometimes in Firefox/Chrome threads along the lines of "firefox sucks", "when did you last use it?", "4 years ago".

Mongo in particular had marketing plays that were quite deceitful; that particular flavor of distate can run deeper than some tech issues.

disclaimer: I use mongo in my day to day as a primary DB store.

Re: Ask HN: Do you still use MongoDB?

#152

Post by subhobroto »

benglish11 wrote: post #132
subhobroto wrote: post #95

Earlier quoted context omitted.

> I never understood the appeal of the JSON to SQL columns workflow. The appeal is non-technical. Writing good migrations, having tests around them to ensure they didn't leave the DB in an inconsistent state if a subset of them failed requires good understanding of a RDBMS and the specific product. You'll be surprised how many engineers don't meet that criteria. The JSON to SQL columns workflow allows any developer t…

>At that point the DB is like a key-value store and you get to claim you are using Postgresql. I know this statement is a little tongue in cheek but there is a lot of value organizationally to using Postgres as a key-value store vs MongoDb or some other flavor of no-sql. Even if you're not really getting all of the benefits of a relational db, you are still getting ACID transactions, envryption, user/access controls,…

Hey there, thanks for reading my comments and sharing your thoughts.

> in my experience software engineers/data engineers/DBA with postgres experience are easier to find.

I need to understand what "postgres experience" means in this context. Having experience writing postgres client software using some postgres driver is a different kind of experience than installing, provisioning, monitoring and turning postgres itself.

The former is a days worth of work for any good engineer; the later can take decades and those people are really hard to find.

> you are still getting ACID transactions, envryption, user/access controls, backup/restore, libraries, etc

Sure, at a high level, making a KV-store on top of a RDBMS feels like a grand idea - hey you get ACID for free and all the RDBMS goodness while getting the flexibility of a KV-store to boot.

As they say - when something sounds too good to be true ...

One small scenario worth thinking about:

What does a KV-store on top of a RDBMS with ACID semantics even mean?

How do you handle merging objects?

Does the RDBMS even supporting merging objects inside a column?

What would happen if I have the different attributes in the same object that I then update one after the other into a JSON column on a RDBMS?

Does it fail one of the updates with an error message that data is lost?

Does it automagically merge the data? How does it even know how to handle conflicts?

Hint: No it cannot - the reason why a RDBMS can even offer ACID semantics is because RDBMS operations assume certain rules have been followed. Database Decomposition is important for a number of reliability reasons.

There are KV-stores out there that handle all these scenarios natively without the client having to worry about it (and doing a halfassed, buggy job about it because they are not DB designers). They have conflict resolution algorithms, offer CRDTs for the clients to use and engineers who know what they are doing, use them.

Using the right tool for the right job is what experienced engineers do because it not only makes their lives easier but the businesses they help run more reliable and resilient.

There is no magic.

Re: Ask HN: Do you still use MongoDB?

#153

Post by marcus_holmes »

subhobroto wrote: post #95
smoe wrote: post #82

Earlier 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…

> I never understood the appeal of the JSON to SQL columns workflow. The appeal is non-technical. Writing good migrations, having tests around them to ensure they didn't leave the DB in an inconsistent state if a subset of them failed requires good understanding of a RDBMS and the specific product. You'll be surprised how many engineers don't meet that criteria. The JSON to SQL columns workflow allows any developer t…

This is not true.

I'm using it because the cost of changing the schema for a feature that may only be experimental is too high. I started off changing the schema every time, and it just got too expensive.

Using the JSON-to-SQL workflow, I can mess around with feature design and iterate fast, and then crystallise the schema into SQL once it has stopped changing.

Writing solid migrations can end up being more complex than the feature code itself, and when features are changing fast, writing solid migrations is kinda pointless. The feature may not even make it to production.

But yeah, sure, I'm an idiot who doesn't know how to write proper SQL. rolleyes

Re: Ask HN: Do you still use MongoDB?

#155

Post by pritambarhate »

rat9988 wrote: post #97
asah wrote: post #69

Earlier quoted context omitted.

The PostgreSQL community is a nice counterexample - perfectly gigantic and growing marketshare, and very very reliable.

Listening to the community and using Postgres is my biggest regret. In hindight, given our scale, any database would have worked. There is no built in solution for high availability with multiple VPS, and having one server alone isn't enough availability for me.

Looks like you have not searched enough:

https://aws.amazon.com/rds/ha/

https://github.com/zalando/patroni

https://repmgr.org/

Re: Ask HN: Do you still use MongoDB?

#156

Post by AdrianB1 »

daneel_w wrote: post #141

I can't help noticing that the majority - not all, but the majority - of "No." responses here summarize identically: someone used MongoDB a long time ago (between 5 and 11 years) and ran into a problem, so they stopped using it and will never try or re-evaluate it again. I'm a bit surprised that developers and systems engineers get burned to the point that they disconnect from the daily reality of their occupation, t…

If you have a problem with product A and you have 10 other options, find product B is good enough and start working with it, there is no need to go back to A from time to time to see if it was improved. And watching all the 10 products like a horse race and move to the best of the hour is not reality.

Re: Ask HN: Do you still use MongoDB?

#158

Post by Volundr »

daneel_w wrote: post #141

I can't help noticing that the majority - not all, but the majority - of "No." responses here summarize identically: someone used MongoDB a long time ago (between 5 and 11 years) and ran into a problem, so they stopped using it and will never try or re-evaluate it again. I'm a bit surprised that developers and systems engineers get burned to the point that they disconnect from the daily reality of their occupation, t…

Here's the thing, it's not just that early Mongo had issues, sure whatever that's life. But they argued that things like silently dropping data if your database gets too large were acceptable because it's documented (and this is just one such issue).

The sole, number one requirement I have for my database is that the data I put in is still there when I go to get it back. Failing that and pretending it's not an issue is more than "being shaky", it's a violation of the trust I put in my data-store. It's great they've fixed those issues now, but that cavalier attitude towards data the integrity of my data is what makes me hesitant to use it in future, not the fact that a bug involving data-loss existed.

None of this is to say I'd never use it, but it'd be far harder for me to trust it again vs postgres, couch, rethink, cassandra, or any number of other data-stores that took data integrity seriously from the start.

Re: Ask HN: Do you still use MongoDB?

#159

Post by crankylinuxuser »

Yep. Thats only because Graylog requires it. We don't put any real data in Mongo. That'd just be silly.

I'd put SNMP telemetry data in Mongo, only for the fact that recording that can be somewhat lossy. Plainly, I just don't trust Mongo with consistency, availability, or partition tolerance.

And because Mongo's backup facilities suck (requires taking the DB into readonly, or accepting no time consistency egads), the only good way to do a backup is to put the DB on LVM, and making a LVM snapshot.

Post reply on HN