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个物理节点基本是可以了。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
vivo 大规模特征存储实践
本文首发于 vivo互联网技术 微信公众号 链接:https://mp.weixin.qq.com/s/u1LrIBtY6wNVE9lzvKXWjA 作者:黄伟锋 本文旨在介绍 vivo 内部的特征存储实践、演进以及未来展望,抛砖引玉,吸引更多优秀的想法。 一、需求分析 AI 技术在 vivo 内部应用越来越广泛,其中特征数据扮演着至关重要的角色,用于离线训练、在线预估等场景,我们需要设计一个系统解决各种特征数据可靠高效存储的问题。 1. 特征数据特点 (1)Value 大 特征数据一般包含非常多的字段,导致最终存到 KV 上的 Value 特别大,哪怕是压缩过的。 (2)存储数据量大、并发高、吞吐大 特征场景要存的数据量很大,内存型的 KV(比如 Redis Cluster)是很难满足需求的,而且非常昂贵。不管离线场景还是在线场景,并发请求量大,Value 又不小,吞吐自然就大了。 (3)读写性能要求高,延时低 大部分特征场景要求读写延时非常低,而且持续平稳,少抖动。 (4)不需要范围查询 大部分场景都是单点随机读写。 (5)定时灌海量数据 很多特征数据刚被算出来的时候,是存在一些面...
- 下一篇
数据库中间件漫谈——看看云时代,它会走向何方
云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 前言 随着业务的发展,MySQL数据库中的表会越来越多,表中的数据量也会越来越大,相应地,数据操作的开销也会越来越大;另外,无论怎样升级硬件资源,单台服务器的资源(CPU、磁盘、内存、网络IO、事务数、连接数)总是有限的,最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。 分表、分库和读写分离可以有效地减小单台数据库的压力。 而数据库中间件,也火了很长一段时间,基本上每个大厂都会自研一套。 本文主要针对业界主流的数据库中间件的实现、功能、成本等方面进行对比,总结数据库中间件的实现方式,并展望未来的可能发展。 实现方式 一般来说,对于数据库中间件,可以在以下六个层次做切入。 2.1 代码层在同一个项目中创建多个数据源,采用if else的方式,直接根据条件在代码中路由。 Spring中有动态切换数据源的抽象类,具体参见AbstractRoutingDataSource。 如果项目不是很庞大,使用这种方式能够快速的进行分库。但缺点也是显而易见的,这种海量的代码侵入是绝不能被接受的。 而且...
相关文章
文章评论
共有0条评论来说两句吧...