FriendFeed如何用MySQL儲存K-V資料

標籤：blog   http   io   os   ar   使用   for   sp   資料   

@這是一篇比較老的文章，我現在的理解是使用MySQL實現了一個MongoDB，在思路上有借鑒意義。

原文地址: http://backchannel.org/blog/friendfeed-schemaless-mysql

背景

我們使用MySQL儲存FriendFeed所有的資料。我們的資料庫隨著我們的使用者基數增長而增長了許多，現在儲存了超過2億5千萬（250 million）條目和資料串，這些資料來自評論和朋友列表的“喜歡”。

伴隨著資料的增長，我們反覆處理因為資料過快增長而帶來的擴充問題。我們曾經使用了常規方法，比如使用從屬讀伺服器和memcache，增加讀取能力；使用資料庫分區來提高寫入的能力。然而，隨著我們的發展，發現增加新功能比擴充現有系統容量更困難。

尤其在這些情況下：設計模式改變；給一個超過一兩千萬行的資料庫增加索引，資料庫一次完全鎖死幾小時。刪除舊索引也會佔用同樣的時間，並且不刪除他們會損害效能。因為資料庫會在每次INSERT插入操作時，繼續讀寫這些不使用的塊，並把重要的塊擠出記憶體。存在避開這些問題的非常複雜的設計，比如在從伺服器上產生索引，然後對調主從伺服器。但是這些方法容易出錯，太過重量級，並且暗中阻止我們添加需要改變索引或設計模式的新功能。自從我們的資料庫深度分區開始，與MySQL相關的功能，比如JOIN對於我們毫無價值。所以，我們決定在關係型資料庫之外尋找答案。

為了使用靈活模式和快速索引特性儲存資料，誕生了許多項目，比如說CouchDB。然而，似乎他們中沒有一個擁有足夠的信任被大型網站廣泛使用。在測試中，我們運行表明，對於我們的需求，他們中沒有一款足夠穩定或經受考驗。MySQL可以滿足需求，並且從來不會損壞資料，或重複工作。我們已經認識到了它的局限性。我們喜歡MySQL用來儲存，而不是關係型資料庫的使用模式。

在一些考慮之後，我們決定在MySQL之上，實現一套“無模式”的儲存系統，而不是完整的使用其他新型儲存系統。這篇文字試圖在高層次上描述系統的細節。我們很好奇其他大型網站是如何解決這個問題的，並且我們認為一些我們做的設計工作可能會對其他開發人員有所協助。

概述

我們的資料庫儲存無模式的屬性包（比如JSON或Python中的字典）。儲存實體唯一需要的屬性是id，一個16位元組的UUID（通用唯一識別碼）。實體的其他屬性在資料庫連接之前是不透明的。我們可以簡單地通過儲存新屬性來改變模式。

我們通過在單獨的MySQL表中儲存索引，來索引這些實體的資料。如果我們想在每個實體中索引3個屬性，我們將會有3個MySQL表（每一個對應一個索引）。如果我們想要停止使用一個索引，先從代碼停止向這張表寫入，然後根據需要在MySQL中刪除這張表。如果我們想使用一個新索引，先在MySQL中為這個索引建立新表，然後運行一個程式非同步填入索引，這樣不會干擾我們的正常服務。

因此，相對之前我們後來會有更多的表，但是添加和刪除索引非常容易。我們擁有深度最佳化過的程式用來填充新索引（被我們叫做”Cleaner”），因此可以在不干擾網站正常服務的情況下迅速索引頁預留空間。我們可以在一天的時間記憶體儲新屬性並建立索引，而不是一個周的時間。並且，我們不需要再交換MySQL主從伺服器，或做其他提心弔膽的操作工作讓其實現。

詳情

在MySQL中，我們的實體像這樣被儲存在表中:

CREATE TABLE entities (    added_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,    id BINARY(16) NOT NULL,    updated TIMESTAMP NOT NULL,    body MEDIUMBLOB,    UNIQUE KEY (id),    KEY (updated)) ENGINE=InnoDB;

added_id列存在，因為InnoDB儲存資料行完全按照主鍵順序。自增主鍵確保新實體在舊實體之後連續地被寫入磁碟，同時協助讀寫操作確定位置（因為FriendFeed頁面按照年代反轉排序，所以新實體相對於舊實體，傾向於擁有更頻繁的讀取）。實體內容被使用zlib演算法壓縮儲存，pickle化的python字典。

索引儲存在分開的單獨表裡。為了建立一個新索引，要建立一個表，儲存我們想要索引的屬性，以便在所有資料庫群中尋找。例如，一個標準FriendFeed實體像這樣:

{    "id": "71f0c4d2291844cca2df6f486e96e37c",    "user_id": "f48b0440ca0c4f66991c4d5f6a078eaf",    "feed_id": "f48b0440ca0c4f66991c4d5f6a078eaf",    "title": "We just launched a new backend system for FriendFeed!",    "link": "http://friendfeed.com/e/71f0c4d2-2918-44cc-a2df-6f486e96e37c",    "published": 1235697046,    "updated": 1235697046,}

我們想索引實體屬性中的user_id，以便可以渲染給定使用者請求的一個頁面內所有實體。索引表像這樣:

