第一章：Cassandra超越关系数据库--Cassandra：The Definitive Guide 2nd Edition

欢迎来到Cassandra：The Definitive Guide。 本书的目的是帮助开发人员和数据库管理员了解这一重要的数据库技术。 在本书的过程中，我们将探讨Cassandra如何与传统的关系数据库管理系统进行比较，并帮助您将其用于您自己的环境中。

关系数据库有什么问题？

我们要求你考虑一个数据模型，由一个拥有数千名员工的公司的小团队发明。 它可以通过TCP / IP接口访问，并且可以从各种语言中获得，包括Java和Web服务。 除了最先进的计算机科学家之外，这个模型起初很难理解，直到更广泛的采用有助于使概念更清晰。 使用围绕此模型构建的数据库需要学习新术语并以不同方式考虑数据存储。 但随着产品的兴起，越来越多的企业和政府机构投入使用，这在很大程度上是因为它能够快速处理数千次操作。 它产生的收入是巨大的。

然后出现了一个新模型。

新模型受到威胁，主要有两个原因。 首先，新模型与旧模型非常不同，旧模型引人注目。 这是一种威胁，因为很难理解不同和新的东西。 随后的辩论可以帮助人们在他们的观点中顽固地进一步巩固人们的观点 - 这些观点可能主要是从他们学习手艺的环境和他们工作的环境中继承下来的。 其次，也许更重要的是，作为一个障碍，新模式具有威胁性，因为企业已经对旧模式进行了大量投资，并且用它赚了不少钱。 改变路线似乎很荒谬，甚至是不可能的。

当然，我们正在讨论信息管理系统（IMS）分层数据库，该数据库于1966年在IBM发明。

IMS是为土星五号月球火箭而设计的。 它的建筑师是Vern Watts，他的职业生涯就是为此而努力。 我们中的许多人都熟悉IBM的数据库DB2。 IBM广受欢迎的DB2数据库得名于DB1的继承者 - DB1是围绕分层数据模型IMS构建的产品。 IMS于1968年发布，随后在客户信息控制系统（CICS）和其他应用程序中取得了成功。 它至今仍在使用。

但是在IMS发明之后的几年里，新模型，破坏性模型，威胁模型，是关系数据库。

在1970年的论文“大型共享数据库的数据关系模型”中，Edgar F. Codd博士也在IBM圣何塞研究实验室工作时提出了关于数据关系模型的理论。 本文仍然可以在http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf 上找到，它成为关系数据库管理系统的基础工作。

Codd的工作与IMS的层次结构相对立。 理解和使用关系数据库需要学习新术语，包括“关系”，“元组”和“正常形式”，所有这些术语对于IMS的用户来说确实听起来非常奇怪。 它比其前身具有一些关键优势，例如表达多个实体之间复杂关系的能力，远远超出分层数据库所代表的能力。

虽然这些想法及其应用已经发展了四十年，但关系数据库显然仍然是历史上最成功的软件应用程序之一。 它在独资企业中以Microsoft Access的形式使用，在大型跨国公司中使用，其中包含数百个精细调整的实例集群，代表数TB的数据仓库。 关系数据库存储发票，客户记录，产品目录，会计分类帐，用户身份验证方案 - 可能会出现这个世界。 毫无疑问，关系数据库是现代技术和商业领域的关键方面，并且将在未来许多年内以各种形式与我们合作，IMS将以各种形式出现。 关系模型提供了IMS的替代方案，每种方法都有其用途。

因此，对“关系数据库有什么问题？”这个问题的简短回答是“没什么”。

然而，有一个相当长的答案，它说，每隔一段时间，一个想法诞生，表面上会改变事物，并产生各种革命。 然而，从另一方面来看，从结构上看，这种革命只是历史的一切照旧。 IMS，RDBMS，NoSQL。 马，车，飞机。 它们各自以现有技术为基础，它们各自试图解决某些问题，因此它们每个人都善于处理某些事情而不善于其他事情。 它们各自共存，即使是现在。

