答えの多くは、収集した後に何をしたいかによって異なります。大量のデータを保存するのは簡単です。ログ ファイルに書き込むだけで、データベースは必要ありません。一方、複雑な分析やデータ マイニングを実行する場合は、データベースが役に立ちます。
次の質問は、どのような分析を行うかです。特定のプロパティを持つデータのサブセットに対して実行されますか? 過去の時間/日/週/月のみ、データを集約または事前に計算できますか? つまり、収集された形式でデータセット全体にアクセスする必要がありますか? 古くなりすぎて面白くなくなったデータをアーカイブできますか? データを集計し、集計に対して分析を実行できますか?
広告分析 (広告露出に関する数十億のデータ ポイントを収集する) を扱った私の経験では、集計が重要です。生データを収集し、サニタイズしてから、MongoDB、Cassandra、さらには MySQL などのデータベースに配置して、更新やクエリを実行できます。次に、データを定期的に集計し、データベースから削除します (ただし、生データはアーカイブします。後で必要になる場合があります)。
集計では、基本的に、データについて尋ねたいすべての質問を行い、特定の質問に対する回答を簡単に取得できる形式でデータを保存します。X が最も多い曜日を知りたいとします。これの単純な実装は、記録されたすべての信号を巨大なテーブルに保持し、X を含むすべての行を合計するクエリを実行することです。信号が大きくなると、このクエリはますます時間がかかります。これには、いくらインデックス作成、シャーディング、または最適化を行っても役に立ちません。代わりに、毎日、毎時、毎分 (正確なユース ケースと、レポートをどの程度最新にする必要があるかによって異なります)、記録した新しいシグナルを確認し、X ごとに、その数を追跡するカウンターをインクリメントします。 X 月曜日なら月曜日、火曜日なら火曜日など。そうすれば、後で曜日ごとにカウントを取得して比較できます。回答できるようにしたいすべての質問に対してこれを行い、データベースから信号を削除します (ただし、生データは保持します)。
集計を記録するデータベースの種類は、着信信号を保存するものと同じにすることができますが、それほど凝ったものである必要はありません。特定の回答を表すキーと、通常は単なる数値である値を格納します。
古い学校のデータ ウェアハウスでは、入力信号を格納するデータベースは OLTP (オンライン トランザクション処理用) と呼ばれ、集計を格納するデータベースは OLAP (オンライン分析処理用) と呼ばれます。OLTP は挿入用に最適化されており、OLAP はクエリ用に最適化されています。この用語は古く、人々がそれらを聞くとすぐに SQL やスタースキーマなどを思い浮かべる傾向があります。使うべきではないかもしれませんが、便利な用語です。
とにかく、OLTP には、データをすばやく挿入できるだけでなく、データのインデックス作成と検索をサポートするものが必要です。集計は、合計と最大値と最小値の検索の半分の作業をデータベースが行うことで大幅に支援されます。MongoDB はとても簡単にセットアップして操作できるので、とても気に入っています。私が扱っているデータは乱雑になりがちで、すべてのアイテムが同じプロパティ セットを持っているわけではないため、Mongo の寛容なスキーマレスは恩恵です。一方、あなたのデータははるかに均一に聞こえるので、Mongo はおそらくそれほど多くの利益をもたらさないでしょう. ただし、古き良きリレーショナル データベースを見逃さないでください。多くの合計などを行う場合は、SQL が最適です。そのために構築されています。
OLAP の場合は、はるかに簡単に機能します。必要なのはキー値ストアだけです。私は Redis を使用しています。Redis も操作とセットアップが非常に簡単だからです。また、スカラー値以外も格納できるので便利です。値が実際にはリストまたはハッシュである場合があり、ほとんどのキー値ストアではそのような値をエンコードする必要がありますが、Redis はそれをネイティブに処理します。Redis の欠点は、クエリを実行できないことです (「Y に対してこの値を持つすべての行を教えてください」など)。データのインデックスを自分で保持する必要があります。一方、すべての質問に対する回答は事前に計算されているため、インデックスはあまり必要ありません。質問によって定義されたキーで回答を検索するだけで済みます。上記の質問では、どの曜日に X が最も多いかを調べます。月曜日、火曜日などの X 勤務の数を調べます。おそらくあなたは'
結論として、MongoDB と Redis は私にとって非常にうまく機能します。MongoDB はあなたのユースケースにはあまり適していないと思いますが、代わりに、実際には従来の SQL データベースからより多くの恩恵を受ける可能性があると思います (ただし、データが本当に単純な場合は、Redis をずっと使用できる可能性があります)。最も重要なことは、データを 1 つのデータベースに保持し、それを永久に保持する必要があると誤解しないことです。古いデータの集約と廃棄が重要です。