FriendFeed(リンク)のBret Taylor氏は、急成長するウェブサイトを対象とした「フレキシブルなスキーマでデータを保存し、オンザフライで新しいインデックスを作成する」という 課題に対する「スキーマレスソリューション(リンク)」について語っている。この課題自体は、基礎となるデータベース構造およびデータベースに保存されている何百万 もの既存レコードに常時新しい機能を追加したりこれらを更新したりする必要性、また、新旧両方の機能をサポートする必要性から生じている。FriendFeedのソリューションの目的は、異なる技術ベースに移行するのではなく、MySQLの上に「スキーマレスソリューション」を構築することであった。Taylor氏は基本的な課題について以下のように述べている。
特に、スキーマを変更したり1000～2000万列以上を持つデータベースにインデックスを付加したりすると、データベースは一度に何時間も完全にロック されてしまいます。古いインデックスの削除にも同様の時間がかかり、削除しないとなると、データベースはINSERTの度にこれら未使用のブロックに対す る読み書きを続行し、重要なブロックをメモリから追い出すため、パフォーマンスが低下します。これらの問題を回避するための複雑な操作手順（新しいイン デックスをスレーブ上に設定してから、スレーブとマスターを入れ替える方法など）は存在しますが、その手順は非常にエラーを起こしやすく処理速度を下げる ため、暗黙のうちに、スキーマやインデックスの変更を伴う機能を追加する気持ちは失せてしまうでしょう。私たちが使用するデータベースはすべて大幅に Shard（破片）化されているため、JOINなどのMySQLのリレーショナル機能は役に立ったためしがなく、このため、RDBMSの領域外に目を向け ることに決めたのです。
彼らはいくつかの可能なソリューションを見直した後、完全に異なる永続化ソリューションを選ぶ代わりに、MySQL上でカスタムの「スキーマレス」ソリューションを使用することに決めた。
そのソリューションは、プライマリデータとそのデータへのインデックスを切り離すことであった。「FriendFeedのデータストアは、プロパティのスキーマレスな入れ物を保存します。（中略）インデックスを独立したMySQLテーブルに保存することで、これらのエンティティ内でデータのインデックス作成を行います。」これは、ボリュームと効率のトレードオフをもたらすこととなった。
結果として、以前よりもテーブル数は増えますが、インデックスの追加や削除は簡単になります。サイトを中断せずに新しいインデックスを速やかに埋めること ができるよう、新しいインデックスを格納するプロセス（私たちの間で「Ｔhe Cleaner」と呼んでいるもの）を大幅に最適化しました。
データとインデックスを切り離すことで、一貫性と原子性の問題が浮かび上がった。彼らは厳密なトランザクションプロトコルの代わりに、データベーステーブ ルを標準とし、インデックスはリファレンスのみに使用し、フィルタを実際のデータベースの読み取りに再適用した。また、優先権を持つ更新済みのエンティ ティで常時インデックスを更新、修正できるよう、「The Cleaner」と呼ばれる、テーブルを最新状態に保つ自動化プロセスを強化した。一貫性が失われる可能性は残るが、それでもその矛盾は平均2秒未満に排 除された。
平均ページレイテンシを測定基準として、Taylor氏は以下の傾向を報告した。
- 全体 -- 上昇傾向ではあるが、大幅な減少
- 最後の24時間 -- ピーク時においても安定
- 前の週 -- 「著しい」低下
Taylor氏の投稿には多くのフィードバック(リンク)が寄せられた。そのうちの1つは「現代のRDBMSはスキーマの進化に関して言えばMySQLの制約を共有 しない」というものだが、これは当初の選択の裏側でコスト問題を無視している。他の読者は、また別のソリューションで回答した。
興味深いことに、誰もFriendFeedの ソリューションとISAM（Indexed Sequential Access Method：索引付き順次アクセス方式）という「昔ながらの」技術の間の類似性を指摘しなかった。ISAMも、データ変更時にインデックスの自動更新に よってデータとインデックスを切り離すという、同じ基本的アーキテクチャを使用するものであった。
原文はこちらです：http://www.infoq.com/news/2009/03/friendfeed-schemaless-mySQL