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

RethinkDB Postmortem

github.com

Post reply on HN
Print view View original

231–240 of 270 posts

Re: RethinkDB Postmortem

#231

Post by takeda »

dboreham wrote: post #8
StavrosK wrote: post #5

I don't know, my personal opinion was that RethinkDB had its head on straight, MongoDB is garbage and still neither is so much better than PostgreSQL that I will switch away from it. Postgres is the default datastore (because schemas are awesome) for me, and I haven't had a use case yet where I needed something that Postgres wouldn't do. Maybe if you have a very specific need, you'd reach for another datastore (come…

Rethink, Mongo et al are scalable (at the expense of some ACID). PG is certainly a good DB (I use it in production) but it is at heart a traditional RDBMS - not designed for scalability. Apples vs Pears..

Don't have experience with Rethink, but Mongo scalable? That's a joke right?

Here how it compares: http://www.datastax.com/wp-content/themes/datastax-2014-08/f...

The only values that has higher than rest are on page 13, except those are latency and lower is better.

This paper shows clearly that Mongo doesn't scale.

And even for single instance Mongo is slower than Postgres with JSON data: https://www.enterprisedb.com/postgres-plus-edb-blog/marc-lin...

There are actually add-ons to Postgres[1] that add MongoDB protocol compatibility, and even with that overhead Postgres is still faster.

And even such benchmarks don't tell full story. I for example worked in one company that used Mongo to regional mapping (map latitude/longitude to a zip code and map IP address to ZIP). The database on Mongo was using around 30GB disk space (and RAM, because Mongo performed badly if it couldn't fit all data in RAM), mainly because Mongo was storing data without schema and also had limited number of types and indices. For example to do IP to ZIP mapping they generated every possible IPv4 as an integer, think how feasible that would be with IPv6.

