在使用Redis過程中，我們發現了不少Redis不同於Memcached，也不同於MySQL的特徵。
(本文主要討論Redis未啟用VM支援情況)

1. Schema

MySQL: 需事先設計
Memcached: 無需設計
Redis: 小型系統可以不用，但是如果要合理的規劃及使用Redis，需要事先進行類似如下一些規劃

• 資料項: value儲存的內容是什麼，如使用者資料
• Redis資料型別: 如String, List
• 資料大小: 如100位元組
• 記錄數: 如100萬條(決定是否需要拆分)
• ⋯⋯

上面的規劃就是一種schema，為什麼Redis在大型專案需要事先設計schema？因為Redis伺服器有容量限制，資料容量不能超出實體記憶體大小，同時考慮到業務資料的可擴充性，記錄數會持續增多、單條記錄的內容也都會增長，因此需要提前規劃好容量，資料架構師就是通過schema來判斷當前業務的Redis是否需要“分庫分表”以滿足可擴充套件需求。

2. 容量及頻寬規劃

容量規劃
MySQL: < 硬碟大小
Memcached: < RAM
Redis: < RAM

頻寬規劃
由於Redis比MySQL快10倍以上，因此頻寬也是需要事先規劃，避免頻寬跑滿而出現瓶頸。

3. 效能規劃(QPS)

當系統讀寫出現瓶頸，通常如何解決？
MySQL
寫: 拆分到多伺服器
讀: (1) 拆分 (2) 寫少也可以通過增加Slave來解決

Memcached
讀寫: 都通過hash拆分到更多節點。

Redis:
寫：拆分
讀: (1) 拆分 (2) 寫少也可以通過增加Slave來解決

4. 可擴充套件性

MySQL: 分庫分表
Memcached: hash分佈
Redis：也可以分庫，也可以hash分佈

小結

通過以上分析，Redis在很多方面同時具備MySQL及Memcached使用特徵，在某些方面則更像MySQL。
由於Redis資料不能超過記憶體大小，一方面需要進行事先容量規劃，保證容量足夠；另外一方面設計上需要防止資料規模無限制增加，進而導致Redis不可擴充套件。
Redis需要象MySQL一樣預先設計好拆分方案。

小問題

在MySQL中，通過預先建立多表或者庫可以在業務增長時候將這些表或庫一分為二部署到更多伺服器上。
在Redis中，“分庫分表”應當如何實現？有什麼好的設計模式？