8

私はMongoDBを初めて使用するので、ご容赦ください。

2つの質問があります：

まず、次のことを行います。

// add a record
$obj = array( "title" => "Calvin and Hobbes", "author" => "Bill Watterson" );

MongoDBは、このコレクション内のこのオブジェクトのすべてのエントリのテキストとして「title」と「author」を保存しますか？または、スキーマを作成してこれらをフィールド番号に変換しますか（または何もせずに純粋にデータを保存しますか）？

私の2番目の質問は、「関係」はいつ使用されるべきかということです。たとえば、100のリセラーがあり、それぞれに（オブジェクトごとに）1,000のクライアントが含まれており、各クライアントには10​​のプロジェクトがあります。これにより、1つの巨大なオブジェクト全体を操作できます。

SQLの世界では、これはすべて関連する「オブジェクト」になります。ドキュメントの世界では、サブオブジェクトを埋め込むことで完全なオブジェクトを保存しようとします。

ただし、これは扱いにくい場合があります。このためのベストプラクティスは何ですか？誰かが私にガイドラインを教えてもらえますか？

ありがとう。

4

2 に答える 2

13

このコレクションのすべてのエントリのMongoDBフィールド名はありますか？

はい、MongoDBはすべてのレコードのテキストを保存します。実際には、ディスクスペースが制限要因である場合、これは通常それほど問題にはなりません。別のことを検討することをお勧めします。

「関係」はいつ使用する必要がありますか？

これは科学というよりは芸術です。スキーマに関するMongoのドキュメントは良いリファレンスですが、考慮すべき点がいくつかあります。

  • できるだけ入れて

    ドキュメントデータベースの利点は、多くの結合を排除できることです。最初の本能は、できるだけ多くを1つのドキュメントに配置することです。MongoDBドキュメントには構造があり、その構造内で効率的にクエリを実行できるため、SQLのようにデータをすぐに正規化する必要はありません。特に、親ドキュメント以外で役に立たないデータは、同じドキュメントの一部である必要があります。

  • 複数の場所から独自のコレクションに参照できる分離されたデータ。

    これは「データの一貫性」の問題であるため、「ストレージスペース」の問題ではありません。多くのレコードが同じデータを参照する場合、単一のレコードを更新して他の場所でその参照を保持する方が効率的でエラーが発生しにくくなります。

  • ドキュメントサイズに関する考慮事項

    MongoDBは、1つのドキュメントに4MBのサイズ制限を課します。GBのデータの世界では、これは小さいように聞こえますが、3000万のツイート、25万の典型的なStack Overflowの回答、または20枚のちらつきの写真でもあります。一方、これは、一般的なWebページで一度に提示したい情報よりもはるかに多くの情報です。まず、クエリを簡単にするものを検討します。多くの場合、ドキュメントサイズに関する懸念は時期尚早の最適化です。

    あなたが与えた例では、プロジェクトのリストを作成するために他の9つのプロジェクトについて知る必要がないため、3つの別々のコレクションを作成します。クエリは単純にしておきます。（ただし、下部のProtipを参照してください）

  • 複雑なデータ構造：

    MongoDBは、任意の深いネストされたデータ構造を格納できますが、それらを効率的に検索することはできません。データがツリー、フォレスト、またはグラフを形成する場合は、各ノードとそのエッジを個別のドキュメントに効果的に保存する必要があります。（このタイプのデータ用に特別に設計されたデータストアも考慮する必要があることに注意してください）

  • データの一貫性

    MongoDBは、効率と一貫性の間でトレードオフを行います。ルールは、単一のドキュメントへの変更は常にアトミックであるのに対し、複数のドキュメントへの更新はアトミックであると想定されるべきではないということです。サーバー上のレコードを「ロック」する方法もありません（たとえば、「ロック」フィールドを使用して、これをクライアントのロジックに組み込むことができます）。スキーマを設計するときは、データの一貫性を維持する方法を検討してください。一般に、ドキュメントに保持する量が多いほど良いです。

プロのヒント

参照を使用する場合でも、親ドキュメントの参照からのデータの一部を保持することをお勧めします。一般的に、私は親の子孫への意味のあるリンクを構築するのに十分な情報を保持しています。

あなたの例では、これはリセラーのドキュメントにObjectIDと一緒にクライアント名を保持することを意味します。これにより、個別のクエリなしで名前で各クライアントへのリンクを作成できます。クライアントのURLを作成するために、ドキュメントID以外のものが必要な場合は、それも保存します。

このようなトリックは、1+nクエリの状況を減らすことができます。

于 2011-03-02T20:43:12.317 に答える
1

MongoDBは、このコレクション内のこのオブジェクトのすべてのエントリのテキストとして「title」と「author」を保存しますか？

MongoDBはスキーマレスです-したがって、答えは明白です：スキーマのようなものがないので、はい

私の2番目の質問は、「関係」はいつ使用されるべきかということです。たとえば、100のリセラーがあり、それぞれに（オブジェクトごとに）1,000のクライアントが含まれており、各クライアントには10​​のプロジェクトがあります。これにより、1つの巨大なオブジェクト全体を操作できます。

チェックしてください

http://www.mongodb.org/display/DOCS/Schema+Design

オプションは、埋め込みドキュメント、データベース参照、または複数のクエリです。

于 2011-03-02T17:55:34.357 に答える