MySQL Heatwave Lakehouse を試してみた

この記事は最終更新から1年以上経過しています。内容が古くなっている可能性があります。

MySQL Heatwave Lakehouse がリリース

昨年の年末よりいくつかのサイトではリリースされることが予告されていましたが、ようやく 2023-06-09 に 待望の MySQL Heatwave Lakehouse がリリースされたようです。

リリースノートはこちら:Release Notes

今回は、早速リリースされたばかりのMySQL Heatwave Lakehouseを試してみたいと思います。

目次

MySQL Heatwave Lakehouseについて

MySQL Heatwave Lakehouse では、MySQL Heatwave (MySQL Database Service) に追加された Lakehouse ストレージエンジン を使用して以下の機能を提供します。

  • オブジェクトストレージ上に配置された外部ファイルをMySQLテーブルとしてロード
    • 対応ファイルフォーマットは CSV、 Parquet、Aurora/Redshiftエクスポートファイル
  • 外部ファイルをロードすると、HeatWave ノードのストレージレイヤに保存され、その後メモリにロードされます。

環境の準備

MySQL Heatwave Lakehouseを試すには、以下の準備が必要です。

  • Lakehouseが有効な MySQL Heatwave の起動
  • MySQL Heatwave から Object Storageへのアクセス許可

Lakehouseが有効な MySQL Heatwave の起動

以下の手順に従い、MySQL Heatwaveノードの起動まで行います。

Creating a DB System
Adding a HeatWave Cluster

なお、現時点で MySQL Heatwave Lakehouse には以下の制限があります。

  • MySQL.HeatWave.VM.StandardおよびHeatWave.512GB シェイプでのみサポート
  • 高可用性構成では利用不可
  • ポイントインタイムリカバリ不可
  • リードレプリカの使用不可

コンソール、またはocicliでの作成時にこれらの要件を満たすように、設定を行う必要があります。

上記が満たされたインスタンスを起動すると、Heatwaveノードの追加時に 以下のように Lakehouseの有効化を選択できるようになります。

MySQL Heatwave から Object Storageへのアクセス許可

何らかの方法で MySQL Heatwave から Object Storage へのアクセスを許可する必要があります。

ドキュメントでは、Pre-Authenticated Request(PAR) によるオブジェクトストレージへのアクセス許可方法が案内されていますので、今回はこちらを使用します。

今回検証で利用する tpch_s1000 バケットには、TPC-H で作成した各種テーブルの.tblファイルが格納されており、それらに対してPARを作成しています。

なおドキュメントのPARの例ではオプションがありませんが、PARを使用してLakehouseストレージエンジンにデータをロードするために --bucket-listing-action ListObjects が必要なため追記しています。

https://dev.mysql.com/doc/heatwave/en/mys-hw-lakehouse-par-examples.html

以下のようにPARの一覧が取得できました。これはテーブルの作成時に使用します。

なお、PARは払い出されるURLを知っていれば誰でもアクセスできてしまうので、本番ではプリンシバルベースの許可方法の利用が推奨されています。

今回は詳しい手順は省かせて頂きますが、プリンシバルベースの許可方法については以下のドキュメントを参考に行います。

https://docs.oracle.com/en-us/iaas/Content/Identity/dynamicgroups/managingdynamicgroups.htm

Lakehouse ストレージエンジンで TPC-H してみる

早速Lakehouse ストレージエンジンを使って、TPC-Hしてみたいと思います。

外部ファイルのロード

Lakehouse ストレージエンジンを使用した外部表のCREATE TABLE構文は以下に記載されています。

https://dev.mysql.com/doc/heatwave/en/mys-hw-lakehouse-table-syntax.html

データをロードする方法として、Auto Parallel Loadと、手動でのデータローディング の2パターンがあります。

Auto Parallel Load は、ロード時のコマンドに、対象のファイル構造と、インポート先のDBを設定すれば、型推論によって半自動でテーブルを作成してくれる機能です。

早速やってみたいと思います。

クライアントに使用した Compute instance には mysql-shell 及び mysql-community-client をインストールしてあります。

各コマンドの構文は Lakehouse Auto Parallel Load で説明されています。

PARのURLは、 https://objectstorage.<region name>.oraclecloud.com/<PAR access-uri>/<filename> になります。
"tables" に TPC-Hのテーブルをすべて列挙してロードを実行しました。

