一直纠缠开发人员的最大问题之一是“我应该使用什么技术？”。经过数天的思考和分析，确定了哪些选项（从越来越多的选项中）最适合需求、管理数量和需求、制定长期战略计划、简化/减少支持，并得到同事和管理层的批准。
与现实生活相比，这些步骤甚至看起来很容易。决策的复杂性可能会因需要多少支持以及现有技术和开发人员知识的当前限制而变得复杂。例如，投资于未知或更新的解决方案意味着分配学习成本。
如果您正在研究图形数据库，您可能对它可以处理的复杂性或与数据交互的简单性感到敬畏。也许您对漂亮的可视化或闪电般快速查询的可能性感到震惊。话又说回来，也许你急于学习新的东西并想尝试这个图形数据库的东西。
但是您如何确定该图表是满足您的业务或技术需求的正确解决方案？需要进行什么样的调查才能确定其价值？是什么让图形数据库比您项目的另一个解决方案特别？
在这篇文章中，我想重点介绍一些场景，以帮助您了解何时不适合用例。这些不是严格的指导方针，而是在深入探索图表作为解决方案之前评估图表是否适合您的用例的一些机会。
仅针对图形的好处，有许多特定于供应商的页面，例如“为什么选择图形数据库？”一个来自 Neo4j。
自我评估：您是否渴望在任何事情上使用图形数据库？
我认为我们作为开发人员（或 <在此处插入职位标题>）非常希望使用新的东西，因此我们选择了解决方案并将其应用于下一个出现的“受害者”项目。我们中的大多数人可能都知道不要这样做，但现实往往会在最后期限和绝望中迷失。
为了改变这种心态，我们需要在评估各种解决方案之前对每个问题进行分析。我们使用这项技术的动机是什么？它将提供其他人无法提供的东西吗？应该提出可能的解决方案并进行深入研究，以了解每种解决方案的优缺点。从那里，其他人的一些评论可以捕捉任何缺失的想法或删除不符合足够要求的选项。
图形数据库何时不适合？
与大多数公司一样，Neo4j 偏向于其产品及其实用性。我们都希望我们的产品可以用于一切，但这个世界上永远不会有任何东西是千篇一律的。有太多独特的想法、人、问题和技术存在（这是一件好事！）。您将了解的关于产品的大部分内容可能来自公司本身，这通常侧重于积极方面以及它做得好的方面。
…但是知道你不能或不应该用它做什么呢？
如果您的用例通过了以下所有场景，这应该有助于巩固图表是一个很好的选择。但是，如果您的用例适合这些场景中的任何一个，这将有望帮助您避免为错误的工作使用错误的工具。虽然此列表并不全面，但它涵盖了最常见或最容易识别的情况。
数据断开连接且关系无关紧要的地方
如果您有交易数据并且不关心它与其他交易、人员等的关系，那么图可能不是解决方案。在某些情况下，技术只是存储数据，分析数据之间的联系和意义并不重要。
只写事务和没有 SQL 连接语句的简单查询的要求是很好的指标，表明您的用例可能不适合图形数据库。您的查询可能依赖于顺序索引数据（存储在存储中的前一个记录旁边的下一个记录），而不是关系索引数据（记录存储在与其相关的最接近的数据）。
搜索单个数据片段或项目列表也指向其他解决方案，因为它对该数据的上下文不感兴趣。总体而言，图形解决方案将专注于并从高度连接的数据中提供最大的价值，并且查询搜索可能的连接（如果这些连接不存在）。如果这不适合您的用例，另一种技术可能更适合它。
您正在优化写入和存储数据而不是读取/查询的位置
虽然上面提到了这一点，但我想单独关注它。如果用例只是想将数据写入存储而不期望分析结果，那么图可能无法解决问题。图数据库旨在非常快速地遍历存储的数据并在几毫秒内检索结果。如果预计用例不会利用此优势，那么您可能希望找到另一种解决方案。
核心数据模型保持一致且数据结构固定/表格的地方
如果您正在收集一组不变的、不变的数据，那么图表可能不是最合适的解决方案。图表非常适合存储多种元素类型，并且可以轻松适应不断变化的业务需求。
举个例子，您需要跟踪给您的企业打电话的人数。为此，您只需在 Customer 表中存储 ID、姓名和电话号码。无需保留来自客户的更多信息，因此表格上的列不会更改，并且可以为每个呼叫您的公司的人分配 ID、姓名和电话号码。这是关系数据库的一个很好的例子。
如果预计需求会增长并且需要其他类型的分析，该表仍然可以适应包括电子邮件地址、公司名称、订单号等。仍然有足够的灵活性来处理空值（并非所有客户都创建订单或为公司工作），存储其他类型的实体（如订单），或调整数据定义（即客户也可以是员工）。
简而言之，如果要求仅限于特定需求，并且预计范围仍然有限，那么图表可能不是最合适的。
查询执行批量数据扫描或从未知数据点开始的位置
如果您的查询正在执行表扫描以查找匹配项或搜索适合一般类别的数据，那么图形解决方案并不是最适合该任务。图数据库经过优化，可以从起点遍历关系。它没有针对在没有特定目标区域的情况下搜索整个图形进行优化。
像下面这样的查询最终会遍历一个潜在的海量图，其中包含单个结果的各种类型的信息（Jennifer 是订单或物品还是客户或员工或其他东西？）。但是，下一个查询从特定用户开始，并查看该人认识的人。
MATCH (n) WHERE n.name = "Jennifer" RETURN n; MATCH (n:Person {name: "Jennifer"})-[r:KNOWS]->(p:Person) RETURN p;复制
当您的大多数查询看起来像第一个查询并且这些查询的性能非常重要时，您需要考虑非图解决方案。虽然图形仍然可以处理这些查询，但该技术并未针对批量扫描或未知起点的最大性能进行优化。
它在哪里用作键值存储（如缓存）
如果您只对查找操作感兴趣，那么图形数据库不是您的解决方案。如上所述，图形分析受益于数据之间的关系。从已知键查找并不能最大化创建图形数据库的目的。
例如，有人可能使用数据库作为缓存来存储应用程序的会话数据。您可以将会话 ID 存储在缓存中，然后将会话详细信息写入数据库。当您需要检索会话详细信息或对其运行分析时，您将发送会话 ID（作为键）以返回值（可能是存储在实体上的属性）。
此方法不使用任何关系，因为它使用已知键返回单个对象或一个实体的详细数据。在查看您的用例时，请确保您了解每种技术的存储和检索机制。进行查找可能更适合键值存储甚至关系数据库，从而为您提供更好的性能。
需要将大量文本或 BLOBS 存储为属性的地方
如果您要存储和检索包含极大值的实体属性（例如 BLOB、CLOB、文本段落等），那么另一种技术解决方案可能是更好的选择。图数据库非常擅长遍历小数据实体之间的关系，但当您在单个节点上存储大量属性或在这些属性中存储大量值时，其性能就不那么好了。这样做的原因是因为查询可以从一个实体跳到另一个实体，但是还需要额外的处理来提取沿路径的每个实体的详细信息。
有时，可以通过重新组织数据模型来纠正这个问题。例如，如果您将有关员工的所有信息存储在单个图形节点上（地址、工作信息、订单、福利选举、薪水信息），它将创建一个非常麻烦的节点，其中包含许多属性和潜在的大值。您可以对其进行重新建模，以分离公司、地址和职位详细信息的实体，从而简化模型并降低查询性能。
但是，您可能在某些情况下需要将这些大值存储在单个属性中，并且查询不是特定于图形的。对于这种类型的用例，不建议使用图形数据库。
当然，上面列出的任何一项都不会总是单独出现。一些场景之间的划分经常模糊和跨越界限，因此您的项目的某些方面可能是反对使用图形数据库的原因，也可能是支持使用图形数据库的原因。虽然这可能会使决定复杂化，但最终归结为评估每种技术的正面/负面以确定最合适的技术。
图形数据库什么时候适合？
我不会在这里花太多时间，因为我简要提到了图技术的一些关键优势，您可以从公司资源、员工讨论和客户反馈中了解更多信息，但我想以一些积极的方式结束。 😃
用户想要了解其数据中的关系（隐藏的和明显的）的场景将在图形数据库中蓬勃发展。如果您想了解客户兴趣以将消息传递到主题区域或了解网络布局以分析影响，那么图形数据库非常适合这些用例和查询。图表可以让企业创建全面、多样化的客户档案或审查银行交易以找出可能是欺诈迹象的异常值。
它们还超出了数据科学和分析目的的性能预期。图算法正在扩展对连接数据进行更复杂分析以突出决策模式的价值。
图形技术用于所有类型的行业，用于关键业务系统和主干流程。任何数据看起来像网络的地方都是图表可以最大化价值的指标。
结论
我们只触及了图形数据库能做什么和不能做什么的皮毛。在决定一项或另一项技术时，有很多更精细、更细微的细节。通过这篇文章，我想为您提供一些工具来帮助您做出决定。无论您是否选择图形数据库，目标都是找到满足（并有望超越）要求的最佳工具。
祝您的生活学习愉快！
原文标题：How Do You Know If a Graph Database Solves the Problem?
原文作者：Jennifer Reif
原文地址：https://dzone.com/articles/how-do-you-know-if-a-graph-database-solves-the-problem
