[[314073]]

所有軟件系統(tǒng)中都必須包含一項(xiàng)關(guān)鍵組件，那就是用于存儲(chǔ)、檢索和分析數(shù)據(jù)的數(shù)據(jù)庫(kù)。本文中，我們將和大家一起探討適用于算法交易平臺(tái)的數(shù)據(jù)庫(kù)都會(huì)有哪些特性？有哪些可選擇的數(shù)據(jù)庫(kù)？

從廣義層面來(lái)看，數(shù)據(jù)庫(kù)提供了記錄和管理數(shù)據(jù)（OLTP）和分析數(shù)據(jù)（OLAP）的能力。大多數(shù)數(shù)據(jù)庫(kù)會(huì)擅長(zhǎng)其中一種能力，同時(shí)在某些指標(biāo)具備優(yōu)勢(shì)，而在另一些方面則有所欠缺。舉例來(lái)說(shuō)，擅長(zhǎng)一致和持久事務(wù)的關(guān)系型數(shù)據(jù)庫(kù)可能在性能方面表現(xiàn)不是很好，因?yàn)樗枰i定其數(shù)據(jù)結(jié)構(gòu)并刷新所有磁盤(pán)寫(xiě)入。相反，優(yōu)先考慮性能的數(shù)據(jù)庫(kù)可能需要使用寬松的一致性模型。

根據(jù)特定功能和特性的優(yōu)先級(jí)劃分，不同種類(lèi)的數(shù)據(jù)庫(kù)適用于不同的場(chǎng)景。

1. 算法交易系統(tǒng)的數(shù)據(jù)存儲(chǔ)

如果我們想追求完美，即持久、一致地存儲(chǔ)大量數(shù)據(jù)并快速進(jìn)行實(shí)時(shí)分析，這能做到嗎？盡管計(jì)算機(jī)科學(xué)理論警告我們不要太貪心，但是有一些工程思想值得參考。

主要設(shè)計(jì)目標(biāo)包括：

• 快速將大量事件提取到持久存儲(chǔ)中（每天工作數(shù)小時(shí)，約 250K-1M 個(gè)事件 / 秒；我們預(yù)期每個(gè)事件約為 100-200 字節(jié)，并具有 10-30 個(gè)字段）
• 實(shí)時(shí)分析，包括匯總
• 能夠處理大量模式和趨勢(shì)歷史數(shù)據(jù)

基于以上的設(shè)計(jì)目標(biāo)，我們可以構(gòu)建幾種解決方案，不過(guò)基本上都需要對(duì)數(shù)據(jù)存儲(chǔ)進(jìn)行分層，以提供多種附加能力。

其中的一種解決方案為：

1. 將交易系統(tǒng)中的所有事件存儲(chǔ)到一個(gè)快速數(shù)據(jù)存儲(chǔ)中，例如僅附加文件日志（可能在高可用性系統(tǒng)的多個(gè)節(jié)點(diǎn)上復(fù)制或重新創(chuàng)建）。該文件提供持久存儲(chǔ)，但沒(méi)有真正的查詢(xún)功能。
2. 將該日志文件的內(nèi)容順序提取到一個(gè)內(nèi)存數(shù)據(jù)庫(kù) / 緩存中。這個(gè)步驟可以很快，甚至是實(shí)時(shí)的，因?yàn)樵谶@一層沒(méi)有一致性檢查、復(fù)制或持久性要求。該層應(yīng)提供實(shí)時(shí)聚合和分析。
3. 定期將內(nèi)存數(shù)據(jù)庫(kù)的內(nèi)容持久存儲(chǔ)到磁盤(pán)（每小時(shí)或一天結(jié)束時(shí)等）。這里使用可以對(duì)磁盤(pán)上存儲(chǔ)的大量數(shù)據(jù)進(jìn)行操作的數(shù)據(jù)庫(kù)。本質(zhì)而言，對(duì)存儲(chǔ)的這些數(shù)據(jù)進(jìn)行的操作被視為脫機(jī)或批處理模式，并且不期望瞬時(shí)響應(yīng)時(shí)間。
4. （可選）僅將日志文件的相關(guān)部分提取到一個(gè)關(guān)系型數(shù)據(jù)庫(kù)中，以提交每日 / 每月報(bào)告。例如，只有訂單和執(zhí)行會(huì)被加載到關(guān)系型數(shù)據(jù)庫(kù)中，而市場(chǎng)報(bào)價(jià)會(huì)被跳過(guò)。

