前一陣子公司有個售前來溝通某個使用者的情況：資料量比較大，又涉及很多複雜的關聯計算，在資料庫中用 sql 計算效能很差。本來這種場景是比較適合集算器的集檔案（集算器特有的壓縮二進位制格式）儲存並計算，但據說這個使用者的歷史資料還會經常變動，而集檔案目前沒有提供改寫能力（為了保證壓縮率和效能），也就不容易直接用。於是想推薦使用者採用 nosql 產品做儲存，集算器在上面做計算。
趕快打住！如果使用者真的聽了，那會恨死我們。
這個場景中有三個要素：資料量大、複雜計算、頻繁改動。
為了解釋這三者的大致關係，我畫了乙個不太嚴謹的圖：
nosql 資料庫在儲存時不考慮事務一致性，而且許多 nosql 產品對 key-value 結構（要改的資料肯定要有個 key）的資料都會採用 lsm 樹等優化手段，一般情況比 rdb 常用的 b 樹效能要好，所以對於頻繁改的應用，nosql 的效率會比較高。相反，rdb 雖然也能頻繁改，但為了事務一致性等因素，效率就會低於 nosql。
但 key-value 結構的 nosql 卻不擅長大資料計算，除了按 key 找 value 比較快以外，涉及到遍歷（這是家常便飯）的運算都不靈光，主要是因為 value 是無確定結構的，每次取出資料要現解析，而且資料結構也會多存很多空間，所以大資料計算效率就會遠遠低於 rdb（所以上述場景一定要打住，絕不可以推薦 nosql）。
rdb 頻繁修改後會導致資料在硬碟上的連續性很差，也不容易做好壓縮，這樣大資料量遍歷的效能也不會太好。而 rdw 在 rdb 基礎上做了運算優化，可以事先整理資料，放棄了複雜的寫一致性能力，這樣對於大資料計算就會有更好的效能。但反過來，頻繁改就不適合了。
rdb 和 rdw 都採用 sql 體系運算，對於簡單查詢計算沒太大問題，但過於複雜的關聯和過程性運算，由於關係代數的侷限性，很多優化演算法無法實施（我們已經多次說過這個問題），所以在複雜運算場景下效能不佳（也就會發生上述場景的現象）。
集算器是為了複雜計算而設計，可以實現更優的演算法獲得更好的效能。但如開始所述，目前的集檔案又不支援改寫，所以它只適合解決複雜運算，而難以面對頻繁改的場景。集算器其實比 rdw 在大資料計算效能方面更好，不過作為計算引擎並不太關注儲存，而大資料需求中還是會比較在意的可維護管理能力就要弱了。
集算器進一步發展出來的倉庫版將支援少量修改的儲存方案，這樣可以在保證複雜運算能力的基礎上再提供資料維護能力，可以逐步替代資料倉儲，不過也不合適頻繁修改。而另乙個方向的雲庫版則更注重結構多樣性，同時也支援事務一致性，能適應頻繁改，而且有集算器提供複雜計算能力，但同前面分析 nosql 的理由，這時候它又不適合大資料遍歷了。
那麼這三樣都想要怎麼辦呢？難道就只能見鬼去？
其實也有辦法，只要肯多花錢買大記憶體（還可能要集群）把資料全裝進去，這三樣就能並存了。畢竟，有錢能使鬼推磨嘛，呵呵！
儲存和計算技術的選擇
前一陣子公司有個售前來溝通某個使用者的情況 資料量比較大，又涉及很多複雜的關聯計算，在資料庫中用sql計算效能很差。本來這種場景是比較適合集算器的集檔案 集算器特有的壓縮二進位制格式 儲存並計算，但據說這個使用者的歷史資料還會經常變動，而集檔案目前沒有提供改寫能力 為了保證壓縮率和效能 也就不容易直...
雲計算技術
雲計算基礎設施架構 雲計算基礎設施平台一般分為以下幾層 物理設施，虛擬化，管理，服務提供。物理設施被虛擬化，提供乙個靈活的資源池體提高資源利 用率。管理層負責物理資源和虛擬資源池的管理 部署 監控 報警等。服務提供層組合管理層的功能提供某種形式的服務。雲計算存在的難題 連續高可用性 某個集群的失效處...
RAC（Oracle網格計算技術）
不同的集群產品都有自己的特點，rac的特點包括如下幾點 雙機並行。rac是一種並行模式，並不是傳統的主備模式。也就是說，rac集群的所有成員都可以同時接收客戶端的請求。高可用性。rac是oracle資料庫產品高可用性的解決方案，能夠保證在集群中只要有乙個節 不同的集群產品都有自己的特點，rac的特點...