MongoDB のパフォーマンスを向上させる方法の概要

この記事は、MongoDB のパフォーマンスを向上させるための方法をまとめたものです。必要な方は参考にしていただければ幸いです。

MongoDB は高パフォーマンスのデータですが、それを使用する過程で、誰もが時々パフォーマンスの問題に遭遇することがあります。 MongoDB と SQL などの他のリレーショナル データベースとの比較 サーバー、MySQL、Oracle それに比べて、これは比較的新しく、多くの人がよく知らないため、多くの開発者や DBA は機能の実現に重点を置き、パフォーマンス要件を無視する傾向があります。実際、MongoDB と SQL Server、MySQL、Oracle と同様に、データベース オブジェクトの設計調整、インデックスの作成、ステートメントの最適化はパフォーマンスに大きな影響を与えます。

MongoDB のパフォーマンスを最大限に活用するために、以下の 18 項目を簡単にまとめました。皆さんも引き続きまとめて改善してください。

(1) ドキュメント内の _id キーにはデフォルト値を使用することをお勧めします。カスタマイズした値を _id に保存することは禁止されています。

解釈: MongoDB ドキュメントには「_id」キーが存在します。これは、デフォルトでは ObjectID オブジェクトです (識別子にはタイムスタンプ、マシン ID、プロセス ID、カウンターが含まれます)。 MongoDB では、_id を指定する場合と指定しない場合では挿入速度に大きな差が生じます。

(2) 短いフィールド名を使用することをお勧めします。

解釈: リレーショナル データベースとは異なり、MongoDB コレクション内の各ドキュメントはフィールド名を保存する必要があり、長いフィールド名にはより多くの記憶領域が必要になります。

(3) MongoDB インデックスはドキュメントのクエリ、更新、削除、並べ替えの操作を改善できるため、ビジネス ニーズに基づいてインデックスを適切に作成します。

(4) 各インデックスはある程度の領域を占有し、挿入操作にリソースを消費するため、各コレクション内のインデックスの数はできる限り 5 以内に制御することをお勧めします。

(5) 複数のキーを含むクエリの場合、これらのキーを含む複合インデックスを作成するのが良い解決策です。複合インデックスのキー値の順序は、インデックスの左端のプレフィックスの原則を理解することが非常に重要です。

解釈: たとえば、テスト コレクションに結合インデックス {a:1,b:1,c:1} を作成します。次の 7 つのクエリ ステートメントを実行します。

db.test.find({a:”hello”}) // 1
db.test.find({b:”sogo”, a:”hello”}) // 2
db.test.find({a:”hello”,b:”sogo”, c:”666”}) // 3
db.test.find({c:”666”, a:”hello”}) // 4
db.test.find({b:”sogo”, c:”666”}) // 5
db.test.find({b:”sogo” }) // 6
db.test.find({c:”666”}) // 7

上記のクエリ ステートメントには 1、2、3、4 のインデックスが付けられます。

クエリには左端のインデックス フィールドが含まれ、インデックスの作成順序が優先されます。クエリフィールドの順序は関係ありません。

最小のインデックスでほとんどのクエリがカバーされます。

(6) TTL インデックス (存続時間インデックス、ライフサイクル付きインデックス)。TTL インデックスを使用すると、タイムアウト期間内にドキュメントを期限切れにすることができ、期限切れレベルに達するとドキュメントが削除されます。

解釈: TTL の作成に使用されるインデックスは日付型である必要があります。 TTL インデックスは単一フィールド インデックスであり、複合インデックスにすることはできません。 TTL ドキュメント削除バックグラウンド スレッドは、60 秒ごとに無効なドキュメントを削除します。固定長のコレクションはサポートされていません。

(7) コレクション内の特定のフィールドにインデックスを作成する必要があるが、コレクション内の多数のドキュメントにこのキー値が含まれていない場合は、スパース インデックスを作成することをお勧めします。

