• Cassandra基础2


    =========================================================

    gossip协议
    1、点对点(peer to perr)的网络通信协议,节点间地位相同。
    2、两个节点间断性地交换自身信息及其知道的信息,每秒最多和群集中三个节点交换信息。
    3、每条交换信息中包含版本信息,新版本的信息会覆盖掉就版本的信息。
    4、通过多次交换各节点能获取到整个群集其他节点的信息。

     

    =========================================================

    seed nodes配置建议:
    1、为避免gossip通信出现问题,建议群集中所有节点都有相同的seed nodes列表,seed nodes列表仅用于节点加入到群集时bootstrap过程使用。
    2、在多数据中心集群环境,确保每个数据中心至少有一个节点在seed nodes列表中,为提高容错性,建议为每个数据中心指派多个seed node。
    3、为避免影响gossip性能,建议为每个数据中心最多配置3个节点到seed nodes列表中。

     

    =========================================================

    失败检测和恢复
    1、通过信息交换,系统能自动判断出群集中某个节点发生故障或存在性能问题,并避免将请求路由到该节点。
    2、可以通过配置phi_convict_threshold属性来调节失败检查的敏感性,当网络较差时,可以适当调高该阈值。
    3、对于故障节点,系统仍会定期进行检查,确定该节点是否恢复正常。
    4、对于长期失效节点,建议将其移除节点
    5、对于重新回归的节点,需要对进行repair修复数据。hintedhandoff有时间限制,默认三小时,超过此时间前面的数据会不断的被覆盖掉,需要手动repair。

    =========================================================
    分区器(partitioners):
    分区器用来决定数据在群集的那些节点进行存储(包含副本数据),Cassandra提供三种partitioners:
    1、Murmur3Partitioner(默认): 基于MurmurHash hash值将数据均匀的分布在集群
    2、RandomPartitioner: 基于MD5 hash值将数据均匀的分布在集群中
    3、ByteOrderedPartitioner: 通过键的字节来保持数据词汇的有序分布

    Murmur3Partitioner使用MurmurHash hash算法,而RandomPartitioner使用加密hash算法,因此Murmur3Partitioner比RandomPartitioner有3至5倍的性能提升。

    ByteOrderedPartitioner使得数据按照主键有序排列,运行通过主键进行有序扫描,该功能可以通过index来实现,而ByteOrderedPartitioner分区器很难实现负载均衡和数据热点问题,因此不建议使用。

    =========================================================

    Cassandra数据维护
    当数据发生修改(增删改)操作时,Cassandra将先将修改日志写到Commit Log,然后在把数据写到Memtable,再将Memtable中数据顺序Flush到磁盘保存在SSTable中,

    当Memtable中数据超过配置阈值或Commitlog的空间超过commitlog_total_space_in_mb的值时,便会触发Flush操作。

    Cassandra将数据刷新到SSTable,会将带有新时间戳的数据写入到新的SSTable中,不会覆盖会追加到旧的SSTable,因此不同的SSTable可能保存同一行数据的多个版本,为保证数据库的健康性,Cassandra周期性的合并SSTables,并将老数据废弃掉,该行为被称为合并压缩。

    Cassandra提供以下压缩策略:
    1、SizeTieredCompactionStrategy(STCS)
    2、LeveledCompactionStrategy(LCS)
    3、TimeWindowCompactionStrategy(TWCS)
    4、DateTieredCompactionStrategy(DTCS)

    =========================================================

    SizeTieredCompactionStrategy(STCS)
    当Cassandra 相同大小的SSTables数目达到一个固定的数目(默认是4),STCS开始将多个SSTable压缩成一个更大的SSTable。
    优势:写占比高的情况压缩很好
    劣势: 可能将过期的数据保存的很久,随着时间推移,需要的内存大小随之增加。
    适用场景:写占比高的场景。

    =========================================================
    LeveledCompactionStrategy(LCS)
    LCS会将数据合并压缩成多个层级,每一层是上一层的10倍。LCS压缩过程确保了从L1层开始的SSTables不会有重复的数据。
    优势: 磁盘空间的要求容易预测。读操作的延迟更容易预测。过时的数据回收的更及时。
    劣势: 更高的I/O使用影响操作延迟。
    适用场景:读占比高的场景

    =========================================================

    TimeWindowCompactionStrategy(TWCS)
    TWCS基于时间窗口将SSTable进行分组,
    优势: 用作时间序列数据,为表中所有数据使用默认的TTL。比DTCS配置更简单。
    劣势: 不适用于时间乱序的数据,因为SSTables不会继续做压缩,存储会没有边界的增长,所以也不适用于没有设置TTL的数据。相比较DTCS,需要更少的调优配置。
    适用场景:时间序列且设置了TTL的场景


    DateTieredCompactionStrategy(DTCS)
    DTCS类似于TWCS,已弃用。

     

    摘抄自:https://blog.csdn.net/FS1360472174/column/info/14229

  • 相关阅读:
    ASP.NET Core 中的依赖注入 [共7篇]
    ASP.NET Core的配置(4):多样性的配置来源[下篇]
    ASP.NET Core的配置(4):多样性的配置来源[中篇]
    ASP.NET Core的配置(4):多样性的配置来源[上篇]
    ASP.NET Core的配置(3): 将配置绑定为对象[下篇]
    ASP.NET Core的配置(3): 将配置绑定为对象[上篇]
    ASP.NET Core的配置(2):配置模型详解
    ASP.NET Core的配置(1):读取配置信息
    ASP.NET Core中的依赖注入(5):ServicePrvider实现揭秘【补充漏掉的细节】
    ASP.NET Core中的依赖注入(5): ServiceProvider实现揭秘 【解读ServiceCallSite 】
  • 原文地址:https://www.cnblogs.com/gaogao67/p/10458099.html
Copyright © 2020-2023  润新知