图数据库如何解决问题？

困扰开发者的一个最大问题是：“我应该使用什么技术？”需要花费数天的时间进行思考和分析，才能确定（在日益增长的选项中）哪个选项最符合需求、能管理容量和需求、符合长期战略、简化/减少支持，并获得同事和管理层的批准。

与现实生活相比，这些步骤可能看起来都很简单。所需的认同度，以及现有技术和开发人员知识的实际限制，可能会使决策的复杂性加剧。例如，投资于一个未知或较新的解决方案意味着需要分配学习成本。

如果您正在研究图数据库，您可能对其处理复杂性的能力或与数据交互的简便性感到惊叹。也许您被精美的可视化图或闪电般的查询速度所吸引。又或者，您只是渴望学习新东西，并想尝试一下图数据库。

但您如何确信图是适合您业务或技术需求的解决方案？需要进行什么样的调查才能确定其价值？是什么让图数据库在您的项目中优于其他解决方案？

在本文中，我想重点介绍一些不适合使用图数据库的场景。这些不是严格的准则，而是您可以用来评估图数据库是否适合您的用例，然后再深入探讨解决方案的机会。

有关图数据库的优点，请参阅 Neo4j 的“为什么选择图数据库？”页面。

自我评估：您是否迫切想在任何项目中使用图数据库？

我认为，作为开发者（或<插入职位名称>），我们非常渴望使用新东西，以至于我们在下一个“受害者”项目中选择了一个解决方案并将其应用进去。我们中的大多数人可能知道不该这样做，但由于截止日期和紧迫性，现实往往被忽略了。

要改变这种心态，我们需要在评估各种解决方案之前，先对每个问题进行分析。我们使用这项技术的动机是什么？它能提供其他技术无法提供的东西吗？应该列出可能的解决方案并进行充分研究，以了解每种解决方案的优缺点。之后，参考他人的评审意见，可以发现任何遗漏的观点，或删除不符合足够要求的选项。

什么时候不适合使用图数据库？

像大多数公司一样，Neo4j 也偏向于自己的产品及其用途。我们都希望我们的产品能用于一切，但在世界上没有任何东西是“一刀切”的。想法、人、问题和技术太多样化了，不可能存在（而且这是好事！）。您对产品的了解很可能来自公司本身，该公司通常侧重于积极方面和其优势。例如（但不仅限于此），请查看 Neo4j 的产品页面。

……但如何知道您不能或不应该用它做什么呢？

如果您的用例符合以下所有场景，这应该能帮助您确信图数据库是一个绝佳的选择。然而，如果您的用例符合这些场景中的任何一个，这希望能帮助您避免“错误工具用于错误工作”。虽然此列表并非包罗万象，但它涵盖了最常见或最容易识别的情况。

数据孤立且关系无关紧要。

如果您拥有交易数据，并且不关心它与其他交易、人员等的关系，那么图数据库可能不是解决方案。有些情况下，技术只是存储数据，而对其连接和含义的分析并不重要。

如果您的需求是仅写入事务，且不需要 SQL 连接语句的简单查询，那么图数据库可能不适合。您可能需要依赖顺序索引数据（存储在存储中紧邻前一条记录的那一条）的查询，而不是关系索引数据（记录存储在与其相关联的数据附近）的查询。

搜索单个数据项或项目列表也指向其他解决方案，因为它不关心该数据的上下文。总的来说，图数据库解决方案将最适合高度连接的数据，并且查询会搜索可能的连接（如果尚不存在）。如果这不符合您的用例，其他类型的技术可能更适合。

优化写入和存储数据，而不是读取/查询。

尽管在上一条中已提及，但我仍想单独强调这一点。如果用例仅用于将数据写入存储，而不期望分析结果，那么图数据库可能无法解决问题。图数据库旨在非常快速地遍历已存储的数据，并在毫秒内检索结果。如果用例不期望利用此优势，那么您可能需要寻找其他解决方案。

核心数据模型保持一致，数据结构固定/表格化。

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

例如，假设您需要跟踪致电您公司的客户数量。您只需在“客户”表中存储 ID、姓名和电话号码即可。无需保留客户的更多信息，因此表中的列不会改变，并且每个致电您公司的客户都可以被分配一个 ID、姓名和电话号码。这是关系型数据库的一个好例子。

