JavaScript ubiquity [LWN.net]

JavaScript ubiquity

Posted Oct 22, 2012 7:52 UTC (Mon) by man_ls (guest, #15091)
In reply to: JavaScript ubiquity by cmccabe
Parent article: Wayland and Weston 0.99.0 snapshots released

Somehow I don't think so: node.js is already orders of magnitude faster than other traditional servers. Also, I don't see all Python people throwing away their twisted servers, or Ruby throwing away Rails; and node.js is much more convenient than those two.

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.) Amazon rents cheap two-core servers, very convenient to run node.js on. In fact node.js uses two cores: one for receiving requests and another for servicing them.

There are a couple of ways around a single-process server on a multi-core machine. One is to run many stateless node.js processes on a server. Another is to modify the V8 engine to run many threads in the same process and synchronize them; it is a more definitive solution, even though the engineering costs may be high. I don't doubt that Google can make it if they try.

JavaScript ubiquity

Posted Oct 25, 2012 9:34 UTC (Thu) by cmccabe (guest, #60281) [Link] (2 responses)

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.

JavaScript ubiquity

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

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.