SequoiaDB 架構指南

1 簡介

SequoiaDB（巨杉數據庫）是一款分佈式非關係型文檔數據庫，能夠被用來存取海量非關係型的數據，其底層主要基於分佈式，高可用，高性能與動態數據類型設計，與當前主流分佈式計算框架 Hadoop 緊密集成。

SequoiaDB 同時兼顧了關係型數據庫中衆多的優秀設計：如索引、動態查詢和更新等，同時以文檔記錄爲基礎更好地處理了動態靈活的數據類型。

SequoiaDB 使用 MPP（海量並行處理）架構，運行於 Linux x86-64 與 PowerPC 平臺集羣，支持 PB 級數據存儲。

SequoiaDB 是爲在現代開發技術、編程模型以及計算資源條件下如何搭建和運行應用程序而設計的。

1.1 如何搭建應用程序

新的複雜型數據類型：在今天的應用程序中，相對於傳統應用單一的關係模型，出現了多種多樣的數據類型，包括動態屬性、混合結構、文本、多媒體、數組以及其餘複雜類型都是很常見的。

靈活性：應用程序中的數據模型隨着開發的進展，是不斷變化的。這是因爲現代互聯網環境下，不少需求在應用的設計之初並沒有法規劃到位。所以隨着時間的推移，應用程序會不斷改進數據模型來適應應用程序的新特性以及新需求。

現代程序編程語言：面向對象編程語言影響着數據的結構，而這些結構與關係型數據庫中存儲數據的結構徹底不一樣。

快速開發：軟件工程團隊如今開始接受短期的、迭代的開發週期。在項目中，定義數據模型和應用程序功能並非發生在項目開始的單一事件，而是一個持續的過程。

1.2 如何運行應用程序

大數據的新可擴展性能：運營和分析負載對可擴展性、可用性、性能和數據多樣性提出了新的挑戰。

• 快速實時性能：用戶指望在不少類型接口應用程序中得到一致的、交互式的體驗。
• 新硬件：計算、存儲、網絡以及主內存資源在成本和性能之間的關係發生了巨大變化。應用程序的設計須要能採用不一樣的優化策略優化這些資源，權衡利用這些資源。
• 新計算環境：單臺計算機資源很難知足應用程序的基礎設施需求，而云基礎設施如今能提供海量、彈性、高效的運行環境。

1.3 SequoiaDB 經過創新來面對新的需求

文檔型數據模型：數據以嵌套式的半結構化方式進行存儲，而該結構能夠映射到現代程序編程語言的對象，很容易被開發人員所理解。

豐富的查詢模型：SequoiaDB 適合於各類各樣的應用程序。它提供了豐富的索引和查詢支持，包括二級索引，聚合框架等。

慣用驅動：開發者經過原生庫來與數據庫交互，使得 SequoiaDB 的使用變得簡單且天然。所謂原生庫，是整合了他們各自的環境和代碼庫。

水平可擴展：隨着數據量和吞吐量的增加，開發人員可以利用經過服務器和雲基礎架構來增長 SequoiaDB 系統的容量。

高可用性：數據的多份副本都是經過遠程複製來維護的。自動故障轉移到輔助節點、機架和數據中心上，使得企業不須要自定義代碼和複雜的優化，就能讓系統正常運行。

內存級的性能：數據都是在內存中直接讀取和寫入的，並且爲了系統的持久性，會在後臺持續把數據寫入磁盤。這些都爲系統提供了快速的性能，使得系統不在須要使用單獨的緩存層。

靈活性：從文檔型數據模型到多數據中心部署，到可變的一致性，到運營級可用性的選擇，SequoiaDB 爲開發和運營團隊提供了巨大的靈活性。正是因爲這些優點，SequoiaDB 很是適合於各類跨行業的應用程序。

2 SequoiaDB 數據模型

2.1 做爲文檔的數據