让我们来看看为什么，在这一点上，为什么我们可以考虑替代关系数据库，就像四十年前Codd本人看到信息管理系统并认为它可能不是组织信息的唯一合法方式 并解决数据问题，也许，对于某些问题，考虑替代方案可能会很有成效。

当关系应用程序成功并且使用率上升时，我们会遇到可伸缩性问题。 连接是任何相对规范化的关系数据库中固有的，即使是适度的大小，连接也可能很慢。 数据库获得一致性的方式通常是通过使用事务，这需要锁定数据库的某些部分，以便其他客户端无法使用。 在非常繁重的负载下，这可能变得难以维持，因为锁意味着竞争用户开始排队，等待他们轮流读取或写入数据。

我们通常通过以下一种或多种方式解决这些问题，有时按此顺序：

• 通过添加更多内存，添加更快的处理器和升级磁盘来解决问题。这称为垂直缩放。这可以缓解你一段时间。

• 当问题再次出现时，答案似乎是相似的：现在一个框被最大化，您在数据库集群中以附加框的形式添加硬件。现在，您在常规使用和故障转移方案中遇到了数据复制和一致性的问题。你以前没有那个问题。

• 现在我们需要更新数据库管理系统的配置。这可能意味着优化数据库用于写入底层文件系统的通道。我们关闭日志记录或日志记录，这通常不是理想的（或者，根据您的情况，合法）选项。

• 我们将注意力集中到数据库系统中，然后转向我们的应用程序。我们试图改进我们的指数。我们优化查询。但据推测，在这种规模下，我们并不完全不了解索引和查询优化，并且已经有了很好的形状。因此，这将成为一个痛苦的过程，通过数据访问代码来寻找任何微调机会。这可能包括减少或重新组织联接，抛出资源密集型功能，例如存储过程中的XML处理等等。当然，大概我们正在进行XML处理是有原因的，所以如果我们必须在某个地方进行，我们将这个问题移到应用程序层，希望在那里解决它并且交叉我们的手指我们不会破坏别的东西与此同时。

• 我们使用缓存层。 对于较大的系统，这可能包括分布式缓存，例如memcached，Redis，Riak，EHCache或其他相关产品。 现在，我们在缓存中的更新和数据库中的更新之间存在一致性问题，这在集群中会加剧。

• 我们再次将注意力转向数据库并确定，现在应用程序已构建并且我们了解主要查询路径，我们可以复制一些数据，使其看起来更像是访问它的查询。 这个过程称为非规范化，与表征关系模型的五种常规形式相对立，违反了Codd关于关系数据的12条规则。 我们提醒自己，我们生活在这个世界中，而不是在某些理论云中，然后承诺尽我们所能使应用程序再次以可接受的水平响应，即使它不再是“纯粹的”。

科德的十二条规则

Codd提供了12个规则（实际上有13个，编号为0到12）的列表，正式确定了他对关系模型的定义，作为对商业数据库与其原始概念的分歧的回应。 1985年10月，Codd在CompuWorld杂志的一篇文章中介绍了他的规则，并在他的“数据库管理关系模型”一书的第二版中将其正式化，现在已经绝版。

这听起来很熟悉。在网络规模上，工程师可以合理地思考这种情况是否与亨利·福特的断言相似，即在某个时刻，它不仅仅是你想要的更快的马。他们做了一些令人印象深刻，有趣的工作。

因此，我们必须从这里开始认识到关系模型只是一个模型。也就是说，它旨在成为一种观察世界的有用方式，适用于某些问题。它并不意味着详尽无遗，在所有其他表示数据的方式上结案，再也没有进行过检查，没有留下替代品的余地。如果我们从历史的长远看，Codd博士的模型在当时是一个相当具有破坏性的模型。它是新的，带有奇怪的新词汇和术语，如“元组” - 以新的和不同的方式使用的熟悉的单词。关系模型受到怀疑，无疑遭受了强烈的批评者。它甚至以Codd博士自己的雇主IBM的形式遭遇了反对，IBM拥有围绕IMS的非常有利可图的产品，并且不需要年轻的暴发户。

