目前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，减少不必要的数据存储；