1

私が所有するシステムに大量の受信データ セットがあるという要件があります。

このセット内のデータの 1 つの単位には、不変の属性と状態のセットが関連付けられています。状態は動的で、いつでも変更できます。

要件は次のとおりです-

  1. 大規模なデータ セットでは、状態が変化する可能性があります。更新は高速である必要があります。
  2. さまざまな属性にピボットされたデータを集約できるはずです。
  3. 理想的には、個々のデータ ユニットを集計結果に関連付ける方法が必要です。つまり、特定の集計を生成した特定のトランザクションにドリルダウンしたいと考えています。(集約が実行された後にデータユニットの状態が変化するなど、ここでの競合状態は認識していますが、これは予想されることです)。
  4. すべての集計は時間ベースです。つまり、1 日、2 日、1 週間、1 か月などのピボット y での x の合計です。

これらのユースケースを満たすためにさまざまなテクノロジーを評価しており、あなたの提案を聞きたいと思っています。分析/集計のユース ケースに適合する Hive/Pig を調べました。ただし、いつでもシステムに大量の更新が入る可能性があることを懸念しています。インデックス付きデータベース (sql または nosql) と比較した場合、これが HDFS ファイルでどのように機能するかはわかりません。

4

2 に答える 2

0

Flexviewsを見ることを検討してください。MySQL のインクリメンタル リフレッシュ可能なマテリアライズド ビューの作成をサポートします。マテリアライズド ビューは、変更されたデータで定期的に更新されるクエリのスナップショットのようなものです。マテリアライズド ビューを使用して、異なるサマリー テーブルの複数の属性を要約し、これらのビューのトランザクションの一貫性を保つことができます。slideshare.netで機能を説明するいくつかのスライドを見つけることができます。

InnoDB および MySQL パーティショニングと組み合わせて使用​​できるShard-Queryもあり、多数のマシンへのデータの分散をサポートします。これにより、高い更新レートが満たされ、クエリの並列処理が提供されて高速な集計が行われます。

もちろん、2つを組み合わせることもできます。

于 2011-05-08T07:11:42.130 に答える
0

おそらく、環境内の実際のシナリオでストレス テストを行うことによってのみ、最適なソリューションにたどり着くことができますが、いくつかの提案があります。まず、書き込み速度がボトルネックの場合は、不変データとは別に、変化する状態を追加専用ストアに書き込み、クエリのためにデータを再度結合することが理にかなっている場合があります。追加のみの書き込み (ログ ファイルなど) は、主にディスク シークを最小限に抑えるため、既存のレコードを更新するよりも高速です。この戦略は、クエリ中にデータが変更されるという問題にも役立ちます。時間内の「スナップショット」に対してクエリを実行できます。たとえば、HBase はタイムスタンプ付きの複数の更新をレコードに保持します。(数は設定可能です。)

これは、Multiversion Concurrency Control - MVCC と呼ばれる永続化戦略の特殊なケースです。あなたの説明に基づいて、更新が同時に行われている間でも、MVCC はおそらくクエリを実行し、一貫した状態情報を返すための最も重要な基本戦略です。

もちろん、このように分割されたデータを結合すると、クエリのパフォーマンスが低下します。そのため、クエリのパフォーマンスがより重要な場合は、状態の変化とともに不変データが繰り返されるレコード全体を書き込むことを検討してください。トレードオフとして、それはより多くのスペースを消費します。

于 2011-04-09T15:09:02.057 に答える