MongoDB vs. Clustrix: Fault Tolerance and Availability

> Sergei compares Clustrix to MongoDB because their target markets are very similar

Looking at a coarse, "they want money from people" granularity, the target market (people who need a database) may be similar. If we look closer, however, the target market has, more or less, two segments:

One is at the product-for-free pricepoint, where you make your money either by selling additional services (e.g. 10gen with MongoDB, Basho with Riak, MontyProgram with MariaDB and MySQL) or upselling them to an enterprise version (e.g. IBM's DB2 Express-C, whose 2GB limitation makes it perfect to hook people on a workload they would use MySQL for, Franz' AllegroStore, OpenLink's Virtuoso open source edition).

The try-our-product-for-free method means that all the cheap-and-dirty-folks have something in their grubby fingers to build the next blog, mom-and-pop online store, or whatever. The folks with actual money to spend can lower their initial risk by trying out a couple of different databases to see which one fits best, without even having to ask. Only when they're actually happy with what they've got they're going to fork over the cash.

The next tier is the "we'll have to qualify you before we send our sales engineer" tier where you play with Oracle and IBM, or Greenplum and Vertica, because your prospective customers already know that your product is good enough.

There's no real space in-between. Either you have an engineer with good knowledge but no discretionary budget (whose chooses something appropriate for the task, after testing on a real workload, and makes the DB a non-topic for everyone else), in which case a comparison that people cannot replicate is not going to help you, or you have a high-level decision taker with budget power but no time to try things out or risk a couple thousand on a startup that may have gone bancrupt when he most cares about it. This latter category will be thoroughly unimpressed by any benchmark that is not the TPC-C or similar. No lottery whatsoever involved, these are the rules of enterprise spending.

BTW, calling ColdFusion and PHP (which were a far superior alternative to writing Perl CGI scripts without templating or any kind of library support) shitty and Clustrix "the right approach" is something for which people in 2024 will just laugh at you, even if Clustrix manages to do extremely well end ends up as the second-shittiest solution to a common problem.

I'd like to correct some factual errors from this article.

1) Failover of a MongoDB Replica Set is totally automated and requires no manual intervention. The replica set remains available for writes as long as a quorum can be established between remaining members. See http://www.mongodb.org/display/DOCS/Replica+Sets for more info

2) MongoDB does support different consistency models through Write Concerns and Safe Mode. The client can choose to wait for the transaction to be written to multiple replicas if it wants. See http://www.mongodb.org/display/DOCS/Verifying+Propagation+of... for more info

Disclaimer: I work for 10gen

In the discussion of the previous article posted a couple of days ago, a lot of people complained that he initially didn't provide source code of the tests or go into details about the Mongo's configuration. Some felt that as someone who's worked with internals of RDBMS's, it wouldn't be fair to compare something he knows intimately with something he just learned and didn't spend any time optimizing.

After he posted the code, others complained that the scenarios didn't have enough multi-table joins (which Mongo would represent as nested objects and, at least in the commenters' opinions, would probably do better than it did). There was also a lot of more detailed technical discussions but I won't try to summarize them:

http://news.ycombinator.com/item?id=2161753

(Note: these opinions aren't my own, just what I got out of the discussion.)

1. You really need a minimum of three replica set nodes, one of which can be a lightweight arbiter. If the primary fails, the secondary node will be promoted to primary automatically. In the case of a network partition, the old primary will come back up as a secondary with no problems. In the case of a true hardware failure, you can resync very quickly from a snapshot. For extra peace of mind, add more nodes to the replica set. You can have up to seven.

2. If you're reading from both primary and secondary nodes, then the view may not be consistent. In most cases you simply read from the primary for fully-consistent reads. You get to decide whether reads from secondaries are consistent or not by setting the write concern (i.e., the minimum number of nodes to replicate to before returning each write.)