yang db
1.0.0
https://www.yangdb.org/
维基百科
版本信息
发行说明
利奥尔·佩里
罗曼·马戈利斯
莫蒂·科恩
埃拉德·维斯
西蒙·贝诺什蒂
一篇文章介绍了我们新的开源计划，用于通过 Opensearch 构建可扩展的分布式图数据库 https://www.linkedin.com/pulse/making-db-lior-perry/
Opensearch 作为图形数据库的另一种用法 https://medium.com/@imriqwe/elasticsearch-as-a-graph-database-bc0eee7f7622
在过去的几年里，图数据库世界产生了巨大的影响，特别是与社交网络及其对我们日常活动的影响有关。
曾经强大（且孤独）的 RDBMS 现在不得不为数据中心中新兴且日益重要的合作伙伴腾出空间：图形数据库。
Twitter 在使用它，Facebook 在使用它，甚至在线约会网站也在使用它；他们正在使用关系图。毕竟，社交就是社交，归根结底还是关系。
图技术有两个主要的区别要素：存储和处理。
图存储通常是指包含图数据的数据库结构。
这种图存储针对图进行了多方面的优化，保证了数据的高效存储，使实际物理层的节点和关系保持紧密。
当存储来自外部源（例如关系型数据库、列式数据库或任何其他类型的数据库）时，图存储被归类为非本机存储（大多数情况下，NoSQL 存储更可取）
非原生图数据库通常由现有的关系、文档和键值存储组成，适用于图数据模型查询场景。
图处理包括访问图、遍历顶点和边以及收集结果。
遍历是查询图的方式，从起始节点导航到相关节点，根据某些规则遵循关系。
找到诸如“我的朋友喜欢但我还没有拥有哪些音乐？”之类的问题的答案。
表示图的更流行的模型之一是属性模型。
该模型包含连接的实体（节点），可以保存任意数量的属性（键值对）。
节点有一个唯一的 ID 和代表其特征和内容的属性列表。
可以用代表节点在域中不同角色的标签来标记节点。除了关系属性之外，标签还可以通过图形元素提供元数据。
节点通常用于表示实体，但根据域关系也可以用于该目的。
关系由它们连接的源节点和目标节点表示，并且在同一顶点之间存在多个连接的情况下 - 用于区分的属性的附加标签（关系类型）
关系将节点组织成任意结构，允许图形类似于列表、树、地图或复合实体——其中任何一个都可以组合成更复杂的结构。
非常类似于关系数据库模型中表之间的外键，在图模型中关系描述了顶点之间的关系。
该模型的一个主要区别（与严格的关系模式相比）是这种无模式结构可以在没有任何约束的情况下添加/删除顶点之间的关系。
附加图模型是资源描述框架（RDF）模型。
我们的用例是在社交网络领域。一个非常大的社交图，必须经常更新并且可供以下两者使用：
简单（主要是文本）搜索
基于图的查询。
所有读取和写入都是并发进行的，具有合理的响应时间和不断增长的吞吐量。
第一个要求是使用 Opensearch 来满足的——一个众所周知的、成熟的 NoSql 文档搜索和存储引擎，能够包含大量数据。
对于第二个要求，我们决定最好的解决方案是使用 Opensearch 作为非本机图形数据库存储层。
如前所述，图 DB 存储层可以使用非本机存储（例如 NoSql 存储）来实现。
在以后的讨论中，我将详细说明为什么最流行的图形数据库社区替代方案 Neo4J 无法满足我们的需求。
我们面临的第一个问题是设计表示图形的数据模型，作为一组顶点和边。
通过Opensearch，我们可以利用其强大的搜索能力根据查询过滤器有效地获取节点和关系文档。
在 Opensearch 中，每个索引都可以描述为特定模式的表，索引本身被划分为共享索引，从而允许跨集群进行扩展和冗余（带有副本）。
使用以下公式将文档路由到索引中的特定分片：
shard_num = hash(_routing) % num_primary_shards
每个索引都有一个模式（在 Opensearch 中称为类型），它定义文档结构（在 Opensearch 中称为映射）。每个索引只能保存一种类型的映射（自 Opensearch 6 起）
顶点索引将包含具有属性的顶点文档，边缘索引将包含具有其属性的边缘文档。
我们描述如何遍历图的方式（数据源）
面向图的查询语言很少：
Cypher 是 Neo4j 图形数据库的查询语言（请参阅 openCypher 倡议）
Gremlin 是一种用于 OLTP 和 OLAP 图形系统的 Apache Software Foundation 图形遍历语言。
SPARQL 是 RDF 图的查询语言。
有些语言更加基于模式和声明性，有些则更加命令式——它们都描述了遍历数据的逻辑方式。
让我们考虑一下 Cypher——一种受 SQL 启发的声明性语言，用于使用 ascii-art 语法直观地描述图形中的模式。
它允许我们声明我们想要从图形数据中选择、插入、更新或删除什么，而不需要我们准确地描述如何去做。
一旦给出逻辑查询，我们需要将其转换为数据存储的物理层，即 Opensearch。
Opensearch 有一个查询 DSL，它专注于搜索和聚合——而不是遍历，我们需要一个额外的转换阶段来考虑图的示意结构（和底层索引）。
逻辑查询到物理查询的转换是一个涉及以下几个步骤的过程：
根据架构验证查询
将标签转换为真实的模式实体（索引）
创建物理 Opensearch 查询
这是一个高层回顾中的过程，在实践中——会有更多的阶段来优化逻辑查询；在某些情况下，可以创建多个物理计划（执行计划）并根据某些效率（成本）策略对它们进行排名，例如获取所需的元素数量...
我们首先讨论了图形数据库在当今业务用例中的用途，并回顾了表示图形的不同模型。了解潜在图数据库应包含的基本逻辑构建块，并讨论现有的 NoSql 候选者以满足存储层要求。
一旦我们选择 Opensearch 作为存储层，我们就采用 LDBC 社交网络基准图模型并将其简化以在特定存储中进行优化。我们讨论了具有冗余属性的实际存储模式，并回顾了密码语言，以类似 sql 的图形模式语言查询存储。
我们继续看到密码查询实际转换为将由 Opensearch 运行的物理执行查询。
在上一节中，我们进行了一个简单的图形查询，并深入研究了执行策略和批量机制的细节。
安装教程：
架构创建教程：
数据加载教程：
查询Graph教程：
投影物化和计数教程：
