RethinkDB performance data
rethinkdb.com
rethinkdb.com
Also, include the actual queries you are executing. Inserting into 2 columns with only a primary key index is a completely different beast than 30 columns with uniq key constraints and multiple multi-key indexes.
One thing we're finding is that people are skeptical by default. In retrospect, we probably should have expected this given the amount of false advertisement, magic bullets, and vaporware out there. We're not offering magic bullets - we're simply optimizing for modern hardware and modern workloads as opposed to 1970 hardware and database usage patterns. We'll be posting more benchmark results and detailed explanations of how RethinkDB works to win your confidence. We're not trying to trick you. What's the point? Eventually everyone would find out and the house of cards would collapse anyway. We just have only 24 hours in a day (btw, if anyone has a device to solve this problem, we'd love to beta test it!)
I'm curious, where does the Mysql/RethinkDB take this performance hit, or is this just a totally different benchmark?
Keyspace is a KV-store, but this shouldn't be a big deal, as a rowstore also inserts into a single btree as long as there are no secondary indices (A KV store inserts a K+V whereas a rowstore C1+C2..Cn.) Keyspace groups inserts into transactions of size ~1M in the benchmark I'm referring to. Are you inserting one row per transaction/sync here, or what's the deal?
BTW, an average drive rotates at 250 revolutions per second. If you flush on every transaction, this is roughly how many transactions you'll be able to sustain. Anything more than that, and you have to batch transactions in memory.
A couple of questions:
How has RethinkDB been affected by the recent changes to SSDs that have an improved firmware for garbage collection?
Unrelatedly, does RethinkDB use the same clustering strategies as MySQL?
We don't support clustered indexes. Clustered indexes are good on rotational drives because they allow you to read data as soon as you find an interesting node in the index tree. Because SSDs don't have slow random access, this is not necessary, so we don't do it.
I hope this means timing many, many calls and then timing the loop overhead, subtracting, and dividing by the number of calls made. Clocks just aren't good enough to time individual calls.
What's wrong with Objective-C?
Shouldn't they be using standard benchmarks, anyway? It's easy to write your own benchmark to make something look good.
You're absolutely right about standard benchmarks. We haven't engineered our benchmarking tools to make RethinkDB look good, we simply wrote code to run the most obvious operations - as many inserts as possible, as many selects as possible, etc. We will be moving to more commonly accepted benchmarks (such as TPC and iiBench) soon, but in the meantime it helps to have a simple benchmarking tool that shows off what RethinkDB can do on common workloads.
What is particularly efficient about the threading model? I know very little about Objective-C. Are you guys are very comfortable with it? Does someone writes Mac application there?