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

181–190 of 270 posts

Re: RethinkDB Postmortem

#181

Post by jacobush »

jeremyjh wrote: post #175
lacker wrote: post #92

Earlier quoted context omitted.

This was a really interesting post. Thanks for writing it. First with MySQL and then with MongoDB, a pattern is emerging. There's a popular open-source database. Its feature set is awesome and the ecosystem of software on top of it is good because lots of people are using it, but it's buggy and unreliable. So it's controversial. Since it's popular, it keeps being developed, and over time, it slowly gets more reliable…

The problem with MySQL early on was exactly its feature set. Fifteen years ago it was very far behind Postgres yet much more popular. I do not think it even had InnoDB/transactions at that point (or almost no one used it), definitely did not have user defined functions, procedures and many other features developers took for granted in commercial RDBMS. Like MongoDB, it was popular mostly for being popular, which is a…

Also it was fast on crappy hardware and easy to compile and setup. 80%. Better is worse. Unix.

Re: RethinkDB Postmortem

#182

Post by niftich »

If your target market is enterprises who are willing and able to pay, isn't it paramount to get into some market analysis firm's ranking quickly as a "leader", like Gartner's Magic Quadrant?

On this very busy Quadrant (which ought to be a clue too) from October 2015 [1], I don't see RethinkDB at all, while many other niche players are present. This to me indicates that somehow, somewhere, not enough press was generated on RethinkDB, and it was largely unknown to the sorts of decision-makers who decide what products to evaluate down the road.

[1] http://imgur.com/a/PyR57

Re: RethinkDB Postmortem

#183

Post by raverbashing »

bad_user wrote: post #171
raverbashing wrote: post #140

Earlier quoted context omitted.

I'd say that for more than 90% of potential RethinkDB users there's no need for guaranteed correctness (several exception are in FinTech or similar areas) But even in those cases, the operation can be retried or the operation could take longer If you're "Social startup of the year" it doesn't matter if one post appear to some followers 100ms later than they should be.

In my opinion, you got it backwards. Fewer than 0.1% of software engineers are working on the " social startup of the year ", whereas the other 99.9% of developers are working on software where consistency and correctness matter more than availability. And for most of those developers, atomicity guarantees (the A from ACID) are very important, because without transactions if that one operation fails, before it can be…

Thanks for your comment

I don't disagree consistency and correctness are important, but it's the same with uptime, where to have it an order of magnitude 'more confidence' you have to spend more time/resources (because even if your DB did everything right, your hard drive could have had a glitch, etc)

There are ways of working around the lack of atomicity, for the cases where you really need that guarantee (I really wouldn't try "writing my own" generic transaction manager, but you can try relying on the atomic operations and limiting changes to small steps - and if you wrote information that is irrelevant now because the operation didn't finish that's fine - you can gc it later)

Now if the operations you need to do are very complex then it is probably better to keep using RDBMSs

Re: RethinkDB Postmortem

#184

Post by StavrosK »

btown wrote: post #20
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…

I was truly hoping that RethinkDB would be the Mongo that Mongo could have been: a NoSQL database, but one with joins; a NoSQL database that is actually CP [0]; a database that comes out of the box with granular real-time updates (so you don't even need to worry at first about the extra moving parts of a Redis server or other queue). For a business starting from scratch with those needs, I'm making do with Mongo, but…

I think Rethink would be that, but I don't know, I've never found SQL databases that hard to manage. I've found NoSQL databases hard to manage, because, invariably, someone will be doing a write right when you're trying to do a data migration/transformation, and now you have a single record that looks wrong, and it's a bug waiting to happen on read, rather than on write (where it should).

Rethink definitely had its use cases, I just never saw it as my primary data store.

Re: RethinkDB Postmortem

#185

Post by jpgvm »

jacobush wrote: post #181
jeremyjh wrote: post #175

Earlier quoted context omitted.

The problem with MySQL early on was exactly its feature set. Fifteen years ago it was very far behind Postgres yet much more popular. I do not think it even had InnoDB/transactions at that point (or almost no one used it), definitely did not have user defined functions, procedures and many other features developers took for granted in commercial RDBMS. Like MongoDB, it was popular mostly for being popular, which is a…

Also it was fast on crappy hardware and easy to compile and setup. 80%. Better is worse. Unix.

That is not Unix. Unix is small, composable, correct and 80% of what you need (you write the rest). It doesn't mean 20% of quality was sacrificed.

Re: RethinkDB Postmortem

#186

Post by raverbashing »

dkersten wrote: post #166
raverbashing wrote: post #140

Earlier quoted context omitted.

I'd say that for more than 90% of potential RethinkDB users there's no need for guaranteed correctness (several exception are in FinTech or similar areas) But even in those cases, the operation can be retried or the operation could take longer If you're "Social startup of the year" it doesn't matter if one post appear to some followers 100ms later than they should be.

If you're "Social startup of the year" it doesn't matter if one post appear to some followers 100ms later than they should be. That's latency, not correctness. I think even "social startup of the year" cares that the post shows up at all, is attributed to the correct author, isn't corrupted somewhere and so on. Data correctness/consistency is about making sure that the data isn't in an inconsistent state.

> That's latency, not correctness.

That's "eventual consistency" in replication

Re: RethinkDB Postmortem

#187

Post by FooBarWidget »

sroussey wrote: post #84
coffeemug wrote: post #32

Hey all, author here. FYI, the post is still in its unpublished state. It's basically right, but I've been meaning to edit it for tone and rewrite the market failure section for clarity. Didn't get the chance to do that before it made it on HN, so keep in mind that you're reading a (late) draft.

The key to building developer tools is to build the ones that a developer needs but has no interest in creating. Backend for mobile, infrastructure for backend, etc. Just don't create front end tools for front end developers, for example. Firebug had a donate button and we funneled all of it to volunteers in places where the currency was weak to make it at least seem material.

I don't think it's that simple. Which developer wants to build a reliable, realtime database?

Re: RethinkDB Postmortem

#189

Post by mannykannot »

cmdkeen wrote: post #138
beachy wrote: post #52

Earlier quoted context omitted.

Kudos on a magnificent post, and of course commiserations. One thing resonated strongly with me. When we started out many years ago someone said to me that the worst market you could go after was to target developers. Case in point - every developer who's ever put up a web site has built or thought about building a CMS. There must be thousands upon thousands of them, virtually all with a price of $0. Who would want t…

IT people try and "trip you up" because we've been burnt so many times in the past with systems that don't do what is promised by the sales people, don't integrate well and who stiff you during the implementation phase. HR people are some of the worst because everything is super secret and they don't want to get IT involved, then they go and buy a system that lets you insert a carriage return into the phone number fi…

And yet a bunch of them chose MongoDB (over something else, not just over RethinkDB.) Was there some point in time when it was the best option for a lot of people?

Re: RethinkDB Postmortem

#190

Post by pvg »

jpgvm wrote: post #185
jacobush wrote: post #181

Earlier quoted context omitted.

Also it was fast on crappy hardware and easy to compile and setup. 80%. Better is worse. Unix.

That is not Unix. Unix is small, composable, correct and 80% of what you need (you write the rest). It doesn't mean 20% of quality was sacrificed.

The original "worse is better" example is precisely about Unix making a trade-off in which it gives up on "correctness"
Post reply on HN