7

シナリオは非常に単純です。10 列 (一種の分析データ) を持つテーブルに約 1 億のレコードがあり、それらの 10 列の任意の組み合わせに対してクエリを実行できる必要があります。たとえば、次のようなものです。

  • a = 3 && b > 100過去 3 か月間にのレコードはいくつありますか?

基本的に、すべてのクエリは、時間間隔内に属性を持つレコードがいくつあるかXYXというようなものになり、これらの 10 列を任意に組み合わせることができます。

データは継続的に入ってきます。それは、事前に与えられた 1 億レコードのセットではなく、時間の経過とともに増加しています。

列の選択は完全にランダムになる可能性があるため、一般的な組み合わせのインデックスを作成することはほとんど不可能です。

質問には 2 つの部分があります。

  • クエリをできるだけ高速にするには、SQL データベースでこれをどのように構築する必要がありますか?また、パフォーマンスを向上させるために実行できる一般的な手順は何ですか?
  • この種の検索用に最適化された NoSQL データベースはありますか? 考えられるのは ElasticSearch だけですが、この大規模なデータ セットでうまく機能するかどうかはわかりません。
4

6 に答える 6

1

インデックスがないと、この種の処理をサポートするように RDBMS を調整するオプションが大幅に制限されます。基本的に、大規模な並列処理と超高速キットが必要です。しかし、明らかに実際のデータを格納していないため、RDBMS は適切ではありません。

並行路線を追求し、業界標準となっているのがHadoopです。Hiveを介して SQL スタイルのクエリを引き続き使用できます。

もう 1 つの noSQL オプションは、カラムナ データベースを検討することです。これらは、キューブを使用せずに分析用のデータを編成する代替方法です。データを高速にロードするのが得意です。Vectorwise は、この分野における最新のプレーヤーです。個人的には使ったことはありませんが、昨夜の LondonData ミートアップで、ある人がそれについて絶賛していました。 それをチェックしてください。

もちろん、SQL データベースから離れることは、どの方向に進んでも、学習曲線が急勾配になります。

于 2012-04-27T09:38:07.910 に答える
0

データからOLAPキューブを作成できない場合は、代わりにXとYの一意の組み合わせに基づいてサマリーテーブルを作成できます。期間Yの粒度が十分に高い場合、サマリーテーブルはかなり小さい可能性があります。明らかにデータに依存します。

また、ユーザーが実行するクエリをキャプチャする必要があります。一般的に、ユーザーは可能な限りすべての組み合わせが必要だと言っていますが、実際にはこれが起こることはめったになく、ほとんどのユーザーのクエリは事前に計算された結果から満たすことができます。要約テーブルはここでもオプションになります。このオプションを使用するとデータの待ち時間がいくらか得られますが、機能する可能性があります。

可能であれば、他のオプションはハードウェアを調べることです。私は過去にFusion-IOなどのソリッドステートドライブを使用して良い結果を出しました。これにより、クエリ時間を大幅に短縮できます。これは優れた設計に代わるものではありませんが、優れた設計と適切なハードウェアがあればうまく機能します。

于 2012-05-29T09:40:41.600 に答える
0

Oracleに関する限り、これは、クエリを実行する可能性のある各列にローカルビットマップインデックスがあり、ダイレクトパス挿入またはパーティション交換のいずれかを介して新しいデータが追加される間隔パーティションテーブルとして構造化される可能性があります。

列の一般的な組み合わせのクエリは、マテリアライズドビューのセットを使用して最適化できます。ロールアップクエリまたはキューブクエリを使用することもできます。

于 2012-04-27T13:30:26.173 に答える
0

SQL ソリューションを使用してこれらのクエリを高速に実行するには、次の経験則を使用します。ただし、これには多くの注意点があり、使用している実際の SQL エンジンはソリューションに非常に関連しています。

あなたのデータは整数、日付、または短いスケーラーであると想定しています。長い弦などでゲームが変わります。また、固定比較 (=、<、>、<> など) のみを使用していると仮定しています。

a) 時間間隔 Y がすべてのクエリに存在する場合は、Y 述語が大量の行を選択していない限り、インデックスが作成されていることを確認してください。行がディスク上で隣り合ってパックされるように、行が「Y」の順序で格納されていることを確認してください。いずれにせよ、これは新しいデータに対して時間の経過とともに自然に発生します。Y 述語が非常に狭い場合 (つまり、数百行) は、これだけで十分です。

b) 「select 」または「select count( )」を実行していますか? 「select *」でない場合、存在するエンジンやその他のインデックスによっては、垂直パーティショニングが役立つ場合があります。

c) 値が広く分散し、重複が多すぎない列ごとに単一列インデックスを作成します。インデックス YEAR_OF_BIRTH は通常問題ありませんが、FEMALE_OR_MALE のインデックス作成は多くの場合適切ではありません - これはデータベース エンジンに大きく依存しますが。

d) FEMALE_OR_MALE のような列があり、「Y 述語」が広い場合、別の問題があります。ほとんどの行から女性の数を選択するのは困難です。インデックス作成を試すことができますが、エンジンによって異なります。

e) 可能であれば、列を「NOT NULL」にしてみてください。通常、行ごとに 1 ビットを節約し、内部オプティマイザ操作を簡素化できます。

f) 更新/挿入。インデックスを作成すると挿入のパフォーマンスが低下することがよくありますが、レートが十分に低い場合は問題にならない可能性があります。1 億行しかないので、挿入率はかなり低いと思います。

g) マルチセグメント キーは役に立ちますが、あなたはすでにそれはダメだと言っています。

h) 高速ディスク (RPM) を取得します。通常、これらのタイプのクエリの問題は IO です (TPC-H ベンチマークは IO に関するものであり、「H」の問題のように聞こえます)。

他にも多くのオプションがありますが、「クエリをできるだけ高速にする」ためにどれだけの労力を費やしたいかによって異なります。これを解決するためのNo-SQLやその他のオプションはたくさんありますが、質問のその部分は他の人に任せます.

于 2012-05-01T02:19:25.320 に答える
0

上記の提案に加えて、更新されたマテリアライズド ビューのクエリのみを検討してください。テーブルに select ,count(*) group by cube () マテリアライズドビューを作成するだけだと思います。

これにより、操作する完全な立方体が得られます。小さなテスト テーブルでこれを試して、キューブ ロールアップがどのように機能するかを感じてください。いくつかの例については、Joe Celko の本を参照するか、特定の RDBMS ドキュメントを参照してください。

テーブル内の最新のマイクロ秒データを常にクエリできる必要がある場合は、少し行き詰まります。しかし、その要件を緩和することができれば、マテリアライズド ビュー キューブが適切な選択肢であることがわかります。

ユーザーが 10 列すべてを均一にヒットするという確信はありますか? 私は過去に、この種の状況で時期尚早な最適化を行ったことがありますが、実際にはユーザーがほとんどのレポートで 1 つまたは 2 つの列を使用し、それらの 1 つまたは 2 つの列にロールアップするだけで「十分」であることがわかりました。

于 2012-05-19T20:52:52.790 に答える
0

SSAS キューブを作成し、MDX を使用してクエリを実行する必要があります。

キューブには「集計」ウィッチがあり、事前に計算された結果を意味します。キューブ (および集計) の構成方法に応じて、メジャー グループに SUM 属性 (たとえば、A) を設定し、キューブにどのように問い合わせるかを毎回指定できます。多くのレコード A がある場合、すべてのテーブルを読み取って計算するのではなく、集計を読み取るだけです。

于 2012-04-27T08:06:00.970 に答える