SequoiaDB 以二進制表示的文檔形式存儲數據，這種二進制文檔稱爲 BSON（二進制的JSON）。這個 BSON 編碼擴展了流行的 JSON（JavaScript Object Notation），表如今附加的類型上，如整形、長整形以及浮點數。BSON 文檔包含一個或多個字段，並且每個字段包含一個特定數據類型值，這些特定數據類型包括數組，二進制數據，子文檔。

每每有着類似結構的文檔會組合成集合，類比於關係型數據庫相關概念就是表；把文檔類比於關係型數據中的行；把字段類比於關係型數據庫中的列。

圖 1 博客應用程序的關係型數據模型示例

例如，爲博客應用程序考慮數據模型。在關係型數據庫中，數據模型可能包含多個表。爲了簡化這個例子，假設全部的表包括類別表，標籤表，用戶表，評論表以及文章表。

而在 SequoiaDB 中，數據可能會建模成兩個集合，一個是用戶集合，另一個是文章集合。在每篇博客中，可能會有多個評論，多個標籤以及多個分類，而這裏的每一個評論、標籤、分類均可以做爲一個嵌入的數組。

SequoiaDB 文檔每每把給定記錄的全部數據都存放在一個單一的文檔中，而在關係型數據庫中，給定的記錄一般被分配存放在多個表中。換句話說，也就是 SequoiaDB 中的數據是更本地化的。在大部分 SequoiaDB 系統中，BSON 文檔每每也是與應用程序中的編程語言對象結構緊密相關的，這使得開發人員可以更加容易理解應用程序中使用的數據如何映射到數據庫中存儲的數據的關係。

2.2 動態模式

SequoiaDB 文檔在結構上能夠不一樣。例如，描述用戶的全部文檔可能包含這個用戶 ID，以及他們最後一次登陸系統的時間。然而僅僅有部分文檔可能包含對一個或多個第三方應用程序的用戶身份。文檔與文檔之間的字段也是不相同的，並且文檔都包含各自的數據結構，所以沒有必要在創建集合的時候指定數據模型。若是要在一個文檔中加入一個新的字段，那麼就建立這樣一個新的字段。這樣既不會影響系統中任何其餘文檔，也不會更新編目信息，更不會讓系統離線。

2.3 模式設計

儘管 SequoiaDB 支持強健的模式靈活，但模式設計仍舊是重要的。模式設計者應該從一些主題來考慮，例如應用程序須要執行的查詢類型、如何管理應用程序代碼中的對象、以及文檔隨時間推移如何改變和增加。模式設計超出了本文的範圍，是一個廣延性的話題。

圖 2 博客應用程序的文檔數據模型

3 功能特性

3.1 慣用驅動

SequoiaDB 爲全部受歡迎的編程語言提供了原生驅動程序，爲營造天然的開發環境而提供了框架。支持的驅動程序包括 C、C++、Java、.NET、PHP、Python 等。相比關係數據庫的根本區別在於，SequoiaDB 的查詢模型是在特定編程語言的 API 中以方法或函數實現的，這與相似 SQL 徹底獨立的語言是相對的。再加上 SequoiaDB JSON 文檔模型和麪向對象編程語言中的數據結構的類似性，使得應用程序之間的集成變得簡單。想得到完整的驅動列表，請查閱sequoiadb.com。

3.2 SequoiaDB 命令行

SequoiaDB 命令行是一個交互式的 JavaScript 執行環境，全部的 SequoiaDB 發行版都包含了 SequoiaDB 命令行。幾乎全部 SequoiaDB 支持的命令都經過命令行執行，包括管理操做。在信息查詢操做中，與 SequoiaDB 交互時，使用 SequoiaDB 命令行是一種經常使用的方式。在 SequoiaDB 手冊中的例子都是基於命令行的。

3.3 SequoiaDB SQL 接口

SequoiaDB 提供了與 PostgreSQL 關係型數據庫鏈接的外部表驅動，能夠將 SequoiaDB 中的集合映射爲 PG 中的用戶表，使用戶能夠經過標準 SQL 訪問 SequoiaDB。具體的使用方式請參見 SequoiaDB 信息中心。

