一份2018年最新的NoSQL測試報告

最近，ArangoDB官方發布了一份關于ArangoDB與其它主流NoSQL系統的對比測試報告，測試所選取的場景可能是ArangoDB所擅長的場景，但好在這些場景還算是比較普遍的場景，從客觀的角度來看依然是有參考價值的。

ArangoDB

相信關于”One size does not always fit all“的思想已經深入人心，然而，ArangoDB卻定位于在一個數據庫系統中，通過一種查詢語言，能夠同時支持如下能力：

文檔存儲

圖存儲

KeyValue存儲

這就是所謂的Multiple Data Models數據庫，正如ArangoDB官方所提供的描述：

One Core. One Query Language. Multiple Data Models.

Gartner于2016年10月份發布的報告《Magic Quadrant for Operational Database Management Systems》中，關于2017年的戰略規劃設想部分，曾重點提及Multiple Data Models Databases：

By 2017, all leading operational DBMSs will offer multiple data models, relational and nonrelational, in a single DBMS platform.

By 2017, the “NoSQL” label will cease to distinguish DBMSs, leading data and analytics leaders to select multimodel and/or specific document-style, key-value, graph and table-style engines.

報告總覽

該報告涉及了隨機讀寫，聚合統計，最短路徑查詢，擴線查詢等幾種場景，并且與主流的文檔數據庫(MongoDB)、圖數據庫(Neo4j)、關系型數據庫(postgresql)以及其它Multiple Data Models Database(OrientDB)做了對比，從結果上來看：

在大多數場景中，基于RocksDB作為存儲引擎的ArangoDB，均取得了非常不錯的表現，尤其是在圖數據庫專有的”擴線查詢”和”最短路徑”查詢中，居然遠優于Neo4j，這一點倒是比較驚訝。在聚合統計上，基于Tabular存儲的postgresql，具有非常明顯的優勢。而另外一個Multiple Data Models Database(OrientDB)在圖計算能力上的表現卻差強人意。

軟件版本

Neo4j 3.3.1

MongoDB 3.6.1

PostgreSQL 10.1 (tabular & jsonb)

OrientDB 2.2.29

ArangoDB 3.3.3

測試環境

Server: i3.4xlarge on AWS with 16 virtual cores, 122 GB of RAM, 1900 GB NVMe-SSD

Client: c3.xlarge on AWS with four virtual CPUs, 7.5 GB of RAM and a 40 GB SSD

測試數據

測試數據源自Pokec上的社交關系數據，由Standford University SNAP提供。這些數據中，共包含：

1,632,803 people（Vertices信息）

30,622,564 edges（Edge用來描述兩個Vertices之間的關系）

關于描述people的信息包括{gender, age, hobbies, interest, education, …}。

未壓縮的原始數據大小信息：

Vertices： 600 MB

Edges： 1.832 GB

任意兩個Vertices之間的最短路徑的最大長度為11，而這些這些Vertices之間是高度相關聯的，因此，如果想查詢任意兩個Vertices之間的最短路徑是相對比較難的。

測試場景

Single-read讀取單個Document

Single-write寫入單個Document

Single-write sync寫入單個Document，等待fsync成功

Aggregation針對一個Collection之上的ad-hoc聚合查詢，計算年齡的分布信息

Neighbors second查找”A的朋友的朋友的”二層擴線查詢，并且返回1000個不同的Vertices的ID列表。

Neighbors second with data?查找”A的朋友的朋友的”二層擴線查詢，并且返回100個不同的Vertices的詳細信息(攜帶描述字段信息)。

Shortest path查找任意兩個Vertices之間的最短路徑。

Memory關注測試期間的平均內存使用信息。

詳細結果

Aggregation(聚合統計)

結果點評：

基于tabular存儲的PostgreSQL具有明顯的性能優勢。

Neighbors second(擴線查詢)

結果點評：

僅僅返回1000個Vertices ID列表，而不涉及具體的字段信息時，基于RocksDB的ArangoDB表現最佳。

同為Multiple Data Models的OrientDB在擴線查詢上表現最差，甚至差于MongoDB。

結果點評：

當返回100個Vertices以及相關聯的字段信息時，基于Tabular存儲的PostgreSQL表現最佳。原因應該在于，返回Vertices數量的減少使得讀取的數據量減少了。

ArangoDB的表現次優，該結果與不帶數據時的結果差不多。

MongoDB查詢攜帶有字段信息的結果也遠優于不帶字段信息的結果，原因同樣應該是返回的Vertices數量減少的緣故，作為文檔類型的MongoDB未對擴線查詢做針對性優化也在情理之中。

Shortest path(最短路徑查詢)

結果點評：

因為”最短路徑查詢”屬于圖數據庫的范疇，并沒有測試MongoDB與PostgreSQL。

“最短路徑查詢”其實包含兩部分，第一是通過擴線查詢將所需的Vertices以及Edges加載到內存中，第二是最短路徑算法，而第一點往往是影響性能的關鍵，因此，在擴線查詢上表現最佳的ArangoDB在”最短路徑查詢”中結果也理所當然是最佳的。

Memory Usage(內存占用)

結果點評：

在內存占用上，基于Tabular存儲的PostgreSQL表現最佳，這與PostgreSQL底層優秀的壓縮與編碼機制有關。

Neo4j的內存占用最大，從這點上看的出來，Neo4j是依賴于Caching來提升性能的。

最后的總結

作為Multiple Data Models的ArangoDB在圖存儲能力上以及單點讀寫能力上，均有不錯的表現，但”百萬頂點，千萬條邊”的數據量級，似乎是偏小了一些，尤其是在測試實時寫入時的”10萬個Documents”實在是太小。如果將數據量放大以后，相信這些測試結果的排序將會帶來一些變化。

關于測試報告詳情，感興趣的同學可以參考下面參考信息中的鏈接，原文中附有測試源代碼的路徑。

參考信息

1.?https://www.arangodb.com/

2.?NoSQL Performance Benchmark 2018 – MongoDB, PostgreSQL, OrientDB, Neo4j and ArangoDB

數據庫 NoSQL

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

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