但是关系模型现在可以说是数据世界中最好的位置。 SQL得到了广泛的支持和理解。 它在入门大学课程中讲授。 有一些开源数据库已经安装好，可以使用每月4.95美元的网络托管计划。 基于云的平台即服务（PaaS）提供商（如Amazon Web Services，Google Cloud Platform，Rackspace和Microsoft Azure）提供关系数据库访问即服务，包括自动监控和维护功能。 我们最终使用的数据库通常由我们组织内的架构标准决定。 即使没有这样的标准，也要谨慎地了解您的组织已经拥有的数据库平台。 我们在开发和基础设施方面的同事拥有相当来之不易的知识

如果只是渗透（或惯性），我们多年来已经了解到关系数据库是一种通用的解决方案。

所以也许更好的问题不是“关系数据库有什么问题？”而是“你有什么问题？”

也就是说，您希望确保您的解决方案符合您的问题。 关系数据库解决的问题很严重。 但是，网络的爆炸式增长，尤其是社交网络，意味着我们必须处理的大量数据相应爆炸式增长。 当Tim Berners-Lee在20世纪90年代初首次在网上工作时，它的目的是在物理实验室的博士之间交换科学文献。 当然，现在，网络已经变得如此普遍，以至于每个人都使用它，从同样的科学家到五岁大的小伙子交换关于小猫的表情符号。 这意味着它必须支持大量数据; 事实上，它确实是Web的巧妙架构的纪念碑。

但是，一些基础设施开始在重量下屈服。

关系数据库的快速回顾

虽然您可能熟悉它们，但让我们简单地将注意力转向关系数据库中的一些基本概念。 这将为我们提供一个基础，可以考虑围绕分布式数据系统固有的权衡取舍的最新进展，特别是非常大的分布式数据系统，例如网络规模所需的那些。

RDBMS：令人敬畏和不那么多

关系数据库在过去四十年中变得如此受欢迎的原因有很多。一个重要的结构化查询语言（SQL），它功能丰富，使用简单的声明性语法。 SQL于1986年首次被正式采用为ANSI标准;从那时起，它经历了多次修订，并且还通过Microsoft的T-SQL和Oracle的PL / SQL等供应商专有语法进行了扩展，以提供其他特定于实现的功能。

SQL功能强大有多种原因。它允许用户使用形成数据操作语言（DML）的语句来表示与数据的复杂关系，以插入，选择，更新，删除，截断和合并数据。您可以使用基于关系代数的函数执行各种各样的操作，例如，查找集合中的最大值或最小值，或者过滤和排序结果。 SQL语句支持对聚合值进行分组并执行汇总函数。 SQL提供了一种使用数据定义语言（DDL）在运行时直接创建，更改和删除模式结构的方法。 SQL还允许您使用相同的语法为用户和用户组授予和撤消权限。

SQL易于使用。 可以快速学习基本语法，从概念上讲，SQL和RDBMS提供了较低的入门门槛。 初级开发人员可以随时变得熟练，而且在快速变化，紧迫的期限和预算爆炸的行业中经常出现这种情况，易用性非常重要。 并且它不仅仅是易于使用的语法; 有许多强大的工具，包括用于查看和使用数据库的直观图形界面。

部分原因是它是标准，SQL允许您轻松地将RDBMS与各种系统集成。 您所需要的只是一个适用于您的应用程序语言的驱动程序，并且您可以通过非常便携的方式参加比赛。 如果您决定更改应用程序实现语言（或您的RDBMS供应商），您通常可以轻松地执行此操作，假设您没有使用大量专有扩展来支持自己。

事务，ACID-ity和两阶段提交

除了已经提到的功能之外，RDBMS和SQL还支持事务。 事务的一个关键特性是它们首先实际执行，允许程序员撤消（使用回滚）在执行期间可能出错的任何更改; 如果一切顺利，交易可以可靠地提交。 正如Jim Gray所说，交易是“国家转型”，具有ACID属性（参见“交易概念：美德与限制”）。

