第二章：Cassandra介绍--Cassandra：The Definitive Guide 2nd Edition

最新推荐文章于 2022-12-06 21:21:59 发布

sunchengquan

最新推荐文章于 2022-12-06 21:21:59 发布

阅读量645

点赞数

分类专栏： Cassandra

Cassandra 专栏收录该内容

14 篇文章 12 订阅

订阅专栏

在上一章中，我们讨论了非关系数据库技术的出现，以满足现代Web规模应用不断增长的需求。在本章中，我们将重点介绍Cassandra的价值主张和关键原则，以展示它如何应对挑战。您还将了解Cassandra的历史以及如何参与维护Cassandra的开源社区。

Cassandra 的主要特点

经常建议好莱坞编剧和软件初创公司准备好“Elevator Pitch”。这是对他们的产品究竟是什么的简要概述 - 简洁，清晰，简洁，足以在一两分钟内交付，幸运的是，他们发现自己与行政人员，代理人或投资者分享电梯考虑资助他们的项目。 Cassandra有一个令人信服的故事，所以让我们把它归结为一个“Elevator Pitch”，如果出现这种情况，你可以提交给你的经理或同事。

电梯法则，即用极具吸引力的方式简明扼要地阐述自己的观点。也被称为电梯游说（Elevator pitch），例如你在电梯里，只有30秒的时间来向一位关系公司前途的大客户推广产品且必须成功。

50字或更少

“Apache Cassandra是一个开源，分布式，分散，弹性可扩展，高可用性，容错，可调整，面向行的数据库，其分布式设计基于亚马逊的Dynamo及其数据模型在Google的Bigtable上。它创建于Facebook，现在用于网络上一些最受欢迎的网站。“这正好是50个单词。

当然，如果你在电梯里向老板背诵，你可能会得到一个空白的回报。因此，让我们分解以下各节中的要点。

分布式和分散式

Cassandra是分布式的，这意味着它能够在多台机器上运行，同时作为一个统一的整体出现在用户身上。事实上，运行单个Cassandra节点没有什么意义。虽然你可以做到这一点，并且为了快速了解它的工作方式，但你很快意识到你需要多台机器来真正实现运行Cassandra的任何好处。它的大部分设计和代码基础都是专门设计的，不仅可以在多台不同的机器上运行，而且可以优化多个数据中心机架的性能，甚至可以在跨地理位置分散的数据中心运行的单个Cassandra集群。您可以放心地将数据写入集群中的任何位置，而Cassandra将获得它。

一旦开始扩展许多其他数据存储（MySQL，Bigtable），就需要将一些节点设置为主节点，以便组织其他节点，这些节点被设置为从属节点。然而，Cassandra是分散的，意味着每个节点都是相同的;没有Cassandra节点执行与任何其他节点不同的某些组织操作。相反，Cassandra采用点对点协议，并使用八卦来维护并保持活跃或死亡的节点列表。

Cassandra分散的事实意味着没有单一的失败点。 Cassandra集群中的所有节点功能完全相同。这有时被称为“服务器对称性”。因为它们都在做同样的事情，根据定义，不能有一个特殊的主机协调活动，就像你在MySQL中看到的主/从设置一样，Bigtable，还有很多其他人。

在许多分布式数据解决方案（例如RDBMS群集）中，您在称为复制的过程中在不同服务器上设置多个数据副本，该过程将数据复制到多台计算机，以便它们可以同时处理请求并提高性能。通常，此过程不像Cassandra那样是分散的，而是通过定义主/从关系来执行。也就是说，这种集群中的所有服务器都不以相同的方式运行。通过将一个服务器指定为主服务器而将其他服务器指定为从服务器来配置群集。主设备充当数据的权威来源，并与从节点以单向关系运行，从节点必须同步其副本。如果主节点出现故障，则整个数据库都处于危险之中。因此，分散式设计是Cassandra高可用性的关键之一。请注意，虽然我们经常了解RDBMS世界中的主/从复制，但是有一些NoSQL数据库（如MongoDB）也遵循主/从方案。

因此，权力下放有两个关键优势：它比主/从更简单，它可以帮助您避免中断。由于所有节点都相同，因此操作和维护分散存储比主/从存储更容易。这意味着你不需要任何特殊的知识来扩展; 设置50个节点与设置一个节点差别不大。接下来没有配置支持它。此外，在主/从设置中，主设备可以成为单点故障（SPOF）。为避免这种情况，您经常需要以多个主服务器的形式为环境添加一些复杂性。由于Cassandra中的所有副本都是相同的，因此节点的故障不会中断服务。

