分布式數(shù)據(jù)庫FoundationDB介紹（一）

FoundationDB是一個開源數(shù)據(jù)庫項目，最初于2012年1月進行Alpha測試，2013年4月進行Beta測試。2013年8月20日正式發(fā)布了1.0版本。兩年后的2013年3月25日被蘋果公司收購以后不再開源。蘋果公司于2018I年4月19日再次開源。

本文通過FoundationDB官網(wǎng)學習，記錄FoundationDB相關重要知識點。

FoundationDB有哪些優(yōu)勢？

多模型數(shù)據(jù)存儲。FoundationDB 是多模型的，這意味著可以在單個數(shù)據(jù)庫中存儲多種類型的數(shù)據(jù)。所有數(shù)據(jù)都安全地存儲，分發(fā)和復制在鍵值存儲組件中。

易于擴展和容錯。FoundationDB 易于安裝、擴展和管理。它有一個分布式架構，可以優(yōu)雅地向外擴展，并在像單個 ACID 數(shù)據(jù)庫一樣處理故障的同時。

行業(yè)領先的性能。FoundationDB 在商品硬件上提供驚人的性能，能夠以低成本支持非常重的負載。

生產實踐。FoundationDB 已在生產環(huán)境中運行多年，并通過汲取的經(jīng)驗教訓加以鞏固。支持 FoundationDB 的是一個無與倫比的基于確定性模擬引擎的測試系統(tǒng)。

FoundationDB架構

FoundationDB 使應用架構靈活且易于操作。應用程序可以將它們的數(shù)據(jù)直接發(fā)送到 FoundationDB 或layer，這是一個用戶編寫的模塊，可以提供新的數(shù)據(jù)模型、與現(xiàn)有系統(tǒng)的兼容性，甚至可以作為一個完整的框架。在這兩種情況下，所有數(shù)據(jù)都通過一個有序的、事務性的鍵值 API 存儲在一個地方。

FoundationDB 架構詳解

FoundationDB 架構選擇解耦設計，其中進程被分配不同的異構角色（例如，Coordinators、存儲服務器、Master）。通過水平擴展不同角色的進程數(shù)量來擴展數(shù)據(jù)庫：

Coordinators

所有客戶端和服務器都使用群集文件連接到FoundationDB群集，該群集文件包含協(xié)調程序的IP：PORT。客戶端和服務器都使用協(xié)調器與集群控制器連接。如果不存在，服務器將嘗試成為集群控制器，并在選出一個后向集群控制器注冊。客戶端使用集群控制器來保持最新的代理列表。

集群控制器

集群控制器是由大多數(shù)協(xié)調器選出的單例。它是集群中所有進程的入口點。它負責確定進程何時失敗，告訴進程它們應該成為哪些角色，并在所有進程之間傳遞系統(tǒng)信息。

Master

master 負責協(xié)調 write 子系統(tǒng)從一代到下一代的過渡。寫入子系統(tǒng)包括主、代理、解析器和事務日志。這三個角色被視為一個單位，如果其中任何一個失敗，我們將招募所有三個角色的替代者。master 為代理提供批量突變的提交版本。

歷史上，Ratekeeper 和 Data Distributor 與 Master 耦合在同一進程上。從 6.2 開始，兩者都成為集群中的單例。生命時間不再與師父綁定。

代理

代理負責提供讀取版本、提交事務并跟蹤負責每個密鑰范圍的存儲服務器。為了提供讀取版本，代理將要求所有其他代理查看此時最大的已提交版本，同時檢查事務日志是否未停止。Ratekeeper將人為地降低代理提供讀取版本的速度。

提交是通過以下方式完成的：

從 master 獲取提交版本。

使用解析器確定事務是否與先前提交的事務沖突。

使事務在事務日志上持久化。

以\xff字節(jié)開頭的密鑰空間是為系統(tǒng)元數(shù)據(jù)保留的。提交到該密鑰空間的所有變更都通過解析器分發(fā)給所有代理。該元數(shù)據(jù)包括鍵范圍和具有該范圍鍵數(shù)據(jù)的存儲服務器之間的映射。代理按需向客戶提供此信息。客戶端緩存這個映射；如果他們向存儲服務器詢問它沒有的密鑰，他們將清除緩存并從代理獲取更新的服務器列表。

事務日志