ACID是Atomic，Consistent，Isolated，Durable的首字母缩写，它是我们用来评估交易是否正确执行并且成功的指标：

• 原子性

  原子意味着“全有或全无”; 也就是说，当执行语句时，事务中的每个更新都必须成功才能被调用成功。 没有部分失败，其中一次更新成功，另一次相关更新失败。 这里的常见例子是ATM上的货币转账：转账需要从一个账户中减去钱并将其添加到另一个账户。 此操作无法细分; 他们必须都成功。

• 一致性

  一致意味着数据从一个正确的状态移动到另一个正确的状态，读者不可能一起查看不合理的不同值。 例如，如果交易尝试删除客户及其订单历史记录，则不能保留引用已删除客户主键的订单行; 这是一种不一致的状态，如果有人试图读取这些订单记录，则会导致错误

• 隔离性

  隔离意味着并发执行的事务不会相互纠缠; 它们各自在自己的空间中执行。 也就是说，如果两个不同的事务试图同时修改相同的数据，那么其中一个将不得不等待另一个完成。

• 持久性

  一旦事务成功，更改将不会丢失。 这并不意味着另一个事务不会在以后修改相同的数据; 它只是意味着编写者可以确信更改可用于下一个要处理的事务。

关于支持交易的争论很快就会成为围绕非关系数据存储的对话中的一个痛点，所以让我们花点时间重新审视这意味着什么。从表面上看，ACID属性似乎显然是可取的，甚至不值得谈话。据推测，没有人运行数据库会表明数据更新不必持续一段时间;这是进行更新的重点 - 他们可以让其他人阅读。但是，更细微的检查可能会让我们想要找到一种方法来稍微调整这些属性并稍微控制它们。正如他们所说，互联网上没有免费午餐，一旦我们看到我们如何支付交易费用，我们可能会开始怀疑是否有其他选择。

在重负荷下交易变得困难。当您首次尝试水平扩展关系数据库，使其分布时，您现在必须考虑分布式事务，其中事务不仅仅在单个表或单个数据库中运行，而是分布在多个系统中。为了继续遵守事务的ACID属性，您现在需要一个事务管理器来跨多个节点进行编排。

为了说明跨多个主机的成功完成，引入了两阶段提交（有时称为“2PC”）的想法。但是，因为两阶段提交会锁定所有相关资源，所以它仅对可以非常快速完成的操作有用。尽管通常情况下您的分布式操作可以在亚秒内完成，但情况肯定并非总是如此。某些用例需要您可能无法控制的多个主机之间的协调。协调若干不同但相关活动的操作可能需要数小时才能更新。

两阶段提交块;也就是说，客户端（“竞争消费者”）必须等待先前的事务完成才能访问被阻止的资源。该协议将等待节点响应，即使它已经死亡。在此事件中可以避免永远等待，因为可以设置超时，允许事务协调器节点决定节点不响应并且应该中止事务。但是，2PC仍然可以实现无限循环;这是因为节点可以向事务协调器节点发送消息，同意协调器可以提交整个事务。然后，节点将等待协调器发送提交响应（或者，如果不同的节点无法提交，则返回回滚响应）;如果协调器在这种情况下失效，那么该节点可能会永远等待。

因此，为了解决分布式事务的两阶段提交中的这些缺点，数据库世界转向了补偿的想法。 通常在Web服务中使用的补偿意味着操作立即提交，然后在报告某些错误的情况下，调用新操作以恢复正常状态。

有一些基本的，众所周知的补偿行为模式，架构师经常不得不考虑作为两阶段提交的替代方案。 这些包括在交易失败时注销，决定丢弃错误的交易并在以后进行核对。 另一种方法是稍后在通知时重试失败的操作。 在预订系统或股票销售代码中，这些不太可能满足您的要求。 对于其他类型的应用程序，例如计费或票务应用程序，这是可以接受的。

