Bret Taylor (FriendFeed の共同作成者、現在 Facebook の CTO) によって書かれた衝撃的な記事、 How FriendFeed uses MySQL to store schema-less data を読んだ後、私は、Oracle などの RDBMS を使用するためのベスト プラクティスがあるかどうか疑問に思い始めました。スキーマレス データの保存とクエリには MySQL と PostgreSQL のどちらを使用しますか?
NoSQL が話題になっているときにリレーショナル データベースを使用していることを認める人はほとんどいないため、このトピックに関する優れた記事を見つけるのは困難です。スキーマレス (または「ドキュメント指向」) データベースをリレーショナル データベース上のレイヤーとして実装するにはどうすればよいですか?
これは、このトピックの古典的な記事です: http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html商品サーバー)
Storing schemaless data in SQL basically means implementing a key-value store that happens to use SQL as a back end. Since you aren't using any relational features and the schema is fairly trivial you won't find a lot of information on designing SQL databases this way. However, you should be able to find plenty of more general information on designing applications for key-value storage that will apply.
私はこの問題を広範囲に調査しました。「プロパティ」テーブル (基本的にはキーと値のペアを使用) を使用して、RDBMS でスキーマレス データをモデル化するのはかなり簡単です。難しいのは、自分のものに対するインデックス作成とクエリです。(基本的に、Friendfeed が対処したすべての複雑さは、この問題に集中していました。)
プロパティ テーブルにインデックスを付けると、すべてのプロパティに対するインデックスが作成されます。特定のプロパティに対してのみクエリを実行する必要があるため、オーバーヘッドが大きくなりすぎるため、これは望ましくありません。また、複合インデックスを介して自分のものにアクセスしたいと思うでしょう。複合インデックスをモデル化するのは非常に複雑です。私が見つけた唯一の解決策では、その目的のためだけにスキーマを使用して独自のインデックスを作成する必要があり、非常に面倒です。見れば見るほど実用性がなくなってきました。
この問題の適切な解決策は、部分インデックス (別名、フィルター処理されたインデックス) の使用に依存しています。
ほとんどの人は単一目的のソリューションを構築するため、このトピックについてはあまり見つかりません。彼らのソリューションは、1 つのニーズを非常によく満たすように設計されています。NoSQL データベースは、これらの単一目的のデータ ストアを構築する手間を大幅に軽減しますが、RDBMS の柔軟性や組み込みの制御機能、安全機能の一部を利用できないという代償を払います。
Quora のエンジニアは、Cassandra、MongoDB、CouchDB などの NoSQL ではなく、MySQL をデータ ストアとして使用しています。アプリケーション レベルでデータを分割します。つまり、必要な場合にのみデータを分割し、可能であれば 1 台のマシンにデータを保持し、主キーのハッシュを使用して複数のデータベース間でより大きなデータセットを分割します。データのアプリケーション レベルのパーティショニングは、ある一連の基準を満たすデータが 1 つのデータベースに「引き渡され」、それらの基準 (または別の一連の基準) を満たさないデータが別のデータベースに送信されるように機能します。