web-dev-qa-db-ja.com

MariaDB / MySQLにリアルタイムの時系列を保存するための最適なソリューションは何ですか?

使用例:測定により、指定された数の画像が作成されます。画像ごとに、画像の整数[1 ... N]、タイムスタンプ、および1つまたは2つの外部キー値とともに、品質インジケータ(float、double)の小さなセットを格納する必要があります。これは、ユーザーが評価できるように、Webアプリケーション(PHP)に「リアルタイム」でプロットする必要があります。

各Webクライアントは、5秒ごとにデータベースをポーリングします。ストレージ+品質指標の各セットの取得には、理想的には2秒未満(およそ)が必要です。最悪のシナリオでは、最大30のWebクライアントが同時にポーリングし、約10の測定が同時に書き込みを行う可能性があり、書き込みバーストが約100になる可能性があります。 1秒あたり1000セットの品質インジケータ。

プログラミング言語では、この種のデータはおそらく配列またはリストに格納されます。 MariaDB/MySQLの世界では似たようなことは何も知らないので、上記の各値の列を持つ通常のInnoDBテーブルを使用しています。これにはすでに9000万行以上あり、今後数か月でより速く成長すると予想されます。

InnoDBは全体としてこれに最適なストレージエンジンですか、それとも他のものを検討する必要がありますか?おそらくすべての測定の画像が処理された後で、しばらくしてからデータをアーカイブすることがベストプラクティスですか?圧縮を有効にするのに役立ちますか、それともパフォーマンスに非常に悪い影響がありますか?

4
dbdemon

MySQL/MariaDBだけで、以下を採用します。

  • 高速取り込み: http://mysql.rjweb.org/doc.php/staging_table
  • サマリーテーブル(データをより速く取得するため): http://mysql.rjweb.org/doc.php/summarytables
  • 生データの保存ではないことも考えます。代わりに、データを要約してから、それを投げます。これが実用的であれば、提起する質問のほとんどを回避できます。
  • (データのパージが必要な場合):古いデータをすばやく削除します: http://mysql.rjweb.org/doc.php/partitionmaint
  • オーバーヘッドが増えるため、FOREIGN KEYSは避けます。 (代わりに、SQLをデバッグします。)
  • 私はUUIDキーを使用しない;巨大なテーブルではパフォーマンスが著しく低下します。 ( http://mysql.rjweb.org/doc.php/uuid
  • 余分なインデックスは避けます-他の列が一意である場合はAUTO_INCREMENTを使用しないでください。
  • Spatialについて言及していますが、詳しく説明してください。 2Dルックアップはトリッキーです。 SPATIALは1つのアプローチです。ここに別のものがあります: http://mysql.rjweb.org/doc.php/latlng

あなたの最後の段落は、キッチンシンクの質問(Toku、MyRocks、アーカイブ、圧縮、履歴テーブル)を投げかけます。 「広すぎる」という理由で投稿が殺されていないことに驚いています。データとクエリについて詳しく説明してください。そうでなければ、私たちにできることは解決策でいっぱいの台所の流しを投げることです。

あなたは「リアルタイム」と言いますが、それでも「数千/秒」が必要です。リアルタイムで1分の遅延を許可できますか? 1秒?あなたはできません1msを取得します; 1を達成するのは難しいでしょう。バーストはどのくらい続きますか?毎分バーストとは何ですか? 1K /秒はおそらく次の数秒に波及します。 6K /分はそれほど問題ではありません。

いくつのクライアントがデータを保存していますか?一部のソリューションは、単一のクライアントで適切に機能します。複数のクライアントには異なるソリューションが必要です。

ベンチマークは1つのことを示すために調整されており、実際の生活と一致することはめったにないことに注意してください。

6
Rick James

非常に多くの依存関係があるので、おそらくここで達成できるよりも綿密な調査が必要ないくつかの大きな質問があります(これを知っていることを理解してください!)。 Percona LiveとPercona Live Europeのページには、時系列についてのプレゼンテーションからのスライドセットがいくつかあります。たとえば、YandexのClickHouseの使用について

https://www.percona.com/live/17/program/schedule/time-series

https://www.percona.com/live/e17/program-open-source-databases

また、いくつかのブログ投稿が興味深いかもしれません。これは時系列のベンチマークについて、TokuDBとInnoDBを比較しています。

https://www.percona.com/blog/2013/09/05/tokudb-vs-innodb-timeseries-insert-benchmark/

これはMongoDBとTokuMXを見るのに対して https://www.percona.com/blog/2015/05/26/storing-time-series-data-with-mongodb-and-tokumx/

これらの助けを願っています。

3