简而言之，因为Cassandra是分布式和分散式的，所以没有单点故障，它支持高可用性。弹性

可扩展性

可伸缩性是系统的体系结构特性，可以继续提供大量请求，而性能几乎不会降低。垂直扩展 - 只需为现有机器添加更多硬件容量和内存 - 是实现这一目标的最简单方法。水平扩展意味着添加更多具有全部或部分数据的计算机，这样任何一台计算机都不必承担服务请求的全部负担。但是，软件本身必须具有内部机制，以使其数据与群集中的其他节点保持同步。

弹性可伸缩性是指水平可伸缩性的特殊属性。这意味着您的群集可以无缝扩展和缩小。为此，群集必须能够通过获取部分或全部数据的副本来接受可以开始参与的新节点，并开始提供新的用户请求，而不会对整个群集造成重大中断或重新配置。您不必重新启动您的流程。您不必更改应用程序查询。您不必自己手动重新平衡数据。只需添加另一台机器 - Cassandra会找到它并开始发送它的工作。

当然，缩小意味着从群集中删除一些处理能力。您可能出于商业原因这样做，例如调整零售或旅行应用程序中的季节性工作负载。或者可能存在技术原因，例如将应用程序的部分移动到另一个平台。尽管我们试图最小化这些情况，但它们仍然会发生。但是当他们这样做时，你不需要打乱整个苹果车来缩小规模。

高可用性和容错

在一般架构术语中，系统的可用性是根据其满足请求的能力来测量的。但计算机可能会遇到各种故障，从硬件组件故障到网络中断再到损坏。任何计算机都容易受到这类故障的影响。当然，非常复杂（通常非常昂贵）的计算机本身可以缓解许多这样的情况，因为它们包括内部硬件冗余和发送故障事件通知和热插拔组件的工具。但任何人都可能意外断开以太网电缆，灾难性事件可能会导致单个数据中心出现问题。因此，对于高度可用的系统，它通常必须包括多个联网计算机，并且它们运行的软件必须能够在集群中运行，并且具有一些用于识别节点故障并将请求故障转移到另一部分的设施。系统。

Cassandra高可用。您可以在没有停机的情况下替换群集中的故障节点，并且可以将数据复制到多个数据中心，以提供改进的本地性能，并防止在一个数据中心遇到火灾或洪水等灾难时停机。

可调整的一致性

一致性本质上意味着读取总是返回最近写入的值。考虑两个客户正试图将相同的商品放入电子商务网站的购物车中。如果我在您做完后立即将最后一件商品放入我的购物车，您应该将商品添加到购物车中，并且我会被告知该商品已无法再购买。当写入状态在具有该数据的所有节点之间保持一致时，保证会发生这种情况。

但正如我们稍后将看到的，扩展数据存储意味着在数据一致性，节点可用性和分区容差之间进行一些权衡。卡桑德拉经常被称为“最终一致”，这有点误导。开箱即用，Cassandra交换一些一致性以实现总体可用性。但Cassandra更准确地称为“可调整一致”，这意味着它可以让您轻松确定所需的一致性级别，并与可用性水平保持平衡。

让我们花点时间解开这个问题，因为“最终的一致性”一词在业界引起了一些骚动。一些从业者对使用被描述为“最终一致”的系统犹豫不决。

对于最终一致性的批评者，广泛的论点是这样的：对于数据无关紧要的社交网络应用程序，最终的一致性可能是正常的。毕竟，你只是向妈妈张贴了小比利早餐吃的东西，如果它丢失了，那真的不重要。但是我拥有的数据实际上非常重要，认为我可以在模型中保持最终的一致性是荒谬的。

撇开所有最受欢迎的网络应用程序（亚马逊，Facebook，谷歌，Twitter）正在使用这个模型的事实，也许它有一些东西。据推测，这些数据对运行这些应用程序的公司来说非常重要，因为这些数据是他们的主要产品，而且它们是数十亿美元的公司，拥有数十亿用户，可以在竞争激烈的世界中满足。在各种网络上并行运行的高流量系统中，有可能获得保证，即时和完美的一致性，但如果您希望客户在今年某个时间获得结果，那么这是一个非常棘手的主张。

批评者声称，一些大数据数据库（如Cassandra）只具有最终的一致性，并且所有其他分布式系统都具有严格的一致性。然而，正如世界上许多事物一样，现实并非如此黑白分明，一致与不一致之间的二元对立并未真正反映在实践中。相反，它具有一致性程度，在现实世界中，它们非常容易受到外部环境的影响。

