Live data from Hacker News

We use RethinkDB

blog.workshape.io

51–60 of 78 posts

Re: We use RethinkDB

#51
post #25

Earlier quoted context omitted.

Slava @ RethinkDB here. Unfortunately automatic failover won't be a part of 2.0, but it will happen very quickly after that. Please hang in there, we expect to ship this feature some time in May. I just saw a demo of the failover feature yesterday from Tim Maxwell (the lead engineer on this), and it's really impressive! Another side benefit of this feature is live reshards -- you'll be able to reshard/rebalance data…

You guys are killing it. Wish I had a product I could write around rethink....currently at the day job our stuff is mostly Mongo....all layered under django-nonrel with lots of mongo crud so a port wouldn't really be an option I don't think.

As a person who agrees -- maybe you could write a port/adapter for django-nonrel to Rethink?

Also, why not start a new greenfield project to test out Rethink? a something something realtime something geospacial something app should be a fantastic way to kick the tires, since that's one of the things that Rethink does really well out of the box (as of 1.15) compared to other databases (relational or not)

Re: We use RethinkDB

#52

We have used RethinkDB in production for a handful of months now. 100M docs, 250 GB data spread out on two servers. We added it to the mix because it got increasingly difficult to tune SQL queries involved in building API responses, especially for endpoints that needed to pull data from many tables. Our limited experience of MySQL operations was also a factor. We're on 5.5 and couldn't do some table operations that s…

> We're on 5.5 and couldn't do some table operations that seemed promising without service disruptions.

Everyone has this problem. But it's been largely solved in practice by performing the schema changes on slaves, and then promoting the slaves to master.

Also, if you're just using RethinkDB as a delayed (and almost certainly inconsistent) secondary storage system, why not use ElasticSearch instead?

BTW, 250GB fits in memory on any decent size box. You're not really going to see how things scale till you get into the terabytes.

Re: We use RethinkDB

#53
post #25

Earlier quoted context omitted.

You guys are killing it. Wish I had a product I could write around rethink....currently at the day job our stuff is mostly Mongo....all layered under django-nonrel with lots of mongo crud so a port wouldn't really be an option I don't think.

As a person who agrees -- maybe you could write a port/adapter for django-nonrel to Rethink? Also, why not start a new greenfield project to test out Rethink? a something something realtime something geospacial something app should be a fantastic way to kick the tires, since that's one of the things that Rethink does really well out of the box (as of 1.15) compared to other databases (relational or not)

As the ecosystem engineer at Rethink, I would love if someone adapted Django nonrel for rdb. It's a big job

Re: We use RethinkDB

#54
post #25

Earlier quoted context omitted.

You guys are killing it. Wish I had a product I could write around rethink....currently at the day job our stuff is mostly Mongo....all layered under django-nonrel with lots of mongo crud so a port wouldn't really be an option I don't think.

As a person who agrees -- maybe you could write a port/adapter for django-nonrel to Rethink? Also, why not start a new greenfield project to test out Rethink? a something something realtime something geospacial something app should be a fantastic way to kick the tires, since that's one of the things that Rethink does really well out of the box (as of 1.15) compared to other databases (relational or not)

Plenty busy at the moment and I don't generally code in my free time - I work from home so I really try to maintain that work/home life seperation.

Re: We use RethinkDB

#55
I'm a relative newcomer to the NoSQL scene and have been using RethinkDB for a couple of sideprojects. The IRC channel (#rethinkdb on FreeNode) is really second-to-none - the people on there are incredibly friendly and patient when answering what are probably obvious questions.

Re: We use RethinkDB

#56
post #25

Earlier quoted context omitted.

Slava @ RethinkDB here. Unfortunately automatic failover won't be a part of 2.0, but it will happen very quickly after that. Please hang in there, we expect to ship this feature some time in May. I just saw a demo of the failover feature yesterday from Tim Maxwell (the lead engineer on this), and it's really impressive! Another side benefit of this feature is live reshards -- you'll be able to reshard/rebalance data…

You guys are killing it. Wish I had a product I could write around rethink....currently at the day job our stuff is mostly Mongo....all layered under django-nonrel with lots of mongo crud so a port wouldn't really be an option I don't think.

I am rather horrified to hear of your setup, how has it worked out for you in practice?

Re: We use RethinkDB

#57
post #25

Earlier quoted context omitted.

You guys are killing it. Wish I had a product I could write around rethink....currently at the day job our stuff is mostly Mongo....all layered under django-nonrel with lots of mongo crud so a port wouldn't really be an option I don't think.

I am rather horrified to hear of your setup, how has it worked out for you in practice?

It works, I guess?

I was brought on well after the system was originally developed.

The websites are mostly our internal admin tools anyway.

Most of the real work is run through cronjobs or task queues (Celery).

The biggest annoyance is that the Django version the stable django-nonrel is based on is ancient (1.3). There are non-stable branches to newer Djangos (1.5, I think?). When I investigated there were some issues with them so we're still on 1.3.

Re: We use RethinkDB

#58

We have used RethinkDB in production for a handful of months now. 100M docs, 250 GB data spread out on two servers. We added it to the mix because it got increasingly difficult to tune SQL queries involved in building API responses, especially for endpoints that needed to pull data from many tables. Our limited experience of MySQL operations was also a factor. We're on 5.5 and couldn't do some table operations that s…

> We're on 5.5 and couldn't do some table operations that seemed promising without service disruptions. Everyone has this problem. But it's been largely solved in practice by performing the schema changes on slaves, and then promoting the slaves to master. Also, if you're just using RethinkDB as a delayed (and almost certainly inconsistent) secondary storage system, why not use ElasticSearch instead? BTW, 250GB fits…

I don't think 250GB will fit in memory on any reasonable sized box. What world do you live in?

Re: We use RethinkDB

#59
post #58

Earlier quoted context omitted.

> We're on 5.5 and couldn't do some table operations that seemed promising without service disruptions. Everyone has this problem. But it's been largely solved in practice by performing the schema changes on slaves, and then promoting the slaves to master. Also, if you're just using RethinkDB as a delayed (and almost certainly inconsistent) secondary storage system, why not use ElasticSearch instead? BTW, 250GB fits…

I don't think 250GB will fit in memory on any reasonable sized box. What world do you live in?

An r720 from dell or similar model from dell with 600GB*2 SSD intel s3500DC model, 20 cores & 256GB of RAM will go for 5k-7k. You can bump this to 386GB of ram without going above 10k.

Re: We use RethinkDB

#60
post #58

Earlier quoted context omitted.

I don't think 250GB will fit in memory on any reasonable sized box. What world do you live in?

An r720 from dell or similar model from dell with 600GB*2 SSD intel s3500DC model, 20 cores & 256GB of RAM will go for 5k-7k. You can bump this to 386GB of ram without going above 10k.

And up to 768GB if you go with 32GB LRDIMMs for about $14k (intel oem chassis).
Post reply on HN