Velký soubor JSON se neotevírá: vyberte správný nástroj podle velikosti

Soubor JSON o 45 MB se parsuje za 249 milisekund. Tu půlminutu čekání způsobí vykreslení pěti milionů řádků textu a 3,5 milionu uzlů stromu. Kdo si tyhle dvě věci splete, vždy hledá viníka na špatném místě.

Jedna: nejdřív změřte — parsing nikdy není úzké hrdlo

Dvojklik na JSON export v řádu desítek MB, editor se točí třicet sekund a reflex říká „parsing JSONu je pomalý". Měření říkají opak. Na našem stroji (Node 22) jsme vygenerovali vzorek 500 000 záznamů s pěti poli (id, email, active, score, tags), 45 MB v kompaktní podobě:

Parsing skončil za čtvrt sekundy. Parser dopsal práci dřív, než jste pustili myš. Všechny následující sekundy padly na vrstvu „ukázat výsledek člověku": textový editor musí vysázet pět milionů řádků, aplikovat zvýraznění syntaxe a udržet buffer zpětného volání; stromový prohlížeč musí vytvořit DOM prvek pro každý z 3,5 milionu uzlů — a prohlížeče klopýtnou kolem sta tisíc uzlů a odezvu ztrácejí dlouho před milionem.

Závěr ukazuje úplně jiným směrem: nebojujte s renderováním — vezměte nástroj, který nevykresluje vše najednou.

Dvě: proč to zamrzne — počet řádků a uzlů je skutečná cena

Velikost souboru je jen povrch. Nástroje láme dvě odvozená čísla:

1. Počet řádků. 45 MB kompaktního JSONu je po formátování pět milionů řádků. Na jakoukoli část se díváte, editor musí nejdřív vybudovat řádkovou strukturu celého souboru, rozřešit stav zvýraznění a alokovat buffery — náklady úměrné celkovému počtu řádků.
2. Počet uzlů. Půl milionu záznamů × (jeden objekt + pět polí) je 3,5 milionu uzlů. Každý prohlížeč, který postaví celý strom před zobrazením, platí stejnou paměť a čas, ať rozbalíte jednu větev, nebo všechny.

Odtud dvě neintuitivní důsledky. Formátovat před prohlížením škodí — soubor roste z 45 na 71 MB a počet řádků se zčtyřicetinásobí, čistě dodatečný tlak na nástroj. Strkat soubor přes cat do terminálu škodí taky — scrollback buffer se stane novým úzkým hrdlem; na první bajty stačí head -c 2000.

Tři: vybrat nástroj podle velikosti — rozhodovací tabulka

Různé velikosti vyžadují úplně jiné nástroje. Když zkombinujeme měření výše s publikovanými vodítky (OpenFormatter staví komfortní zónu online nástrojů na 2-5 MB; PureJSON odhaduje paměť po parsování dokumentu 500 MB na 2-4 GB), vznikne tahle tabulka:

Nástroj /parse na tomto webu pokrývá první stupeň: stromový náhled a validaci. Větší patří do desktopové aplikace, aby desítky MB nikdy nepřilepily do webové stránky.

Čtyři: neotevírejte soubor — nejdřív se ptejte na strukturu

U neznámého velkého JSONu je prvním krokem ne otevření, ale pár sekund na zjištění tvaru. jq odpoví na tři otázky asi za 200 ms:

复制# Nahoře pole nebo objekt? Kolik záznamů?
jq 'if type == "array" then {type: "array", count: length} else {type: "object", keys: (keys|length)} end' huge.json

# Jak vypadá první záznam (jeden, bez záplavy)?
jq '.[0]' huge.json | head -40

# Všechny názvy polí (z prvního záznamu)
jq '.[0] | keys' huge.json

Jakmile je struktura známá, většina požadavků se zredukuje na „vytáhnout pole" — soubor ani nemusí být otevřený. Například chcete e-mail každého uživatele:

复制jq -r '.[].email' huge.json | less
# Nasaďte filtr
jq -r '.[] | select(.active == true) | .email' huge.json

Pravidlo je jednoduché: na „dívat se" prohlížeč s virtualizovaným renderováním; na „hledat a vytahovat" jq. Obě role v jednom nástroji nemíchejte.

Pět: paměťový útes — normální režim proti streamování, rozdíl 150×

U téhož vzorku 45 MB změřil /usr/bin/time -v špičkovou paměť jq ve dvou režimech:

Normální režim čte celý soubor a staví graf objektů; špička 542 MB potvrzuje pravidlo „graf objektů ≈ 7-12× velikost textu". --stream konzumuje vstup token po tokenu a drží paměť v jednotkách MB — za cenu delšího celkového času. Za hranicí gigabajtu odděluje tahle rozdílnost „funguje" od „zabil ho OOM killer":

复制# Pro soubory větší než paměť: --stream je jediný režim, který nikdy nenahraje vše
jq --stream -n 'fromstream(1|truncate_stream(inputs))' huge.json

