FriendFeedの創業者であり開発者であるBret Taylor氏によるブログ記事の翻訳です。FriendFeedはTwitterやYouTube、Flickrなどの各種Webサービスの更新を集約するサービスです。記事ではFriendFeedで使われているMy-SQLの独特なスキーマ設計について、DDL（Data Definition Language）を示しながら解説しています。

FriendFeedは2億5千万ものエントリやコメントなど、多くのデータを保持しています。スキーマを変更するとインデックスの更新が必要になり、データ量が巨大であるがゆえに、性能や稼働性を確保しながらスキーマの変更を行うことがかなりの運用負荷になっていたようです。でも、CouchDBなどのスキーマレスなDBは信頼性が十分ではありません。いろいろな方法を考えた結果、My-SQLを使ってスキーマレスなストレージシステムを構築する方法にたどりついたようです。

エントリなどを格納するテーブルは次のような形になっています。

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;

上記のBLOB型であるbodyに実際のデータが入ります。データはPythonのディクショナリをpickle化（整列化）し、zlibで圧縮した形式で格納します。

そしてインデックスを作りたい場合には専用のテーブルを作成します。たとえばユーザ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で書かれた専用ライブラリ（記事ではfriendfeed.datastoreと記載）で行います。JOIN操作もMy-SQLでは行わずPython上にて扱います。

データとインデックスを別々に管理しているため一貫性に問題があることを認めていますが、ある程度の妥協を許すことでおおむねうまく運用できているようです。また、性能に関しても適用前後のグラフを比較して、とても安定していることを示しています。

元記事には、絶賛している人や批判している人、mixiの平林幹雄氏が開発しているkey-valueストア「Tokyo Cabinet」（⁠編注）を提案している人、Pythonライブラリの公開を望んでいる人など、数多くのコメントが書き込まれています。

編注）

key-valueストアについて詳しくは特集3「⁠［⁠旬のライブラリ大集合］key-valueストア入門」（⁠WEB+DB Vol.50　95ページ）をご覧ください。

URL：http://hyuki.com/yukiwiki/wiki.cgi?HowFriendFeedUsesMySqlToStore
SchemaLessData