2

プロジェクトを最初から作成していないのは久しぶりで、ドキュメント指向データベース(および ODM) が非常に普及したため、やみくもにリレーショナル ルートに進む前に、それらについて検討する必要があります。

いずれかの選択につながる可能性のある動機/プロジェクトの基準をリストアップしようとする人はいますか?

4

1 に答える 1

11

ORM / リレーショナル データベース / SQL

長所：

  • よく理解された標準的なアプローチ
  • 一貫した構造を持つデータに適切にマッピング
  • 複数のエンティティ間の複数の関係を持つデータに適切にマッピング
  • 広範な結合機能を備えています
  • 取引あり
  • 毎秒膨大な数のトランザクションに拡張可能 (MySQL Cluster、Fusion-IO などを使用)

短所：

  • パフォーマンスも懸念される場合、膨大な量のデータに拡張するのは難しい
  • 可変構造 (または半構造化) のデータにうまくマッピングされない
  • オブジェクトの永続化には、パフォーマンスのボトルネックになる可能性のあるグルー/変換レイヤーが必要です (また、間違って実行すると非常に冗長になる可能性があります)。

ODM / ドキュメント データベース / NoSQL

長所：

  • 膨大な量のデータ、および比較的独立した膨大な数のクエリにスケーラブル
  • 高可用性、シャーディング、マルチマスター、...
  • 半構造化データにうまくマッピング
  • 可変構造のデータにうまくマッピング
  • データモデルはより柔軟に
  • クエリを SQL に変換する必要はありません (ネイティブの NoSQL クエリ スタイルは、一部の用途には適している場合とそうでない場合があり、SQL ドライバー/解析などによるオーバーヘッドはありません)
  • (オブジェクト データベースの場合) オブジェクトに直接マップされ、オブジェクト リレーショナル変換は不要

短所：

  • 多くの場合、結合なし (または限定バージョンの結合)
  • 多くの場合、トランザクションはありません (または、トランザクションの一貫性/アトミック性の制限されたバージョン)。

決定方法

データの種類と使用パターンに基づく:

  • データの構造は統一されていますか? (リレーショナル) ... または変数/一貫性のない構造? （資料）
  • 一般的な使用法は、単一タイプのエンティティの読み取り/書き込みですか? (ドキュメント) ... または複数のエンティティのプロパティで構成されるビュー? （関連した）
  • 取引は必要ですか？(リレーショナル) ... またはトランザクションは必要ありませんか? （資料）

スケーリング/パフォーマンス要件に基づく:

  • 巨大なデータ + 少ない、遅い、複雑な読み取り/書き込み? (データ ウェアハウジング タイプのシナリオ) => リレーショナル
  • 膨大なデータ + 大量の単純な読み取り/書き込み? (craigslist バックエンド タイプのシナリオ) => ドキュメント
  • 巨大なデータ + 高速で複雑な読み取り/書き込み? => これは難しいです。リレーショナルを使用してスケールアップを試みるか、ドキュメントを使用してクエリを単純化してみてください
  • 中程度のデータ + 高速トランザクション書き込み? (銀行タイプのシナリオ) => リレーショナル
  • 中程度のデータ + 中程度の読み取り/書き込み? => ベンダー/ツールのサポート、親しみやすさなどに基づいていずれかを選択

参考文献

(背景: 最近はこの分野で何もしていませんが、数年前に複製された MySQL + Sphinx、つまりリレーショナルとドキュメントのハイブリッドを使用する大規模なシステムを構築しました)

于 2012-11-28T07:16:17.640 に答える