一 简介
对于那些习惯了关系型数据库的人来说，学习Cassandra有一定的困难。Cassandra有很多新的术语，与关系型DB中的术语既类似但本质上又不相同。这里我们主要从两个角度来学习Cassandra的数据模型：自底向上和自顶向下。
二 自底向上理解Cassandra的数据模型
Cassandra被归类于NoSQL数据库，其根本原因在于它的设计不像关系型DB那样需要预告定义属性列。Cassandra是按列进行存储的，通常我们可以想像为以下这种模型：
但是使用这种数据模型来存储数据之后，如果数据没有放在固定位置，那么在查询时我们就需要逐个查看各个Value的值；如果永远将一个值放在此模型中的固定位置，那么对于没有值的情况下必须添加点位符以保持相对位置。产生这些问题的根本在于，这种可称之为数组的数据模型过于简单，它的语义还不够丰富。
于是，我们考虑在些种模型之上增加一个维度以增加语义：value对应的名称。在给每一个Value取一个Name之后就得到了如下图所示的一个映射结构。
这样就大大增加了语义，我们知道了每一个Value对应的Name，知道了它的用途。
虽然上面的模型解决了数据的存储及解析问题（主要是解决了正确解析的问题），但是这种模型只能存储某一个实例的数据，如果有多个实例，它们要存储的数据都一样，那应该怎么办呢？
Cassandra为解决此问题，给上面这种数据模型再增加了一个Name，并且称之为Row Key。要注意的是，这里的Row Key本质上也是一个Name，它不同于关系型DB中的Row Key，但作用类似，均是用于唯一标识一组数据。在增加了这个Row Key后，得到如下图所示的数据模型：
在得到了Row的概念后，就有了一个新的问题了，我们怎么存储多个行的数据呢？Cassandra为些引入了一个列族的概念，用作逻辑上的分组，联系起相似的数据。因此，可以把列族类比作关系型DB中的Table。
把上面提到的这些概念整合在一起，就得到了Cassandra的基本数据结构：列，也就是Name/Value对（客户端还会提供一个最近一次更新的时间戳）；列族，就是为具有相似但不同的列的集合的行而准备的容器。
最后再稍微提一下从列到行演化时可能发生的嵌套问题，Cassandra中称此为超级列（Super Column）,它的本质就是用Row对上图中的Row再封装一层。值得注意的是，Cassandra中只允许嵌套一层。
三 小结
虽然不倡议将Cassandra中的概念同关系型DB中的概念进行类比，但是通过类比我们可以更快捷地理解各个概念所起的作用及引入的源由。列，就是Name/Value对，而列族就相当于Table，它是为存储由列组成的Row来引入的。至于列族外层是什么容器，那就是下一篇文章《[原创]Cassandra的基本数据模型之自顶向下》中所讲述的了。
如有错误这处，敬请留言！