Espresso NoSQL分布式NoSQL數(shù)據(jù)庫

Espresso 是一個來自 LinkedIn 的分布式 NoSQL 數(shù)據(jù)庫，其具有高性能、高擴展性、支持事務、容錯能力等重要特征。在LinkedIn，Espresso有著強大的應用規(guī)模，它運行在十幾個集群中，并且已有將近30個應用在使用Espresso，如Member Profile、InMail、LinkedIn的手機客戶端等。在高峰期，它能夠每秒處理數(shù)百萬的訪問記錄。Espresso由LinkedIn的分布式數(shù)據(jù)系統(tǒng)團隊基于高性能的數(shù)據(jù)抓取系統(tǒng)Databus、R2D2、通用的集群管理框架Apache Helix等開源技術開發(fā)，用來解決關系型數(shù)據(jù)庫（如MySQL、Oracle等）不能滿足當前線上并發(fā)業(yè)務的性能要求的問題以及關系型數(shù)據(jù)庫固有的一些局限性，如擴展性差、容錯處理能力差、成本高等。

Espresso具有一個分層的數(shù)據(jù)模型，其結(jié)構為數(shù)據(jù)庫（Database）->表（Table）>集合 （Collection）->文檔（Document）。Espresso使用JSON數(shù)據(jù)格式定義數(shù)據(jù)庫Schema和表Schema，使用數(shù)據(jù)序列化的系統(tǒng)Apache Avro定義文檔Schema。 Espresso的表是同一類型文檔的容器，使用指定Key所確定的文檔就是一個集合，一個指定的Key唯一確定一個文檔，一個文檔Schema對應一個 Avro的Schema。Espresso提供了簡單、易用的讀/寫操作的REST風格API和基于Last-Modified 和 ETag的條件操作API，其中的寫操作API還具有事務性。

Espresso的整個架構如下圖所示：

• 路由器（Router）

  路由器是一個無狀態(tài)的HTTP代理，它是客戶端訪問Espresso的入口。路由器首先檢查請求的URL以確定需要訪問的數(shù)據(jù)庫（除了內(nèi)部的 Schema注冊數(shù)據(jù)庫，該數(shù)據(jù)庫能夠映射到任何節(jié)點），并根據(jù)分區(qū)Key以確定請求對應的分區(qū)，并將請求轉(zhuǎn)發(fā)到對應的存儲節(jié)點。路由器還有一個本地的緩 存路由表，該路由表映射分區(qū)的分布情況。當集群的狀態(tài)發(fā)生變化時，路由表通過分布式應用程序協(xié)調(diào)服務應用Apache ZooKeeper實現(xiàn)路由器的更新，并以并行的方式實現(xiàn)跨分區(qū)的批量請求。

• 存儲節(jié)點（Storage Node）

  存儲節(jié)點是集群擴展和數(shù)據(jù)存儲的基本單元，每個存儲節(jié)點都包括一套分區(qū)。路由器能夠?qū)l(fā)送請求轉(zhuǎn)發(fā)到存儲節(jié)點，存儲節(jié)點的功能包括查詢處理、作為存儲引擎、實現(xiàn)二級索引、處理節(jié)點狀態(tài)的轉(zhuǎn)換、支持本地事務、提交復制日志、定時備份以及一致性檢查和數(shù)據(jù)驗證等工具類功能。

• 集群管理框架Helix

  Espresso使用Helix 進行集群管理。Espresso的狀態(tài)模型具有OFFLINE、SLAVE和MASTER狀態(tài)。Espresso的狀態(tài)模型約束包括每個分區(qū)必須至少有一 個Master節(jié)點和n個可配置的Slave節(jié)點、分區(qū)分布在所有的存儲節(jié)點上、在同一個基點上不存在同一分區(qū)的副本、當Master節(jié)點出現(xiàn)故障 時，Slave節(jié)點要能夠升級成為Master節(jié)點。

• 低延遲數(shù)據(jù)抓取系統(tǒng)Databus

  Espresso使用Databus實現(xiàn)變化捕獲機制，Databus能夠處理Espresso事務日志，Databus的重要特征包括來源獨 立、可擴展、高度可用、低延遲、支持多種訂閱機制和無限回溯等。Espresso使用Databus目的包括：（1）將事件傳遞給下游消費者，如搜索的索 引和緩存等；（2）實現(xiàn)Espresso的多數(shù)據(jù)中心的復制。Databus的結(jié)構如下圖所示：

  

