2022.3 のカラムナーストレージ

Global Summit 2022 または 2022.2 ローンチウェビナーの内容からよく覚えていると思いますが、InterSystems IRIS の分析ソリューションに組み込むための目覚ましい新機能をリリースしようとしています。 分析クエリを桁違いに高速化する、代替の SQL テーブルデータ格納手法であるカラムナー(列指向)ストレージです。 もともと 2022.2 の実験的機能としてリリースされましたが、最新の 2022.3 開発者プレビューには多数の更新が含まれているため、別途ここで簡単に説明したいと思います。

簡単な要約

カラムナーストレージにあまり詳しくない方は、こちらの簡単な紹介動画かこの件に関する GS2022 セッションをご覧ください。 手短に言うと、新しい $vector データ型を用いて、列ごとに 64k チャンクでテーブルデータをエンコーディングしています。 $vector は、疎データと密データの両方を効率的に格納できるように、アダプティブエンコーディングスキームを利用する（現時点では）内部専用のデータ型です。 エンコーディングは、一度に 64k チャンク全体の集計、グループ化、およびフィルタを計算し、可能な場合は SIMD 命令を利用するなどの、一連の専用の $vector 演算にも最適化されています。 

SQL クエリ時に、これらのチャンクに対しても動作するクエリプランを作成して、これらの演算を利用します。想像できるように、従来の行単位での処理に比べ、これによってクエリを実行するための IO の量と ObjectScript 命令の数が大幅に削減されます。 もちろん、行指向における単一値演算に比べれば、個別の IO はより大きく、$vector 演算は多少重くなりますが、非常に大きなメリットがあります。 $vector データを処理し、チャンク全体を一連の高速な個々の演算にプッシュする実行戦略を「ベクトル化された」クエリプランと呼んでいます

とにかく速い

最も重要なのは、すべてが高速化されたことです。 列インデックスに関するオプティマイザの理解が深まったことで、リクエストされたフィールドの一部が列インデックスまたはデータマップに格納されていない場合であっても、より多くのクエリが列インデックスを使用するようになります。 また、多くのケースで列インデックスとビットマップインデックスが組み合わせられるようになります。これは、列インデックスを既存のスキーマに追加することから始める場合に役立ちます。

新しいキットには、いくつかのクエリ処理の機能強化に対する低レベルの $vector 演算の最適化から並列化できるより広範な一連のベクトル化されたクエリプランまで、パフォーマンスを改善する多数の変更がスタック全体に含められています。 INSERT .. SELECT ステートメントなどによる特定のデータ読み込み方法も インデックスの構築にすでに使用しているバッファリングされたモデルを採用し、テーブル全体を非常に高いパフォーマンスで構築できるようになっています。

ベクトル化された JOIN

このリリースで追加された最も注目すべき機能は、ベクトル化の方法による列データの JOIN のサポートです。 2022.2 では、クエリ内で 2 つのテーブルからデータを結合する場合、列編成のデータでも行編成のデータでも機能する堅牢な行単位の JOIN 戦略に頼っていました。 今回は、JOIN の両端が列形式で格納されている場合、新しいカーネル API を使用して、メモリ内で JOIN し、$vector 形式を保持することができるようになっています。 これは最も複雑なクエリであっても完全にベクトル化されたクエリプランにするもう 1 つの重要なステップです。

以下に、新しい関数を利用するクエリの例を示します。前のデモで使用した New York Taxi データセットの自己結合を行っています。

SELECT 
   COUNT(*), 
   MAX(r1.total_amount - r2.total_amount) 
FROM
   NYTaxi.Rides r1, 
   NYTaxi.Rides r2
WHERE 
   r1.DOLocationID = r2.PULocationID 
   AND r1.tpep_dropoff_datetime = r2.tpep_pickup_datetime 
   AND r2.DOLocationID = r1.PULocationID 
   AND r1.passenger_count > 2 
   AND r2.passenger_count > 2

このクエリは、乗客が 2 人を超えるルートのペアを検索します。2 番目のルートが最初のルートが終了する時点で同時刻に開始し、2 番目のルートが最初の開始地点に戻るルートペアです。 非常に有用な分析ではありませんが、このスキーマには実際のテーブルが 1 つしかなく、複合 JOIN キーのお陰で味気なさが少し緩和されています。 このステートメントのクエリプランには、Apply vector operation %VHASH（複合 JOIN キーの作成用）と Read vector-join temp-file A などのスニペットが含まれており、新しいベクトル化された結合が機能していることを示しています。 これは、長めのクエリプランにある小さく些細なもののように聞こえるかもしれませんが、内部では多くのスマートエンジニアリングが伴っています。このようなことをただ許可せず、スキーマレイアウトに厳しい制約を課す一般的なカラムナーデータベースベンダーがかなりの数存在しますので、ぜひ一緒にこれを楽しみましょう！ :-)

クエリプランがその一時ファイルの読み取りを続けると、Join 後の作業にまだ行単位の処理が残っていることに気づくかもしれません。そこで...

今後の予定

カラムナーストレージは 2022.3 でも「実験的」となっていますが、本番対応に近づいており、間もなくマルチテーブルクエリ用の完全なエンドツーエンドベクトル化が可能になります(訳注：2023.1では本番用としてリリースされています)。 これには、先ほど述べた JOIN 後の作業、クエリオプティマイザのより幅広いサポート、カラムナーテーブルの読み込みのさらなる高速化、共有メモリサポートなどの JOIN のさらなる機能強化などが含まれます。 要するに、今こそ、2022.3 Community Edition を使用して New York Taxi データセットを試してみる絶好の機会です（現時点では IPM で、または Docker スクリプトを使用）。そうすれば、2023.1 がリリースされる頃には「Run」を押すだけで済みます！

カラムナーストレージを独自のデータとクエリで使用する方法について、より具体的なアドバイスに興味のある方は、私かアカウントチームに直接ご連絡ください。Global Summit 2023 でお会いできるかもしれません ;-)