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个物理节点基本是可以了。

上一篇:我的博客即将入驻“云栖社区”,诚邀技术同仁一同入驻。


下一篇:Android Studio 中 build.gradle 中 dependencies 下的 comile 后面的内容的来源