Announcing RethinkDB 2.3.6: the first release under community governance • Hacker News Board

Re: Announcing RethinkDB 2.3.6: the first release under community governance

#21

Post by timmaxw » Tue, Jul 18, 2017, 10:23 PM UTC

cupcakestand wrote: post #19

timmaxw wrote: post #14

Earlier quoted context omitted.

Former rethinkdb developer here. Sharding and replication just work out of the box. Connect the servers to each other with "rethinkdb --join otherserver", then use the web dashboard or the client APIs to specify how many shards and replicas for each table. Send queries to any server in the cluster and they get routed automatically.

> Send queries to any server in the cluster and they get routed automatically. Nice! Also the writes? Mongo wants the writes to the primary only.

Yes, if you send a write to a server that's not the primary then rethinkdb will transparently forward it to the primary.

Re: Announcing RethinkDB 2.3.6: the first release under community governance

#22

Post by inimino » Wed, Jul 19, 2017, 3:20 AM UTC

cupcakestand wrote: post #20

_Codemonkeyism wrote: post #15

Earlier quoted context omitted.

After some years with Mongo I would not use Mongo again (we had some site downs). It you do not need to push to the client, I'd use Postgres. It just works. For replication and sharding better wait for 10 though.

Can I use Postgres fully schemeless without even defining any collection (table) or db before doing the first write (which is possible with Mongo).

Nope. However, "time to hello world", while certainly a large factor in the success of development tools, is not always the most relevant criteria from an engineering perspective. Cf. PHP.

Re: Announcing RethinkDB 2.3.6: the first release under community governance

#23

Post by nieve » Wed, Jul 19, 2017, 9:24 AM UTC

cupcakestand wrote: post #17

kerkeslager wrote: post #16

Earlier quoted context omitted.

The problem with a feature comparison between Mongo and another database is that feature comparisons rarely include the features that Mongo lacks. Mongo looks good if you ask about sharding or replicating, but Mongo looks terrible if you ask about losing data or leaking memory. But nobody asks about losing data or leaking memory because they reasonably assume that a popular data store wouldn't do those things. That a…

> but Mongo looks terrible if you ask about losing data or leaking memory Sorry, but this is just not true for many years now. Mongo has its warts but reading old stuff again and again feels strange and like pure hate. If your claims have some recent sources I am happy to hear them.

The list of problems goes on, but if you want really current at a local presentation a few weeks ago a user who's actually pretty positive about MongoDB reported data loss without hardware failure with what is supposedly a safe configuration. If even experienced people who like Mongo are still losing data eight years after publich release there's a problem. The claim that it's "not true for many years now" is the result of buying into PR and fanboyism.

Re: Announcing RethinkDB 2.3.6: the first release under community governance

#24

Post by cupcakestand » Wed, Jul 19, 2017, 1:13 PM UTC

nieve wrote: post #23

cupcakestand wrote: post #17

Earlier quoted context omitted.

> but Mongo looks terrible if you ask about losing data or leaking memory Sorry, but this is just not true for many years now. Mongo has its warts but reading old stuff again and again feels strange and like pure hate. If your claims have some recent sources I am happy to hear them.

The list of problems goes on, but if you want really current at a local presentation a few weeks ago a user who's actually pretty positive about MongoDB reported data loss without hardware failure with what is supposedly a safe configuration. If even experienced people who like Mongo are still losing data eight years after publich release there's a problem. The claim that it's "not true for many years now" is the res…

Again the same old accusations without a single source ('local presentation', of course!).

Re: Announcing RethinkDB 2.3.6: the first release under community governance

#25

Post by kerkeslager » Wed, Jul 19, 2017, 5:51 PM UTC

cupcakestand wrote: post #17

kerkeslager wrote: post #16

Earlier quoted context omitted.

The problem with a feature comparison between Mongo and another database is that feature comparisons rarely include the features that Mongo lacks. Mongo looks good if you ask about sharding or replicating, but Mongo looks terrible if you ask about losing data or leaking memory. But nobody asks about losing data or leaking memory because they reasonably assume that a popular data store wouldn't do those things. That a…

> but Mongo looks terrible if you ask about losing data or leaking memory Sorry, but this is just not true for many years now. Mongo has its warts but reading old stuff again and again feels strange and like pure hate. If your claims have some recent sources I am happy to hear them.

February 2017: https://jepsen.io/analyses/mongodb-3-4-0-rc3

I would expect these bugs to keep occurring, because they're still approaching the development of the consensus algorithm incorrectly. Instead of formally proving correctness, they're doing something that seems right and then patching bugs when they are discovered.

Re: Announcing RethinkDB 2.3.6: the first release under community governance

#26

Post by jwr » Fri, Jul 21, 2017, 5:26 PM UTC

egeozcan wrote: post #9

jwr wrote: post #8

Earlier quoted context omitted.

I did bet on it and so far I'm happy as long as it continues to work. Sure, I would like it to be developed further, but what I have now is great and works well. As for progress, it slowed down to non-existent during the handover period, and now seems to be picking up.

Great to hear that! Is there any issues close to being show-stoppers or any "it would have been immensely helpful to have this but I can work around it" features? Also, what would be the thing that RethinkDB is really good at that makes you keep using it?

I use it for two major reasons:

1. It's distributed. I can elastically add/remove nodes. I need this not so much for scalability, as for reliability, and I want to be future-proof.

2. Changefeeds. Nothing else even comes close, and my entire application is built around them.

I have no show-stoppers. The thing works. Sure, I'd love to see some things done differently (ReQL looks nice at a first glance, but has many limitations in practice, causing code that ends up being quite complex), but overall even if it were to stay exactly the way it is now, I'd continue using it.