instagram的開發者首先否定了資料庫儲存的方案，他們保持了kiss原則（keep it ****** and stupid），因為這個應用根本用不到資料庫的update功能，事務功能和關聯查詢等等牛x功能，所以不必為這些用不到的功能去選擇維護乙個資料庫。
於是他們選擇了redis，redis是乙個支援持久化的記憶體資料庫，所有的資料都被儲存在記憶體中（忘掉vm吧），而最簡單的實現就是使用redis的string結構來做乙個key-value儲存就行了。像這樣：
set media:1155315 939其中1155315是id，939是使用者id，我們將每一張id為作key，使用者uid作為value來存成key-value對。然後他們進行了測試，將資料按上面的方法儲存，1,000,000資料會用掉70mb記憶體，300,000,000張**就會用掉21gb的記憶體。對比預算的17gb還是超支了。get media:1155315
> 939
redis容量評估模型根據key型別而有所不同。
1、string
乙個簡單的set命令最終會產生4個消耗記憶體的結構，中間free掉的不考慮：
（nosqlfan：其實這裡我們可以看到乙個優化點，我們可以將key值前面相同的media去掉，只存數字，這樣key的長度就減少了，減少key值對記憶體的開銷【注：redis的key值不會做字串到數字的轉換，所以這裡節省的，僅僅是media:這6個位元組的開銷】。經過實驗，記憶體占用會降到50mb，總的記憶體占用是15gb，是滿足需求的，但是instagram後面的改進任然有必要）
於是instagram的開發者向redis的開發者之一pieter noordhuis詢問優化方案，得到的回覆是使用hash結構。具體的做法就是將資料分段，每一段使用乙個hash結構儲存，由於hash結構會在單個hash元素在不足一定數量時進行壓縮儲存，所以可以大量節約記憶體。這一點在上面的string結構裡是不存在的。而這個一定數量是由配置檔案中的hash-zipmap-max-entries引數來控制的。經過開發者們的實驗，將hash-zipmap-max-entries設定為1000時，效能比較好，超過1000後hset命令就會導致cpu消耗變得非常大。
於是他們改變了方案，將資料存成如下結構：
hset "mediabucket:1155" "1155315" "939"通過取7位的id的前四位為hash結構的key值，保證了每個hash內部只包含3位的key，也就是1000個。hget "mediabucket:1155" "1155315"
> "939"
再做一次實驗，結果是每1,000,000個key只消耗了16mb的記憶體。總記憶體使用也降到了5gb，滿足了應用需求。
（nosqlfan：同樣的，這裡我們還是可以再進行優化，首先是將hash結構的key值變成純數字，這樣key長度減少了12個位元組，其次是將hash結構中的subkey值變成三位數，這又減少了4個位元組的開銷，如下所示。經過實驗，記憶體佔用量會降到10mb，總記憶體占用為3gb）
hset "1155" "315" "939"優化無止境，只要肯琢磨。希望你在使用儲存產品時也能如此愛惜記憶體hget "1155" "315"
> "939"
如何在程式設計中節約系統記憶體
程式語言為現代的計算和自動化作出了重要貢獻！能運用程式語言解決現實中的問題，你會發現，其實很多事情真的很方便！前段時間一直跟他們測量的講解cass這個軟體，我並沒有學過這個軟體，但是從它的安裝和使用，我發現其實就是基於cad的乙個二次開發！如果有足夠的條件，我們也可以開發出類似於cass這樣的軟體，...
節約記憶體是一種罪惡 ZT
節約記憶體是一種罪惡?回福州幾天了，有好多東西想寫，可是由於一些個人問題而中斷了，那怎麼辦呢？今天來個重量級別高一點的內容吧。這可是我花了一兩年時間才明白的東西哪。是的，一兩年。似乎從我的第一位程式語言老師開始，任何人都這麼告訴我 寫出來的程式，要跑得又快佔的記憶體又少 不是嗎？第一位程式老師？噢，...
如何在程式設計中節約系統記憶體
程式語言為現代的計算和自動化作出了重要貢獻！能運用程式語言解決現實中的問題，你會發現，其實很多事情真的很方便！前段時間一直跟他們測量的講解cass這個軟體，我並沒有學過這個軟體，但是從它的安裝和使用，我發現其實就是基於cad的乙個二次開發！如果有足夠的條件，我們也可以開發出類似於cass這樣的軟體，...