Cassandra最佳实践(3)配置篇

本文涉及的产品
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云原生多模数据库 Lindorm,多引擎 多规格 0-4节点
简介: cassandra最佳实践之cassandra的配置

本篇文章我们主要介绍cassandra的相关配置,我把cassandra的相关配置中个人觉得相对比较重要的按照集群、节点这个横向维度进行介绍,可能有的配置我不会列在这里,那么具有见cassandra.yaml里面的详细介绍;如何配置cassandra,需要在集群启动的时候在conf目录下面的cassandra.yaml里面进行配置即可。此外我们的配置需要遵守yaml文件配置规则。本处以3.11.4进行介绍

集群维度

cluster_name: //集群的名字,默认是Test Cluster,用''括起来。不同的cluster name的节点无法组成一个集群

num_tokens: 256 //集群中单节点的的分配token数,因为使用vnode,也就是vnode的个数,每个token是随机生成的,此外如果不使用vnode的话,可以使用每个节点预分配一个初始的token,通过下面的配置下;

initial_token: //如果集群不想使用vnode的话,需要手工给每个节点进行token配置,手工计算节点的token数,但是扩容的时候建议是成倍扩容。vnode不需要

partitioner: //集群的数据分配算法,也就是常见的一致性hash算法中计算hash的那个模块,其中默认使用org.apache.cassandra.dht.Murmur3Partitioner,也就是现在比较推荐的mum3的hash策略,也有别的RandomPartitioner(md5),OrderPreservingPartitioner,ByteOrderedPartitioner(字典序),对scan比较亲和,但是会有key倾斜

seed_provider:
    - class_name: org.apache.cassandra.locator.SimpleSeedProvider
      parameters:
          # seeds is actually a comma-delimited list of addresses.
          # Ex: "<ip1>,<ip2>,<ip3>"
          - seeds: "127.0.0.1"
//这个配置相对比较重要,主要是集群种seed节点配置,需要所有节点一样,而且数量有一定限制,取决于集群规模,如果是10个节点,推荐2个是ok的。

endpoint_snitch: //集群的snitch策略,涉及到集群的副本节点管理的测,默认SimpleSnitch

单节点维度

涉及到单节点的相关配置:

 hints_directory: //涉及到的hint的目录,默认的使用 /var/lib/cassandra/hints,如果某个节点挂掉,且这个节点负责挂掉节点hint记录,那么数据就会记到这个目录下面
 
 authenticator: //认证相关,默认是AllowAllAuthenticator,所有都可以通过认证,还有使用账户密码认证,这个需要集群种所有节点使用一种相同配置
 
 authorizer: //鉴权,默认是所有都可以有任何操作,可以通过配置CassandraAuthorizer进行不同鉴权,同样各个节点配置需要一样;
 
 data_file_directories: //数据文件的放置目录,默认是使用/var/lib/cassandra/data,推荐多快盘组合使用。
 
 commitlog_directory: //commitlog的配置目录,默认是 /var/lib/cassandra/commitlog,推荐较好的磁盘配置
 
 cdc_enabled: //是否使用cdc 功能,默认是关闭,如果开启,需要表配置也进行开启
 
 disk_failure_policy: //单机数据盘磁盘坏盘处理配置,默认stop,不接受gossip响应以及停掉cilent的服务。但是可以通过jmx访问
 
 commit_failure_policy: //commitlog数据盘的坏盘策略,默认是stop
 
 commitlog_sync:  //commitlog的 数据sync策略,默认是periodic,这个会影响系统的写性能;
 commitlog_sync_period_in_ms: // period模式下的flush 频率10000ms;也可以使用另一种sync策略,与period是二选一的;
 commitlog_sync: //如果是batch 下面就是batch sync的时间配置。
 commitlog_sync_batch_window_in_ms: 2
 
 commitlog_segment_size_in_mb: //commitlog每隔多大切一下,默认是32m
 commitlog_compression: //支持commitlog的压缩,默认是lz4
 
 concurrent_reads: //节点读线程池线程数,默认32,io bound,建议是16*磁盘数
 concurrent_writes: //节点写线程池线程数,默认32,cpu bound,建议是8*cpu core数
 concurrent_counter_writes: //counter线程池数,默认32,与read一样
 
 memtable_allocation_type: //memtable 的内存管理,默认是heap_buffers,也就是on heap的buffer管理
 
 listen_address: //节点监听服务的地址,本地节点的bind地址接口,如果配置文件不容易管理,可以使用统一的网卡bind配置:listen_interface: eth0
 rpc_address: //4.0之前需要thrift,所有这个可以配置下,默认localhost
 
 

