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教學：
投影物化和計數教程：
