Cassandra 数据模型设计，根据你的查询来制定设计——反范式设计本质：空间换时间
转自：http://www.infoq.com/cn/articles/best-practice-of-cassandra-data-model-design
不要把Cassandra model想象成关系型数据库table
取而代之，应该把它想象成事一个有序的map结构。
对于一个新手来说，下面关系型数据库术语常常被对应到Cassandra模型
这种对比可以帮助我们从关系型数据库转换到非关系型数据库。但是当设计Cassandra column famiy的时候请不要这样去类比。取而代之，考虑它是一个map中嵌入另一个map：外部map的key为row key，内部map的key为column key，两个map的key都是有序的。如下：
SortedMap<RowKey, SortedMap<ColumnKey, ColumnValue>>
why？
将column family想象成嵌套的并排序的map比关系型数据库table描述的更为准确，它将帮助你正确的进行Cassandra模型设计。
How?
- Map可以进行高效查询，同时排序的特性可以进行高效column扫描。在Cassandra中，我们可以使用row key和column key做高效查找和范围扫描
- Column key的数量是很庞大的（译者注：目前译者所使用的Cassandra1.2.5版本，每个row支持最多20亿个columns）。换句话说你，你可以拥有一个wide rows。
- Column key自身可以存储值，即你可以拥有一个没有值的column。
如果集群使用Order Preserving Partitioner (OOP)策略进行数据存储,就可以对row key进行范围查询。但是OOP大多数情况都不推荐使用（译者注：将rowkey按照顺序存储到节点上，如果分区不均匀，将导致数据读写不均衡），所以你可以认为外部的map是不排序的，如下：
Map<RowKey, SortedMap<ColumnKey, ColumnValue>>
上面提到的”Super Column”，认为它们是一组column，这样的话，两级嵌套map就会像下面展示的一样变为三级嵌套map：
Map<RowKey, SortedMap<SuperColumnKey,
SortedMap<ColumnKey, ColumnValue>>>
注意：
- 你需要传递timestamp给每个column value，因为Cassandra使用它做内部的冲突处理机制。但在建模过程中你可以忽略它（译者注：在操作column的时候timestamp信息 会自动添加到column）。同时，不要考虑在你的程序中使用column的timestamp，因为它不是为你设计的，与Hbase不同，它们不会生成 新的version数据（译者注：在Hbase中相同rowkey和column key的数据会保存多个version，而Cassandra会将相同数据覆盖，timestamp只保存最后一次更新的时间）。
- 因为Super Column的性能问题和缺乏二级索引支持问题，Cassandra社区对它的使用曾有过强烈争议。所以，推荐使用Composite Columns代替Super Column实现功能。（译者注：使用Super Column，如果你要获取其中一个columnvalue，则要扫描整个Super Column,这会导致查询性能很糟糕）
围绕着查询模式进行Column Family建模
建模尽量从实体和它们的关系开始
- 与关系型数据库不同，在Cassandra中通过创建二级索引或者编写复杂SQL（使用joins, order by, group by）来新建或修改查询不是件容易的事情。因为Cassandra具有很高的分布式特性，所以要先考虑查询模式，然后再设计column family。
- 牢记前面提到的嵌入排序map数据结构，在考虑如何组织你的数据到map，以满足快速查询/排序/分组/过滤/聚合的要求。
在大部分情况下，实体和它们的关系是很重要的（特殊用例除外，如日志存储或者其它时间序列数据）。如果我给你一个查询模式，用于为一个电子商务网站 创建Cassandra模型，但不告诉你任何实体和它们的关系。你会有意或者无意的从查询模式或者从你之前领域对象的理解找出实体和它们之间的关系（因为 我们是通过实体和关系来描述真实世界）。在设计数据模型时最好从实体和关系开始，然后使用反范式化和冗余的方式继续围绕查询模式建模。如果这听起来有些让 人困惑，通过后面的详细例子就可以理解。
注意：在建模的时候考虑以下几点会很有帮助。区分频次大的查询和频次小的查询，有些查询可能只被查询几千次，其它可能被查询数十亿次；还要考虑哪些查询对数据延迟是敏感的。确保你的模型优先满足查询频次大的查询和重要查询。
