[[320127]]

【51CTO.com快譯】總的來說，如果你需要一個數(shù)據(jù)庫，可以使用某一款大牌的數(shù)據(jù)庫：MySQL/MariaDB、PostgreSQL、SQLite、MongoDB，然后開始工作。但有時候一應俱全的方法并不適合所有場景。主流數(shù)據(jù)庫有時無法支持你的使用場景，你需要尋找更專門化的數(shù)據(jù)庫。本文介紹了9款非主流數(shù)據(jù)庫，從內存中分析、鍵值存儲到時間序列系統(tǒng)，不一而足。

DuckDB

“SQL OLAP系統(tǒng)”這個短語通常讓人聯(lián)想到處理數(shù)據(jù)的整體式系統(tǒng)或龐大的數(shù)據(jù)倉庫集群。DuckDB之于分析數(shù)據(jù)庫，尤如SQLlite之于MySQL和PostgreSQL。它不是為在與成熟的OLAP解決方案一樣龐大的規(guī)模下運行而設計的，而是為本地數(shù)據(jù)集提供快速的內存中分析處理。

DuckDB的許多功能與大型OLAP產(chǎn)品中的功能相對應，盡管規(guī)模較小。數(shù)據(jù)存儲為列而不是行，查詢處理進行矢量處理，以便最大程度地利用CPU緩存。雖然在直接連接至Tableau之類的報告解決方案方面辦法不多，但是手動并入這種解決方案應該不難。除了面向C++的綁定外，DuckDB還直接連接到兩個最常用的分析編程環(huán)境：Python和R。

EdgeDB

 “邊緣”是圖數(shù)據(jù)庫中使用的術語，指高度連接的數(shù)據(jù)集中兩個實體或節(jié)點（比如客戶與訂單或訂單與產(chǎn)品）之間的連接或關系。EdgeDB使用PostgreSQL核心及其提供的所有屬性（比如ACID事務和高可靠性）來構建開發(fā)者所謂的“對象關系數(shù)據(jù)庫”，擁有強字段類型和類似SQL的查詢語言。

因此，EdgeDB結合了類似NoSQL的易用性和即時性、圖形數(shù)據(jù)庫的關系建模功能以及SQL的保證和一致性。盡管EdgeDB不是正式的文檔數(shù)據(jù)庫，你也可以用它以這種方式存儲數(shù)據(jù)。你還可以使用GraphQL查詢語言輕松地從EdgeDB檢索數(shù)據(jù)，就像使用Neo4j之類的原生圖形數(shù)據(jù)庫那樣。

FoundationDB

蘋果牽頭的開源項目FoundationDB是一種“多模”數(shù)據(jù)庫，內部將數(shù)據(jù)存儲為鍵值對（實際上是NoSQL模型），但可以組織成關系表、圖形、文檔及其他許多數(shù)據(jù)結構。ACID事務保證了數(shù)據(jù)完整性，橫向擴展和復制功能均可直接使用。不過FoundationDB的設計有一些嚴格的限制：鍵、值和事務都有嚴格的大小限制，事務還有嚴格的時間限制。

HarperDB

HarperDB的目標是提供單一數(shù)據(jù)庫，以處理企業(yè)中的結構化數(shù)據(jù)和非結構化數(shù)據(jù)——介于FoundationDB之類的多模數(shù)據(jù)庫和數(shù)據(jù)倉庫或OLAP解決方案之間。所攝取的數(shù)據(jù)已經(jīng)過重復數(shù)據(jù)刪除，通過你選擇的界面：SQL、NoSQL、Excel等可供查詢使用。Tableau或Power BI等BI解決方案可以直接與HarperDB集成，無需提取或處理數(shù)據(jù)。企業(yè)版和社區(qū)版均有提供。

KeyDB

盡管Redis很流行很強大，但內存中鍵值存儲因線程性能和易用性不盡如人意而受到批評。KeyDB與Redis在協(xié)議上兼容，因此可以臨時替代Redis。但KeyDB在底層作了一些出色的改進，主要是面向網(wǎng)絡I/O操作的多線程和查詢解析。Redis的下一版本Redis 6計劃也包括線程I/O，但KeyDB現(xiàn)在就可以使用。

M3DB

M3DB是優(yōu)步內部工程團隊開發(fā)的產(chǎn)品，這個分布式時間序列數(shù)據(jù)庫用于優(yōu)步的度量指標平臺（實際上作為Prometheus的數(shù)據(jù)存儲）。M3DB借鑒了Apache Cassandra和Facebook項目“Gorilla”的想法，支持任意的時間精度、無序插入以及可配置的復制和讀取一致性。然而，開發(fā)者特別指出M3DB可能不適合所有時間序列數(shù)據(jù)庫使用場合。比如說，M3DB無法在給定的時間窗口（默認值為2小時）外無序插入數(shù)據(jù)，它主要針對存儲和檢索64位浮點數(shù)而不是其他類型的數(shù)據(jù)進行了優(yōu)化。

RediSQL

名稱暗示著融合了Redis內存中鍵值存儲和SQL查詢功能，而這正是RediSQL的本質——具體來說，嵌入SQLite數(shù)據(jù)庫的Redis模塊。數(shù)據(jù)透明地存儲在Redis中，因此Redis處理持久性和內存中處理。每個數(shù)據(jù)庫都與Redis鍵相關聯(lián)，因此你可以在一個Redis實例上有多個SQL數(shù)據(jù)庫。針對這些數(shù)據(jù)庫的查詢是標準SQL，通過標準的Redis API來傳遞。你還可以在RediSQL中創(chuàng)建和預編譯語句（實際上是存儲過程），以加快查詢執(zhí)行。商業(yè)版和開源版均有提供。

RQLite

SQLite稱得上是個奇跡：這是一款運行飛快、超級可靠的嵌入式開源數(shù)據(jù)庫。只要你在單用戶應用程序中需要數(shù)據(jù)庫，SQLite都是很好的默認選擇，但SQLite實例僅限于一個節(jié)點。

RQLite基于SQLite創(chuàng)建分布式數(shù)據(jù)庫系統(tǒng)。設置多個節(jié)點很容易，數(shù)據(jù)使用Raft共識算法可在這些節(jié)點之間自動復制。RQLite還提供節(jié)點之間的加密和發(fā)現(xiàn)服務，該服務使自動添加節(jié)點變得很容易。但RQLite也有幾個缺點：寫速度不如SQLite，只有確定性的SQL函數(shù)（即保證在每個節(jié)點上生成同樣結果的函數(shù)）可以安全使用。

UmbraDB

如今大多數(shù)高端數(shù)據(jù)庫都有某種內存中功能，即使它涉及表固定之類的系統(tǒng)（比如SQL Server）。UmbraDB這種分析數(shù)據(jù)庫可以作為PostgreSQL的臨時替代來運行，旨在盡可能使用內存中處理。如果不行，它使用一種新穎的可變大小頁面機制從存儲系統(tǒng)對數(shù)據(jù)分頁處理。長時間運行的查詢針對使用LLVM執(zhí)行進行了優(yōu)化。

原文標題：9 offbeat databases worth a look，作者：Serdar Yegulalp

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】