株式会社ログラスのソフトウェアエンジニア、龍島浩人氏がOSSデータベースDuckDBの内部実装を解説する記事を公開しました。DuckDBは「larger-than-memoryワークロード」、つまりシステムメモリより大きなデータセットを処理できることを強みとしています。5,000万行・1.7GBのParquetファイル（キーはすべてユニーク）を使い、メモリ上限を変えて処理時間や挙動を検証しています。
既定のmemory_limit（38.3GiB）では処理時間3.0秒、hash tableサイズ1,960MiBでディスクへの書き出しは発生しませんでした。memory_limitを300MBに制限すると処理時間は約8.5秒に伸び、hash tableは200MiB前後に抑えられ、一時ファイルへ1,770MiBが書き出されました。memory_limit=250MBでは4回の実行中2回がOut of Memoryとなり、200MB以下では処理が完全に失敗したとのことです。
DuckDBはメモリ上限に達すると、buffer managerによってページを一時ファイルへ退避する「外部ハッシュ集約」という分割統治の仕組みを実装しています。同じキーは必ず同一partitionに格納されるため、partition単位で独立して計算を進められる点がポイントです。「一部の演算子は入力の最後の行を見るまで1行も出力できない」ため、こうしたブロッキング処理をどう扱うかがメモリ制御の鍵になっているとしています。
出典が伝えている要点
- 著者は株式会社ログラスのソフトウェアエンジニア龍島浩人氏である。
- 記事はDuckDBの内部実装(GROUP BY処理)を解説する技術ブログである。
- テストには5,000万行、1.7GBのParquetファイルを使用した。
- テストデータのキーはすべてユニークであり、グループ数は入力行数と同じである。
- 既定のmemory_limit(38.3GiB)では処理時間が3.0秒だった。
- 既定のmemory_limitでのhash tableのサイズは1,960MiBだった。
- 既定のmemory_limitではディスクへの書き出しは発生しなかった。
- memory_limitを300MBに制限した場合、処理時間は約8.5秒だった。
- memory_limit=300MBの場合、メモリ上のhash tableは200MiB前後に制限され、一時ファイルへ1,770MiBまで書き出された。
- memory_limit=250MBの場合、4回の実行中2回は完走し、2回はOut of Memoryとなった。
- memory_limit=200MB以下では処理は完全に失敗した。
- DuckDBはメモリ上限に達するとページをbuffer managerにより一時ファイルへ退避する「外部ハッシュ集約」を実装しており、同じキーは必ず同一partitionに格納されるためpartition単位で独立して計算できる。
原文より
A key strength of DuckDB is support for larger-than-memory workloads, i.e., it is able to process datasets that are larger than the available system memory
Some operators cannot output a single row until the last row of their input has been seen. These are called blocking operators
出典: zenn.dev