T-SQL Regex Artık Büyük Veride de Rahat: CU5 Detayı
LOB desteği neden bu kadar önemli öldü?
Regex tarafında uzun zamandır tuhaf bir sınırla uğraşıyorduk: küçük metinlerde işler yolunda, ama varchar(max) ya da nvarchar(max) gibi gerçek hayattaki büyük alanlara gelince iş yavaşlıyor. Log dosyası mı? Parça parça böl. HTML içerik mi? Dilimle. JSON payload mı? Önce kes, sonra işle… İşin aslı şu ki, bu yöntem hem yorucu hem de hata çağırıyor.
Ben bunu ilk kez 2018’de bir finans kuruluşunda gördüm — dürüst olayım, biraz hayal kırıklığı —. Ankara’daki ekipte, günlük log kayıtları tek satırda 1 MB’a yaklaşınca regex’i uygulama katmanına taşımışlardı; sonra aynı desenin üç ayrı kopyası ortaya çıktı, biri kaçtı, biri güncellendi, biri unutuldu. Klasik kurumsal karmaşa yanı. SQL tarafında doğal destek olunca o dağınıklığın ciddi kısmı azalıyor.
Bu yeni destek bana biraz eski usül “önce string’i küçült, sonra akıllı davran” alışkanlığının bittiğini hissettiriyor. Çok basit görünüyor, evet, ama etkisi bayağı hissediliyor. Çünkü artık veri — ki bu tartışılır — tabanının içinde kalan işi dışarı taşımak zorunda değilsiniz; özellikle raporlama, arşiv analizi. Denetim senaryolarında fark hemen ortaya çıkıyor.
Neyse uzatmayayım: CU5 ile gelen asıl yenilik sadece “büyük metni kabul etmesi” değil. Asıl mesele bunun pek çok regex fonksiyonlarına yayılması. Yanı arama yapıyorsunuz, sayıyorsunuz, değiştiriyorsunuz, bölüyorsunuz… hepsi aynı mantıkta çalışıyor.
CU5 ile ne değişti?
Kısa cevap şu: SQL Server 2025 CU5 ve Azure SQL tarafındaki güncellemelerle birlikte regex fonksiyonları artık LOB tiplerini daha rahat işliyor. Hem REGEXP_MATCHES hem REGEXP_SPLIT_TO_TABLE dahil olmak üzere yedi fonksiyonun tamamı için büyük girişler destekleniyor. Üstelik limit de fena değil; tek çağrıda 2 MB’a kadar input alabiliyor (buna dikkat edin)
İşin garibi, Bence burada kritik detay şu: pattern limiti hâlâ 8.000 byte civarında kalıyor. Açıkçası bu iyi bir şey. Çünkü gereğinden fazla büyüyen regex desenleri çoğu zaman zekâ belirtisi olmuyor; daha çok tasarım kokusu gibi dürüyor. İyi yazılmış bir desen kısa olur, geri kalan işi verinin düzeni halleder.
Peki neden?
| Konu | Önce | CU5 sonrası |
|---|---|---|
| LOB girişi | Tüm fonksiyonlarda yoktu | Tüm regex fonksiyonlarında var |
| Maksimum input | Kısıtlı / parçalama gerekiyordu | Tek çağrıda 2 MB |
| TVF desteği | Sınırlıydı | Pekâlâ çalışıyor |
| Taşınabilirlik | Sürüm bağımlılığı vardı | Azure SQL ve SQL Server arasında daha tutarlı |
Bir de şu var: Bu kabiliyetin Azure SQL Database, Fabric içindeki SQL Database. Always-up-to-date politikasındaki Managed Instance’larda. Mevcut durumda; SQL Server 2025 CU5 işe on-prem tarafta kapıyı açıyor (buna dikkat edin). Kurumsal yapılarda sürüm farkı yüzünden çıkan “bende çalıştı sende niye çalışmadı?” tartışmaları azalıyor. Azalıyor diyorum çünkü tamamen bitmiyor tabiî — o ayrı dert. Ajan Yeteneklerinde Yeni Dönem: Tek Sağlayıcıyl… yazımızda bu konuya da değinmiştik.
Sahada bunun karşılığı ne?
Size bir şey söyleyeyim, Açık konuşayım, sahada en çok üç yerde işe yarar görüyorum: log analizi, belge tarama ve veri temizleme. Mesela de de güvenlik ekipleri bazen ham IIS loglarını ya da uygulama günlüklerini hızlıca sorgulamak istiyor (ki bu çoğu kişinin gözünden kaçıyor). Eskiden önce ETL yazılırdı, sonra staging tabloya alınırdı… şimdi bazı işleri doğrudan T-SQL içinde halletmek mümkün hâle geliyor.
Kendi deneyimimden konuşuyorum, Bunu Mart 2024’te İstanbul’da bir perakende müşterisinde test etmiştik; ürün açıklamaları HTML karışık geliyordu ve araya gömülü kodlar yüzünden temizlik işi can sıkıyordu. İlk denemede ben de ufak bir hata aldım: beklediğim eşleşme gelmedi çünkü deseni gereğinden fazla agresif kurmuştum. Çözümü basit çıktı — regex’i sadeleştirdim ve satır sonu karakterlerini daha dikkatli ele aldım.
Bir şey dikkatimi çekti: E tabi her şey güllük gülistanlık değil. Büyük metin üzerinde doğrudan regex kullanmak bazen performans açısından hâlâ dikkat istiyor; özellikle indeks stratejiniz zayıfsa tablo taraması sizi tokatlar resmen! Yanı özelliğin gelmesi tek başına yetmiyor, sorgu planını da düşünmek gerekiyor (yanlış duymadınız)
Bunu biraz açayım. Bu konuyla ilgili Kubernetes v1.36: Sharded Watch ile Ölçek Duvarını Aşmak yazımıza da göz atmanızı tavsiye ederim.
Küçük ekip vs enterprise yapı
Küçük bir startup iseniz bu özellik size hız kazandırır; ekstra servis kurmadan birkaç sorguyla işi çözersiniz (evet, doğru duydunuz). Hatta teknik borcu biraz azaltırsınız çünkü uygulama koduna özel parser yazma ihtiyacı düşer.
Büyük kurumsal yapılarda işe olay biraz farklıdır. Orada mesele sadece “çalışsın” değildir; (söylemesi ayıp) audit izi olsun mu, yetki modeli nasıl olacak, regülasyon açısından veriyi nerede işliyoruz soruları üst üste biner (ve hiç acımadan). Benim önerim şu: küçük ekipse direkt deneyin; enterprise işe önce pilot kapsam belirleyin, sonra yaygınlaştırın. Daha fazla bilgi için GitHub Copilot for Eclipse Açık Kaynak Oldu: Bu Ne Değiştiriyor? yazımıza bakabilirsiniz.
Maliyet açısından bakınca ne çıkıyor?
Maliyet hesabını TL bazında düşününce resim netleşiyor: Uygulama katmanında çalışan bir parser için ekstra compute ayırıyorsunuz, belki başka servis ayağa kaldırıyorsunuz ya da Function/App Service tüketimini artırıyorsunuz. Halbuki bazı kullanım senaryolarında SQL içinde çözmek gayet idare eder bir seçenek oluyor. Daha fazla bilgi için C#’ta Bellek Güvenliği Neden Şimdi Daha Önemli? yazımıza bakabilirsiniz.
Garip gelecek ama, Ama dürüst olayım: Her şeyi database’e yüklemek de doğru değil. Eğer işlem yoğunluğu yüksekse veya regex operasyonu sürekli koşuyorsa CPU baskısı artabilir. O noktada alternatif olarak Azure Data Factory benzeri akışlarla ön işleme yapmak ya da Python/.NET tarafında toplu parsing yapmak daha mantıklı olabilir. MSVC’de SPGO Neyi Değiştiriyor: PGO’nun Pratik Hali yazımızda bu konuya da değinmiştik.
Neden RE2 önemli?
T-SQL regex’in altında RE2 motorunun olması bana güven veriyor doğrusu. Çünkü RE2 geri izlemeli klasik motorlar gibi davranmıyor. Bazı kötü yazılmış desenlerin sistemi kilitlemesi riski ciddi biçimde düşüyor. ReDoS tarafındaki avantaj boş laf değil — üretimde gecenin üçünde alarm çaldıracak türden sorunların önüne geçebiliyor.
RE2’nın en sevdiğim yanı şu: performans vaat etmiyor sadece… öngörülebilirlik veriyor.
Bu ikisi kurumsalda çoğu zaman aynı şeyden daha değerli.
Bunu AZ-500 hazırlığı yaptığım dönemde tekrar fark ettim aslında; güvenlikte “iş görür” ile “öngörülebilir” arasındaki çizgi çok ince oluyor.
Regex konusunda da aynısı geçerli.
Kodu güçlü yapan şey yalnızca esneklik değil…
Şu ufak detaya bakın: sınırlar neler?
- Sadece giriş boyutu büyüdü diye sınırsız sanmayın; tek çağrıda 2 MB sınırı var.
- Email doğrulamak için devasa pattern yazmayın; kısa ve okunur tutun.
- Aynı sorguyu milyonlarca satırda koşturacaksanız plan maliyetine bakın.
- Büyük blob’ları doğrudan işlemeye başlamadan önce filtre koyun; boş yere CPU harcamayın.
- Eğer çıktı sadece birkaç satır olacaksa TVF yerine scalar fonksiyon yeterli olabilir.
Sahada nasıl uygularım?
SELECT
Id,
REGEXP_LIKE(LogTextMaxColumn, 'error|fail|exception') AS HasProblem
FROM dbo.AppLogs
WHERE CreatedAt >= DATEADD(DAY,-7,SYSDATETIME());
Şunu fark ettim: Lafı gevelemeden söyleyeyim: ilk adımınız mevcut iş yükünü sınıflandırmak olsun.
Hangi kolonlar gerçekten LOB?
Hangileri yanlışlıkla MAX tipine dönüşmüş?
Bunları ayıklarsanız neyi regex’e sokacağınız netleşir.
Ben genelde müşterilerde üç aşamalı giderim:
önce örnek veri alırım,
sonra küçük pilot test yaparım,
en sonda üretime çıkarırım…
- Büyük metin kolonlarını listeleyin.
- Sorguyu küçük örnek üzerinde ölçün.
- Aynı deseni uygulama katmanı ile karşılaştırın.
- Zamanlama ve CPU etkisini izleyin.
- Pilot başarılıysa yaygınlaştırın.
Pardon… yukarıdaki son iki madde Japonca noktalama olmuş gibi görünüyorsa önü unutun;
neyse asıl mesele şu:
her zaman önce ölçün.
Bu servis güzel ama henüz tam anlamıyla “tak çalıştır mucizesi” değil.
Biraz pişmesi gereken yerler var,
özellikle ağır tablolar üzerinde sorgu tasarımı kısmında.
Ama yön doğru,
ona şüphe yok.
“””
Sıkça Sorulan Sorular
T-SQL regex hangi sürümlerde LOB tipi destekliyor?
Azure SQL Database’de ve Always-up-to-date politikasındaki Azure SQL Managed Instance’da bu destek mevcut. SQL Server tarafında işe CU5 ile geliyor. Fabric içindeki SQL Database de kapsama dahil edilmiş.
REGEXP_SPLIT_TO_TABLE büyük metinlerde kullanılabilir mi?
Evet, kullanılabiliyor aslında. Yeter ki tek çağrıdaki giriş limiti olan 2 MB aşılmasın. Tecrübeme göre log veya JSON parçalama gibi işlerde baya işe yarıyor.
Pattern boyutunda sınır var mı?
Evet, yaklaşık 8 KB seviyesinde bir limit var. Açıkçası çoğu okunabilir regex bundan çok daha küçük oluyor zaten, yanı pratikte pek sorun çıkarmıyor.
Bu özellik performansı her zaman iyileştiriyor mu?
Hayır. Veri miktarı büyüdüğünde bazı durumlarda CPU maliyeti artabiliyor. Yanı bence amaç sadece kolaylık; performansı muhtemelen ölçmek lazım.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
4 comments