解釈: インデックスはデフォルトで集中的です。つまり、ドキュメントのインデックス フィールドが欠落している場合でも、インデックス内に対応する関係が存在します。スパースインデックスでは、インデックスキー値を含むドキュメントのみが表示されます。

(8) テキスト インデックスを作成する場合、フィールドには 1 または -1 の代わりにテキストを指定します。テキスト インデックスはコレクションごとに 1 つだけですが、必要な数のフィールドにインデックスを付けることができます。

解釈: テキスト検索のほうがはるかに高速です。コレクション ドキュメントの複数のフィールドに対する非効率なクエリを置き換えるには、テキスト インデックスを使用することをお勧めします。

(9) findOne を使用して、データベース内の一致する複数のアイテムをクエリすると、自然に並べ替えられたファイル コレクションの最初のアイテムが返されます。複数のドキュメントを返す必要がある場合は、find メソッドを使用します。

(10) クエリがドキュメント全体を返す必要がない場合、またはキー値が存在するかどうかを判断するためにのみ使用される場合は、プロジェクション (マッピング) を通じて返されるフィールドを制限して、ネットワーク トラフィックとクライアント メモリを削減できます。使用法。

解釈: {key:1} を設定して返されるフィールドを明示的に指定することも、{key:0} を設定して除外する必要があるフィールドを指定することもできます。

(11) プレフィックス スタイルのクエリを除き、正規表現クエリはインデックスを使用できないため、ほとんどのセレクターよりも実行に時間がかかります。使用は控えめにする必要があります。

(12) 集計操作では、$ を match および $group の前に置く必要があります。$ を接頭辞として付けることで、match の接頭辞を減らし、$group 演算子によって処理されるドキュメントの数を減らすことができます。

(13) オペレーターを使用してドキュメントを変更すると、ドキュメント データを取得して変更するためにサーバーに行ったり来たりする必要がなくなり、データのシリアル化と送信に費やす時間が短縮されるため、通常はパフォーマンスが向上します。 。 時間。

(14) バッチ挿入 (batchInsert) は、サーバーへのデータ送信の数を減らし、パフォーマンスを向上させることができます。ただし、バッチで送信される BSON サイズは 48MB を超えません。

(15) MongoDB は現在、32M 以内のソート結果セットを一度に取得することは禁止されています。並べ替えが必要な場合は、結果セット内のデータ量を制限するようにしてください。

(16) クエリ内の一部の $ 演算子 ($ne、$、not、$exists、$nin、$ など) はパフォーマンスの低下を引き起こす可能性があります。ビジネスでは使用しないでください。

a) $exist: 緩いドキュメント構造のため、クエリは各ドキュメントを走査する必要があります;

b) $ne: 否定された値が過半数である場合、インデックス全体がスキャンされます。 ;

c) $not: クエリ オプティマイザーがどのインデックスを使用すべきかを認識できない可能性があるため、多くの場合、フル テーブル スキャンに低下します。

# #e) \$複数の条件がある場合は、結果セットをマージするときに、それを or に変更することを検討する必要があります。複数の条件がある場合は、どのようにクエリすることになります。結果セットをマージする場合は、それを $in に変更することを検討する必要があります。

(17) 固定コレクションを使用してログを記録すると、データの挿入が速くなり、データの挿入時に最も古いデータを削除できます。この機能は、需要の分析と設計中に考慮できるため、パフォーマンスが向上し、削除の必要がなくなります。

解釈: 固定コレクションは明示的に作成する必要があり、サイズを指定し、ドキュメントの数も指定できます。どちらの制限に最初に到達しても、後で挿入された新しいドキュメントでは最も古いドキュメントが削除されます。

(18) コレクション内のドキュメントのデータ量はクエリのパフォーマンスに影響します。適切な量を維持するには、定期的にアーカイブする必要があります。

以上がMongoDB のパフォーマンスを向上させる方法の概要の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。