Realtime Scalable Data Analysis with Redis

Redis 一般用來做記憶體層的 key-value cache store，一般 data analysis 也不會使用 Redis 當儲存，因為 Redis 跑在單一主機上的情況記憶體容量有限，不方便橫向擴展，Redis cluster 有希望解決橫向擴展的問題，但是目前還在 Beta 階段，不適合放到我們目前這個穩定性優先的project 裡面。

選擇使用 Redis 的主要原因是，Redis 速度非常快，可以做非巨量資料的 realtime 分析，資料結構比 memcached 彈性，我們的專案不需要分析超過一個禮拜以上的資料，只是做重點分析，做沒有特定目的的儲存和分析我們使用其他的資料庫來做，還有我們的專案索需要儲存的資料結構 Redis 都有支援，資料可以自然揮發（expire），另外最最最重要的是 AWS ElastiCache 有直接支援，省掉了 server 架構的時間和維護成本。這樣最後只剩下一個問題，就是橫向擴展問題。

Consistent Hashing

Consistent Hashing 可以用來解決 key-value datastore 擴展的時候資料搬遷最小化的問題，避免因為使用傳統的 hash 方式造成伺服器擴展的時候，短時間極大量的資料都要往資料的源頭（底層）訪問造成系統失靈。Consistent Hashing 同時也是 DynamoDB 和 Riak 等資料庫重要的核心概念。

我們也可以用 Consistent Hash Ring 來做記憶體陣列來增加橫向擴展的能力，同時兼具擴展時資料最小搬遷的優點，但是有一個問題，使用 Consistent Hash 的資料必須是 key - value 對應，一定要有 key 才能做 hash 對吧，但是 Redis 中許多指令是不對應 key 的，比如說 keys 列出所有的 key ，必須要自己做  broadcast ，還有許多指令根本會失效的，像是 sort ，這種對全部資料演算的都不能用，所以部分索引資料還是要存在特定的 server 上，這樣又有一個問題，就是SPOF(single point of failure) ，對於這樣的情況，我們目前的解法仍然是廣播指令到一定數量的 server 上，也就是應用層的 replication server ，這些 replication server 其實也同樣位於  Consistent Hash Ring 中，這樣會產生另外一個問題，就是資料在 replication servers 中有可能不一致，我們目前的解決方式是 fail-retry-verify 的方式來使資料最終會一致，也因為有可能發生時間差的問題，所以我們仍然無法直接使用這個方法來把 Redis 建構成我們主要的 database，但是用來做重點資料分析，這樣已經綽綽有餘了。