最终的一致性是架构师可用的几种一致性模型之一。让我们来看看这些模型，以便我们理解权衡：

严格的一致性

这有时称为顺序一致性，并且是最严格的一致性级别。它要求任何读取始终返回最近写入的值。这听起来很完美，而且正是我正在寻找的。我要买它！但仔细研究后，我们发现了什么？究竟是什么意思是“最近写的”？最近给谁？在一个单处理器机器中，这没有问题需要观察，因为一个时钟已知操作顺序。但是，在跨越各种地理位置分散的数据中心执行的系统中，它变得更加滑溜。实现这一点意味着某种全局时钟能够为所有操作加时间戳，无论数据的位置或请求它的用户，或者确定响应需要多少（可能是不同的）服务。

因果一致性

这是一种稍微弱一点的严格一致性。它消除了单个全局时钟的幻想，它可以神奇地同步所有操作，而不会产生无法忍受的瓶颈。而不是依赖于时间戳，因果一致性而是采用更加语义的方法，尝试确定事件的原因以在它们的顺序中创建一些一致性。这意味着必须按顺序读取可能相关的写入。如果两个不同的，不相关的操作突然写入同一字段，则推断这些写入不是因果关系。但如果一次写入发生在另一次之后，我们可能会推断出它们是因果关联的。因果一致性要求必须按顺序读取因果写入。

弱（最终）一致性

 最终的一致性意味着表面上所有更新都将在分布式系统中的所有副本中传播，但这可能需要一些时间。 最终，所有副本都将保持一致。

当您考虑实现更强一致形式所需的条件时，最终的一致性会突然变得非常有吸引力。

在考虑一致性，可用性和分区容差时，我们在给定的分布式系统中只能实现其中两个目标，这种权衡被称为CAP定理（我们在“Brewer的CAP定理”中更深入地探讨了这个定理）。问题的核心是数据更新复制。为了实现严格的一致性，所有更新操作将同步执行，这意味着它们必须阻止，锁定所有副本直到操作完成，并强制竞争客户端等待。这种设计的副作用是在故障期间，一些数据将完全不可用。正如亚马逊首席技术官Werner Vogels所说，“而不是处理答案正确性的不确定性，数据在完全确定它是正确的之前是不可用的。”1

我们也可以采取乐观的复制方法，在后台传播所有副本的更新，以避免在客户端上爆炸。这种方法的难点在于，现在我们被迫陷入了发现和解决冲突的境地。设计方法必须决定是否在两个可能的时间之一解决这些冲突：读取期间或写入期间。也就是说，分布式数据库设计者必须选择使系统始终可读或始终可写。

Dynamo和Cassandra选择始终可写，选择将协调的复杂性推迟到读取操作，并实现巨大的性能提升。另一种方法是拒绝网络和服务器故障中的更新。

在Cassandra中，一致性不是一个全有或全无的命题。我们可以更准确地将其称为“可调整一致性”，因为客户端可以控制要阻止所有更新的副本数量。这是通过将一致性级别设置为复制因子来完成的。

通过复制因子，您可以决定要在性能上支付多少以获得更高的一致性。您可以将复制因子设置为希望更新传播到的群集中的节点数（请记住，更新意味着任何添加，更新或删除操作）。

一致性级别是客户端必须在每个操作上指定的设置，并且允许您决定群集中必须确认写入操作或响应读取操作以便被视为成功的副本数量。这就是Cassandra推动决定客户端一致性的决定。

因此，如果您愿意，可以将一致性级别设置为等于复制因子的数字，并以等待所有节点更新并在返回之前声明成功的同步阻塞操作为代价获得更强的一致性。然而，这通常不会在Cassandra的实践中完成，原因应该是明确的（它会破坏可用性目标，会影响性能，并且通常与您最初想要使用Cassandra的原因背道而驰）。因此，如果客户端将一致性级别设置为小于复制因子的值，则即使某些节点关闭，也会认为更新成功。

布鲁尔的CAP定理

为了理解Cassandra的设计及其作为“最终一致”数据库的标签，我们需要理解CAP定理。 CAP定理有时被称为Brewer定理，其作者是Eric Brewer。

在加州大学伯克利分校工作期间，Eric Brewer于2000年在ACM分布式计算原理研讨会上提出了他的CAP定理。该定理指出，在大规模分布式数据系统中，有三个要求具有滑动依赖关系：

一致性

 即使给定并发更新，所有数据库客户端也将为同一查询读取相同的值。

可用性

 所有数据库客户端始终能够读取和写入数据。

分区容差

数据库可以拆分成多台机器;它可以在网络分段中断时继续运行。

