User: Password:
Subscribe / Log in / New account

JavaScript ubiquity

JavaScript ubiquity

Posted Oct 25, 2012 9:34 UTC (Thu) by cmccabe (guest, #60281)
In reply to: JavaScript ubiquity by man_ls
Parent article: Wayland and Weston 0.99.0 snapshots released

My argument is not about whether node.js is faster or slower than anything today, but about whether it will be useful in a multi-core future.

Personally I find the claims of "orders of magnitude faster than other traditional servers" pretty hard to swallow, but such claims are also "traditional" in their own way, so who am I to complain? :)

> For some applications a single-process server may not
> be right, but for the rest convenience usually trumps
> performance. (Witness MongoDB beating Riak or Cassandra.)

It doesn't really make sense to compare Cassandra to MongoDB and Riak, since traditionally Cassandra is used with a much weaker consistency model.

(Log in to post comments)

JavaScript ubiquity

Posted Oct 25, 2012 9:38 UTC (Thu) by man_ls (guest, #15091) [Link]

I don't understand the bit about "weaker consistency model". I am using MongoDB with a very weak consistency model: data is denormalized (there are several copies of each piece of data, in different collections) and I have to ensure consistency in my application code. Why is it different with Cassandra or Riak?

JavaScript ubiquity

Posted Oct 30, 2012 15:55 UTC (Tue) by cmccabe (guest, #60281) [Link]

MongoDB has a master server at each point in time for any given shard. And when you update a key in that shard, you always update the master. In contrast, Riak doesn't force you to funnel all writes to a key through a particular server. Because of this, clients are forced to reconcile the divergent versions of a key that may occur when they do reads. Cassandra is similar.

Note to nitpickers: a lot of these datastores can be configured to run in different consistency modes. For example Riak has last_write_wins, and Cassandra has the ability to do quorum writes, etc. In general, though, if you find yourself obsessing over these settings, you might just be using the wrong datastore for the job. They have different design goals.

To come back to your particular situation, denormalizing the data that you store in MongoDB is a choice that you have made. You could do the same thing with SQL, or any other strongly consistent data store.

On the other hand, you could say that the limtiations MongoDB forced you to go down this path, since it doesn't support SQL-style transactions, foreign keys, and so forth. That's a fair point.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds