SQL Layer is built to provide competitive performance on a per-machine basis with traditional RDBMS's while providing a fundamentally more scalable architecture which separates the storage tier from the SQL query processing tier.
To compare performance, we use the open-source sysbench benchmark running in read/write mode. We use a ~80GB 300M row dataset that falls well outside the 8GB page cache that we use on both systems. We run both MySQL 5.5.37 and the Key-Value Store on a commodity quad-core server with an enterprise-grade SATA SSD. Though this would be an unusual deployment for the Key-Value Store, it creates common ground for comparison. In both cases we drive load from a set of four client machines each running sysbench, and, in the case of FoundationDB, the SQL Layer process.
For the classic sysbench R/W benchmark, SQL Layer is about half the speed of MySQL:
SQL Layer is slower because of the overhead of network communication between the SQL Layer processes and the Key-Value Store. This overhead becomes an inevitability in larger clusters, but FoundationDB is paying for it even in this simple configuration.
A secondary effect is from the different page sizes. MySQL uses 16K pages which are an excellent choice for the medium-size range scans prevalent in sysbench whereas FoundationDB uses 4K. In a small random-read test favoring 4K pages the numbers can make SQL Layer the winner. Just goes to show that you need to test performance yourself using your workload.
Of course, a single-machine cluster as tested above isn’t very exciting! The real power of SQL Layer is that any number of SQL Layer processes can run against a single, scalable, Key-Value Store cluster. This creates a single, unified, ACID transactional SQL database with exceptional fault-tolerance and scalability. (For details on how this works, see the recommended architecture.)
In this test we show the performance as we add more SQL Layer clients:
Because we pay for the overhead of our architecture even in the single-machine case, we see performance increase linearly as we add more SQL Layer clients. In this test, a powerful Key-Value Store cluster supports 32 clients without saturating. Linear scalability will hold for any workload which does not exceed the performance capabilities of the underlying Key-Value Store.
FoundationDB Key-Value Store and SQL Layer work together to provide an exceptional architecture for applications that need both fault-tolerance and high performance. Though the distributed architecture pays an overhead cost for network communications that cannot be easily avoided, it enables a scalable architecture impossible with a traditional RDBMS.
All machines are E3-1240v1 4 core CPU, 16GB RAM, 200GB INTEL S3700 SATA SSD
sysbench table
Rows: 300,537,650 (about 10% fits in cache)
Average Row Length: 229 bytes
Sysbench OLTP test-mode
Machines were restarted after the data was loaded and before running sysbench to start from an equivalent clean buffer pool.
SQL Layer machines are at about 40% CPU utilization as would be the case when collocated with an app-server.
A single machine with 4 K/V processes, SSD engine, single replication, driven by 4 SQL Layer client machines with 8-thread sysbench process.
In FoundationDB All operations are fully ACID transactional at the highest possible level of isolation (SERIALIZABLE) and durability (commit means flushed to disk in three places).
For MySQL we used a single machine, allocated 8GB of buffer pool memory, default trasnaction isolation level of REPEATABLE-READ with:
40 machine cluster
E3-1240v1 4 core CPU, 16GB RAM, 200GB INTEL S3700 SATA SSD
sysbench table
Rows: 10,000,000
Average Row Length: 229 bytes
Sysbench OLTP test-mode
8 machines with a single K/V process each, SSD engine, triple replication and a variable number of upto 32 SQL Layer client machines with 8-thread sysbench process per machine.
In FoundationDB All operations are fully ACID transactional at the highest possible level of isolation (SERIALIZABLE) and durability (commit means flushed to disk in three places).
