Hacker News Reader

Comment by jondubois | Hacker News Reader

MongoDB 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. Also RethinkDB scales very well and the control panel that comes with it is mind-bendingly powerful, I'm not kidding; you can click a button to shard or replicate a table over multiple hosts! WTF! I can't say the same about Postgres unfortunately. There is nothing truly remarkable about it.

I use Postgres for one of my projects today but purely because of compatibility reasons with an existing system. I don't understand what all the hype is with Postgres.

View on HN

So what's the status of RethinkDB? Is it still being developed? Who's working on it? Is it stable and feature-complete or are there any kinds of features missing that only a dedicated (paid) team would be able to pull off? Genuinely curious!

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/

MongoDB 2.6 was released 7 years ago. Why are you bringing it up ?

If you use MongoDB today then (a) there is no global write lock and (b) there are transactions.

IMO I've come to see DB transactions as a hack because they limit scalability.

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.

Exactly it's a bit more of work does make you prone to mistakes. This is what happens when you rewrite transaction on your application. See what happens with to a btc exchange using mongo who got hacked.

https://dzone.com/articles/mongodb-bitcoin-how-nosql (article is 2014)

I'm a bit outdated with mongo since 2.4-2.6 . It's a bit traumatic and i'm never coming back to it.

If in case I'll need a high atomicity and consistency for financial transaction i'll just use postgres with SERIALIZABLE transaction isolation. This solves everything.

Checkout the redbook.io it's a bit outdated but you can see from stonebreaker's discussion that nosql + sql will merge, which is what happening or happened right now. Mongo having transaction, and SQL having json datatypes.

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.

> 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.

i agree, there's reputational impact but again it's the trade off that early adopters make and are fully aware of.

When you're the first user of a brand new companies' database, you better bet there will still be kinks they're working through and let's face it you're the guinea pig.

i'm sure mongo is thankful for all these guinea pigs because they helped to define the roadmap and iron out the bugs. however, in the end of the day 2009 version of a product is entirely different than 2020 version. there are endless analogies (facebook, google, etc.) the only difference with an open source technology is users can analyze it under a microscope.

You make technical decisions based on what happened a decade ago? Do you make all decisions based on ten year old information?

Depends on what.

You seem to think this is about tech. It's not. It's about company culture, trust, and reputation.

Code can change reasonably fast, in some cases 10 years is enough to replace an entire codebase. But company culture has or can have an expected life time way longer than 10 years. In this case, my heuristic is justified.

Are you not buying iPhones because Apple’s first music player had no wireless and less space than the Nomad?

(For the younger people https://slashdot.org/story/01/10/23/1816257/apple-releases-i...)

How much memory a device has now does not depend on company culture. How reliable we can expect a future feature to be, does.

I think you're making an active effort to misunderstand me.

I’m saying it’s completely illogical to base technical decisions on information that is 10 years old when just like you can see the modern specs of the iPhone and compare to the first iPod, you can also see the modern specs of Mongo, read third party assessments, and even look at the source code to see if it meets your needs.

You have a view of software development so narrow minded to a point it's cartoonish.

You’re right. I’ve only been doing this professionally for 25 years and as a hobbyist for 10 years before that.

I’ve only developed software from everything from 8 bit computers with 128K of RAM, to DEC mainframes to Android tablets....

What do I know?

> 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.

> 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.

That's why I replied to the person you're responding to that his view of software development is cartoonish, but I don't think he got it.

> the problem was that authors of it had no idea about databases when they started their work

Speaking of which, have you heard of influxdb? It's going down the exact same route.

yep I heard of it and had similar period of excitement I had with Mongo. Although when they were postponing addition of distributed functionality I lost interest. You can't design a good distributed system as an addon, you need to think about it from day 1.

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.

long time postgres user.

the hype about postgres is that there is no hype. it's one of those systems that have been working for decades. they have their flaws but they are well known and as long as you aware of them it does exactly what it is supposed to do.

Reply on news.ycombinator.com