この記事の内容は Mongodb と MySQL の比較分析に関するものです。必要な方は参考にしていただければ幸いです。
データベースに格納されたデータには、主キーと呼ばれる特別なキー値があり、テーブル内のレコードを一意に識別するために使用されます。つまり、テーブルに複数の主キーを持つことはできず、主キーを null にすることもできません。 MongoDBでもMySQLでも、主キーの定義が存在します。 MongoDB の場合、主キーは「_id」と呼ばれます。データを生成するときに、ユーザーが主キーを積極的に割り当てない場合、MongoDB はランダムに割り当てられた値を自動的に生成します。
ストレージ速度の比較
1. データベースの平均挿入率: MongoDB は _id 挿入を指定しません> MySQL は主キーを指定します。挿入> MongoDB は挿入用の _id を指定します。 2. MongoDB では、_id を指定した場合と指定しない場合では挿入速度に大きな差がありますが、MySQL ではその差ははるかに小さいです。分析:
1. _id または主キーを指定する場合、2 つのデータベースは挿入時にインデックス値を処理し、データベース内に同じ値が存在するかどうかを確認する必要があります。 . キーの値により、挿入速度が遅くなります。 2. MongoDB では、インデックス挿入を指定すると、指定しない場合よりもはるかに時間がかかります。これは、MongoDB 内の各データの _id 値が固有であるためです。 _id を指定せずにデータが挿入された場合、その _id はシステムによって自動的に計算され、生成されます。 MongoDB は、コンピューターの特性、時間、プロセス ID、乱数を使用して、生成された _id が一意であることを保証します。 _id を指定して挿入する場合、MongoDB はデータを挿入するたびにこの _id が使用可能かどうかを確認する必要があります。データベース内のデータ項目が多すぎると、このステップのクエリのオーバーヘッドにより全体の挿入速度が遅くなります。データベース。 3. MongoDB はシステム メモリをキャッシュとして完全に使用します。これは非常に優れた機能です。私たちのテスト マシンには 64G のメモリがあり、メモリを挿入すると、MongoDB はメモリがデータでほぼいっぱいになった後、データをハードディスクに永続化しようと最善を尽くします。これは、_id を指定せずに挿入する場合に MongoDB がはるかに効率的である理由でもあります。ただし、_idを指定して挿入する場合、データ量が多くてメモリに収まらない場合、MongoDBは重複チェックのためにディスクから情報をメモリに読み込む必要があり、挿入効率が遅くなります。 4. MySQL は確かに非常に安定したデータベースであり、主キーを指定して挿入しても、主キーを指定せずに挿入しても、その効率に大きな違いはありません。挿入安定性解析
挿入安定性とは、データ量が増加するにつれて、一定量のデータを挿入したときの挿入率を指します。 このテストでは、このインジケーターのスケールを 100,000 に設定します。つまり、表示されるデータは、100,000 個のデータが挿入されたときに、この期間中に 1 秒あたり何個のデータを挿入できるかということです。 最初に 4 つの図を示します: 1. MongoDB は _id 挿入を指定します:
##2. MongoDB は _id 挿入を指定しません:
3. MySQL は挿入用の PRIMARY KEY を指定します:
##4. MySQL は挿入用の PRIMARY KEY を指定しません: 
要約:
1. 全体的な挿入速度は、依然として前のラウンドの統計と同様です。MongoDB は次のようになります。挿入用の _id を指定しません> MySQL は挿入用の主キーを指定しません> MongoDB は挿入用の _id を指定します。
2. 図からわかるように、主キーを指定してデータを挿入する場合、MySQL と MongoDB でデータの大きさが異なる場合、1 秒あたりに挿入されるデータが時々変動します。チャートの表示に定期的な不具合が発生します。データの挿入を指定しない場合、ほとんどの場合挿入率は比較的平均的ですが、データベース内のデータが増加すると、挿入効率は一定期間で一時的に低下し、その後再び安定します。 3. 全体として、MySQL よりも MongoDB のレート変動が大きく、分散が大きく変化します。4. MongoDB が _id を指定して挿入する場合、これ以上のデータを挿入すると挿入効率が大幅に低下します。他の 3 つの挿入テストでは、挿入速度は最初から最後までほとんどの時間、標準で固定されています。
分析:
1. 不具合現象は、挿入されるデータが多すぎると、MongoDB がメモリ内のデータをハードディスクと MySQL に書き込む必要があるためです。サブテーブルを再作成する必要があります。これらの操作は、データベース内のデータが特定のレベルに達するたびに自動的に実行されるため、明らかな不具合が発生することがあります。
2. 結局のところ、MongoDB はまだ新しいものであり、その安定性は長年使用されている MySQL には及ばないのです。
3. MongoDB が指定された _id を挿入すると、パフォーマンスが大幅に低下します。
4. 読み取られるデータのサイズが大きくない場合、MongoDB のクエリ速度は実に比類のないものであり、MySQL に大きく劣ります。
5. クエリされるデータの量が徐々に増加すると、MySQL のクエリ速度は着実に低下しますが、MongoDB のクエリ速度は多少変動します。
分析:
1. MySQL がクエリに最適化されていない場合、そのクエリ速度を MongoDB と比較すべきではありません。 MongoDB はシステムのメモリ リソースを最大限に活用できます。メモリが大きいほど、MongoDB のクエリ速度は桁違いに速くなります。 。
2. この実験のクエリ データもランダムに生成されるため、クエリ対象のすべてのデータが MongoDB のメモリ キャッシュに格納される可能性は非常に低くなります。クエリを実行する場合、MongoDB はメモリとディスク内のデータを見つけるために複数回対話する必要があるため、クエリ速度は対話の回数によって決まります。クエリされるデータの量は多くなりますが、このランダムに生成されたデータが MongoDB によってディスクからフェッチされる回数は少なくなる可能性があります。したがって、平均クエリ速度は速くなります。この観点から見ると、MongoDB のクエリ速度の変動も妥当な範囲内にあります。
3. MySQL の安定性については疑いの余地がありません。
結論
1. MySQL と比較して、MongoDB データベースは大量の読み取り操作を伴うタスク モデルに適しています。 MongoDB はマシンのメモリ リソースを最大限に活用できます。マシンに豊富なメモリ リソースがある場合、MongoDB のクエリ効率ははるかに速くなります。
2. "_id" を使用してデータを挿入する場合、MongoDB の挿入効率は実際には高くありません。 MongoDB のパフォーマンスを最大限に活用したい場合は、「_id」なしで挿入し、クエリ用に関連するフィールドにインデックスを付けることをお勧めします。
3. MongoDB は、データベースの特定のデータ形式が不明瞭であるか、データベースのデータ形式が頻繁に変更される需要モデルに適しており、開発者にとって非常に使いやすいです。
4. MongoDB には正式に分散ファイル システムが付属しており、サーバー クラスターに簡単にデプロイできます。 MongoDB にはシャードという概念があり、サーバーのシャーディングに便利です。シャードを追加するたびに、MongoDB の挿入パフォーマンスがほぼ 2 倍になり、ディスク容量を簡単に拡張できます。
5. MongoDB には、データ統計にも非常に便利なマップ リデュース コンピューティング フレームワークもサポートされています。
MongoDB の欠陥
1. トランザクション関係のサポートが弱い。これはすべての NoSQL データベースに共通する欠陥でもありますが、NoSQL はトランザクション関係向けに設計されておらず、特定のアプリケーションは依然として需要があります。
2. 上記のテストからもわかるように、安定性がやや欠けています。
3. MongoDB は、開発者にとって便利である一方で、運用および保守担当者に多大な要求を課します。業界には MongoDB の運用および保守の成熟した経験がなく、MongoDB のデータの保存形式も非常にランダムです。このような問題は、運用および保守担当者にとって試練となります。
以上がMongodbとMySQLの比較分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
