Laravel Nightwatch × ClickHouse 講演レポート【Laravel Live Japan】

こんにちは！SHIPエンジニアの廣山です！

少し前のお話になりますが、5月に東京で開催されたLaravel Live Japan に、社内のエンジニア数名とともに参加してきました！

その中でも一番刺さったのが、Laravelの話……というより、実質データベースの話だったこのセッションでした。普段の業務ではデータベースを深く扱うわけではないので、新しく知ることも多いセッションでした。せっかくなので、聞いて面白かったポイントを、自分の理解を整理しながらまとめてみます。

Laravel Live Japan について

Laravel Live Japan は、5月末に立川ステージガーデンで開催された、日本初のLaravel公式カンファレンスです。

自分がこのイベントを知ったきっかけは、これまで数回参加することがあった PHP×Tokyo というミートアップでの告知でした。正直に言うと、自分はPHPを業務で使うことはありますが、Laravelを業務で使ったことがありません。それでも参加して大正解でした。というのも、セッションのテーマは Laravel だけにとどまらず、AI、テスト、データベース、ネイティブアプリ、フロントエンド、アーキテクチャ、さらにはPHPで音楽を作るというトークまで、とても幅広かったからです。

その中で一番印象に残ったのが、Laravel Nightwatch のリードエンジニア Jess Archer さんによるセッション「Inside Nightwatch: Real-Time Analytics at Scale」です。

（セッション全編はLaravel公式チャンネルにてアーカイブされているので、実際の様子はこちらから観られます！）

この記事でわかること

Laravel Nightwatch と ClickHouse がそれぞれ何なのか
「列指向」と「行指向」DBMS のちがい
ClickHouse の速さを支える仕組みの一部
「列指向 DB が向かない場面」についての、登壇者の答え

Laravel Nightwatch とは

Nightwatch は Laravel 公式のアプリケーション監視ツールで、例外・ログ・パフォーマンスをモニタリングします。このことから、Nightwatch は多くの利用者のアプリケーションから大量のデータを集めています。

講演で挙げられていた数字がこちら：

昨年6月のNightwatchリリース以来のイベント取り込み数: 4,810億件以上
Nightwatch が扱っている、最大の単一テーブル: 460億行

Nightwatchがこの量のデータを管理するのに使用しているデータベースが、ClickHouseです。

※ なお、Nightwatch は Laravel 製ですが、ClickHouse は Laravel とは別の、独立したデータベースです。自分は最初ここを混同していました。

Nightwatch が使う DBMS「ClickHouse」とは

ClickHouse はデータ分析に適した、オンライン分析処理（Online Analytical Processing - 略して「OLAP」）に分類される、列指向の DBMS。

一方、行指向であるMySQLやPostgreSQLは、オンライントランザクション処理（Online Transaction Processing - 略して「OLTP」）に分類されるDBMS。

自分なりに用途で整理すると：

OLAP（ClickHouse）：
- 大量のデータをまとめて集計する処理向き。「直近1時間の平均レスポンスタイムは？」のように、数百万〜数十億行をまとめて1つの答えを出すなど。
OLTP（MySQL / PostgreSQLなど）：
- アプリを日々動かすための処理向き。「このユーザーを取得」「この注文を更新」といった、対象を絞った読み書きです。

「列指向」と「行指向」

ClickHouse が MySQLやPostgresと根本的に違うのが、データの保存のしかたです。

ClickHouse は列指向であり、列ごとにまとめて保存します。
MySQL・PostgreSQL などは行指向であり、１行分のデータをまとめて保存します。

列ごとに保存するメリットを例で見てみると：

50列あるテーブルで、3列だけを読む集計クエリを実行するとします。

select avg(col1), sum(col2), max(col3)
from tablename;

列指向の場合、その3列だけ読めばよく、残り47列に触れる必要がありません。これで処理も速く済みます。

これが行指向だと、必要なのは3列でも1行丸ごと読むので、ほぼ全部のデータを読むことになります。

ある1つの列を集計したいとき、その列のデータはすべてまとまって保存されているので、あちこち飛び回らずに一気に読めます。なので速い。

逆に、1行分をまるごと取り出そうとすると、その行の値は各列のファイルにバラバラに分かれているため、あちこちから集めてくる必要があります。

他にも面白かった ClickHouse の仕組み

ここからはセッションで面白かった、ClickHouse の内部の話です。速さの理由は他にもいろいろあるとのことですが、セッションで紹介されていた中から、特に印象に残った2つを紹介します。

1. データの挿入方法

ClickHouse では、INSERT を実行するたびに、パートと呼ばれるものが作られます。

パートとは、ディスク上のディレクトリのこと。つまり、INSERT のたびにディスク上に新しいフォルダが1つできる、というイメージです。

そしてこのパートは、一度作ったら変更されない（イミュータブル）。

それではパートが増え続けるのでは？と思いますが、ここで「マージ」という仕組みが働きます。バックグラウンドで一定間隔で走り、小さいパートを大きなパートへと少しずつまとめていきます。設定で変えられるそうですが、圧縮後で最大約150GBまでまとめていくそうです。こちらが何もしなくても、裏で自動的に整理してくれる、という感じです。

この「書き込みはとりあえず新しいパートとして追記して、重い処理は裏のマージに任せる」という仕組みのおかげで、書き込み自体はとても軽く・効率的になります。

2. インデックスは全行分じゃない

一般的なRDBMSでは、プライマリインデックスはテーブルの全行に対して1つずつエントリを持ちます。特定の行をピンポイントで速く見つけられるので、ルックアップや1行更新に適しています。

一方、ClickHouse で面白いのが、そのインデックスが全行分ではないこと。なんと、8,192行につき1エントリしか持ちません（この8,192行のかたまりを「グラニュール」と呼ぶそうです）。

このように間を引いて何の役に立つのか。データがキー順に並んでいるので、この目印を手がかりに「どのグラニュールにありそうか」を素早く絞り込めます。関係ないグラニュールは読まずに済むので、分析系のクエリが速くなるわけです。

Laravel での使い方

パッケージを入れれば、Laravel のクエリビルダから ClickHouse を扱えるようになります。セッションでは2つ紹介されていました：

composer require glushkovds/phpclickhouse-laravel
# または
composer require laravel-clickhouse/laravel-clickhouse

実際のクエリはこんな形です：

DB::connection('clickhouse')
    ->table('requests')
    ->selectRaw(<<<'SQL'
        date(timestamp) as date,
        count(*) as requests,
        min(duration) as fastest,
        max(duration) as slowest,
        avg(duration) as average
    SQL)
    ->where('environment_id', $environmentId)
    ->where('timestamp', '>=', now()->subHour())
    ->groupBy('date')
    ->orderBy('date')
    ->get();