另外，這個(gè)解決方案也是可以簡(jiǎn)化的，例如可以將步驟 2、3 和 4 組合起來(lái)，使用一個(gè)提供多種存儲(chǔ)和分析數(shù)據(jù)模式的工具。

接下來(lái)，我們就來(lái)一起討論一下細(xì)分需求下的數(shù)據(jù)庫(kù)工作。

2. 我們對(duì)數(shù)據(jù)庫(kù)的要求

我們對(duì)數(shù)據(jù)庫(kù)的要求可分為非技術(shù)需求和技術(shù)需求兩部分。

非技術(shù)需求列表：

成本：作為一家注重成本的初創(chuàng)企業(yè)，我們正在尋找免費(fèi)或相對(duì)便宜的產(chǎn)品。鑒于當(dāng)今有許多 FOSS 方案，我們認(rèn)為這不是什么瘋狂的要求。這也意味著 Oracle 和 MS SQL Server 等標(biāo)準(zhǔn)付費(fèi)數(shù)據(jù)庫(kù)被排除在外了。

良好的文檔和社區(qū)支持：如果我們不支付許可和支持費(fèi)用，就需要良好的文檔和另一種解答問(wèn)題的途徑。可行途徑可以是郵件列表、活躍的在線(xiàn)社區(qū)，也可能只需 StackOverflow 即可。

運(yùn)營(yíng)工具：我們更喜歡相對(duì)成熟的產(chǎn)品，自帶用于設(shè)置、管理和監(jiān)視部署（包括可能的多節(jié)點(diǎn)集群）的工具。

技術(shù)需求：

快速提取：我們需要數(shù)據(jù)庫(kù)能夠以每秒 250K 次插入的速度提取，越高越好。如果我們需要批量插入，那是可以接受的；如果我們需要使用多個(gè)線(xiàn)程或連接也可以。

快速聚合：我們打算在系統(tǒng)中使用事件源模式。按照這一架構(gòu)模式的規(guī)定，我們會(huì)將系統(tǒng)中的所有狀態(tài)更改記錄為離散的不可變事件。為了從這些事件中重新創(chuàng)建系統(tǒng)的最新?tīng)顟B(tài)，我們需要對(duì)內(nèi)存中快速聚合的支持，包括窗口函數(shù)、upsert 和其他可能的橫截面聚合。

時(shí)間序列操作：支持諸如時(shí)間段、移動(dòng)窗口聚合和 as-of joins 之類(lèi)的操作。

表達(dá)力強(qiáng)的查詢(xún)語(yǔ)言：SQL 可以，但對(duì)于高級(jí)分析來(lái)說(shuō)表達(dá)能力還是不夠。理想情況下，數(shù)據(jù)庫(kù)將使用帶有矢量化操作的函數(shù)語(yǔ)言支持?jǐn)?shù)據(jù)訪(fǎng)問(wèn)和處理。創(chuàng)建用戶(hù)定義函數(shù)或服務(wù)端腳本的能力也很有用。

內(nèi)存中的表：用于快速分析工作數(shù)據(jù)集。

磁盤(pán)中的表：我們預(yù)期這一類(lèi)別中的多數(shù)數(shù)據(jù)庫(kù)使用面向列的存儲(chǔ)。

數(shù)據(jù)庫(kù)應(yīng)支持優(yōu)化的磁盤(pán)數(shù)據(jù)布局，這會(huì)顯著提高性能。