布鲁尔定理是，在任何给定的系统中，你只能强烈支持三者中的两个。这类似于你在软件开发中可能听到的说法：“你可以把它变好，你可以快速拥有它，你可以把它变得便宜：选择两个。”

由于这种滑动的相互依赖性，我们必须在它们之间做出选择您需要从系统中获得更高的一致性，例如，您可能能够实现的分区容忍度越低，除非您对可用性做出一些让步。

2002年麻省理工学院的Seth Gilbert和Nancy Lynch正式证明CAP定理是真实的。然而，在分布式系统中，你很可能会进行网络分区，并且在某些时候，机器会失败并导致其他人变得无法到达。丢包或高延迟等网络问题几乎是不可避免的，有可能导致临时分区。这使我们得出这样的结论：分布式系统必须尽最大努力继续在网络分区（分区容忍）的情况下运行，只留下两个真正的选择：可用性和一致性。

图2-1直观地说明没有重叠的部分可以获得所有三个部分。

在这里插入图片描述

在这一点上可能证明有用的是看到我们将看到的每个非关系数据存储在何处落在CAP频谱内的图形描述。图2-2中的图形灵感来自于MongoDB的首席执行官兼创始人Dwight Merriman在纽约市MySQL用户组的2009年演讲中的幻灯片。但是，我们已经根据研究修改了一些系统的位置。

在这里插入图片描述

图2-2显示了我们在本章中讨论的一些不同数据库的一般焦点。请注意，此图表中数据库的放置可能会根据配置而更改。正如Stu Hood所指出的，只有当你使用谷歌的同步复制补丁时，分布式MySQL数据库才能算作一致的系统;否则，它只能是可用的和分区容错的（AP）。

值得注意的是，围绕CAP布局的系统设计与数据存储机制的方向无关;例如，CP边缘由图形数据库和面向文档的数据库填充。

在此描述中，关系数据库处于一致性和可用性之间，这意味着它们可能在网络发生故障（包括断线）时发生故障。这通常通过定义单个主服务器来实现，该主服务器本身可能会停机，或者服务器阵列中没有内置足够的机制以在网络分区的情况下继续运行。

图形数据库（如Neo4J）和至少部分源自Google Bigtable数据库（如MongoDB，HBase，Hypertable和Redis）设计的数据库集合都略微偏向于可用性，而更多地关注于确保一致性和分区容错。

最后，源自亚马逊Dynamo设计的数据库包括Cassandra，Project Voldemort，CouchDB和Riak。这些更侧重于可用性和分区容错。然而，这并不意味着他们将一致性视为不重要，而不是Bigtable驳回可用性。根据Bigtable论文，“某些数据”不可用的服务器小时数的平均百分比是0.0047％（第4节），所以这是相对的，因为我们已经讨论过非常强大的系统。如果您将这些字母（C，A，P）中的每一个都视为旋钮，您可以调整以达到您想要的系统，Dynamo衍生产品可用于许多使用情况，其中“最终一致性”是可以容忍的，并且“最终” “只需几毫秒，读取修复意味着读取将返回一致的值，如果您愿意，可以实现强一致性。

那么实际上，仅支持CAP三个方面中的两个方面意味着什么呢？

主要支持一致性和可用性意味着您可能使用两阶段提交进行分布式事务。这意味着系统将在网络分区发生时阻塞，因此可能是您的系统仅限于单个数据中心群集以尝试缓解此问题。如果您的应用程序只需要这种级别的规模，这很容易管理，并允许您依赖熟悉，简单的结构。

要主要支持一致性和分区容错，您可以尝试通过设置数据分片来扩展您的体系结构以进行扩展。您的数据将保持一致，但如果节点出现故障，您仍然可能会遇到某些数据不可用的风险。

要主要支持可用性和分区容差，您的系统可能会返回不准确的数据，但即使面对网络分区，系统也始终可用。 DNS可能是大规模可扩展，高可用性和分区容错的系统中最流行的示例。

请注意，此描述旨在提供有助于区分这些系统中更广泛轮廓的概述; 它不是严格精确的。例如，谷歌的Bigtable应该放在这样一个连续统一体的地方并不完全清楚。 Google论文将Bigtable描述为“高度可用”，但后来接着说，如果Chubby（Bigtable持久锁定服务）“长时间不可用[由Chubby中断或网络问题引起]，Bigtable就会变得不可用” （第4条）。关于数据读取问题，该论文称“我们不考虑同一数据的多个副本的可能性，可能是由于视图或索引的替代形式。”最后，本文指出“集中控制和拜占庭容错” 不是Bigtable的目标“（第10条）。鉴于此类可变信息，您可以看到确定数据库在此滑动范围内的位置并不是一门精确的科学。