事務日志使更改持久化到磁盤以實現(xiàn)快速提交延遲。日志按版本順序從代理接收提交，并且只有在數(shù)據(jù)被寫入并同步到磁盤上的僅附加突變日志后才響應代理。在數(shù)據(jù)甚至寫入磁盤之前，我們將其轉發(fā)到負責該突變的存儲服務器。一旦存儲服務器使突變持久化，它們就會從日志中彈出它。這通常發(fā)生在最初將突變提交到日志后大約 6 秒。我們只在進程重新啟動時從日志的磁盤中讀取。如果存儲服務器發(fā)生故障，則綁定到該存儲服務器的突變將在日志中累積。

解析器

解析程序負責確定事務之間的沖突。如果事務讀取在事務的讀取版本和提交版本之間寫入的鍵，則事務會發(fā)生沖突。解析器通過在內存中保存最后 5 秒提交的寫入，并將新事務的讀取與這組提交進行比較來做到這一點。

存儲服務器

集群中的絕大多數(shù)進程都是存儲服務器。存儲服務器被分配了密鑰范圍，并負責存儲該范圍內的所有數(shù)據(jù)。他們在內存中保留 5 秒的突變，并在 5 秒前保留數(shù)據(jù)的磁盤副本。客戶端必須在最后 5 秒內讀取一個版本，否則會?transaction_too_old出錯。SSD 存儲引擎將數(shù)據(jù)存儲在基于 SQLite 的 B 樹中。內存存儲引擎將數(shù)據(jù)存儲在內存中，并帶有僅在進程重新啟動時從磁盤讀取的附加日志。在即將發(fā)布的 FoundationDB 7.0 版本中，B-tree 存儲引擎將被全新的Redwood?引擎取代。

數(shù)據(jù)分發(fā)器

數(shù)據(jù)分配器管理存儲服務器的生命周期，決定哪個存儲服務器負責哪個數(shù)據(jù)范圍，并確保數(shù)據(jù)在所有存儲服務器 (SS) 上均勻分布。數(shù)據(jù)分發(fā)器作為集群中的單例由集群控制器招募和監(jiān)控。

監(jiān)控系統(tǒng)

Ratekeeper 監(jiān)控系統(tǒng)負載并在集群接近飽和時通過降低代理提供讀取版本的速率來降低客戶端事務速率。Ratekeeper 作為集群中的單例，由 Cluster Controller 招募和監(jiān)控。

客戶

客戶端與特定語言綁定（即客戶端庫）鏈接，以便與 FoundationDB 集群通信。語言綁定支持加載多個版本的 C 庫，允許客戶端與舊版本的 FoundationDB 集群通信。目前，官方支持 C、Go、Python、Java、Ruby 綁定。

事務處理

FoundationDB 中的數(shù)據(jù)庫事務由客戶端聯(lián)系其中一個代理以獲取讀取版本開始，該版本保證大于客戶端可能知道的任何提交版本（甚至通過 FoundationDB 集群之外的側通道）。這是必需的，以便客戶端將看到已發(fā)生的先前提交的結果。

然后客戶端可以向存儲服務器發(fā)出多次讀取并獲取該特定讀取版本的值。客戶端寫入保存在本地內存中，無需聯(lián)系集群。默認情況下，讀取在同一事務中寫入的鍵將返回新寫入的值。

在提交時，客戶端將事務數(shù)據(jù)（所有讀取和寫入）發(fā)送到代理之一，并等待來自代理的提交或中止響應。如果事務與另一個事務沖突而無法提交，客戶端可能會選擇從頭開始重試事務。如果事務提交，代理還將提交版本返回給客戶端。請注意，此提交版本大于讀取版本，并由 master 選擇。

FoundationDB 架構將客戶端讀取和寫入（即事務提交）的擴展分開。由于客戶端直接向分片存儲服務器發(fā)出讀取，因此讀取與存儲服務器的數(shù)量成線性關系。類似地，通過向事務系統(tǒng)中的代理、解析器和日志服務器添加更多進程來擴展寫入。更多FoundationDB事務處理相關的技術，將在后面單獨去討論。

EI企業(yè)智能 可信智能計算服務 TICS 數(shù)據(jù)庫 數(shù)據(jù)湖治理中心 DGC 智能數(shù)據(jù)

版權聲明：本文內容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內刪除侵權內容。

版權聲明：本文內容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內刪除侵權內容。