January 2018 Summaries

YugabyteDB's DocDB storage engine is capable of handling very high data densities per node, which helps keep server footprint and cloud provider bills low. The system was tested on a 4-node cluster in Google Compute Platform with a total data set size of approximately 1.4TB across 300-byte key values and 50-byte value sizes. The results showed that YugabyteDB achieved sub-ms read latencies, with an average read latency of 0.88 ms, and an optimal number of disk I/Os for the workload. This is made possible by Yugabyte's highly optimized storage engine, which effectively chunks/partitions and caches index and bloom filter blocks. The system also demonstrated high bloom filter efficiency in minimizing the number of I/Os to SSTable files in its Log-Structure-Merge organized storage engine.

Google Cloud Spanner and Azure Cosmos DB are CAP (Consistency-Availability-Partition Tolerance) compliant databases that provide high availability, but at the cost of potentially slower write performance due to the need for leader election in case of network partitions. YugabyteDB, on the other hand, is an EL (Low Latency - High Consistency) database that allows lower latency operations by tuning consistency down, making it suitable for cloud-native applications with strict latency requirements. While Google Cloud Spanner and Azure Cosmos DB offer strong consistency guarantees, YugabyteDB offers tunable read consistency, including optional read-only replicas for remote regions, which can be beneficial in multi-region deployments.

YugabyteDB is compatible with the Redis API, providing a true distributed and fault-tolerant database that simplifies the use of Redis as a primary database, eliminates the need for manual sharding and replication, and offers built-in block caching and polyglot persistence to support diverse workloads.

YugabyteDB is a cloud-native database that has been benchmarked to achieve linear scalability with 50 nodes, doubling read and write throughput while maintaining low latencies of around couple of ms. The benchmark was performed on Google Cloud Platform using 50 compute instances with 16 virtual CPUs, 60GB RAM, and 2 x 375 GB direct attached SSDs, and replicated data with a factor of 3. YugabyteDB performs strongly consistent reads and writes by default, with low CPU usage of around 65% for reads and 75% for writes. The database can deliver similar performance outcomes on other public clouds as well as on-premise data centers. It is possible to install and try YugabyteDB out by following simple Quick Start instructions, which are also available in the documentation.

YugabyteDB's YEDIS API offers a native time series (TS) data type that simplifies modeling and retrieving time series data with high performance. The TS data type uses a sorted map from a 64-bit integer to a single object, making it easy to model time series data by using the timestamp as an integer and the value as the associated measurement. This approach supports adding new data points efficiently through the TSADD operation, looking up values for specific timestamps with the TSGET command, retrieving data within a range of timestamps with TSRANGEBYTIME, and deleting entries with the TSREM command. Additionally, the TS data type allows setting a TTL (time-to-live) for each timestamp using the EXPIRE_IN and EXPIRE_AT commands, enabling efficient purging of expired data. In contrast to traditional Redis approaches using Sorted Sets or plain key-values, YEDIS's TS data type addresses common issues such as memory and CPU consumption, read-modify-write operations, and synchronization complexities. By leveraging this native time series data type, developers can build scalable and performant applications that efficiently store and retrieve time-stamped data.