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，但是用來做重點資料分析，這樣已經綽綽有餘了。

使用 AWS DynamoDB 筆記

使用 AWS DynamoDB 主要有幾個原因

1. 需要 Key-Value Datastore
2. 需要 stability, scalability (heavy write)
3. 不想要自己管理Cluster/Sharding、OS tuning、failover、Disaster Recovery等

稍微比較了幾個資料庫，其中 Redis 的設計其實更適合我們，因為我們有部分資料需要 expire  還有 increment，但是單一 Redis instance 很快就會不夠我們用，而 Redis 官方說 Redis Cluster 目前還是 alpha quality ，不太適合我們目前這個以穩定性為第一要務的 project ，我試著參考 DynamoDB、Riak 架構設計做 Redis Sharding Cluster ，但是信心不夠拿來放 persistent data，主要是在 Redis nodes 數量變動的時候，很難確保資料的一致性，所以最後還是決定先使用比較穩定的 DynamoDB，等到 Redis 有依區塊的移動（migrate）資料的功能後，或是AWS支援Redis Cluster 我們就可以考慮離開DynamoDB。

DynamoDB 測試起來有幾個地方比較不習慣

1. 像是一個Table要建很久，下建立Table指令之後大概要等個幾十秒後才能使用這個Table，所以最好預先建立Table，但是動態建立Table卻又很好用，因為可以一次丟掉整個Table，刪除個別資料又慢又貴。
2. 要自己觀察Database大概需要的讀寫量，並且告訴Amazon可能會用到多少，最好能夠自己動態調整DynamoDB的 read/write unit，因為DynamoDB是按使用者宣告的讀寫次數收費，使用量超過宣告時則會出現error，這有點麻煩。
3. 沒有 expire 功能，大概一般Database也很少有這個功能吧，利用不同建立不同時間區分的Table的方式可以達到類似 expire 的概念，作法可以參考http://stackoverflow.com/questions/9343909/how-do-i-expire-keys-in-dynamodb-with-boto/21323698#21323698
4. Rang Key 不是拿來做 Range Query 的，跟我看到這個名稱的第一聯想相左。Range key 是 default sorting attribute，Rang Key也是完整Key的一部分，所以如果將來想依特定時間區間搜尋的話要用別的方法，在儲存的時候就要先處理。

在Linux 安裝 redis 建立 daemon

Ubuntu 12.04

參考http://redis.io/topics/quickstart

下載安裝redis stable
wget http://download.redis.io/redis-stable.tar.gz tar xvzf redis-stable.tar.gz cd redis-stable sudo make 把src資料夾內 redis-server 和 redis-cli 加到路徑
cd src sudo cp redis-server /usr/local/bin/ sudo cp redis-cli /usr/local/bin/ 測試redis server
redis-server >exit 設定redis成為daemon，以port 6379為例
mkdir /etc/redis sudo mkdir /etc/redis sudo mkdir /var/redis sudo cp redis-stable/utils/redis_init_script /etc/init.d/redis_6379 sudo vi /etc/init.d/redis_6379 設定REDISPORT為6379
sudo cp redis-stable/redis.conf /etc/redis/6379.conf sudo mkdir /var/redis/6379 sudo vi /etc/redis/6379.conf 設定config檔的參數
daemonize yes
pidfile /var/run/redis_6379.pid
port 6379
logfile /var/log/redis_6379.log
dir /var/redis/6379
把redis init script加到開機自動執行
sudo update-rc.d redis_6379 defaults
啓動redis service
sudo /etc/init.d/redis_6379 start redis-cli ping >PONG