Ukládání dokumentů JSON

Platí na: SQL Server 2016 (13.x) a novější verze Azure SQL Database Azure SQL Managed Instance SQL database in Microsoft Fabric

Databázový stroj SQL poskytuje nativní funkce JSON, které umožňují analyzovat dokumenty JSON pomocí standardního jazyka SQL. Dokumenty JSON můžete ukládat do databázového stroje SQL a dotazovat se na data JSON jako v databázi NoSQL. Tento článek popisuje možnosti ukládání dokumentů JSON.

Formát úložiště JSON

Prvním rozhodnutím o návrhu úložiště je ukládání dokumentů JSON do tabulek. K dispozici jsou dvě možnosti:

Úložiště LOB – Dokumenty JSON je možné ukládat v původním formátu ve sloupcích s datovým typem JSON nebo nvarchar. Toto je nejlepší způsob, jak rychle načíst data a ingestovat, protože rychlost načítání odpovídá rychlosti načítání řetězců sloupců. Tento přístup může zavést další penalizaci výkonu při době dotazování/analýzy, pokud není provedeno indexování hodnot JSON, protože nezpracované dokumenty JSON se musí analyzovat ve chvíli, kdy jsou dotazy spuštěné.
Relační úložiště – dokumenty JSON je možné analyzovat, když jsou vložené do tabulky pomocí OPENJSONJSON_VALUE funkcí nebo JSON_QUERY funkcí. Fragmenty ze vstupních dokumentů JSON lze uložit do sloupců obsahujících dílčí prvky JSON s datovými typy JSON nebo nvarchar. Tento přístup zvyšuje dobu načítání, protože analýza JSON se provádí během načítání; Dotazy ale odpovídají výkonu klasických dotazů na relační data.
V současné době v SQL Serveru není JSON integrovaným datovým typem.

Poznámka:

Datový typ JSON:

je obecně dostupná pro Službu Azure SQL Database a Azure SQL Managed Instance pomocí zásad aktualizaceSQL Serveru 2025 nebo Always-up-to-date.
je ve verzi Preview pro SQL Server 2025 (17.x) a databázi SQL v prostředcích infrastruktury.

Klasické tabulky

Nejjednodušší způsob, jak ukládat dokumenty JSON na SQL Serveru nebo Azure SQL Database, je vytvořit tabulku se dvěma sloupci, která obsahuje ID dokumentu a obsah dokumentu. Například:

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

Nebo pokud je to podporováno:

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

Tato struktura je ekvivalentní kolekci, které najdete v klasických databázích dokumentů. Primární klíč _id je hodnota automatického přírůstku, která poskytuje jedinečný identifikátor pro každý dokument a umožňuje rychlé vyhledávání. Tato struktura je dobrou volbou pro klasické scénáře NoSQL, ve kterých chcete načíst dokument podle ID nebo aktualizovat uložený dokument podle ID.

Použijte nativní datový typ JSON , kde je k dispozici pro ukládání dokumentů JSON.
Datový typ nvarchar(max) umožňuje ukládat dokumenty JSON, které mají velikost až 2 GB. Pokud jste si jistí, že vaše dokumenty JSON nejsou větší než 8 kB, doporučujeme místo nvarchar(4000) místo nvarchar(max) použít z důvodů výkonu.

Ukázková tabulka vytvořená v předchozím příkladu předpokládá, že platné dokumenty JSON jsou uloženy ve sloupci log . Pokud chcete mít jistotu log , že je ve sloupci uložený platný KÓD JSON, můžete do sloupce přidat omezení CHECK. Například:

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

Pokaždé, když někdo vloží nebo aktualizuje dokument do tabulky, toto omezení ověří, že je dokument JSON správně naformátovaný. Bez omezení je tabulka optimalizovaná pro vložení, protože jakýkoli dokument JSON se přidá přímo do sloupce bez jakéhokoli zpracování.

Při ukládání dokumentů JSON do tabulky můžete k dotazování na dokumenty použít standardní jazyk Transact-SQL. Například:

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

Je to výkonná výhoda, kterou můžete k dotazování dokumentů JSON použít libovolnou funkci T-SQL a klauzuli dotazu. SQL Server a SQL Database nezavádějí žádná omezení v dotazech, které můžete použít k analýze dokumentů JSON. Hodnoty z dokumentu JSON můžete extrahovat pomocí JSON_VALUE funkce a použít je v dotazu stejně jako jakoukoli jinou hodnotu.

Tato schopnost používat bohatou syntaxi dotazů T-SQL je klíčovým rozdílem mezi SQL Serverem a databázemi SQL a klasickými databázemi NoSQL – ve Transact-SQL pravděpodobně máte libovolnou funkci, kterou potřebujete zpracovat data JSON.

Indexes

Pokud zjistíte, že dotazy často prohledávají dokumenty podle určité vlastnosti (například severity vlastnosti v dokumentu JSON), můžete do vlastnosti přidat neclusterovaný index rowstore a urychlit tak dotazy.