CREATE TABLE index_user_id (    user_id BINARY(16) NOT NULL,    entity_id BINARY(16) NOT NULL UNIQUE,    PRIMARY KEY (user_id, entity_id)) ENGINE=InnoDB;

我們資料存放區代替你自動維護索引，因此開啟一個資料存放區的執行個體 ，儲存給定索引上文結構的實體應該這樣寫（python）:

user_id_index = friendfeed.datastore.Index(    table="index_user_id", properties=["user_id"], shard_on="user_id")datastore = friendfeed.datastore.DataStore(    mysql_shards=["127.0.0.1:3306", "127.0.0.1:3307"],    indexes=[user_id_index])new_entity = {    "id": binascii.a2b_hex("71f0c4d2291844cca2df6f486e96e37c"),    "user_id": binascii.a2b_hex("f48b0440ca0c4f66991c4d5f6a078eaf"),    "feed_id": binascii.a2b_hex("f48b0440ca0c4f66991c4d5f6a078eaf"),    "title": u"We just launched a new backend system for FriendFeed!",    "link": u"http://friendfeed.com/e/71f0c4d2-2918-44cc-a2df-6f486e96e37c",    "published": 1235697046,    "updated": 1235697046,} datastore.put(new_entity) entity = datastore.get(binascii.a2b_hex("71f0c4d2291844cca2df6f486e96e37c")) entity = user_id_index.get_all(datastore, user_id=binascii.a2b_hex("f48b0440ca0c4f66991c4d5f6a078eaf"))

上文的索引類在素有實體中尋找user_id屬性，並自動在index_user_id表中維護索引。自從我們的資料庫分區以後，shard_on屬性就被用來確認，索引被儲存在哪一個資料庫片上（在這個案例中，值為實體的ueser_id對分區數量取餘）。

你可以使用索引執行個體查詢一個索引（請參考上文user_id_index.get_all）。資料存放區系統代碼會在python中完成index_user_id表和實體表之間的“join”工作，通過先在所有資料庫片中查詢index_user_id表，拿到實體ID的列表，然後再實體表中讀取這些ID。

為了添加一個新索引，例如，在link屬性上建立所有，我們應該建立一個新表:

CREATE TABLE index_link (    link VARCHAR(735) NOT NULL,    entity_id BINARY(16) NOT NULL UNIQUE,    PRIMARY KEY (link, entity_id)) ENGINE=InnoDB DEFAULT CHARSET=utf8;

我們將會改變儲存系統的初始代碼來增加這個新索引:

user_id_index = friendfeed.datastore.Index(table="index_user_id", properties=["user_id"], shard_on="user_id")link_index = friendfeed.datastore.Index(table="index_link", properties=["link"], shard_on="link")datastore = friendfeed.datastore.DataStore(    mysql_shards=["127.0.0.1:3306", "127.0.0.1:3307"],    indexes=[user_id_index, link_index])

並且我們可以非同步填充這個索引（即使在服務繁忙的時候），使用:

./rundatastorecleaner.py --index=index_link

一致性與原子性

自從我們的資料庫開始分區，對比實體資料本身，一個實體的索引會被儲存到不同資料庫片上，一致性是一個問題。假設程式在寫完所有索引表前崩潰將會怎樣呢？

建立一個事務協議對於大部分有抱負的FriendFeed工程師是一個誘人的方案，但是我們希望保持系統儘可能的簡單。我們決定這樣放開約束：

• 屬性包儲存在主實體表中作為標準規範

• 索引可能不會反映實體的真實值

因此，我們用以下步驟向資料庫寫入了新的實體：

1. 使用InnoDB的ACID屬性，向實體表寫入實體

2. 向所有資料庫片上的所有索引表，寫入索引

當從索引表讀取時，我們知道結果不是非常精確的（也就是，如果寫入時沒有完成步驟2，索引可能反映舊的屬性值）。為了保證基於以上約束，我們不會返回無效的實體，我們使用索引表來確認要讀取哪一個實體，但是我們會在實體中重複提交過濾查詢，而不是相信索引的完整性：

1. 基於查詢在所有索引表中讀取entity_id

2. 根據給定的實體ID在實體表中讀取實體

3. 過濾（in python）所有不與實際屬性值匹配的實體

為了確保索引不失去持久性，不一致最後會被修複，我上文提到過的“Cleaner”程式，在表間不斷運行，寫入丟失索引並清除舊的、無效的索引。它會先處理最新動向的實體，所以在實際中索引中的不一致會被非常快的修複（在幾秒之內）。

效能

我們在新系統中已經對主要索引進行了非常多的最佳化，並且對最佳化結果非常滿意。下面是上個月FriendFeed頁面延遲的圖表（我們在幾天前啟動了新後台，你可以看到戲劇性的下降）：

尤其是，我們系統的延遲現在非常穩定，即使在高峰的正午時間。下面是過去24小時FriendFeed頁面延遲的圖表：

對比一周前的資料：

到目前為止，系統真的容易完成了工作。自從我們發展了系統，已經改變了索引好多次，並且我們開始使用新模式轉換最大的的MySQL表，以便於我們可以隨著發展更自由的改變資料結構。

FriendFeed如何用MySQL儲存K-V資料