Is performance still a problem for MongoDB?
Avalon benchmarked Couchbase Server and MongoDB last year, and a lot has changed since then. Couchbase Server 4.0 introduced a SQL-based query language, N1QL. Couchbase Server 4.1 added prepared statements and covering indexes, and the query performance improved.
Couchbase Server 4.5 added memory-optimized indexes, array indexing, and index joins as well as improvements to storage (circular writes) and consistency (read-your-own-writes). Couchbase Server has a more powerful query engine, but with these improvements, does it have the fastest?
This time, Avalon benchmarked both read/write performance and query performance.
The read/write results should come as no surprise.
Couchbase Server has 6x higher read/write throughput than MongoDB? How? Why?
It boils down to architecture, resource utilization, and efficiency.
When it comes to write performance, MongoDB suffers from a legacy master/slave architecture. With a primary and a secondary node running on every server, and with writes limited to primary nodes, only half of the server resources can be utilized for writes.
When it comes to read performance, Couchbase Server benefits from a memory-centric architecture. While it writes all data to disk, it maintains as many documents as possible in a managed object cache – far more efficient than caching blocks of file data.
The query results may be surprising.
Couchbase Server has 3x higher query throughput than MongoDB? How? Why?
Like I said, it boils down to architecture, resource utilization, and efficiency.
MongoDB executes every query on every node because it relies on local indexes – every node contains just a piece of the index. As a result, query performance is limited to that of a single node. For example, if a single node can execute 7,500 queries per second, adding more nodes does not help – every node still has to execute the same 7,500 queries per second.
Couchbase Server benefits from global, memory-optimized indexes as well as independent services for reading and writing data, indexing it, and querying it.
When it comes to scan latency, Couchbase Server can leverage Global Secondary Indexes (GSI), where the index service maintains a complete index (not a piece of it). This enables the query service to identify the documents to return with a single index scan, limiting fetch requests to only those nodes that contain one or more of the documents to return. With memory-optimized storage, the whole index is not only stored in memory, it’s stored in a lock-free skip list – far more efficient than a B-tree, a data structure optimized for disk.
When it comes to insert latency, Couchbase Server benefits from isolation. The index and data services, whether they’re running on different nodes or not, are isolated with indexes being updated asynchronously. As a result, while MongoDB insert latency was severely impacted by queries, Couchbase Server insert latency was not.
You can find all of the details in the complete report.
if (users > 100) return “Couchbase Server”; else return “MongoDB”;
