Thank goodness Linux and Unix give us the monitoring tools to honestly look at every link in the chain and take appropriate action where action is needed.

I like that you are using the “right” tools to overcome the bottlenecks (as they arise) and not limiting your success by attempting to force the use of this one toolkit or that one framework, or one language, etc… Very smart. If C is the solution, use it. If C++ is the solution use it. If PHP is the solution, use it, etc, etc, etc… If Python presents a bottleneck, what might remove it. KISS. The right tool is whatever solves the problem, brilliant and comically simple.

I was remembering when a power user development machine was an 8086 without a hard drive and so little memory it was a joke, but a state of the art PC for the time. Heck I remember when you could only transfer data in 2MB chunks via a 3289 adapter from an IBM PC (4 mhz) to the mainframe, where you had to dutifully and carefully re-combine the data before you could use a relational database to manipulate it. And later when a power user development machine was a 286 processor (20 mhz or slower), 120MB or less harddrive, 16MB or less of RAM, yet it was a power user’s development machine. I am sure many of us remember those days.

Well thanks to those days, I have often wondered why more people did not divide and conquer with multiple boxes (simplifying the problem) rather than just jumping to “big iron”. I believe many companies jump prematurely to big iron, artificially increasing their Total Cost of Ownership (TCO) when a simpler (KISS) solution is available to them.

Some might say adding boxes to hold different pieces of the databases (divided in an intelligent meaningful way given what the data is used for) adds complexity, I would suggest that it increases the robustness of the solution. Just as a RAID system is better than a single hard drive. Just makes sense.

Heck in the mid 80s I had students working for me that were using 100 networked PCs to battle a Cray computer (or whatever students had at their university and could bet access too) playing Othello. Later it was used to do rapid image recognition. They used a Master / Slave setup with min/max algorithms that allowed the processing to finish within an allotted time limit. A IBM 50Z could do 7X the work of an IBM PC(8088), so 7X the work was sent to the 286 IBM 50Z. (Whille the Cray beat them in one round, they later found a problem in their algorithm that they believed might have allowed them to beat the Cray, sadly we will never know.)

Why not take a quad processor and dedicate each of those processors for specific purposes. Couldn’t two of those processors (actually probably 1 of the 4) process graphics fast enough to make GPUs on an adapter or even on the motherboard antiquated? After all the bus between the processors and the adapter cards is a potential source of bottlenecks. Add in four 1000 (or faster) Network Interrface Cards (NIC) and you increase the number of access to the points for the portion of the database sitting on that machine in its memory.

Put multiple proxies in front of those machines, it seems like you could design a system that would be all but impervious to DDOS attacks. A solution with more boxes, not fewer seems like it would be more robust against that type of attack.

What you guys are doing is exciting and seems logical. I look forward to seeing, reading and eventually implementing your success. I predict you will be very successful.

Michael: Watch for our next post.

Looking forward to your next development!

These graphs are essentially just snapshots of what we’re doing internally, not metrics we’d use to convince anybody to switch, and they’re just meant to give a general idea of how we’re doing.

We’re eager to run “real” benchmarks, like TPC, as you suggested, but that isn’t necessary until we’re ready to offer a production package. For now, these benchmarks tell us where to focus, and that’s enough.

Sam: The MySQL API is C++, so we’re using that, although most of our engine code is closer to straight C.

-rather than writing your own benchmark program, it’d be more informative to use one of the many standard DB benchmark tools available such as dbSTRESS or tpcc-mysql

-benchmarking with 1 insert thread and 2 select threads isn’t very useful if you’re targeting the web app market (which you seem to be since you mentioned you spent most of your time testing RethinkDB with Wordpress). A web app with only 3 concurrent users has minimal performance demand anyway. A far more realistic use case would be benchmarking with a high number of concurrent users (32, 64, 256…) each doing select or insert or update.

Basically something like this: http://dimitrik.free.fr/blog/archives/08-01-2009_08-31-2009.html