文書データベースとリレーショナルデータベースとグラフデータベースのどちらを使用すべきですか?[閉まっている]


29

議論のために、FourSquareのシナリオを考えてみましょう。

シナリオ

エンティティ:

  • ユーザー
  • 場所

関係:

  • チェックイン:ユーザー<->場所、多対多
  • 友人:ユーザー<->ユーザー、多対多

データベース設計

これらにはエラーが発生する可能性が高いため、指摘してください。

RDBMS

テーブル:

  • ユーザー
  • 場所
  • チェックイン(ジャンクション)
  • 友達(ジャンクション)

長所:

  • CAP:一貫性、可用性

短所:

  • CAP:パーティション許容値、別名シャーディング
  • スキーム=柔軟性のない構造
  • 貧弱な複製?

グラフ

オブジェクト:

  • ユーザー
  • 場所

エッジ:

  • 友達:ユーザー<->ユーザー
  • チェックイン:ユーザー->場所
    • タイムスタンプを含む

長所:

  • CAP:一貫性、可用性?
  • スキーマレスで簡単に変更可能なオブジェクトとエッジ
  • グラフトラバーサルクエリ、たとえば:
    • クラスタリング
      • 友達のグループを見つける
      • 似たような人が好きなレストランを見つける
    • 他の一般的な/有用なクエリはありますか?

短所:

  • CAP:パーティションの許容範囲?

ドキュメント/オブジェクト

3つの個別のデータベース?

  • ユーザー
    • 友達リスト
  • チェックイン
    • タイムスタンプ
    • ユーザー
    • 場所
  • 場所

長所:

  • CAP:可用性、パーティショントレランス
  • スキーマレスで簡単に変更可能なオブジェクト

短所:

  • CAP:一貫性

ご質問

記録のために、彼らは最終的にMongoDBを使用することになりました。上記のすべての疑問符に加えて:

  1. ドキュメントデータベースの実装方法がわかりません。
  2. ドキュメントデータベースはどのようにパーティションの許容値を取得しますか?
  3. 単一のユーザーのチェックインを取得するには、操作がすべてのチェックインを解析し、ユーザー名のメタデータをフィルタリングすることを想定しています(マップ+フィルター)。各ユーザーの1,000,000以上のドキュメントを解析するパフォーマンスはひどく劣っています。これは正しい動作ではないと思いますか?
  4. 他にどのような賛否両論がありますか?

(1)ビジネス用語の2つのテーブル間の関係を綴る必要があります。これは、並列関係がある可能性があるためです。たとえば、ユーザー<->ユーザーは1 mmの関係を意味しません。1以上を意味する場合があります。たとえば、あるユーザーは別のユーザーが好きで、そのユーザーは別のユーザーを嫌います。これらは2つの関係です。(2)「正確に」欲しいものを要約できれば助かります。
-NoChance

@EmmadKareem:(1)シナリオを複雑にするつもりはありません。私が興味を持っている唯一のユーザー<->ユーザー関係は相互の友情であり、これは多対多のつながりです。(2)投稿の下部にリストされている4つの質問に回答してほしい。
12

回答:


13

あなたの質問は、1学期の大学のコースのトピックかもしれません。管理しやすいチャンクに分割する必要があります。そのため、部分的な答えをいくつか捨てます。

使用するデータベースの種類を決定する際に最初に検討することの1つは、実行するクエリの種類と、データベースを作成する前にそれらをすべて知っているかどうかです。SQLデータベースには、データベース内のすべてのデータにわたる強力で柔軟なクエリという利点があります。グラフデータベースには、グラフデータに最適で、非グラフデータには非常に悪い特殊なクエリ機能があります(ただし、グラフデータベースはSQLデータベースのコンポーネントになる場合があります)。NoSQLデータベースは、データを取得して操作する能力がはるかに制限されています。

次は、ACIDプロパティについてどのように感じているかです:原子性、一貫性、分離、および耐久性。SQLデータベースは、すべて4について強力な保証を提供します。通常、NoSQLデータベースは4をすべて約束するわけではありません。それらの出発方法は、さまざまなNoSQLデータベースの実装を区別する重要な違いです。一方、パーティションに直面して一貫性と可用性を保証することは不可能なので(BrewerのCAP thoremを参照)、パーティションに直面して完全な可用性を主張する場合、SQLデータベースは何もしません。個人的には、データベース内のデータの耐久性に非常に関心があります。通常、0.0001%のデータ損失でも受け入れられず、パーティションを心配する必要がないほどデータセットが小さいデータを扱うため、 SQLデータベースが非常に有利です。

もう1つの非常に実用的な考慮事項は、サーバーコードの品質、データベース管理者とプログラマーの可用性、発生する問題に利用できるサポートの品質、アプリケーションをデータベースに接続するためのインターフェイスライブラリの品質と可用性などです。MySQLはほぼ20年前から存在しており、バグの大部分が解決され、非常に広く使用されているため、優れたサポートと人材の可用性があり、今後10年間サポートされる可能性があります。Riakについてのそれらのことを言うことはできません。

Googleは実質的にNoSQLデータベースを発明して、World Wide Webのキャッシュおよびインデックスバージョンを保存できるようにしましたが、いまだにMySQLを使用していることに注意してください。


1
私は多くのことを尋ねていたので、一般的な答えは大丈夫だったでしょう。核となる質問は次のとおりです。(1)範囲シャーディングを使用してロジックに水平シャーディングを実装できるのに、想定される優れたシャーディングにドキュメントデータベースを使用する理由 (2)FourSquareシナリオで使用するドキュメントデータベースをどのように設計し、いくつかの一般的な使用(ユーザーのチェックインを表示、ユーザーの友人を表示、現在チェックインしている場所のユーザーを表示)をどのように処理しますか?
重み付け

1
@William、あなたの質問に答える記事はGoogleから簡単にアクセスできます。スタックオーバーフローだけでもいくつか。宿題をしてください。
オールドプロ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.