Cassandra 最佳实践系列(2) - 选型篇，
本文会从cassandra的选型，机器基本配置，节点数，基本使用介绍方面进行基本的介绍；
机器基本配置选择
Cassandra的性能使用可以随着机器的硬件配置，以及集群的节点数的横向和纵向的升级而相应的有所提升。
CPU
Cassandra内部会有很多地方使用多线程进行处理，一般配置里面对于读写而言，写操作是CPU bound，所以如果系统的写操作会相对多一点，对cpu的要求也会相对配置要好一点，一般至少是2c起步，如果是生产环境对写要求更高，相对的cpu核数应该更好。
内存
Cassandra使用java 语言编写，会用到jvm-on heap内存以及offheap内存，其中jvm预先想操作系统申请的内存大小是系统大小的1/2, 其中off-heap会使用于压缩元数据，bloom filter等等。官方建议生产环境内存不低于8G，但是具体可以视自己的需求再说，对于gc算法来说：
- 堆内存小于12G，推荐cms算法；
- 大于12G堆内存的话，可以使用G1 算法；
磁盘
对于cassandra而言有几个地方需要使用到磁盘，commitlog、hint、cache-file、sstable-file。其中对我们来说，我们需要重点关注commitlog的文件以及sstable的文件，因为写操作会先写commitlog，然后把数据丢到memtable，然后memtable会异步的dump到磁盘成为sstable的文件，而且sstable后台会进行异步的compaction操作合并成新文件。那么这里commitlog的会影响我们的写性能，常见的建议是commitlog的配置
磁盘与放置sstable的data 目录分开配置，commitlog单独配置一块盘，因为写commitlog的速度直接影响写操作的速度，所以建议commitlog的配置磁盘需要稍微好一点，但是容量不需要很大，因为commitlog的数据在相关memtable数据dump到磁盘以后就会删除。只有存留在memtable的数据在commitlog里面以做节点crash以后做replay使用。
存放sstable的磁盘可以使用HDD/SSD磁盘，相关cassandra有优化配置，那么这里的话可以使用多块磁盘组合使用Raid0或者cassandra所谓的JBOD方式，使用其他的Raid1-Raid5不是最优的使用推荐，因为在节点层面有多数据副本冗余。具体磁盘容量视集群业务需求以及其他配置来定。
节点数
Cassandra可以是单节点（需要设置replicat factor 为1），2个节点（replicat factor最多是2），3个节点，…..个节点，理论上的扩容是线性的，无上限的扩容，可以从1 到很大。但是常见一般300个物理节点基本是可以了。