5万
まとめ
- Open ElectricityはClickHouseを活用し、約10億件のレコードに及ぶオーストラリアのリアルタイムエネルギーデータを提供するオープンなプラットフォームとパブリックAPIを運用しています。
- PostgresおよびTimescaleDBからClickHouseへ移行したことで、クエリ速度が92倍向上し、ベンチマーククエリの実行時間は5分超からわずか3秒強へ、マテリアライズドビュー経由では60ミリ秒へと短縮されました。
- ClickHouseは、Postgresの16コア、32GB RAM、1.6TBディスクに対し、4コア、4GB RAM、200GBディスクという大幅に少ないハードウェアリソースかつわずかなコストで稼働しています。
オーストラリアの電力網で、目覚ましい変化が起きています。大規模な転換が進む中、同国のエネルギーシステムは世界で最も注視される存在の一つとなりました。
「20年前のグリッドは、かなり退屈なものでした」と、オーストラリアの電力転換を追究するオープンなプラットフォーム Open Electricity の開発者である Nik Cubrilovic 氏は語ります。当時、国内の発電施設は100基ほどで、石炭火力発電所、スノーウィー水力発電計画、そして一握りのガス火力発電所がある程度でした。「1年に1つの施設が新設されたり廃止されたりするくらいでした」と Nik 氏は言います。
2025年だけでも、オーストラリアでは40の新規施設が登録されました。しかも、グリッドは単に拡大しているだけではありません。「グリッドの構成自体も変化しています」と Nik 氏は述べ、これら新規施設の半分以上が蓄電池設備であることを強調します。「石炭火力発電所の設備容量が減少する一方で、蓄電池、太陽光発電、風力発電がまさに急伸しています」
1999年以降のオーストラリアの燃料種別発電設備容量。石炭 (黒および茶色) が減少する一方で、蓄電池 (濃い青)、太陽光 (黄色)、風力 (緑) が近年急増しています。
「これこそが、オーストラリア国内だけでなく、世界的にも私たちのグリッドが注目を集めている理由です」と Nik 氏は言います。「オーストラリアのエネルギーデータに関心を持つ規制当局や研究者は世界中に大勢おり、それに伴って生じる課題に私たちがどう適応しているかを見守っています」
2026年2月にメルボルンで開催された ClickHouse ミートアップ で、Nik 氏は Open Electricity がそのデータをどのようにアクセス可能にしているか、なぜ10億行を超えるデータを ClickHouse へ移行するに至ったのか、そして ClickHouse と Postgres の組み合わせが「魔法のようなペアリング」だと確信している理由について語りました。
10億行を超えてなお増加中
Open Electricity は、タスマニアからクイーンズランド北部までの東部諸州をカバーする NEM (全豪電力市場: National Electricity Market) と、西オーストラリア州の WEM (卸売電力市場: Wholesale Electricity Market) という2系統のグリッドからデータを取得しています。5分ごとに各発電ユニットが発電量を報告し、規制当局はそのデータを Nik 氏が「実に扱いにくい CSV ファイル」と表現する形式で公開します。Open Electricity はそれを解析し、データを補正して付加価値を与える必要があります。
送電網には階層構造があると Nik 氏は説明します。各ネットワークは施設 (facility) から成り、各施設はユニット (unit) から成り、各ユニットには独自の燃料技術があります。「石炭火力発電所には4基の異なるユニットがあるかもしれません」と同氏は言います。「風力発電所なら30基の異なる風力発電機があるでしょう」
データは3種類に分かれます。市場データ (地域ごとの価格、需要、発電量、予測)、1999年に遡るユニットごとの間隔別の発電データ、そして規制当局の生の4桁コードを元に Open Electricity が構築した、施設ごとに100以上のフィールドを網羅するキュレーション済み施設データです。これらを合わせると約10億件のレコードに達し、プラットフォームには毎日さらに50万件が追加されています。
その規模の大きさは、Open Electricity の Web サイト のグラフを見始めれば一目瞭然です。デフォルトの7日間ビューでは、16の燃料技術グループにわたり、1時間に12回 (5分間隔)、24時間、7日間にわたる32,000件以上のデータポイントを描画します。1999年まで遡る全期間ビューでは、その10億行のテーブルから約4,500万件のデータポイントを集計する必要があり、ユーザーは地域別、燃料種別、あるいは再生可能エネルギーと非再生可能エネルギーの切り口で細かく分析できます。これらはすべて、約300の企業や機関に利用されている公開 API を通じてリアルタイムに提供されています。
Open Electricity のデフォルトビュー。燃料技術タイプ別の7日間の発電量を表示しています。
1999年に遡る数十億件の5分間隔データポイントから集計された全期間ビュー。
金融や暗号資産など幅広い分野で働いてきた Nik 氏にとっても、エネルギーデータの負荷の高さと複雑さに匹敵するものはありませんでした。「電力ネットワークはきわめて複雑であり、データを解析して実態を解き明かすには細やかな工夫が求められます」
データベースに格納したからといって、その複雑さが消えるわけではありません。年中無休で5分ごとに、世界中の数百の機関に向けてライブデータを提供する少人数のチームにとって、適切なインフラを整えることは非常に重要です。
TimescaleDB から ClickHouse へ
長年、Open Electricity は Postgres と TimescaleDB を組み合わせて運用していました。しかし、データが10億行を超えて増加し続けるにつれて、この構成は悲鳴を上げ始め、クエリによっては完了までに5分以上かかるものも出てきました。最悪だったのは、市場データと発電データの間の結合 (JOIN) です。Nik 氏が語るように、「時間間隔に基づいて結合し、10億行を遡る処理は、あっという間に極めて負荷の高いものになります」
TimescaleDB も一定の救済策にはなりました。発電機は連続稼働しないためデータセットには多くの欠落があり、データを結合する前に NULL を埋める作業が常に求められていたことから、TimescaleDB の時系列関数、特に time_bucket や time_bucket_gapfill は重宝しました。
しかし、深刻な制約もありました。Continuous Aggregates (連続集計) では time_bucket_gapfill がサポートされておらず、マテリアライズドビューでのタイムゾーン処理もありませんでした。Nik 氏が「東海岸のタイムゾーンを扱い、西海岸のタイムゾーンと合算したうえで、さらにオーストラリア全体のビューを表示する必要がある」と説明するように、これは大きな問題でした。Continuous Aggregates に対するクエリは依然として遅く、マテリアライズドビューのリフレッシュ時にはテーブルがロックされました。結果としてチームは、大規模なクエリから SELECT した結果を手動で別のテーブルに書き込む運用に追い込まれました。
マテリアライズド化という発想自体は正しかったのです。彼らに必要だったのは、専用に作られた OLAP エンジンでした。「私は ClickHouse が法人化される前から使っています」と Nik 氏は言います。「列指向ストレージであり、圧縮性能が素晴らしく、クエリもはるかに書きやすいです……SQL を知っていれば、ClickHouse 独自のカスタム関数もすぐに習得できます」
また、さまざまな集計パターンに対応する 複数のエンジンタイプ、明確なパフォーマンス上の利点、そして Nik 氏とチームがフル活用している マテリアライズドビュー も備わっていました。「エネルギーデータの表現方法は非常に多岐にわたるため、ベーステーブルさえあれば、ClickHouse でマテリアライズドビューを作成するのは極めて低コストです」と同氏は言います。「現在では20個以上運用しており、常に増やし続けています。クエリの負荷が高い箇所が見つかれば、それ用の新しいマテリアライズドビューを作成し、クエリの参照先をそちらに向けるだけです」
92倍高速な新しいアーキテクチャ
スタックに ClickHouse が加わったことで、Open Electricity のアーキテクチャは明確に役割分担されました。Nik 氏はこれを「両者のいいとこ取り」と呼びます。「負荷の高いリレーショナルデータは引き続き Postgres に置きつつ、すべての分析ワークロードは現在 ClickHouse 上で行われています。どんなワークロードを投入しても、難なく処理してくれます」
ClickHouse 構成の中核にあるのは unit_intervals と market_summary というテーブルです。前者はユニットごとの5分間の発電量、排出量、市場価値データを格納し、後者は地域ごとの価格と需要を保持します。どちらも重複排除のために設計された ClickHouse 独自のエンジンタイプの一つである ReplacingMergeTree を使用しています。「ClickHouse の ドキュメント や ClickHouse を取り巻く GitHub コミュニティ は素晴らしいです」と Nik 氏は言います。「さまざまなエンジンタイプや、それぞれをいつ適用すべきかについて、すべて学ぶことができます」
これらベーステーブルの上には、各集計パターンに合わせてチューニングされたマテリアライズドビューの階層が置かれています。「クエリは非常に高速です」と Nik 氏は語ります。「Postgres では数分オーダーかかっていたクエリの一部が、今ではミリ秒単位で返ってきます」
性能を適切にベンチマークするため、チームは両方のシステムで同じクエリを実行しました。1999年に遡り、月単位でグループ化して燃料技術別の全期間エネルギーを集計するクエリです。Postgres は313秒かかりました。ClickHouse は3.4秒でした。「つまり、約92倍高速です」と Nik 氏は言います。「さらに素晴らしいことに、月次のマテリアライズドビューを使えば、同じクエリがわずか60ミリ秒で返ってきます」と付け加えました。
Nik 氏は、このベンチマークが同一ハードウェアによる比較ではないことも率直に指摘しています。Postgres は16コア、32 GB RAM、1.6 TB のディスクで稼働しています。ClickHouse は4コア、4 GB RAM、200 GB で稼働しており、ハードウェアもコストもほんのわずかです。
移行から得られた教訓
Nik 氏とチームは段階的な移行を選択し、新旧システムを並行稼働させながらトラフィックを少しずつ切り替えていきました。フィーチャーフラグを使ってエンドポイントごとに新旧両システムを切り替えられるようにし、API の出力を同一にしたため、ユーザーはどちらのデータベースにアクセスしているかまったく気づきませんでした。一定割合のユーザーをどちらかに振り分けて結果を比較し、確信が持てた段階でさらに切り替えを進めることができました。
「ClickHouse は運用コストが非常に安いため、完成度を高めるために必要なだけ並行稼働させておくことができます」と Nik 氏は言います。「オフィスに行って ClickHouse のスキーマを読み込み、既存のワークロードと並行して動かしながら少しずつ切り替えていくことを阻むものは何もありません」
最終的な結果には満足しているものの、いくつか乗り越えるべき「落とし穴 (gotchas)」もありました。第一は、Nik 氏が「FINAL の罠」と呼ぶものです。ClickHouse の ReplacingMergeTree エンジンは、クエリに明示的に FINAL を付けない限り、クエリ実行時には重複排除を行いません。「ClickHouse のアーキテクチャを理解することが重要です」と Nik 氏は言います。そうしないと、「ある朝起きたら、データがすべて2倍になっていた」ということになりかねません。
第二の落とし穴は、もう少しわかりにくいものでした。自動投入されるマテリアライズドビューと ReplacingMergeTree を組み合わせると、Nik 氏の言葉を借りれば「大惨事」になる可能性があります。不完全な日次集計が「最大バージョン争い」に勝ってしまい、完全な集計を上書きしてしまうのです。チームは巧妙なハックを考案しました。データの完全性をバージョン番号に直接エンコードすることで、288区間すべて揃った1日分のバックフィルが、10区間しかない自動投入の部分集計よりも常に優先されるようにしたのです。
タイムゾーンも悩みの種でした。東海岸と西海岸のデータが Python バックエンド、複数のドライバー、JavaScript フロントエンドを経由するため、パイプラインの中で日付が処理される箇所が20ほどあります。「タイムゾーンのないフィールドとタイムゾーン付きのフィールドを行き来していると、データが狂ってしまいます」と Nik 氏は言います。同氏は、最初から DateTime64 を UTC で標準化しておくことを勧めています。
その他の注意点としては、バックフィル時のメモリ管理 (ClickHouse は 一括挿入 (バルク挿入) を得意とするため、チームはデータを3日間のウィンドウに分割し、20,000レコードのバッチにするのが最も効率的であると突き止めました) や、ディスク容量の問題がありました。多くの場合、「メモリ不足 (out of memory)」エラーの原因は、ClickHouse が大規模な操作用のテンポラリディスク領域を使い果たしたことでした。また Nik 氏は、操作の種類に応じてタイムアウト値を合わせることも推奨しています。ユーザー向けクエリは数秒でタイムアウトさせ、長時間稼働するバックフィルや最適化タスクには十分な猶予を与えるべきだとしています。
「こうした注意点の一つひとつについて何日でも語れます。私たちのコードベースには多くの実践的なノウハウが詰まっています」と、同氏は笑顔で語ります。
ClickHouse + Postgres = 「魔法のようなペアリング」
Open Electricity の ClickHouse への移行により、チームは以前には実用的でなかった方法、すなわち10億行に及ぶデータをリアルタイムかつ大規模に、ミリ秒単位でクエリできるようになりました。
Nik 氏は、そのスピードと柔軟性を実感できるデモを2件紹介して発表を締めくくりました。オーストラリア国内のすべての石炭火力発電ユニットのリアルタイムステータスページ (5分間隔ごとの設備容量と出力を表示) と、フロントエンド開発者がその日のうちに構築した、2016年から2025年までの時間別太陽光発電出力を追跡する太陽光発電ヒートマップです。「今やミリ秒単位のクエリの話をしているのです」と Nik 氏は言います。
「Postgres と ClickHouse の組み合わせは、魔法のようなペアリングです」と同氏は続けます。「すべてのリレーショナルワークロードには Postgres を、すべての分析ワークロードには ClickHouse を使えます。私たちにとって極めてうまく機能しており、以前は不可能だった方法でデータをクエリできるようになりました」
世界で最も注視されているエネルギー転換の一つを追跡する小規模な非営利団体にとって、このペアリングこそが、研究者、ジャーナリスト、政策決定者にオーストラリアの電力網の現状をリアルタイムに伝え、その全体像を世界と共有することを可能にしている基盤です。
