Logfireのクエリ速度が最大1000倍向上するシャーディングとは
Logfireは、2026年2月に提供開始される新機能「ダイナミックシャーディング」により、データのクエリ速度が大幅に向上すると発表しました。一部のケースでは1,000倍以上の高速化が実現し、これまで30秒でタイムアウトしていたクエリが1秒未満で完了するとのことです（Lobsters）。これは、半構造化された属性データを効率的にクエリするための最適化技術で、ログデータ分析の体験を大きく変える可能性を秘めています。
以前はタイムアウトしていたクエリが1秒未満で完了するなど、最大1,000倍以上の速度向上が見込まれます。
OpenTelemetryデータの課題とLogfireの解決策
Logfireが取り込むOpenTelemetryデータは、固定スキーマフィールド（タイムスタンプ、スパン名など）と半構造化属性（HTTPステータスコード、ユーザーID、リージョンなど）が混在する特徴があります。特に属性データは、スパンごとに内容が大きく異なるため、効率的な保存とクエリが難しいという課題がありました。Logfireでは、これらのデータをParquetファイル形式でオブジェクトストレージに保存していますが、従来の方式ではattributesやotel_resource_attributesといったフィールドがJSON文字列として格納されていました。
| 項目 | 概要 | 具体例 |
|---|---|---|
| 固定スキーマフィールド | 常に存在する、型が厳密に定義されたフィールド | start_timestamp, span_name, trace_id |
| 半構造化属性 | スパンごとに内容が変化するキーバリューペア | user_id, http.status_code, region |
このJSON文字列のままでは、特定の属性値でフィルタリングや集計を行う際に、フルスキャンとJSONパースが必要となり、パフォーマンスが低下する要因となっていました。
ダイナミックシャーディングによる効率化
Logfireが採用したダイナミックシャーディングは、このJSON形式で格納された属性データを、クエリ時に動的に構造化するアプローチです。具体的には、頻繁にクエリされる可能性のある属性を事前に特定し、それらを個別のカラムとしてParquetスキーマに「シャーディング（細分化）」します。これにより、必要なデータだけを効率的に読み込み、JSONパースのオーバーヘッドを削減します。
この最適化の背景には、Parquetのようなカラムナー（列指向）ストレージと、ゾーンマッププルーニングといった技術があります。カラムナー形式は、特定のカラムだけを読み込む際に高速性を発揮し、ゾーンマッププルーニングは、データブロックの最小値・最大値情報を利用して、不要なブロックの読み込みをスキップすることでクエリを高速化します（Lobsters）。これらをJSON属性に適用することで、大幅なパフォーマンス向上が実現しています。
エンジニア目線で見ると：BigQueryなどでの最適化に活かせそう
Logfireが実現したダイナミックシャーディングは、半構造化データを扱う多くのエンジニアにとって非常に示唆に富む内容だと感じます。私自身、GCPのBigQueryでJSON形式のデータを扱う際に、同様の課題に直面することがあります。
BigQueryではJSON_EXTRACT関数を使ってJSON内のフィールドを取り出すことが多いですが、頻繁にアクセスするフィールドは標準SQLのUNNESTやSTRUCT型を使って構造化しておくことで、クエリパフォーマンスを大幅に改善できる経験があります。今回のLogfireのアプローチは、まさにその思想を動的に適用していると言えるのではないでしょうか。
既存のシステムでOpenTelemetryのようなトレーシングデータを扱っている場合、属性データの保存方法を見直す良い機会になるかもしれません。BigQueryではコストがクエリするデータ量に比例するため、不要なJSONパースを避けることはコスト最適化にも直結します。Logfireが提供するシャーディング機能はサービス側で自動的に最適化してくれるものですが、もし自前でデータ基盤を構築している開発者の方がいれば、アクセス頻度の高いJSONフィールドを物理的に独立したカラムとして持つ、あるいはビューとして構造化するといった工夫は、パフォーマンスとコストの両面で有効だと考えます。
PythonのPandasやPolarsでデータ分析を行う際にも、JSON文字列のままでなく、適切なデータ型に変換してから扱うことで、処理速度が向上するケースは少なくありません。PydanticがもともとJSONパースの効率化から始まったことを考えると、その知見がLogfireのデータ基盤にも活かされているのは納得感がありますね。
