MongoDBとPostgreSQLのパフォーマンスの比較。 パートII:インデックス

続けて、 ここから始めてください



実験II:インデックス





この実験では、 id フィールドfloatvalueフィールドにインデックスを作成しました(テキストフィールドは省略しました。フルテキストインデックスのトピックについては触れません。これは別の記事の資料です)。 クエリとして、範囲のサンプルを使用しました。







ただし、最初に、インデックスを追加した後に挿入速度がどれだけ低下したかを評価する必要があります。 これを行うには、MongoDBとPOstgreSQLに別の250,000エントリを追加します。







モンゴッド



Insert 250000 records complete! Total time: 69.453 sec
      
      







PostgreSQL



 psql -d prefTest -f 250k.p5.sql (Total time: 466.153 sec)
      
      







簡単な計算の後、MongoDBは挿入速度の点で議論の余地のないリーダーであり続けていることがわかります。インデックスを追加した後、挿入率はわずか10%低下し、 1秒あたり3600オブジェクトに達しました。 一方、PostgreSQLの挿入速度は1秒あたり536レコードに約30%低下しました。



サンプルの状況を同様の方法で発展させたいです。 次のリクエストを処理します。



モンゴッド



  1. db.tmp.find({$and:[{id:{$gt:10000}},{id:{$lt:100000}}]})



  2. db.tmp.find({$and:[{floatvalue: {$lt:300000}},{floatvalue: {$gt:200000}}]})







PostgreSQL



  1. select * from tmp where id>10000 and id<100000



  2. select * from tmp where floatvalue<300000 and floatvalue>200000







ただし、操作の速度を比較した後、サンプリング状況はPostgreSQLに変更されました。



画像



また、範囲からではなく、特定の数値( floatvalue=1234567.76545



)でサンプリングした場合、両方のDBMSで0ミリ秒の結果が表示されたことも注目に値します。 したがって、このような操作はここでは考慮されていません。 これは、計画されたサンプリング条件に従ったインデックスの賢明な使用に関するものです。 ここでは、インデックスとクエリは負荷テストの目的でのみ使用されます。



別の啓示は、インデックスを使用すると、MongoDBがCPU消費を劇的に削減し(インデックスなしで検索した場合は最大30%から40% )、これでPostgreSQLを追い越す( 5-25に対して4-14%に減少) )。



まとめ





何かを要約する前に、約束どおり、リクエストの結果のプレートとリソース消費の図を共有します。



画像



画像



画像



そして、結果について。



肉眼で見ると、PostgreSQLに対するMongoDBの利点の1つである挿入速度がすぐにわかります。 インデックスを使用した場合と使用しない場合の両方で、ほぼ1桁高くなっています。 さらに、インデックスを使用しても、インデックスが大幅に減少することはありません(PostgreSQLの30%の減少に対して、最大10%しか減少しません)。 これは本当に素晴らしい結果です! しかし... (選択に対してさまざまな条件下で)挿入を使用する頻度はどれくらいですか?



それほど重要ではありませんが、インデックスのないコレクションからフェッチする場合、MongoDBもリードします。 悪くない! しかし... ... インデックスのないテーブルをどのくらいの頻度で使用しますか?



私の質問でnoSQL DBMSからあなたを引き離そうとしているとは思わないでください。 インデックスのないテーブル(プライマリを意味するわけではありません)には、これらの決定またはそれらの決定に含まれる場所があります。 一部のタスクの挿入速度の優先度も非常に現実的であり、さらに非常に需要が高い場合があります。 問題は、 特にこれが必要ですか? 現在のタスクに具体的ですか? この(非常に表面的な)テストは、「SQLやnoSQLより優れているものは何ですか?」というかなり一般的な質問に答えることを意図したものではありません。 特定のタスクのためのソリューションを選択する際に、あなたを考えに導き、ニーズと機会を評価するように設計されています。



最後に、たとえば、データ構造、目標、およびそれらを操作するためのオプションに応じて、両方のタイプのDBMSを使用すると言います。 統合アプローチの方がはるかに優れており、あらゆるデータを最適に処理できます。



All Articles