关于CAP的更新观点

2012年2月，Eric Brewer在IEEE计算机的文章“CAP十二年后：'规则’如何改变”一文中提供了他的CAP定理的最新观点。布鲁尔现在将“2中3”公理描述为有些误导。他指出，设计人员只需要在存在分区时牺牲一致性或可用性，并且分区恢复技术的进步使设计人员可以实现高水平的一致性和可用性。

分区恢复的这些进步当然会包括Cassandra对暗示切换和读取修复等机制的使用。我们将在第6章中探讨这些。但是，重要的是要认识到这些分区恢复机制并非绝对可靠。 Cassandra的可调整性仍然具有巨大价值，使Cassandra能够在多种部署中有效运行，在这些部署中无法完全阻止分区。

面向行的

Cassandra的数据模型可以描述为分区行存储，其中数据存储在稀疏的多维哈希表中。 “稀疏”意味着对于任何给定的行，您可以有一个或多个列，但每行不需要像其他行一样具有所有相同的列（如在关系模型中）。 “分区”表示每行都有一个唯一的密钥，可以访问其数据，密钥用于在多个数据存储中分配行。

面向行的Vs面向列

Cassandra经常被称为“面向列的”数据库，事实证明这是一些混乱的根源。面向列的数据库是指按列实际存储数据的数据库，而不是将数据存储在行中的关系数据库。分类数据库时出现的部分混淆是数据库公开的API与磁盘上的底层存储之间可能存在差异。所以Cassandra并不是真正面向列的，因为它的数据存储不是主要围绕列组织的。

在关系存储模型中，预先定义表的所有列，并为每个列分配空间，无论是否填充。相比之下，Cassandra将数据存储在多维排序的哈希表中。由于数据存储在每列中，因此它将作为单独的条目存储在哈希表中。列值按照一致的排序顺序存储，省略未填充的列，从而实现更高效的存储和查询处理。我们将在第4章中更详细地研究Cassandra的数据模型。

Cassandra是“Schema-Free”吗？

在其早期版本中。 Cassandra忠实于原始的Bigtable白皮书，支持“无模式”数据模型，其中可以动态定义新列。无模式数据库（如Bigtable和MongoDB）具有在访问大量数据时具有高度可扩展性和高性能的优势。无模式数据库的主要缺点是难以确定数据的含义和格式，这限制了执行复杂查询的能力。这些缺点被证明是许多人采用的障碍，特别是当初始灵活性受益于初始灵活性的初创项目成熟为涉及多个开发人员和管理员的更复杂的企业。

这些用户的解决方案是引入了Cassandra查询语言（CQL），它提供了一种通过类似于来自关系背景的结构化查询语言（SQL）的语法来定义模式的方法。最初，CQL是作为Cassandra的另一个接口以及基于Apache Thrift项目的无架构接口提供的。在此过渡阶段，术语“模式可选”用于描述数据模型可以使用CQL通过模式定义，但也可以动态扩展以通过Thrift API添加新列。在此期间，基础数据存储继续基于Bigtable模型。

从3.0版本开始，不推荐使用支持动态列创建的基于Thrift的API，并且已经重新实现了Cassandra的底层存储以更紧密地与CQL保持一致。 Cassandra并没有完全限制动态扩展架构的能力，但它的工作方式却截然不同。 CQL集合（如列表，集合，尤其是映射）提供了以较不结构化的形式添加内容的功能，可以利用它来扩展现有模式。 CQL还提供了在某些实例中更改列类型的功能，以及支持存储JSON格式文本的工具。

因此，描述Cassandra当前姿势的最佳方式可能是它支持“灵活的架构”。

高性能

Cassandra专门从头开始设计，以充分利用多处理器/多核机器，并运行在多个数据中心内的许多这些机器。它可以持续无缝地扩展到数百TB。 Cassandra在重负荷下表现出色。它始终能够在基本商用计算机（无论是物理硬件还是虚拟机）上显示非常快的每秒写入吞吐量。随着您添加更多服务器，您可以在不牺牲性能的情况下维护所有Cassandra所需的属性。

Cassandra来自哪里？

Cassandra数据存储是一个开源的Apache项目。 Cassandra于2007年在Facebook发起解决其收件箱搜索问题 - 该公司不得不以传统方法难以扩展的方式处理大量数据。具体而言，该团队有要求以消息副本，消息的反向索引以及许多随机读取和许多同时随机写入的形式处理大量数据。