如果需求预计会增长，并且需要其他类型的分析，表仍然可以适应以包含电子邮件地址、公司名称、订单号等。仍然有足够的灵活性来处理空值（并非所有客户都会创建订单或在公司工作），存储其他类型的实体（如订单），或调整数据定义（例如，客户也可以是员工）。

简而言之，如果需求仅限于特定需求，并且范围预计将保持相对有限，那么图数据库可能不是最佳选择。

查询执行批量数据扫描或从未知数据点开始。

如果您的查询是通过表扫描来查找匹配项，或者搜索符合一般类别的数据，那么图数据库不是最适合此任务的。图数据库经过优化，可以从一个起始点遍历关系。它并不针对在没有特定目标区域的情况下搜索整个图进行优化。

如下面的查询将遍历一个可能包含各种类型信息的巨大图来获取单个结果（Jennifer 是订单、物品、客户、员工还是其他什么？）。然而，下一个查询从一个特定用户开始，查看该人认识谁。

//Query 1
MATCH (n)
WHERE n.name = "Jennifer"
RETURN n;

//Query 2
MATCH (n:Person {name: "Jennifer"})-[r:KNOWS]->(p:Person)
RETURN p;

如果您的绝大多数查询都类似于第一个查询，并且这些查询的性能至关重要，那么您需要考虑非图数据库解决方案。虽然图数据库仍然可以处理这些查询，但该技术并非针对批量扫描或未知起始点的最大性能进行了优化。

用作键值存储（例如缓存）。

如果您只对查找操作感兴趣，那么图数据库不是您的解决方案。如上所述，图分析得益于数据之间的关系。从已知键进行的查找并未最大化图数据库的创建目的。

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

这种方法不利用任何关系，因为它使用已知键来返回单个对象或一个实体上的详细数据。在审查您的用例时，请确保您了解每种技术的存储和检索机制。查找操作可能更适合键值存储甚至关系型数据库，从而为您提供更好的性能。

需要存储大量文本或 BLOB 作为属性。

如果您存储和检索包含极大的值的实体属性（如 BLOB、CLOB、文本段落等），那么另一种技术解决方案可能更好。图数据库非常擅长遍历小型数据实体之间的关系，但当您在一个节点上存储大量属性或在这些属性中存储大值时，其性能会下降。原因是查询可以从一个实体跳到另一个实体，但还需要额外的处理才能提取路径上每个实体的详细信息。

有时，可以通过重新组织数据模型来纠正此问题。例如，如果您将有关员工的所有信息存储在一个图节点上（地址、工作信息、订单、福利选择、薪资信息），这将创建一个包含大量属性和潜在大值的非常繁琐的节点。您可以将其重塑为独立的实体（公司、地址和职位详细信息），从而简化模型并提高查询性能。

然而，您可能会遇到一些需要将这些大值存储在单个属性中的情况，并且查询不是图数据库特有的。对于这类用例，不推荐使用图数据库。

当然，以上列出的任何一项都不会总是单独出现。某些场景之间的界限常常模糊不清，相互交叉，因此您的项目可能既有反对使用图数据库的理由，也有支持使用图数据库的理由。这可能会使决策复杂化，但最终还是取决于评估每种技术的优缺点，以确定最适合的方案。

什么时候适合使用图数据库？

我不会花太多时间在这里，因为我简要提到了图技术的一些关键优势，您可以从公司资源、员工讨论和客户反馈中了解更多信息，但我想以一些积极的方面来结束。：）

用户希望了解其数据中关系（隐藏的和显而易见的）的场景将非常适合图数据库。如果您想了解客户兴趣以针对特定主题区域发送消息，或了解网络的布局以分析其影响，图数据库非常适合这些用例和查询。图数据库可以使企业创建全面、多样化的客户画像，或审查银行交易以查找异常情况，这些异常可能是欺诈的迹象。

它们在数据科学和分析方面的性能也超出了预期。图算法正在扩展运行更复杂分析的价值，以突出显示用于决策的模式。

图技术被用于各种行业的关键业务系统和骨干流程。任何数据看起来像网络的地方都表明图数据库可以最大化价值。

结论

我们只是触及了图数据库能做什么和不能做什么的表面。在选择一种技术或另一种技术时，还有更多细微和微小的细节需要考虑。通过这篇文章，我希望能为您提供一些帮助您做出决定的工具。无论您是否选择图数据库，目标都是找到满足（并有望超越）需求的最佳工具。

仍然不确定，想测试一下图数据库以进行概念验证？立即启动一个免费的 Neo4j AuraDB 实例！