• 數(shù)據(jù)按日期劃分并分段存儲(chǔ)，以便數(shù)據(jù)管理
• 對(duì)于每個(gè)分區(qū)，數(shù)據(jù)由 Symbol（交易代碼）跨多個(gè)節(jié)點(diǎn)分片，以實(shí)現(xiàn)并行性和冗余
• 在每個(gè)分區(qū)和分片中，數(shù)據(jù)記錄按（Symbol + Exchange，代碼 + 交易所）進(jìn)行聚類(lèi)，以方便順序讀取磁盤(pán)
• 最后，在每個(gè)聚簇鍵的記錄中，按時(shí)間戳對(duì)數(shù)據(jù)排序，以實(shí)現(xiàn)更快的時(shí)序操作
• 此外，可以將數(shù)據(jù)壓縮在磁盤(pán)上，以減少?gòu)拇疟P(pán)讀取的數(shù)據(jù)總量
• 分層數(shù)據(jù)存儲(chǔ)：數(shù)據(jù)庫(kù)還可以支持分層存儲(chǔ)策略，將較舊的數(shù)據(jù)移動(dòng)到速度較慢的存儲(chǔ)上，從而降低存儲(chǔ)成本。

下面是我們?cè)u(píng)估的數(shù)據(jù)規(guī)模估算：

1. 每日數(shù)據(jù)增長(zhǎng)：50–100 GB（未壓縮）〜1B 條記錄
2. 歷史數(shù)據(jù)（最終）：100 TB（未壓縮）〜1T 條記錄

3. 如何進(jìn)行測(cè)試？

我們所有的測(cè)試都是在單個(gè)或兩個(gè) AWS 專(zhuān)用實(shí)例（m5n-2xlarge）上進(jìn)行的。這些實(shí)例運(yùn)行 Amazon Linux 2 AMI，包括 8 個(gè) vCPU、32GB RAM 和 100–200GB SSD 卷。

我們知道，對(duì)于某些參與測(cè)試的數(shù)據(jù)庫(kù)來(lái)說(shuō)，這些實(shí)例不算很大，尤其是在內(nèi)存指標(biāo)方面。但我們這樣選擇也有我們的考量，首先，我們認(rèn)為這些資源足以進(jìn)行我們想要的測(cè)試，其次，我們想了解在資源不足時(shí)，這些工具將如何降級(jí)或失敗。

在我們的時(shí)間限制內(nèi)，我們盡了最大的努力來(lái)配置各個(gè)工具以使其發(fā)揮最佳性能，但是我們可能并沒(méi)有一直使用推薦的配置、硬件或節(jié)點(diǎn)數(shù)。我們也嘗試了遵循文檔并以最佳方式設(shè)置數(shù)據(jù)布局（例如分片方案）。

我們執(zhí)行的實(shí)際測(cè)試包括：

• 加載一天的 NYSE TAQ 數(shù)據(jù)（20180730 的文件）。這會(huì)將 3500 萬(wàn)筆交易加載到一個(gè)表中，并將 7.19 億個(gè)報(bào)價(jià)加載到另一個(gè)表中。我們不打算將此數(shù)據(jù)庫(kù)用于報(bào)價(jià)數(shù)據(jù)分析，但這肯定會(huì)成為一個(gè)很好的示例數(shù)據(jù)集。
• 對(duì)于每筆交易，在該交易所在的交易所中找到當(dāng)前的報(bào)價(jià)。我們希望對(duì)單個(gè)繁忙的代碼（例如 SPY）的查詢(xún)將花費(fèi)不到一分鐘的時(shí)間，對(duì)于所有代碼，我們希望查詢(xún)?cè)?30 分鐘內(nèi)完成。這是對(duì)查詢(xún)語(yǔ)言表示復(fù)雜聯(lián)接的能力，以及數(shù)據(jù)庫(kù)在合理時(shí)間內(nèi)執(zhí)行聯(lián)接能力的測(cè)試。
• 對(duì)于每個(gè)交易代碼，計(jì)算交易日每分鐘的交易數(shù)量、平均大小和交易量加權(quán)平均成交價(jià)。我們希望在整個(gè)交易表上花費(fèi)的時(shí)間不超過(guò) 10 秒。
• 在交易日的每一分鐘計(jì)算每個(gè)交易代碼的 OHLC 條形。
• 計(jì)算交易日每個(gè)交易品種的時(shí)間加權(quán)平均價(jià)差。這是一個(gè)有趣的測(cè)試，其原因有兩個(gè)：1）確定報(bào)價(jià)的持續(xù)時(shí)間需要使用諸如 LEAD 或 next 之類(lèi)的窗口函數(shù)；2）必須處理每個(gè)報(bào)價(jià)，因此這是對(duì)原始掃描速度的測(cè)試。

