Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MongoDB vs. Clustrix Benchmark

sergeitsar.blogspot.com

Post reply on HN
Print view View original

61–67 of 67 posts

Re: MongoDB vs. Clustrix Benchmark

#61

Post by cwcr7 »

weavejester wrote: post #56
PaulHoule wrote: post #28

Earlier quoted context omitted.

Well, there are quite a few commercial database vendors that offer parallel and clustered RDBMS products, and many of them appear to be quite good. Unfortunately, they've got a terrible marketing problem. Before 1998 or so, a relational database was an expensive product that you got from a vendor like Oracle. Since then, a generation of people have grown up that think about using a commercial RDBMS the same way most…

If I want to trial Oracle or Clustrix, well, I'm going to have to start a contact with a sales organization and then they need to pre-qualify me, and then they need to qualify me and then I'll spend a few hours on the phone talking to people (which might take a few weeks in wall-clock time.) If Clustrix offered cloud-based deployment of their database, they could have a small free tier for people to play around with.…

Presumably at some point they will offer a cloud-based service. It particularly makes sense given the fundamental design of their product.

Since they only launched their product quite recently, it is understandable that they would want to test it with several customers before offering it as a service.

In fact, if the product scales well enough, it would be perfect for deploying as a cloud-based service and could be very successful as such.

Re: MongoDB vs. Clustrix Benchmark

#62

Post by fedd »

mjw0 wrote: post #58
fedd wrote: post #30

> Interestingly enough, we never heard that SQL or the relational model was the root of all their problems. i really think that sometimes SQL and the relational model is a problem. at least, the relational database design is a course in a university, along with (object oriented) programming. so, to properly use postgre or mysql in your sophomore web startup, you should know two things well, or have a clever db guy...…

So relational data is hard but implementing appropriate consistency checks in your application is easy? Or do you just skip that second part and hope for the best?

imho, the second, except that some consistency is present ib document dbs: like in the order example, all order items will be within the document and wont be lost without losing the whole order.

no-one would ever use 'eventually consistent' databases for financial or trading data, i think. they're for higly scalable consumer web projects

Re: MongoDB vs. Clustrix Benchmark

#63

Post by jhugg »

strlen wrote: post #60
jhugg wrote: post #57

Earlier quoted context omitted.

I like the content of this post, but I take issue with the idea that the debate only matters in a failure condition. That's academically true, but practically misleading. When developing my app, I have to assume any part of the system could fail at any time. Thus my whole app needs to be written with failure in mind. In an ACID system, that means my transactions either happen or don't, and it's on me to figure out wh…

> This is why Cassandra is now offering counters as an API feature This is specific to Cassandra, where the development team chose not to implement optimistic locking via version vectors. That said the counters patch essentially implements a vector of counters, very similar conceptually to a vector clock. That said, there are some scenarios where quorums (in absence of an agreed upon view of the cluster e.g., a zooke…

Overall, another solid comment.

As for RPC, whether the client is informed of success or failure has nothing to do with atomicity. The guarantee is that the transaction either happens completely or not at all, and nothing more.

Agreed, it can be very frustrating that under certain failure scenarios, it's unclear whether the transaction completed or rolled back. Still, given atomicity, a correctly designed system can't be left in an inconsistent state. At times, it's up to the application to discover (or re-discover) that state.

Systems that offer atomicity for single record operations can actually make the same assurances, but may require complicated escrow systems and compensating transactions.

Re: MongoDB vs. Clustrix Benchmark

#64

Post by pmikesell »

strlen wrote: post #46

Pet peeve: eventual consistency isn't for scalability and performance, it's for availability. In a well designed system, the whole debate only matters during in a failure condition: a strongly consistent system gives up availability upon a certain kind of failure, an eventually consistent system gives up consistency upon a certain kind of failure. There are strongly consistent scalable "NoSQL" systems e.g., BigTable.…

He did go into more on the on fault-tolerance and availability of Clustrix in another post:

http://sergeitsar.blogspot.com/2011/02/mongodb-vs-clustrix-c...

(nb - I also work at Clustrix)

Re: MongoDB vs. Clustrix Benchmark

#65

Post by weavejester »

cwcr7 wrote: post #61
weavejester wrote: post #56

Earlier quoted context omitted.

If I want to trial Oracle or Clustrix, well, I'm going to have to start a contact with a sales organization and then they need to pre-qualify me, and then they need to qualify me and then I'll spend a few hours on the phone talking to people (which might take a few weeks in wall-clock time.) If Clustrix offered cloud-based deployment of their database, they could have a small free tier for people to play around with.…

Presumably at some point they will offer a cloud-based service. It particularly makes sense given the fundamental design of their product. Since they only launched their product quite recently, it is understandable that they would want to test it with several customers before offering it as a service. In fact, if the product scales well enough, it would be perfect for deploying as a cloud-based service and could be v…

Ah, I didn't realise their product was only recently released.

Re: MongoDB vs. Clustrix Benchmark

#66

Post by lindvall »

PaulHoule wrote: post #28
va_coder wrote: post #23

First off, how do you download Clustrix? With MongoDB, simple as pie: http://www.mongodb.org/downloads Now, where are the docs? Again, Mongo has great docs http://wiki.mongodb.org/display/DOCS/Home How can I verify your claims? Oh that's right, you call a salesperson first....

Well, there are quite a few commercial database vendors that offer parallel and clustered RDBMS products, and many of them appear to be quite good. Unfortunately, they've got a terrible marketing problem. Before 1998 or so, a relational database was an expensive product that you got from a vendor like Oracle. Since then, a generation of people have grown up that think about using a commercial RDBMS the same way most…

Small nit: You can download Oracle 11g (or 10g) strait off their website for free — you just need to sign up for a free developer account.

Here's a link: http://www.oracle.com/technetwork/database/enterprise-editio...

Re: MongoDB vs. Clustrix Benchmark

#67

Post by jdr20000 »

moe wrote: post #19
mayank wrote: post #11

Earlier quoted context omitted.

Would you care to elaborate? Seriously, do you have any pointers or benchmarks for a Mongo vs Cassandra vs X comparison that isn't purely anecdotal, and which takes the relative strengths of each into account in a robust way? A lot of blog posts with performance numbers seem anecdotal or loaded towards one option over the other. I'm excited by some of the underlying technology in Mongo and its ilk (gossiping protocol…

Well, don't trust a benchmark that you haven't faked yourself they say. I was just trying to point out that MongoDB is too easy a target here. The problems it has under high load are fairly well-known, at least to anyone who tried to benchmark it outside of their MacBooks. Just bulk-load a couple million records and watch it tip over if you don't believe me - I'm not making it up and neither is Sergei. However if Clu…

I am a Mongo fan in some respects, but I agree that every benchmarking I do with any significant data involves the painfully slow bulk writes to get it started -- not a good first impression. Can some Mongo people help explain this?
Post reply on HN