2PC为应用程序开发人员引入的问题包括部分故障期间的可用性损失和更高的延迟。 这些都不可取。 因此，一旦你有足够的成功就必须通过一台机器扩展数据库，你现在必须弄清楚如何在多台机器上处理事务并仍然使ACID属性适用。 无论您有10台还是100台或1,000台数据库计算机，事务中仍然需要原子性，就像您在单个节点上工作一样。 但它现在吞下了一个更大，更大的药丸。

架构

关系数据库系统的一个经常被称赞的特性是它们提供的丰富模式。 您可以在关系模型中表示域对象。 围绕（昂贵的）工具（例如CA ERWin Data Modeler）涌现出整个行业来支持这一努力。 但是，为了创建正确规范化的模式，您必须创建在域中不存在的业务对象的表。 例如，大学数据库的模式可能需要“学生”表和“课程”表。 但由于这里的“多对多”关系（一个学生可以同时学习多门课程，一门课程同时有很多学生），你必须创建一个连接表。 这污染了原始数据模型，我们更喜欢只有学生和课程。 它还迫使我们创建更复杂的SQL语句来将这些表连接在一起。 反过来，join语句可能很慢。

同样，在适度规模的系统中，这不是一个大问题。但是，一旦在许多表中处理大量行来处理复杂查询和多个连接，就会变得非常缓慢。

最后，并非所有模式都能很好地映射到关系模型。在过去十年中越来越受欢迎的一种系统是复杂的事件处理系统，它以非常快的速度表示状态变化。将运行时事件与可能相关的其他事件进行上下文关联通常很有用，以便推断出一些支持业务决策的结论。虽然事件流可以用关系数据库来表示，但这是一个令人不舒服的延伸。

如果您是一名应用程序开发人员，您无疑会熟悉近年来涌现出来的许多对象关系映射（ORM）框架，以帮助减轻将应用程序对象映射到关系模型的难度。同样，对于小型系统，ORM可以是一种解脱。但它也引入了自己的新问题，例如扩展内存需求，并且它经常使用越来越难以处理的映射代码来污染应用程序代码。这是一个使用Hibernate来减轻必须编写SQL代码负担的Java方法的示例：

是否确定我们已经做了什么，只是在这里解决问题？ 当然，对于某些系统，例如那些广泛使用文档交换的系统，如服务或基于XML的应用程序，关系数据库并不总是有明确的映射。 这加剧了这个问题。

分片和无共享架构

尝试扩展关系数据库的另一种方法是为您的体系结构引入分片。这已经在eBay这样的大型网站上得到了很好的效果，eBay每天支持数十亿条SQL查询，在其他现代网络应用程序中也是如此。这里的想法是，您将数据拆分，以便不是将所有数据托管在单个服务器上，也不是复制群集中所有服务器上的所有数据，而是水平分割部分数据并分别托管它们。

例如，考虑关系数据库中的大型客户表。最不具破坏性的事情（对于编程人员来说，无论如何）是通过添加CPU，增加内存和获得更快的硬盘来垂直扩展，但如果你继续成功并增加更多客户，在某些时候（可能是几十个）数百万行），您可能不得不开始考虑如何添加更多机器。当你这样做时，你只是复制数据，以便所有的机器都有它吗？或者您是否将该单个客户表分开，以便每个数据库只有一些记录，并保留其订单？然后，当客户端执行查询时，他们只将负载放在具有他们正在查找的记录的计算机上，而在其他计算机上没有负载。

似乎很清楚，为了分片，你需要找到一个好的密钥来订购你的记录。 例如，您可以将您的客户记录划分为26台机器，每个字母对应一个字母，每个机器只记录姓氏以该特定字母开头的客户的记录。 这可能不是一个好的策略，但是可能没有很多以“Q”或“Z”开头的姓氏，所以那些机器将闲置而“J”，“M”和“S” 机器穗。 您可以根据数字，例如电话号码，“成员自”日期或客户状态的名称进行分片。 这完全取决于您的特定数据可能如何分配。

确定分片结构有三种基本策略：

基于特征的分片或功能分段