该团队由Jeff Hammerbacher领导，Avinash Lakshman，Karthik Ranganathan和Facebook工程师在搜索团队Prashant Malik担任主要工程师。该代码于2008年7月作为开源Google Code项目发布。在2008年作为Google Code项目任职期间，该代码只能由Facebook工程师更新，因此围绕它构建的社区很少。所以在2009年3月，它被转移到Apache孵化器项目，并在2010年2月17日，它被投票成一个顶级项目。在Apache Cassandra Wiki上，您可以找到提交者列表，其中许多人自2010/2011年以来一直参与该项目。提交者代表公司，包括Twitter，LinkedIn，Apple，以及独立开发者。

向全世界介绍卡桑德拉的论文

Facebook的Lakshman和Malik的“分散式结构化存储系统”是Cassandra的中心报纸。 Jonathan Ellis对应于2.0版本提供了本文的更新评论，注意到自从向Apache过渡以来对该技术的更改。我们将在“发布历史记录”中更详细地解压缩其中的一些更改。

卡桑德拉是如何得名的？

在希腊神话中，卡桑德拉是特鲁伊国王普里亚姆和女王赫库巴的女儿。卡珊德拉非常漂亮，阿波罗神让她有能力看到未来。但是，当她拒绝了他多情的进展时，他诅咒她，使她仍然能够准确预测所有可能发生的事情 - 但没有人会相信她。卡桑德拉预见到了她的特洛伊城的毁灭，但无法阻止它。 Cassandra分布式数据库以她的名字命名。我们推测它也被称为Delphi上甲骨文的一个笑话，这是另一个为数据库命名的先知。

随着对Cassandra的商业兴趣的增长，对生产支持的需求变得明显。 Cassandra的Apache项目主席Jonathan Ellis和他的同事Matt Pfeil于2010年4月成立了一家名为DataStax（最初称为Riptano）的服务公司.DataStax为Cassandra项目提供领导和支持，雇用了几名Cassandra提交者。

DataStax提供免费产品，包括用于各种语言的Cassandra驱动程序以及用于开发和管理Cassandra的工具。付费产品包括Cassandra服务器和工具的企业版，与其他数据技术的集成以及产品支持。与其他一些具有商业支持的开源项目不同，更改首先添加到Apache开源项目，然后在每次Apache发布后不久就进入商业产品。

DataStax还提供Planet Cassandra网站作为Cassandra社区的资源。该网站是了解不断增长的在工业和学术界使用Cassandra的公司和组织名单的绝佳位置。代表的行业涉及的范围很广：金融服务，电信，教育，社交媒体，娱乐，营销，零售，酒店，运输，医疗保健，能源，慈善，航空航天，国防和技术。您可能会在这里找到一些与您的需求相关的案例研究。

发布历史

既然我们已经了解了塑造Cassandra的人和组织，那么让我们来看看Cassandra自成为官方Apache项目以来如何通过其各种版本成熟。如果您是Cassandra的新手，请不要担心这些概念和术语中的一些对您来说是否是新的 - 我们将在适当的时候更深入地深入研究它们。您可以稍后返回此列表，以了解Cassandra随着时间的推移及其未来发展方向的成熟轨迹。如果您以前使用过Cassandra，本摘要将为您提供有关更改内容的快速入门。

性能和可靠性改进

此列表主要关注在Cassandra的生命周期中添加的功能。这并不是对可靠性和读/写性能的稳定和实质性改进的折扣。

发布0.6

这是Cassandra从Apache孵化器毕业后进入顶级项目的第一个版本。本系列的发布从2010年4月的0.6.0到2011年4月的0.6.13。本系列的特色包括：

    与Apache Hadoop集成，允许通过MapReduce从Cassandra轻松检索数据
    集成的行缓存，有助于消除应用程序与Cassandra一起部署其他缓存技术的需要

发布0.7

本系列的发布从2011年1月的0.7.0到2011年10月的0.7.10。主要功能和改进包括：

    辅助索引 - 即非主列上的索引
    支持包含多达20亿列的大行
    在线模式更改，包括通过Thrift API添加，重命名和删除实时集群中的键空间和列系列而无需重新启动
    通过每列的生存时间（TTL）规范使列到期
    引入NetworkTopologyStrategy以支持多数据中心部署，每个密钥空间允许每个数据中心单独的复制因子
    配置文件从XML转换为更易读的YAML格式

发布0.8

