图数据库何时并不适用？到底什么时候适合用图呢？

将图作为解决方案深入探索之前，需先评估图是否适合您的实际应用场景。

“我该用哪项技术？”这个棘手的问题一直困扰着开发者。技术的选择，需要经过数天的思考和分析，您得在日益增长的选项中确定哪些最符合需求，做好数量和需求管理，制定长期战略计划，简化或减少支持，并得到同事的认可和管理层的批准。

实际情况却复杂得多。认可度的高低、现有技术条件的限制和开发人员知识水平的不足，可能都会让决策的过程更加复杂。例如，投资未知或全新的解决方案意味着要付出学习成本。

如果您正在研究图数据库，可能会惊叹它处理复杂事物的能力和数据交互的简易性，或许还会被漂亮的可视化效果图和快如闪电的查询功能所震撼。因此，为了学习新事物，就会想要开始尝试图数据库。

但要如何确定图是适合您业务或技术需求的解决方案呢？需要进行什么样的调查才能确定其价值？是什么让图数据库从一众的解决方案中脱颖而出？

关于应用图的好处，相信大家已经看了很多内容了。本文将不做赘述，而是将重点介绍一些应用场景，帮您了解什么情况下不适合用图数据库。这些不是严格的准则，但可以在您将图作为解决方案深入探索之前，帮助您判断图与您的用例是否合适。

自我评估 .

您是否期望图数据库能解决所有问题？

作为开发人员（或其他头衔）总是想尝试新的解决方案，并选择这样的解决方案并将其应用于下一个出现的项目。大多数开发人员都明白不能这样做，但现实情况是，项目截止日期和紧迫感往往会迫使他们妥协。

为了改变这种心态，我们需要在评估各类解决方案之前回答这两个问题：我们使用这项技术的动机是什么？它有何与众不同之处？因此，我们要提出可能的解决方案并深入研究，从而了解每种方案的优缺点。如此一来，他人的建议可以补充我们没想到的地方，或是剔除不符合要求的选项。

场景评估 .

图数据库何时并不适用？

我们都希望我们的产品可以普遍适用，但世上没有任何东西能普适万物。因为独特的想法、人、问题和技术实在是太多了（这其实是件好事！）。您对一款产品的大部分了解可能来自该公司本身，他们通常致力于宣传自己积极和出色的一面。

如果您的用例符合以下的任何一个场景，那您就要避免将错误的工具用于不合适的场景。但是，如果您的用例不符合以下所有场景，那图对您来说或许是绝佳选择。虽然这个场景清单不算全面，但它涵盖了最常见和最容易辨认的情况。

1

数据互不关联，

数据间的关系无足轻重

如果交易数据与其他交易、人员等方面的关系无关紧要，那么图可能不是合适的解决方案。因为在某些情况下，只需使用技术存储数据即可，分析数据之间的关系和意义并不重要。

若是该交易只具备“只写”属性，且无需SQL 连接语句的简单查询，那么这就说明您的情况可能不适合图数据库。您的查询可能更依赖于顺序索引数据（下一个数据紧靠上一个数据存储），而不是关系索引数据（存储在与其相关的最邻近的数据旁）。

若只需搜索单个数据片段或项目列表，那么最好另寻他法，因为无需知晓数据环境。总体而言，图解决方案专注于从高度互接的数据中获取最大价值，查询搜索潜在的各类关联（如果这些关联还未建立）。如果您的场景不具备这些特性，其他技术或许更合适。

2

需要优化数据写入与存储，

而不是读取或查询

虽然上面提到了这一点，但我想着重强调一下。如果用例只需将数据写入存储库而无需分析数据结果，那么图可能无法解决问题。图数据库旨在快速遍历存储的数据并在几毫秒内检索结果。如果用例无需使用图的这一优势，那么您可以寻找其他解决方案。

3

核心数据模型不变，

数据结构固化或被表格化

如果您正在收集一组恒定不变的数据，那么图可能不是最佳的解决方案。图非常适用于存储多种元素类型，可以轻松适应不断变化的业务需求。

举个例子，您需要追踪来电客户人数。那么您只需在客户信息表中存储客户ID、姓名和电话号码。此外无需其他信息，表格上的列不会更改，因此每个咨询的客户都有其特有的 ID、姓名和电话号码。这是关系型数据库的一个绝佳案例。

