現在、1000台のデバイス（クライアント）から一度にメッセージを受信するシステム（サーバー）があり、それぞれが1分に1回メッセージを送信します。
各メッセージには2000を超えるレコードが含まれます。
したがって、1分あたりシステムは1000 X 2000=>2,000,000レコードを受信します
同時に、頻繁な選択リクエスト（約1000）を期待しています
クエリは
この頻繁な一括挿入および読み取り操作を処理するためにデータベースサーバー（Mysql / postgres）をセットアップするための最良の方法は何ですか？
1000台のデバイスはどのように接続していますか？それぞれがサーバーへのTCP/IP接続を確立する場合は、接続先のマシンに十分なファイル記述子があることを確認する必要があります。/proc/sys/fs/file-max最大値を確認するために見てください。単一のサーバーマシンへの1,000のクライアント接続は、多数と見なされます。
各レコードにはどのくらいのデータがありますか？ネットワークハードウェアを圧倒しますか？各レコードが10バイトの場合、1秒あたり2,000万バイト、つまり1億6,000万ビットが着信することを意味します。100メガビット/秒のイーサネットインターフェイスでは、ほぼ十分ではありません。ギガビットインターフェイスでさえ疑わしいです：巨大なスループットを維持するのは難しいです。DBMSがデータを受信するサーバーとは別のマシン上にある場合、これらのレコードは出入りする必要があり、ネットワークスループットが2倍になることに注意してください。
DBMSまたはシステムの他の部分がワークロードで遅れる可能性をどのように処理しますか？INSERTコマンドを受け入れる際のDBMSによる時折の30秒の遅延は非常に可能ですが、その間に大量の未処理のデータが蓄積されます。
この問題を、おそらく50または100のデバイスのグループに分割し、データを収集する中央サーバーのセットアップを20または10に分割することを検討する必要があります。そうすれば、単一障害点が発生せず、ネットワークハードウェアを極端にプッシュすることはなく、ハードウェアを紛失した場合に、ある種のフェイルオーバー戦略を実行できる可能性があります。また、はるかに安価で費用対効果の高いサーバーおよびネットワーク機器を使用できるようになります。
MySQLでは、実行する必要のあるクエリをサポートするために、できるだけ少ないインデックスを使用します。サマリークエリ（などSELECT COUNT(*) FROM raw WHERE timestamp > NOW() - INTERVAL 1 HOUR）を実行すると、実行中のINSERT操作が大幅に遅くなる可能性があることに注意してください。
データフローを処理するために、ActiveMQなどのキューイングシステムの使用を検討することをお勧めします。
そこで、1Mの偽の行（1文字と1から1000000までのint）をバッチ処理し、ラップトップのpostgresqlの1つのトランザクションに挿入しました。4秒かかりました。1分間に100万回挿入するのは、少なくとも最初は簡単です。ただし、心配することはまだたくさんあります。たとえば、インデックスの更新にはコストがかかる可能性があります。整数フィールドに一意のインデックスを追加すると、挿入時間が4秒から9秒になりました。さらに100万行を挿入するには14秒かかりました。この数は、インデックスが大きくなるにつれて増加し続けます。インデックスがメモリに収まらなくなると、急上昇します。
多くの場合、これだけのデータを処理する最良の方法は、データを個別のテキストファイルに詰め込み、後でインデックスなしで一括アップロードすることです。次に、インデックスを追加します。
OllieがMySQLについての彼の回答で言及していることはすべて、他のほとんどのデータベースにも当てはまります。
PostgreSQL固有のもの：
接続プールと持続的接続を使用して、接続の総数を低く、たとえば100未満に保ちます。
FASTストレージメディアを使用します。ここでの問題は、大量のストレージが必要になる可能性が高いため、SSDが機能しない可能性があることです。回転するドライブを使用する必要がある場合は、最高のパフォーマンスと信頼性を実現するために、RAID-10のバッテリバックアップ式ハードウェアキャッシングを備えたRAIDコントローラの下に多数のドライブを配置します。RAID-5または6は、書き込みパフォーマンスがひどいため、ここでは災害になります。
できるだけ多くの書き込みをまとめてバッチ処理します。大規模なトランザクションを実行する一部のデータベースとは異なり、PostgreSQLはトランザクションで一度に1M以上の行を処理するのに非常に快適です。
必要な数のインデックスを使用してください。
通常、書き込みまたは読み取りのいずれかを最適化できますが、両方を最適化することはできません。したがって、この場合、テーブルのサイズを慎重にトリミングし、必要なインデックスのみを宣言し、それを高速マシンに配置することが、おそらく唯一のオプションです。データを長期間保持する必要がありますか、それとも古いデータをフラッシュできますか？そうしないと、テーブルが非常に大きくなります。