背景

我們使用MySQL存儲了FriendFeed的所有數據。數據庫隨著用戶基數的增長而增長了很多。現在已經存儲了超過2.5億條記錄與一堆涵蓋了從評論和“喜歡”到好友列表的其他數據。

隨著數據的增長，我們也曾迭代地解決了隨著如此迅猛的增長而帶來的擴展性問題。我們的嘗試很有代表性，例如使用只讀mysql從節點和memcache來增加讀取吞吐量，對數據庫進行分片來提高寫入吞吐量。然而，隨著業務的增長，添加新功能比擴展既有功能以迎合更多的流量變得更加困難。

特別的，對 schema 做改動或為超過 1000-2000 萬行記錄的數據庫添加索引會將數據庫鎖住幾個小時。刪除舊索引也要占用這么多時間，但不刪除它們會影響性能;因為數據庫要持續地在每個INSERT上讀寫這些沒用的區塊，并將重要的區塊擠出了內存。為避免這些問題需要采取一些復雜的措施（例如在從節點上設置新的索引，然后將從節點與主節點對調），但這些措施會引發錯誤并且實施起來比較困難，它們阻礙了需要改動 schema/索引才能實現的新功能。由于數據庫的嚴重分散，MySQL 的關系特性(如join）對我們沒用，所以我們決定脫離 RDBMS。

雖然已有許多用于解決靈活 schema 數據存儲和運行時構建索引的問題(例如 CouchDB)的項目。但在大站點中卻沒有足夠廣泛地用到來說服人們使用。在我們看到和運行的測試中，這些項目要么不穩定，要么缺乏足夠的測試(參見這個有點過時的關于 CouchDB 的文章)。MySQL 不錯，它不會損壞數據；復制也沒問題，我們已經了解了它的局限。我們喜歡將 MySQL 用于存儲，僅僅是非關系型的存儲。

幾經思量，我們決定在 MySQL 上采用一種無模式的存儲系統，而不是使用一個完全沒接觸過的存儲系統。本文試圖描述這個系統的高級細節。我們很好奇其他大型網站是如何處理這些問題的，另外也希望我們完成的某些設計會對其他開發者有所幫助。

綜述

我們在數據庫中存儲的是無模式的屬性集(例如JSON對象或python字典)。存儲的記錄只需一個名為id的16字節的UUID屬性。對數據庫而言實體的其他部分是不可見的。我們可以簡單地存入新屬性來改變schema(可以簡單理解為數據表中只有兩個字段：id,data;其中data存儲的是實體的屬性集)。

我們通過保存在不同表中的索引來檢索數據。如果想檢索每個實體中的三個屬性，我們就需要三個數據表-每個表用于檢索某一特定屬性。如果不想再用某一索引了，我們要在代碼中停止該索引對應表的寫操作，并可選地刪除那個表。如果想添加個新索引，只需要為該索引新建個MySQL表，并啟動一個進程異步地為該表添加索引數據(不影響運行中的服務)。