bugger763 wrote:
這種卡片快是很快，但是要是卡片掛了的話，有什麼保護機制可以讓服務繼續運作？
就跑 RAID 啊，你的問題跟本不算問題，因為你用一般硬碟也會有同樣問題啊。
有些人說傳統硬碟壞了還有機會救回來，但誰會接受關站幾天等硬碟救援?
還是靠 RAID、Clustering、backup 比較實際。
還有說真的，五十多 GB 的資料，整個擺到記憶體裡都夠了，看你要用 Ramdisk 還是單純的 cache 都行，而且也不貴。
但如果希望繼續成長，網站架構也許可以做個翻修，將大部分使用介面端的運算透過 javascript 交給用戶端處理，伺服器端就可以將焦點放在關鍵的資料存取上面，應該可以有效提昇使用者體驗。
另外，如果是使用 MySQL ，也許可以把部份的資料存取改用 HandlerSocket 之類介面（或升級到 MySQL 5.6 ，直接提供類似機制），可以減少 SQL 語法的解析時間來降低延遲。資料庫架構的部份不確定是否已經實做了讀寫分離，如果已經走到這一步，理論上是只要加機器就可以提昇效能了。
長期來看，找個 NoSQL 技術混用或改用應該不賴，但轉換成本非常高
***
Finjon Kiang / 江明宗
就這間電腦工作室: http://olc.tw
facebook已經用了好幾年的技術，也open source了
http://zh-tw.facebook.com/note.php?note_id=388112370932
https://github.com/facebook/flashcache/
keny009 wrote:
奇怪，看了一整串討論...(恕刪)
Facebook数据库工具Flashcache初探
Flashcache配置
看起來就是用SSD做快取，和標題說的需求有一點點不同
內文搜尋
從 APP 打開
X