毫无疑问，web应用程序处理数据的方式在过去十年中发生了重大变化. 正在收集的数据和并发访问这些数据的用户比以往任何时候都多. 这意味着对于基于模式的关系数据库来说，可伸缩性和性能比以往任何时候都更具有挑战性，因此更难以扩展.

NoSQL的演变

SQL的可伸缩性问题是在Web 2中发现的.0拥有庞大且不断增长的数据和基础设施需求的公司，如谷歌、亚马逊和Facebook. 他们提出了自己的解决方案，比如技术 BigTable, DynamoDB, 卡珊德拉.

这种日益增长的兴趣导致了许多NoSQL数据库管理系统(数据库管理系统)的出现。, 专注于表现, 可靠性, 和一致性. 为了增强搜索和读取性能，重用和改进了许多现有的索引结构.

第一个, 大公司开发了专有(闭源)类型的NoSQL数据库来满足他们的特定需求, 比如谷歌的BigTable, 哪个被认为是第一个NoSQL系统, 以及亚马逊的DynamoDB.

这些专有系统的成功启动了许多类似的开源和专有数据库系统的开发, 最流行的是Hypertable, 卡珊德拉, MongoDB, DynamoDB, HBase, 和复述,.

NoSQL的不同之处?

NoSQL数据库和传统关系数据库之间的一个关键区别是，NoSQL是一种数据形式 非结构化存储.

这意味着NoSQL数据库可以 不 有一个固定的表结构，就像在关系数据库中发现的那样.

NoSQL数据库的优点和缺点

优势

与传统的关系数据库相比，NoSQL数据库有许多优点.

一个主要的、潜在的区别是NoSQL数据库具有简单而灵活的结构. 它们是无模式的.

与关系数据库不同，NoSQL数据库基于键值对.

NoSQL数据库的一些存储类型包括列存储, 文档存储, 键值存储, 图的存储, 对象存储, XML存储, 以及其他数据存储模式.

通常，数据库中的每个值都有一个键. 一些NoSQL数据库存储还允许开发人员将序列化的对象存储到数据库中, 不仅仅是简单的字符串值.

开源NoSQL数据库不需要昂贵的许可费用，并且可以在便宜的硬件上运行, 使其部署具有成本效益.

也, 当使用NoSQL数据库时, 不管它们是开源的还是专有的, 与使用关系数据库相比，扩展更容易，成本更低. 这是因为它是通过水平扩展和在所有节点上分配负载来完成的, 而不是通常在关系数据库系统中完成的垂直扩展类型, 哪个是用一个更强大的主机取代主主机.

缺点

当然，NoSQL数据库并不完美，也不总是正确的选择.

首先，大多数NoSQL数据库不支持 可靠性的特点 由关系数据库系统本地支持的. 这些可靠性特性可以概括为原子性、一致性、隔离性和持久性. 这也意味着NoSQL数据库, 哪些不支持这些功能, 用一致性换取性能和可伸缩性.

为了支持可靠性和一致性特性， 开发人员 必须实现自己的专有代码，这会增加系统的复杂性吗.

这可能会限制可以依赖NoSQL数据库进行安全可靠事务的应用程序的数量, 比如银行系统.

在大多数NoSQL数据库中发现的其他形式的复杂性包括与SQL查询的不兼容性. 这意味着需要一种手动或专有的查询语言, 增加了更多的时间和复杂性.

NoSQL vs. 关系数据库

该表提供了NoSQL和关系型数据库的简要特性比较:

应该指出的是，该表显示了对……的比较 数据库级而不是各种各样 数据库管理系统 实现了这两个模型. 这些系统提供 他们自己的专有技术 克服两种制度存在的一些问题和不足, 在某些情况下, 显著提高性能和可靠性.

NoSQL数据存储类型

键值存储

在键值存储类型中，使用哈希表，其中唯一键指向项.

键可以组织成键的逻辑组, 只要求键在自己的组中是唯一的. 这允许在不同的逻辑组中使用相同的键. 下表显示了一个键值存储的示例, 其中的钥匙是城市的名字, 值是该城市阿尔斯特大学的地址.

键值存储的一些实现提供了缓存机制, 这大大提高了他们的表现.

处理存储在数据库中的项所需要的只是键. 数据以字符串、JSON或BLOB(二进制大对象)的形式存储。.

这里面最大的缺陷之一 数据库格式 是否在数据库级别缺乏一致性. 这可以由开发人员用自己的代码添加, 但是正如之前提到的, 这会增加更多的工作量, 复杂性, 和时间.

