目錄
3.NOSQL象限（The NOSQL Quadrants）
5.Key-Value 存儲（Key-Value Stores）
近年來，一系列稱爲NOSQL的數據存儲技術的流行迅速增長（NOSQL的厚臉皮首字母縮寫，或者更具爭議性的No表示SQL）。 但是NOSQL定義了不是這些數據存儲區（不是以SQL爲中心的關係數據庫）而不是它們，這是一組有趣且有用的存儲技術，其操作，功能和體系結構特徵很多，而且多變。
爲什麼創建這些新數據庫？ 他們解決什麼問題？ 在這裏，我們將討論過去十年中出現的一些新數據挑戰。 然後，我們將研究四個NOSQL數據庫家族，包括圖形數據庫。
1.NOSQL的興起
從歷史上看，大多數企業級Web應用程序都運行在關係數據庫之上。 但是在過去的十年中，與傳統的RDBMS部署相比，我們面臨的數據量更大，變化更快，結構上的變化也更大。 面對這些挑戰，出現了NOSQL運動。
毫不奇怪的是，隨着存儲量的急劇增加，數量已成爲組織採用NOSQL存儲量的主要推動力。 卷可以簡單定義爲存儲數據的大小。
衆所周知，大型數據集存儲在關係數據庫中後變得笨拙，尤其是查詢執行時間隨着表的大小和聯接數量的增加而增加（所謂的聯接痛苦）。 這不是數據庫本身的問題。 而是它是基礎數據模型的一個方面，該模型在過濾以獲取正確的解決方案之前爲查詢構建一組所有可能的答案。
爲了避免連接和連接痛苦，從而更好地處理超大型數據集，NOSQL世界採用了關係模型的幾種替代方法。 儘管這些替代模型更擅長處理非常大的數據集，但它們的表達性往往不如關係模型（圖模型除外，後者實際上更具表達性）。
但是數量並不是現代面對Web的系統必須解決的唯一問題。除了龐大之外，當今的數據通常變化非常迅速。 速度是數據隨時間變化的速率。
速度很少是靜態指標。 系統的內部和外部更改以及使用該系統的環境可能會對速度產生很大影響。 加上高容量，可變速度要求數據存儲不僅要處理持續的高寫入負載水平，還要處理峯值。
速度還有另一個方面，即數據結構變化的速率。 換句話說，除了更改特定屬性的值之外，承載這些屬性的元素的整體結構也可以更改。 發生這種情況通常有兩個原因。 首先是快速發展的業務動態。 隨着業務的變化，其數據需求也隨之變化。 其次，數據採集通常是實驗性的事情。 某些屬性是“以防萬一”的，而其他屬性則根據變化的需求在以後引入。 被證明對企業有價值的產品仍然存在，而其他產品則被淘汰。 這兩種形式的速度在關係世界中都是有問題的，在關係世界中，高寫入負載轉化爲高處理成本，而高模式波動性則具有高運營成本。
儘管評論員後來在最初的規模追求中增加了其他有用的要求，但最後一個關鍵方面是認識到數據遠比我們在關係世界中處理的數據變化得多。 爲了存在證明，請考慮我們表中的所有這些null和代碼中的null檢查。 這驅使最終達成共識的方面多樣化，我們將其定義爲數據規則或不規則結構，密集或稀疏，連接或斷開的程度。
2.ACID 與 BASE
當我們第一次遇到NOSQL時，通常是在我們許多人已經熟悉的背景下進行：關係數據庫。 儘管我們知道數據和查詢模型會有所不同（畢竟，沒有SQL），但NOSQL存儲使用的一致性模型也可能與關係數據庫使用的一致性模型完全不同。 許多NOSQL數據庫使用不同的一致性模型來支持先前討論的數據量，速度和數據種類的差異。
讓我們探討一下哪些可用的一致性功能可幫助確保數據安全，以及在使用（大多數）NOSQL存儲時需要進行哪些取捨。
在關係數據庫世界中，我們都熟悉ACID交易，這種交易已經有一段時間了。 ACID保證爲我們提供了一個安全的環境，可在其中操作數據：
- 原子性（Atomic）
- 事務中的所有操作都會成功，或者每個操作都會回滾。
- 一致性（Consistent）
- 事務完成後，數據庫在結構上是健全的。
- 獨立性（Isolated）
- 事務不相互競爭。 數據庫控制對狀態的有爭議訪問，以便事務似乎按順序運行。
- 持久性（Durable）
- 即使存在故障，應用事務的結果也是永久的。
這些屬性意味着，一旦事務完成，其數據便是一致的（所謂的寫一致性），並且在磁盤（或多個磁盤，或者實際上在多個不同的內存位置）中是穩定的。 對於應用程序開發人員來說，這是一個奇妙的抽象，但是需要複雜的鎖定，這可能導致邏輯上的不可用性，並且在大多數情況下，通常被認爲是重量級的模式。
對於許多域，ACID事務比域實際需要的更爲悲觀。 在NOSQL世界中，ACID事務已經過時，因爲存儲鬆動了對即時一致性，數據新鮮度和準確性的要求，以便獲得其他好處，例如規模和彈性。 代替使用ACID，術語BASE已成爲一種描述更樂觀的存儲策略屬性的流行方式：
- 基本可用性（Basic availability）
- 該存儲似乎大部分時間都在工作。
- 軟態（Soft-state）
- 存儲不必保持寫一致，不同的副本也不必始終保持一致。
- 最終一致性（nt all the time.）
- 存儲在以後的某個時刻表現出一致性（例如，在讀取時懶惰）。
BASE屬性比ACID保證要寬鬆得多，並且它們之間沒有直接映射。 BASE存儲重視可用性（因爲這是規模擴展的核心組成部分），但不能在寫入時提供副本的保證一致性。 BASE存儲提供了不太嚴格的保證：將來數據可能保持一致，例如在讀取時（例如Riak），或者始終保持一致，但僅適用於某些經過處理的過去快照（例如Datomic）。
鑑於對一致性的寬鬆支持，我們（開發人員）在考慮數據一致性時需要更加了解和嚴格。 我們必須熟悉所選存儲的BASE行爲，並在這些約束內工作。 在應用程序級別，我們必須根據具體情況選擇是否接受可能不一致的數據，或者是否指示數據庫在讀取時提供一致的數據，同時導致隱含的延遲損失。 （爲了保證一致的讀取，數據庫將需要比較數據元素的所有副本，並且在不一致的結果中甚至需要對該數據執行補救性修復工作。）從開發角度來看，這與依賴的簡單性相去甚遠。 代表我們管理一致狀態的事務，儘管這不一定是一件壞事，但這確實需要付出努力。
3.NOSQL象限（The NOSQL Quadrants）
在討論了可增強NOSQL存儲一致性的BASE模型之後，我們準備開始研究衆多的用戶級數據模型。 爲了消除這些模型的歧義，我們設計了一種簡單的分類法，如圖A-1所示。 這種分類法將當代的NOSQL空間劃分爲四個象限。 每個象限中的存儲都針對不同類型的功能用例，儘管非功能性需求也會極大地影響我們對數據庫的選擇。
在以下各節中，我們將處理這些象限中的每個象限，重點介紹數據模型的特徵，操作方面以及採用的驅動因素。
4.文件存儲（Document Stores）
文檔數據庫爲習慣於使用層次結構文檔的開發人員提供了最直接熟悉的範例。 文檔數據庫存儲和檢索文檔，就像電子文件櫃一樣。 文檔往往由地圖和列表組成，允許自然的層次結構-就像我們習慣使用JSON和XML這樣的格式一樣。
在最簡單的級別上，可以通過ID存儲和檢索文檔。 只要應用程序能夠記住其感興趣的ID（例如用戶名），文檔存儲就可以像鍵值存儲一樣工作（我們將在以後進行介紹）。 但是在一般情況下，文檔存儲依賴索引來根據其屬性來方便地訪問文檔。 例如，在電子商務場景中，我們可能使用索引來表示不同的產品類型，以便可以將其提供給潛在的賣方，如圖A-2所示。 通常，索引用於從存儲中檢索相關文檔集，以供應用程序使用。
與關係數據庫中的索引非常相似，文檔存儲中的索引使我們能夠以寫入性能爲代價來獲得更高的讀取性能。 寫操作成本更高，因爲它們還維護索引，但是讀操作需要掃描較少的記錄才能找到相關數據。 對於繁重的記錄，需要牢記的是索引實際上可能會降低整體性能。
在沒有索引數據的地方，查詢通常要慢得多，因爲必須對數據集進行完全搜索。 顯然，這是一項昂貴的任務，應儘可能避免。而且，正如我們將看到的那樣，而不是在內部處理這些查詢，對於文檔數據庫用戶來說，在並行計算框架中外部化這種處理是正常的。
因爲文檔存儲的數據模型是斷開連接的實體之一，所以文檔存儲往往具有有趣且有用的操作特徵。 由於在寫時相互獨立的記錄之間沒有競爭狀態，並且不需要在副本之間進行事務處理，因此它們應該水平縮放。
分片（Sharding）
大多數文檔數據庫要求用戶計劃跨實例的數據分片以支持水平擴展。 因此，向外擴展成爲開發和運營的明確方面。 相比之下，鍵值和列族數據庫往往不需要這種計劃，因爲它們將數據分配給副本作爲其內部實現的正常部分。 有時令人費解地認爲這是選擇文檔存儲區的積極原因，最有可能是因爲它引起（錯位）興奮，即通過分片進行縮放是一種應被接受和稱讚的東西，而不是被熟練而勤奮地掌握的東西。
對於寫操作，歷史上，文檔數據庫提供的事務性僅限於單個記錄的級別。 也就是說，文檔數據庫將確保對單個文檔的寫入是原子的-假設管理員在設置數據庫時選擇了安全的持久性級別。 在此類別中逐漸出現了對跨文檔集進行操作的支持，但還不成熟。 在沒有多鍵事務的情況下，應由應用程序開發人員在應用程序代碼中編寫補償邏輯。
由於未連接存儲的文檔（通過索引除外），因此有許多樂觀的併發控制機制可用於幫助協調單個文檔的併發競爭寫入，而不必求助於嚴格的鎖定。 實際上，某些文檔存儲區（例如CouchDB）已將其作爲其價值主張的關鍵點：文檔可以保存在多主數據庫中，該數據庫在多個實例之間自動複製併發訪問的競爭狀態，而不會受到用戶的過度干擾。
在其他存儲中，數據庫管理系統也可能能夠區分和協調對文檔不同部分的寫入，甚至可以使用時間戳將多個競爭寫入協調爲一個邏輯上一致的結果。 這是一個合理的樂觀權衡，因爲它通過使用可替代的機制來減少對事務的需求，這些機制可樂觀地控制存儲，同時力爭提供更低的延遲和更高的吞吐量。
5.Key-Value 存儲（Key-Value Stores）
鍵值存儲是文檔存儲家族的表親，但它們的血統來自亞馬遜的Dynamo數據庫。 它們的作用就像大型的分佈式哈希圖數據結構，可通過鍵存儲和檢索不透明值。
如圖A-3所示，哈希圖的密鑰空間分佈在網絡上的多個存儲桶中。 出於容錯原因，每個存儲桶都複製到多臺計算機上。 R = 2F +1給出了所需副本數的公式，其中F是我們可以容忍的故障數。 複製算法旨在確保計算機不是彼此完全相同的副本。 這允許系統在機器及其存儲桶恢復時進行負載平衡。 它還有助於避免熱點，因爲熱點可能導致疏忽的自我拒絕服務。
從客戶的角度來看，鍵值存儲易於使用。 客戶端通過散列特定於域的標識符（鍵）來存儲數據元素。 哈希函數經過精心設計，可以在可用存儲區之間提供均勻的分佈，從而確保沒有一臺計算機成爲熱點。 給定哈希鍵，客戶端可以使用該地址將值存儲在相應的存儲桶中。 客戶使用類似的過程來檢索存儲的值。
一致的散列（Consistent Hashing）
所有計算機系統都會發生故障。 在可靠的系統中，這些故障通過爲故障組件接通冗餘替代件來掩蓋。 在鍵值存儲中（與任何分佈式數據庫一樣），在正常運行期間，隨着網絡中斷或硬件出現故障，個別計算機可能變得不可用。 只要從此類故障中恢復過來的副作用不會引起進一步的問題，就可以認爲此類事件是正常的。 例如，如果支持特定哈希範圍的計算機發生故障，則在進行內部重組時，不應阻止該範圍內的新值被存儲或導致不可用。
這就是一致性哈希起作用的地方。 使用此技術，可以將對失敗的哈希範圍的寫入廉價地重新映射到下一臺可用的計算機，而不會干擾整個存儲的數據集。 實際上，在許多情況下，僅需要重新映射失敗範圍內的一部分鍵，而不是整個鍵。 當故障機器恢復或更換後，一致的哈希再次確保僅重新映射總密鑰空間的一小部分。
給定這種模型，希望將數據存儲在鍵值存儲中或從中獲取數據的應用程序僅需要知道（或計算）相應的鍵。 儘管密鑰集中有很多可能的密鑰，但實際上，密鑰往往會很自然地從應用程序領域掉出來。 用戶名和電子郵件地址，興趣點的笛卡爾座標，社會保險號和郵政編碼都是各個域的自然鍵。 使用合理設計的系統，由於缺少密鑰而導致存儲中的數據丟失的可能性很小。
鍵值數據模型類似於文檔數據模型。 它們與衆不同之處在於它們對數據的洞察力。
從理論上講，鍵值存儲會忽略其值中包含的信息。 純粹的鍵值存儲只是關心代表應用程序有效地存儲和檢索不透明數據，而不受其性質和應用程序使用的限制。
不透明度和對結構化數據內部子元素的訪問
不透明度有一個缺點。 從存儲的值中提取數據元素時，客戶端通常必須檢索整個值，然後過濾掉不需要的父級或同級數據元素。 與在服務器上執行此類操作的文檔存儲相比，這可能效率較低。
實際上，這種區分並不總是那麼清晰。 一些流行的鍵值存儲（例如Riak）還提供對某些類型的結構化存儲數據（如XML和JSON）的可見性。 它還支持某些核心數據類型（稱爲CRDT），即使在存在併發寫入的情況下也可以放心地合併它們。 在產品級別上，文檔和鍵值存儲之間存在一些重疊。
儘管鍵值模型很簡單，但與文檔模型一樣，它對應用程序開發人員的數據洞察也很少。 爲了從各個記錄中檢索有用的信息集，我們通常使用外部處理基礎結構，例如MapReduce。 與在數據存儲區中執行查詢相比，這是高度潛在的。
鍵值存儲提供某些運營和規模優勢。 它們來自Amazon的Dynamo數據庫（一個專爲不間斷購物車服務設計的平臺），因此往往針對高可用性和可擴展性進行了優化。 或者，就像亞馬遜團隊所說的那樣，即使“如果磁盤出現故障，網絡路由震盪或數據中心被龍捲風破壞，它們也應該工作”。
6.列族（Column Family）
列族存儲以Google的BigTable爲模型。 數據模型基於人口稀少的表，該表的行可以包含任意列，爲其提供自然索引的鍵。
在我們的討論中，我們將使用Apache Cassandra的術語。Cassandra不一定是BigTable的忠實解釋，但它已經得到廣泛部署，並且其術語已廣爲人知。
在圖A-4中，我們看到了列族數據庫中使用的四個常見構建基塊。 最簡單的存儲單元是列本身，由名稱/值對組成。 可以將任意數量的列組合爲一個超級列，該超級列爲一組排序的列命名。 列存儲在行中，當行僅包含列時，稱爲列族。 當一行包含超級列時，它被稱爲超級列族。
當數據模型表面上是列狀時，專注於行可能看起來很奇怪，但是單個行很重要，因爲它們提供了嵌套的哈希映射結構，我們可以將數據進行非規範化。 在圖A-5中，我們展示瞭如何將唱片藝術家和他的專輯映射到一個超級列族結構中-從邏輯上講，這實際上只是地圖。
在列族數據庫中，表中的每一行代表一個特定的總體實體（例如，關於藝術家的所有內容）。 這些欄目族是包含相關數據（例如藝術家的姓名和唱片目錄）的容器。 在列族中，我們可以找到實際的鍵值數據，例如專輯發行日期和藝術家的出生日期。
有用的是，可以將此面向行的視圖旋轉90度，以達到面向列的視圖。 每行給出一個實體的完整視圖時，列視圖自然會在整個數據集中索引特定方面。 例如，如圖A-6所示，通過“排隊”鍵，我們可以找到藝術家爲英語的所有行。 從那裏很容易從每一行中提取完整的藝術家數據。 它不是我們在圖中發現的關聯數據，但至少可以提供對一組相關實體的深入瞭解。
列族數據庫與文檔和鍵值存儲區的區別不僅在於其更具表現力的數據模型，還在於其操作特性。 例如，Apache Cassandra基於類似於Dynamo的基礎架構，其設計旨在進行分發，擴展和故障轉移。 在幕後，它使用了多個存儲引擎來處理較高的寫入負載，這是由流行的交互式電視節目產生的峯值寫入負載。
總體而言，列族數據庫具有合理的表達能力，並且在操作上非常稱職。 但是，它們仍然像文檔和鍵值數據庫一樣是聚合存儲，因此仍然缺少聯接。 查詢它們以深入瞭解數據需要一些外部應用程序基礎結構進行處理。
7.彙總存儲中的查詢與處理
在前面的部分中，我們重點介紹了文檔，鍵值和列族數據模型之間的異同。 總而言之，相似之處大於差異之處。 實際上，相似性是如此之大，有時將這三種類型統稱爲集合存儲。 聚合存儲持久保存獨立的複雜記錄，這些記錄反映了聚合的域驅動設計概念。
儘管每個聚合存儲都有不同的存儲策略，但是在查詢數據時，它們都有很多共同點。 對於簡單的即席查詢，每個查詢都傾向於提供諸如索引，簡單的文檔鏈接或查詢語言之類的功能。 對於更復雜的查詢，應用程序通常先從商店中識別並提取數據的子集，然後再通過一些外部處理基礎結構（如MapReduce框架）將其進行管道傳輸。 當無法簡單地通過檢查單個集合來生成必要的深入洞察力時，執行此操作。
像BigTable一樣，MapReduce是Google提供的另一項技術。 MapReduce上最流行的開源實現是Apache Hadoop及其附帶的生態系統。
MapReduce是一個並行編程模型，可對數據進行拆分並對其進行並行操作，然後再將其收集回並彙總以提供重點信息。 例如，如果我們想用它來計算唱片藝術家數據庫中有多少美國藝術家，那麼我們將提取所有藝術家記錄並在地圖階段丟棄非美國藝術家，然後計算剩餘記錄 在還原階段。
即使有很多機器和快速的網絡基礎結構，MapReduce也會具有很大的潛能。 通常，我們會使用數據存儲區的功能來提供更集中的數據集（也許使用索引或其他臨時查詢），然後MapReduce較小的數據集來得出答案。
聚合存儲庫不是爲處理高度關聯的數據而構建的。 我們可以嘗試將它們用於此目的，但是我們必須添加代碼來填充基礎數據模型遺留的地方，從而導致開發經驗遠非無縫的，並且操作特性通常不是很快，特別是隨着跳數（或查詢的“度”）增加。 聚合存儲可能擅長存儲大數據，但不適用於處理需要了解事物之間如何連接的問題。
8.圖數據庫
圖形數據庫是具有創建，讀取，更新和刪除（CRUD）方法的在線可操作數據庫管理系統，可公開圖形數據模型。 圖形數據庫通常是爲與事務（OLTP）系統一起使用而構建的。 因此，它們通常針對事務性能進行優化，並且在設計時要考慮事務的完整性和操作可用性。
在研究圖形數據庫技術時，圖形數據庫的兩個屬性對於理解很有幫助：
- 基礎存儲
- 一些圖形數據庫使用本機圖形存儲，該存儲是針對存儲和管理圖形進行優化和設計的。 但是，並非所有的圖形數據庫技術都使用本機圖形存儲。 一些將圖形數據序列化爲關係數據庫，面向對象的數據庫或其他類型的NOSQL存儲。
- 處理引擎
- 圖形數據庫的某些定義要求它們能夠無索引鄰接，這意味着連接的節點在數據庫中在物理上彼此“指向”。 在這裏，我們有一個更廣泛的看法。 從用戶的角度來看，任何行爲類似於圖形數據庫（即通過CRUD操作公開圖形數據模型）的數據庫都屬於圖形數據庫。 但是，我們確實認識到無索引鄰接在性能方面的顯着優勢，因此在引用利用無索引鄰接的圖數據庫時使用術語本機圖處理。
圖形數據庫（尤其是本機數據庫）在很大程度上不依賴索引，因爲圖形本身提供了自然的鄰接索引。 在本機圖形數據庫中，附加到節點的關係自然會提供與其他相關感興趣節點的直接連接。 圖查詢使用該局部性通過追逐指針來遍歷圖。 與通過全局索引連接數據相比，這種操作效率極高，每秒可遍歷數百萬個節點，而全局索引的速度要慢許多個數量級。
除了採用特定的存儲和處理方法之外，圖形數據庫還將採用特定的數據模型。 常見用法有幾種不同的圖數據模型，包括屬性圖，超圖和三元組。 我們在下面討論每種模型。
8.1.屬性圖（Property Graphs）
屬性圖具有以下特徵：
- 它包含節點和關係。
- 節點包含屬性（鍵值對）。
- 節點可以用一個或多個標籤標記。
- 關係是命名和定向的，並且始終具有起點和終點。
- 關係也可以包含屬性。
8.2.超圖（Hypergraphs）
超圖是一種通用圖模型，其中關係（稱爲超邊）可以連接任意數量的節點。 屬性圖模型允許一個關係只有一個開始節點和一個結束節點，而超圖模型則允許在關係的任一端有任意數量的節點。 當域主要由多對多關係組成時，超圖很有用。 例如，在圖A-7中，我們看到愛麗絲和鮑勃是三輛車的所有者。 我們使用單個超邊來表達，而在屬性圖中我們將使用六個關係。
正如我們在第3章中討論的那樣，圖形使我們能夠以易於可視化和理解的方式對問題域進行建模，並以高保真度捕獲現實世界中遇到的數據的許多細微差別。 儘管從理論上說，超圖可以生成準確的，信息豐富的模型，但實際上，在建模時我們很容易錯過一些細節。 爲了說明這一點，讓我們考慮圖A-8中所示的圖，它是與圖A-7中所示的超圖等效的屬性圖。
此處顯示的屬性圖需要幾個OWNS關係來表達僅用一個就捕獲的超圖。 但是，在使用多種關係時，我們不僅可以使用一種熟悉且非常明確的建模技術，而且還可以對模型進行微調。 例如，我們通過在相關關係中添加屬性來確定每種車輛的“主要駕駛員”（出於保險目的），而這是單條超邊緣無法實現的。
因爲超邊緣是多維的，所以超圖比屬性圖包含更通用的模型。 也就是說，這兩個模型是同構的。 始終可以將超圖中的信息表示爲屬性圖（儘管使用更多的關係和中間節點）。 超級圖或屬性圖最適合您將取決於您的建模思想和所構建的應用程序類型。 有趣的是，在大多數情況下，屬性圖被廣泛認爲具有實用性和建模效率的最佳平衡，因此它們在圖數據庫領域非常受歡迎。 但是，在需要捕獲元意圖，有效地限定一種關係與另一種關係的情況下（例如，我喜歡您喜歡那輛車的事實），與屬性圖相比，超圖通常需要更少的圖元。
8.3.三元組（Triples）
三重存儲來自語義Web運動，研究人員通過將語義標記添加到連接Web資源的鏈接中，對大規模知識推理感興趣。 迄今爲止，很少有Web以有用的方式進行標記，因此在語義層上運行查詢並不常見。 取而代之的是，語義Web上的大部分工作似乎都花在了從Web（或其他更平凡的數據源，例如應用程序）中收集有用的數據和關係信息，並將其存儲在三重存儲中以進行查詢。
三元組是主語-謂語-賓語數據結構。 使用三元組，我們可以捕獲事實，例如“姜與弗雷德共舞”和“弗雷德喜歡冰淇淋”。單獨地，三元組在語義上相當差，但是在大量處理中，它們提供了豐富的數據集，可以從中收集知識並推斷出聯繫。 。 三重存儲通常提供SPARQL功能來推理和存儲RDF數據。
RDF（三元商店的通用語言和語義網）可以幾種方式進行序列化。 下面的代碼片段顯示瞭如何使用RDF / XML格式將三元組組合在一起以形成鏈接數據：
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns="http://www.example.org/terms/">
<rdf:Description rdf:about="http://www.example.org/ginger">
<name>Ginger Rogers</name>
<occupation>dancer</occupation>
<partner rdf:resource="http://www.example.org/fred"/>
</rdf:Description>
<rdf:Description rdf:about="http://www.example.org/fred">
<name>Fred Astaire</name>
<occupation>dancer</occupation>
<likes rdf:resource="http://www.example.org/ice-cream"/>
</rdf:Description>
</rdf:RDF>
W3C Support
三重存儲的實現方式有所不同。 商店不必具有類似於三元組的內部實現即可生成三元組的邏輯表示。 但是，大多數三重存儲由於對語義Web技術（如RDF和SPARQL）的支持而統一。
儘管RDF沒有什麼特別的作爲序列化鏈接數據的方法，但是它已得到W3C的認可，因此可以從被廣泛理解和充分記錄中受益。 查詢語言SPARQL受益於類似的W3C支持。
在圖數據庫空間中，圍繞圖序列化格式（例如GEOFF）和推理查詢語言（例如我們在本書中使用的Cypher查詢語言）也有大量類似的創新。 關鍵區別在於，儘管這些創新確實得益於用戶和供應商社區的大力參與，但它們在這一點上並沒有得到像W3C這樣受人尊敬的機構的支持。
三重存儲屬於圖數據庫的一般類別，因爲它們處理的數據（一旦處理）往往被邏輯鏈接。 但是，它們不是“本機”圖數據庫，因爲它們不支持無索引的鄰接關係，並且它們的存儲引擎也未針對存儲屬性圖進行優化。 三元組存儲將三元組存儲爲獨立的工件，這使它們可以水平擴展以進行存儲，但可以阻止它們快速遍歷關係。 要執行圖查詢，三元組存儲必須根據獨立事實創建連接的結構，這會增加每個查詢的延遲。 由於這些原因，三重存儲的最佳選擇是分析，其中延遲是次要考慮因素，而不是OLTP（響應性在線事務處理系統）。
儘管圖數據庫主要是爲遍歷性能和執行圖算法而設計的，但可以將它們用作RDF / SPARQL端點後面的後備存儲。 例如，Blueprints SAIL API提供了到包括Neo4j在內的幾個圖形數據庫的RDF接口。 在實踐中，這意味着圖形數據庫和三元組存儲之間的功能同構水平。 但是，每種商店類型都適用於不同類型的工作負載，其中圖數據庫針對圖工作負載和快速遍歷進行了優化。