議論のために、FourSquareのシナリオを考えてみましょう。
シナリオ
エンティティ:
- ユーザー
- 場所
関係:
- チェックイン:ユーザー<->場所、多対多
- 友人:ユーザー<->ユーザー、多対多
データベース設計
これらにはエラーが発生する可能性が高いため、指摘してください。
RDBMS
テーブル:
- ユーザー
- 場所
- チェックイン(ジャンクション)
- 友達(ジャンクション)
長所:
- CAP:一貫性、可用性
短所:
- CAP:パーティション許容値、別名シャーディング
- スキーム=柔軟性のない構造
- 貧弱な複製?
グラフ
オブジェクト:
- ユーザー
- 場所
エッジ:
- 友達:ユーザー<->ユーザー
- チェックイン:ユーザー->場所
- タイムスタンプを含む
長所:
- CAP:一貫性、可用性?
- スキーマレスで簡単に変更可能なオブジェクトとエッジ
- グラフトラバーサルクエリ、たとえば:
- クラスタリング
- 友達のグループを見つける
- 似たような人が好きなレストランを見つける
- 他の一般的な/有用なクエリはありますか?
- クラスタリング
短所:
- CAP:パーティションの許容範囲?
ドキュメント/オブジェクト
3つの個別のデータベース?
- ユーザー
- 友達リスト
- チェックイン
- タイムスタンプ
- ユーザー
- 場所
- 場所
長所:
- CAP:可用性、パーティショントレランス
- スキーマレスで簡単に変更可能なオブジェクト
短所:
- CAP:一貫性
ご質問
記録のために、彼らは最終的にMongoDBを使用することになりました。上記のすべての疑問符に加えて:
- ドキュメントデータベースの実装方法がわかりません。
- ドキュメントデータベースはどのようにパーティションの許容値を取得しますか?
- 単一のユーザーのチェックインを取得するには、操作がすべてのチェックインを解析し、ユーザー名のメタデータをフィルタリングすることを想定しています(マップ+フィルター)。各ユーザーの1,000,000以上のドキュメントを解析するパフォーマンスはひどく劣っています。これは正しい動作ではないと思いますか?
- 他にどのような賛否両論がありますか?