【Cassandra】数据表设计（不断更新）.

Cassandra表设计的注意事项

以母语中文进行转述：

对于表格设计的考虑要点进行概括性总结…

功能性的事情 de

考虑到RDB不提供像SQL一样的表项间连接功能，
如果需要连接多个表的数据，则可以采取以下方法：
· 在客户端从多个表中进行读取，并在应用程序中进行连接。
· 创建与连接结果对应的非规范化表。
※虽然在应用程序中读取多个表并进行处理会很麻烦，而且可能在处理过程中出现问题，还存在性能问题，但如果能通过非规范化来处理那就更好了。

只有主键或者辅助索引指定的列才可以在”where”语句中指定。

在查询中可用的排序仅由使用CREATE TABLE命令指定的聚簇键选择决定。
（SELECT语句支持ORDER BY，但仅限于按照指定的聚簇键顺序进行排序，无法进行类似关系数据库的任意排序。）

无法使用聚类键列的内容来“反向查找”分区键列项目。
⇒可以准备一个用于反向查找的查找表。

・主键必须是唯一的。
Cassandra始终是upsert的，因此如果偶然发生相同的键值，需要小心，以免发生错误并被覆盖。
※虽然可以通过使用轻量级事务来避免，但会带来很大的负担。

性能方面

对于表格的规范化（非规范化），需要考虑作为分布式数据库的特性。
由于是分布式数据库且不支持连接操作，因此在读取方面比关系型数据库更突显规范化的不足之处。
为了避免多次读取，可以将其作为与发出查询对应的架构。
关系型数据库：数据建模 → 查询创建
Cassandra：查询路径建模 → 支持模型的表格设计

希望partition key具备将数据均匀分配到每个节点的功能。
当在单一partition上频繁进行读写操作时，会导致节点负载不平衡。

・不要创建过大的分区。
・使用聚簇键向行中添加行，可能导致分区不断增长。
分区内的列（单元格）上限为20亿个，但建议保持在100MB以下。
・若分区过大，可能会对修复、数据流和读取性能造成问题。

根据I/O模式（读取/写入），考虑到Compaction策略的使用情况，我们将表进行分割。
（由于Compaction策略是基于每个SStable（每个表）的设置。）

适用于基数极高的列的次要索引效率不高。次要索引的搜索在所有节点上进行，但是如果基数很高，例如只获取一个分区（在大多数节点上不会找到目标），效率就不高。

请注意，当次要索引的基数较低时，可能会生成大量的响应结果。

如果次要索引效率较低，可以考虑使用查找表。
注意，由于没有提供表间的引用一致性机制，需要考虑整个一致性的问题。