随着CQL的引入，这个版本开始了Cassandra API的重大转变。本系列的发布从2011年6月的0.8.0到2012年2月的0.8.10。主要功能和改进包括：

    分布式计数器作为新数据类型添加，逐步递增计数
    引入了sstableloader工具以支持将数据批量加载到Cassandra集群中
    提供了一个堆外行缓存，以允许使用本机内存而不是JVM堆
    并发压缩允许SSTable压缩的多线程执行和限制控制
    改进的内存配置参数允许更灵活地控制memtables的大小

发布1.0

为了与常见的版本编号实践保持一致，这正式是Cassandra的第一个生产版本，尽管许多公司在此之前都在使用Cassandra。本系列的发布从2011年10月的1.0.0到2012年10月的1.0.12。为了保持对生产准备的关注，改进的重点是性能和现有功能的增强：

    CQL 2增加了一些改进，包括改变表和列的能力，支持计数器和TTL，以及检索与查询匹配的项目数的能力
    引入了级别压缩策略作为原始大小分层压缩策略的替代方案，允许更快的读取，代价是写入时的更多I / O
    压缩SSTable文件，可在每个表级别进行配置

版本1.1

本系列的发布从2011年4月的1.1.0到2013年5月的1.1.12。主要功能和改进包括：

    CQL 3添加了timeuuid类型，以及使用复合主键（包括群集键）创建表的功能。群集键支持“order by”语义以允许排序。这是一个备受期待的功能，允许通过CQL创建“宽行”。
    支持通过cqlsh导入和导出逗号分隔值（CSV）文件
    灵活的数据存储设置允许在SSD或磁存储中存储数据，可通过表格进行选择
    重新实现了模式更新机制，以允许并发更改并提高可靠性。模式现在存储在系统键空间的表中。
    更新缓存以提供更简单的缓存大小配置
    一个利用Hadoop批量加载器的实用程序，允许从Hadoop到Cassandra的高效数据导出
    添加了行级隔离以确保在写入时更新多个列时，读取不可能混合使用新旧列值

1.2版

本系列的发布时间为2013年1月的1.2.0至2014年9月的1.2.19。显着的功能和改进包括：

    CQL 3添加了集合类型（集合，列表和映射），预处理语句和二进制协议，以替代Thrift
    虚拟节点在群集中的节点之间更均匀地分布数据，从而提高性能，尤其是在添加或替换节点时
    原子批次确保批处理中的所有写入作为一个单元成功或失败
    系统密钥空间包含本地表，该表包含有关本地节点的信息以及描述集群中其他节点的对等表
    可以启用请求跟踪，以允许客户端查看节点之间的读取和写入交互。跟踪提供有价值的洞察力，可以帮助开发人员了解各种表格设计选项的含义。
    大多数数据结构都从JVM堆移到本机内存
    磁盘故障策略允许灵活配置行为，包括在磁盘故障时从群集中删除节点或尽最大努力从内存中访问数据，即使是陈旧的

发布2.0

2.0版本是Cassandra历史上一个特别重要的里程碑，因为它标志着CQL能力的高潮，以及新的生产成熟度水平。这包括显着的性能改进和清理代码库以偿还5年累积的技术债务。本系列的发布从2013年9月的2.0.0到2015年6月的2.0.16。亮点包括：

    使用Paxos共识协议添加轻量级交易
    CQL3改进包括在ALTER命令上添加DROP语义，条件模式修改（IF EXISTS，IF NOT EXISTS），以及在主键列上创建二级索引的能力
    原生CQL协议的改进开始使CQL比Thrift更具性能
    添加了触发器的原型实现，提供了一种对写入操作作出反应的可扩展方法。触发器可以用任何JVM语言实现。
    Java 7是第一次需要
    在2.0.6版本中添加了静态列

版本2.1

本系列的发布时间为2014年9月的2.1.0至2015年6月的2.1.8。主要功能和改进包括：

    CQL3添加了用户定义类型（UDT），以及在集合上创建二级索引的功能
    添加了配置选项以将可记忆数据从堆移动到本机内存
    行缓存更加可配置，以允许设置每个分区的缓存行数
    重新实施了计数器以提高性能和可靠性

2.2版

Cassandra开发人员概述的原始发布计划未包含2.2版本。目的是为3.0版本的3.0版本做一些主要的“幕后”返工。但是，由于所涉及的更改的数量和复杂性，决定分别发布一些已完成的功能，以使它们可用，同时允许一些更复杂的更改时间成熟。版本2.2.0于2015年7月推出，支持版本计划于2016年秋季发布。本系列的显着特性和改进包括：

    CQL3改进，包括对JSON格式输入/输出和用户定义函数的支持
    在此版本中，Windows成为完全支持的操作系统。尽管Cassandra在Linux系统上表现最佳，但文件I / O和脚本的改进使得在Windows上运行Cassandra变得更加容易。
    引入日期分层压缩策略（DTCS）以提高时间序列数据的性能
    引入了基于角色的访问控制（RBAC），以允许更灵活的授权管理

