01 General overview
VoltDB is trusted by global telecom software solution providers, who use it as the preferred in-memory database to drive their mission-critical applications deployed at more than 100 operators worldwide. VoltDB is favored because its performance and functions can not only solve current challenges, but also support the rapid development of various systems in the industry.
Our benchmarks below show how VoltDB's performance meets or exceeds the requirements of telecommunications systems, and demonstrates the high performance, low latency, and linear expansion that VoltDB has to drive industrial revolutions such as 5G.
In this benchmark test, we tested VoltDB v8.3 in the cloud, and then observed the performance that can scale linearly with the number of servers and the speed of more than 3 million operations/sec, with only single digit latency from start to finish.
1. VoltDB and 5G development
The emergence of 5G has brought some important challenges to telecom software solution providers. In addition to the new hardware standards, this network evolution also requires OSS and BSS to support IT functions to change. The creation of additional revenue opportunities through new services requires flexibility and scalability of OSS and BSS functions to enable new use cases to be realized under increasing loads.
This requirement for the system increases the importance of supporting databases, whose function is no longer simply to store data, but to act as an active real-time decision-making system.
In short, VoltDB is a carrier-grade database that fully meets the requirements of active real-time decision-making systems, such as those that may be needed to support 5G. VoltDB is a memory relational database with extremely important and uncompromising scalability, programmability and consistency. Applications built on VoltDB, whether in telecommunications, finance or retail, have horizontal scalability, can withstand the test of complexity evolution, and are very reliable in terms of consistency and uptime.
In theory, the solution can be pieced together by multiple open source tools for streaming, cluster management, database storage, and memory caching, but in practice, these solutions fall short of the requirements. They usually increase the latency between systems, the operating costs of managing multiple software stacks on a large number of servers are high, and they create a client programming burden when checking and managing consistency and correctness.
VoltDB is not only a high-performance database, it also provides the core architectural elements required to drive mission-critical real-time telecommunications applications:
- Strictly comply with ACID requirements
- Materialized views, stored procedures, and user-defined functions
- Inherent high availability, disaster recovery and multi-site cross-data center replication
- Cloud/container ready
- Import/export stream
When it comes to embedding the right database to drive 5G applications, there is no room for compromise. Having a mature enterprise-level database (not just features and functions, but also round-the-clock support and skilled professional services) is critical to the success of 5G.
02 benchmark
2.1 Online billing system
The online billing function is an ideal example to understand the challenges that 5G brings at the system level. For the ever-increasing diversity of devices, the solution must not only deal with the connection load from billions of newly connected devices, but also the complexity of implementing different strategies.
Therefore, online charging in 5G networks must be able to scale with load and functional complexity without compromising consistency or performance.
2.2 Why do we need ACID?
The system architecture of these applications uses different methods to deal with the impact of these challenges. Most applications use key-value storage to obtain the benefits of their so-called unlimited scalability, but these applications are forced to use custom mechanisms to implement transactions, resulting in a complex system that cannot honor simplicity and scalability. The initial promise of sex.
Even the fastest key-value stores require additional client-server communication and custom blocking and consistency checks, all of which will increase latency and network burden.
On the other hand, the problem of scaling with traditional databases is well known. We believe that VoltDB occupies a unique position in today's database market. It can not only solve the scalability and complexity challenges, but also ensure the highest consistency and strictly serialized ACID transactions.
2.3 Implementation details
We tested VoltDB database instances built with 3, 9, 18, and 27 node clusters provided by Google Cloud Platform. The workload simulated a simplified online billing application. After preloading the data, the benchmark application ran for 10 minutes.
We collected performance statistics on the number of transactions per second (TPS) and the 99th percentile latency during the run (each VoltDB transaction is a single application "operation" and the terms are interchangeable). The graph data from these statistics prove that VoltDB has linear scalability to cope with increasing workloads while maintaining predictable low latency.
2.4 Application
The application mainly consists of a Java client and a VoltDB database. The pre-stored program that implements the processing logic of each operation is coded in both Java and SQL to run on the database.
The benchmark application manages the user's balance, while allowing them to purchase new services and add other limits, such as minutes, data, messages, etc. The client relies on the database to run complex transactions with multiple SQL statements and conditional logic that can fully guarantee ACID characteristics.
2.4.1 Architecture
As a relational database, the data in VoltDB consists of the following tables. Each table is either partitioned, where data rows are distributed among different locations (sites_per_node * node_count), or replicated, where each node has a complete copy of the data table. Tables that are updated infrequently, such as the product table, are ideal examples to save as replicated tables.
However, the product table is part of the main workload because it is used to get the price of the product that the user is trying to buy. User tables, usage tables, and balance tables are created as partition tables to achieve high-concurrency read and write access.
2.4.2 Data
The workload runs on a stable data set that scales according to the size of the cluster. The starting data set sizes of different clusters follow the following proportions:
2.4.3 Workload
The workload consists of two operations that run in parallel, namely allocating quotas and adding users/balances. These operations are implemented in Java + SQL and involve the use of conditional logic to execute multiple SQL statements. The benefits of these statements are to reduce network travel and achieve more work in each logical transaction.
After the initial data set is loaded, two operations in the workload are called in parallel at the same frequency to achieve the target throughput. Both operations are complex and involve decisions that must be made by joining data from multiple tables. By implementing each operation as a VoltDB stored program, the entire operation will succeed or fail as a complete transaction, and the status will be returned to the client application:
"
Allocation quota-access to 4 tables. Assign only when the user's account balance is sufficient Limit and reduce the balance after successful allocation.
Add user/balance-access 2 tables. Add a new user to the system or increase the balance of a user.
2.4.4 Metric
The benchmark application was run on different node configurations to prove VoltDB's scalability when running highly transactional workloads. We capture latency and throughput data points on each node configuration and use them to draw a scalability curve.
We capture data points after running for 10 minutes. This waiting period helps us ensure that the system reaches a steady state of moderate CPU utilization (between 55% and 60%), and the RAM utilization of each machine is roughly 33%.
2.5 Environment
The benchmark test was conducted on a Google Cloud instance. The node configuration is as follows:
03 Benchmark test results and analysis
Regarding the background of the benchmark results, we want to clarify that based on our conversations with telecom customers, the SLA for the most demanding 5G applications is a predictable latency of less than 5 milliseconds, and 2~6 million processing per second The ability of data rows and the ability of linear expansion. We can look at the benchmark results in the context of these strict SLAs.
Throughput and latency of VoltDB (4 partitions running on a 4-core machine)
This graph shows the approximate linear expansion of throughput and number of nodes. The largest cluster tested contains 27 nodes. The highest throughput observed is 740,703 operations per second.
The above figure also shows that for each tested cluster size, the 99th percentile latency meets the 5 milliseconds required by the SLA (except for the 27-node cluster, where the latency is slightly longer than 5 milliseconds). Considering that 5G telecom SLA is the most stringent of all industries or use cases, and the complexity of billing applications, VoltDB's ease of surpassing throughput and latency SLA is a very remarkable achievement.
Throughput and latency of VoltDB (16 partitions running on a 16-core machine)
The benchmark test runs on a 16-core machine, which is closer to the configuration in the production system, so it can be a good measure of VoltDB's performance. Similarly, VoltDB exhibits linear scalability and has achieved a throughput of more than 3 million operations per second on a 27-node cluster, so it can meet or exceed SLA requirements.
For various cluster sizes, VoltDB's latency is much lower than the 5 milliseconds required by the SLA. For a smaller cluster of 3 nodes, its 99th percentile latency is slightly longer than 3 milliseconds, while for other cluster configurations, its latency is less than 3 milliseconds!
Throughput comparison of different VoltDB clusters (4 partitions running on a 4-core machine and 16 partitions running on a 16-core machine)
Unsurprisingly, as the partition size increases and the number of cores increases, throughput increases significantly. For a 27-node cluster with 4 cores and 4 partitions, the throughput is less than 75K, while for a 27-node cluster with 16 cores and 16 partitions, the throughput exceeds 3 million operations per second!
Latency comparison of different VoltDB clusters (4 partitions running on a 4-core machine and 16 partitions running on a 16-core machine)
The trend of throughput increasing with the number of servers/partitions also applies to latency. The most powerful 16-core server with 16 partitions has a lower 99th percentile latency than a 4-core server with 4 partitions. For a 27-node cluster of 4-core machines, the delay is just over 5 milliseconds, while for a 27-node cluster of 16-core machines, the delay is less than 3 milliseconds.
3.1 The secret to achieving high scalability
"As mentioned earlier, VoltDB is designed for linear scaling. In order to achieve a throughput of even more than 3 million operations/sec, users simply need to add VoltDB nodes until the desired throughput is obtained."
3.2 Total Cost of Ownership (TCO)
In addition to top-notch performance, VoltDB also has a much lower TCO than any other solution in the industry. Although some people may think that "open source solutions are free", there is no free lunch in the world.
Many telecom customers who initially chose open source solutions turned to VoltDB after experiencing a lot of pain. They also realized that open source tools often run on larger hardware, resulting in very high capital expenditures, and because these solutions require costly development efforts for product construction, maintenance, and fault detection, operating costs are far higher For VoltDB product licenses that provide 24/7 product support.
One of the world's largest telecom software solution providers switched from Redis to VoltDB, saving a million dollars in hardware alone.
04 Conclusion
In response to the inflexibility of traditional SQL databases (such as Oracle, IBM, SQL Server, etc.), NoSQL databases (such as Redis, Cassandra, MongoDB, etc.) have come out. They blatantly claim that they can expand by storing and querying unstructured data without implementing the structured concept of relational databases.
Although they initially claimed that NoSQL databases do not "rely on" SQL to be beneficial, the fact that SQL's standardization, flexibility, and efficiency in querying large amounts of data cannot be replaced prevents them from entering high-performance or mission-critical applications. Sex.
NoSQL vendors' attempts to support the SQL language at the top level still failed to achieve their goal: to provide basic ACID feature guarantees similar to current SQL databases. A next-generation SQL database like VoltDB is a solution that has the best of both worlds, with the scalability of a NoSQL solution, and the high throughput, low latency, high availability, powerful ACID transactions, real-time analysis, and Other functions.
The results of this benchmarking study prove that VoltDB can provide the linear scalability, low latency, and high throughput required for extremely demanding 5G applications without sacrificing consistency. VoltDB's throughput of more than 3 million operations/sec and the 99th percentile delay of less than 5 milliseconds can meet the SLA proposed for 5G systems, while NoSQL databases are far from meeting the performance and latency requirements of telecom applications. If you want to run benchmark tests, we recommend that you download the application source code from our public repository and try it yourself:
https://github.com/VoltDB/app-telco-charging
If you are interested in VoltDB's industrial IoT big data low-latency solution, welcome to poke privately and enter our official WeChat exchange group.