多年来，我使用的大多数后端系统在某些角色上都使用了关系数据库存储。 尽管许多应用程序开发人员抱怨RDBMS性能，但我发现，通过良好的设计和实现，关系数据库实际上可以比开发人员想象的扩展得多。 即使实际上根本原因可以归结为不良的设计和实现，但实际上并不真正了解关系数据库的软件开发人员往往将其归咎于数据库是性能瓶颈。
也就是说，RDBMS可伸缩性受到限制，并且在处理大量事务和数据时可能会成为一个严重的问题。 常见的解决方法是根据选定的标准（功能区域和/或功能区域内实体的选定属性）对应用程序数据进行分区，然后在数据库服务器节点之间分配数据。 这种划分通常必须以放松一致性为代价。 还有很多其他用例，它们对于一般的关系数据库或可供您使用的关系数据库并非没有问题。
有时即使使用关系型数据库进行较小规模的扩展，负载平衡和故障转移有时也很难实现，尤其是在您没有许可使用商业数据库集群选项的选项的情况下。 即使可以，可伸缩性也受到限制。 人们倾向于使用主从数据库配置解决这些问题，但是可能很难设置和管理它们。 如果主从复制不是同步的（通常是这种情况），则这种配置也会影响数据的一致性。
当应用程序还需要动态或开放式数据模型时，人们通常会开始研究NoSQL存储解决方案。
这是我目前正在从事的项目的设计推理的路径。 我在开发项目中使用Apache Cassandra（v1.2）已有几个月了。 NoSQL数据库的形式非常不同，Cassandra通常被称为“面向列”或“宽行”数据库。 通过引入Cassandra查询语言（CQL），Cassandra现在支持声明模式和为数据模型进行键入。 对于应用程序开发人员而言，此功能使Cassandra数据模型更接近关系（关系和元组）模型。
NoSQL设计目标和CAP定理
NoSQL和关系数据库具有非常不同的设计目标。 对于应用程序开发人员来说，理解这些目标很重要，因为在实践中，它们指导和指示了可行的产品功能集。
ACID交易保证提供了一个强大的一致性模型，传统上围绕该模型设计了Web应用程序。 在构建Internet规模的系统时，开发人员开始意识到，强大的一致性保证是有代价的。 这是用Brewer的CAP定理表示的，该定理最初的形式表明分布式系统只能实现以下两个属性：
- 一致性（C）等同于拥有单个最新数据副本；
- 该数据的高可用性（A）（用于更新）； 和
- 对网络分区的容忍度（P）。
Brewer后来对“ 2 of 3”公式进行了一些修改 ，但是这种认识导致开发人员考虑使用替代的一致性模型，例如“基本可用，软状态，最终一致性”或BASE ，以便为可用性和分区容忍度，以及可扩展性。 通过一致性提高可用性已成为许多NoSQL数据库的关键设计原则。 NoSQL数据库的其他常见设计目标包括高性能，水平可伸缩性，简单性和模式灵活性。 这些设计目标也由Cassandra创始人共享，但也旨在支持CAP，这意味着开发人员可以在一致性和延迟之间进行权衡。
BASE是不需要NoSQL数据库的分布式系统的一致性模型。 促进BASE模型的NoSQL数据库也鼓励围绕BASE设计应用程序。 从技术角度来看，设计使用BASE一致性模型的系统可能具有挑战性，而且还因为放松的一致性保证对于用户是可见的，并且需要传统上习惯于以强大的思维方式进行思考的产品所有者的新思维方式。一致性模型。
数据访问API和客户端库
开始开发Java数据库应用程序时，需要做的第一件事就是数据库客户端库。 在大多数RDBMS产品中，这很简单：JDBC是事实上的低级数据库访问API，因此您只需下载该特定数据库的JDBC驱动程序，然后配置较高级别的数据访问API（例如JPA）即可使用该驱动程序。 您可以选择使用哪个更高级别的API，但是对于特定的数据库产品，通常只有一个JDBC驱动程序供应商。 另一方面，Cassandra目前为Java开发人员提供9个不同的客户端。 这些客户端提供了不同的数据管理方式：一些提供对象关系映射API，一些支持CQL，另一些提供较低级别（例如，基于Thrift）的API。
可以使用RPC样式（基于Thrift的）API访问和管理Cassandra中的数据，但是Cassandra还具有一种非常基本的查询语言，称为CQL，在某种程度上在语法上类似于SQL，但是在许多情况下，开发人员需要具有很多与关系数据库相比，更深入地了解存储引擎如何在后台运行。 Cassandra社区推荐用于使用Cassandra 1.2的新项目的API是CQL 3。
由于正在积极开发Cassandra，因此必须选择开发速度与服务器相匹配的客户端，这一点很重要。 否则，您将无法利用应用程序中的所有新服务器功能。 由于Cassandra用户社区仍在增长，因此最好选择具有活跃用户社区和现有文档的客户端。 由Netflix开发的Astyanax客户端目前似乎是Cassandra上使用最广泛，可用于生产且功能齐全的Java客户端。 该客户端支持基于Thrift和CQL 3的API来访问数据。 提供商业Cassandra产品和支持的公司DataStax也正在开发自己的基于CQL 3的Java驱动程序，该驱动程序最近才进入beta阶段。
与关系数据库的区别
Cassandra存储引擎的设计目标与关系数据库的目标完全不同。 这些目标不可避免地反映在产品和API中，并且IMO既不能也不应该对应用程序开发人员隐藏。 CQL查询语言为许多开发人员设定了期望，并可能使他们假设他们正在使用关系数据库。 从RDBMS背景可以注意到的一些重要差异可能令人惊讶，其中包括：
- 不支持联接和子查询。 该数据库针对面向键的访问进行了优化，并且需要通过非规范化预先设计数据访问路径。 Apache Solr，Hive，Pig和类似的解决方案可用于提供更高级的查询和联接功能
- 没有完整性约束。 引用和其他类型的完整性约束强制必须内置到应用程序中
- 没有ACID交易。 单行内的更新是原子性的和隔离的，但不是跨行或跨实体的。 与使用RDBMS时相比，逻辑工作单元可能需要拆分和排序。 应设计应用程序，以确保最终的一致性
- 查询语句中只能使用索引谓词。 自动为行键创建索引，可以根据需要创建其他列值的索引（当前针对集合类型的列除外）。 不支持复合索引。 Solr，Hive等可用于解决这些限制。
- 排序标准需要提前设计。 排序顺序选择非常有限。 行按行键排序，列按列名排序。 这些以后无法更改。 Solr，Hive等可用于解决这些限制。
数据模型设计是一个过程，与RDBMS相比，开发人员将遇到其他差异。 对于Cassandra，推荐的数据建模方法与RDBMS相反：先确定数据访问模式，然后再模型数据以支持这些访问模式。 数据独立性不是主要目标，开发人员应了解CQL数据模型如何映射到存储引擎的实现数据结构，以便最佳利用Cassandra。 （实际上，使用大数据量RDBMS应用程序也无法实现完全的数据独立性）。 数据库针对面向键的数据访问进行了优化，必须对数据模型进行非规范化。 可以在运行时在关系数据库中轻松修改或配置的应用程序的某些方面是使用Cassandra进行设计时决策，例如排序。
关系应用程序数据模型通常为每个关系存储单一类型的实体。 Cassandra存储引擎不需要列族中的行包含相同的列集。 您可以将有关完全不相关的实体的数据存储在单个列族（宽行）中。
行键，分区键和集群列是数据建模概念，对于Cassandra应用程序开发人员而言，了解这些概念很重要。 Cassandra存储引擎按行键唯一地标识行，并且键提供主要的行访问路径。 CQL单列主键直接映射到存储引擎中的行键。 对于复合主键，主键的第一部分用作行键和分区键。 复合主键的其余部分用作群集列。
行键和列名，以及分区器（和比较器）算法的选择对数据分区，群集，性能和一致性具有重要影响。 行键和分区程序控制数据如何在数据库集群的节点之间分配以及如何在节点内排序。 这些参数还确定在存储引擎中是否可以进行范围扫描和排序。 具有相同分区键的逻辑行将作为单个物理宽行存储在同一数据库节点上。 单个存储引擎行中的更新是原子性的和隔离的，但不是跨行的。 这意味着您的数据模型设计将确定可以原子执行的更新。 行中的列由群集列进行群集和排序，这在数据模型包含宽行（例如时间序列数据）时尤其重要。
在对应用程序问题进行故障排除时，能够使用即席查询研究存储引擎中的数据通常非常重要。 尽管Cassandra确实支持即席CQL查询，但受支持的查询类型受到更多限制。 此外，数据库架构更改，数据迁移和数据导入通常需要自定义软件开发。 另一方面，当涉及到大数据量时，使用RDBMS进行模式演化传统上是非常具有挑战性的。
Cassandra支持二级索引，但是应用程序通常被设计为维护单独的列系列，这些列系列支持基于单个或多个二级访问条件来查找数据。
我注意到有关Cassandra的有趣的事情之一是，它具有非常好的负载平衡和故障转移群集支持，并且很容易设置。 故障转移无缝且快速地进行。 Cassandra的重量也很轻巧，安装起来也不费力。 在Cassandra中，数据访问和操纵操作的性能非常快。 数据模型具有架构灵活性，并支持RDMBS通常无法满足其使用要求的用例，例如，以高性能存储大量的时序数据。
结论
Cassandra是一个高度可用的Internet规模的NoSQL数据库，其设计目标与传统的关系数据库大不相同。 本文中确定的Cassandra数据库和关系数据库之间的差异应被视为各有利弊，并应根据您的问题域进行评估。 另外，使用NoSQL并不排除使用RDBMS –具有混合体系结构是很常见的，其中每种数据库类型根据各自的优势在不同的用例中使用。
当开始他们的第一个NoSQL项目时，开发人员很可能会进入新的领域，并且第一次接触相关概念，例如大数据和最终的一致性。 关系数据库通常与强一致性相关联，而NoSQL系统通常与最终一致性相关联（即使使用某种类型的数据库并不意味着特定的一致性模型）。 从关系世界和强大的一致性转移到NoSQL领域时，最大的思想转变可能是在理解和设计应用程序以实现最终的一致性。 数据建模是另一个需要采用新的设计思维方式的领域。
Cassandra是一款非常有趣的产品，具有广泛的用例。 我认为它特别适合以下用例的数据库选项：
- 超大数据量
- 非常大的用户交易量
- 对数据存储的高可靠性要求
- 动态数据模型。 数据模型可能是半结构化的，并有望随着时间的推移而发生重大变化
- 跨数据中心分布
但是，它与关系数据库有很大不同。 为了能够就是否使用Cassandra做出明智的设计决策，了解更多信息的一种好方法是仔细研究文档。 Cassandra的开发速度非常快，因此您可能会发现许多文档已经过时。 但是，没有什么可以替代动手实践的，因此您也应该进行一些原型设计和基准测试。
翻译自: https://www.javacodegeeks.com/2013/07/practical-nosql-experiences-with-apache-cassandra.html
2824
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
