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:
