Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

rethinkdb.com

Post reply on HN
Print view View original

161–170 of 247 posts

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

#161

Post by j-kidd »

i386 wrote: post #159
biturd wrote: post #153

Earlier quoted context omitted.

Thanks for this work, it looks really nice. I was looking at the github comments about a home brew recipe in which it was stated that aside from a recipe creating a VM, the Mac OS X port would take a bit longer. Is that a full port from one language to another? Or just an issue of the different flavors of *nix that need dealing with and probably some of the dependency tree issues that come with it? I'm curious what n…

Seems to me that most of us who have used MacPorts have moved to Homebrew or that could just be the bubble I'm living in. Is there anyone still who still uses MacPorts who could chime in and say why they never made the switch?

Come on, Homebrew doesn't even have gcc.

I am not a Mac user, but a designer using MacBook joined our team last week, and we struggled for half a day with Homebrew. The next day, we installed MacPorts instead, and with just:

$ sudo port install python27 py27-virtualenv gcc46

we were able to proceed and get the whole stack up and running. Not to mention everything from MacPorts is installed nicely under /opt/local.

MacPorts is just way ahead of Homebrew. OTOH, Portage is way ahead of MacPorts ;)

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

#162

Post by jchrisa »

erichocean wrote: post #139
erichocean wrote: post #134

I find JSON-oriented databases to be a huge limitation for writing applications managing any kind of financial data, due to the lack of a decimal number type and a timestamp/date type, both of which SQL provides (and are used A LOT). Sure, you can put that stuff in strings, but then you'll run into limitation with queries where you want to, e.g., aggregate a total, or do timestamp arithmetic. I could do everything wi…

The other thing that bothers me about all these new JSON databases is they aren't really novel anymore. Clustered databases are essentially a solved problem, and have been for years. What's needed today are databases solving the problem that Google Spanner addresses – global consistency across distributed clusters in separate data centers. If you want a challenge in the DB world, that's where it is. But another clust…

Try keeping it running while growing to millions of users in weeks. The simple data model lets us focus on elasticity and performance. There's a lot more to production quality software than the algorithms, but there are only a few NoSQL databases that get the algorithms right.

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

#163

Post by rdtsc »

kemiller wrote: post #90
crazygringo wrote: post #75

Earlier quoted context omitted.

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.

There is a standard for representing string (see sibling comment) and your type information is the field name. So you know your document has a type if you give it a d_type field for example and then based on that you know your tstamp field is the date.

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

#164

Post by kinleyd »

jdoliner wrote: post #76
xutopia wrote: post #69

Earlier quoted context omitted.

What's the elevator pitch? Maybe we can help you with those advantages if you can tell us right now.

The elevator pitch is: "Mongo's ease of use without the gotchas." We have a nice simple to use query language and quick setup process. But things like analytic queries like map reduce don't lock up the entire database. Our product aims to not be a ticking time bomb of technical debt.

Sounds like an excellent elevator pitch.

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

#165

Post by leif »

alexpopescu wrote: post #141
erichocean wrote: post #133

Earlier quoted context omitted.

And yet the Clojure guy did his distributed DB in Clojure (aka, Lisp). Kind of makes me wonder why C++ was chosen...

I've joined RethinkDB just a couple of months ago, so I might not have all the historical facts right, but here is what I know. In a previous incarnation RethinkDB was a highly optimized storage engine for SSDs implemented in C++ to be able to take full advantage of both low level SSD and kernel access. The current distributed engine was built on top on this storage engine and I think it only made sense to continue w…

Originally, RethinkDB was to be a MySQL storage engine, which made C++ the natural choice.

They pivoted away from MySQL after my short stint in the beginning so I can't speak to why the storage code was kept (though I can't imagine it's because my code was so great they couldn't bear to throw it away).

Storage people tend to stick close to the metal, in general. This means C or C++ in most cases, for better or for worse.

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

#166

Post by merlincorey »

j-kidd wrote: post #161
i386 wrote: post #159

Earlier quoted context omitted.

Seems to me that most of us who have used MacPorts have moved to Homebrew or that could just be the bubble I'm living in. Is there anyone still who still uses MacPorts who could chime in and say why they never made the switch?

Come on, Homebrew doesn't even have gcc. I am not a Mac user, but a designer using MacBook joined our team last week, and we struggled for half a day with Homebrew. The next day, we installed MacPorts instead, and with just: $ sudo port install python27 py27-virtualenv gcc46 we were able to proceed and get the whole stack up and running. Not to mention everything from MacPorts is installed nicely under /opt/local. Ma…

clang is better than gcc, IMO

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

#167

Post by coffeemug »

biturd wrote: post #153
coffeemug wrote: post #130

Hey guys, Slava here. I've been up since yesterday, so I'm going to clock out (though some of the team members are still lurking here). I wanted to thank everyone for great feedback. We're working hard to improve Rethink over the next few months. FYI, you can always hop on IRC (#rethinkdb on freenode) or github tracker ( https://github.com/rethinkdb/rethinkdb/issues ) with questions and we'll help you out.

Thanks for this work, it looks really nice. I was looking at the github comments about a home brew recipe in which it was stated that aside from a recipe creating a VM, the Mac OS X port would take a bit longer. Is that a full port from one language to another? Or just an issue of the different flavors of *nix that need dealing with and probably some of the dependency tree issues that come with it? I'm curious what n…

Most of the issues come from kernel differences. Some are relatively big, like epoll vs. kqueue, and some are very subtle (some syscalls have subtly different behavior on strange edge-case scenarios). I don't think building this natively would be too hard, but in the context of everything else left to do, it isn't an absolutely trivial project.

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

#168

Post by coffeemug »

m0th87 wrote: post #148
coffeemug wrote: post #122

Earlier quoted context omitted.

To add to jdoliner's answer, the reason why you can write table('foo').filter(lambda x: x['bar'] > 5).run() is because we do some language trickery on the client side to compile the query to an AST. In this case, we overload greater than operator, call the lambda function once on the client with a special object, and return an AST. This AST is then sent to the server and executed there. It's rather difficult to integ…

Does the function have to be referentially transparent?

No. E.g., you could write r.table('foo').update(lambda row: row.merge({'bar': row['bar'] + 1 })). A shortcut for this is r.table('foo').update({'bar': r['bar'] + 1 }). Neither is referentially transparent, and both work.

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

#169

Post by tbrock »

j-kidd wrote: post #161
i386 wrote: post #159

Earlier quoted context omitted.

Seems to me that most of us who have used MacPorts have moved to Homebrew or that could just be the bubble I'm living in. Is there anyone still who still uses MacPorts who could chime in and say why they never made the switch?

Come on, Homebrew doesn't even have gcc. I am not a Mac user, but a designer using MacBook joined our team last week, and we struggled for half a day with Homebrew. The next day, we installed MacPorts instead, and with just: $ sudo port install python27 py27-virtualenv gcc46 we were able to proceed and get the whole stack up and running. Not to mention everything from MacPorts is installed nicely under /opt/local. Ma…

Hahah don't be naive. Use homebrew. Macports has been broken for years.

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

#170

Post by tbrock »

ch0wn wrote: post #14

This looks really interesting. I'm interested to see how their license choice works out. The server is AGPL-licensed while the drivers are under Apache 2.0. This should at least avoid the issues we all know from libmysqlclient.

Same licensing that 10gen uses for MongoDB (AGPL) and drivers (apache).
Post reply on HN