Tick-Tock发布
2015年6月，Cassandra团队宣布计划采用tick-tock发布模式，作为更加注重提高敏捷性和发布质量的一部分。

英特尔推广的tick-tock发布模型最初用于芯片设计，并提到了替代版本中不断变化的芯片架构和生产流程。您可以在http://www.intel.com/content/www/us/en/silicon-innovations/intel-tick-tock-model-general.html 上阅读有关此方法的更多信息。

事实证明，tick-tock方法在软件开发中也很有用。从Cassandra 3.0版本开始，偶数版本是功能版本，其中包含一些错误修复，而奇数版本则专注于修复错误，目标是每个月发布一次。

3.0版（功能发布 - 2015年11月）

    重写底层存储引擎以更接近地匹配CQL构造
    增加了对物化视图（有时也称为全局索引）的支持
    Java 8现在是受支持的版本
    基于Thrift的命令行界面（CLI）已删除

3.1版（Bug修复版 - 2015年12月）
版本3.2（功能发布 - 2016年1月）

    Cassandra在“只是一堆磁盘”或JBOD配置中跨多个磁盘分配SSTable文件存储的方式被重新设计，以提高可靠性和性能，并启用单个磁盘的备份和恢复
    添加了压缩和加密提示的功能

版本3.3（错误修复版本 - 2016年2月）
3.4版（功能发布 - 2016年3月）

    SSTableAttachedSecondaryIndex（简称“SASI”）是Cassandra的SecondaryIndex接口的实现，可以用作现有实现的替代方案。

版本3.5（错误修复版本 - 2016年4月）

4.0版本系列计划于2016年秋季开始。

您会注意到，这些版本的趋势包括：

持续改进CQL的功能
越来越多的流行语言客户端基于一组共同的隐喻构建
暴露配置选项以调整性能并优化资源使用
提高性能和可靠性，减少技术债务

支持的版本

任何时候都有两个官方支持的Cassandra版本：最新的稳定版本，适合生产，以及最新的开发版本。您可以在项目的下载页面上看到官方支持的版本。

强烈建议Cassandra的用户跟踪生产中的最新稳定版本。有趣的是，发布到Cassandra用户电子邮件列表的绝大多数问题和问题都与不再受支持的版本有关。 Cassandra专家非常慷慨地回答问题并诊断这些不受支持的版本的问题，但通常建议尽快升级到解决问题的版本。

Cassandra是否适合我的项目？

我们现在已经了解了Cassandra的优势。尽管Cassandra的设计精巧，功能强大，但它并不适合各种工作。因此，在本节中，让我们快速了解一下Cassandra适合的项目类型。

大型部署

你可能不会开一个semitruck去拿干洗;半成品不适合这种任务。 Cassandra的高可用性，可调谐一致性，点对点协议和无缝扩展已经成为其主要卖点。在单节点部署中，这些特性都没有意义，更不用说让它们充分发挥其潜力。

但是，存在各种各样的情况，其中我们可能需要单节点关系数据库。做一些测量。考虑您的预期流量，吞吐量需求和SLA。这里没有严格的规则，但如果您希望只使用少量关系数据库就可以可靠地提供具有可接受性能水平的流量，那么这样做可能是更好的选择，因为RDBMS更容易在一台机器上运行，更熟悉。

但是，如果您认为至少需要几个节点来支持您的努力，那么Cassandra可能是个不错的选择。如果您的应用程序需要几十个节点，那么Cassandra可能非常适合。

大量的写作，统计和分析

从读取与写入的比率的角度考虑您的应用程序。 Cassandra针对写入时的出色吞吐量进行了优化。

Cassandra的许多早期生产部署涉及存储用户活动更新，社交网络使用，推荐/评论和应用程序统计信息。这些是Cassandra的强大用例，因为它们涉及大量写入，具有较少的可预测读取操作，并且因为突然出现峰值时更新可能不均匀。实际上，处理需要在具有许多并发客户端线程的大量写入卷时具有高性能的应用程序工作负载的能力是Cassandra的主要功能之一。

根据项目维基，Cassandra已被用于创建各种应用程序，包括窗口化的时间序列存储，用于文档搜索的倒排索引和分布式作业优先级队列。