クライアントはリアルタイム データをサーバーに送信します。サーバーは、これらのデータを使用して簡単な分析を行います。特定の範囲のデータのみを検索するか、一部のデータを並べ替えます。ほとんどのデータは分析後に破棄されるため、ディスクに保存する必要はありません。
それらを処理するためにいくつかのメモリDBを使用したいと思います。MYSQL のメモリ エンジンは適切な選択ですか? Redis などのキー値メモリ キャッシュ エンジンを使用するとどうなりますか? データを比較する必要があるため、純粋なキー値ストアでは要件を満たせない可能性があります。
Redis などのキー値メモリ キャッシュ エンジンを使用するとどうなりますか?
Redis は高度なデータ構造をサポートしているため、非常に便利なキー値ベースのデータ ストアになります。ただし、データに複雑な関係が必要な場合は、メモリ ベースのストレージ エンジンをすべてサポートするMongoDB、OrientDBまたはRiakを確認する必要があります。
私には、データベースがないほうがよいように思えますが、それはデータの構造と、実行する必要がある操作の種類によって異なります。
構造が単純で操作が簡単な場合は、おそらく使用しているプログラミング プラットフォームのデータ構造にデータを格納する必要があります。
MySQL のメモリ エンジンを使用する場合は、いくつかの落とし穴があります。
デフォルトでは、インデックスは btree ではなくハッシュ テーブルを使用して実装されます。データを並べ替える必要がある場合、または範囲のサポートが必要な場合は、btree を使用する方が興味深い場合があります。
ロックの粒度はテーブルです。同時 DML 操作から保護するための R/W ロックがあります。生のパフォーマンスは悪くありませんが、同時に多くのライターがある場合、スケーラビリティはあまり良くありません。
すべての行は固定幅です (varchar を格納する必要がある場合は注意してください ...)
さらに、他のほとんどの RDBMS と同様に、MySQL プロトコルは同期的です。クライアントがデータベースに書き込むたびに、応答を待ちます。大量のデータがある場合、良好なパフォーマンスを得るには、書き込み操作のバッチ処理がほぼ必須です。
これは、ボリューム、クライアント数、およびスループットに大きく依存します。要件が低ければ、どのストレージ ソリューション (MySQL を含む) でも問題なく機能します。より高いパフォーマンスやスケーラビリティが必要な場合は、他のソリューションの方が優れている可能性があります。
あなたが書きたいのは、おそらく DIRT アプリケーション (データ集約型リアルタイム) です。これに適したストレージ ソリューションは、MongoDB (アップサートのサポート、書き込み操作の一方向プロトコルなど) と Redis (インメモリ、O(1) 操作、パイプラインなど) です。ニーズによっては、MongoDB を使用すると、btree インデックスと map/reduce がサポートされているため、データのモデリングと処理がほぼ間違いなく簡単になります。Redis ではおそらくもう少し複雑になりますが、正しいデータ構造を選択すると、より決定論的なパフォーマンスが得られます。
最後に、オンザフライで処理してデータを保存することを避けたい場合もあります。これは、高速取引プラットフォームで使用されるようなストリーミング エンジンで実現できます。たとえば、Java でコーディングする準備ができている場合、ESPERは、データ ストリームを処理したり、SQL に似た言語を使用してストリーム間の相関関係を確立したりするための優れた CEP ソリューションです。