この結果は論理的です。ベンチマークの結果を理解するには、システムでトリガーされた操作を理解することが重要です。
RedisとPostgreSQLの両方のクライアントは、それぞれのサーバと同期して動作します。各ステートメントについて、それらは照会を送信し、次のステートメントを処理する前に応答を待ちます。
このような量では、(PostgreSQLを使用していても)多くのことが起こります。さらに、ここには並行処理はありません。したがって、操作のコストはI/Oや索引付けによって支配されるのではなく、クライアントとサーバーの間で交換されるラウンドトリップによって支配されます。
ここで、各テストで生成されるラウンドトリップはいくつですか?
PostgreSQLではレコードごとに1つのステートメントがあり、その結果200,000回のラウンドトリップが発生します。 Redisでは、レコードごとに2つのステートメントがあり、その結果、400000回のラウンドトリップが発生します。さらに、Redis往復には、スキーマのキーワード(データ、タイムスタンプ、値)が体系的に含まれており、アドレスはレコードごとに2回送信されます。 Redisテストではさらに多くのデータが交換されます。
また、クライアントソフトウェアによって入力ファイルが解析される方法に違いがあるかもしれません。
redis-cliによる結果を少し改善するには、コマンドHMSETを使用してレコードごとに1つのステートメントのみを送信します。
HMSET data:address timestamp <VALUE> value <VALUE>
しかし、ここで本当のゲインはpipeliningを使用することです:
HSET data:address timestamp <VALUE>
HSET data:address value <VALUE>
になります。残念ながら、 - pipeオプションに頼る以外は、redis-cliからは使用できません。このオプションでは、テキストコマンドの代わりに実際のRedisプロトコルを生成する必要があります。だから、 "cat data.txt | redis-cli --pipe"を使ったテストはうまくいかない。単純なシェルコマンドからRedis protocolを生成するのは便利ではありません。
redis-cliではなく、独自のクライアントプログラムを使用することを強くお勧めします。 Python、Ruby、またはJavascriptで書かれたものでさえ、パイプライン処理が使用されると、興味深いパフォーマンスが得られます。
PostgreSQLはどのくらいの期間かかりますか?リクエストをパイプライン化しようとしましたか?クライアントのオーバーヘッドはおそらく全体的な時間を削っているでしょう。 –
6秒(Redis)対16秒(PostgreSQL)です。私は 'cat data 'を試みました。txt | redis-cli --pipe'を実行してください。これはhttps://redis.io/topics/mass-insertで説明されているように、より合理的に見えます。しかし、上記のようなHSETステートメントは受け入れられず、代わりに構文エラーメッセージが表示されます。 – user318592009
エラーは何ですか? –