Pydantic'ın Logfire'ı, Parquet'te JSON özniteliklerini parçalayarak sorguları 1000 kata kadar hızlandırıyor

Pydantic'ın gözlemlenebilirlik platformu Logfire ciddi bir hız artışına hazırlanıyor. Pydantic ekibinin mühendislik yazısına göre, şirketin dinamik parçalama (dynamic shredding) adını verdiği optimizasyon bazı sorguları 1000 kattan fazla hızlandırıyor — eskiden 30 saniyelik zaman aşımına takılan aramalar artık bir saniyenin altında geri dönüyor. Değişiklik Şubat 2026'da tüm müşterilere ulaşmaya başlayacak ve yazı Hacker News'in ana sayfasında da yer buldu.

Sütunsal depoda yarı yapılandırılmış veri

Logfire, iki tür veriyi harmanlayan OpenTelemetry telemetrisini alır. Zaman damgaları, span adları, trace ve span kimlikleri gibi sabit şemalı alanlar her span'de mevcuttur ve güçlü şekilde tiplidir. HTTP durum kodları, kullanıcı kimlikleri veya dağıtım bölgeleri gibi yarı yapılandırılmış öznitelikler ise span'lere veya kaynaklara eklenmiş anahtar-değer çiftleri olarak gelir ve büyük çeşitlilik gösterir: bazı anahtarlar OpenTelemetry belirtiminde standartlaştırılmıştır, user_id gibi uygulamaya özgü bir anahtar ise bir serviste tam sayı, diğerinde dize olabilir.

Veriler eninde sonunda nesne depolamada Parquet dosyaları olarak saklanır. Sabit alanlar tipli sütunlara eşlenir, ancak öznitelikler tek bir sütunda JSON blob'u olarak duruyordu.

Ayrıştırma hızı neden yeterli olmadı

Pydantic'ın ilk yaklaşımı ham ayrıştırma performansına dayanıyordu: öznitelikler JSON olarak kalıyor ve ekibin herhangi bir dildeki en hızlılardan biri olarak nitelendirdiği Jiter adlı ayrıştırıcı, onları sorgu zamanında işliyordu. Yazı, bunun yanlış şeyi optimize ettiğini açıkça kabul ediyor. Şirket işi hızlandırmak yerine ondan kaçınması gerekiyordu.

İki maliyet öne çıkıyordu. Sıkıştırma kötüydü, çünkü tek bir değişken öznitelik bile Parquet'in sözlük kodlamasını etkisiz hale getiriyor ve zstd bile yüksek değişkenlikli, sözdizimi ağır JSON'da zorlanıyor. Daha kötüsü, ekstra baytlar ekstra G/Ç anlamına geliyordu ve nesne depolamada indirmelerin başlatılma gecikmesi, sorgu çalışma sürelerinin ana belirleyicisi olarak CPU süresini gölgeliyordu.

Tipli sütunlar ve istatistikler

DataFusion gibi sütunsal motorlar gereksiz işi iki yoldan kaçınır: yalnızca sorgunun dokunduğu sütunları okurlar ve satır grubu ile sayfa başına kaydedilen min/maks istatistikleri olan zone map'leri kullanarak bir filtreye kesinlikle uymayan parçaları atlarlar. Yazı, saklanan hiçbir değerle eşleşemeyecek bir süre filtresi örneği veriyor; bu tür bir sorgu hiç tarama yapmadan yalnızca istatistiklerden yanıtlanabiliyor.

Logfire'ın bu mekanizmayı özniteliklere taşıyan ilk girişimi statik parçalamaydı: sorgulanma ihtimali yüksek, elle seçilmiş bir anahtar listesi — http.response.status_code veya url.full gibi — alım sırasında ayrı tipli sütunlara çıkarılıyordu. JSON yoluna yazılan sorgular dahili olarak parçalanmış sütuna yönlendirilecek şekilde yeniden yazılıyor, böylece kullanıcıların bunun varlığından haberdar olması gerekmiyor. Tipli sütunlar iyi sıkışıyor ve budaklanmanın (pruning) tüm avantajlarından yararlanıyor.

Statik parçalama nerede yetersiz kaldı

Pydantic, statik yaklaşımın önemli sınırları olduğunu kabul ediyor. Yalnızca küçük, sabit kodlanmış bir öznitelik kümesi yarar sağlıyor; listede olmayan her şey tam JSON maliyetini ödüyor — ve bu, yüzlerce gigabayt veriye sahip projelerde ciddi şekilde yavaş hale geliyor. Yeni parçalanmış öznitelikler eklemek zor. Dahili sütunlar ayrıca birisi select * çalıştırdığında lf_attributes önekiyle kullanıcıya dönük çıktıya sızıyor ve ekipte saklanmasını istediği bir uygulama detayını ortaya çıkarıyor; açıklanan hedef, özniteliklerin tek bir mantıksal JSON sütunu gibi görünmesi, alttaki fiziksel düzen değişirken bile.

Dinamik parçalama

Bu gerilim, yazının ana konusunu hazırlıyor: Pydantic'ın baştaki hız artışlarını borçlu olduğu teknik, yani dinamik parçalama. Makale, veri modelini, özgün JSON tasarımını ve statik parçalamanın eksikliklerini gözden geçirdikten sonra yeni yaklaşımı ortaya koyuyor ve erken erişimdeki müşterilerin kazanımları zaten gördüğünü bildiriyor — alıntılanan bir müşteri, öznitelik sorgularının artık fiilen anlık hissettirdiğini söylüyor.

Neden önemli

Gözlemlenebilirlik araçlarında performans tavanını genellikle iyi tiplenmiş çekirdek alanları değil, yarı yapılandırılmış, yüksek kardinaliteli öznitelikler belirler. Pydantic'ın anlatısı, bu maliyetin gerçekte nerede yaşadığına dair yararlı bir vaka çalışması: CPU'ya bağlı JSON ayrıştırmasında değil, daha hızlı ayrıştırıcıların asla ortadan kaldıramayacağı nesne deposu G/Ç'sinde. Ayrıca daha geniş uygulama alanı olan bir tasarım örüntüsünü de örnekliyor — mantıksal şemayı (tek bir JSON sütunu), tipli ve budaklanabilir sütunlardan oluşan fiziksel şemadan ayırmayı, böylece depolama optimizasyonlarının kullanıcıya görünmez kalmasını sağlıyor. Logfire müşterileri için pratik sonuç anında ortada: zaman aşımına uğrayan sorgular artık geri geliyor ve öznitelik filtreleme, daha önce kullanılamadığı veri kümelerinde kullanılabilir hale geliyor.