ClickHouse 26.10, seçici LIKE sorgularında bellek kullanımını tarama sırasında string filtreleme ile 25 kat düşürüyor

26.10 ile gelenler

ClickHouse 26.10, 6 Kasım 2026'da yayımlandı ve varsayılan olarak etkin olan yeni bir ayar olan apply_string_filters_during_scan ile geldi. dev.to'daki yazıya göre bu ayar, String kolonlarındaki alt string koşullarını kolon okuyucunun içine indiriyor: PREWHERE ifadesinde LIKE, position, startsWith, endsWith veya boş olmayan bir string ile eşitlik testi bulunduğunda, her değer seri durumdan çıkarma sırasında kontrol ediliyor ve eşleşmeyen değerler tam olarak oluşturulmak yerine boş string olarak döndürülüyor. Ayarın kendi açıklaması, bir koşulun seçici olmadığı ortaya çıktığında kendini uyarlamalı olarak devre dışı bıraktığını da söylüyor; benchmark bu iddiayı doğrudan test etti.

25 kat bellek azalması

dev.to testi, satır başına yaklaşık 1.3KB metin içeren (diskte 103MB) on milyon satırlık bir MergeTree tablosu kurdu; her yüz satırdan biri aranan kelimeyi içeriyor. Eşleşen ve eşleşmeyen satırlar bilerek aynı uzunlukta tutuldu, böylece bellek farkları veri şeklinden değil seçicilikten kaynaklanacaktı. Aynı LIKE sorgusu ClickHouse 26.9 üzerinde, ayar zorla kapatılarak 26.10 üzerinde ve varsayılan haliyle 26.10 üzerinde, her biri üç kez çalıştırılarak, tek iş parçacığıyla ve tepe bellek system.query_log'dan okunarak test edildi.

Sürüm 26.9 37.6MB tepe belleğe, ayar kapalıyken 26.10 ise 37.7MB'a ulaştı; bu da işi yapanın sürümdeki başka bir değişiklik değil ayarın kendisi olduğunu doğruluyor. Ayar açıkken tepe bellek 1.48MB'a, yaklaşık 25 kat daha düşüğe indi ve çalışma süresi kabaca 1.5-2.0 saniyeden yaklaşık bir saniyeye düştü; bu %35-40'lık bir hızlanma.

Yardım etmediği yerler

Belgelenen uygun koşullar listesi dar ve benchmark, hiçbir şey kazanmayan birkaç benzer koşul buldu. ClickHouse'un regex fonksiyonu olan match(), ayar açık ve kapalıyken aynı bellek kullanımını gösterdi. NOT LIKE da değişiklik göstermedi; bu, seçicilik mantığıyla tutarlı: satırların %1'inde bulunan bir terimi dışlamak, satırların %99'unun hâlâ geçtiği anlamına geliyor.

Uyarlamalı devre dışı bırakma iddiası, satırların %100'üyle eşleşen bir desenle test edildi. Ayar açıkken bellek yine yaklaşık %32 daha düşüktü (37.7MB'a karşı 25.6MB), ancak hız avantajı tamamen kayboldu ve filtreli çalıştırmalar üç karşılaştırmadan ikisinde hafifçe daha yavaştı. dev.to'daki sonuç: seçici olmayan filtreler için ılımlı bir bellek tasarrufu ve hiç zaman tasarrufu beklemeyin.

Eşitlik tuzağı

Boş olmayan bir string ile eşitlik belgelenmiş listede, ancak düz bir WHERE body = '...' sorgusu hiçbir fark görmedi. EXPLAIN nedenini gösterdi: ClickHouse LIKE koşullarını otomatik olarak PREWHERE'e yükseltiyor, ancak eşitlik tarama sonrası bir Filter olarak kalıyor ve yeni optimizasyon yalnızca PREWHERE içinde etkili oluyor. Sorguyu açık bir PREWHERE ile yeniden yazmak faydayı geri getirdi: ayar kapalıyken 17.82MB'a karşı 1.50MB, kabaca 12 katlık bir azalma. Pratik sonuç şu: geniş bir metin kolonuna karşı düz eşitlik yazan bir analist, PREWHERE anahtar kelimesini kendisi eklemedikçe bu sürümün öne çıkan iyileştirmesinden hiçbir şey kazanmıyor, buna karşılık LIKE kullanıcıları otomatik olarak yararlanıyor.

Eşzamanlı yük altında

On eşzamanlı istemci sürecinden %1 seçicilikteki LIKE sorgusu çalıştırıldığında, tüm parti ayar açıkken 3.18 saniyede, kapalıyken 6.54 saniyede tamamlandı; tekrar çalıştırmada 3.03'e karşı 7.17 saniye. Avantaj, eşzamanlılık arttıkça aşınmak yerine yük altında da korunmuş oldu.

Neden önemli

Sorgu başına tepe bellek, bir düğümün veri boşaltmaya ya da işi reddetmeye başlamadan önce kaç eşzamanlı metin taramasına hizmet verebileceğini belirliyor; dolayısıyla seçici LIKE filtrelerinde 25 katlık azalma, ClickHouse'un yaygın olarak kullanıldığı log ve olay analitiği iş yükleri için gerçek bir kapasite kazancı. Ancak uçlar, başlık kadar önemli: regex kullanıcıları ve düz eşitlik sorguları yeniden yazım olmadan hiçbir fayda görmüyor ve seçici olmayan desenler küçük bir bellek kazanımı karşılığında hız kazanımı sağlamıyor. 26.10'a yükselen ekipler bu iyileştirmeyi yaygın LIKE yolunda ücretsiz olarak alıyor; aynı sonucu istiyorlarsa match() veya geniş string kolonlarına karşı eşitliğe dayanan sorguları incelemeliler.