Cassandra数据模型

提起NoSQL
这个话题，仿佛不应该是DBA
要关注的事，而是架构师应该关心的。但是作为一名DBA
，在使用传统的关系型思想建模时，应该有必要了解NoSQL
的建模方法。

各种NoSQL
数据库有很多，我最关注的还是BigTable

类型，因为它是一个高可用可扩展的分布式计算平台，用来处理海量的结构化数据，而数据库同样也是处理结构化数据，所以除了没有SQL
，在数据模型方面有相似之处。Cassandra

是facebook
开源出来的一个版本，可以认为是BigTable
的一个开源版本，目前twitter
和digg.com
在使用。我们尝试从DBA
的角度出发去理解Cassandra
的数据模型。

NoSQL
并不能简单的理解为No SQL

，其本质应该是No Relational

，
也就是说它不是基于关系型的理论基础，而我们所有传统的数据库都是基于这套理论而发展起来的，所以SQL
并不是问题的关键所在，比如有些NoSQL
数据库 可以提供SQL
类型的接口，允许你通过类SQL
的语法去访问数据。而Friendfeed
则是反其道而行之，利用关系型数据库MySQL
，采用了去关系化 的设计方法，去实现自己的KeyValue
存储。所以NoSQL
的本质是No Relational.

Cassandra
特点：

1.
灵活的schema
，不需要象数据库一样预先设计schema
，增加或者删除字段非常方便（on the fly
）。

2.
支持range
查询：可以对Key
进行范围查询。

3.
高可用，可扩展：单点故障不影响集群服务，可线性扩展。

Keyspace


Cassandra
中的最大组织单元，里面包含了一系列Column
family
，Keyspace
一般是应用程序的名称。你可以把它理解为Oracle
里面的一个schema
，包含了一系列的对象。

Column
family

（CF
）


CF
是某个特定Key
的数据集合，每个CF
物理上被存放在单独的文件中。从概念上看，CF
有点象数据库中的Table.

Key


数据必须通过Key
来访问，Cassandra
允许范围查询，例如：

start => '10050', :finish => '10070'

Column


在Cassandra
中字段是最小的数据单元，column
和value
构成一个对，比如：name:“jacky”
，column
是name
，value
是jacky
，每个column:value
后都有一个时间戳：timestamp
。

和数据库不同的是，Cassandra
的一行中可以有任意多个column
，而且每行的column
可以是不同的。从数据库设计的角度，你可以理解 为表上有两个字段，第一个是Key
，第二个是长文本类型，用来存放很多的column
。这也是为什么说Cassandra
具备非常灵活schema
的原 因。

Super
column


Super column
是一种特殊的column
，里面可以存放任意多个普通的column
。而且一个CF
中同样可以有任意多个Super column
，一个CF
只能定义使用Column
或者Super column
，不能混用。下面是Super column
的一个例子，homeAddress
这个Super column
有三个字段：分别是street
，city
和zip
：

homeAddress: {street: "binjiang road",city: "hangzhou",zip: "310052",}

Sorting


不同于数据库可以通过Order by
定义排序规则，Cassandra
取出的数据顺序是总是一定的，数据保存时已经按照定义的规则存放，所以取出来的顺序已经确定了，这是一个巨大的性能优势。有意思的是，Cassandra

按照column name
而不是column value
来进行排序，

它 定义了以下几种选项：BytesType, UTF8Type, LexicalUUIDType, TimeUUIDType, AsciiType,

和LongType
，用来定义如何按照column name
来排序。实际上，就是把column name
识别成为不同的类型，以此来达到灵活排序的目的。UTF8Type
是把column name
转换为UTF8
编码来进行排序，LongType
转换成为64
位long
型，TimeUUIDType
是按照基于时间的UUID
来排序。例如：

Column name
按照LongType
排序：

{name: 3, value: "jacky"},

{name: 123, value: "hellodba"},

{name: 976, value: "Cassandra"},

{name: 832416, value: "bigtable"}

Column name
按照UTF8Type
排序：