4. 備選方案

要說(shuō)明一下，我們?cè)?kdb+ 上擁有豐富的經(jīng)驗(yàn)，因此，我們對(duì)響應(yīng)時(shí)間的預(yù)期大部分來(lái)自于這部分經(jīng)驗(yàn)。在原始單核速度方面，我們還沒(méi)有發(fā)現(xiàn)比 kdb + 更快的工具。但因?yàn)閮r(jià)格、陡峭的學(xué)習(xí)曲線(xiàn)和缺乏可操作工作等原因，我們沒(méi)有把 kdb+ 列在備選名單中。

平面文件（Flat File）

雖然數(shù)據(jù)庫(kù)是最常見(jiàn)的數(shù)據(jù)存儲(chǔ)，但是直接處理平面文件是真正關(guān)鍵的競(jìng)爭(zhēng)優(yōu)勢(shì)，因?yàn)樗峁┝舜鎯?chǔ)數(shù)據(jù)的最大靈活性。如今，有多種工具可以有效操作存儲(chǔ)在本地磁盤(pán)或 S3 存儲(chǔ)桶上的平面文件，例如：Python（帶有 Jupyter 的 Pandas）、Apache Spark、Amazon Redshift Spectrum 甚至 clickhouse-local。

我們?cè)?AWS 上使用 Apache Spark 嘗試了 EMR（Elastic Map Reduce）集群，雖然設(shè)置起來(lái)相對(duì)容易，但我們?nèi)耘f花了一些時(shí)間才弄清楚如何從文件和 JDBC 源加載數(shù)據(jù)，以及如何使用 Spark 數(shù)據(jù)集和 PySpark 數(shù)據(jù)幀。我們的結(jié)論是，這可以用于具有適當(dāng)擴(kuò)展能力的批處理分析，但不能用作主數(shù)據(jù)庫(kù)。不過(guò)，我們對(duì) Hadoop 和 Spark 的了解有限，因此對(duì)于結(jié)論判斷也會(huì)有所影響。

不過(guò)，我們?nèi)匀徽J(rèn)為這是一個(gè)精心設(shè)計(jì)的系統(tǒng)，該系統(tǒng)以正確方式組織文件和目錄，還帶有相應(yīng)的工具和規(guī)劃好的作業(yè)，對(duì)于能夠分配適當(dāng)資源的高級(jí)用戶(hù)而言，這可能是一個(gè)可行的選擇。但是對(duì)于我們來(lái)說(shuō)，我們認(rèn)為它可能太脆弱且缺乏組織性，我們還需要其他一些花哨的功能。

MySQL

我們只把 MySQL 視為一個(gè)起點(diǎn)，主要是為了確認(rèn)傳統(tǒng)的 RDBMS 對(duì)我們而言并不是真正的正確答案。MySQL 不是時(shí)間序列數(shù)據(jù)庫(kù)，也不是面向列的，并且不支持我們正在尋找的高級(jí)分析特性或性能指標(biāo)。

它的優(yōu)點(diǎn)是免費(fèi)，還有龐大的社區(qū)。它的支持者會(huì)聲稱(chēng)，只要你知道方法，它就可以做任何事情。在我們的測(cè)試中，MySQL（InnoDB 引擎）無(wú)法跟上連接池中 250K/ 秒的快速批量插入，并且隨著表增加到幾百萬(wàn)條記錄，插入速率也下降了。磁盤(pán)上的數(shù)據(jù)大小看起來(lái)非常大，查詢(xún)幾百萬(wàn)條記錄時(shí)的響應(yīng)時(shí)間以秒為單位。即使可以添加索引，具有數(shù)百萬(wàn)條記錄的聯(lián)接表也無(wú)法在可接受的時(shí)間內(nèi)完成。

在校對(duì)本文的草稿時(shí)，一位前同事向我們推薦了 MariaDB 列存儲(chǔ)，由于時(shí)間限制，我們無(wú)法對(duì)其進(jìn)行全面評(píng)估。

