各大記憶體資料庫系統對比
這裡比較四個記憶體資料庫系統情況，分別是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。