Cassandra 数据模型 （基于CQL,解决胖列数量限制及灵活性问题）（1.1及以上版本）

文中主要交代Cassandra的编程模型及数据结构。

因为Cassandra版本数次更新，网上中文的资料已经有点过期，比较有表明性的好比ebuy那篇文章都已通过时了，因而本身找资料，结合官方博客写一篇Cassandra模型的文章。

一些名词的介绍：因为技术名词冲突，BigTable里的表对应的是Cassandra里的列族，而BigTable里面列族的概念更相似Cassandra早期实现里的超级列（该功能在Cassandra里已被关闭）。

Cassandra介绍

首先介绍一下Cassandra。

Cassandra是Apache的开源项目，是NoSQL的一种，普遍意义上的列族数据库，分布式，无中心机。其早期实现主要参考了Google的Big Table论文及亚马逊的Dynamo论文中的介绍，能够参考两篇论文来得到Cassandra的设计思想，关于更详细的资料，能够参见wiki及官方文档。

早期实现及最佳实践

前文提到早期实现，那么如今固然与早期区别已经极大了，从数据模型设计到实际使用，基本上已经自成体系了。其中之一最大的改变，就是1.1版本里对数据库操做的改变。

Cassandra的早期实现里，使用的彻底是BigTable的数据模型，即列及列族及主键等概念。在ebuy的最佳实践的文中，对该模型的使用作了详细解释，我无心在此引用他人文章，只是简单说一下概念。

最佳实践文章总共分两部分，上部分主要说的是列族数据库中该如何设计数据模型，其中主要讨论的是对关系及部分相关数据的重复储存来减小对数据库的分布式读取，其中对列族数据库数据结构的有个挺有意思的式子，以下：

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

下部分交代的则是Cassandra中的具体实现方式，好比当时Cassandra实现了一个与BigTable列族相似的东西，或者说只是名字不一样的东西，就是超级列，把相似的列聚 合在一块儿提取。

再好比说推荐使用胖列（使用列键查询）而不是瘦列（使用主键查询）。胖列指的是以大量的列储存关系，好比用户表users有三列user_k,p1,p2，第一列user_k是主键，第二列p1是用户购买的产品1，第三列p2是用户购买的产品2，pn能够扩展到极大的数量.

注：上文只是简单解释，实际全文中对各类应用场景的讨论不只限于该范围。

磁盘储存方式

Cassandra使用的方式是：把一级主键当作分区主键，列名做为列键储存。光说不清楚，上图：（图片来自Cassandra 1.1）

CREATE TABLE timeline ( user_id varchar, tweet_id uuid, author varchar, body varchar, PRIMARY KEY (user_id, tweet_id) );

上图是传统数据库的储存方式。

上图是Cassandra的储存方式，注意{1787，author}是列键名而不仅是数据。

如今的实现

随着Cassandra的成长，原先彻底按照BigTable实现的数据模型开始产生一些问题，其中之一就是没法无限扩大的列的数量，虽然已经设计了一个足够大的列数量，但对于大数据分布式数据库，仍然是不够用的，并且超级列的方式灵活性受限制，因而开发者开始走本身的道路，因而随着CQL（Cassandra本身的相似SQL的操做语言）的发布及发展，首先清除了超级列（BigTable里的列族）的概念：在CQL中，没有超级列的概念，在列上一级就是表，也就是原先概念上的超级列是不存在的，那针对原先的胖列的应用场景，该如何处理呢？

CQL中有主键及二级主键的概念，主键就是原先的主键，这个概念没有变化，而对于原先的超级列聚合，CQL经过 把二级主键的值加上列名做为列键名解决了这个问题。

也就是说，把原先由数据字典（请容许我使用这个关系数据库词汇）储存的数据储存到了数据表中，减轻了对数据字典的访问及数据字典数据结构的维持开销，把压力下发到数据表。

参考：

Schema in Cassandra 1.1

Cassandra Wiki

Cassandra Data Modeling Best Practices, Part 1

Cassandra Data Modeling Best Practices, Part 2