DynamoDB，amazondynamodb

DynamoDB，amazondynamodb

        本來想寫寫進程、線程、輕量級線程、goroutine還有協程（coroutine），為什麼我把goroutine單獨列出來是因為它不是協程，所有翻譯成協程的都是偷用概念，把比線程輕量的都叫做協程。算了，先不糾結這個，今天想寫寫DynamoDB，記錄下經曆。

        就如官網描述到的，無限擴充，好吧，具體實現也不得而知，但這個無限擴充的前提是諸多限制。在確認DynamoDB是否適口你的項目使用的時候，記得多分析它的限制，否則遲早會成為項目的瓶頸，或者減緩業務的開發。

        首先，DynamoDB統計不友好，想統計它的東西？最好還是放棄這個念頭，掃描一遍的代價大得不可思議。在用DynamoDB之前，先弄好你的日誌系統。
        其次，它不是緩衝，雖然是說SSD搞的，但是連這個東西（HTTPS）的代價不是普通緩衝所會做的，就它內部查詢效能來看，也是幾十上百毫秒層級的。
        再次，不要以為這個東西很容易用，各種SDK各種坑，拿python boto為例子，兩個版本的實現，各自殘缺，有些功能SDK根本提供不了，你要做好寫RESTful requests的準備。
        最後，你要是會看英文且真的想用DynamoDB就別繼續往下看了，直接看官網文檔各種詳盡和指引，以下只是個人心得和坑的摘錄。

        第一個坑是資料類型，嗯，不完全符合JSON，也就是說，這個要做點格式轉換，前不久才出了List和Map的支援，叫文件類型，官方建議可以把JSON壓縮成Binary，這...。一條項目（就是一條record，叫item）最大儲存容量為400KB（只是英文文檔這樣寫，中文文檔還沒更新，依然寫著64K，這有點小，除此以外，中文文檔殘缺不全，不值一嗔），這個還可以。讀/寫流量限制預設（Provisioned Throughput）是一個最大的坑，以流量限定讀寫速率和容量。單個讀單位可在1秒內讀1次且4KB以內的內容，40KB就要10個讀單位，同樣地，單個寫單位每秒可寫入1次且1KB以內內容。
        第二個坑來了，就是這個讀/寫流量限制預設，全域二級索引是和主表分開預設流量計算。最坑在於，倘若你想寫入主表，主表的預設流量是夠的而全域二級索引預設流量不夠，這樣就會插不進，報錯，這樣使得全域二級索引和建立一張表無異，建立一張表還更靈活。預設流量的另一個坑是，你的hashkey（整個資料庫以hashkey作為主鍵，不知道的請到官網中文版補習）必須hash得均勻才能得到預設流量的最大效用。比如說，你預設了1000個讀（預設讀容量超過10000還需要遞表申請），amazon幫你自動分在20個區存放，那麼你每個區只會獲得50個讀的流量，假如你現在急著要讀某一類別的資料，並且這一類別的不小心集中在某一地區，不好意思，你的消費將乘以個幾倍幾十倍（amazon的服務本身就貴）。如果你要強一致性讀（預設是不強一致性讀的，不懂的自己腦補），那麼將會消耗兩倍於髒讀的讀單位。
        第三大坑是索引，上面說到的全域索引是一個坑，還有一種叫二級本地索引也是一個坑，它居然有一條單個hashkey索引內容不超過10G的規定，這個索引內容投影屬性*（這個概念請看官網）。這就是說，當你索引加投影單個item有200個位元組（200個位元組真心不多吧，一個uuid隨便都32byte了，當然，你可以選擇壓縮...），200位元組的情況下，該hashkey最多可以包含的條目是5000萬條，這個規定直接給人限死了，你不能拿單個hashkey來玩，更別做太多投影。此外，索引是不能添加修改刪除的，只能跟隨表建立時添加。雖然有10G這個限定，但我覺得它的RangeKey和本地二級索引還是比較獨特的，可以解決很大一部分的需求。前提是，最深的索引就是二級，你要做三級四級的索引就要想一下辦法了，這個想一下辦法也可以再解決一大部分的需求吧。
        第四，別考慮太多事務啊原子操作之類，它做不了，簡單的自增還是可以的。
        最後就是SDK，如果你只是簡單的使用，python的SDK boto沒什麼大問題，但你考慮到並發衝突，部分屬性修改兼上是否覆蓋寫入等等的問題的時候，boto壓根就不能解決，這就需要又花費一大塊精力去手工Restful了，當然，如果你想用上tonado，沒有現成的非同步模組可用。

        如果你已經跳過上述的坑，相信離DynamoDB符合你的項目需求已經不遠了，當然，效能方面我還沒做過多測試，準備上線億級以上條目的項目了，詳情敬請期待。