這裏比較四個內存數據庫系統情況，分別是Timesten、AltiBase、ExtremeDB、CacheDB（自研），需要說明的是，這是這段時間的粗略感性認識（並沒有經過一段時間的使用，是換不來理性的客觀認識）
一、市場與技術支持比較
|
項目 |
市場及應用領域比較 |
排行 |
|
Timesten |
全球化，領域全面，金融領域有應用。 |
2 |
|
AltiBase |
韓國及東南亞，分佈較廣，電信市場爲主體 |
4 |
|
Extreme |
全球化，領域全面，在國內的金融領域有大商所撮合系統、國際有印度證券風控系統 |
1 |
|
CacheDB |
集中在電信、廣電、監控領域。… |
3 |
|
項目 |
金融領域和電信領域對數據庫的要求特性比較 |
|
金融領域 |
數據的複雜度和量很高很大。傳統應用對數據訪問性能要求不高，近年來對性能要求在提高 |
|
電信領域 |
數據的複雜度較低，量很大，對數據訪問性能要求一直都很高。 |
|
項目 |
市場及應用領域比較 |
排行 |
|
Timesten |
市場老大，不見得會強力支持。 |
3 |
|
AltiBase |
中國區的技術支持力量薄弱。 |
4 |
|
Extreme |
感覺會提供更好的支持。 |
2 |
|
CacheDB |
… … |
1 |
二、數據庫集成特性比較
|
項目 |
耦合特性比較 |
排行 |
|
Timesten |
鬆耦合（獨立的不同進程），可採用共享內存直連和CS兩種模式進行訪問。 |
3 |
|
AltiBase |
鬆耦合（獨立的不同進程），可採用共享內存直連和CS兩種模式進行訪問。 |
2 |
|
Extreme |
緊耦合（作爲一個庫嵌入應用進程），可通過共享內存進行不同應用間的數據共享。 |
4 |
|
CacheDB |
既支持緊耦合模式（小容量，作爲一個庫嵌入應用進程）、也支持鬆耦合模式（大容量，獨立的不同進程，採用CS模式進行訪問） |
1 |
|
項目 |
接口特性比較 |
排行 |
|
Timesten |
JDBC/ODBC/OCI，支持SQL交互 |
4 |
|
AltiBase |
JDBC/ODBC/ACI，XDB支持API，支持SQL交互 |
3 |
|
Extreme |
API，支持SQL交互 |
2 |
|
CacheDB |
API，支持SQL交互 |
1 |
|
項目 |
系統複雜度 |
排行 |
|
Timesten |
難管理 |
4 |
|
AltiBase |
較易管理 |
2 |
|
Extreme |
易管理 |
1 |
|
CacheDB |
易管理 |
1 |
三、數據庫通用特性比較
|
項目 |
表特性比較 |
排行 |
|
Timesten |
行表； |
2 |
|
AltiBase |
行表 |
2 |
|
Extreme |
行表、列表，還可並存 |
1 |
|
CacheDB |
行表 |
3 |
|
項目 |
索引特性比較 |
排行 |
|
Timesten |
T樹、散列(靜態，可通過語句動態調整)，主/外鍵 |
2 |
|
AltiBase |
B樹、散列（靜態，可通過語句動態調整)，主/外鍵 |
2 |
|
Extreme |
B樹、散列（動態，但可能會影響應用的訪問）、KD樹、R樹、前綴匹配樹可以通過OID等實現 |
1 |
|
CacheDB |
散列（靜態，可修改配置重啓生效，負載均衡模式下對業務不受影響）， T樹（目前不支持範圍查詢，僅僅用在漫遊號碼分配應用中） 前綴匹配樹（用作號碼分析） 不支持主/外鍵 |
3
|
|
項目 |
視圖 |
排行 |
|
Timesten |
支持 |
1 |
|
AltiBase |
只讀 |
2 |
|
Extreme |
不支持 |
3 |
|
CacheDB |
只讀，相比傳統視圖而言，功能更簡單。 |
2 |
|
項目 |
事務特性比較（目前風控系統不需要事務） |
排行 |
|
Timesten |
支持事務模型，默認不立即提交。 |
1 |
|
AltiBase |
支持事務模型，默認立即提交。 |
1 |
|
Extreme |
支持事務模型，必須手工提交。（非事務系統操作麻煩一些） |
2 |
|
CacheDB |
不支持事務模型。 |
3 |
|
項目 |
序列特性比較（目前風控系統不需要序列） |
排行 |
|
Timesten |
支持 |
1 |
|
AltiBase |
支持 |
1 |
|
Extreme |
不清楚是否支持 |
2 |
|
CacheDB |
不支持 |
2 |
|
項目 |
觸發器特性比較。 如果緊耦合模式下，一般不需要，但從數據庫複製數據到應用時應該支持。 鬆耦合模式下，應該要能支持（把部分計算的工作放在數據庫後臺，爲的是減少通信量） |
排行 |
|
Timesten |
支持腳本性觸發器或外掛C性驅動，但支持的特性不清楚 |
2 |
|
AltiBase |
支持腳本性觸發器，但支持的特性不清楚 |
2 |
|
Extreme |
支持C性驅動，通過Event實現事件觸發等。 |
2 |
|
CacheDB |
支持C性驅動，緊耦合方式下，僅在數據庫動態通知到應用時支持。鬆耦合模式下在應用修改時也支持（動態庫架構）。 |
1 |
|
項目 |
數據類型比較 |
排行 |
|
Timesten |
與Oracle一樣 |
3 |
|
AltiBase |
支持C數據類型和擴展類型 |
2 |
|
Extreme |
支持所有的C數據類型，還支持時間，變長數據類型及大文件數據類型如，string，vector，blob。 |
1 |
|
CacheDB |
僅支持C數據類型 |
1 |
|
項目 |
查詢特性比較(無條件查詢、條件查詢<索引查詢、非索引查詢，定值查詢、範圍查詢>、分段查詢<遊標>、分組查詢、排序查詢、模糊查詢) |
排行 |
|
Timesten |
都支持 |
1 |
|
AltiBase |
都支持 |
1 |
|
Extreme |
都支持，可以通過API和SQL等模式進行排序查詢，另外也還要落實大量的排序字段對系統性能的衝擊（這個需要根據應用場景進行測試，因素包括事務大小，環境信息等）。 |
2 |
|
CacheDB |
不支持分組查詢、排序查詢、模糊查詢、範圍查詢 目前模糊查詢的具體需求還不清楚，如果只是正則表達式模式，還是比較好加的。 增強範圍查詢的能力較難，範圍查詢支持後，分組排序查詢就不是難點。 |
4 |
四、數據庫持久特性比較
|
項目 |
純內存表 |
排行 |
|
Timesten |
支持 |
1 |
|
AltiBase |
支持 |
1 |
|
Extreme |
支持 |
1 |
|
CacheDB |
支持 |
1 |
|
項目 |
部分字段持久化 |
排行 |
|
Timesten |
不支持 |
4 |
|
AltiBase |
不支持 |
4 |
|
Extreme |
不支持 |
4 |
|
CacheDB |
支持 |
1 |
|
項目 |
本地文件持久化 |
排行 |
|
Timesten |
支持 |
1 |
|
AltiBase |
支持 |
1 |
|
Extreme |
支持 |
1 |
|
CacheDB |
支持 |
1 |
|
項目 |
數據庫持久化 |
排行 |
|
Timesten |
支持Oracle，其它數據庫的持久化，需要應用自行擴展 |
2-2 |
|
AltiBase |
支持HDB持久化（性能較好），但HDB接受程度需要打問號。 其它數據庫的持久化，需要應用自行擴展 |
3-1 |
|
Extreme |
不支持，需要應用自行擴展 |
4-4 |
|
CacheDB |
支持Oracle、MySql、SyBase無縫集成。尤其是Oracle和MySql |
1-2 |
第一個排行是指支持的能力，第二個排行指支持的性能
|
項目 |
數據庫部分列加載 |
排行 |
|
Timesten |
支持 |
1 |
|
AltiBase |
不支持 |
4 |
|
Extreme |
X |
4 |
|
CacheDB |
支持 |
1 |
|
項目 |
數據庫部分行加載 |
排行 |
|
Timesten |
支持，還能進行動態換出 |
1 |
|
AltiBase |
不支持 |
4 |
|
Extreme |
X |
4 |
|
CacheDB |
支持，不能進行動態換出 |
2 |
|
項目 |
數據庫故障對系統的影響 |
排行 |
|
Timesten |
無影響，有本地CheckPoint文件和增量日誌 |
1 |
|
AltiBase |
無影響，壓根不從數據庫讀。 XDB+HDB配合下，是很好的模式，但是任然需要應用干預。 |
2 |
|
Extreme |
無影響，有本地數據庫文件和redo,undo日誌 |
4 |
|
CacheDB |
無影響，有本地備份文件和增量日誌 |
1 |
|
項目 |
數據庫變更對應用的反向複製 |
排行 |
|
Timesten |
需要另外的組件，其它特性不清楚 |
3 |
|
AltiBase |
無需另外的組件，利用複製特性實現，其它特性不清楚 |
1 |
|
Extreme |
可以根據項目提供 |
4 |
|
CacheDB |
需要另外的組件，可觸發應用，便於做處理 |
2 |
|
項目 |
數據入庫特性 |
排行 |
|
Timesten |
同步日誌 |
2 |
|
AltiBase |
同步日誌，採用複製特性實現 |
1 |
|
Extreme |
同步日誌 |
4 |
|
CacheDB |
同步日誌， |
2 |
|
項目 |
高頻數據持久化策略（均沒有入庫的優化方案） |
排行 |
|
Timesten |
無特別方案 |
4 |
|
AltiBase |
無特別方案 |
4 |
|
Extreme |
無特別方案 |
3 |
|
CacheDB |
目前高頻數據採用本地保存的策略 |
1 |
五、數據庫部署特性比較
|
項目 |
主備方案 |
排行 |
|
Timesten |
支持，但需要應用層總裁 |
4 |
|
AltiBase |
無，需要應用管理 |
1 |
|
Extreme |
無，需要應用管理 |
1 |
|
CacheDB |
無，需要應用管理 |
1 |
|
項目 |
均衡方案 |
排行 |
|
Timesten |
支持，但不支持持久化 |
4 |
|
AltiBase |
支持，複製模型較複雜，最多32個節點 |
2 |
|
Extreme |
支持，無節點限制 |
1 |
|
CacheDB |
支持，最多16個節點 |
1 |
|
項目 |
本地表支持情況 |
排行 |
|
Timesten |
不清楚，從演示情況看，沒有體現出來 |
4 |
|
AltiBase |
支持，因爲複製是基於表級別的 |
2 |
|
Extreme |
支持，同時支持distributed特性，scatter和gather方式 |
1 |
|
CacheDB |
支持， |
1 |
|
項目 |
數據複製模型 |
排行 |
|
Timesten |
僅僅TCP，數據庫級別複製 |
4 |
|
AltiBase |
僅僅TCP，表級別複製 |
3 |
|
Extreme |
主播、單播TCP、管道、單播UDP，表級別複製 |
1 |
|
CacheDB |
主播或單播TCP，數據庫級別複製 |
1 |
|
項目 |
部分字段或部分記錄的複製支持 |
排行 |
|
Timesten |
全表複製 |
4 |
|
AltiBase |
全表複製 |
4 |
|
Extreme |
全表複製 |
4 |
|
CacheDB |
支持部分複製 |
1 |
六、數據庫一致性特性比較
|
項目 |
數據庫一致性策略 |
排行 |
|
Timesten |
支持事務，支持全同步方式(性能低)，也支持異步模式 |
2 |
|
AltiBase |
支持事務，支持全同步方式(性能低)，也支持異步模式 |
3 |
|
Extreme |
支持事務，支持全同步方式(性能低)，也支持異步模式 |
1 |
|
CacheDB |
不支持事務，採用異步方式，允許系統暫時的不一致 |
1 |
|
項目 |
數據庫衝突補救 |
排行 |
|
Timesten |
無 |
4 |
|
AltiBase |
無 |
4 |
|
Extreme |
可以通過mvcc的事務管理器進行衝突回滾，操作遵守ACID性 |
4 |
|
CacheDB |
有單獨的組件，進行不同節點數據的一致性檢查（包括與持久性數據庫系統之間），並提供策略讓應用恢復數據，原則是“錯，也要錯成一致” |
1 |
七、數據庫性能特性比較
|
項目 |
數據庫性能特性比較 |
排行 |
|
Timesten |
有公司做過比較測試 |
4 |
|
AltiBase |
2 |
|
|
Extreme |
從公開的測試數據來看，性能比AltiBase還快，官方網站上有1TB+的數據測試報告，內包含，join，子查詢。http://www.mcobject.com/index.cfm?fuseaction=download&pageid=657§ionid=154 |
1 |
|
CacheDB |
沒有做過純內存表的測試，從均衡測試情況來看，性能應該與Extreme相當 |
2 |
八、綜合比較（沒加權重）
（1）沒有加權的統計，並不一定能說明什麼問題。
|
統計 |
1 |
2 |
3 |
4 |
|
Timesten |
9 |
8 |
4 |
10 |
|
AltiBase |
8 |
10 |
4 |
9 |
|
Extreme |
12 |
6 |
2 |
11 |
|
CacheDB |
19 |
7 |
4 |
1 |
（2）從應用市場來看，Extreme無疑佔據較大優勢，無論從市場佔有率還是在金融領域的應用，都是相當不錯的。
（3）從數據庫與應用集成特性來看，CacheDB和Extreme的集成難度最小、AltiBase稍高、Timesten最大。
（4）從數據庫通用特性來看，Extreme、AltiBase、Timesten都差不多，CacheDB因爲不支持範圍查詢（雖有T樹索引），而相對較弱。
（5）從持久性上看，CacheDB無疑排在首位。Extreme不具備數據庫持久化能力，需要應用層做工作【工作量應該很大】，如果接受HDB的持久化模式，在持久化性能上應該最好，否則也和Extreme一樣。另外還有一個重要特性CacheDB可以支持臨時字段。
（6）從分佈式模式上看，CacheDB無疑排在首位。其次是Extreme，再就是AltiBase，Timesten最差。
（7）從數據一致性上看，強一致性的AltiBase、Timesten無疑性能低，所以用處不大，非強一致性的模式下，CacheDB提供了一致性補救措施。
（8）從性能上看，無疑Extreme和CacheDB都佔據頭號位置，而Timesten最差。
綜合來看：
（1） 如果CacheDB支持了範圍查詢，無疑是首選。
（2） 如果ExtremeDB支持了Oracle數據庫的持久化，無疑是首選。
（3） 如果大家能接受AltiBase的私有磁盤數據庫系統，或者支持Oracle數據庫系統，無疑是首選。
（4） 如果上面都不滿足，那就只能選擇Timesten。
