Hacker News new | ask | show | jobs
by jd_mongodb 1858 days ago
AH I see. When we talk about nodes in MongoDB they are the elements of a replica set. That is what confused me. Yes, you are right, to get the equivalent performance of a two node database server you would have to run a sharded cluster with two shards. That is definitely more nodes than the two node design you have outlined for the RAC like design.

I am not familiar with Oracle RAC architecture but casual mention of a SAN fails to recognise the cost and complexity of even the smallest SAN. On the other hand MongoDB can run on dumb disks without a SAN or RAID required (though RAID can help with performance).

With you two node system loss of a node results in a 50% loss in performance whereas with MongoDB loss of a node will result in a secondary taking over the primary role with no loss in performance. You get what you pay for.

Setting up such clusters used to be a PITA until the advent of MongoDB Atlas. Now you can set them up with a few mouse clicks.

As regards shard keys. Yes, they are immutable, but the documents they index are not. So dynamic schema properties are preserved in a sharded cluster.
1 comments
sepin4 1857 days ago
While a SAN/NAS is overall an expensive hardware in both price and manageability, there are entry level devices. You can even get direct SCSI devices in some cloud services(Azure has "shared disks"). For Oracle RAC the data is accessed from same location, it's not distributed/replicated across nodes. It's literally the same disks attached to all nodes. Also ASM works with raw block devices which bypasses the need for file system abstraction and all the latency that comes with it. You could also deploy a cluster on a cluster/network file system, but this would generally not be a good idea since you get a lot of overhead.

Postgre clusters can be configured in similar fashion.

I'm not saying that Mongo doesn't have it's strengths. However using the full potential of your environment requires much more planing and has a lot more pitfalls.

I was particularly discussing the implications on what the relative immutability of the shard key has on the data distribution and that it is not that easy to change.

link