留一份备用 2016 年 NoSQL 介绍

36大数据 • 7年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

在万维网的早期，看到一张道路挖掘工人的动画GIF以及标题“正在建设中”是很常见的。这是未完成的网站，相当于要访客原谅这些混乱。

随着网络的成熟，那些“正在建设中”的GIF消失了。然而，他们的精神后裔却存在了相当长一段时间：网络应用程序不可用，或者是只读的，用于计划维护。而计划维护往往涉及数据库模式迁移。

现在，我们的期望是不同的。如果我们的移动和网络应用程序不能全天候工作，这将是一个大问题; 在某些情况下，这是有新闻价值的。

不仅仅是对可用性的期望已经改变：有时我们的应用程序所接触的数据的形态和体量与前几年相比也大不相同。

那么，为什么关系数据库仍然处于几乎每个Web应用程序的核心位置？

取舍

答案当然是我们了解关系数据库。我们懂得取舍，我们知道如何规划他们以及如何查询。关系数据库可以工作并且仍然相关。

然而，值得注意的是，我们从关系数据库获得的好处并不是免费的。仅仅因为我们懂得取舍，这并不意味着他们不在那里。

我们从SQL获得的可查询性部分来自于强制性模式，这些模式易于编入索引，但不容易更改。我们从关系数据库中获得的强大的一致性使得扩展潜在的成本高昂，写入可用性高昂成为挑战。

NoSQL数据库也有很多取舍。通过了解每种类型的NoSQL数据库的基础知识，我们可以更好地知道何时使用它们以及那些取舍。

非关系数据库的四种基本类型

NoSQL涵盖了存储和检索数据的许多类型的系统。这不是一个特别准确的名称，因为许多人采用自己的类似SQL的查询语言。将它们称为非关系数据库更为准确，因为数据模型（不一定是查询语言）与关系数据库不同。

2016 年，常见的有大概四种类型的非关系数据库用法：

键值 Key-Value
文档
列
图

在数据模型上，另外一个重要的方面就是，它将会影响你的应用程序架构，以及你需要做什么样的取舍，特别是特定的数据库系统中如何简单的跨多个服务器运行一个数据库实例。

分布式和单实例

只有极少数的情况下使用单服务器来运行 NoSQL 数据库。因为 NoSQL 一般设计用于适合进行水平扩展的，二者的实现方法完全不同。

这些不同的方法主要影响有：

数据的一致性和可用性
数据集的体积是否已经超过单台机器能承载的最大存储容量
单点故障
在应用层上需要做的工作量

我们将在下面对这几个问题进行简单的讨论，但是要详细展开就需要单独再发篇文章。

Key-Value 存储

绝大多数人已经比较熟悉 key-value 存储了，它们就像是一个哈希或者字典。

在非关系数据库属于中，一个 key-store 存储包含如下几个简要的特性：

每个值都有唯一的一个键
对数据库系统而言，允许存储任何类型的值
在一个纯 key-value 系统中，key 是唯一的索引

那么，为什么要使用一个似乎提供很少功能的数据存储呢？

正是因为他们做的这么少，键值存储用起来非常灵活：

您可以存储任何东西：二进制文件，POJO，文本，会话数据，无论您选择什么。
模式未强制：您可以将其从一个KV对更改为下一个。
它们很快：存储和检索键值对没有任何开销。查询处理期间没有磁盘查找，无需复杂的JOIN进行解析，无需等待索引完成。
分配KV对很容易：它们是离散的数据单元。

这些使键值存储成为一个不错的选择：

存储对象状态。
存储会话状态。
从更昂贵的来源（例如大型机或数据分析工具）卸载/缓存数据。
存储高速数据。
存储不可预测和变化的数据。
通过添加更多服务器来存储大量数据。

如果您需要任何超出键查询类型之外的查询，键值存储不适合该用例。这引入了纯键值存储的关键取舍之一：除了基本的存储和检索之外，它们还要求您在应用层中执行其他所有操作。

键值存储的例子

LevelDB：简单，单实例，需要的资源很少。

Riak：分布在较大的服务器群集中的最终一致的数据库。

Couchbase：在群集上运行并具有强大的文档数据库功能的分布式强一致的数据库。

文档数据库

文档数据库与键值存储共享一些共同点：

文件很容易分发。
模式未强制
对于大多数文档数据库，您可以使用键来查找整个文档。

