Benchmarking Couchbase Server for Interactive Applications
2 likes1,521 views
This document provides a benchmark comparison of Couchbase, Cassandra, and MongoDB for interactive applications with high in-memory data loads. It describes the key criteria for databases used in these applications, including scalability and low latency performance. The infrastructure and settings for benchmarking the databases are outlined. Results are then shown for read, insert, and update latencies as well as 95th percentile times. Finally, the document analyzes the results and concludes that Couchbase is well-suited for interactive applications requiring low latency access to large, in-memory datasets.
Benchmarking Couchbase Server for Interactive Applications
- 1. Benchmarking Couchbase for Interactive Applications with High In-memory Data Loads By Alexey Diomin and Kirill Grigorchuk
- 2. Using NoSQL Databases for Interactive Applications Contents 1. Introduction .................................................................................................................................. 3 2. A brief overview of Cassandra, MongoDB, and Couchbase ........................................................ 3 3. Key criteria for a DB used in interactive applications ................................................................ 4 4. Infrastructure and settings for benchmarking ............................................................................ 6 5. Results: latencies for reads, inserts, and updates ..................................................................... 8 6. Results: 95th-percentile time for reads, inserts, and updates ................................................. 10 7. Analysis ....................................................................................................................................... 11 8. Conclusion ................................................................................................................................... 11 9. Additional Links .......................................................................................................................... 12 10. About the authors .................................................................................................................... 12 ©Altoros Systems 2
- 3. Using NoSQL Databases for Interactive Applications 1. Introduction Today, most interactive Web applications need high-performance and scalable databases. Unless you have implemented and managed large deployments of NoSQL databases that support data-intensive distributed applications, then dozens database of options are probably a slight enigma. And if your application is not fast enough, users may quickly abandon it and look for alternatives. In paid online social games, players are extremely demanding and will drop out, even if there is a slight delay. To deliver the best user experience, you must pick the right storage system: fast, scalable, and robust. Unfortunately, the capabilities of traditional RDBMS for working with big data are limited—they cannot provide the necessary scalability and performance. NoSQL databases have become a viable alternative to RDBMS—particularly, for applications that need to read or write enormous amounts of data rapidly. They provide high throughput, low latency, and horizontal scaling. However, with so many different options around, choosing the right NoSQL database can be tricky. This research paper provides information on how Couchbase—a scalable, document-oriented database—performs in comparison to Cassandra and MongoDB, the most popular NoSQL systems. The test scenario simulated workloads typical of interactive Web applications, such as social and mobile games, real-time ad platforms, etc. In use cases like these, most, if not all of the working data set is often stored in RAM to ensure low latencies under heavy loads. So, this research is mainly focused on testing how the three systems behave in such a scenario. The paper was sponsored by our client and partner Couchbase, Inc., the developer of the Couchbase system. 2. A brief overview of Cassandra, MongoDB, and Couchbase If you are already familiar with these NoSQL databases, you might want to skip the rest of this section and go directly to the performance evaluation. Cassandra is a distributed columnar key-value database with eventual consistency. It is optimized for write operations and has no central master—data can be written or read to and from any of the nodes in a cluster. Cassandra provides seamless horizontal scaling and has no single point of failure. If a node in the cluster fails, another node steps up to replace it. At the moment, Cassandra is an Apache 2.0 licensed project supported by the Apache Community. MongoDB is a schema-free, document-oriented, NoSQL database that stores data in the BSON format. A BSON document is essentially a JSON document in the binary format, which allows for easier and faster integration of data in certain types of applications. This database also provides horizontal scalability and has no single point of failure. A MongoDB cluster is different from a Cassandra or Couchbase Server cluster, as it includes an arbiter, a master, and multiple slaves. Since 2009, MongoDB is an open source project with the AGPL license supported by 10gen. ©Altoros Systems 3
- 4. Using NoSQL Databases for Interactive Applications Couchbase is an open source NoSQL document database for interactive Web and mobile applications. Documents in Couchbase Server are stored as JSON. With built-in caching, Couchbase provides low-latency read and write operations with linearly scalable throughput. The architecture has no single point of failure. It is easy to scale-out the cluster and support live cluster topology changes. This means, there is no application downtime when you are upgrading your database, software, or hardware using rolling upgrades. Couchbase, Inc. develops and provides commercial support for the Couchbase Apache 2.0 licensed project. 3. Key criteria for a DB used in interactive applications When choosing a database for interactive applications, the following are the most important factors to keep in mind: Scalability: It’s hard to predict when your application needs to scale, but when your Web site traffic suddenly spikes and the database does not have enough capacity, you need to scale quickly, on demand, and without any application changes. Similarly, when your system is idle, you should have a possibility to decrease the amount of resources used. Scaling your database must be a simple operation—you should not need to deal with complicated procedures or make any changes to the application. In this white paper, we only speak about horizontal scalability, which involves dividing a system into small structural components hosted on different physical machines (or groups of machines) and/or increasing the number of servers that perform the same function in parallel. a Cassandra meets the requirements of an ideal horizontally scalable system. Nodes can be added seamlessly as you need more capacity. The cluster automatically utilizes new resources. A node can be decommissioned in the automatic or semi-automatic mode. b MongoDB has a number of functions related to scalability. They include: automatic sharding (auto-partitioning of data across servers), reads and writes distributed over shards, and eventually-consistent reads that can be distributed over replicated servers. When the system is idle, cluster size can only be decreased manually. The administrator uses the management console to change the system’s configuration. After that, the server process of MongoDB can be safely stopped on the idle machines. c Couchbase scales horizontally. All nodes are identical and easy to setup. Nodes can be added or removed from the cluster with a single button click and no changes to the application. Auto-sharding evenly distributes data across all nodes in the cluster without any hotspots. Cross-datacenter replication makes it possible to scale a cluster across datacenters for better data locality and faster data access. Performance: Interactive applications require very low read and write latencies. The database must deliver consistently low latencies regardless of load or the size of data. In general, the read and write latency of NoSQL databases is very low because data is shared across all nodes in a cluster while the application’s working set is in memory. ©Altoros Systems 4
- 5. Further Actions Please go to this link for downloading the full research for free. Also, browse through other Altoros’s researches published by CIO.com, NetworkWorld, ComputerWorld, TechWorld, and other online magazines.