这是eBay的杰出建筑师Randy Shoup采取的方法，他在2006年帮助将网站的架构变得成熟，每天支持数十亿次查询。使用此策略，数据的分割不是通过在单个表中划分记录（如前面讨论的客户示例），而是通过将不相互重叠的特征拆分为单独的数据库。例如，在eBay上，用户在一个分片中，而待售商品在另一个分片中。在Flixster，电影评级在一个分片中，评论在另一个分片中。此方法取决于您对域的理解，以便您可以干净地细分数据。

基于密钥的分片

在这种方法中，您可以在数据中找到一个密钥，该密钥可以在分片中均匀分布。因此，不像在早期和不正确的早期示例中那样简单地为每个服务器存储一个字母，而是在关键数据元素上使用单向散列，并根据散列在机器之间分配数据。在此策略中常见的是找到基于时间或数字键的哈希值。

查找表

在此方法中，群集中的一个节点充当“黄页”目录，并查找哪个节点具有您尝试访问的数据。 这有两个明显的缺点。 首先，每次必须通过查找表作为额外的跃点时，您将获得性能提升。 第二，查找表不仅成为瓶颈，而且成为单点故障。

分片可以根据您的策略最小化争用，并且不仅可以水平缩放，还可以更精确地缩放，因为您可以为需要它的特定分片添加功率。

Sharding可以被称为一种特定于数据库的“无共享”架构。

无共享体系结构是没有集中（共享）状态的体系结构，但是分布式系统中的每个节点都是独立的，因此共享资源没有客户端争用。 这个术语最初是由加州大学伯克利分校的迈克尔斯通布拉克尔在他1986年的论文“无共享案例”中创造的。谷歌最近普及了无共享架构，谷歌已经编写了Bigtable数据库和MapReduce等系统。 不共享状态的实现，因此能够接近无限扩展。 Cassandra数据库是一种无共享架构，因为它没有中央控制器，也没有主/从的概念; 它的所有节点都是一样的。

MongoDB还提供自动分片功能来管理故障转移和节点平衡。许多非关系数据库自动提供这个并且开箱即用非常方便;手动创建和维护自定义数据分片是一个邪恶的主张。一般来说，理解数据架构方面的分片很好，但特别是在Cassandra方面更具体，因为它可以采用类似于基于密钥的分片的方法来跨节点分配数据，但这样做是自动完成的。

网络规模

总之，关系数据库非常擅长解决某些数据存储问题，但由于它们的重点，它们在缩放时也会产生自己的问题。然后，您经常需要找到一种方法来摆脱您的连接，这意味着对数据进行非规范化，这意味着在数据库和应用程序中维护多个数据副本并严重破坏您的设计。此外，您几乎肯定需要找到解决分布式事务的方法，这很快就会成为瓶颈。除了最昂贵的RDBMS之外，不会直接支持这些补偿操作。即使您可以编写如此庞大的支票，您仍然需要仔细选择分区键，以至于您永远无法完全忽略限制。

也许更重要的是，当我们看到RDBMS的一些局限性以及架构师用来缓解其缩放问题的一些策略时，一幅画面慢慢开始出现。这张照片让一些NoSQL解决方案看起来可能不像我们最初想象的那么激进和不那么可怕，更像是一个自然表达和封装已经用于管理超大型数据库的一些工作。

由于RDBMS中的一些固有的设计决策，并不总是像其他一些考虑Web结构的更新的可能性那样容易扩展。然而，我们不仅要考虑Web的结构，还要考虑其显着的增长，因为随着越来越多的数据变得可用，我们需要架构，使我们的组织能够近乎实时地利用这些数据来支持决策为我们的客户制作并提供新的，更强大的功能和功能。

