The interfaces of the NoSQL platforms are different from traditional SQL databases, which implies a significant shift for a company’s product.
NoSQL databases are typically hard to configure for large deployments.
Most NoSQL databases do not guarantee ACID transactions, which impacts how these databases are used by applications.
The few that do guarantee ACID transactions have scalability problems. In many cases, the system might not be capable of growing as much as the workload requires.
LeanXcale is a database that solves these problems without impacting current systems:
LeanXcale offers an SQL interface that follows the query language standard to make it easier to adapt to the new database system. Companies won’t need to spend much effort refactoring products to adapt to this scalable database.
Being easy to configure, LeanXcale offers an on-premise instance entirely configured and ready for use out of the box.
LeanXcale guarantees full ACID transactions, so you won’t need to adapt your product.
Based on its patented system, LeanXcale can scale as much as the workload requires while maintaining full ACID transactions, so companies can grow as much as needed.
In this article, I test the horizontal scalability of the LeanXcale database using the TPC-C benchmark.
As described above, LeanXcale is a distributed database, and it offers disruptive features. Scalability is the most relevant for this benchmark, although we also use the dual interface through which LeanXcale provides a key-value interface offering fast insertions, gets and scans, and an SQL interface through a JDBC driver. This key-value interface populates the database and prepares all data required to run the clients of the benchmark. Through the JDBC interface, the client of the benchmark runs the SQL queries.
You can get a more in-depth description of LeanXcale capabilities here.
The TPC-C Benchmark
This benchmark simulates different user queries, each running some linked queries with the following percentages:
On each data node, we populate the benchmark with 200 warehouses, then run the benchmark with 1, 20, and 100 data nodes. Each data node includes a Query Engine responsible for managing the transactional workload for a fraction of the clients. The data nodes also have an instance of the storing engine, KVDS. Each KVDS instance oversees a fraction (200 warehouses) of the entire dataset.
The result of this benchmark is the number of new order operations (around 45% of the total operations of the benchmark) and is expressed as tpmCs. The benchmark passes if the number of tpmCs is around 12,5 tpmCs per warehouse.
The following chart shows the tpmCs obtained with the following configurations:
- 1 data node with 200 warehouses: 2.500 tpmCs
- 20 data nodes with 4.000 warehouses: 50.000 tpmCs
- 100 data nodes with 20.000 warehouses: 250.000 tpmCs
The number of transactions of the system is relevant for the TPC-C benchmark as well as the response time. With LeanXcale, the average response time (during 15 mins) is independent of the number of warehouses and data nodes in the deployment. The following chart shows the response time during the last 15 minutes of the TPC-C benchmark. As can be seen, the response time maintains a maximum of 80 ms and a minimum of 45 ms.
Diego Burgos Sancho, Software Engineer at LeanXcale
After working at the Distributed Systems Lab at the Technical University of Madrid as a computer scientist, I joined LeanXcale to build one of the most interesting distributed systems ever developed. At LeanXcale, I’m performing research through an industrial PhD at the Technical University of Madrid.