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存储性能监控指标数据的文章，可以在这里阅读：点击打开链接。

Cassandra与RDBMS的设计差别相关推荐

各类镜头的设计差别(转载）
各类镜头的设计差别(转载) 一.照相镜头照相镜头的光学特性可由三个参数来表示,即照相镜头的焦距f'.相对孔径D/f'和视场角2ω'.其实就135 照相机而言,其标准画幅已确定为24mm X 36mm ...
Cassandra 权威指南
Cassandra 权威指南基本信息作者: (美)Eben Hewitt [作译者介绍] 译者:王旭丛书名: 图灵程序设计丛书出版社:人民邮电出版社 ISBN:9787115251121 上架 ...
Cassandra 简介
Cassandra 简介 Apache Cassandra是一个高度可扩展的高性能分布式数据库,用于处理大量商用服务器上的大量数据,提供高可用性,无单点故障.这是一种NoSQL类型的数据库. 让我们先 ...
Cassandra 1
Cassandra 架构 Cassandra的设计目的是处理跨多个节点的大数据工作负载,而没有任何单点故障 Cassandra中的数据复制: 集群中的一个或多个节点充当给定数据片段的副本.如果检测到一 ...
[翻译] Cassandra 分布式结构化存储系统
Python微信订餐小程序课程视频 https://edu.csdn.net/course/detail/36074 Python实战量化交易理财系统 https://edu.csdn.net/cou ...
NoSQL概述-从Mongo和Cassandra谈谈NoSQL
分两部分介绍NoSQL - NoSQL 概览 1. RDBMS VS NoSQL 2. NoSQL 种类 3. NoSQL 的一些名词 - 结合Mongo,Cassandra谈谈NoSQL的设计和应用 ...
NoSQL数据库知多少--列存储Cassandra数据库
背景 2007年Facebook为了解决消息收件箱搜索问题(Inbox Search problem)而开始设计Cassandra项目. 当时Facebook遇到了传统的方法难以解决的超大数据量存储可 ...
android 模糊查询搜索框_彻底搞懂 iOS 和 Android 的设计差异
设计经验分享 · 不定时更新 ------------------------------------------- 胡桃子深圳 | UI/UX设计师唧唧歪歪:设计师在做 app 的时候很少考虑两 ...
安卓和ios的ui设计区别_UI设计中IOS和安卓的设计差异
设计师在做app的时候很少考虑两个平台的差异,在设计上用一套设计稿去做,其实有很多不一样的地方.今天我就针对UI设计中IOS和安卓的设计差异进行简单的说明. iOS与安卓设计上的差异主要从系统差异.成 ...

Cassandra与RDBMS的设计差别

没有查询语言

没有引用完整性

第二索引

排序成为一种设计决策

反范式化

Cassandra与RDBMS的设计差别相关推荐

最新文章

热门文章