During the evaluation over the last month both the DataStax 5.1 and Mongo 3.6 database platforms were evaluated and compared on various different aspects. Some of the key criteria used for the evaluation include: overall performance and throughput, operational overhead, data-modeling and application time to market, uptime and scalability, operational support, BI support, price and overall database functionality. In the end, MongoDB Atlas platform scored better or largely better than DataStax.
Performance, throughput and ad-hoc querying: Both databases were able to exceed the minimum read/write/updates per second, each performing better in different criteria. For direct inserts (tested with 3M and 30M inserts), MongoDB was found to be 21% faster. For primary key reads DataStax was 41% faster, but for non-primary (ad-hoc) queries it suffered due to its lack of secondary indexing support and Mongo was 156% faster. Ad-hoc queries are not directly supported in DataStax and need to be off-loaded to Spark/Solr search engines.
Operational overhead: MongoDB offers it’s Atlas Cloud DataBase as a Service package which has been extremely attractive. Atlas runs in a MongoDB managed GCP instance and handles routine DBA maintenance and support. Failover testing was done in Atlas and minimal impacts were observed. Failover testing has not yet been done with DataStax.
Data modeling and application time to market: This is one of the big winners for MongoDB, ease of use of application data-modeling. While NoSQL databases require a “shift in thinking” of how to model data, the Cassandra/DataStax model is quite complex and easy to get wrong and hard to fix/adjust as the access patterns evolve. The MongoDB data-model truly represents the application state with application object data being persisted back to the database with the data-model naturally transitioning as the application itself transitions.
Uptime, scalability and BI: Cassandra/DataStax has a reported 100% uptime while MongoDB has high-availability uptime. Scalability is supported in both, in DataStax it’s the use of “data-centers”, in Mongo it’s sharding. Both databases support “read-only” replica sets/”data-centers”. Both support Business Intelligence. DataStax does not support simple, native ad-hoc querying without additional data-modeling and pre-prepared support tables.
Database functionality: When it comes to application development database functionality, MongoDB is a full scale, near general purpose database with support for aggregate functions (group by, sum, etc), reg-ex search, aggregation pipelines, single table in database joins (both support driver level joins). Many of these features are not supported well in DataStax without additional server-side data-modeling. Neither database fully 100% supports transactions. In DataStax there can be “consistency issues” with transactions, with Mongo it can be achieved requires certain data-models and/or “two-phase commits” in certain use cases. MongoDB will have native transactional support in version 4.0 which is scheduled to be released this fall. DataStax released their 6.0 version just when we completed our evaluation. So, we haven’t looked closely into what it would offer.
Analytics and BI: Both MongoDB and DataStax offer read-only replica sets/”data-centers”. Both offer wide ranges of Business Intelligence and Analytics tool, adapters and interfaces.
Security: Both databases support encryption at rest and SSL/TLS for in-flight data.
Cost: We will be approaching both vendors for pricing based on the sizing we can estimate for the main areas – Cart/Checkout, OMS, Profile, Florist Member, Product, Availability and Single Pool of Inventory Services. Probably IDGenerator Service as well – TBD.