4

好きなようにMongoDBを構築できるので、このようにすることができます

{ products:
  [
    { date: "2010-09-08", data: { pageviews: 23, timeOnPage: 178 }},
    { date: "2010-09-09", data: { pageviews: 36, timeOnPage: 202 }}
  ],
  brands:
  [
    { date: "2010-09-08", data: { pageviews: 123, timeOnPage: 210 }},
    { date: "2010-09-09", data: { pageviews: 61, timeOnPage: 876 }}
  ]
}

そのため、毎日データを追加すると、productsドキュメントとbrandsドキュメントはどんどん大きくなります。3 年後には と に 1000 個の要素が存在productsしbrandsます。MongoDB には適していませんか? さらに 4 つのドキュメントに分割する必要があります。

{ type: 'products', date: "2010-09-08", data: { pageviews: 23, timeOnPage: 178 }}
{ type: 'products', date: "2010-09-09", data: { pageviews: 36, timeOnPage: 202 }}
{ type: 'brands', date: "2010-09-08", data: { pageviews: 123, timeOnPage: 210 }}
{ type: 'brands', date: "2010-09-08", data: { pageviews: 61, timeOnPage: 876 }}

では、3 年後には 2000 の「ドキュメント」しかないということですか?

4

5 に答える 5

2

Mongoid を使用している (タグ付けした) と仮定すると、最初のスキーマのアイデアを使用したくないでしょう。単一の小さな値を検索するたびに、Mongoid がこれらの巨大なドキュメントを引き出すのは非常に非効率的です。

おそらくあなたにとってより良いモデルは次のとおりです。

class Log
  include Mongoid::Document

  field :type
  field :date
  field :pageviews,    :type => Integer
  field :time_on_page, :type => Integer
end

これにより、次のようなドキュメントが得られます。

{_id: ..., date: '2010-09-08', type: 'products', pageviews: 23, time_on_page: 178}

ドキュメントの数について心配する必要はありません。Mongo は何十億ものドキュメントを処理できます。また、タイプと日付に索引を付けて、必要な図を簡単に見つけることができます。

さらに、この方法では、データベースからレコードを取得しなくても、ドライバーを介してレコードを更新する方がはるかに簡単です。たとえば、各ページビューで次のようなことができます。

Log.collection.update({'type' => 'products', 'date' => '2010-09-08'}, {'$inc' => {'pageview' => 1}})
于 2010-09-11T02:18:46.257 に答える
1

私は MongoDB の専門家ではありませんが、1000 は「巨大」ではありません。また、合計 4000 のサブ要素を含む 1 つのトップレベル ドキュメントと、それぞれ 1000 のサブ要素を含む 4 つのトップレベル ドキュメントの違いを真剣に疑うでしょう。

1,000,000 個の要素を持つ 1 つのドキュメントと、それぞれ 1000 個の要素を持つ 1000 個のドキュメントを話している場合、それは大きさが異なります + ストレージ時間またはクエリ時間のいずれか/両方で、一方と他方の利点がある可能性があります。

于 2010-09-11T00:40:01.167 に答える
0

あなたの設計はリレーショナル テーブル スキーマによく似ているようです。

代替テキスト

したがって、追加されたすべてのドキュメントは、独自の識別子を持つコレクション内の個別のエントリになります。mongo ドキュメントのサイズは 4 MB に制限されていますが、ほとんどの場合、プレーン テキスト ドキュメントを収容するには十分です。また、mongo で増加するドキュメントの数を心配する必要はありません。これがドキュメント ベースのデータベースの本質です。

心配する必要があるのは、db コレクションのサイズだけです。32ビットシステムでは2GBに制限されています。MongoDB は、使用可能なメモリ アドレッシングに関連付けられているメモリ マップト ファイルを使用するためです。これは、64 ビット システムでは問題になりません。

お役に立てれば

于 2010-09-14T13:30:10.357 に答える
0

データを更新する方法について話しましたが、どのようにクエリを実行する予定ですか? おそらく、ドキュメントをどのように構成する必要があるかに違いがあります。

配列に埋め込み要素を使用する際の問題は、要素を追加するたびに、ドキュメントに割り当てられている現在のスペースに収まらない可能性があることです。これにより、(新しい) ドキュメントが再割り当てされ、移動されます (その移動には、ドキュメントのインデックスを書き直す必要があります)。

一般的には、あなたが提案した 2 番目の形式をお勧めしますが、上記の質問によって異なります。

注: 4MB は任意の制限であり、すぐに引き上げられる予定です。実際に必要な制限に対してサーバーを再コンパイルできます。

于 2010-09-12T20:37:49.850 に答える
0

繰り返しますが、これはクエリのユースケースによって異なります。1日あたりの製品など、単一のアイテムを本当に気にする場合:

{ type: 'products', date: "2010-09-08", data: { pageviews: 23, timeOnPage: 178 }}

1 つの日付に複数の日を含めることができます。

{ type: 'products', { date: "2010-09-08", data: { pageviews: 23, timeOnPage: 178 } } }

次のようなものを使用します。

{ type: 'products', "2010" : { "09" : { "08" : data: { pageviews: 23, timeOnPage: 178 }} } }

したがって、日単位でインクリメントできます: { "$inc" : { "2010.09.08.data.pageviews" : 1 } }

複雑に思えるかもしれませんが、「タイプ」に関するすべてのデータを 1 つのレコードに格納できるという利点があります。したがって、単一のレコードを取得して、すべての情報を取得できます。

于 2010-09-15T19:17:45.450 に答える