Scribble at 2026-08-16 13:43:05 Last modified: unmodified

丁寧に調べてみるまでは、DuckDuckGo のバックエンドかと勘違いしていたのだが、DDG とは何の関係もないプロダクトだ。でも、実際にドキュメントを読むと面白い DBMS だと分かった。用途によっては、弊社でも利用する機会があるかもしれない。

まず MariaDB や PostgreSQL などの RDBMS と大きく異なるのが、処理系に組み込むタイプのライブラリ型であるという点だ。これは、SQLite のように PHP や Go といった処理系のライブラリとして動作するため、データベース用のサーバを建てる必要がない。そして、行ではなく列（column）指向でデータを保存するため、列を単位にする集計処理などが高速であるという特徴があり、したがって統計処理などに最適だと言われている。なので、「データ分析用の SQLite」などという俗称もあるらしい。

このような密結合のサービス・アーキテクチャをもつシステムにおいては、もちろんデータを別のサーバ（「サーバ」というだけなら同じ筐体でも複数のサーバを実装できるから、実際には通信ネットワークで隔てられた別の筐体と言う方が正確なのだが）へ置かずに記録し保管し運用することとなるので、当然だが弊社のようなプライバシーマークの認定事業者においては、システムの設計段階で Privacy by Design の指針に従った慎重な配慮が必要だ。そこで DuckDB では、第一にデータをストアする際の暗号化をサポートしている。第二に、処理の途中でメモリやスワップ領域へ記録したデータを即座にクリアする仕組みもある。第三に、ログやデバッグ情報の出力では具体的なデータを自動でマスキングする仕組みがあり、第四に、アプリケーションのプロセス内においても個々のモジュールや実行ユーザの単位でデータに対する authorization（認可）が設定できる。

恐らく、これに加えて僕なら統計データなどで集計した結果の数値だけを利用する場合は、集計結果だけを永続的にストアしておいて、そのために利用した生のデータは別の機器へ退避させて、DuckDB のサーバからは削除していくといったバッチ処理を加えると思う。統計処理だけに使うのであれば、匿名化したデータだけが重要なのであって、それが具体的なソースとしてどういうものであるかは、とりあえず気にしなくてもよいからだ。もちろん、後から別の用途で集計をやりなおす可能性はあるから、ソースを削除してしまうわけにはいかないのだが、そういう場合でもデータを取得した際の「利用目的」に合致した範囲で集計しなおすのかどうかは、プライバシーマークの認定事業者のチーフ・エンジニアとしては当然のように配慮するべきであろう。