Můžete vytvořit počítaný sloupec, který zpřístupňuje hodnoty JSON ze sloupců JSON v zadané cestě (tj. na cestě $.severity) a vytvořit standardní index pro tento vypočítaný sloupec. Například:

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

Vypočítaný sloupec použitý v tomto příkladu je neuchovávaný (virtuální) sloupec, který nevyužívá žádné další místo v tabulce. Index ho používá ix_severity ke zlepšení výkonu dotazů, jako je následující příklad:

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

Jednou z důležitých charakteristik tohoto indexu je to, že je si vědom řazení. Pokud má původní sloupec COLLATION vlastnost (například citlivost na malá a velká písmena nebo japonský jazyk), index je uspořádaný podle pravidel jazyka nebo pravidel citlivosti velkých a malých písmen přidružených ke sloupci nvarchar. Toto povědomí o kolaci může být důležitou funkcí, pokud vyvíjíte aplikace pro globální trhy, které při zpracování dokumentů JSON potřebují používat vlastní pravidla jazyka.

Velké tabulky a formát columnstore

Pokud očekáváte, že máte v kolekci velký počet dokumentů JSON, doporučujeme do kolekce přidat clusterovaný index columnstore, jak je znázorněno v následujícím příkladu:

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
);

Clusterovaný index columnstore poskytuje vysokou kompresi dat (až 25krát), která může výrazně snížit požadavky na prostor úložiště, snížit náklady na úložiště a zvýšit výkon vstupně-výstupních operací vaší úlohy. Clusterované indexy columnstore jsou také optimalizované pro prohledávání tabulek a analýzu dokumentů JSON, takže tento typ indexu může být nejlepší volbou pro log analytics.

Předchozí příklad používá objekt sekvence k přiřazení hodnot ke sloupci _id . Obě sekvence i identity jsou platné možnosti pro sloupec ID.

Časté změny dokumentů a tabulek optimalizovaných pro paměť

Pokud očekáváte velký počet operací aktualizace, vložení a odstranění v kolekcích, můžete dokumenty JSON ukládat do tabulek optimalizovaných pro paměť. Kolekce JSON optimalizované pro paměť vždy udržují data v paměti, takže nedochází k žádným režijním nákladům na vstupně-výstupní operace úložiště. Kromě toho jsou kolekce JSON optimalizované pro paměť zcela uzamčené – to znamená, že akce na dokumentech neblokují žádnou jinou operaci.

Jedinou věcí, kterou musíte převést klasickou kolekci na kolekci optimalizovanou pro paměť, je zadat WITH (MEMORY_OPTIMIZED=ON) možnost za definicí tabulky, jak je znázorněno v následujícím příkladu. Pak máte verzi kolekce JSON optimalizovanou pro paměť.

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

Nejlepší možností pro často se měnící dokumenty je tabulka optimalizovaná pro paměť. Při zvažování tabulek optimalizovaných pro paměť zvažte také výkon. Pokud je to možné, použijte datový typ nvarchar(4000) místo nvarchar(max) pro dokumenty JSON v kolekcích optimalizovaných pro paměť, pokud je to možné, protože může výrazně zlepšit výkon. Datový typ JSON není podporován v tabulkách optimalizovaných pro paměť.

Stejně jako u klasických tabulek můžete přidávat indexy do polí, která vystavujete v tabulkách optimalizovaných pro paměť pomocí počítaných sloupců. Například:

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)

Chcete-li maximalizovat výkon, přetypujte hodnotu JSON na nejmenší možný typ, který lze použít k uložení hodnoty vlastnosti. V předchozím příkladu se použije tinyint .

Můžete také umístit dotazy SQL, které aktualizují dokumenty JSON do uložených procedur, abyste získali výhodu nativní kompilace. Například:

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

Tento nativně zkompilovaný postup převezme dotaz a vytvoří .DLL kód, který dotaz spouští. Nativně zkompilovaný postup je rychlejší způsob dotazování a aktualizace dat.

Conclusion

Nativní funkce JSON v SQL Serveru a SQL Database umožňují zpracovávat dokumenty JSON stejně jako v databázích NoSQL. Každá databáze – relační nebo NoSQL – má určité výhody a nevýhody pro zpracování dat JSON. Klíčovou výhodou ukládání dokumentů JSON na SQL Serveru nebo SQL Database je plná podpora jazyka SQL. Pomocí bohatého jazyka Transact-SQL můžete zpracovávat data a konfigurovat různé možnosti úložiště, od indexů columnstore pro účely vysoké komprese a rychlé analýzy až po tabulky optimalizované pro bezblokované zpracování. Zároveň získáte výhodu vyspělých funkcí zabezpečení a internacionalizace, které můžete snadno použít ve scénáři NoSQL. Důvody popsané v tomto článku jsou skvělé důvody, proč zvážit ukládání dokumentů JSON do SQL Serveru nebo SQL Database.

Další informace o formátu JSON v databázovém stroji SQL

Vizuální úvod k integrované podpoře JSON najdete v následujících videích:

JSON jako most mezi NoSQL a relačními světy

Váš názor

Byla tato stránka užitečná?

Last updated on 2025-11-18