Vertipaq でのデータ インデックス作成: 行ストアと列ストア

このチュートリアルでは、リレーショナル データベースと Vertipaq でのデータ インデックス作成の仕組みの違いについて説明します。

リレーショナル データベースはデータを行ごとに保存します。一方、Vertipaq は列ごとにそれを実行します。

データの保存とインデックス付けに関するこれら 2 つの方法が、特にクエリの実行時にレポート開発プロセスにどのような影響を与えるかを見てみましょう。

目次

• 行ごとのデータインデックス作成
• 列ごとのデータインデックス作成
• 単純なクエリの実行時間の比較
• より複雑なクエリの実行時間の比較
• 結論

行ごとのデータインデックス作成

データを行ごとに保存するのが従来のデータ保存方法です。ただし、このプロセスには時間がかかるため、クエリのパフォーマンスに影響します。

ブランド、色、性別、数量、正味価格を含むテーブルがあるとします。

このテーブルのすべてをデータベースに保存すると、データは行ごとに保存されます。従来のデータ ストレージ構造が行ストアとも呼ばれるのはこのためです。

まず、同じ行に、最初の行にある列ヘッダー (ブランド、色、性別、数量、正味価格) が保存されます。次に、次の行に進み、各列の最初の項目 (A. Datum、Azure、空白、1、および 103.2) を保存します。これを行ごとに続けます。

では、このデータ インデックス付け方法を使用して、数量のをどのように計算するのでしょうか?

まず、列ヘッダーを含む最初の行から開始します。次に、次の行にジャンプし、最初に表示される量 (1) に到達するまで他のデータをスキップします。次に、行から行にジャンプして、各行に含まれるすべてのデータを調べて、すべてのデータを収集します。数量が見つかります。

各行のすべての数量が脇に置かれたら、それが計算が完了する唯一の時間です。

SQL データ ソースへの DirectQuery 接続を使用する LuckyTemplates レポートを準備している場合、そのプロセスがどれほど面倒か想像できるでしょう。この場合、分析サービスは DAX コードを SQL 言語に変換し、データ構造を行ごとに調べ始めます。

列ごとのデータインデックス作成

時間がかかるプロセスを回避するために、インポート モードを選択するときに、Vertipaq を介して列ごとにデータを保存するオプションがあります。

行ストアの代わりに列ストアを使用すると、ブランド、色、性別、数量、正味価格がそれぞれ異なるデータ構造に保存されます。

「数量」列の値の合計を取得したいとします。ブランド、色、数量列以外のその他のデータを渡す必要はありません。1 回のスキャンで、数量列全体を上から下まで読み取り、すべての値を合計します。

このため、クエリは左から右に実行する場合と比べてより速く実行されます。

単純なクエリの実行時間の比較

行ストアと列ストアの大きな違いを実際に確認するために、SQL と Vertipaq の両方でいくつかのテスト クエリを実行してみましょう。実行時間は、あるプロセスが他のプロセスと比較してどれくらい速いかを示します。

SQL での単純なクエリから始めましょう。Sales テーブルの Quantity 列の SUM を計算します。

ご覧のとおり、合計実行時間は 2.2 秒です。

ここで、DAX Studio に移動し、EVALUATE関数を使用して同じクエリを実行してみましょう。サーバーのタイミングをオンにして、トレースが完了するまで待つ必要があります。

また、クエリを実行するときに「キャッシュをクリアしてから実行する」オプションが選択されていることを確認する必要もあります。

クエリが実行されると、先ほど SQL で実行したのと同じクエリを完了するのに 3 ミリ秒しかかからないことがわかります。

結果セットも SQL と DAX Studio の両方で一致する必要があります。並べてみると、同じ値が返されていることがわかります。

クエリをさらに数回実行して、実行時間がどの程度一貫しているかを確認できます。

より複雑なクエリの実行時間の比較

今回は、より複雑なクエリを実行した場合の実行時間を比較してみましょう。

各ブランドの販売数量の合計を特定したいとします。これを行うには、各製品のブランドのに対して使用します。ローコンテキストでは、販売数量の合計を

このコードを実行すると、合計実行時間が 7 ミリ秒であることがわかります。

このコードはバックグラウンドで実際に 2 つのクエリを実行しています。最初の例では、Products テーブルから Brand 列を取得し、次にSales 列と Products 列の両方の Product Key 列に対して OUTER JOINを実行します。

2 番目のクエリは単に Products テーブルから Brand 列を取得します。

結果画面に移動すると、合計数量メジャーが各ブランドに基づいて分割されていることがわかります。

次に、SQL サーバーに移動して、同じクエリを作成してみましょう。

DaxStudio Sales テーブルを次の行にプッシュし、Sales テーブル AS S を参照します。次に、 S.Product Key と等しい AS P で参照される DaxStudio Products テーブルでLEFT JOINも実行します。P.プロダクトキー。また、 SELECTステートメントで Quantity と Total Quantity のSUMを指定して P.Brand を使用します。を使用します。

このコードを実行すると、各ブランドごとに分離された合計数量を含むテーブルが取得されます。これは、以前に Vertipaq で取得したものと同じです。

合計実行時間に関しては、依然として 2.5 秒とはるかに遅いです。

LuckyTemplates の DAX: DAX Studio での数式エンジンを使用した最適化
DAX クエリの最適化テクニックとレッスン
クエリのパフォーマンスと DAX Studio のセットアップ

結論

SQL データベースの行ストアと比較して、Vertipaq による列ストアが実際にどれほど高速であるかは明らかです。これは、さまざまなプラットフォームを通じてデータのインデックス作成がどのように機能するかを実際に知ることが重要であることを示しています。

行ストアがクエリを実行する時間を 7 ミリ秒ではなく 2.5 秒にすることを選択した場合、最初は小さな犠牲のように思えるかもしれません。しかし、誰もがレポートを作成するときにいくつかのクエリを実行し、それらの実行時間はすべて加算され、長期的には生産性とユーザー エクスペリエンスに影響を与えます。