Temenos could not continue to rely on monolithic databases for manufacturing business operations. They needed a high-availability, scale-out transactional database, so they turned to YugabyteDB. They recently announced that the Temenos Banking Cloud is achieving 100,000 business transactions per second. Learn how that performance benchmark was achieved.
Category: Performance Benchmarks
The purpose of this blog post is to show how you can increase the failure threshold when a node goes down, which happens for a variety of reasons including hardware or network issues and most commonly maintenance. The failure threshold is the amount of time YugabyteDB would wait, after a node goes down, for it to potentially come back up. After reaching this threshold the physical data will begin to move from the dead node to other nodes in the cluster.
Organizations need to protect their data, especially the personal data entrusted to them from their users and customers. In order to do so, the data transferred by a database over the network needs to be secure. This is often accomplished using TLS encryption, an encryption protocol that secures communication across a network. When secured by TLS, a communication between a client and a server can enable the two parties to identify one another (preventing any impersonation),
“I don’t think it’s quite fair to condemn the whole program because of a single slip up, sir.” Famous last words from Kubrick’s 1964 classic Dr. Strangelove, as a forlorn general realizes his negligence is about to lead to nuclear apocalypse. This may feel relatable to any engineer who has immediately regretted pushing the big red “release” button only to later find themselves putting out fires late into the night.
We are excited to announce that the TPC-C benchmark implementation for YugabyteDB is now open source and ready to use! While this implementation is not officially ratified by the TPC organization, it closely follows the TPC-C v5.11.0 specification.
For those new to TPC-C, the aim of the benchmark is to test how a database performs when handling transactions generated by a real-world OLTP application. This blog post shows the results of running the TPC-C benchmark in addition to outlining our experience of developing and running a TPC-C benchmark against YugabyteDB.
In part 1 of this blog series, we highlighted multiple factual errors in the Cockroach Labs analysis of YugabyteDB. In this second post we provide the next layer of detail behind YugabyteDB’s architecture, with an emphasis on comparing it to that of CockroachDB’s.
- Query layer – reusing PostgreSQL
- Storage layer – engineered for performance at scale
- A deep dive into performance at large data sizes
- Results at a glance
- Take one – loading 1 billion rows with 64 threads
- CockroachDB: data load slowdown with data size increase
- Using multiple disks for a single large table
- Ranges vs tablets – architectural differences
- Impact of compactions on query performance
- YugabyteDB: 1B data load completed successfully
- Backpressure user requests when overloaded
- Take two – loading 450 million rows with 32 threads
- Detailed YCSB results
- Understanding performance in distributed SQL
Yugabyte SQL is based on a reuse of PostgreSQL’s native query layer.
When starting the YugabyteDB project, our founding thesis was to build a high-performance distributed SQL database for the cloud native era. Achieving high performance will always remain an ongoing initiative, especially when additional optimizations are required to support new features and new use cases. We are excited that the current YugabyteDB 2.1 release has a number of improvements that make Yugabyte SQL’s performance 10x better on average than the previous 2.0 release (from September 2019).
There are a number of well-known experiments where eventually-consistent NoSQL databases were scaled out to perform millions of inserts and queries. Here, we do the same using YSQL, YugabyteDB’s PostgreSQL-compatible, strongly-consistent, distributed SQL API. We created a 100-node YugabyteDB cluster, ran single-row INSERT and SELECT workloads with high concurrency – each for an hour and measured the sustained performance (throughput and latency). This post details the results of this experiment as well as highlights the key aspects of the YugabyteDB architecture that makes it fit for such high-volume ingest workloads.
This post addresses a concern raised about a benchmarking result we recently published comparing the performance of YugabyteDB, Amazon Aurora and CockroachDB. It was pointed out that we unfairly used the default isolation level for each database rather than use serializable isolation level in all databases (even though serializable level was not required for these workloads). In addition, we are also happy to share additional results with the workloads run at YugabyteDB’s serializable isolation level.
Update: A new post “The Effect of Isolation Levels on Distributed SQL Performance Benchmarking” includes performance results from running these workloads at serializable isolation level in YugabyteDB.
We are excited to announce the general availability of YugabyteDB 2.0 this week! One of the flagship features of the release was the production readiness of the PostgreSQL-compatible YugabyteDB SQL (YSQL) API. In this blog post, we will look at the performance and scalability of YSQL as compared to two other PostgreSQL-compatible distributed SQL databases –