The book mentions, "where Cassandra fits in". This is a question that I constantly get when talking about Cassandra. Many people want to know, "why not [NoSQL database of your choice]?". The short answer is: if you want fast writes, multi-data center support baked into your system, a truly scalable system with tons of metric, then you should consider Cassandra. However, I always follow my answer by saying that the best way to know if Cassandra fits into the role, is to understand it. When I started using it, I had to stop myself thinking about all that I know about data modeling with RDBMS. Most of the stuff that we learned in RDBMS is actually an anti-pattern for Cassandra - normalization, build your model first, index with high-cardinality, leverage joints. Don't think of a relational table, think of a nested, sorted map data structure.
Tunable Consistency and Polyglot Databases
Many people don't understand that you can tune the consistency of Cassandra. The followings are the configuration that you can have for reads and writes:- ANY: is for writes only and ensures that the write will persists on any server in the cluster.
- ONE: ensures that at lease one server within the replicate set with persist the write or respond to the read
- QUORUM: means the read/write will go to the half of the nodes in the replica set plus one.
- LOCAL_QUORUM: it's just like "quorum" except that it is only for the nodes in that data center.
- EACH_QUORUM: is like "quorum" but ensures a quorum read/write on each of the data centers.
- ALL: ensures that all nodes in a replica set will receive the read/write.
One of the things Cassandra does not do, is joins or ad-hoc queries. This is a something that Cassandra simply doesn't do and other tools do it better (Solr, ElasticSearch, etc). This is what people are calling to Polyglot Data.
Gossip vs Snitch
Practical Cassandra helped me understand the difference between the "gossip" and "snitch" protocol. This is something that I struggled time and time again. Gossip is the protocol that Cassandra uses to discover information about the new nodes. When bringing a new node into the cluster, you must specify a "seed node". The seed nodes are a set of nodes that are used to given information about the cluster to newly joining nodes. As you can imagine, the seed nodes should be stable and should point to other seed nodes.The snitch protocol helps map IPs to racks and data centers. It creates a topology by grouping nodes together to help determine where data is read from. There are few types of snitches: simple, dynamic, rack interfering, EC2, and Ec2MultiRegion.
- Simple snitch is recommended for a simple cluster (one datacenter as one zone in a cloud architecture).
- Dynamic snitch wraps over the SimpleSnitch and provides an additional adaptive layer for determining the best possible read location.
- RackInferringSnitch works by assuming it knows the topology of your network, by the ocftets in node's IP address.
- EC2Snith snitch EC2 Snitch is for Amazon Web Service (AWS)-based deployments where the cluster sits within a single region.
- EC2MultiRegionSnitch is for AWS deployments where the Cassandra cluster spans multiple regions.
Node Layout
Prior to Cassandra 1.2, one token was assigned to each node. Whenever you had a node that would have a lot of load of data, that would be consider a "hot spot". Most of the times, you will just add another node to leverage the "hot spot", but then you had the "rebalance" the cluster. Virtual nodes or vnodes, provide a Cassandra node with the ability to be responsible for many token ranges. Within a cluster, they can be noncontiguous and selected at random. This provide a greater distribution of data than the non-vnode paradigm.Performance
The performance chapter was also another very interesting chapter. Being a developer it introduced me to common *nix tools like vmstat, iostat, dstst, htop, atop, and top. All of these tools provide a picture of usage. It also explained how instrumentations goes a long way. Also, if one node becomes too slow to respond, the FailureDector will remove it.An easy optimization for Cassandra is putting your CommitLog directory on a separate drive from your data directories. CommitLog segments are written to every time a MemTable is flushed to disk. You can do this setting in the cassandra.yml by setting the data_directory and commitlog_directory.
Metrics
Cassandra goes out of her ways to provide lots of metrics. With all these metrics you can do capacity planning. Once you start getting all these metrics, you'll be able to differentiate trends and be able to proactively add or remove nodes. For example, you can monitor the PendingTask under the CompactionManagerMBean to know the speed and volume with which you can ingest data, you will need to find a comfortable set of threshold for your system. Another example is to monitor the high request latency, which can indicate that there is a bad disk or that your current read pattern is starting to slow down.These are some of the metrics that you can get via JMX:
- DB: monitors the data storage of Cassandra. You can monitor the cache and the CommitLogs, or even information about the ColumnFamily.
- Internal: these cover the state and statistics around the staged architecture (gossip information and hinted handoffs).
- Metrics: these are client request metrics (timeouts and "unavailable" errors).
- Net: these metrics monitored the network (failure detector, gossiper, messaging service, and streaming service).
- Request: these are metrics about request from the client (read, write, and replication).
There are still a lot of stuff that I need to learn about Cassandra. Specially about the data model. It's very tricky to start thinking about your queries (pre-optimized queries like Nate McCall calls them). In all, the book does covers the basics .
No comments:
Post a Comment