2

私はmysqlテーブルを作成し、毎秒1000台以上のデバイスのデータを受信して​​保存するAPIをコーディングしています。各デバイスは、100 を超えるデータポイントをこの PHP サーバーにプッシュします。それぞれ 10 個のデータポイントを持つ 360 台のデバイスをテストしていますが、1 秒あたり 3600 回の書き込みカウントでうまくいきました。ただし、デバイスの数が増えると、1 秒あたりの書き込み操作数が増加することに気付きました。1秒あたりの書き込み数の飽和点をグーグルで検索しようとしていますが、何も見つかりませんでした。1 秒あたりの最大書き込み回数はありますか? 書き込み回数が 1 秒あたり 10 万回に達したときのシステム パフォーマンスはどうですか。誰でもmysqlデータベースの専門家ですか、私にアドバイスしてください、ありがとう。

4

2 に答える 2

2

非常に限られたテスト ケースで高い数値を示すベンチマークを見つけることができる場合があります。しかし、「1 秒あたりの書き込み数」に影響を与える要因が多すぎます。

  • スピニングドライブ vs SSD、プラスブランドなど
  • レイド
  • 一括挿入 / LOAD DATA / 単一行挿入 / MyISAM
  • 索引の数
  • BEGIN...COMMIT / 自動コミット
  • 並行性 -- 複数の書き込みと同時読み取りの両方
  • 設定: innodb_flush_log_at_trx_commit、sync_binlog など
  • バージョン (5.6 ではいくつかの改善が行われました。5.7 ではさらに改善されました。MariaDB にはこれらの改善の一部とその他の改善が含まれています)
  • スキーマ
  • リソースを争うクライアントとサーバー
  • 等

5.7 で 1 秒あたり 100 万回の「トランザクション」を示すベンチマークについて聞いたことがあります。

しかし、100K を達成するのは非常に困難です。これが私が推奨するものです：

  • SSD (おそらく AWS に存在します。最大 IOP を取得します)
  • RAID ストライピング (パリティは多少のダメージを与えますが、おそらく持つ価値があります)
  • マルチスレッドの挿入を使用する場合、MyISAM はテーブルのロックのため、良い考えではないかもしれません。(この説明の残りの部分では、InnoDB を想定しています。)
  • データで何をしますか？個々の値を確認するためにSQLが必要ない場合は、100 個の値を JSON 文字列に格納し、それを BLOB に圧縮します。これで、ゆっくりと 1 秒あたり 1000 回の書き込みにまで落ちました。
  • FusionIO SSD が圧縮を行う場合があります。私は InnoDB の自動圧縮が好きではありません。クライアントでそれを行うと、サーバーの負荷が軽減されます。
  • インデックス: 膨大な量のデータを取得すると、インデックスのランダムな更新が致命的になります。PRIMARY KEYインサートが「テーブルの最後」になるように設計します。
  • バッチごとに 100 ～ 10,000 行を挿入します。これより少ないと間接費が発生します。それ以上にすると、アンドゥ ログのオーバーランなどの非効率性につながります。
  • innodb_flush_log_at_trx_commit=2、sync_binlogバッチ処理のために問題にならない場合があります。
  • 5.7、おそらく MariaDB 10.1
  • 必要に応じて、クライアントを別のサーバーに移動します。

おそらく複数のスレッドを使用して大量のデータを高速に収集する方法については、私のブログ「高速取り込み」を参照してください。1 つはデータの受信用、もう 1 つは処理 (正規化、圧縮、要約) 用であり、Fact テーブルへのシャベルです。

別の問題...毎秒数MBをテーブルにプッシュしようとしています。これは、1 日あたりほぼ 1 テラバイトにもなります。どのくらいの期間データを保持しますか? どのくらいのディスク容量がありますか? 「古い」データを削除する場合PARTITION BY RANGEは、必須です。私のパーティショニング ブログでは、非常に安価に削除を実行する方法について詳しく説明していますDROP PARTITION。REORGANIZE PARTITION

それは別の提案につながります - データを処理しますが、保存しないでください。OK、処理するのに 1 時間分のデータが必要かもしれません。この場合、上記のすべての議論が引き続き適用されます (INDEX制限を除く)。そして、私の高速摂取はおそらくまだやりがいがあります。1 時間に 1 回、卓球をすることもできます。1 時間は 10GB になる可能性があります。RAM に保持するのに十分なため、I/O のボトルネックを回避できます。

于 2016-02-23T16:37:56.250 に答える
1

また、プロビジョニングされた RDS の基礎となる EC2 インスタンスのサイズも考慮してください。

于 2016-02-24T15:13:17.007 に答える