如果预计需求会增长并且需要其它类型的分析，还可以加入电子邮件地址、公司名称、订单号等信息。此外，该表还能够灵活地处理空值（并非所有客户都是公司职员或能创建订单）、存储其他类型的实体（如订单）或调整数据定义（即客户也可以是员工）。

简而言之，如果仅限于特定需求，并且预计使用范围有限，那么图可能并不适用。

4

查询需要执行批量数据扫描

或从未知数据点开始

如果您想通过表扫描查询匹配项或找到符合一般范畴的数据，图数据库并不是解决问题的最优方案。图数据库经过优化，可以从一个起点开始遍历关系。但不适用于无指定目标区域的全表搜索。

下方的查询代码最终可能遍历一张包括各类信息却只得到单一结果的超大图（Jennifer可以是一份订单，一个物品，一位顾客，一个员工或是其他事物）。然而，下一个查询要从特定用户开始，查看该用户认识的人。

若您的大多数查询与第一个查询类似，而且查询性能至关重要，您需要考虑舍弃图数据库。尽管图数据库也能处理这些查询，但不能最大程度地优化批量扫描或未知起点的遍历性能。

5

如需用于键值存储（类似缓存）

如果您只需要查找操作，图数据库并不适合您。如上所述，图分析得益于数据之间的关系。从已知键开始查找，并不能最大限度地发挥图数据库的作用。

例如，有些人会把数据库当作缓存，存储应用程序中的会话数据。您可以在缓存中存储会话ID，并将会话详情写入数据库。当您需要检索会话详情或分析其运行时，您可以发送会话ID（作为键）来返回值（可能是存储在实体上的属性）。

这种方法不使用任何关系，它能通过已知键返回单个对象或单个实体的具体数据。在检查用例时，这种方法能确保您了解每种技术的存储和检索机制。键值存储，甚至是关系型数据库更适合查询，查询性能也更佳。

6

如需将大量文本或BLOBS存储为属性

如果您正在存储并检索包含超大值的实体属性（例如BLOB、CLOB、文本段落等），其他技术会更适合。图数据库十分擅长遍历小型数据实体之间的关系，但是并不适用于在单个节点上存储大量属性，或者在这些属性中存储超大值。虽然查询可以从一个实体跳转到另一个实体，但您需要额外步骤来获取路径中每个实体的详细信息。

有时候，您能通过重组数据模型来改善这个问题。例如，如果您将与员工有关的所有信息都储存在单一图节点上（员工的住址、工作信息、订单、福利选择、工资信息），这个节点会包含许多属性与潜在大值，十分复杂。您可以重新建模，将公司、地址和职位详情分开，简化模型并降低查询性能。

但是，在特定情况下，您可能需要将这些大值存储在单个属性中，而且这些查询不仅限于图数据库。对于这种类型的用例，我们不建议使用图数据库。

当然，上述情况不会总是单独出现。有时，场景之间的界限并不分明。在您的项目中，可能有些部分适合用图数据库，但有些则不然。虽然这可能是个复杂的选择，但我们仍需要评估每种技术的优缺点，从而确定最佳的解决方案。

简单说说 .

到底什么时候适合用图呢？

我在前面简单提到了图技术的一些核心优势，您可以通过公司资源、员工讨论或客户反馈中了解更多到信息，这里我就不再赘述了。在文章的结尾，我想和大家聊聊图数据库的优点。:)

图数据库的出现让越来越多的用户想要了解数据间的关系（隐性和显性）。如果您想了解客户兴趣，将消息推送到话题区，或是想了解网络布局，分析其影响，那么图数据库是您的不二之选，非常适合用于这些用例和查询。企业可以借助图创建全面且多样化的客户资料，或仔细审查银行交易，发现可能存在欺诈迹象的异常值。

图数据库在数据科学与分析领域的性能十分卓越。图算法能增值基于数据关联的复杂分析，突显决策模式。

总结 .

我们现在只谈到图数据库的使用范围，而这只是图数据库最浅显的部分。我们需要通过更细微的细节来选择不同技术。这篇文章旨在为您提供一些方法，帮助您更好地做出选择。无论您是否选择图数据库，我们都希望您能找到最合适（甚至超乎预料）的方法。

审核编辑：刘清