随着Web的快速发展，需要存储，处理和查询的数据种类繁多，而使用此类数据的企业则有很多种。 不仅要考虑熟悉的零售商或供应商的客户数据，还要考虑数字视频内容，以及数字电视所需的移动以及电子邮件，消息传递，移动电话，RFID，IP语音（VoIP）使用的爆炸式增长，以及 物联网（IoT）。 由于我们偏离了物理消费者媒体存储，提供内容的公司和围绕它们构建的第三方增值业务需要非常可扩展的数据解决方案。 还要考虑作为典型的业务应用程序开发人员或数据库管理员，我们可能会习惯将关系数据库视为我们Universe的中心。 然后，您可能会惊讶地发现，在公司内部，大约80％的数据是非结构化的。

NoSQL的崛起

最近对非关系数据库的兴趣反映了软件开发社区对Web规模数据解决方案的需求日益增长。 “NoSQL”一词在2009年左右开始流行，作为描述这些数据库的简写方式。 这个术语在历史上一直是争论的主题，但已经出现了一个共识，即该术语指的是支持“不仅仅是SQL”语义的非关系数据库。

各种专家试图在几大类别中组织这些数据库; 我们将研究一些最常见的：

• 键值存储

  在键值存储中，数据项是具有一组属性的键。 与密钥相关的所有数据都与密钥一起存储; 数据经常重复。 流行的键值商店包括亚马逊的Dynamo DB，Riak和Voldemort。 此外，许多流行的缓存技术充当键值存储，包括Oracle Coherence，Redis和MemcacheD。

• 列存储

  列存储也经常被称为宽列存储。 谷歌的Bigtable是实施的灵感来源，包括Cassandra，Hypertable和Apache Hadoop的HBase。

• 文档存储

  文档数据库中的基本存储单元是完整文档，通常以JSON，XML或YAML等格式存储。 流行的文档存储包括MongoDB和CouchDB。

• 图数据库

  图形数据库将数据表示为图形 - 连接节点的节点和边缘的网络。 节点和边都可以具有属性。 因为它们对关系给予了高度重视，所以图形数据库（如FlockDB，Neo4J和Polyglot）已经证明可以用于构建社交网络和语义Web应用程序。

• 对象数据库

  对象数据库不是根据关系，列和行来存储数据，而是根据对象本身，使得从面向对象的应用程序中使用数据库变得简单。 db4o和InterSystemsCaché等对象数据库允许您避免使用存储过程和对象关系映射（ORM）工具等技术。

• XML数据库

  XML数据库是一种特殊形式的文档数据库，专门用于处理XML。 所谓的“XML原生”数据库包括Software AG和eXist的Tamino。

有关NoSQL数据库的完整列表，请访问网站http://nosql-database.org。

这些数据库的目标和功能有很多种，但它们往往具有一系列共同特征。其中最明显的是NoSQL这个名称 - 这些数据库支持数据模型，数据定义语言（DDL）以及流行关系数据库中可用的标准SQL之外的接口。此外，这些数据库通常是没有集中控制的分布式系统。它们强调水平可伸缩性和高可用性，在某些情况下以强一致性和ACID语义为代价。它们倾向于支持快速开发和部署。他们采用灵活的方法来定义模式，在某些情况下不需要预先定义任何模式。它们为大数据和分析用例提供支持。

在过去几年中，NoSQL领域出现了大量的开源和商业产品。它们的采用和质量差异很大，但领导者已经出现在刚刚讨论的类别中，并且许多已经成为具有大型安装基础和商业支持的成熟技术。我们很高兴地报告Cassandra是这些技术之一，我们将在下一章深入探讨。

总结

在过去的四十年中，关系模型为软件行业提供了良好的服务，但现代应用程序所需的可用性和可扩展性水平已将关系数据库技术扩展到了突破点。

本书的目的不是通过巧妙的论证来说服您采用Apache Cassandra等非关系型数据库。 我们只是想介绍一下Cassandra可以做什么以及它如何做到这一点，这样你就可以做出明智的决定，并且如果你发现它适用，就可以开始以实际的方式使用它。

那么，也许最终的问题不是“关系数据库有什么问题？”而是“如果不是问题，我会对数据做什么样的事情呢？”在一个现在正在网络规模工作并期待 未来，Apache Cassandra可能是答案的一部分。