JSON belgelerini depolama

Şunlar için geçerlidir: SQL Server 2016 (13.x) ve sonraki sürümler Azure SQL DatabaseAzure SQL Managed InstanceSQL database in Microsoft Fabric

SQL Veritabanı Altyapısı, standart SQL dilini kullanarak JSON belgelerini ayrıştırmanızı sağlayan yerel JSON işlevleri sağlar. JSON belgelerini SQL Veritabanı Altyapısı'nda depolayabilir ve JSON verilerini NoSQL veritabanında olduğu gibi sorgulayabilirsiniz. Bu makalede, JSON belgelerini depolama seçenekleri açıklanmaktadır.

JSON depolama biçimi

İlk depolama tasarımı kararı, JSON belgelerini tablolarda depolamaktır. Kullanılabilir iki seçenek vardır:

• LOB depolama - JSON belgeleri as-is json veya nvarchar veri türündeki sütunlarda depolanabilir. Yükleme hızı dize sütunlarının yükleme hızıyla eşleştiğinden hızlı veri yükleme ve alma için en iyi yol budur. Bu yaklaşım, sorgular çalışırken ham JSON belgelerinin ayrıştırılması gerektiğinden, JSON değerlerinde dizin oluşturma gerçekleştirilmezse sorgu/analiz süresinde ek bir performans cezasına neden olabilir.
• İlişkisel depolama - JSON belgeleri, , OPENJSON veya JSON_VALUE işlevleri kullanılarak tabloya eklenirken ayrıştırılabilir. Giriş JSON belgelerindeki parçalar json veyanvarchar veri türlerine sahip JSON alt öğelerini içeren sütunlarda depolanabilir. Yükleme sırasında JSON ayrıştırma yapıldığından bu yaklaşım yükleme süresini artırır; ancak sorgular, ilişkisel verilerdeki klasik sorguların performansıyla eşleşer.
• Şu anda SQL Server'da JSON yerleşik bir veri türü değildir.

Uyarı

JSON veri türü:

• , SQL Server 2025 veya Always-up-to-dategüncelleştirme ilkesi ile Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği için genel kullanıma sunulmuştur.
• SQL Server 2025 (17.x) ve Fabric'teki SQL veritabanı için önizleme aşamasındadır.

Klasik tablolar

JSON belgelerini SQL Server veya Azure SQL Veritabanı'nda depolamanın en basit yolu, belgenin kimliğini ve belgenin içeriğini içeren iki sütunlu bir tablo oluşturmaktır. Örneğin:

create table WebSite.Logs (
    [_id] bigint primary key identity,
    [log] nvarchar(max)
);

Veya desteklenen yerlerde:

create table WebSite.Logs (
    [_id] bigint primary key identity,
    [log] json
);

Bu yapı, klasik belge veritabanlarında bulabileceğiniz koleksiyonlarla eşdeğerdir. Birincil anahtar _id , her belge için benzersiz bir tanımlayıcı sağlayan ve hızlı aramaları etkinleştiren otomatik olarak artan bir değerdir. Bu yapı, bir belgeyi kimlikle almak veya depolanan bir belgeyi kimlikle güncelleştirmek istediğiniz klasik NoSQL senaryoları için iyi bir seçimdir.

• JSON belgelerini depolamak için yerel json veri türünü kullanın.
• nvarchar(max) veri türü, boyutu 2 GB'a kadar olan JSON belgelerini depolamanıza olanak tanır. Ancak JSON belgelerinizin 8 KB'tan büyük olmadığından eminseniz performans nedenleriyle nvarchar(max) yerine nvarchar(4000) kullanmanızı öneririz.

Önceki örnekte oluşturulan örnek tablo, geçerli JSON belgelerinin sütunda log depolandığını varsayar. Geçerli JSON'un sütuna kaydedilip kaydedilmediğini log öğrenmek istiyorsanız, sütuna bir CHECK kısıtlaması ekleyebilirsiniz. Örneğin:

ALTER TABLE WebSite.Logs
    ADD CONSTRAINT [Log record should be formatted as JSON]
                   CHECK (ISJSON([log])=1)

Birisi tabloya her belge eklediğinde veya güncelleştirdiğinde, bu kısıtlama JSON belgesinin düzgün biçimlendirildiğini doğrular. Kısıtlama olmadan, herhangi bir JSON belgesi herhangi bir işleme olmadan doğrudan sütuna eklendiğinden, tablo eklemeler için en iyi duruma getirilir.

JSON belgelerinizi tabloda depoladığınızda, belgeleri sorgulamak için standart Transact-SQL dilini kullanabilirsiniz. Örneğin:

SELECT TOP 100 JSON_VALUE([log], '$.severity'), AVG( CAST( JSON_VALUE([log],'$.duration') as float))
 FROM WebSite.Logs
 WHERE CAST( JSON_VALUE([log],'$.date') as datetime) > @datetime
 GROUP BY JSON_VALUE([log], '$.severity')
 HAVING AVG( CAST( JSON_VALUE([log],'$.duration') as float) ) > 100
 ORDER BY AVG( CAST( JSON_VALUE([log],'$.duration') as float) ) DESC

JSON belgelerini sorgulamak için herhangi bir T-SQL işlevini ve sorgu yan tümcesini kullanabilmeniz güçlü bir avantajdır. SQL Server ve SQL Veritabanı, sorgularda JSON belgelerini analiz etmek için kullanabileceğiniz hiçbir kısıtlamaya neden olmaz. İşlevi olan JSON_VALUE bir JSON belgesindeki değerleri ayıklayabilir ve sorguda diğer herhangi bir değer gibi kullanabilirsiniz.

Zengin T-SQL sorgu söz dizimini kullanabilme özelliği, SQL Server ve SQL Veritabanı ile klasik NoSQL veritabanları arasındaki temel farktır; Transact-SQL büyük olasılıkla JSON verilerini işlemek için ihtiyacınız olan herhangi bir işleve sahip olursunuz.

Indexes

Sorgularınızın bir özelliğe (örneğin, JSON belgesindeki bir severity özellik) göre belgeleri sık sık aradığını fark ederseniz, sorguları hızlandırmak için özelliğine bir satır deposu kümelenmemiş dizini ekleyebilirsiniz.

Belirtilen yolda (yani yolda $.severity) JSON sütunlarından JSON değerlerini kullanıma sunan hesaplanan bir sütun oluşturabilir ve bu hesaplanan sütunda standart bir dizin oluşturabilirsiniz. Örneğin:

create table WebSite.Logs (
    [_id] bigint primary key identity,
    [log] nvarchar(max),
    [severity] AS JSON_VALUE([log], '$.severity'),
    index ix_severity (severity)
);

Bu örnekte kullanılan hesaplanan sütun, tabloya ek alan eklemeyen kalıcı olmayan veya sanal bir sütundur. Aşağıdaki örnekte olduğu gibi sorguların performansını geliştirmek için dizin ix_severity tarafından kullanılır:

SELECT [log]
FROM Website.Logs
WHERE JSON_VALUE([log], '$.severity') = 'P4'

Bu dizinin önemli özelliklerinden biri harmanlama duyarlı olmasıdır. Özgün nvarchar sütununuzun özelliği COLLATION varsa (örneğin, büyük/küçük harf duyarlılığı veya Japonca dil), dizin dil kurallarına veya nvarchar sütunuyla ilişkili büyük/küçük harf duyarlılığı kurallarına göre düzenlenir. JSON belgelerini işlerken özel dil kuralları kullanması gereken küresel pazarlar için uygulamalar geliştiriyorsanız bu harmanlama tanıma önemli bir özellik olabilir.

Büyük tablolar ve columnstore formatı

Koleksiyonunuzda çok sayıda JSON belgesi olmasını bekliyorsanız, aşağıdaki örnekte gösterildiği gibi koleksiyona kümelenmiş columnstore dizini eklemenizi öneririz:

create sequence WebSite.LogID as bigint;
go
create table WebSite.Logs (
    [_id] bigint default(next value for WebSite.LogID),
    [log] nvarchar(max),
    INDEX cci CLUSTERED COLUMNSTORE
);

Kümelenmiş columnstore dizini, depolama alanı gereksinimlerinizi önemli ölçüde azaltabilen, depolama maliyetini düşürebilen ve iş yükünüzün G/Ç performansını artırabilen yüksek veri sıkıştırma (25 kata kadar) sağlar. Ayrıca, kümelenmiş columnstore dizinleri JSON belgelerinizde tablo taramaları ve analizler için iyileştirildiğinden, bu dizin türü log analytics için en iyi seçenek olabilir.

Yukarıdaki örnek, sütuna değer _id atamak için bir sıra nesnesi kullanır. Hem diziler hem de kimlikler, kimlik sütunu için geçerli seçeneklerdir.

Belgeleri ve bellek için iyileştirilmiş tabloları sık sık değiştirme