最著名的建立在键值存储上的NoSQL数据库是亚马逊的DynamoDB.

文档存储

文档存储类似于键值存储，因为它们没有模式并且基于键值模型. 因此，两者都有许多相同的优点和缺点. 两者在数据库级别上都缺乏一致性, 这为应用程序提供更多的可靠性和一致性特性铺平了道路.

然而，两者之间有一些关键的区别.

在文档存储中，值(文档)为存储的数据提供编码. 这些编码可以是XML、JSON或 二进制编码JSON.

此外，还可以进行基于数据的查询.

依赖于文档存储的最流行的数据库应用程序是MongoDB.

列存储

在列存储数据库中, 数据存储在列中, 而不是像大多数关系数据库管理系统那样按行存储.

列存储由一个或多个列族组成，这些列族在逻辑上对数据库中的某些列进行分组. 键用于标识和指向数据库中的许多列, 使用keyspace属性定义该键的作用域. 每一列包含名称和值的元组，以逗号分隔.

列存储具有对存储数据的快速读/写访问. 在列存储中，与单个列对应的行存储为单个磁盘条目. 这使得读/写操作期间的访问速度更快.

使用列存储的最流行的数据库包括Google的BigTable、HBase和卡珊德拉.

图基础

在图基NoSQL数据库中，使用有向图结构来表示数据. 图由边和节点组成.

正式, 图是一组对象的表示, 其中有几对物体是通过链接连接起来的. 相互联系的对象用数学抽象表示, 被称为顶点, 连接一些顶点对的链接叫做边. 一组顶点和连接它们的边被称为一个图.

这说明了使用边和节点来表示和存储数据的图基数据库的结构. 这些节点通过彼此之间的一些关系来组织, 哪个由节点之间的边表示. 节点和关系都有一些已定义的属性.

图形数据库通常用于社交网络应用程序. 图形数据库允许开发人员更多地关注对象之间的关系，而不是对象本身. 在这种情况下，它们确实支持可伸缩且易于使用的环境.

目前最流行的图形数据库是InfoGrid和InfiniteGraph.

NoSQL数据库管理系统

对于数据库的简要比较, 下表提供了不同NoSQL数据库管理系统的简要比较.

MongoDB具有灵活的模式存储, 这意味着存储对象不一定需要具有相同的结构或字段. MongoDB也有一些优化特性, 哪个将数据收集分布在不同的地方, 导致整体性能的提高和更平衡的系统.

其他NoSQL数据库系统, 如Apache CouchDB, 文档存储类型也是数据库吗, 并与MongoDB共享许多特性, 除了可以使用休息ful api访问数据库之外.

休息是一种体系结构风格，由应用于组件的一组协调的体系结构约束组成, 连接器, 数据元素, 在万维网上. 它依赖于无状态、客户端-服务器、可缓存的通信协议.g.HTTP协议).

休息ful应用程序使用HTTP请求来发布、读取和删除数据.

对于列基数据库, Hypertable是一个用c++编写的NoSQL数据库，基于Google的BigTable.

Hypertable支持跨节点分布数据存储，以最大化可伸缩性, 就像MongoDB和CouchDB一样.

使用最广泛的NoSQL数据库之一是由Facebook开发的卡珊德拉.

卡珊德拉是一个列存储数据库，它包含了许多旨在提高可靠性和容错性的特性.

而不是深入了解每个NoSQL 数据库管理系统, 卡珊德拉和MongoDB, 两个最广泛使用的NoSQL数据库管理系统, 将在下一小节中探讨.

卡珊德拉

卡珊德拉是Facebook开发的数据库管理系统.

卡珊德拉背后的目标是创建一个没有单点故障并提供最大可用性的数据库管理系统.

卡珊德拉主要是一个列存储数据库. 一些研究将卡桑德拉称为混合系统, 灵感来自谷歌的BigTable, 哪个是列存储数据库, 以及亚马逊的DynamoDB, 哪个是键-值数据库.

这是通过提供一个键值系统来实现的, 但卡桑德拉的钥匙指向一组列族, 依赖于Google的BigTable分布式文件系统和Dynamo的可用性特性(分布式哈希表).

卡珊德拉旨在存储分布在不同节点上的大量数据. 卡珊德拉是一个设计用于处理大量数据的数据库管理系统, 分布在许多服务器上, 同时提供无单点故障的高可用性服务, 这对Facebook这样的大型服务来说是必不可少的吗.

卡珊德拉的主要特点包括:

• 无单点故障。. 为了实现这一点，卡珊德拉必须在节点集群上运行，而不是在单个机器上运行. 这并不意味着每个集群上的数据是相同的，但是管理软件是相同的. 当其中一个节点发生故障时，该节点上的数据将无法访问. 但是，其他节点(和数据)仍然可以访问.
• 分布式哈希 提供哈希表功能的方案是否以增加或删除一个槽的方式不会显着改变键到槽的映射. 这提供了根据服务器或节点的容量将负载分配给它们的能力, 反过来, 减少停机时间.
• 相对容易使用的客户端界面. 卡珊德拉使用Apache 节俭作为它的客户端接口. Apache 节俭提供了一个跨语言的RPC客户端, 但大多数开发者更喜欢基于Apple 节俭的开源替代品, 比如赫克托.
• 其他可用性特性. 卡珊德拉的功能之一是数据复制. 基本上，它将数据镜像到集群中的其他节点. 复制可以是随机的, 或者通过放置在不同数据中心的节点来最大化数据保护, 例如. 卡珊德拉的另一个特性是分区策略. 分区策略决定在哪个节点上放置键. 这也可以是随机的，也可以是有序的. 当使用这两种类型的分区策略时, 卡珊德拉可以在负载均衡和查询性能优化之间取得平衡.
• 一致性. 像复制这样的特性使得一致性具有挑战性. 这是因为所有节点在任何时间点都必须是最新的，具有最新的值, 或者在触发读操作时. 最终, 虽然, 卡珊德拉试图通过向开发人员提供这种可定制性来保持复制操作和读/写操作之间的平衡.
• 读/写操作. 客户端向单个卡珊德拉节点发送请求. 该节点按照复制策略将数据存储到集群中. 每个节点首先执行提交日志中的数据更改, 然后用更改更新表结构, 都是同步完成的. 读操作也非常相似, 一个读请求被发送到单个节点, 这个节点决定了哪个节点保存数据, 根据分区/放置策略.

MongoDB

MongoDB是一个用c++编写的无模式、面向文档的数据库. 数据库是基于文档存储的, 这意味着它以编码数据的形式存储值(称为文档).

MongoDB中选择的编码格式是JSON. 这是强大的，因为即使数据嵌套在JSON文档中，它仍然是 可查询 和 可转位.

下面的小节描述了MongoDB中可用的一些关键特性.

碎片

分片是在多个机器(节点)之间对数据进行分区和分布。. 分片是MongoDB节点的集合, 与卡珊德拉相反，卡珊德拉的节点是对称分布的. 使用分片还意味着能够横向扩展多个节点. 在应用程序使用单个数据库服务器的情况下, 它可以转换为分片集群，只需对原始应用程序代码进行很少的更改，因为分片是由MongoDB完成的. 软件几乎完全与公开给客户端的公共api解耦.

Mongo查询语言

如前所述，MongoDB使用休息ful API. 从数据库集合中检索某些文档, 将创建一个查询文档，其中包含所需文档应该匹配的字段.

行动

在MongoDB中，有一组称为路由器的服务器. 每个都充当一个或多个客户机的服务器. 类似地，集群包含一组称为配置服务器的服务器. 每个分片保存一个元数据副本，指示哪个分片包含哪些数据. 读或写操作从客户端发送到集群中的一个路由器服务器, 并且在配置服务器的帮助下，由该服务器自动路由到包含数据的适当分片.

类似于卡桑德拉, MongoDB中的分片具有数据复制方案, 它会创建每个分片的副本集，其中包含完全相同的数据. MongoDB有两种复制模式:Master-Slave复制和replica - set复制. Replica-Set提供了更多的自动化和更好的故障处理, 而主从系统有时需要管理员的干预. 与复制方案无关, 在复制集的任何时间点, 只有一个shard作为主shard, 其他所有复制分片都是二级分片. 所有的写和读操作都到主分片, 然后(如果需要的话)均匀地分布到集合中的其他次级分片.

在下面的图表中, 我们看到上面解释的MongoDB架构, 以绿色显示路由器服务器, 配置服务器用蓝色表示, 以及包含MongoDB节点的分片.

应该注意的是，MongoDB中的分片(或在分片之间共享数据)是完全自动的, 这降低了故障率，使MongoDB成为一个高度可扩展的数据库管理系统.

NoSQL数据库的索引结构

索引是将键与数据库管理系统中相应数据记录的位置相关联的过程. 在NoSQL数据库中使用了许多索引数据结构. The following sections will briefly discuss some of the more common methods; namely, b -树索引, -树索引, 和O2-Tree索引.

b -树索引

B-Tree是数据库管理系统中最常见的索引结构之一.