PostgreSQL 和 TimescaleDB

在我們的負(fù)載測(cè)試中，PostgreSQL 比 MySQL 更好，尤其是在插入速率和表大小增加時(shí)響應(yīng)時(shí)間的退化水平方面，但對(duì)于實(shí)際需求而言還不夠好。

TimescaleDB 似乎很有競(jìng)爭(zhēng)力——它是一個(gè) PostgreSQL 擴(kuò)展，使用大量常規(guī) PostgreSQL 表創(chuàng)建一個(gè)稱(chēng)為超表的虛擬表。在超表上的所有查詢(xún)和操作都向下傳遞到適當(dāng)?shù)膲K表。這里的主要目的是提高插入速率，并在處理大量數(shù)據(jù)時(shí)提供可預(yù)測(cè)的查詢(xún)時(shí)間。TimescaleDB 還提供了一些與時(shí)間序列相關(guān)的功能，以幫助分析。

宣傳的效果很好，但實(shí)際跑起來(lái)就不行了。最初的插入速率很不錯(cuò)（250K / 秒），但我們無(wú)法提取 3500 萬(wàn)筆交易記錄——它莫名其妙地耗盡了內(nèi)存。我們還注意到，文本文件加載器無(wú)法利用服務(wù)器上所有可用的內(nèi)核。提取數(shù)據(jù)時(shí)，我們發(fā)現(xiàn)服務(wù)器上的 IOWait 時(shí)間比其他數(shù)據(jù)庫(kù)長(zhǎng)得多，這可能是由于缺少磁盤(pán)壓縮所致。磁盤(pán)空間使用率也很高——存儲(chǔ)的數(shù)據(jù)比完全未壓縮的文本數(shù)據(jù)占用的空間還要多，這是很奇怪的（也許是因?yàn)轭A(yù)分配？）。我們知道最近的版本支持原生壓縮了，但是我們無(wú)法將其自動(dòng)用于新提取的數(shù)據(jù)。

ClickHouse

ClickHouse 基本可以算是一個(gè)新玩家，幾乎擁有我們夢(mèng)寐以求的所有特性：

• 它是 FOSS、速度超快、水平可伸縮、容錯(cuò)、硬件支持良好，并且具有磁盤(pán)（包括分層存儲(chǔ)）上的高級(jí)數(shù)據(jù)管理；
• 開(kāi)發(fā)過(guò)程非常透明，在 Github 上有活躍的社區(qū)，并且每 2 至 3 周發(fā)布一次更新，其中包含新功能、改進(jìn)和修復(fù)；
• 文檔很好，很容易從維護(hù)者那里得到問(wèn)題的答案。

ClickHouse 主要是一個(gè) OLAP 引擎，沒(méi)有真正的事務(wù)支持可言——例如，它不支持插入數(shù)據(jù)的更新和刪除，除非通過(guò)笨拙的異步 ALTER TABLE 命令。它還不支持窗口函數(shù)（neighbor 和 runningAccumulate 這類(lèi)特殊情況除外），這讓人有些驚訝，畢竟它主要針對(duì)的是時(shí)間序列。

我們?cè)谖磫⒂萌魏螐?fù)制功能的單個(gè)節(jié)點(diǎn)上測(cè)試了 ClickHouse。ClickHouse 能夠以超過(guò) 1M/sec 的速度加載 3500 萬(wàn)筆交易和 7.19 億筆報(bào)價(jià)。它使用特殊的磁盤(pán)數(shù)據(jù)結(jié)構(gòu)（MergeTree）將數(shù)據(jù)盡快寫(xiě)入臨時(shí)文件，然后在后臺(tái)合并，從而達(dá)到很高的速度。它永遠(yuǎn)不會(huì)用完內(nèi)存（只有一個(gè)例外），并且使用壓縮過(guò)的源文件節(jié)省了將近一半磁盤(pán)空間，效率極高。

遺憾的是，我們無(wú)法克服一些關(guān)鍵障礙：