3.4 查詢類型

SequoiaDB 支持不少類型的查詢。一個查詢可能會返回一個文檔，也多是返回文檔中特定字段的子集。

鍵值對查詢返回的結果是基於文檔中任何字段的，一般是關於主鍵字段的。

範圍查詢返回的結果是定義爲不等式的值（例如，大於，小於或者等於）。

聚合框架查詢返回的是經過查詢返回值的聚合（例如總數、最小數、最大數、平均數，相似於 SQL 的 GROUP BY 語句）。

3.5 索引

相似於大多數數據庫管理系統，在 SequoiaDB 中，索引對於優化系統性能是一個很重要的機制。雖然索引可以以數量級來提升一些操做的性能，可是也產生了寫延遲、磁盤使用、內存使用等成本消耗。SequoiaDB 包括文檔中任何字段多種類型的索引。

惟一索引：惟一索引意思是指定一個索引是惟一的。一旦一個惟一索引創建，SequoiaDB將會拒絕對已經創建的惟一索引字段的文檔插入新文檔或更新該文檔。默認狀況下，全部的索引都未被設置爲惟一索引。若是一個複合索引被指定爲惟一索引，則這個複合值必定是惟一的。在分區系統中，惟一索引必須包含分區鍵。

複合索引：爲指定的多個語句查詢，建立複合索引是有意義的。例如，考慮一個存儲用戶數據的應用程序，這個應用可能須要基於用戶的姓氏、用戶的名字及居住地來查詢該用戶。當存在基於用戶的姓氏、用戶的名字及居住地的複合索引時，查詢能夠有效定位到全部指定爲這三個值的用戶。複合索引還有一個好處就是，在一個索引裏，任何主要字段均可以被使用，所以這會減小單個字段索引的使用。複合索引還能經過用戶的姓氏來查找用戶，以此來優化查詢。

數組索引：對於包含數組的字段，每一個數組值都會做爲一個單獨的索引條目來存儲。例如，描繪食譜的文檔可能會包括食材這個字段。若是在食材字段有個索引，那麼每一個食材都能被檢索到，且食材字段的查詢可以經過該索引而優化。建立數組索引是不須要任何特殊的語法，若是字段包含一個數組，它將做爲數組索引而被檢索到。

3.6 查詢優化

SequoiaDB 的自動優化查詢使得評估儘量高效。評估一般包括基於語句選擇數據以及基於給定分類標準來分類數據。查詢優化器爲每一個查詢類型根據開銷評估選擇使用最佳索引。這些經驗測試的結果將被存儲爲一個緩存的查詢計劃並按期更新。

4 SequoiaDB 數據管理

4.1 就地更新

SequoiaDB 在磁盤上以連續的形式存儲每一個文檔。當要插入新記錄時，SequoiaDB 分配空間並就地更新該文件。經過就地管理數據，SequoiaDB 可以以字段進行更新，從而減小了磁盤 IO 次數，而且僅僅只更新須要更新的索引條目。

4.2 分片

SequoiaDB 經過使用分片技術爲數據庫提供了橫向擴展機制，這個分片過程對應用程序來講是透明的。分片分配數據跨越多個物理分區，每一個分區也即分片。分片是爲了替SequoiaDB 部署解決單臺服務器硬件資源受限問題，如內存或者磁盤 I/O 瓶頸，不會增長應用程序複雜性。

SequoiaDB 支持兩種類型的分片：

• 基於範圍的分片。文檔經過分片的鍵值被分割。文檔具備的分片鍵值接近另外一個文檔的分片鍵值時，則這兩個文檔位於同一個分片上。這種方法很是適合須要優化基於範圍查詢的應用。
• 基於哈希的分片。文檔經過分片鍵值的 MD5 值來均勻分佈。文檔的分片鍵值接近另外一個文檔的分片，通常不太可能分佈在同一個分片上。這種方法保證了整個分片的寫均勻分佈，避免了數據的熱點訪問。
  
  圖 3 分片機制提供了水平擴展