{name: 123, value: "hellodba"},

{name: 3, value: "jacky"},

{name: 832416, value: "bigtable"}

{name: 976, value: "Cassandra"}

下面我们看twitter
的Schema
：

<Keyspace Name="Twitter">

<ColumnFamily CompareWith="UTF8Type" Name="Statuses" />

<ColumnFamily CompareWith="UTF8Type" Name="StatusAudits" />

<ColumnFamily CompareWith="UTF8Type" Name="StatusRelationships"

CompareSubcolumnsWith="TimeUUIDType" ColumnType="Super" />

<ColumnFamily CompareWith="UTF8Type" Name="Users" />

<ColumnFamily CompareWith="UTF8Type" Name="UserRelationships"

CompareSubcolumnsWith="TimeUUIDType" ColumnType="Super" />

</Keyspace>

我们看到一个叫Twitter
的keyspace
，包含若干个CF
，其中StatusRelationships
和 UserRelationships
被定义为包含Super column
的CF
，CompareWith
定义了column
的排序规则，CompareSubcolumnsWith
定义了subcolumn
的排序 规则，这里使用了两种：TimeUUIDType
和UTF8Type
。我们没有看到任何有关column
的定义，这意味着column
是可以灵活变更的。

为了方便大家理解，我会尝试着用关系型数据库的建模方法去描述Twitter
的Schema
，但千万不要误认为这就是Cassandra
的数据模型

，对于Cassandra
来说，每一行的colunn
都可以是任意的，而不是象数据库一样需要在建表时就创建好。



Users CF
记录用户的信息，Statuses CF
记录tweets
的内容，StatusRelationships CF
记录用户看到的tweets
，UserRelationships CF
记录用户看到的followers
。我们注意到排序方式是TimeUUIDType
，这个类型是按照时间进行排序的UUID
字段，column name
是用UUID
函数产生（这个函数返回了一个UUID
，这个UUID
反映了当前的时间，可以根据这个UUID
来排序，有点类似于timestamp
一样），所以得到结果是按照时间来排序的。使用过twitter
的人都知道，你总是可以看到自己最新的tweets
或者最新的friends.

存储


Cassandra
是基于列存储的(Bigtable
也是一样)
，这个和基于列的数据库是一个道理。



API


下面是数据库，Bigtable
和Cassandra API
的对比：

Relational
SELECT `column` FROM `database`.`table` WHERE `id` = key;

BigTable
table.get(key, "column_family:column")

Cassandra: standard model
keyspace.get("column_family", key, "column")

Cassandra: super column model
keyspace.get("column_family", key, "super_column", "column")

我对Cassandra
数据模型的理解：


1.column name
存放真正的值，而value
是空。因为Cassandra
是按照column name
排序，而且是按列存储的，所以往往利用column name
存放真正的值，而value
部分则是空。例如：“jacky”:“null”
，“fenng”:”null”

2.Super column
可以看作是一个索引，有点象关系型数据库中的外键，利用super column
可以实现快速定位，因为它可以返回一堆column
，而且是排好序的。

3.
排序在定义时就确定了，取出的数据肯定是按照确定的顺序排列的，这是一个巨大的性能优势。

4.
非常灵活的schema
，column
可以灵活定义。实际上，colume name
在很多情况下，就是value
（是不是有点绕）。

5.
每个column
后面的timestamp
，我并没有找到明确的说明，我猜测可能是数据多版本，或者是底层清理数据时需要的信息。

最后说说架构，我认为架构的核心就是有所取舍

，不管是CAP

还是BASE

，讲的都是这个原则。架构之美在于没有任何一种架构可以完美的解决各种问题，数据库和NoSQL
都有其应用场景，我们要做的就是为自己找到合适的架构。

–EOF–

这篇文章，我参考了up
and running with cassandra

，除此以外，我还参考了twitter
提供的API
，它帮助我理解twitter
的schema
设计。这篇文章，肯定有很多理解不正确的地方，希望朋友们指正。