• 發(fā)出查詢(xún)的唯一方法是使用類(lèi)似 SQL 的查詢(xún)語(yǔ)言，但有一些嚴(yán)格的限制：每個(gè)請(qǐng)求只能發(fā)出一個(gè)選擇語(yǔ)句，并且不支持用戶(hù)定義函數(shù)（UDF）或存儲(chǔ)過(guò)程（Stored Procedure）。
• 他們的哲學(xué)可以概括為"只能聽(tīng)我的"。維護(hù)人員對(duì)一些合理的用戶(hù)請(qǐng)求（例如支持日期時(shí)間數(shù)據(jù)類(lèi)型中的亞秒級(jí)精度）給出了無(wú)法令人滿(mǎn)意的答復(fù)。公平地說(shuō)，有些回應(yīng)也有正當(dāng)?shù)睦碛桑强吹竭@些交流仍然有些令人不安。

總而言之，我們還是認(rèn)為 ClickHouse 具有很大的潛力，將密切關(guān)注其發(fā)展，甚至我們會(huì)在系統(tǒng)中的非關(guān)鍵部分部署 ClickHouse。

DolphinDB

DolphinDB 是一種奇特的專(zhuān)用產(chǎn)品，在這次評(píng)估之前我們完全沒(méi)注意過(guò)它。這是一個(gè)快速的分布式時(shí)間序列分析數(shù)據(jù)庫(kù)，是 kdb+ 的可行替代方案。來(lái)自 kdb+ 的背景激發(fā)了我們的興趣，即便它是付費(fèi)產(chǎn)品，也足以讓我們?cè)囉靡幌隆?/p>

我們對(duì)它的總體印象是積極的。它比 ClickHouse 更快，甚至可能比 kdb+ 更快。它擁有對(duì)多節(jié)點(diǎn)集群的原生支持、功能豐富的函數(shù)式編程語(yǔ)言以及優(yōu)化的內(nèi)存上以及磁盤(pán)上的數(shù)據(jù)結(jié)構(gòu)。它僅用 6 秒鐘就將我們的 3500 萬(wàn)筆交易載入了一張表！它僅在 358 毫秒內(nèi)就執(zhí)行了所有 SPY 交易及其主要報(bào)價(jià)之間的 as-of join，在 25 秒鐘內(nèi)對(duì)所有代碼執(zhí)行了同樣的聯(lián)接，而在 kdb+ 上一次查詢(xún)大約需要 5 分鐘。另外，存儲(chǔ)數(shù)據(jù)的磁盤(pán)用量還不到壓縮后的源文件的一半。

它還有一些高級(jí)功能（我們未測(cè)試）包括：支持流和發(fā)布 / 訂閱、實(shí)時(shí)聚合 / 窗口引擎、實(shí)時(shí)異常檢測(cè)引擎、高級(jí)統(tǒng)計(jì)分析函數(shù)和機(jī)器學(xué)習(xí)函數(shù)

盡管它表現(xiàn)極佳，但仍有一些我們無(wú)法克服的負(fù)面因素：

• 成本：雖然它看起來(lái)比 kdb+ 便宜，但對(duì)我們來(lái)說(shuō)仍然太貴了；
• 需要學(xué)習(xí)非標(biāo)準(zhǔn)語(yǔ)言（盡管比 kdb+ 容易得多），不過(guò)，好在它的文檔完整出色；
• 對(duì)于關(guān)鍵業(yè)務(wù)組件，我們真的可以考慮為（對(duì)我們而言）未經(jīng)驗(yàn)證且尚無(wú)法判斷其局限性的閉源產(chǎn)品付費(fèi)嗎？讓人猶豫不決的是，它出現(xiàn)了幾次崩潰和莫名其妙的內(nèi)存不足情況，這都是扣分點(diǎn)。

不過(guò)，看來(lái)我們可能已經(jīng)發(fā)現(xiàn)了比 kdb+ 更快、功能更豐富的產(chǎn)品，這一點(diǎn)得分很高。我們將密切注意這款產(chǎn)品，如果對(duì)具有這些能力的產(chǎn)品（例如 tick 數(shù)據(jù)研究環(huán)境）有強(qiáng)烈的需求，我們一定會(huì)考慮它的。

MemSQL

