注释
此功能目前处于公开预览状态。 此预览版在没有服务级别协议的情况下提供，不建议用于生产工作负荷。 某些功能可能不受支持或者受限。 有关详细信息，请参阅 Microsoft Azure 预览版补充使用条款。
图形数据库将数据建模为连接的实体和关系网络。 最常用的图形数据库类型实现 标记的属性图 模型：实体（节点）和关系（边缘）可以具有标签和属性（键值对）。 此灵活模型既支持架构可选设计，又支持架构驱动设计，并让你表达丰富的语义。 由于连接作为边显式存储，因此查询会沿着这些边遍历关系，而不是在查询时计算高成本的连接。
图形数据库核心概念
- 节点表示人员、产品或位置等内容。 节点可以具有描述其属性的标签和属性。
- 边缘表示这些内容的连接方式，例如FRIENDS_WITH、购买或LOCATED_IN。 边缘还可以携带属性和标签来编码关系元数据。
- 属性将详细信息附加到节点和边（例如，人员的姓名或边的起始日期）。 由于关系以边形式显式存储，因此查询通过沿着连接进行导航，而不是在查询时计算关系。
如何查询关系的工作原理
图查询通过从起始节点依次遍历到相邻节点，然后再到他们的邻居节点，以此类推来检索连接的信息。 遍历执行的工作与它接触的边缘数（局部邻域）相关联，而不是数据集的总大小。 这使得有关路径、连接和模式的问题（例如朋友的朋友、最短路径或多跳依赖关系）可以自然且高效地表达。
图形数据库使用基于模式的查询语言（如日益采用的 图形查询语言（GQL）来简明地描述这些遍历。 GQL 正由监督 SQL（ISO/IEC 39075）的同一国际工作组标准化，使图形查询与已建立的数据库标准保持一致。
示例（与 GQL 的模式匹配）：
MATCH (p:Person {name: "Alice"})-[:FRIENDS_WITH]->(friend)-[:PURCHASED]->(o:Order)
RETURN o
此模式读取为：从 Alice 的 Person 节点开始，沿着 FRIENDS_WITH 边缘到每个朋友，然后沿着 PURCHASED 边缘到相关的订单节点，返回这些订单。
建模和架构
图形数据模型是架构可选的：当需要强治理时，可以使用固定架构，或者随着新节点类型、关系或属性的出现而改进模型。 此方法减少了重复数据的需求，使团队能够统一来自多个源的数据，而无需预先重新设计大量数据。
图形数据库的常见用途
图形数据库与连接驱动价值的域紧密匹配，例如社交网络、知识图、建议系统、欺诈和风险网络、网络和 IT 拓扑以及供应链依赖关系分析。 在这些情境中，问题不再只是关于单个记录，而是关于有多少实体通过多个跃点进行关联和交互。
何时考虑图形数据库
如果主要问题涉及连接数据中的路径、邻域和模式，请选择图数据库；当跃点数量可变或事先未知时；或者当您需要在不同的数据集中合并和导航关系时。 如果这些问题需要反复回答，图形模型是自然拟合的。
那么 ETL 呢
将数据表示为图形并将其存储在单独的独立图形数据库中通常会引入 ETL 和治理开销。 相比之下，Microsoft Fabric 中的图形直接在 OneLake 上运行，这减少了或消除了单独的 ETL 管道和数据重复的需求。 请考虑以下利弊：
- 数据移动和重复：独立图形数据库通常需要提取、转换和加载（ETL）数据到单独的存储中，这会增加复杂性，并可能导致重复数据集。 Microsoft Fabric 中的 Graph 在 OneLake 上运行，因此可以在不移动连接数据的情况下对连接数据进行建模和查询。
- 运营成本：独立图形堆栈作为单独的群集或服务运行，并且通常会产生空闲容量费用。 Fabric 中的图形工作负荷使用具有自动缩减和集中式指标的共用容量单位（CUs），从而简化了操作并降低成本。
- 可伸缩性：某些独立图形数据库依赖于纵向扩展或特定于供应商的群集。 Microsoft Fabric 中的图专为大规模图设计，使用跨多个工作单元的扩展缩放分片来高效处理大数据处理负载。
- 工具和技能：特定于供应商的图形系统可能需要专用语言和单独的分析框架。 Microsoft Fabric 中的 Graph 提供统一的建模、基于标准的查询（GQL）、内置的图形分析算法、BI 和 AI 集成，以及低/无代码探索工具，以便更广泛的用户可以处理连接的数据。
- 治理和安全性：单独的图形部署需要独立的治理和安全设置。 Microsoft Fabric 中的 Graph 使用 OneLake 治理、世系和工作区基于角色的访问控制（RBAC），因此合规性、审核和权限与 Fabric 环境的其余部分保持一致。