Recently I had a chance to work on the Cassandra. To explain the need in short, it was required to have a distributed key-value store. While Redis is great but it doesn’t let you have multiple geographically distributed writable servers but Cassandra does. Writing here few points about Cassandra and so that one can keep them in the back of the head while setting it up.
- Contrary to what I said, Cassandra is not exactly key-value storage. It is more of a JSON format storage which can behave like key-value pair.
- CQL – Cassandra Query Language distracts the user from the true nature of Cassandra. It makes one believe that Cassandra is like RDBMS while its not. One must think of it as key-value, where values can be extended further.
- Data structures provided by Redis can be implemented easily.
- Throughput are depended on configuration of machine. More the number of CPU, better the throughput can be. Go through other configurations as well, best practices are explained in configuration file.
- Data is first written in memory(memtables) and on disc(sstables) during compaction, which depends on the settings. By default it is set to 10 days or Java heap size in memory whichever is reached first.
- Lesser the tombstones, faster will be the compaction. This way, probability of reading sstables, which is disk read, go low.
- Updates are waste of resource use insert instead, it will overwrite the existing row/document on compaction.
- To keep the read fast use quorum as 1, that is whatever you are getting on selection is the truth.
- Partitioning key should be designed as such to keep the data related to it on a single node. IMO partitioning key is analogous to tables in RDBMS. This way for a particular key and quorum equals to 1 will always be truth. See composite partitioning keys.
- Latency is a thing to worry about. Try to keep reads as low as possible.
- Schema structure is very important. It is important to learn about the queries one needs to make on the table before writing schema. Unlike RDBMS, condition has to be on successive columns instead of random columns.
- If using PHP, use Java-client with php-java bridge instead of native PDO driver. It provides almost 3x read/write throughput per node.
- IRC is good place to get help in case of issues.
- If nodes are EC2 instances, snitch configured for EC2 is available for used.
- Version 2.0.9 is not compatible with 2.1.x in a cluster.
- In general, version below x.x.5 are not production ready and have serious bugs. Current 2.1.1 is not suitable for production environment.
I Wonder 