現(xiàn)在要講的是，我們最終的選擇——MemSQL 了。MemSQL 是一種付費(fèi)產(chǎn)品，但它也為初始集群提供了免費(fèi)的商業(yè)許可證，其最多可包含 4 個(gè)節(jié)點(diǎn)、128 GB 內(nèi)存和無(wú)限的磁盤(pán)數(shù)據(jù)。我們認(rèn)為這足以滿(mǎn)足我們?cè)诳紤]付費(fèi)產(chǎn)品之前的初始需求了。

MemSQL 將自己定義為名為 HTAP（混合事務(wù) / 分析處理）的新數(shù)據(jù)庫(kù)種類(lèi)。MemSQL 的主要賣(mài)點(diǎn)有：它提供快速的分析功能，同時(shí)具有豐富的事務(wù)支持并充分兼容 SQL。它甚至可以與 MySQL 兼容，因此你可以使用所有 MySQL 工具和驅(qū)動(dòng)程序。與龐大的工具生態(tài)系統(tǒng)集成是很棒的，但也存在一些障礙，因?yàn)樗茈y使用純 SQL 表示某些高級(jí)分析。由于它以 UDF 和存儲(chǔ)過(guò)程提供了對(duì)過(guò)程語(yǔ)言的全面支持，我們接受了這一特殊缺點(diǎn) [注意：過(guò)程方法比通常的矢量化操作至少慢一個(gè)數(shù)量級(jí)]。

MemSQL 支持內(nèi)存上行存儲(chǔ)表以及磁盤(pán)上列存儲(chǔ)表，帶有分片、排序和壓縮功能（它們最近還發(fā)布了混合單存儲(chǔ)格式。我們僅使用 Columnstore 進(jìn)行了測(cè)試，特別是考慮到我們的測(cè)試實(shí)例只有 32GB 內(nèi)存。就部署、管理、監(jiān)視、集群設(shè)置甚至數(shù)據(jù)的加載和查詢(xún)而言，MemSQL 是最容易使用的工具之一。

我們能夠以超過(guò) 50 萬(wàn)條記錄 / 秒的速度加載交易和報(bào)價(jià)。我們注意到，服務(wù)器上的加載過(guò)程能夠使用多個(gè)內(nèi)核并行化提取。加載的數(shù)據(jù)占用的空間與壓縮后的源文件大致相同。我們還觀察到，使用 JDBC 接口時(shí)，外部工具能夠以超過(guò) 1Gbps 的速度從 MemSQL 讀取數(shù)據(jù)，這特別令人印象深刻。

大多數(shù)單表查詢(xún)以及多表聯(lián)接查詢(xún)的整體性能都很好。它在 as-of joins 中表現(xiàn)不佳，但畢竟它根本不是針對(duì)該用例設(shè)計(jì)的。我們花了很多時(shí)間試圖以最佳方式在 SQL 中表示一個(gè) as-of join，最后我們強(qiáng)迫引擎執(zhí)行（相對(duì)）快速的 MergeJoin。可以預(yù)期，廠(chǎng)商將來(lái)可以作為自定義操作添加對(duì) as-of-join 的專(zhuān)門(mén)支持。

總而言之，MemSQL 是我們?cè)谡{(diào)查中可以找到的最平衡解決方案。它很成熟、易于使用、免費(fèi)（暫時(shí)）、快速、高效且可與我們想要的所有標(biāo)準(zhǔn)工具互操作。

5. 結(jié)果統(tǒng)計(jì)

針對(duì)以上測(cè)試，我們做了一個(gè)詳細(xì)的數(shù)據(jù)統(tǒng)計(jì)和對(duì)比：

如果想要更詳細(xì)查看我們的測(cè)試結(jié)果，可以查看這里：

https://github.com/prerak-proof/dbtests

6. 總結(jié)

我們知道還有其他許多工具可以評(píng)估，尤其是各種 NoSQL 數(shù)據(jù)庫(kù)。我們的總體感受是，盡管這些選項(xiàng)也可能處理我們的數(shù)據(jù)規(guī)模，但它們大概無(wú)法滿(mǎn)足我們的性能期望。至少到現(xiàn)在，我們認(rèn)為 MemSQL 是最適合我們的產(chǎn)品，既能滿(mǎn)足我們的需求，也符合我們的約束條件。