3

複数のセグメンテーション (集約) の可能性がある生の (集約されていない) データを保存する必要があります。例: 日、時間、デバイスなど。少なくとも 6 つのセグメンテーション列があり、各列には平均 5 つの一意の値があります。そして、さまざまな範囲でこのデータの可能なすべての集計を管理する必要があります。

例:

  • 先月から日と時間でグループ化された columnX の合計が必要です
  • columnX の合計、月ごとにグループ化された columnY の平均、昨年のデバイスが必要です

生データでなければなりません。この要件により、1 か月あたり平均 1 億レコードが発生します。セグメンテーション列のすべての組み合わせに対して可能なすべての合計を保存する必要があったため、合計を保存することはできません。

このようなタスクに最適なデータベース エンジン/設計はどれですか? 当初、アプリケーションには MySQL データベースを選択しましたが、選択する際には、抽出に必要なデータ構造と統計について十分に認識していませんでした。それを知ったとき、私はテーブルのパーティション分割について考えましたが、私はそれに慣れておらず、さまざまな範囲のために本当に役立つかどうかわかりません。それが役に立たない場合、MySQL がこのタスクに失敗した場合、テーブルの設計に関係なく、どうすればよいでしょうか? たとえば、MongoDB のような非リレーショナル エンジンはありますか?

クエリの要件 - 2 ～ 3 秒以内。

データベースを処理するための会社のハードウェアリソースと思われます-高品質のサーバーがいくつかありますが、確かに数十または数百ではありません。

4

2 に答える 2

1

私が最もよく機能することがわかったのは、生データをどの種類のデータベースにも保存せず、それらのシステムでクエリしようとしているものの集計を保存することです。これに関連する理由は、生データが不格好であり、特に生データ全体が設定されている場合は、検索対象に関係なく、1日に1億行を超える可能性のある行を検索すると、大きな遅延の問題が発生します。ただし、ログファイルを集計して、必要な結果を生成することができます。

HTTPリクエストが機能するときにこれらのログを保存すること、または生のJSONファイルを保存するために何かを書くことでさえ、第2レベルを取得するのに役立つことがわかりました。

たとえば、デバイスグループを実行したいとします。Mongoを使用して、これを次の構造のようなものに集約できます。

{
    "_id": "20121005_siteKey_device",
    "hits": 512,
    "hours": {
        "0": 52,
        "1": 31
    }
} //mongo structure

または、さらに数分に集約したい場合：

{
    "_id": "20121005_siteKey_device",
    "hits": 512,
    "minutes": {
        "0": 52,
        "1": 31
        ...
        "3600":31
    }
}

これとは別に、はるかに小さいデータセットがある場合は、Redisの使用を検討できます。ここでこのリンクでピークを取ります：

Redisを使用したメトリクス

解決するのが楽しい問題にもかかわらず。幸運を！

于 2012-12-04T14:01:07.370 に答える
0

でグループ化された集計を保存できHour, Device, ...ます。言い換えれば、すべての興味深い次元でまとめてグループ化されます。明確な組み合わせがほとんどない場合 (あるとおっしゃいました)、この集計テーブルは小さくなります。その後、巨大なベース テーブルをスキャンする代わりに、集計をクエリできます (もちろん、再度集計します)。

NoSQL データベースは根本的に異なることを行うわけではないことに注意してください。このタスクでは、すべて同じ問題が発生します。テーブル全体をスキャンするか、集計を保存する必要があります。これは、SQL Server と NoSQL で同じです。

于 2012-12-04T14:06:37.313 に答える