Live data from Hacker News

RethinkDB: An open-source distributed database built with love over three years

rethinkdb.com

81–90 of 247 posts

Re: RethinkDB: An open-source distributed database built with love over three years

#81
post #17

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.

[deleted]

Re: RethinkDB: An open-source distributed database built with love over three years

#82
post #72

I 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 didn't make me a Lisper (I'm more a Haskell fan these days), but reading Slava's Lisp articles years ago was a significant part of what set me on my current career path.

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

#83
post #63

Why 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.

While technically correct I assume the parent was referring to hstore [0] which has both GIST and GIN indexes as well as btree and hash for equality.

With some simple formatting functions (its just json after all) it's sixes to me.

[0] http://www.postgresql.org/docs/9.2/static/hstore.html

Re: RethinkDB: An open-source distributed database built with love over three years

#84
If 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.

Re: RethinkDB: An open-source distributed database built with love over three years

#85

Earlier 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?

Correct, the query will only touch two shards in this case.

Re: RethinkDB: An open-source distributed database built with love over three years

#86
post #84

If 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 first. It's a long list :)

Re: RethinkDB: An open-source distributed database built with love over three years

#87
post #84

If 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…

I don't feel the need to provide the hash function, as long as it's something reasonable. I understand that it's a long list! Just adding a vote to one particular item. Good luck!

Re: RethinkDB: An open-source distributed database built with love over three years

#89
post #39

What 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.

Since it's under the AGPL it will mostly be built by people that have been vetted. By switching to this people are one step closer to having a machine that boots without assholes. http://rusty.ozlabs.org/?p=196

Re: RethinkDB: An open-source distributed database built with love over three years

#90

Please 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.

But there's no standard way of representing the dates as strings, or indicating that this field here is a date and not a string that happens to look like one, so nothing can rely on what you do. You can represent literally anything with a string, but you lose type information when you do.
Post reply on HN