ファイルサイズ的には合計1TB程度のデータでしたが、Heatwaveにロードする時点で最適化が行われ、見積もり上は 633.66 GiB となっています。

ロード時間の見積もりは 1.24h と出ています。
あれこれ考えずとも、事前にこういった情報が確認できるのは非常に嬉しいポイントです。

ロードに使用されたコマンドは以下で確認できます。

列名には、 自動的に col1 からの連番の名称が設定されています。型推論によって、列データの内容に沿った型が自動的に設定されているのは素晴らしいと思いました。

なお、ロードに使用されるコマンドは sys.heatwave_load() を dryrun モードで実行する事でも確認できます。

実運用では、dryrunモードで取得したロードスクリプトをもとに、適切な列名を設定して手動でテーブルを作成する、という流れが一般的になるのではと思います。

ということで、列名が colN だとTPC-Hが実行できないため、一旦 DROP DATABASE しました。

TPC-Hの実行

実行するSQLについては、 HeatWave TPC-H をありがたく利用させていただきました。

この公開ベンチマークスクリプトには create_tables_lakehouse.sql という専用のテーブル作成スクリプトが同梱されています。

ENGINE_ATTRIBUTE の箇所を修正するだけで使用する事ができます。
なお、ENGINE=datalake となっている箇所は現時点ではENGINE=lakehouseに書き換えが必要です

以下のように修正します。

全テーブルを作成し、データをロードします。

以下のようにTPC-Hを実行し、実行速度を測定してみました。

Heatwave(RAPID) ストレージエンジンの場合と比較してみた結果、以下のようになりました。
結果は、各SQLごとに5回実行した平均値(秒)になります。

想定ではLakehouseストレージエンジンのほうがかなり遅いと考えていましたが、RAPIDストレージエンジンと比較してもレスポンスタイムは遜色なく、場合によっては高速であるケースもある事がわかりました。

Lakehouseストレージエンジンの制限

最後にドキュメントをもとに、2023-06-21現在での MySQL Heatwave Lakehouse の制限について確認しておきましょう。

https://dev.mysql.com/doc/heatwave/en/mys-hw-lakehouse-limitations.html

  • クエリによってはHeatWave Lakehouseによって高速化できない場合がある
  • ファイルに含まれるすべてのNAN値をNULLに置き換える必要がある
  • dumpInstance() などのMySQL Shellエクスポートユーティリティを使用して外部テーブルをダンプすることはできない
    • このため、上記の処理時にはexcludeTablesオプションにlakehouseテーブルを列挙する必要がある
  • 1行あたり4 MBを超えるCSVファイルはサポートされていない
  • Lakehouse対応DBシステムからスタンドアロンDBシステムにバックアップを復元することはできない
  • Lakehouseテーブルにについて以下は実行できない
    • DMLステートメント
    • 一時テーブルの作成
    • AUTO_INCREMENTカラムの作成
    • トリガーの作成
    • ANALYZE TABLEの実行
    • インデックスの作成
    • ALTER TABLE ADD/DROP COLUMN
    • CHECK制約
    • 一意制約の強制
    • GROUP BY句の結果に影響
    • STORAGE句を含む任意のステートメントの実行
  • 次のシェイプのみをサポートする → MySQL.HeatWave.VM.StandardMySQL.HeatWave.512
  • ポイントインタイムリカバリ機能の使用はできない
  • 高可用性構成の使用はできない
  • リードレプリカの使用はできない
  • アウトバウンドレプリケーション機能の使用はできない

現状の制限からは、MySQL Heatwave Lakehouseを使用する場合は、ある程度データレイク専用の用途として運用するのが良いように見えます。

まとめ

今回、MySQL Heatwave Lakehouseを使ってみて、簡単かつ高速であることを確認できました。

データレイク領域まで、MySQLクライアントでアクセスできるようになり、MySQLの便利さはとどまることを知らないようです。

現在 MySQL Heatwave はマルチクラウド対応や高可用性構成でのRAPIDストレージエンジンの対応、MySQL Enterprise Editionの機能の統合、機械学習 など非常に活発に開発が進んでいます。

ぜひMySQL Heatwave Lakehouseをお試しください!

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃OCIのサポート業務に従事している有資格者で構成された技術サポートチームがOCIに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

よかったらシェアしてね!
  • URLをコピーしました!
目次