其他

当然如果集群需要别的配置,比如安全相关的,client 到server,server与server的ssl配置,等等则可以yam里面再进行配置即可。

系统级别的配置则是别的章节介绍。

目录
相关文章
|
分布式计算 大数据 API
完美避坑!记一次Elasticsearch集群迁移架构实战
Elastic自身设计了集群分片的负载平衡机制,当有新数据节点加入集群或者离开集群,集群会自动平衡分片的负载分布。
|
存储 Java 大数据
分布式数据库HBase的安装部署和环境搭建的集群模式
HBase是一个分布式数据库系统,能够支持高性能、高可靠性、高伸缩性的数据存储和读写操作。在大数据时代,HBase成为了一个越来越受欢迎的数据库选择。本文将介绍HBase的集群模式的安装部署和环境搭建,帮助开发者快速上手。
671 2
|
存储 NoSQL Java
|
存储 分布式计算 NoSQL
分布式数据库HBase的基本概念和架构之基本架构的Client
HBase是一个分布式数据库系统,基于Google的Bigtable和Apache Hadoop的HDFS构建而成。它是一个分布式数据库的NoSQL数据库,主要用于存储和处理海量数据。HBase的核心特性包括高可用性、高性能和高伸缩性。在阿里云开发者社区中,我们将介绍HBase的基本概念和架构,以及它的基本架构Client。
501 1
|
存储 消息中间件 缓存
【Cassandra从入门到放弃系列 一】概述及基本架构
【Cassandra从入门到放弃系列 一】概述及基本架构
1794 0
|
消息中间件 分布式计算 Cloud Native
[实战系列]SelectDB Cloud Datax 数据写入最佳实践
企业正在经历其数据资产的爆炸式增长,这些数据包括批式或流式传输的结构化、半结构化以及非结构化数据,随着海量数据批量导入的场景的增多,企业对于 Data Pipeline 的需求也愈加复杂。新一代云原生实时数仓 SelectDB Cloud 作为一款运行于多云之上的云原生实时数据仓库,致力于通过开箱即用的能力为客户带来简单快速的数仓体验。在生态方面,SelectDB Cloud 提供了丰富的数据连接器插件(Connector)来连接各种来自周边大数据工具的数据源,内置 Kafka、Flink、Spark、DataX 等常见的 Connector。基于此,企业开发者能够更加便捷的将数据移动到 Se
289 0
|
存储 SQL 分布式计算
HBase 与 Cassandra 架构对比分析的经验分享
HBase 与 Cassandra 架构对比分析的经验分享
|
存储 监控 安全
HBase集群多租户实践
HBase集群多租户实践
460 0
HBase集群多租户实践
|
存储 缓存 算法
生产环境使用HBase,你必须知道的最佳实践
生产环境使用HBase,你必须知道的最佳实践
278 0
|
存储 运维 NoSQL
Cassandra 在 360 的实践与改进
2010年,Dropbox 在线云存储在国外被用户熟知,同时国内如360、金山、百度等各个厂商也都陆续推出了自家的网盘类产品;而在 "360云盘" 背后的存储技术支撑之一就是以 Cassandra 为基础的云端存储方案。自此,Cassandra 在360实现技术落地和大规模生产应用,并被持续改进优化,最终形成高峰时期超 10k+ 物理节点的使用规模,成为互联网公司中 Cassandra 生产环境落地规模最大的公司。
908 0
Cassandra 在 360 的实践与改进