然而它们与键值存储不同的地方是最有趣的。文档数据库索引并允许您查询数据的内容。这意味着它们比我们认为的数据库更接近于基本的存储和检索机制。

今天的大部分文档数据库索引并查询JSON数据，而其中的一两种则使用XML代替。如果您使用过Lotus Notes和Domino，那么您已经使用了一种形式的文档数据库; 但不要让它们令你失望。

现代文档数据库非常适合Web应用程序：

我们在Web应用程序中使用的大部分数据已经在JSON中，或者很容易序列化为JSON。
灵活的模式意味着模式迁移的停机时间成为过去，因此您可以快速迭代应用程序的功能，而不会导致停机时间。
文件易于分发，因此随着需求的上升和下降而易于变化。
结构化文档格式，如JSON，易于索引等查询。

当涉及到用例时，有一些功能与键值存储交叉，但是文档数据库的可查询性意味着它为您做了大量工作，而不是将该工作推卸到应用层。

您可以考虑将文档数据库用于：

用户配置文件。
会话存储。
任何结构化文本内容：产品目录，社交媒体新闻稿，内容管理等。
对象状态（如果容易地序列化到JSON或XML）。

主要有两个取舍：

保持模式检查成为你的工作。
查询还没有像您在SQL数据库中使用的那样优化。

同样值得注意的是，与所有这些非关系数据库一样，软件本身和周围的生态系统也不像以前那样成熟。

文档数据库的例子

MongoDB ：最着名的非关系数据库，它使用简单的方法链进行查询，容易上手而且有一个很好的社区，但当大规模使用时其性能急剧下降。

CouchDB ：早期的NoSQL先驱，对于较大的数据集来说，并不是很好，而且依赖于map-reduce来进行查询。然而，所有这些问题都应该随着2.0版本的变化而发生改变。

Couchbase ：键值存储介绍了map-reduce，子文档更新和类似SQL的查询语言，以成为文档数据库。

Elasticsearch ：虽然不是主要的文档数据库，但Elasticsearch允许您存储，索引和搜索文档，因此，如果这是您对查询机制的唯一要求，那么它对你来说就够了。

列式存储

列式存储既有点陌生又有点熟悉。它们旨在使其易于存储和查询时间序列数据。最初令他们与关系数据库混淆的是，他们与关系数据库有一些术语相同，但含义却不同。

使用列式存储，行可以保存任意数量的列，每列具有与其相关联的任意数量的值。使列式存储最有趣的是，一列中的数据依次保存在磁盘上，使得它能够快速地在该数据上运行范围查询。

想象一下一种测量流体通过管道的流量的仪器。每秒记录流量。在列式存储中，此特定仪器将具有其自己的列，每秒的测量将是该列中的一个值。在列式存储中附加数据开销很小，使其成为时间序列数据的理想选择。

列式存储的主要取舍是，您将失去一些灵活性。您必须先了解您正在存储的数据的形状，但最重要的是，您需要考虑如何查询数据，这将影响将其存储在磁盘上的方式。

列式数据库的示例

Cassandra ：最着名的列式存储，它还使用了Dynamo论文介绍的在群集上分发数据的方法，以一致性为代价提供高读/写可用性。

HBase ：来自Hadoop世界，HBase在牺牲可用性的基础上保持了强一致性。

图数据库

以上三种数据库类型首先从数据开始，并将查询视为次要考虑因素。相反，图数据库都是关于查询的，它们基于欧拉图论。

在图论中，数据集由图上的节点和这些节点之间的连接组成。有趣的是连接在节点之间启用的路由。

图数据库用例的一个常见例子是社交网络。每个节点都是一个人，连接是这些人彼此连接的方式。所以，两个分享喜爱道格拉斯·亚当斯作品的两个人之间可能会有标记为“道格拉斯·亚当斯”的定向连接。如果这些人每个人都有非道格拉斯·亚当斯的联系，那么社交网络可以帮助他们找到其他道格拉斯·亚当斯的粉丝。怎么样？图数据库可以遍历人物图寻找标记为“道格拉斯·亚当斯”的连接。

这使得图数据库成为社交网站等的理想选择。也许更有趣的是，它也有助于识别数据集中的异常元素，如银行诈骗活动。

一个很大的取舍在于，要使查询在可接受的时间内运行，连接的数据必须位于同一台服务器上。这使得扩展图数据库变得更加困难。也可能需要运行其他类型的数据库来存储图中节点的数据。

图数据库的例子