一個被頻繁提出的問題就是，Apache Cassandra和Apache Ignite之間的區別是什麼，這很正常，因爲這兩個數據庫有很多的共同之處，比如水平擴展性、高可用和持久化。在本系列的前四篇文章中，已經介紹了了架構以及從開發角度上的主要區別：
- Apache Cassandra和Apache Ignite: 架構簡化思考
- Apache Cassandra和Apache Ignite：關係並置和分佈式SQL
- Apache Cassandra和Apache Ignite：強一致和事務
- Apache Cassandra和Apache Ignite：通過Ignite增強Apache Cassandra
在對比Ignite和Cassandra時，還有一個無法迴避的問題，現在也需要揭曉答案，問題很簡單，就是兩者的性能差異如何？從哪裏可以得到性能測試結果？
自從Ignite完整支持內存存儲之後，兩者之間的測試就變得不再對等，因爲Ignite可以在內存中持有TB甚至PB級的數據，而Cassandra的內存選項非常有限。但是，不管怎樣，測試一下性能指標然後分享出來，還是有價值的。
環境和配置
下面快速瀏覽一下測試環境以及Ignite和Cassandra配置參數的細節，沒什麼特別的，這類文章都會有這樣的內容。 常規參數
- 硬件：
- CPU：2x Xeon E5-2609 v4 1.7GHz
- RAM：96Gb
- SSD：3x800Gb SSD RAID0 2.4Tb
- 網絡：10Gb/s
- 集羣大小：3服務端節點，1客戶端節點（應用）
- 測試框架：Yahoo! Cloud Serving Benchmark
- 數據大小：8000萬條目/記錄
Ignite參數
- 版本：Apache Ignite 2.4
- 內存配置：所有數據都同時存儲在內存以及Ignite持久化中
- 緩存模式：ATOMIC
- 複製因子：1主1備
- 寫同步模式：FULL_SYNC
- WAL刷新模式：LOG_ONLY
Cassandra參數
- 版本：3.11.1
- 鍵空間：2副本
- 寫一致性：ALL
- 讀一致性：ONE
- commitlog_sync：periodic（默認），10s
- JVM_OPTS="-Xm48g -Xmx48g -Xmn1600M -XX:+UseG1GC"
- key_cache_size_in_mb: 4096
- row_cache_size_in_mb: 32768
- caching = { 'rows_per_partition' : 'ALL' }
- bloom_filter_fp_chance = 0.01
- 讀測試執行兩次，對緩存進行預熱
預期結果
首先，使用32個應用線程，模擬小負載訪問Ignite和Cassandra，下圖是最終的測試結果：
Y軸表示每秒操作數，X軸表示度量的操作類型，總而言之，這一輪測試告訴我們：
- 對於讀負載，Ignite顯著優於Cassandra（快3倍），對於混合負載（讀+更新，快2倍），這很正常，因爲Ignite在內存中有數據的完整副本；
- 對於密集的寫負載（插入和更新），兩者差不多，因爲兩者都需要將變更持久化到磁盤。
接下來，會使用256個應用線程並行地增加負載：
會發現，兩者都發生了明顯的變化：
- Ignite保持了在讀負載和混合負載下的領先優勢，平均快6倍；
- Cassandra在更新操作中領先，這是合理的，因爲Cassandra列式存儲在架構上對這些操作有利，所以本次測試在預期範圍內對其進行了重現，而Ignite繼承了大部分關係數據庫的原則，比如對一致性和索引數據的處理。
Ignite還是Cassandra？
如果性能需求和嚴格的SLA影響最終決定，那麼對於高負載情況下的寫密集應用，Cassandra會是一個好的選擇，而對於Ignite，在重度的讀或者混合負載下，會有超預期的表現。
此外，作爲整個系列的總結，公平地講，雖然性能對決策有很大的影響，但是還有很多其他的因素需要考慮。比如，因爲寫密集型負載的性能而選擇了Cassandra的，就放棄了分佈式事務的強一致性、放棄了規範化架構、放棄了使用SQL進行查詢的優勢。同時，如果確實需要Ignite中超過Cassandra的功能（簡化架構、強一致、並置處理和SQL、內存級性能），那麼對於寫密集負載考慮使用Ignite也是符合邏輯的，因爲從測試結果來說，兩者在中等規模寫負載情況下，性能差不多。
最後，本文和測試完成於2018年3月15日，誰知道未來會怎麼樣呢？拭目以待吧。
本文譯自社區Denis Magda的博客。