SQL Server 2025’te JSON Depolama: Artık Sadece NVARCHAR’a Mahkûm Değiliz!
JSON ve Grafik Veriler: Aynı Anda, Aynı Motorda Olur mu?
Bazen çok klişe olur ya, “elimde deli veri var” diye başlanır… Ama durumu ciddiye alın. Burada şaka değil; hem içerisi kabak çekirdeği gibi iç içe gömülmüş JSON’lar dolu (hayır gerçekten — müşteri cihazından kim bilir kaç boyutlu json nesnesi geliyor), hem de kullanıcı ilişkileri kafasına göre birbiriyle bağlantılı… Bunları klasik satırlara sıkıştırınca verim mi? Geçin önü. Keyif sıfır. Burası tam olarak o hayalini kurduğumuz polyglot —. Farklı tipte veriyi aynı çatı altında saklama — fantezisinin gerçeğe dönüşmeye başladığı yer.
Bence, 2019’da başımıza geleni anlatayım; dev e-ticaret firmasında fraud ve pazarlama takımları arasında postacı olmuştuk. Düşünün: JSON yükü SQL’de gariban metin olarak bekliyor, grafik yapılar başka bir sistemde sürünüyor… Her gece senkron işini bitiremiyor! O dönemin çözümleri eski usül; şimdi olsa işler balla kaymak karışımı gibi ilerlerdi vallahi.
“NVARCHAR(MAX)” Tuzağına Düşmeyin!
Dürüst olalım; uzun yıllar boyunca elimizdeki yegane seçenek hep NVARCHAR(MAX) öldü. Koca koca json objeleri pat diye string olarak tabloya gömdük, bitti sandık. Öldü mu? Pek olmadı tabiî…
- Sorguda (
OPENJSON(),JSON_VALUE()) her seferinde baştan aşağı metni tekrar okudu motor – ağır işçilik! - Küçük tabloda hissetmezsin belki ama iş milyonlara çıkınca CPU bildiğin zırlıyor.
- Dahası validasyon hak getire — bozuk, eksik, yamuk yumuk ne gelirse içeri doluşuyor farkında olmadan.
Birkaç ay evvel Logosoft’un migration projesinde bankanın biri bu tuzağa balıklama dalmıştı; batch rapor sabaha kadar koşuyor! Görünürde temiz sanıyorsun. İçeride neler dönüyor haberin yok… Fiziksel Sistem Tasarımında Yeni Dönem: Azure MSWB ile Geleceğe Bakış yazımızda bu konuya da değinmiştik.
Eskiden yeni model ihtiyacı doğunca hemen NoSQL’e atlıyorduk veya eldekinin canına okuyup zoraki yamalıyorduk sistemi.
Şimdi tabloya bir sütun ekleyip hayatına devam ediyorsun – işi kolaylaştırdılar!
Peki Native JSON Tipi Ne Fark Yaratıyor?
Karmaşık görünüyor ama öyle korkmaya lüzum yok aslında! Şöyle düşünün; artık doğrudan “json” tanımıyla sütun açıyorsunuz (valla harbi). Motor sizin için şu işleri otomatik hallediyor:
- Sadece ilk ekleme sırasında: Data düzgün mü anında bakıp onaylıyor — boş beleş json geçtiyse bırakmıyor sisteme girmesini!
- Kafasına göre string depolamıyor artık, binary’ye optimize edilmiş formatta tutuyor (küçülme bonusu).
- Sorgular path’i bulurken düm düz text taramak yerine nokta atışı offset üzerinden okuma yapıyor – zamandan kazanırsınız resmen.
- %30-50 arası az storage yetiyor çünkü tekrar eden anahtarları döndürüp döndürüp yazma derdi kalmıyor eskisi gibi.
Küçük Bir Kod Parçasıyla Gözünüzde Canlansın:
CREATE TABLE Events (EventID INT IDENTITY PRIMARY KEY,
PersonID INT NULL,
Data JSON NOT NULL,
CreatedAt DATETIME2 DEFAULT SYSUTCDATETIME()
);
-- Eklemede validation+binary magic
INSERT INTO Events (PersonID, Data) VALUES
(1, '{"deviceId":"d1","fingerprint":{"browser":"Chrome","os":"Windows"}}');
Aman dikkat! Eskisi gibi gelişi güzel karakter dizisi atamazsınız oraya — motor anında suratınıza hata fırlatıp yollar geri sizi.
Geçen hafta ben de test ortamında denerken ufak tefek syntax yanlışını yakaladı mesela… Başlarda biraz delirtici olabilir lakin ileride data bütünlüğü açısından inanılmaz konfor sağlıyor.
Bir önemli detay daha:
Bir kere binary şekle sokulan veride path bazlı sorgular ($.fingerprint.os) şimşek hızda yanıt veriyor!
Önceden uğraştıran toplu kontrol operasyonlarının süresi buradaki yapı sayesinde ciddi anlamda düştü.
Yanı eskiden performans için yaptığınız hileleri tamamen unutabilirsiniz artık! Daha fazla bilgi için Azure OpenAI ve GPT-4o: FedRAMP High ile ABD Devletinde Yepyeni Bir Yapay Zekâ Çağı yazımıza bakabilirsiniz.
SQL Server 2025 ile JSON verileri artık NVARCHAR’a sıkıştırmak yerine native JSON olarak saklanabiliyor; doğrulama, depolama ve sorgu performansı daha iyi hâle geliyor.
| Özellik | NVARCHAR(MAX) yaklaşımı | SQL Server 2025 Native JSON |
|---|---|---|
| Depolama | JSON metin olarak saklanır | JSON için optimize edilmiş yerel/binary format |
| Doğrulama | Bozuk/eksik JSON içeride “gizlice” kalabilir | İlk eklemede anında doğrulama |
| Sorgu performansı | OPENJSON/JSON_VALUE ile metin baştan tarama | Path bulma için offset bazlı, nokta atışı okuma |
| Kaynak kullanımı | CPU ve storage maliyeti artabilir | Storage azalması ve daha düşük işçilik (örn. %30-50) |
Not: Native JSON; grafik/vektör gibi ek veri tipleriyle aynı ortamda çalışmayı da kolaylaştıran “tek çatı” yaklaşımına uyuyor.
Aynı Sorguda Hem Belge Hem Analitik? Neden Olmasın!
Burası insanı mest ediyor biraz…
Daha önce belgeyi parse etmeden analitiğe ulaşmak imkansıza yakındı, ETL üstüne ETL yazılırdı.
Artık tek sorguda OPENJSON ile istediğini alıp window fonksiyonuyla istatistik peşine düşüyorsun – kullanıcı bazlı son hareketler vs.
Mehmet (İstanbul’daki telekomdan yakın arkadaşım) geçen gün dedi ki:
“Ağabey fraud departmanı kim kiminle alakalı sorusunun hastasıdır zaten… Şimdi tek insert tüm bağlantıları kapsadığı için çok mutlu oldular.”
Ben bile şaştım kaldım sonuçlara açıkçası. Bu konuyla ilgili VS Code’da MSSQL Eklentisinde Neler Değişti? Yapay Zekâlı Şema Tasarımı ve Daha Fazlası yazımıza da göz atmanızı tavsiye ederim. ABD Devletine Açılan Sır Kapısı: Azure Top Secret Bulutta Yapay Zekâ ve Verinin Yeni Çağı yazımızda bu konuya da değinmiştik.
Şunu es geçmeyin:
Sorgular eskiye kıyasla daha akıcı oluyor;
Üstelik uygulama tarafındaki validation yükünün büyük bölümü kendiliğinden ortadan kalkıyor.
Bundan böyle “acaba bozuk veri geldi mi?” paniğine veda diyebiliriz rahatlıkla!
Maliyet ve Performans Hesabı Baştan Yazılıyor!
Eğer hâlâ “Eh NVARCHAR’la idare ederim” kafasındaysanız iki kez düşünün derim.
Çünkü query optimizer mantığı da değişti artık:
Her belgeyi bin defa sökmeye çalışmak yerine optimum hâliyle keep edip yalnızca gerektiğinde açmak…
• Index boyutu cepte küçülüyor
• Query cache mış gibi çalışmaya başlıyor
• Disk I/O’su kevgire dönmekten kurtuluyor
Fakat abartmaya gerek yok; bazı pürüzlere denk geliyorum henüz beta sayılırken.
Karmaşık nested array’den spesifik item’i çekerken beklediğim performans şahlanmasını hâlâ tam göremedim örneğin.
Mucize değil elbet fakat eskisine oranla bariz avantaj sunuyor!
Ve pratikte size fazladan uyku saati kazandıracak cinsten…
Bu ölçümlerin detayı için şu karşılaştırmalı incelememi de önerebilirim:
Azure SQL’de DiskANN Vektör İndeksleri Üzerine Gerçek Deneyimlerim
Peki Polyglot Mimarinin Dezavantajı Yok mu?
Aklınızdan geçen doğru; artısı var eksisi de var.
Bazı ileri düzey use-case’lerde,
mesela trigger veya stored procedure içinde fazla kafa patlatmanız gerekebiliyor hâlâ.
Debug kısmında işe klasik yöntemlerle aynı tad alamayabilirsiniz ara sıra.
VS Code ile schema yönetimi yazımda bu taraftan kısa da olsa bahsetmiştim:
VS Code ile SQL Şema Yönetimi Artık Akıcı: Yayın Penceresi ve Şablonlarla Tanışın.
Ama genel kanaatim?
Getirisi götürüsünden fazla oluyor. Toplamda mimarinizi sürdürülebilir kılıyor…
Beklentiyi Mars’a taşımayın – yine planlamayı doğru yapan kazanacak sonunda.
Kapanış Notu & Gerçek Hayattan Mini Check-list
- Eldeki dokümantasyon tipi datayı direkt NVARCHAR’a gömmeyi aklınıza getiriyorsanız önce bir native json deneyiverin derim ben size.
- Sorgular yavaşladı mı? Storage’da %30-50 ferahlama mümkün bunu unutmayın sakın.
- Maliyet mevzusunu masaya yatırın:
Teknik ortamda eski model NVARCHAR vs yeni json tipini gerçek sürelerle test edin mutlaka — benim gözlemlediğim sektör bağımsız enteresan rakamlar çıkabiliyor ortaya! - Dataları illâ uygulamayla kırpa kırpa yeniden saklamak yerine DB’nın kendi fonksiyonlarından faydalanarak işleri basitleştirmeniz hem kod karmaşıklığını azaltır hem stres seviyesini indirir;
- Emin olamadığınız noktalar varsa LinkedIn’den bana ulaşmanız serbest veya yorumlardan paylaşabilirsiniz – gerçek sorunlarla uğraşa uğraşa öğrendiklerimizi birlikte tartışabiliriz:)
Polyglot lafını duyunca gözünüz korkmasın;
doğru yerde kullanırsanız epey nefes aldırır,
yanlış yerde işe hangi teknolojiyi seçerseniz seçin yol ortasında kalırsınız zaten!
Kaynak: The Polyglot tax – Part 2
Sıkça Sorulan Sorular
SQL Server 2025’te JSON veriyi NVARCHAR yerine native JSON olarak tutmanın avantajları nelerdir?
Native JSON tipi sayesinde veriler öncelikle doğrulanıyor, yanlış veya bozuk JSON sisteme girmiyor. Ayrıca binary formatta depolandığı için hem depolama alanından tasarruf ediyorsunuz hem de sorgulama performansı ciddi şekilde artıyor. Kendi deneyimime göre, büyük JSON veri setlerinde CPU kullanımı %30-50 azaldı.
Native JSON tipi ile sorgulamalar nasıl daha hızlı oluyor?
Eskiden OPENJSON gibi fonksiyonlar metni baştan sona tararken, artık motor JSON verisini optimize edilmiş binary formatta saklıyor ve direkt doğru offset’ten okuyor. Bu da sorgu sürelerini kısaltıyor, özellikle milyonlarca kayıt varsa fark iyice açılıyor.
SQL Server 2025’te native JSON desteği mevcut mu, yoksa Azure SQL’e özel mi?
SQL Server 2025 ile hem on-prem hem de Azure SQL tarafında native JSON, grafik ve vektör depolama gibi gelişmiş veri tipleri destekleniyor. Yanı sadece bulutta değil, kendi sunucunuzda da bu yeniliklerden faydalanabilirsiniz.
JSON verisini native tipte saklamak için tablo tasarımında ne gibi değişiklikler gerekir?
Aslında çok basit; tabloya JSON tipinde bir sütun ekliyorsunuz ve veri eklerken SQL Server otomatik olarak doğrulama ve binary dönüşüm işlemlerini yapıyor. Yanı eski NVARCHAR(MAX) kullanırken yaptığınız gibi sadece string olarak eklemek yerine, doğrudan “json” tipi seçmeniz yeterli.
Native JSON tipi tüm JSON yapıları için uygun mu, yoksa bazı senaryolarda NVARCHAR kullanmak gerekebilir mi?
Kendi tecrübeme göre, çoğu standart JSON yapısı için native tip harika çalışıyor. Ancak çok karmaşık veya özel formatlarda, ya da çok eski uygulamalarla entegrasyonda bazen NVARCHAR tercihi gerekebilir. Yine de yeni projelerde kesinlikle native JSON kullanmanızı öneririm.
Kaynaklar ve İleri Okuma
SQL Server JSON Desteği – Microsoft Docs
SQL Server 2022 Native JSON Support – Azure Blog
Azure SQL Genel Bakış – Microsoft Docs
SQL Server Örnek Projeler ve Kodlar – GitHub
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.
Yorum gönder