4.3 協調節點

分片對於應用程序是透明的，無論系統中有 1 個分片仍是有 100 個分片，查詢 SequoiaDB的應用程序代碼都是同樣的。應用程序把查詢請求發給協調節點，協調節點會把該查詢請求分配到合適的分片上。

圖 4 分片對應用程序是透明的

對於基於分片鍵值的鍵值查詢，協調節點將分發查詢請求到具備查詢鍵值文檔所屬的分片中。當使用基於範圍分片時，指定分片鍵值範圍的查詢僅僅分發查詢請求到在查詢鍵值範圍內文檔所屬的分片中。

對於沒有使用分片鍵值的查詢，協調節點將會派發該查詢到全部的分片上，而後在聚合全部分片上的結果，並將結果排序做爲合適的查詢結果。

在 SequoiaDB 系統中可使用多個協調節點，並且合適的協調節點數量是由應用程序的性能和可用性需求共同決定的。

4.4 分區集合

除了支持橫向擴展的數據分片機制，SequoiaDB 還提供了對集合的縱向分區功能。用戶能夠對一個集合中數據的某一字段指定集合分區鍵，則每條符合特定範圍的記錄會被切分至各自的集合分區。

集合分區在邏輯上看作一個集合的子集，每一個集合分區擁有本身獨立的元數據和索引。用戶能夠建立一個集合並將其加入一個已有的集合，或者從一個分區集合中移除特定分區（Roll-in\Roll-out）。

5 一致性和持久性

5.1 事務模型

SequoiaDB 是 ACID 兼容文檔級別，支持提交回滾等事務操做。默認狀況下，SequoiaDB爲了保證性能關閉事務的支持，若是用戶須要則能夠在啓動數據庫時指定參數打開事務。

在關閉事務支持時，一個單一操做可以寫一個或多個字段，包括多個子文檔的更新和數組元素更新。SequoiaDB 的 ACID 保證了文檔更新的完整隔離性，任何錯誤都會引起回滾操做，以及客戶能獲得文檔的一致性視圖。

而當事務打開時，任何在事務啓動到提交（回滾）之間的操做都會在數據節點寫入事務日誌並跟蹤事務 ID。更改的記錄在事務提交（回滾）前持有互斥鎖，不可被其餘會話更改。當前 SequoiaDB 事務的隔離級別爲 UR。

5.2 一致性

SequoiaDB 採用集合級別的可配置一致性策略，容許用戶在對記錄修改時，根據該記錄所在集合判斷是否須要等待備節點的確認。

譬如，對於一個對性能要求較高、對數據可靠性要求通常的集合來講，能夠在建立集合時將 write concern 參數設置爲 1，表明只要寫入主節點就能夠返回成功信息。而該操做會在後臺異步地發送給從節點執行。

而對於性能要求較低、對數據可靠性要求很高的集合來講，能夠在建立集合時指定 write concern 參數爲 3，表明該操做最少被三個節點確認執行成功後纔可以返回。

當 write concern 的數量與該集合所在每一個副本集中包含節點數量相等時，系統能夠被認爲是強一致，不然爲最終一致。

5.3 日誌

SequoiaDB 實現了事務事務日誌的功能，這確保了在存儲引擎中的快速故障恢復和持久性。日誌有助於防止毀壞，提升操做彈性。每當日誌內存空間佔滿後，日誌將會被刷入磁盤，能夠爲服務器損壞時數據恢復提供方便。

5.4 副本集

SequoiaDB 經過使用遠程複製功能，維護了數據的多個副本，即副本集。一個副本集是有助於防止數據庫停機的、徹底自我修復的分片。副本故障轉移是徹底自動，不須要管理員手動干預。通常來講，一個包含多個節點的分片構成一個副本集。

圖 5 副本集

