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

MongoDB は高性能なデータベースですが、使用していくうちにパフォーマンスの問題が発生することがあります。 SQL Server、MySQL、Oracle などの他のリレーショナル データベースと比較すると、MongoDB は比較的新しいため、あまり馴染みのない人が多くいます。そのため、多くの開発者や DBA は機能の実装に重点を置き、パフォーマンス要件を無視する傾向があります。実際、SQL Server、MySQL、Oracle と同様に、MongoDB の設計調整、インデックス作成、ステートメントの最適化はパフォーマンスに大きな影響を与えます。

MongoDB のパフォーマンスを徹底的に探求するために、次の 18 項目を簡単にまとめました。 引き続きまとめ、改善を続けていくことを皆様に歓迎します。

（１）ドキュメント内の_idキーにはデフォルト値を使用することをお勧めします。_idにカスタム値を保存することは禁止されています。

解釈: すべての MongoDB ドキュメントには「_id」キーがあり、これはデフォルトで ObjectID オブジェクトです (識別子には、タイムスタンプ、マシン ID、プロセス ID、カウンターが含まれます)。 MongoDB への挿入速度は、_id を指定するか指定しないかによって大きく異なります。_id を指定すると挿入速度が低下します。

（２）短いフィールド名を使用することをお勧めします。

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

（3）MongoDBのインデックスはドキュメントのクエリ、更新、削除、ソート操作を改善できるため、ビジネスニーズに応じて適切にインデックスを作成します。

（4）各インデックスはある程度のスペースを占有し、挿入操作のリソース消費を引き起こします。したがって、各コレクションのインデックスの数は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インデックス（Time-To-Liveインデックス、ライフサイクルを持つインデックス）。TTLインデックスを使用すると、タイムアウト期間に達したドキュメントを古めかしくすることができます。ドキュメントが古めかしいレベルに達すると、削除されます。

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

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

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

（8）テキストインデックスを作成するときは、フィールドを1または-1ではなくテキストとして指定します。各コレクションにはテキスト インデックスが 1 つだけありますが、任意の数のフィールドにインデックスを付けることができます。

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

(9) findOneを使用してデータベース内の複数の一致する項目を照会すると、自然にソートされたドキュメントセットの最初の項目が返されます。複数のドキュメントを返す必要がある場合は、find メソッドを使用します。

（10）クエリがドキュメント全体を返す必要がない場合、またはキー値が存在するかどうかを判断するためだけにクエリが使用される場合は、投影（マッピング）を使用して返されるフィールドを制限し、ネットワークトラフィックとクライアントのメモリ使用量を削減できます。

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

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

（12）集計演算では、$はmatchの前と$groupの前に来なければなりません。$を演算子の先頭に置くことで、一致の数と$group演算子が処理しなければならない文書の数を減らすことができます。

（13）オペレータを介して文書を変更すると、文書データを取得して変更するためにサーバーとやり取りする必要がなく、データのシリアル化と転送にかかる時間が短縮されるため、通常はパフォーマンスが向上します。

（14）バッチ挿入により、サーバーへのデータの送信回数が減り、パフォーマンスが向上します。ただし、バッチ送信の BSON サイズは 48 MB を超えません。

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

(16) クエリ内の一部の$演算子（$ne、$、not、$exists、$nin、$orなど）はパフォーマンスを低下させる可能性があります。ビジネスではこれらの演算子を使用しないようにしてください。

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

b) $ne: 否定された値が大多数の場合は、インデックス全体がスキャンされます。

c) $not: クエリ オプティマイザーがどのインデックスを使用するか分からなくなる可能性があり、その結果、完全なテーブル スキャンが必要になることがよくあります。

d) $nin: テーブル全体のスキャン。

e) \$ 複数の条件がある場合は、クエリが一定回数実行され、結果セットが最後にマージされます。またはに変換することを検討してください。 複数の条件がある場合は、クエリが一定回数実行され、結果セットが最後にマージされます。$in に変換することを検討してください。

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

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

（18）コレクション内の文書のデータ量はクエリのパフォーマンスに影響します。適切な量を維持するために、定期的にアーカイブする必要があります。

Mongodb パフォーマンス最適化

データベースのパフォーマンスは、ソフトウェアの全体的なパフォーマンスに重大な影響を及ぼします。Mongodb データベースで一般的に使用されるパフォーマンス最適化方法は次のとおりです。

1. パラダイム化と脱パラダイム化

2. フィルファクターの使用

3. 索引の使用

以上がMongoDBのパフォーマンスを向上させる方法についての内容です。123WORDPRESS.COMをご愛顧いただきありがとうございました。