テックブログ

2021.11.01

【Laravel】chunk と chunkById を比較してわかったこと

エンジニアの小林です。

クラフではLaravelを使ったWEBサービスの開発も行っています。

今回はLaravelのchunkメソッドとchunkByIdメソッドの違いについて、解説してみたいと思います。

chunkとは

chunkとは「小さな塊（チャンク）」という意味で、Laravelではクエリビルダに用意されているchunkメソッドで、DBからデータを小さな「塊（チャンク）」ごとに分割して結果を取得し、処理を行うことができます。大量データを扱う場合はメモリ不足エラーを起こさず安全に処理することができます。

Laravelには似たような名前でchunkByIDというメソッドも用意されていますが、どちらを使えばいいのでしょうか。

結論：chunkByIDが使えるときはchunkByIDを使う

最初に結論を書いてしまうと、私はchunkByIDが使える局面ではchunkByIDを使うことをおすすめします。

なぜなら、chunkは大量データを処理する場合に処理速度の問題があるからです。

公式リファレンスには、「結果をチャンクしつつデータベースレコードを更新すると、チャンク結果が意図しない変化を起こす可能性があります。そのため、チャンク結果を更新する場合は、常に代わりのchunkByIdメソッドを使用するのが最善です。」と記載されています。たしかにそういう側面もあると思いますが、私の場合は、パフォーマンス面のほうが気になりました。

chunkの仕組み

chunkメソッドの仕組みを理解するために、展開されるSQLを確認していきたいと思います。

確認コード1

    Sample::chunk(100, function ($sample) {
        // SQL出力
    });

展開されるSQL1

select * from “samples” order by “samples”.”id” asc limit 100 offset 0;
select * from “samples” order by “samples”.”id” asc limit 100 offset 100;
select * from “samples” order by “samples”.”id” asc limit 100 offset 200;
…

一回呼び出されるごとに、offsetが100づつ増えているのがわかります。

chunkは、limit offset で分割処理を実現しているようです。

また、order by id が自動で付加されています。

次に、queryにorderBy句を設定してみます。

確認コード2

    Sample::orderBy(‘updated_at’)->chunk(100, function ($sample) {

        // SQL出力
    });

展開されるSQL2

select * from “samples” order by “updated_at” asc limit 100 offset 0;
select * from “samples” order by “updated_at” asc limit 100 offset 100;
select * from “samples” order by “updated_at” asc limit 100 offset 200;
…

orderBy句を設定すると、期待通り orderBy updated_at に変わりました。

chunkByIDの仕組み

一方のchunkByIdメソッドで展開されるSQLをみていきたいと思います。

確認コード3

    Sample::chunkById(100, function ($sample) {
       // SQL出力
    });

展開されるSQL3

select * from “samples” order by “id” asc limit 100;
select * from “samples” where “id” > ? order by “id” asc limit 100; [bindings => [100]]
select * from “samples” where “id” > ? order by “id” asc limit 100; [bindings => [200]]
…

注目するのは、where “id” > ? の部分です。100, 200 と順に値が渡されることで、offset と同じ動作を実現しているようです。また、サンプルでは連番になっていますが、自動で1つ前のSQLで取得したIDの最大値をバインドしてくれるため、IDが連番になっていなくても大丈夫です。

また、order by id が自動で付加されています。

次に、queryにorderBy句を指定してみます。

確認コード4

    Sample::orderBy(‘updated_at’)->chunkById(100, function ($sample) {
       // SQL出力
    });

展開されるSQL4

select * from “samples” order by “id” asc limit 100;
select * from “samples” where “id” > ? order by””updated_at” asc, “id” asc limit 100;
[bindings => [100]]
select * from “samples” where “id” > ? order by””updated_at” asc, “id” asc limit 100;
[bindings => [200]]

こちらもorderByにupdated_atに変わりました。

しかし、where “id” > ? という検索条件はそのまま設定されているため、chunkメソッドの結果とは異なります。期待する動作にはなりませんので、注意が必要です。

chunkByIDの第３引数を指定する

chunkByIdをID以外でおこないたい場合は、第3引数を設定します。

確認コード5

Sample::chunkById(100, function ($sample) {
// SQL出力
}, ‘updated_at’);

展開されるSQL5

select * from “samples” order by “updated_at” asc limit 100;
select * from “samples” where “updated_at” > ? order by””updated_at” asc limit 100;
[bindings => [Illuminate\Support\Carbon @1594977896]]
select * from “samples” where “updated_at” > ? order by””updated_at” asc limit 100;
[bindings => [Illuminate\Support\Carbon @1594977996]]
…

where句、orderBy句ともに、updated_atに置き換わり、期待している動作になりました。注意点としては、指定するカラムがユニークでない場合、データの抜け漏れが発生する可能性があります。

chunkのパフォーマンス問題について

chunkにはパフォーマンス問題があると前述しましたが、確認のためchunkByIdと処理速度を比較していきたいと思います。

以下は、70万件のデータを処理したときのスプリットタイムの比較です。

chunkByIdはほぼ一定の速度を保っていますが、chunkのほうは処理を重ねるごとに遅くなっていってます。

chunkが遅くなる原因はSQLにoffsetを使用しているためです。SQLにoffsetが指定された場合、DBエンジンの内部では、検索条件に一致するデータを取得したあと、取得したデータの先頭から順に読み出し、offsetの部分のレコードをあとから取り出すという動作を行っています。つまり、offsetの値が大きくなると比例してDBからのレスポンスが遅くなります。

参考までにoffset値別の1回のSQLの実行時間の比較をしてみます。

DBはPostgreSQL13を使っていますが、Mysqlなどでも同様の傾向になります。