Suggestion: It would be great to have a page on your website that explains why RethinkDB is better than the other prevailing options. Right now I don't know why I'd want to invest time setting up yet another database.
Thanks -- will do in the next few days.
RethinkDB: An open-source distributed database built with love over three years
81–90 of 247 posts
Re: RethinkDB: An open-source distributed database built with love over three years
#82I don't know much about RethinkDB yet, but I will say that I have been a big fan (online) of one of its founders, Slava Akhmechet, for years. I've never met him, but he wrote some terrific articles on his website, http://www.defmacro.org/ , a few years ago. Start at the bottom of the list of articles, with "The Nature of Lisp." Slava is a deep thinker, which makes me very excited to take a look at RethinkDB.
Indeed - he mentions in the article that he set himself a goal to convert 10 programmers into Lispers. Sounds like he probably has that many just in this thread! Kudos, sir!
He helped get me into functional programming, which got me a contract job [1], which is how I met one of my current co-founders.
[1] http://martin.kleppmann.com/2009/09/18/the-python-paradox-is...
Re: RethinkDB: An open-source distributed database built with love over three years
#83Why would you use this over PostgreSQL, especially with pg's new json support?
JSON support in Postgres is currently limited to a validated plain text field, it doesn't let you efficiently query inside the json object.
With some simple formatting functions (its just json after all) it's sixes to me.
Re: RethinkDB: An open-source distributed database built with love over three years
#84-harryh
1. Yes, I know there are other ways to do this besides hashing the shard key, but this is often the best way.
Re: RethinkDB: An open-source distributed database built with love over three years
#85Earlier quoted context omitted.
Joe Doliner - RethinkDB engineer here. > Does it means that every query touches all servers ? No. > Or does it sends queries to only a subset of servers when possible ? (e.g. range queries on PK) The query planner distributes the query between the nodes that actually contain the relevant data. Here are a few examples: In your example, a range get on the primary key, the query would touch one copy of each shard of the…
> In your example, a range get on the primary key, the query would touch one copy of each shard of the table. But shouldn't it be fewer than "each shard"? Let's say the range is 3 < PK < 7. If all PKs in that range only lives in 2 shards (out of a total of say 10 shards) then the query should only be run in those 2 shards, no? Or will all 10 shards still be touched by the query?
Re: RethinkDB: An open-source distributed database built with love over three years
#86If I were you guys I'd strongly consider adding support for hashing of the shard key. There are many cases where you care about distributing your writes(1) a lot more than fast range queries on the PK. -harryh 1. Yes, I know there are other ways to do this besides hashing the shard key, but this is often the best way.
We'll be addressing this at some point, we have to sort through the list of feature requests first. It's a long list :)
Re: RethinkDB: An open-source distributed database built with love over three years
#87If I were you guys I'd strongly consider adding support for hashing of the shard key. There are many cases where you care about distributing your writes(1) a lot more than fast range queries on the PK. -harryh 1. Yes, I know there are other ways to do this besides hashing the shard key, but this is often the best way.
We actually support hash sharding underneath -- each range shard is further broken down into hash shards internally to support multicore scalability. This isn't exposed to the users currently, but it can be. Another option is to allow the user to provide a hash function on the PK (I think this is what you're suggesting). We'll be addressing this at some point, we have to sort through the list of feature requests firs…
Re: RethinkDB: An open-source distributed database built with love over three years
#88Re: RethinkDB: An open-source distributed database built with love over three years
#89What the heck does "built with love" even mean? Is this just a hipster marketing term to tell us that it's small and cute and made by people who play ukuleles and ride unicycles in their spare time, and not by evil corporate people who commute to work and have mortgages? I find a lot of advertising eyeroll inducing, and the current trend of more-hipster-than-thou posturing is right at the top.
Re: RethinkDB: An open-source distributed database built with love over three years
#90Please stop using json as a data model. I have no idea how to represent dates, or timestamps, or colors, or any other unsupported data type.
I have nothing to do with RethinkDB, but what are you talking about? Just represent them as strings. (What databases support colors as native types, anyways?) If you format dates YYYY-MM-DD, then you can do string comparisons for ranges. And JSON has the huge advantage of supporting hierarchical data -- arrays with objects inside, etc. It seems a like a huge step forward.