Cassandra与RDBMS的设计差别

Cassandra的模型和查询方式与RDBMS有很多的不同，记住这些差异非常重要。

没有查询语言

SQL是关系型数据库的标准查询语言，Cassandra却没有查询语言。不过Cassandra确实也有自己的RPC序列化机制，Thrift。通过Thrift API，用户可以访问其中的数据。

没有引用完整性

Cassandra没有引用完整性的概念，因而没有join的概念。在关系型数据库中，你可以在一个表中指定一个外部键值， 以此引用另一个表中记录的主键。但是，Cassandra并没有提供这个功能。存储其他表中的相关ID是一个通用需求，这仍然是被支持的，但Cassandra里没有级联删除这样的概念。

第二索引

第二索引确实是一个有用的功能，比如你需要找到具有某个属性的酒店的唯一ID，在关系型数据库里，可能这么查询：

SELECT hotelID FROM Hotel WHERE name = 'Clarion Midtown';

当你知道酒店的名字却不知道ID的时候，肯定想这么查询这个酒店。关系型数据库如果接到这个查询，会进行一个全表扫描，检查每行的name列，查找所需要的名字。如果表很大，这种查询可能会很慢。对这种情况，关系型数据库的解决方案就是为这列建一个索引，相当于这部分数据的一个副本，来帮助更快地检索数据。因为HotelID已经是一个主键约束了，主键会自动进行索引，也就是主索引，所以，对name列建立的索引自然就是第二索引，目前Cassandra仍然不支持第二索引。

要在Cassandra中做到同样的事情，需要创建另一个列族来存储查询信息。你可以创建一个列族来存储酒店名，并将它们映射到酒店的ID。第二列族实际上起到一个显式的第二索引的作用。

第二索引目前正在被加入到Cassandra 0.7之中来，允许为列值建立索引。所以，如果你希望找到所有居住在指定城市的用户，第二索引的支持将会让你不必费力手工建立第二索引列族了。

排序成为一种设计决策

在RDBMS中，可以在查询中使用ORDER BY来轻松改变返回记录的顺序。默认的排序方法确实是不可配置的；默认情况下，记录按照它们写入的顺序被读出。如果希望改变顺序，只要改变查询语句即可，而且可以对任意一组列进行排序。但在Cassandra之中，排序就不同了，它变成了一个设计决策。列族的定义中包含一个CompareWith配置元素，这个配置指定了行在读出的时候按照什么方式排序，它在查询的时候是无法重新配置的。

RDBMS限制你只能基于存储在列中的数据类型来进行排序，但Cassandra存储的数据是字节数组，所以这种用指定数据类型排序的方法是行不通的。不过，你能做的是把列当作几种可排序的类型之一（ASCII、LONG、integer、TimestampUUID、字典排序等）。如果需要，你还可以使用自己实现的比较器来进行排序。

此外，Cassandra里没有SQL里的ORDER BY和GROUP BY语句。有一个查询的类型称为SliceRange，在第4章里会介绍到，它类似于ORDER BY，因为它允许翻转。

反范式化

在关系型数据库设计中，我们经常强调范式化的重要性。但是当使用Cassandra时，这就不是一个优点了，因为只有当数据模型是反范式化的时候，它的性能才是最好的。实际上，很多公司最终都会将关系型数据库反范式化，这主要有两个原因。其一是性能原因，当他们在其多年积累的海量有价值的数据上进行大量的join操作的时候，无法得到所需的性能，于是就按照已知的查询内容来反范式化数据库以优化查询。这种方法最终可以工作，但和关系型数据库的设计初衷相悖，最终引发的问题就是，在这种条件下，使用关系型数据库是否还是最佳手段。

关系型数据库进行反范式化的第二个原因是业务文档结构有时需要留存。也就是说，你有一个外围表，引用了很多的外部表，表的数据可能会随时间发生变化，但你也需要以快照形式保存外围文档的历史。常见的一个例子是收款信息。你已经有客户和产品表了，而且认为可以在收款信息里引用这些表。但是实际不应该这么做，因为客户和价格信息都可能发生变化，那时你就会丢失收款信息的完整性了，因为这些表的变动似乎在收款时也发生了，这可能会影响到审计、报告，甚至是违法的，还可能引发其他问题。

在关系型数据库里， 反范式化会破坏Codd的范式， 我们需要尽力避免。但在Cassandra中，反范式化却正好合乎规则。它在数据模型很简单时并不必要，但也不需要害怕它。

重点在于，首先对数据建模、然后再写查询的方法不再适用了。Cassandra中，应该先定义好查询，并围绕查询来组织数据。考虑一下应用使用的最基本的查询路径，之后根据查询路径来构建所需要的列族就可以了。

批评者们认为这是个非常严重的问题。不过在设计数据库的时候能够考虑应用如何查询也并非没有道理，实际上，一般在关系型数据库里也是这么做的。如果不能正确预期查询方式，那么不论是在Cassandra里还是在关系型数据库里，都会遇到问题。当然，查询方式可能会随着时间推移而改变，那么就不得不更新数据了。不过这和在关系型数据库里定义表时犯错或需要新的附加表也没什么区别。

有一篇关于Cloudkick如何使用Cassandra存储性能监控指标数据的文章，可以在这里阅读：点击打开链接 。