Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've been playing around with Rethink for a couple of days now, and I just can't get over how nice the admin web UI is. Scaling up machines is quick and easy, and it's pretty simple to resolve master/secondary issues when one of the servers goes down (or it's shut off).

I'm seeing some performance issues, and I'm definitely going to spend some time messing with my test data and optimizing it for Rethink. Right now, a couple of basic counting queries take ~1 second when the MySQL equivalent takes milliseconds. The other issue I'm having is that I simply did an import of existing data from MySQL that contains dates, which are treated as strings, so I'll need to convert the dates into a native format (integer based timestamps) before I can get some more performance numbers.



Keep us posted on the performance issues you experience-- the team hangs out on IRC (#rethinkdb on freenode) and are usually more than happy to help work through these problems. If you identify a specific query that isn't performant, please open an issue on Github as well (http://rethinkdb.com/docs/comparison-tables/).

Also, RethinkDB 1.8 (shipping next week) will include native date support. You can follow the progress and discussion of the planned interface here: https://github.com/rethinkdb/rethinkdb/issues/977?source=cc


Great. I've been meaning to jump on IRC with some questions, but haven't had the time to do so yet. I'll definitely be waiting for 1.8.


Anyway timestamps are better. First reason is difference in implementations of "date"-formats in almost each database, and second reason - integers will always faster than strings or structures.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: