目前spark、storm都支持cassandra存储,cassandra重返nosql舞台,本文分享一些Cassandra 表设计的通用原则,我们团队的实战经验,希望对大家有用。
每个数据库中有成百上千的表,将其抽象分类起来无非以下几种:拥有较少数据量的小型表、主要起参考作用的大中型表、管理具体业务行为的大中型表、存储用的大型表。一般而言Cassandra的写是优于读的,因此需要结合表的类型,以及其读写方面的要求,合理设计每个CF的属性,将每个CF的设计达到最优。表类型可以按照下图分类:
- 较少数据量的小型表
此类表一般都是编码表,比如枚举类型表,状态信息表等。一般情况只有几行,几十行,最多几千行数据。他们的体积都非常的小,列都不多,一次IO基本都将全部的数据读取完毕,里面的数据也基本是静止的,平时基本保持不变。但是此类表引用的非常的频繁,几乎每个查询都要使用,对于此类表一般而言可以考虑将其设计caching属性设计为:
1) rows_only,即将全表放到内存中;
2) 如果该表的update数据比较多,将gc_grace_seconds调小,建议值(1800-3600)。
2.起参考作用的大中型表
此类表一般都是主题信息方面的表,比如员工表,供应商表,商品表等。一般情况存有几千,几万,最多几百万的数据。他们的体积偏小,一般几M,几十M,最多几百M,里面的数据会变化,但不是非常频繁的变,一般是定时变化一次。但是此类表的列一般比较多,因此设计列的顺序非常的重要,特别是key内的字段顺序的设计。需要考虑到将key经过hash后值的分布,将值类型比较多、同时查询比较多的列作为key较好。需要考虑几个问题:
1) 是否需要keycache,即将key放到内存中,方便快速查询;
2) 相同的key值是否过多,出现数据单点问题,如果出现使用复合key设计;
3) 如果该表的update数据比较多,将gc_grace_seconds调小,建议值(1800-3600);
4) 过期数据使用default_time_to_live设置自动删除;
5) 写多的表compaction使用SizeTieredCompactionStrategy;
6) 读较多的表compaction使用LeveledCompactionStrategy;
7) 自动做compaction,提高读效率;
3.管理具体业务行为的大中型表
此种表的数据量比较大,读写都很频繁,也是整个数据库中最复杂,最繁忙的表,比如订单表。
1) 是否需要keycache,即将key放到内存中,方便快速查询;
2) 相同的key值是否过多,出现数据单点问题,如果出现使用复合key设计;
3) 如果该表的update数据比较多,将gc_grace_seconds调小,建议值(1800-3600);
4) 过期数据使用default_time_to_live设置自动删除;
5) 写多的表compaction使用SizeTieredCompactionStrategy;
6) 读较多的表compaction使用LeveledCompactionStrategy;
7) 自动做compaction,提高读效率。
4.存储用的大型表
2) 相同的key值是否过多,出现数据单点问题,如果出现使用复合key设计;
3) 过期数据使用default_time_to_live设置自动删除;
4) 写多的表compaction使用SizeTieredCompactionStrategy
定时做compaction,减少不必要的数据存储;