ディスク使用量によるさまざまな mongodb サービス メーター。mongodb を使用するときにスペースを節約するためのヒントは何ですか?
ありがとう。
この質問は、実に漠然としています。あなたに当てはまるかもしれないし、当てはまらないかもしれないいくつかのこと(順不同):
これは、次の例で最もよく説明されています。
{
surname: "Smith",
forename: "John",
location: { grid_e: 100.02, grid_n: 450.08 }
}
前のドキュメントは、さまざまなフィールド名の不要な言葉遣いを削除することで短縮できます。
{
sn: "Smith",
fn: "John",
loc: { e: 100.02, n: 450.08 }
}
これにより、スペースがわずかに節約されますが、各ドキュメントのサイズ (フィールドの数) とドキュメントの数が乗算されます (数百万の場合、かなりの量になる可能性があります)。これは、この方法の利点と欠点について説明している素晴らしい投稿です。
上限付きコレクションを使用すると、保存するドキュメントの数に制限を指定できます。先入れ先出し方式で機能します (最も古いドキュメントは破棄されます)。これは、ログを記録していて、最新のx
ドキュメントを保存したいが、古いドキュメントには関連性がない場合に特に当てはまります。
上限付きコレクションの使用にはいくつかの注意事項があります。詳細については、MongoDB のドキュメントを参照してください。
ドキュメントには、埋め込まれたドキュメントまたは他のドキュメント (他のコレクション内の) 外部キー スタイルとの関係のいずれかを含めることができます。各アプローチの長所と短所は頻繁に議論さ れますが、最終的には、どのアプローチが適切かを選択する必要があります。
ブログを例にとると、各ブログ投稿には作成者がいる場合があります。この著者情報を各投稿に埋め込むか、独自の投稿authors
またはusers
コレクションに投稿することを選択できます。後者のアプローチは、特に多くのユーザーが (1 つまたは 2 つの投稿ではなく) 多くの投稿を頻繁に行う場合に、スペースを節約します。結合がないため、追加のデータベース呼び出しが発生することに注意してください。
ドキュメント間の関係は、ドキュメントの埋め込みに加えて、いくつかの方法で行うことができます。関連するドキュメントの ID を次のように使用できます (上記のブログの例を再利用):
{
_id: <whatever>,
title: "Document Relationships in MongoDB",
body: "bla bla bla bla",
// ...
user_id: <id of the user document>
}
コレクションにはusers
、その関連ドキュメントが存在します。
{
_id: <whatever>,
name: "Mark Embling",
email: "example@markembling.info",
///...
}
これはおそらく、リレーションシップに対する最も単純なアプローチです (リレーションシップを埋め込むことを除けば)。必要なときに関連するユーザーを取得し、必要に応じて更新するために呼び出しを行う必要があります。とはいえ、私はこのアプローチに何の問題もないと考えており、何度か使用されているのを見てきました。
同様のアプローチは、DBRef を使用することです。これは、上記のような関係を記述するためのより正式な方法です。他のドキュメントの ID を入れるだけでなく、形式化された別のドキュメントへの一種の参照である DBRef を指定します。それが理にかなっていることを願っています。ここで説明した両方のアプローチは、mongodb のドキュメントで詳しく説明されています。DBRef は、どのコレクションが参照されているかなどの余分な (おそらく冗長な) 情報を保持するため、手動参照は DBRef より (わずかに) 少ないスペースしか占有しないことに注意してください。ただし、多くのドライバー ライブラリでネイティブにサポートされているという利点があるため、作業が少し楽になります。
最終的に、どの方法が機能し、関連性があるかは、何をしようとしているのかによって異なります。オプション、トレードオフを検討し、それがあなたがすべきことかどうかを判断してください。そして実験。
関連するデータに 1 つのドキュメントを使用するのが良い方法だと思います
たとえば、ユーザーコレクションがある場合、各ユーザーにドキュメントを提供し、このドキュメントにアバターやACLなどの他のものを埋め込むことができます
データの重複を避け、検索可能にする必要のない大量のデータを保存する場合は、何らかの形式の圧縮を使用するようにしてください。