• 數(shù)據(jù)復制服務（Data Replicator）

  數(shù)據(jù)復制是一個在跨地域復制的Espresso集群間轉(zhuǎn)發(fā)提交請求的服務，該服務由Helix管理的無狀態(tài)集群實例構成，并具有容錯處理能力和線 上/線下的Helix狀態(tài)模型。數(shù)據(jù)復制服務是Databus的一個Consumer，用來處理集群中的數(shù)據(jù)庫分區(qū)事件，它還能夠在數(shù)據(jù)中心之間批量處理 事件以提升高延遲的鏈接線路的吞吐量。該服務定期檢查ZooKeeper的復制進度以及節(jié)點故障、服務重啟等，每個節(jié)點負責一定數(shù)量分區(qū)的復制，具體負責 哪些分區(qū)由Helix指定。一旦節(jié)點發(fā)生故障，屬于故障節(jié)點負責的分區(qū)會被重新分配給正常的節(jié)點。當一個節(jié)點開始處理新指派的分區(qū)時，它會從保存在 Zookeeper中的最近檢查點重新執(zhí)行相關處理/操作。

• 快照服務（Snapshot Service）

  快照服務能夠自動、定期地備份數(shù)據(jù)中心的所有Espresso節(jié)點的數(shù)據(jù)，且對正在運行的集群影響非常小?？煺辗毡旧硪彩且粋€分布式系統(tǒng)，并與 數(shù)據(jù)復制服務一樣具有相同的線上/下狀態(tài)模型。最近備份的元數(shù)據(jù)信息也將寫入到ZooKeeper，叫做“znode”的節(jié)點是存儲元數(shù)據(jù)的地方。

Espresso的關鍵特征和實現(xiàn)細節(jié)內(nèi)容如下：

• 序列號-- Espresso時鐘

  Espresso使用一個內(nèi)置的時鐘以確定事件的全序關系，時序?qū)洪g的復制和Databus都是非常重要的。每個成功的操作（如插入、更新、刪除）都分配了一個64位的系統(tǒng)改變碼（SCN），SCN由MySQL在事務提交時生成，其是單調(diào)遞增且由每個分區(qū)獨立維護。

• Schema的管理

  Espresso的Schema存儲在ZooKeeper中，該組件在所有服務中可共享。

• Schema的演變

  Espresso的文檔Schema根據(jù)Avro的Schema演化規(guī)則的改變而改變，且還有一些的規(guī)范限制。

• 容錯處理

  Espresso的集群管理使用Helix來實現(xiàn)，存儲節(jié)點是真是數(shù)據(jù)的來源，所以容錯功能是至關重要的。在Espresso中，每個節(jié)點既有 Slave分區(qū)，也有Master分區(qū)。容錯處理的情況包括（1）當一個存儲節(jié)點連接到Helix時，該節(jié)點會在Zookeeper中創(chuàng)建一個臨時節(jié)點， 該節(jié)點由Helix監(jiān)視；（2）當一個節(jié)點出現(xiàn)故障時，如管理了Socket連接或者沒有響應心跳檢測，Zookeeper移除該臨時節(jié)點；（3）在刪除 一個節(jié)點出現(xiàn)故障時，Helix會更新外部試圖來排除出現(xiàn)故障的節(jié)點；（4）一旦生成“ideal state”，Helix就會根據(jù)定義好的狀態(tài)模型進行狀態(tài)轉(zhuǎn)換 。在Espresso中，每個受到影響的分區(qū)的Slave節(jié)點將會收到SLAVE->MASTER的轉(zhuǎn)換信息。

• 備份恢復服務（Backup Restore ）

  Espresso的存儲節(jié)點能夠定期備份所有分區(qū)，壓縮后的存儲節(jié)點數(shù)據(jù)流備份鏡像會存儲到一個分布式文件系統(tǒng)里，在每個分區(qū)生成的備份能夠在擴展時跨遷移。備份數(shù)據(jù)能夠用來恢復故障節(jié)點、啟動新的集群、擴展已存在的集群等。

• 其它 Espresso 還有其他一些有趣的特性，如 集群擴展、每個數(shù)據(jù)庫的定額管理、批量加載HDFS中的數(shù)據(jù)、自動實化集群、組提交、沖突解決等。

更多關于Espresso的相關信息，請讀者閱讀2013年ACM SIGMOD數(shù)據(jù)管理國際會議上關于Espresso的論文和Swaroop Jagadish關于Espresso的演示稿。

介紹內(nèi)容來自 InfoQ