NoSQL Software Configuration & Deployment

The driving force behind the development of NoSQL databases is the need to rapidly store and manage ever larger, dynamically changing Big Data information sets.

Configuring Cassandra NoSQL column store

  • Cassandra workloads can rapidly become CPU-bound, and as such, we recommend systems with as many CPU cores as possible.
  • On RHEL and CentOS, system limits should be changed from 1024 to 10240 in /etc/security/limits.d/90-nproc.conf like so: soft nproc 10240
  • Tune the JVM Heap size on each node of the cluster, depending on the amount of memory on that specific node. Too big a Heap size can impair Cassandra’s efficiency.
  • Cassandra through the JVM only makes use of 8GB RAM. For best read performance, allow for enough nodes to host the dataset in RAM, at about 8GB per server.
  • Fast I/O storage, such as RAID or SSDs, becomes crucial for out of memory read-dominant workloads. Reads tap secondary storage far more than writes.

Configuring MongoDB NoSQL document store

  • MongoDB uses a scale-out architecture based on “sharding”. Each instance stores its data on disk, while also maintaining a memory-mapped cache in RAM.
  • MongoDB can serve “web-scale” request rates, at millions of end-user requests per second, while providing sub-second responses—requires that servers have sufficient RAM to hold the “working set” from which most requests can be served.
  • The storage must then perform fast enough to accommodate the rate at which the working set changes, occasional requests beyond the working set, and rates of write and update traffic.
  • On NUMA hardware, run MongoDB with an interleave policy. Start the sharding servers like so:  numactl--interleave=all ./mongod … Failure to disable NUMA will result in sporadic slowdowns.

Download our informative poster, below:

For more complete information about compiler optimizations, see our Optimization Notice.