With Postgres + ip4r (extension that adds a type for IP ranges) + PostGIS (extension that adds GEO capabilities (lookup by latitude/longitude that Mongo has, but PostGIS is way more powerful) things looked dramatically different.

After putting data using correct types and applying proper indices, all of that data took only ~600MB, which could fit in RAM on smallest AWS instance (Mongo required three beefy machines with large amount of RAM). Basically Postgres showed how trivial the problem really was when you store the data properly.

[1] https://github.com/torodb/torodb

Re: RethinkDB Postmortem

#232

Post by takeda »

drdaeman wrote: post #218
flukus wrote: post #62

Earlier quoted context omitted.

The vast majority of us probably won't ever need that scalability anyway. Most places I've seen that needed something more scalable needed to just stop being so retarded with the tools they already had.

As for the clustering in general... Scalability may be not important, but replication and failover should be. I believe, every place that had existed long enough must've had theirs "ouch, our master DB host went down" moment. I wasn't able to set it up properly some years ago and settled down with warm standby replica (streaming + WAL shipping) and manual failover. Automating it (and even automating the recovery when…

You can try http://repmgr.org/ for automation.

It offers easy commands to perform failover and even has an option to configure automatic one.

After reading about github issues[1], I am a bit cautious about having automatic failover though.

[1] https://github.com/blog/1261-github-availability-this-week

Re: RethinkDB Postmortem

#233

Post by HodGreeley »

yummyfajitas wrote: post #56

I do find it truly sad how anti-intellectualism is pervading our industry and causing good products to die. Nowadays, a significant number of the hottest new technologies offer literally nothing of value beyond "low learning curve". It's my current belief that tech culture has lost nearly everything that once made us great. Think about some examples. MongoDB is nothing but the object databases of the 80's, rebranded.…

NoSQL's only selling point is you don't need to learn SQL? Hardly true.

Major Oracle shops aren't dumping them for Mongo/Couchbase/... because they're trying to avoid SQL. They do it for scalability, availability, performance, flexibility and more.

I don't see that the facts in the real world back you up here.

Not claiming NoSQL is a panacea. You're definitely making some trade-offs, and in many cases it's just the wrong tech. But it's absurd to say it's happening to avoid a learning curve.

Re: RethinkDB Postmortem

#234

Post by wedesoft »

I have used RethinkDB and must say this is one of the most polished pieces of software I have ever used. The only think I am wondering is, whether the project could have moved faster if it had not been implemented in C++.

Re: RethinkDB Postmortem

#235

Post by HodGreeley »

JohnBooty wrote: post #215
andrewbarba wrote: post #199

Earlier quoted context omitted.

I was a huge advocate of RethinkDB, absolutely love what Slava and the team were able to accomplish, but I am having a really hard time digesting that "Correctness", "Simplicity of the interface" and "Consistency" were the issue here. Example: Realm. I can only imagine what the team at Realm is thinking after going through comments and the post-mortem. Realm was an open-source mobile first database for the past 3 yea…

> Is mobile different? Is it easier? It's easier to get adoption for mobile, I'd think. Database component designed for use by mobile applications: something you base an app around Database server: something you base your business around

I don't actually think it is easier to get adoption. The major mobile platforms have SQLite built-in (under the hood in the case of Core Data). I think that's actually a strong barrier to overcome.

Furthermore, mobile is becoming in-demand or even core in both consumer and enterprise. For enterprise especially, though, you have to think of it as mobile + sync, not on-device only.

Turns out sync is the really hard part when you want to build something that's robust in the face of poor network connectivity.

Re: RethinkDB Postmortem

#236

Post by flukus »

pandeiro wrote: post #211
flukus wrote: post #69

Earlier quoted context omitted.

Don't forget the proliferation of electron so no one has to learn a new language and desktop toolsets. Just for kicks I wrote a desktop todo list in GTK and C, not tools I had extensive knowledge of ever and nothing recently. It was a breath of fresh air how simple it was compared to doing the same in modern frameworks. A single ~30 line function to create the gui and the rest held together with a couple of function…

Did you blog/gist that example, by any chance?

I half wrote a blog post/angry rant over Christmas. I'd post the draft/source here, but my c is very rusty and I want to at least check for memory leaks first (no valgrind on cygwin) ;)

Re: RethinkDB Postmortem

#238

Post by manigandham »

drdaeman wrote: post #218
flukus wrote: post #62

Earlier quoted context omitted.

The vast majority of us probably won't ever need that scalability anyway. Most places I've seen that needed something more scalable needed to just stop being so retarded with the tools they already had.

As for the clustering in general... Scalability may be not important, but replication and failover should be. I believe, every place that had existed long enough must've had theirs "ouch, our master DB host went down" moment. I wasn't able to set it up properly some years ago and settled down with warm standby replica (streaming + WAL shipping) and manual failover. Automating it (and even automating the recovery when…

> you start a fresh server, tell it some other server address to peer with, and it does the magic

This is the one thing I ask of every database software, yet we still don't really have it. 90% of problems could be solved if there was a focus on the basics like easy startup, config and clustering.

Re: RethinkDB Postmortem

#239

Post by manigandham »

flukus wrote: post #62
manigandham wrote: post #35

Earlier quoted context omitted.

Postgres neither scales vertically or horizontally. v9.6 finally brought some parallel scans but is still limited in scope and far behind the commercial databases. Same with replication and failover, although there are decent 3rd party extensions to get it working.

The vast majority of us probably won't ever need that scalability anyway. Most places I've seen that needed something more scalable needed to just stop being so retarded with the tools they already had.

Vertical scalability is important for everyone as it makes better use of hardware (lower costs or more performance).

Horizontal scalability is important for HA which every production environment would like or need.

Re: RethinkDB Postmortem

#240

Post by sikan »

roel_v wrote: post #114
sikan wrote: post #47

Why not position yourself as the better mongodb? You explained pretty well in the post mortem (and to yourself in 2014) how much better rethinkdb is to mongo. All you had to do was aggressively market yourself as the better option by directly comparing yourself to it. I remember when iPhone first launched, the first 30 min was spent just trashing then-current smartphones - the blackberrys.

"All you had to do was aggressively market yourself as the better option by directly comparing yourself to it." Lol. "It's not hard to win an Olympic medal in the 100m sprint. All you have to do is move your legs faster than those other guys!"

But they were and still are better than mongodb? They already achieved that ?
Post reply on HN