从 NoSQL 迁移到图数据库
尽管命名不够直观，但 NoSQL（“不仅仅是 SQL”）领域汇集了许多有趣的解决方案，它们提供了不同的数据模型和数据库系统，每种方案在特定的用例和数据形态下，都比传统的 SQL 解决方案更为适用。
随着 NoSQL 运动的兴起，大型关系型系统“一刀切”的主张被取代，取而代之的是针对特定任务寻找合适工具的慎重决策。
大多数 NoSQL 系统都是面向聚合（aggregate-oriented）的，根据特定的标准和数据库类型（如文档存储、键值对等）对数据进行分组。这种模型仅提供简单且有限的操作，且只形成数据的一种专用视图。一次专注于一个聚合，使用户能够轻松地沿着聚合维度（例如文档数据库中的文档）将大量数据块分布在机器网络上；但这意味着其他投影和视角必须通过处理或复制数据来计算。
大多数 NoSQL 数据库存储的是一组组断开连接的聚合。这使得它们难以用于关联数据和图。为这类存储添加关系的一个众所周知的策略是在属于另一个聚合的字段中嵌入一个聚合的标识符——实际上就是引入外键。但是，这需要在应用程序层面连接聚合，其开销会迅速变得极其昂贵。
其他 NoSQL 数据库缺乏关系。而图数据库则可以处理细粒度的信息网络，提供适合您用例的任何视角。来自关系型系统中广为人知且值得信赖的事务保证也同样保护了 Neo4j 中图数据的更新，符合 ACID 标准。
让我们将图数据模型与其他 NoSQL 模型进行比较。
将 NoSQL 知识转化为图
随着 NoSQL 运动的到来，各种规模的企业都有了多种现代化的选择，用以构建与其用例相关的解决方案。
-
计算平均收入？请咨询关系型数据库。
-
构建购物车？请使用键值存储。
-
存储结构化的产品信息？请以文档形式存储。
-
描述用户如何从 A 点到达 B 点？请跟随图。
下图展示了每种数据库类型在衡量深度和规模的量谱上的表现。虽然键值存储可以处理海量规模，但它们是为数据的高级视图（低深度）而设计的。即使在比其他类型的数据库更深的数据深度下，图数据库也能保持最小的规模。其他类型的数据库则落在这些范围之间。
键值模型与图模型：数据模型的差异
键值模型非常出色，对于查找大量简单甚至复杂的值具有极高的性能。下图展示了典型的键值存储是如何构建的。
然而，当这些值本身是相互关联的时，您就拥有了一个图。Neo4j 让您可以快速遍历所有关联的值，并发现关系中的洞察。下方的图版本展示了每个键如何与单个值相关联，以及不同的值如何相互关联（就像通过关系连接在一起的节点）。