一個副本集是由多個副本組成。在任何一個時間裏，都有一個副本做爲主副本，其餘副本是從副本。SequoiaDB 在默認狀況下是最終一致的，即寫做用於主副本，讀做用於從副本。若是主副本因任何緣由而宕掉（如過熱、硬件故障或網絡分區），從副本中的一個將會被選出做爲主副本，且開始處理全部的寫操做。

圖 6 分片和副本集

用戶能夠經過指定每一個鏈接會話的讀請求偏好，來定義該會話從主副本或從副本讀取數據。
SequoiaDB 副本集中的副本數量是可配置的，多副本提升了數據持久性以及預防了數據庫的停機時間（如多機器故障、機架故障、數據中心故障或網絡分區）。配置操做在返回應用程序以前寫入多個副本，提供了同步複製相似的功能。應用程序可以選擇從從副本中進行讀操做，從副本默認狀況下是最終一致的。在相似報表類應用中，即能接受稍稍有些過期數據的應用，讀從副本是頗有用的。

副本集提供了操做靈活性，即不須要使數據庫脫機就能升級硬件和軟件。例如，若是要對副本集中全部副本進行硬件升級，能夠依次升級從副本而不會影響整個副本集。當全部從副本都已升級，能夠暫時把主副本降爲從副本，而後再更新這個副本。相似的，像添加索引操做，就能繼續在副本上進行而不會影響系統正常的運行。

6 可用性

6.1 副本

在主副本上修改數據的操做會經過一個日誌複製到從副本上，這個日誌也叫作事務日誌。這些事務日誌包含了主副本中所有的數據操做，將會在從副本上重作。事務日誌的大小是可配置的。

若是一個從副本停機時間比事務日誌保存的時間還要長，那麼從副本必需要使用全量同步過程從主副本恢復。在全量同步過程當中，全部的數據庫和集合以及事務日誌都會從主副本或者其餘副本複製到這個從副本上，還會生成索引。在向副本集中加入一個新副本時，也須要執行全量同步過程。

6.2 選舉和故障轉移

副本集下降了運行開銷，提升了系統可用性。若是主副本集分片出現故障，全部從副本就一塊兒決定哪一個副本應該成爲主副本，這個過程也就是選舉過程。一旦肯定了新的主副本，剩下的從副本都將配置好來接受重新主副本發來的更新操做。若是原先的主副本從新聯機，它也會意識到本身再也不是主副本，並會配置好本身爲從副本。

6.3 選舉優先

關於如何選舉新的主副本，SequoiaDB 有一系列標準，主要依賴每一個節點的當前事務號（LSN）做爲評判依據。在進行選舉的過程當中，參與者中 LSN 號最高的節點（表明該節點包含最新的數據）會被推選爲主節點。

6.4 磁盤的容量，內存的性能

SequoiaDB 大量使用內存來加速數據庫操做。從內存讀數據是納秒級的，從普通磁盤讀數據是毫秒級的。因此從內存讀數據大約比從磁盤讀數據快 100,000 倍。在 SequoiaDB 中，全部的數據都是經過內存映射文件來讀取和操做的。不被訪問的數據是不會加載到內存中的。雖然並不要求全部的數據都裝在內存中，可是把全部頻繁訪問的索引和數據裝入內存應該是指望的目標。例如，應用程序頻繁的訪問數據庫中的小部分，如最近時間或受歡迎產品的數據。若是常常被訪問的數據超過了單臺機臺的容量，用戶可使用分片機制將SequoiaDB在多個服務器上進行橫向擴展。

因爲 SequoiaDB 提供了內存級的性能，所以對於大多數應用程序來講，都不須要單獨的緩存層。

7 總結

SequoiaDB 提供了一個強大的、創新的數據庫平臺，它是爲如何構建和運行應用程序而設計。在這份指南中，咱們探討了 SequoiaDB 體系結構的基本概念和設想。相似業務最佳實踐等其餘主題指南，你可以在 sequoiadb.com 上找到。