構築中。

名古屋のITインフラお守り係です。ITイベントへの参加記録などを残していきます。

HeatWavejp Meetup #13 祝 2 周年 HeatWave の 〇〇 やってみた!LT 大会!! LT 参加(4/17)

ちょっと遅くなりましたが LT 参加した報告を残しておきます。

heatwavejp.connpass.com

今回も諸々の都合でオンラインリモート参加です。

オープニングと HeatWave 概要紹介

リモート参加していて会場から聞こえてくる内藤さんの声が割れていましたw

タイムテーブルからはほぼ確実?に遅れるのは「仕様」です。

祝、🐬もほかのみんなも 30 歳!

出社時に引き取ってきました(ありがとうございます!)

MySQL 30 周年記念ノベルティ

開封です。

なお写真を撮るとき初めて T シャツの袋の中にステッカーが入っていることに気づきました。

最新アップデート情報

発表参加なので事前に聞いていましたが、公開されていたタイムテーブルから変更があって、オープニングと概要紹介の後は HeatWave の最新アップデート情報でした。

登壇するとき、

語彙が揺れがちで困るんですよね(今回も「HeatWave Cluster」だとわかりづらいと思って「HeatWave エンジン」にしたという経緯が)。

HeatWave のアップデート情報とは直接関係ないのですが、yoku0825 さんに拾っていただいたページを見て、「GoldenGate も ZeroETL とか言い出したのか」と気づいてしまいました。

HeatWave のアップデート情報(本体)はこっちです。

個人的には、

これ↑が結構影響あるかな、と。

テーブル全行中数行程度だけ 65532 バイトを超える TEXT 系の列があったときにわざわざセカンダリテーブルへのロード除外をしないといけないのが地味に面倒だったので。

(もっとも、集計に使わないのであれば除外しておいたほうが容量の節約にはなりますが)

各 LT

反応や自分の感想などを拾っておきます。

HeatWave の Autopilot Indexing を試してみた!

これ↑、まさに「HeatWave」が何を指してるかわからない問題そのもの、では…?

ネタ元ブログ記事です。

HeatWave on AWS のインバウンドレプリケーションHeatWave エンジン有効時のレプリケーションラグを確認してみた!

わたしのターンです。毎度ながらタイトルが長くてごめんなさい。

www.docswell.com

今回の LT の本題ではないのですが参考情報ということで。

あと、こちらも本題から外れるので当日は話しませんでしたが。

9.0.0 から HeatWave エンジン(HeatWave Cluster)側でクエリの並列実行ができるようになったのは良いけれど、何らかのリソースに対するロックの取り方が非効率なのか、並列で実行させると途中から各クエリの結果が返るタイミングがほぼ揃うようになり、結果として並列実行しないほうがクエリ処理時間の合計が短くなる、という罠があります。

これ、「クエリの並列実行ができるようになった」というのがドキュメントのどこに書かれているのか見つけられず(教えてもらって初めて知った)、ゆえに現時点で「9.0.0 以降で並列実行をさせない方法」が見つかっていないので、地味に厄介です。

(少なくとも 8.4 が現役のうちは 8.4.x を使い続ける予定なので、まだ時間的な猶予はありますが)

このあたりの話は追って Qiita か Zenn にでも軽くまとめます。


2025/4/23 追記:

記事を書きました。

qiita.com


処理が非同期だからといって MySQL DB(InnoDB)側のオーバーヘッドがないとは言っていないし、非同期だからこそ最終的に HeatWave エンジン(HeatWave Cluster)のデータが更新されるまでのタイムラグが気になるので確かめてみました、という話をしました。

あわせて MySQL DB(InnoDB)→ HeatWave エンジン(HeatWave Cluster)の遅延もほぼゼロ、でした。

ただ、更新データ容量が大きいケース、例えば 9.2.2 で制限が緩和された 65532 バイトを超える文字列のロードが頻発するようなことがあると状況が変わるかもしれませんね。

ちょうど先日の MySQL アンカンファレンスでも話題になりましたよね。

HeatWave MySQL で DB 監査ログ運用を実装してみた!

まあ性能がかなり改善された Aurora の監査ログも全然活用できていないわけですが…。

とはいえ「機密性は確保されても完全性・可用性に難がある」のは良くないので、

と思ったり。

正直、監査ログを「中継点で自由に加工しうる」のは良くないと思うんですよね(改ざん検知できれば別だけど)。

途中で「使いづらい」話がいろいろ出てきていたので。

HeatWave Lakehouse で 膨大になる csv データを必要な分だけロードしてデータ集計してみた!

いまどきのゲームは大人(かつての子供)が支えている?

ですね。

頼れるサポートは大事です。

HeatWave Lakehouse で オブジェクト・ストレージのデータ変換 / 加工ができるか試してみた!

こちらはサポートではなく AI に質問w

バージョン非互換で回答が混乱しているケースもありますが、それ以上にカオスになりそうw

これ↑に絡む話だったようです。

ブログ記事、ときどき説明を飛ばしている(で、読んで再現しようとして引っかかる人がたくさん出る)ことがあるので。

「INTO OUTFILE って結局入力だっけ出力だっけ?」って一瞬迷うのはわたしだけ?

「ロードマップに載ってからどうなるか」についての保証はない…?

直感的でない挙動(仕様)がある模様です。

HeatWave をオンプレの MySQL と同じように使おうとしてみた!

日々の覚書をチラチラ見て「あ、これは HeatWavejp の LT で話すやつだ」と思っていたらそのとおりでした。

speakerdeck.com

内藤さん曰く。

割と権限まわりで引っかかるとかあるんですよね。

HA の意味…?

AWS の旧 Elasticsearch Service(いまは本家をフォークして OpenSearch Service)もディスク容量周りのトラブルで動かなくなったことがありますから(結局サポートに直してもらった)。

過去に吉祥寺.pm で話したことがありますがこれはひどかったw

どんな本音だったかは内緒です。

クロージング

次回は GenAI 回だそうです。