2

わかりました、NoSQL データベースはクエリにジョイントを使用しないことがすべてであることは理解していますが、いくつかの概念に頭を悩ませることはできません。たとえば、複数の著者とその著者に関連する記事を含むブログを作成したいとします。MySQL では、ユーザーのテーブルを作成します。

Users: id, name, surname, nickname, password...
Articles: id, user_id, title, content, date, tags...

しかし、MongoDB でこれを適切に設定するための最良の方法が何であるかはわかりません。私はただ言うべきですか:

db.users.insert({
    id:1,
    name: "Author name",
    ...
    articles: [{id:1, article:1, title:"Article title", ...}, {...}, ...]
});

私はおそらくこのようなことをする必要がありますか?:

db.articles.insert(
    {
    ...
    article related stuff
    ...
    user related stuff: {...}
);

それとも、記事用に別のデータベースとユーザー用に別のデータベースを用意する必要がありますか?

最新の 10 の記事の抜粋と著者データを表示するホームページがある場合、MySQL では、著者テーブルから著者のニックネームを取得し、記事テーブルからタイトルと抜粋を取得するための共同クエリを実行します。

ドキュメント指向のデータベースで自分のデータを表現する方法がよくわかりません。著者のデータをそれぞれの記事に保存する必要があるかもしれませんが、著者が情報を変更した場合、その著者のすべての記事を更新する必要があります。

MongoDB で個別のドキュメントを作成するのは理にかなっているように思えます。1 つはすべての著者ドキュメントを保持し、もう 1 つはすべての記事ドキュメントを保持しますが、最初の 10 個の記事を取得し、著者ドキュメントから著者データを取得する何らかの共同操作が必要になります。

わかりました、多分いくつかのマップ削減操作ですが、それがどのように見えるかはわかりません.

私のこの問題に関するあなたの考えとアドバイスをいただければ幸いです。ありがとう!

[編集] また、すべての記事を 1 つのドキュメントに保持する場合、1 つのドキュメントあたり 16 mb の制限があり、これは大規模な Web サイトの場合に問題になるため、記事用に別のデータベースが必要だと思いますか?

4

2 に答える 2

3

@Pavel が既に述べたように、 http://www.mongodb.org/display/DOCS/Schema+Design を経験したことがあると想定しています

スキーマの設計は、MongoDB では完全に相対的な概念であり、ケースバイケースです。コレクションをどのように設計するか、リンクと埋め込みは、データ アーキテクチャ、データのサイズ、クエリの方法によって異なります。

著者の情報があまりスペースを占めていない場合は、記事のドキュメントに著者の情報を埋め込むことをお勧めします。記事や著者にもインデックスを付けることができるため(埋め込まれていても)、ルックアップは非常に高速です。

作成者が自分の情報を変更した場合、その情報コレクション全体を簡単に更新できます。この著者が著者リストにリストされている記事を更新するだけです。特に $ (位置演算子) を使用します。http://www.mongodb.org/display/DOCS/Updating#Updating-The%24positionaloperator

ただし、サイズと制限が気になる場合は、別の話です。@Derickが述べたように、16MBはたくさんあります。したがって、制限に達すると思われる場合は、個別のコレクションに移動してリンクを実行してください。

私が知る限り、MongoDB はデフォルトで複数のコレクションにまたがる MapReduce 機能を提供していないため、最終的にいくつかの手順で実行することになり、リソースを大量に消費することになります。

MapReduce は、本番での使用には最適ではありません。バッチ プロセスで使用するのが最適ですが、リアルタイムの集計では、さまざまなソリューション (ニーズに合わせて調整) を考え出し、それらをベンチマークすることをお勧めします。ドキュメントを見つけて、スクリプト側 (Python、PHP など) で集計を行う方が速い場合もあります。

最後に、MongoDB と NoSQL がどれほど美しく、高速でトレンディであっても、すべての問題を解決できるわけではありません。一部の問題は、従来のリレーショナル アプローチで対処するのが最適です。

于 2012-05-09T20:22:51.263 に答える
3

まず、用語の一部を修正させてください。

  • db.databaseName.insert({間違っています。データベースに接続したら、ドキュメントをコレクションに挿入します。行は次のように記述しdb.articles.insert({ます。

  • 現在、ドキュメントの最大サイズは16MBです。

この場合、私がおそらく行うことは、すべての記事を記事コレクションに保存することです。ここで、フィールドの 1 つが著者名(または著者のニックネーム) になります。この理由は主に、これがホームページで頻繁に実行されるクエリであると述べたためです。その後、 authorsコレクション内のドキュメントに追加の作成者情報を格納できます。各著者の _id フィールドは、単に著者名(または著者のニックネーム) である可能性があります。スカラー値 (および配列ではない) である限り、「ObjectId」型である必要はまったくありません。

または、最初の例で示したように、著者によるすべての記事を入れ子になった配列として、記事コレクションに保存することもできます。16MB のドキュメント制限は少し聞こえるかもしれませんが、それはあなたが思っている以上です。たとえば、私のブログの 477 の記事は 2.4MB しか占有しません。

于 2012-05-09T19:12:39.223 に答える