摘要：使用海量并行處理架構，運行于與平臺集群，支持級數據存儲。水平可擴展隨著數據量和吞吐量的增長，開發人員能夠利用通過服務器和云基礎架構來增加系統的容量。如果一個復合索引被指定為唯一索引，則這個復合值一定是唯一的。

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

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

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

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

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

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

現代程序編程語言：面向對象編程語言影響著數據的結構，而這些結構與關系型數據庫中存儲數據的結構完全不同。

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

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

快速實時性能：用戶期望在很多類型接口應用程序中獲得一致的、交互式的體驗。

新硬件：計算、存儲、網絡以及主內存資源在成本和性能之間的關系發生了巨大變化。應用程序的設計需要能采用不同的優化策略優化這些資源，權衡利用這些資源。

新計算環境：單臺計算機資源很難滿足應用程序的基礎設施需求，而云基礎設施現在能提供海量、彈性、高效的運行環境。

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

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

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

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

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

內存級的性能：數據都是在內存中直接讀取和寫入的，而且為了系統的持久性，會在后臺持續把數據寫入磁盤。這些都為系統提供了快速的性能，使得系統不在需要使用多帶帶的緩存層。

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

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

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

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

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

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

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

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

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

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

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

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

SequoiaDB 提供了與 PostgreSQL 關系型數據庫連接的外部表驅動，可以將 SequoiaDB 中的集合映射為 PG 中的用戶表，使用戶可以通過標準 SQL 訪問 SequoiaDB。具體的使用方式請參見 SequoiaDB 信息中心。

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

鍵值對查詢返回的結果是基于文檔中任何字段的，通常是關于主鍵字段的。

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

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

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

唯一索引：唯一索引意思是指定一個索引是唯一的。一旦一個唯一索引建立，SequoiaDB將會拒絕對已經建立的唯一索引字段的文檔插入新文檔或更新該文檔。默認情況下，所有的索引都未被設置為唯一索引。如果一個復合索引被指定為唯一索引，則這個復合值一定是唯一的。在分區系統中，唯一索引必須包含分區鍵。

復合索引：為指定的多個語句查詢，創建復合索引是有意義的。例如，考慮一個存儲用戶數據的應用程序，這個應用可能需要基于用戶的姓氏、用戶的名字及居住地來查詢該用戶。當存在基于用戶的姓氏、用戶的名字及居住地的復合索引時，查詢可以有效定位到所有指定為這三個值的用戶。復合索引還有一個好處就是，在一個索引里，任何主要字段都可以被使用，因此這會減少單個字段索引的使用。復合索引還能通過用戶的姓氏來查找用戶，以此來優化查詢。

數組索引：對于包含數組的字段，每個數組值都會作為一個多帶帶的索引條目來存儲。例如，描繪食譜的文檔可能會包括食材這個字段。如果在食材字段有個索引，那么每個食材都能被檢索到，且食材字段的查詢能夠通過該索引而優化。創建數組索引是不需要任何特殊的語法，如果字段包含一個數組，它將作為數組索引而被檢索到。

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

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

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

SequoiaDB 支持兩種類型的分片：

基于范圍的分片。文檔通過分片的鍵值被分割。文檔具有的分片鍵值接近另一個文檔的分片鍵值時，則這兩個文檔位于同一個分片上。這種方法非常適合需要優化基于范圍查詢的應用。

基于哈希的分片。文檔通過分片鍵值的 MD5 值來均勻分布。文檔的分片鍵值接近另一個文檔的分片，一般不太可能分布在同一個分片上。這種方法保證了整個分片的寫均勻分布，避免了數據的熱點訪問。

圖 3 分片機制提供了水平擴展

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

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

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

對于沒有使用分片鍵值的查詢，協調節點將會派發該查詢到所有的分片上，然后在聚合所有分片上的結果，并將結果排序作為合適的查詢結果。

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

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

集合分區在邏輯上看做一個集合的子集，每個集合分區擁有自己獨立的元數據和索引。用戶可以創建一個集合并將其加入一個已有的集合，或者從一個分區集合中移除特定分區（Roll-inRoll-out）。

SequoiaDB 是 ACID 兼容文檔級別，支持提交回滾等事務操作。默認情況下，SequoiaDB為了保證性能關閉事務的支持，如果用戶需要則可以在啟動數據庫時指定參數打開事務。

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

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

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

譬如，對于一個對性能要求較高、對數據可靠性要求一般的集合來說，可以在創建集合時將 write concern 參數設置為 1，代表只要寫入主節點就可以返回成功信息。而該操作會在后臺異步地發送給從節點執行。

而對于性能要求較低、對數據可靠性要求很高的集合來說，可以在創建集合時指定 write concern 參數為 3，代表該操作最少被三個節點確認執行成功后才能夠返回。

當 write concern 的數量與該集合所在每個副本集中包含節點數量相等時，系統可以被認為是強一致，否則為最終一致。

SequoiaDB 實現了事務事務日志的功能，這確保了在存儲引擎中的快速故障恢復和持久性。日志有助于防止毀壞，提高操作彈性。每當日志內存空間占滿后，日志將會被刷入磁盤，可以為服務器損壞時數據恢復提供方便。

SequoiaDB 通過使用遠程復制功能，維護了數據的多個副本，即副本集。一個副本集是有助于防止數據庫停機的、完全自我修復的分片。副本故障轉移是完全自動，不需要管理員手動干預。一般來說，一個包含多個節點的分片構成一個副本集。

圖 5 副本集

一個副本集是由多個副本組成。在任何一個時間里，都有一個副本作為主副本，其他副本是從副本。SequoiaDB 在默認情況下是最終一致的，即寫作用于主副本，讀作用于從副本。如果主副本因任何原因而宕掉（如過熱、硬件故障或網絡分區），從副本中的一個將會被選出作為主副本，且開始處理所有的寫操作。

圖 6 分片和副本集

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

副本集提供了操作靈活性，即不需要使數據庫脫機就能升級硬件和軟件。例如，如果要對副本集中所有副本進行硬件升級，可以依次升級從副本而不會影響整個副本集。當所有從副本都已升級，可以暫時把主副本降為從副本，然后再更新這個副本。類似的，像添加索引操作，就能繼續在副本上進行而不會影響系統正常的運行。

在主副本上修改數據的操作會通過一個日志復制到從副本上，這個日志也叫做事務日志。這些事務日志包含了主副本中全部的數據操作，將會在從副本上重做。事務日志的大小是可配置的。

如果一個從副本停機時間比事務日志保存的時間還要長，那么從副本必須要使用全量同步過程從主副本恢復。在全量同步過程中，所有的數據庫和集合以及事務日志都會從主副本或者其他副本復制到這個從副本上，還會生成索引。在向副本集中加入一個新副本時，也需要執行全量同步過程。

副本集降低了運行開銷，提高了系統可用性。如果主副本集分片出現故障，所有從副本就一起決定哪個副本應該成為主副本，這個過程也就是選舉過程。一旦確定了新的主副本，剩下的從副本都將配置好來接受從新主副本發來的更新操作。如果原先的主副本重新聯機，它也會意識到自己不再是主副本，并會配置好自己為從副本。

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

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

由于 SequoiaDB 提供了內存級的性能，因此對于大多數應用程序來說，都不需要多帶帶的緩存層。

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