在b树中，内部节点可以在预定义的范围内拥有可变数量的子节点.

与其他树形结构的一个主要区别, 比如AVL, b树是否允许节点拥有可变数量的子节点, 这意味着更少的树木平衡，但更多的浪费空间.

B+树是B树最流行的变体之一. B+-树是对B-树的改进，它要求所有键都驻留在叶子中.

-树索引

结合avl树和b树的特征设计了t树的数据结构.

avl树是一种自平衡二叉搜索树, 而b树是不平衡的, 每个节点可以有不同数量的子节点.

在t树中，其结构与avl树和b树非常相似.

每个节点存储多个{键-值，指针}元组. 也, 二分搜索与多个元节点结合使用，以产生更好的存储和性能.

t树有三种类型的节点:一个t节点有一个右子节点和一个左子节点, 没有子节点的叶节点, 半叶节点只有一个子节点.

人们认为t - tree比avl树s具有更好的综合性能.

O2-Tree索引

o2树基本上是对红黑树的改进, 二叉搜索树的一种形式, 其中叶节点包含{键值, 指针}元组.

O2-Tree是为了提高现有索引方法的性能而提出的. m阶O2-Tree (m≥2), 其中m是树的最小度, 满足以下性质:

• 每个节点不是红色就是黑色. 根是黑色的.
• 每个叶节点都是黑色的，由一个保存“键值”的块或页组成, 记录指针”对.
• 如果一个节点是红色的，那么它的两个子节点都是黑色的.
• 对于每个内部节点, 从节点到后代叶节点的所有简单路径都包含相同数量的黑节点. 每个内部节点保存一个键值.
• 叶节点是具有≤m/2²和m对“键值，记录指针”的块.
• 如果树只有一个节点, 那么它一定是一片叶子, 哪一个是树的根, 它可以有1到m个键数据项.
• 叶节点在向前和向后方向上是双链接的.

在这里, 我们可以看到O2-Tree之间的性能比较, -树, B +树, avl树, 红黑树:

使用的-树、B +树和O2-Tree的阶数为m = 512.

记录搜索操作的时间, 插入, 对于包含50M条记录的索引，以0%-100%的更新比率进行删除, 这些操作导致在索引中添加另外50M条记录.

很明显，当更新率为0-10%时，B-Tree和-树的性能优于O2-Tree. 然而, 随着更新率的增加, O2-Tree索引的性能明显优于大多数其他数据结构, 其中b树结构和红黑树结构受到的影响最大.

NoSQL的案例?

快速介绍NoSQL数据库, 强调传统关系数据库不足的关键领域, 引出第一个要点:

而关系数据库提供一致性, 它们没有针对大量数据存储和频繁处理的应用程序的高性能进行优化.

NoSQL数据库因其高性能而广受欢迎, high scalability 和 ease of access; however, 他们仍然 缺乏提供一致性和可靠性的特性.

幸运的是, 许多NoSQL dbms通过提供增强可伸缩性和可靠性的新特性来解决这些挑战.

并非所有NoSQL数据库系统的性能都比关系数据库好.

MongoDB和卡珊德拉也有类似的, 而且在大多数情况下更好, 在写和删除操作方面性能优于关系型数据库.

存储类型和NoSQL 数据库管理系统的性能之间没有直接的关联. NoSQL实现会发生变化，因此性能可能会有所不同.

因此，在不同的研究中，跨数据库类型的性能度量应该 总是 用最新版本的数据库软件更新，以便这些数字准确.

虽然我无法给出一个明确的评价，但这里有几点需要记住:

• 传统的b树和t树索引是传统数据库中常用的索引方法.
• 一项研究通过结合多个索引结构的特征来提出O2-Tree，从而提供了改进和增强.
• 在大多数测试中，O2-Tree的性能优于其他结构, 特别是在庞大的数据集和高更新率的情况下.
• 在本文介绍的所有索引结构中，B-Tree结构的性能最差.

可以而且应该做进一步的工作来增强NoSQL dbms的一致性. NoSQL和关系数据库这两个系统的集成是一个有待进一步探索的领域.

最后, 值得注意的是，NoSQL是对现有数据库标准的一个很好的补充, 但有一些重要的警告. NoSQL以可靠性和一致性特性换取纯粹的性能和可伸缩性. 这使它成为一个专门的解决方案, 因为可以依赖NoSQL数据库的应用程序数量仍然有限.

有利的一面? 专业化可能不会提供太多的灵活性, 但是当你想要尽可能快速高效地完成一项专业工作时, 你不需要瑞士军刀. 你需要NoSQL.