MongoDB vs. Clustrix: Fault Tolerance and Availability
sergeitsar.blogspot.com
MongoDB vs. Clustrix: Fault Tolerance and Availability
1–10 of 25 posts
Re: MongoDB vs. Clustrix: Fault Tolerance and Availability
#2These posts are written by one of the Clustrix founders.
Re: MongoDB vs. Clustrix: Fault Tolerance and Availability
#3These posts are written by one of the Clustrix founders.
Are you trying to imply that the post has wrong information because of this fact? If so, attack the wrong data. I don't care who posts facts, as long as they really are facts.
Re: MongoDB vs. Clustrix: Fault Tolerance and Availability
#4These posts are written by one of the Clustrix founders.
Are you trying to imply that the post has wrong information because of this fact? If so, attack the wrong data. I don't care who posts facts, as long as they really are facts.
I haven't read their analysis yet (I will try to when I have some free time), but in general, I would argue that trying to compare a document database to a SQL one is always going to be somewhat misleading. I'd care more if they were comparing Clustrix to MSSQL, MySQL, PostgreSQL.
If you are using MongoDB in a way that is similar to the way you would have used a SQL DB you are probably doing something wrong. Specifically, you are trying to place normalized data in a database designed for denormalization.
Re: MongoDB vs. Clustrix: Fault Tolerance and Availability
#5Earlier quoted context omitted.
Are you trying to imply that the post has wrong information because of this fact? If so, attack the wrong data. I don't care who posts facts, as long as they really are facts.
I haven't read their analysis yet (I will try to when I have some free time), but in general, I would argue that trying to compare a document database to a SQL one is always going to be somewhat misleading. I'd care more if they were comparing Clustrix to MSSQL, MySQL, PostgreSQL. If you are using MongoDB in a way that is similar to the way you would have used a SQL DB you are probably doing something wrong. Specific…
Sergei compares Clustrix to MongoDB because their target markets are very similar--not because the technology is similar.
As a startup, it behooves them to attack the low-end database market, but I suspect they've found that the primary market for a highly scalable low-end database lies on the web, but that market has chosen to go cheap-and-dirty with NoSQL. So now they're in the middle ground between fast-and-and-loose-and-free and my-enterprise-uses-Oracle.
I think a lot of web development is of a highly speculative, winner-take-all sort, so devs. want to be as cheap as possible until they win the web lottery. For all the flaws of NoSQL, software only solutions do allow developers to make very efficient use of their hardware by running multiple services on the same machine, or run them in the cloud. Once they hit the jackpot, they can afford to either go Oracle, hire software developers to work around deficiencies in their data store (e.g. Facebook), or use a data store from Amazon or Google or Microsoft.
That's a shame, because I think Clustrix is ultimately the right approach. The web has a history of doing the shittiest-and-easiest thing first (ColdFusion, anyone?) only to repent years later to the second-shittiest solution. Rinse, repeat.
Re: MongoDB vs. Clustrix: Fault Tolerance and Availability
#6Earlier quoted context omitted.
Are you trying to imply that the post has wrong information because of this fact? If so, attack the wrong data. I don't care who posts facts, as long as they really are facts.
I haven't read their analysis yet (I will try to when I have some free time), but in general, I would argue that trying to compare a document database to a SQL one is always going to be somewhat misleading. I'd care more if they were comparing Clustrix to MSSQL, MySQL, PostgreSQL. If you are using MongoDB in a way that is similar to the way you would have used a SQL DB you are probably doing something wrong. Specific…
The article is not about the DBMS interface. It's about Fault Tolerance (what happens when stuff breaks) and Availability (can I still use my database when there is a fault).
MongoDB claims to support both. So does Clustrix. I'm comparing both claims.
Re: MongoDB vs. Clustrix: Fault Tolerance and Availability
#7Earlier quoted context omitted.
I haven't read their analysis yet (I will try to when I have some free time), but in general, I would argue that trying to compare a document database to a SQL one is always going to be somewhat misleading. I'd care more if they were comparing Clustrix to MSSQL, MySQL, PostgreSQL. If you are using MongoDB in a way that is similar to the way you would have used a SQL DB you are probably doing something wrong. Specific…
Sergei compares Clustrix to MongoDB because their target markets are very similar--not because the technology is similar. As a startup, it behooves them to attack the low-end database market, but I suspect they've found that the primary market for a highly scalable low-end database lies on the web, but that market has chosen to go cheap-and-dirty with NoSQL. So now they're in the middle ground between fast-and-and-lo…
Fair enough, I'll definitely take the time to read the article. Though I'm not sure it's a fair analogy to compare Mongo to ColdFusion in terms of doing the wrong thing first.
Re: MongoDB vs. Clustrix: Fault Tolerance and Availability
#8Earlier quoted context omitted.
Are you trying to imply that the post has wrong information because of this fact? If so, attack the wrong data. I don't care who posts facts, as long as they really are facts.
I haven't read their analysis yet (I will try to when I have some free time), but in general, I would argue that trying to compare a document database to a SQL one is always going to be somewhat misleading. I'd care more if they were comparing Clustrix to MSSQL, MySQL, PostgreSQL. If you are using MongoDB in a way that is similar to the way you would have used a SQL DB you are probably doing something wrong. Specific…
Please do not comment without reading the article. You do not even have the word SQL in it. Sergei is addressing the different approaches to achieve Consistency/Availability and Performance between their solution and MongoDB. A good read and I must say, I would really love to have more details and more general overview of their algorithms. They could be used for other problems.
Note that I am a huge fan of MongoDB and using it in production since the 1.4 something release.
Re: MongoDB vs. Clustrix: Fault Tolerance and Availability
#9Earlier quoted context omitted.
Are you trying to imply that the post has wrong information because of this fact? If so, attack the wrong data. I don't care who posts facts, as long as they really are facts.
I haven't read their analysis yet (I will try to when I have some free time), but in general, I would argue that trying to compare a document database to a SQL one is always going to be somewhat misleading. I'd care more if they were comparing Clustrix to MSSQL, MySQL, PostgreSQL. If you are using MongoDB in a way that is similar to the way you would have used a SQL DB you are probably doing something wrong. Specific…
Most databases that I've worked with that need to stand up to any real load do end up getting fairly denormalized. So a database might contain multiple data silos.
A job is a job and data is data. Attacking the interface doesn't seem entirely fair. SQL is used with a good number of non-RDBMS. Should it really matter if my interface is a QBE JSON document, a JavaScript function, or a SQL procedure? That seems like one of the least important concerns.
Re: MongoDB vs. Clustrix: Fault Tolerance and Availability
#10These posts are written by one of the Clustrix founders.
Are you trying to imply that the post has wrong information because of this fact? If so, attack the wrong data. I don't care who posts facts, as long as they really are facts.
His last article was intensely ignorant of MongoDB. I appreciate his attempt to promote his product, but the last one showed that he'd spent about 10 minutes on the Wiki and that's it. Or perhaps he's more informed and conveniently left out a number of things that would have made MongoDB look better. I don't want to cast aspersions, but it wasn't a good argument.
This one does seem to be more informed (and I agree with a lot his criticism of MongoDB here), but it's almost like comparing apples to oranges. Things are done in MongoDB a certain way for a number of reasons (e.g., the query interface doesn't allow certain things in a distributed context that you could probably do with a SQL database). But I think anyone who's done large-scale MongoDB deployments can (or at least should) attest that it works well, but perhaps not as well as other solutions (or as well as it could/will work eventually/whatever).