DuckDBとは｜20万行の課別集計が3.9ms、CSVのままだと47.5ms

20万行の課別集計が3.9ms、CSVのままだと47.5ms

20万行の表に対する集計を実際に走らせました。形式をそろえれば、待ち時間として意識しない範囲に収まります。

DuckDBがどれくらいの速さで動くのかを、実際に走らせて測りました。使ったのは出張申請を模した20万行・8列の表です。

問い合わせは業務でよく使う形にしました。全件の合計、課ごとの合計、条件で絞った合計、上位の並べ替えです。

con = duckdb.connect()
con.execute("CREATE VIEW t AS SELECT * FROM read_parquet('data.parquet')")
con.execute('SELECT ka, sum(kingaku) FROM t GROUP BY ka').fetchall()

問い合わせ                          かかった時間  返る行数
全件の合計                                  1.7 ms         1行
課ごとの合計                                 3.9 ms         8行
課×目的ごとの合計                              6.7 ms         8行
条件で絞って合計                               2.0 ms         1行
上位を並べる                                 4.5 ms         3行

同じ集計を CSV に対して行った場合
全件の合計                                 44.4 ms
課ごとの合計                                47.5 ms
課×目的ごとの合計                             49.5 ms

上の表を見てください。課ごとの合計が3.9ミリ秒です。20万行を読んで8行に集約しています。

形式で12倍変わる

同じ集計をCSVに対して行うと47.5ミリ秒でした。12倍の差です。

CSVの側は、どの問い合わせでも44から49ミリ秒に収まっています。読み込みの時間が大半を占めるので、集計の中身で変わりません。

集計の形で変わる

Parquetの側は集計の形で変わります。全件の合計が1.7ミリ秒、課×目的ごとだと6.7ミリ秒でした。

読む列が増え、まとめる単位が細かくなるほど伸びます。読み込みではなく、集計そのものが時間を使っている状態です。

DuckDBとは、その場で動く分析用の問い合わせ基盤

別のサーバを立てずに、呼び出す側の処理のなかで動きます。分析向けの問い合わせに合わせて作られています。

DuckDBは、別のサーバを立てずにその場で動く問い合わせ基盤です。分析向けの処理に合わせて作られています。

立てるものがない

公式の説明は、別のプロセスとしては動かず、呼び出す側のプロセスのなかに完全に埋め込まれるとしています。

つまり接続先も、起動の手順もありません。前の節の計測でも、入れてすぐ動きました。

依存がない

導入も軽くなっています。同じ説明は外部への依存が、組み立てのときも実行のときもないとしています。

配布の形も特徴的です。全体の原始コードが、見出しと実装の2つのファイルにまとめられると説明されています。

何に向けて作られているか

対象がはっきりしています。想定されているのは保存されたデータの大部分を処理する、複雑で比較的長く走る問い合わせで、表全体にわたる集計や大きな表どうしの結合が例に挙げられています。

1. まとめて読んで集計する。ここが本領
2. 1件ずつ書き換える。この用途には向かない
3. 大量の同時接続をさばく。別のサーバが要る
4. 手元のファイルをそのまま読む。取り込みの手順を省ける

4番目が実務では効きます。CSVやParquetをそのまま読めるので、試すまでの手間がほとんどありません。

分析基盤を立てる前に試せる

立てるものがないので、比較の出発点として使えます。合わなければ捨てるのも簡単です。

分析の仕組みを検討するとき、まず基盤を選ぶところから始めがちです。DuckDBは、その手前で試せます。

先に測る

前の節のとおり、手元のファイルをそのまま読めます。取り込みの仕組みを作る前に、集計が現実的な時間で終わるかを確かめられます。

20万行で3.9ミリ秒という数字が出れば、この規模なら基盤は要らないと判断できます。逆に足りなければ、必要な性能が具体的に見えます。

捨てる費用が小さい

外部への依存がないので、入れるのも外すのも1つの手順で済みます。合わなければ消せます。

利用の条件も緩く、きわめて許容的なMITライセンスのもとで公開されているとされています。

越えられない線

1. 同時に多数が書き込む。別のサーバを立てる
2. 1件ずつ更新し続ける。業務システムの土台には向かない
3. 複数の人が同じデータを共有する。置き場と権限の仕組みが要る
4. 1台に載らない大きさ。分散させる基盤が要る

3番目が判断の分かれ目になりやすい部分です。1人で分析するなら十分でも、部署で共有するなら別の仕組みが要ります。