Koleksiyonlarınızda çok sayıda güncelleştirme, ekleme ve silme işlemi bekliyorsanız JSON belgelerinizi bellek için iyileştirilmiş tablolarda depolayabilirsiniz. Bellek için iyileştirilmiş JSON koleksiyonları verileri her zaman bellekte tutar, bu nedenle depolama G/Ç ek yükü yoktur. Buna ek olarak, bellek için iyileştirilmiş JSON koleksiyonları tamamen kilitsizdir; yani belgelerdeki eylemler başka bir işlemi engellemez.

Klasik koleksiyonu bellek için iyileştirilmiş bir koleksiyona dönüştürmeniz gereken tek şey, aşağıdaki örnekte gösterildiği gibi tablo tanımından sonra seçeneği belirtmektir WITH (MEMORY_OPTIMIZED=ON) . Ardından JSON koleksiyonunun bellek için iyileştirilmiş bir sürümüne sahip olursunuz.

CREATE TABLE WebSite.Logs (
  [_id] bigint IDENTITY PRIMARY KEY NONCLUSTERED,
  [log] nvarchar(max)
) WITH (MEMORY_OPTIMIZED=ON)

Bellek için iyileştirilmiş tablo, sık sık değişen belgeler için en iyi seçenektir. Bellek için iyileştirilmiş tabloları değerlendirirken performansı da göz önünde bulundurun. Mümkünse performansı önemli ölçüde artırabileceğinden bellek için iyileştirilmiş koleksiyonlarınızda JSON belgeleri için nvarchar(max) yerine nvarchar(4000) veri türünü kullanın. Json veri türü bellek için iyileştirilmiş tablolarda desteklenmez.

Klasik tablolarda olduğu gibi, hesaplanan sütunları kullanarak bellek için iyileştirilmiş tablolarda açığa çıkarmakta olduğunuz alanlara dizinler ekleyebilirsiniz. Örneğin:

CREATE TABLE WebSite.Logs (

  [_id] bigint IDENTITY PRIMARY KEY NONCLUSTERED,
  [log] nvarchar(max),

  [severity] AS cast(JSON_VALUE([log], '$.severity') as tinyint) persisted,
  INDEX ix_severity (severity)

) WITH (MEMORY_OPTIMIZED=ON)

Performansı en üst düzeye çıkarmak için JSON değerini özelliğin değerini tutmak için kullanılabilecek en küçük olası türe dönüştürebilirsiniz. Yukarıdaki örnekte tinyint kullanılmıştır.

Yerel derlemeden yararlanmak için JSON belgelerini güncelleştiren SQL sorgularını saklı yordamlara da yerleştirebilirsiniz. Örneğin:

CREATE PROCEDURE WebSite.UpdateData(@Id int, @Property nvarchar(100), @Value nvarchar(100))
WITH SCHEMABINDING, NATIVE_COMPILATION

AS BEGIN
    ATOMIC WITH (transaction isolation level = snapshot,  language = N'English')

    UPDATE WebSite.Logs
    SET [log] = JSON_MODIFY([log], @Property, @Value)
    WHERE _id = @Id;

END

Bu yerel olarak derlenmiş yordam sorguyu alır ve sorguyu çalıştıran .DLL kod oluşturur. Yerel olarak derlenmiş bir yordam, verileri sorgulamak ve güncelleştirmek için daha hızlı bir yaklaşımdır.

Conclusion

SQL Server ve SQL Veritabanı'ndaki yerel JSON işlevleri, Aynı NoSQL veritabanlarında olduğu gibi JSON belgelerini işlemenizi sağlar. İlişkisel veya NoSQL gibi her veritabanının JSON veri işlemeye yönelik bazı avantajları ve dezavantajları vardır. JSON belgelerini SQL Server veya SQL Veritabanı'nda depolamanın temel avantajı tam SQL dil desteğidir. Zengin Transact-SQL dilini kullanarak verileri işleyebilir ve yüksek sıkıştırma ve hızlı analiz için columnstore dizinlerinden kilitsiz işleme için bellek için iyileştirilmiş tablolara kadar çeşitli depolama seçeneklerini yapılandırabilirsiniz. Aynı zamanda, NoSQL senaryonuzda kolayca yeniden kullanabileceğiniz olgun güvenlik ve uluslararasılaştırma özelliklerinden yararlanırsınız. Bu makalede açıklanan nedenler, JSON belgelerini SQL Server veya SQL Veritabanı'nda depolamayı göz önünde bulundurmanın mükemmel nedenleridir.

SQL Veritabanı Altyapısı'nda JSON hakkında daha fazla bilgi edinin

Yerleşik JSON desteğine görsel bir giriş için aşağıdaki videolara bakın:

• NoSQL ile ilişkisel dünyalar arasında bir köprü olarak JSON

İlgili içerik

• SQL Server içindeki JSON verileri
• JSON veri türü