Pythoní ekvivalent je ijson: ijson.items(f, 'item') vydává prvky pole po jednom se stejně konstantní pamětí. Společná cena těchto nástrojů: vzdát se náhodného přístupu — stream je jediný průchod vpřed a druhý průchod znamená znovučtení souboru.

Šest: kolik ukáže prohlížeč — meze lokálního zpracování

Online nástroje se dají používat, v mezích. Moderní karta prohlížeče má zhruba 1-4 GB paměti; soubor 45 MB naparsovaný na graf plus strom obvykle přežije. Několik set MB je už u okraje útesu. Při výběru online prohlížeče vyžadujte tři věci:

1. Zpracování probíhá lokálně (vložený obsah se nikdy neposílá na server) — chrání to data i šetří čas nahrávání; všechny nástroje tohoto webu běží zcela v prohlížeči a fungují offline;
2. Parsing běží ve Web Workeru — hlavní vlákno nezamrzne a zaseknutí stojí kartu, ne celý prohlížeč;
3. Strom je virtualizovaný nebo líný — složené větve stojí skoro nic, vykresluje se jen rozbalené.

Na tomto webu: /parse hodí se na průzkum struktury a hledání chyb u souborů do několika desítek MB; nad to jq nebo desktopová aplikace, prohlížeč zůstává pro malé úseky.

Sedm: správný formát odstraní polovinu problémů

Pokud ovlivňujete, jak soubor vzniká, lepší prohlížeč je špatný lék — zařiďte, aby nevyrůstal v „jedno obrovské pole":

• NDJSON/JSONL: jeden záznam na řádek. Přidávání nepřepisuje soubor, head, grep, tail, split fungují přímo; useknutý soubor ztratí jen poslední řádek. V naší příručce JSONL je úplný postup rozborku rozbitých řádků.
• Stránkované exporty: API vracející 100 000 záznamů má přijímat parametry stránkování — po 100 je to příjemnější pro obě strany.
• Tabulková data nejsou JSON: jeden záznam na řádek, pevná pole bez zanoření — to je tabulka. CSV nebo Parquet jsou menší a mají bohatší ekosystém.

Číslo k zapamatování: přetněte napůl pole s 500 000 záznamy a první polovina zůstává platným NDJSON souborem (polovina záznamů přežije), zatímco odpovídající jediné obrovské pole se ztratí celé. 500 zachráněných záznamů z 501 je víc než nula.

Osm: checklist

• Nejdřív zjistěte strukturu přes jq '.[0] | keys' nebo výběr 500 záznamů;
• Nikdy neformátujte jen proto, abyste soubor otevřeli — zdvojnásobení řádků to jen zpomalí;
• Pod 2 MB: online stromový náhled; nad 20 MB: příkazová řádka; nad 1 GB: vždy --stream nebo ijson;
• Ověřte, že online nástroj zpracovává lokálně (vložený obsah neopustí prohlížeč);
• Když ovládáte generátor, přejděte na NDJSON nebo stránkování a obrovská pole odstraňte u zdroje.

FAQ

Proč editor otevírá JSON desítky sekund, když to program parseuje za 200 ms?

Parsing je nativní kód, který mění text na datovou strukturu: 249 ms na našem vzorku 45 MB. Editor se vázne na prezentaci: pět milionů řádků k vysázení, zvýraznění a bufferu zpětného volání; strom buduje DOM pro 3,5 milionu uzlů. Virtualizovaný prohlížeč nebo přímé vytahání přes jq to všechno obchází.

Přeteče jq u JSON nad 1 GB?

V normálním režimu ano: nahraje celý dokument a graf objektů šlape na 7-12× velikost souboru. S --stream se vstup konzumuje token po tokenu: náš test na 45 MB dosáhl špičky 3,6 MB a paměť zůstává plochá při jakékoli velikosti — za cenu jediného sekvenčního průchodu.

Jak velké soubory zvládnou online JSON nástroje?

Většina je v pohodě do 2-5 MB a nad 10 MB se zřetelně zhoršuje. Tuhý strop je paměť karty (asi 1-4 GB), ale už u několika desítek MB je čekání na parsing a stavbu stromu trýznivé. Nad 20 MB sáhněte po lokálním nástroji nebo příkazové řádce.

Jak se podívat na hodnotu jednoho pole v obřím JSON?

Vytáhněte přes jq bez otevření souboru: jq -r '.[].email' huge.json vypíše všechny e-maily; s filtrem jq -r '.[] | select(.active == true) | .email'. Prvních pár záznamů: jq '.[0:5]' huge.json — o řády rychlejší než otevírání.

Pomůže formátování před otevřením?

Ne. Formátování promění kompaktních 45 MB na 71 MB a jeden řádek na pět milionů — čistá přidaná zátěž pro editor i prohlížeč. Formátujte jen to, co má člověk číst — a jen když je soubor dost malý.