四种类型的非关系，您知道多少

本文内容摘录自“数据科学概论”. 在这里，我们将向您介绍四种NoSQL. 继续阅读，您将获得更多有用的信息.

当前，用于非关系的数据存储有四种主要类型: 键值存储（键值），文档存储（文档存储），面向列的（面向列）和图形（图形）. 每个都将解决相应的问题，而关系无法解决这些问题. 在实际应用中，将这些情况结合起来以实现相应的功能. 例如: OrientDB是一个集成了NoSQL几种存储类型的多类型. OrientDB是一个图形，每个节点是一个文本.

在开始介绍NoSQL之前，让我们先回顾一下关系，以便我们可以在非关系和关系之间进行深入的比较. 在数据建模中，可能会使用许多方法. 关系将严格按照标准化进行建模（即第一范式，第二范式，第三范式等）: 以确保每条数据仅存储一次. 标准化是其结构的规范. 例如: 如果要存储一个人的信息和该人的爱好等数据，则可以创建两个表: 一个表用于存储该人的信息，另一个表用于存储该人的爱好. 如图1所示，您必须具有一个附加的映射表，该映射表在人员的信息表和爱好表之间建立相应的关系. 这是因为他们的关系是多对多关系，一个人可以有多个爱好，而多个人可能有相同的爱好.

第一张图片

一个完整的关系将由许多实体表和关系映射表组成. 现在您已经可以与NoSQL进行比较，让我们看一下这些不同的存储类型.

面向列的（面向列）

传统关系是面向行的. 每行都有一个行ID，并且行中的每个字段都存储在一个表中. 假设在上面的示例中，没有单独的表格来存储人们的爱好，我们仅使用一个表来存储个人信息和爱好，如图2所示. 在这里，您需要注意. 在这种付款方式下，由于存在重复的爱好，您已经有点违反了严格遵循关系的标准. 如果嗜好是一条很好的信息，它可以很好地描述一个人，但对您的用例并不重要，则可以在“嗜好”列中将其列出，这是一种可以接受的方法. 但是，如果这些信息对您根本不重要，那么是否需要存储这些数据？

图2

在基于行的中搜索时，无论是否需要数据列，每次都会遍历每一行. 如果只需要9月生日的人的数据，那么基于行的将从上到下从左到右遍历该表，如图3所示，最后返回需要的那些数据.

图三

为特定列中的数据建立索引可以有效地提高搜索速度，但是为每个列建立索引也将带来额外的负担，并且还将遍历所有列以获得要搜索的数据.

基于列的将分别存储每个列，并且在搜索少量列时搜索速度非常快. 其结构如图4所示.

图四

这种设计看起来很像基于行的，每列都有一个索引. 索引的数据结构以存储空间和更多写入文件（索引更新）为代价提高了搜索速度. 索引将行号映射到数据，而基于列的将数据映射到行号. 此方法的计算非常简单. 例如，在上面的示例中，很容易计算出多少人的爱好包括射箭. 此外，单独存储每一列可以优化压缩非关系型有哪些，因为每个表中仅存储一种类型的数据.

所有这些，什么时候应该使用基于行的，什么时候应该使用基于列的？在基于列的中添加新的数据列很容易，因为现有列将不受新列的影响. 但是，如果要添加整个记录，则需要适应所有表非关系型有哪些，以防止每个表的数据之间的对应关系出错. 因此，这使得基于行的在事务处理方面比基于列的更好，因为它很好地实现了实时数据更新.

基于列的的优势在于分析数据并形成关于数据的报告，例如对值求和并计算整个记录. 基于行的通常用于实际交易中（例如销售操作）. 夜间批处理作业可以更新基于列的，它还支持快速搜索并使用MapReduce技术聚合数据以形成报告. 目前，Apache HBase，Facebook的Cassandra，Hypertable和宽列存储的祖父Google BigTable用于将数据存储在基于列的中.

键值存储

键值对的存储方法是NoSQL中最简单的方法，其结构就像其名称所暗示的那样，它是一个键值集合. 如图5所示. 该方法是NoSQL类型中最可扩展的类型，可以存储大量数据.

图5

键值对中存储的数据类型不受限制. 它可以是字符串，数字，甚至是由一系列键值对封装的对象. 图6向我们展示了一个更复杂的键值对结构. 存储的使用价值包括Redis，Voldemort，Riak和Amazon的Dynamo.

图6

文档存储

文档存储基于键值对存储，并且其结构比键值对存储更为复杂. 可以说，这是在键值对存储基础上更进一步的一步. 文档存储假定可以通过特定模式来解释特定文档的结构. 与其他NoSQL类型相比，它的外观是最自然的，因为设计此方法的最初目的是存储Daily文档，并且此方法支持通常汇总的数据的复杂查询和计算. 从标准化的角度来看，使用关系存储数据的方式是有意义的: 每条数据仅存储一次，并通过外键链接. 只要数据在此结构下有意义，文档存储就不会在乎所谓的标准化. 因此，关系不能很好地适应特定的企业案例，而只能用于更一般的案例.

例如: 报纸和杂志包含文章. 如果要将这些文章存储在关系中，则首先需要分离这些文章. 文章的内容在一个表中，文章的作者和有关作者的信息需要存储在另一个表中，对Internet上发表的文章的评论也需要一个附加的表来存储. 如图7所示，可以将报纸上的文章作为实例存储，这样可以减少处理始终查看的数据时的搜索时间. 使用文档存储的NoSQL包括MongoDB和CouchDB.

第七张图片

图形

现在剩下的是最后一个NoSQL存储类型，它也是最复杂的一种，主要使用一种有效的方法来存储各种实体之间的关系. 当数据紧密相关时，例如社会关系，科学论文的引文或资本资产定价模型等，使用图形时的最佳选择. 图形或网络数据由两部分组成:

节点-: 实体本身可以被视为社会关系中的一个人.

Edge-: 实体之间的关系. 这种关系可以用一条线来表示，它具有自己的属性. 这条线可以有方向，箭头可以指示谁是上级.

如果提供足够的关系和实体类型，则图形将变得非常复杂，并且混乱的程度令人难以置信. 图8显示了只有几个实体的复杂图形. 像Neo4j这样的图形声称支持ACID，但是文档存储和键值对都遵循BASE.

图八

非关系的潜力是无限的. 如今，世界变得越来越近，图形存储类型在地理上可能胜过其他存储类型，包括仍占主导地位的关系类型. . 可以找到当今最受欢迎的的排名以及它们的开发方式.

图九

图9显示了在这9条记录中，在撰写本书时，关系在前15名中仍然占主导地位. 随着NewSQL的到来，我们还没有重新计算排名. 编写本书时，Neo4j是当前最受欢迎的图形存储，位于第23位，而Titan则位于第53位.

原文翻译: NoSQL类型

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/ruanjian/article-289512-1.html