一些 Riak 適合與不適合的東西 Scenario ..
專心使用 Riak 也將近一年, 這一年來對他也算有那麼點小心得. 就大致分享一下使用 Riak 適合的場景, 以及他的功能.
Riak 其實就只是一個很簡單的 key-value DB.
他沒有 SQL, Cyper, Sparql 等神奇的 query language. 儘管他支援 map-reduce, secondary-index, key_filters ... 但以我們的經驗, 在 query 和分析上還是另尋高明比較好. 這不只是我們自己的說詞, Riak 官方目前停擺 Riak Search 的開發進度. 取而代之是新的東西 Yokozuna , 雖然他還在 alpha 階段. 而 Riak 官方自己也承認, 要分析, 搜尋, 應該使用類似 Solr 的東西. 這是一段節錄自 Little Riak Handbook 的話 :
What Happened to Riak Search?
If you have used Riak before, or have ahold of some older documentation, you may wonder what the difference is between Riak Search and Yokozuna.
In an attempt to make Riak Search user friendly, it was originally developed with a "Solr like" interface. Sadly, due to the complexity of building distributed search engines, it was woefully incomplete. Basho decided that, rather than attempting to maintain parity with Solr, a popular and featureful search engine in its own right, it made more sense to integrate the two.
儘管我們還是很高興地使用著 Riak 內建的 query interface, 比如 map-reduce, key-filters, secondary-index. 但這意味著如果想要無痛轉換, 那麼也許 Mongo 比較適合? 或是有支援 Sparql, gremlin 的 db 如 neo4j, infinite? 否則, 就得花很多力氣在這方面了. 適合 : 關系不算複雜, 但有大量儲存需求. 不適合 : 需要做複雜的 query, 他也許不適合. ( 至於我們使用 riak 來處理 graph, 是因為我們寫了很多 code 去處理 & query ... :p )
Riak 專注在 Scalability 和 Availability , 以 CAP 理論就是 AP.
雖然透過 write 的份數, 可以調整 consistent, 但那就有點失去本意. 而且, 其實 consist 的速度並不慢.. 以我們來說, 因為寫入量大, 如果 crash 就會很麻煩, 所以寧願他不一致, 也要不 miss 任何寫入的資料. 適合 : 絕對不能當機, 存取不到, 下線. 比如廣告. 不適合 : 需要資料一定是正確的, 比如金融交易, 那就不適合.
Riak CS 支援 Large File 和 s3 等背後儲存.
因為 riak cs 大部份功能 (除了 multiple-datacenter) 在前些日子 open source. 使得 Riak 更適合做為一個資料儲存的解決方案. 這裡說的是資料儲存喔, 不是分析.. 作為一個 Cloud Storage, 內建支援 s3 是一定要的. 而 Riak CS 的幾個亮點在於 : - Per-Tenant Visibility : 這樣的功能意味著我們可以在本地端對儲存空間的狀況一目瞭然, 包括用了多少空間, 目前的費用.. 等等 - Supports Large Objects of Arbitrary Content Type, Plus Metadata : Support Large Objects 聽起來像廢話, 不過後面的可就不是了. 因為我們可以切割檔案, 並且把每個 Object 都加上 Metadata, Content-Type, 想像一下這是什麼意思? YouTube Stream ? - Multi-Datacenter Replication : 就是你可以在所需要的任何地方都有一份一模一樣的 Riak Center. 但很可惜的, 這是要收費... 適合 : 需要大型檔案的處理. 不適合 : 沒有這方面的需求.
Riak 需要高規格設備
根據官方建議的設備為 : - Multi-core 64-bit CPU - Minimum 4 GB RAM - Multiple Fast Hard Disks (RAID and/or SSD) - Fast Network (Gigabit +) 而預設在 production 上建議是五個 node (riak). 也就是一開始我們就需要有五台這樣的 server. 這些設備對大公司可能是小錢, 對小型公司可能需要評估一下, 對 startup 可就是大錢了. 以另一篇 ( Digital Ocean 使用感受 )的計算, 如果要在 cloud 上開出至少可以運作的規格, 不做任何特殊調校, 一個月至少要花 10000 NTD..
需要 Multi-core 的原因 : Riak 本身程式撰寫良好 (?) 可以利用到 multiple-core 之外, erlang 本身就是一個語言能善用到 multiple-core. 所以如果有 multiple-core, 效能會增加許多. 需要 SSD 的原因 : Riak 本身是 IO Bound, 而且, 如果使用 eleveldb, 因為連 key 都需要搜尋 disk, 這需求就更高了. 需要 RAM 的原因 : 除了 Bitcask 本身是將所有的 key 儲存在 memory 之外. Map-Reduce 本身也需要很大量的 Memory. 可以透過官方提供的計算機來計算一下, 多少的資料量需要多少的 ram : Riak Memory Calculator 需要好網路的原因 : 應該就是因為 node 跟 node 之間的溝通太頻繁了, data sync, handoff, ring-state gossip... etc 適合 : 會調校來替代規格不足 或是 好規格的設備.. 不適合 : 環境不好的 server, 比如 cloud vps.
以上, 也許有遺漏, 再帶後續補上.
最後, 想說一下. 沒有必要拿他和其他 db 比較, 每個 db 的特長和用途不同. 如果會拿他和比如 redis 比較, 那就是對自己的需求不理解, 或是不了解特性. 覺得 美國 比較好, 就去當美國人, 覺得 大陸 好就去當大陸人. 就像我還是很喜歡 neo4j, 還是有用 redis, 按需求去走就好. 僅此. :)
