什么是图形数据库？

注释

此功能目前处于公开预览状态。此预览版在没有服务级别协议的情况下提供，不建议用于生产工作负荷。某些功能可能不受支持或者受限。有关详细信息，请参阅 Microsoft Azure 预览版补充使用条款。

图形数据库提供了一种对连接数据进行建模和查询的强大方法。与在表中存储数据的传统关系数据库不同，图形数据库将信息表示为节点（实体）和边缘（关系），以便更轻松地更灵活地探索复杂的连接和模式。

最常用的图形数据库类型实现标记的属性图（LPG）模型：实体（节点）和关系（边缘）可以具有标签和属性（键值对）。此灵活模型既支持架构可选设计，又支持架构驱动设计，并让你表达丰富的语义。由于连接作为边显式存储，因此查询会沿着这些边遍历关系，而不是在查询时计算高成本的连接。

重要

图形数据库核心概念

节点表示人员、产品或位置等实体。节点可以具有描述其属性的标签和属性。例如，Person 节点可能具有 firstName、lastName 和 age 等属性。
边表示实体的连接方式，例如FRIENDS_WITH、PURCHASED 或 LOCATED_IN。边缘还可以携带属性和标签来编码关系元数据。
属性将详细信息附加到节点和边（例如，人员的姓名或边的起始日期）。由于关系以边形式显式存储，因此查询通过沿着连接进行导航，而不是在查询时计算关系。

图查询通过从起始节点依次遍历到相邻节点，然后再到他们的邻居节点，以此类推来检索连接的信息。遍历执行的工作与它接触的边缘数（局部邻域）相关联，而不是数据集的总大小。这使得有关路径、连接和模式的问题（例如朋友的朋友、最短路径或多跳依赖关系）可以自然且高效地表达。

图形数据库使用基于模式的查询语言（如日益采用的 图形查询语言（GQL）来简明地描述这些遍历。 GQL 正由监督 SQL（ISO/IEC 39075）的同一国际工作组标准化，使图形查询与已建立的数据库标准保持一致。

示例（与 GQL 的模式匹配）：

MATCH (p:Person {firstName: "Annemarie"})-[:knows]->(friend)-[:likes]->(c:Comment)
RETURN c
ORDER BY c.creationDate
LIMIT 100

此模式的读取过程为：从 Annemarie 的 Person 节点出发，沿着 :knows 边遍历到每个好友节点，然后沿着 :likes 边移至相关的 :Comment 节点。返回按创建日期排序的 100 条最新批注。

图形数据模型是架构可选的：当需要强治理时，可以使用固定架构，或者随着新节点类型、关系或属性的出现而改进模型。此方法减少了重复数据的需求，使团队能够统一来自多个源的数据，而无需预先重新设计大量数据。

图数据库与那些通过连接驱动价值的领域紧密对齐，例如：

在这些情境中，问题不再只是关于单个记录，而是关于有多少实体通过多个跃点进行关联和交互。

在以下情况下选择图形数据库：

如果经常询问这类问题，图形模型是自然拟合的。

将数据表示为图形并将其存储在单独的独立图形数据库中通常会引入 ETL（提取、转换、加载）和管理开销。相比之下，Microsoft Fabric 中的 Graph 直接在 OneLake 上运行，这减少了或消除了单独的 ETL 管道和数据重复的需求。请考虑以下利弊：

数据移动和重复：独立图形数据库通常需要提取、转换和将数据加载到单独的存储中，这会增加复杂性，并可能导致重复数据集。 Microsoft Fabric 中的 Graph 在 OneLake 上运行，因此可以在不移动连接数据的情况下对连接数据进行建模和查询。
运营成本：独立图形堆栈作为单独的群集或服务运行，并且通常会产生空闲容量费用。 Fabric 中的图形工作负荷使用具有自动缩减和集中式指标的共用容量单位（CUs），从而简化了操作并降低成本。
可伸缩性：某些独立图形数据库依赖于纵向扩展或特定于供应商的群集。 Microsoft Fabric 中的图专为大规模图设计，使用跨多个工作单元的扩展缩放分片来高效处理大数据处理负载。
工具和技能：特定于供应商的图形系统可能需要专用语言和单独的分析框架。 Microsoft Fabric 中的 Graph 提供统一建模、基于标准的查询（GQL）、内置图形分析算法、BI 和 AI 集成以及低/无代码探索工具。这些功能使更广泛的用户能够处理连接的数据。
治理和安全性：单独的图形部署需要独立的治理和安全设置。 Microsoft Fabric 中的 Graph 使用 OneLake 治理、世系和工作区基于角色的访问控制（RBAC），因此合规性、审核和权限与 Fabric 环境的其余部分保持一致。

此页面是否有帮助？