बड़ी JSON फ़ाइल नहीं खुल रही? साइज़ के हिसाब से सही टूल चुनें
मुख्य बात: दसियों MB के JSON एक्सपोर्ट अक्सर टेक्स्ट एडिटर और ऑनलाइन टूल्स को जमा देते हैं, जबकि पार्सिंग खुद महज़ कुछ सौ मिलीसेकंड लेती है। हमने 45 MB के सैंपल (500,000 रिकॉर्ड) के लिए हर चरण पर समय और मेमोरी मापी, यह दिखाया कि असली लागत लाइनों और नोड्स की संख्या में है, और फ़ाइल साइज़ के अनुसार टूल चयन तालिका बनाई: ऑनलाइन व्यूअर, कमांड लाइन, स्ट्रीम प्रोसेसिंग और डेस्कटॉप ऐप।
45 MB की JSON फ़ाइल 249 मिलीसेकंड में पार्स हो जाती है। आधा मिनट जो आप इंतज़ार करते हैं, वह पाँच मिलियन टेक्स्ट लाइनों और 3.5 मिलियन ट्री नोड्स के रेंडरिंग से आता है। दोनों को उलझा दीजिए, और हर बार आप गलत दोषी को कोसेंगे।
एक: पहले मापें — पार्सिंग कभी अपराधी नहीं होती
दसियों MB के .json एक्सपोर्ट पर डबल क्लिक, एडिटर तीस सेकंड घूमता है, और रिफ्लेक्स उठता है: "JSON पार्सिंग धीमी है"। माप कहता है बिल्कुल उल्टा। हमारी मशीन (Node 22) पर हमने 500,000 रिकॉर्ड का सैंपल बनाया, हर रिकॉर्ड में पाँच फ़ील्ड (id, email, active, score, tags), कॉम्पैक्ट रूप में 45 MB:
| ऑपरेशन | मापा गया परिणाम |
|---|---|
पूर्ण JSON.parse |
249 ms |
JSON.stringify(data, null, 2) — फ़ॉर्मेट किया आउटपुट |
215 ms |
| फ़ॉर्मेट किया टेक्स्ट | 71 MB, 5,000,001 लाइनें |
| कुल ट्री नोड्स (रिकॉर्ड + फ़ील्ड) | लगभग 3,500,001 |
| पार्सिंग के बाद Node प्रोसेस का RSS | 313 MB (लगभग फ़ाइल साइज़ का 7×) |
पार्सिंग एक चौथाई सेकंड में खत्म। पार्सर ने अपना काम तब तक पूरा कर लिया था जब आपने माउस छोड़ा भी नहीं था। उसके बाद का हर सेकंड "परिणाम इंसान को दिखाओ" परत पर खर्च होता है: टेक्स्ट एडिटर को पाँच मिलियन लाइनें व्यवस्थित करनी हैं, सिंटैक्स हाइलाइटिंग गिननी है, और अनडू बफ़र संभालना है; ट्री व्यू को 3.5 मिलियन में से हर नोड के लिए DOM एलिमेंट बनाना है — और ब्राउज़र लगभग एक लाख नोड्स पर लड़खड़ाने लगता है, मिलियन से बहुत पहले रिस्पॉन्सिवनेस खो देता है।
निष्कर्ष पूरी तरह अलग दिशा की ओर इशारा करता है: रेंडरिंग से लड़ना बंद करें — ऐसे टूल अपनाएँ जो सब कुछ एक साथ नहीं दिखाते।
दो: क्यों जम जाता है — लाइनों और नोड्स की संख्या ही असली लागत है
फ़ाइल साइज़ सिर्फ़ सतह है। दो व्युत्पन्न आँकड़े ही टूल्स को तोड़ते हैं:
- लाइनों की संख्या। 45 MB का कॉम्पैक्ट JSON फ़ॉर्मेट होते ही पाँच मिलियन लाइनें बन जाता है। आप कोई भी हिस्सा खोलें, एडिटर को पहले पूरी फ़ाइल की लाइन संरचना बनानी होती है, हाइलाइट स्थितियाँ सुलझानी होती हैं, और बफ़र आवंटित करने होते हैं — लागत कुल लाइनों के अनुपात में होती है।
- नोड्स की संख्या। आधा मिलियन रिकॉर्ड × (एक ऑब्जेक्ट + पाँच फ़ील्ड) = 3.5 मिलियन नोड्स। कोई भी व्यू जो दिखाने से पहले पूरा ट्री बनाता है, वही मेमोरी और वही समय चुकाता है — आप एक शाखा खोलें या सब।
यहाँ से दो अंतर्ज्ञान-विरोधी निष्कर्ष निकलते हैं। देखने से पहले फ़ॉर्मेट करना नुकसानदेह है — फ़ाइल 45 से 71 MB तक सूजती है और लाइनें चालीस गुना बढ़ जाती हैं, टूल के लिए शुद्ध अतिरिक्त बोझ। फ़ाइल को cat से टर्मिनल में धकेलना भी नुकसानदेह है — स्क्रॉल बफ़र नई समस्या बन जाता है; पहले कुछ बाइट्स के लिए head -c 2000 ही काफ़ी है।
तीन: साइज़ के हिसाब से टूल चुनें — निर्णय तालिका
अलग साइज़ बिल्कुल अलग टूल माँगते हैं। ऊपर के माप को प्रकाशित गाइडों से जोड़ने पर (OpenFormatter ऑनलाइन टूल्स का आराम क्षेत्र 2-5 MB पर रखता है; PureJSON 500 MB दस्तावेज़ की पार्सिंग-पश्चात मेमोरी 2-4 GB अनुमानित करता है), यह तालिका बनती है:
| फ़ाइल साइज़ | पहली पसंद | क्यों |
|---|---|---|
| < 2 MB | कोई भी ऑनलाइन टूल | तुरंत उपयोग; एक ही चरण में ट्री व्यू + /parse शैली का सत्यापन |
| 2 – 20 MB | लोकल एडिटर (VS Code) या ब्राउज़र में लोकल टूल | ऑनलाइन टूल्स गिरने लगते हैं; लोकल प्रोसेसिंग कुछ नहीं भेजती |
| 20 – 100 MB | CLI से jq अन्वेषण + वर्चुअल ट्री व्यू | एडिटर लड़खड़ाने लगता है; jq कोई भी हिस्सा सेकंडों में निकाल देता है |
| 100 MB – 1 GB | jq --stream / ijson, स्ट्रीम प्रोसेसिंग |
पारंपरिक पार्सिंग मेमोरी फ़ाइल साइज़ का ~7× तक फूलती है; नहीं समाती — स्ट्रीम करें |
| > 1 GB या लगातार वृद्धि | फ़ॉर्मेट बदलें: NDJSON / CSV / Parquet | "दानव-ऐरे" को पूरा पार्स करना पड़ता है इससे पहले कि पहला रिकॉर्ड काम आए; समस्या फ़ॉर्मेट में ही है |
इस साइट का /parse टूल पहली सीढ़ी कवर करता है: ट्री व्यू और सत्यापन। बड़ी फ़ाइलें डेस्कटॉप ऐप की ओर जानी चाहिए, ताकि दसियों MB कभी वेब पेज पर पेस्ट न हों।
चार: फ़ाइल खोलें ही नहीं — पहले उसकी संरचना से पूछें
अनजान बड़ी JSON के सामने पहला कदम खोलना नहीं, बल्कि कुछ सेकंड उसकी बनावट समझने में लगाना है। jq तीन सवालों के जवाब लगभग 200 ms में देता है:
# ऊपर क्या है: ऐरे या ऑब्जेक्ट? कितने रिकॉर्ड?
jq 'if type == "array" then {type: "array", count: length} else {type: "object", keys: (keys|length)} end' huge.json
# पहला रिकॉर्ड कैसा दिखता है (सिर्फ़ एक, बिना बाढ़)?
jq '.[0]' huge.json | head -40
# सभी फ़ील्ड नाम (पहले रिकॉर्ड से)
jq '.[0] | keys' huge.json
संरचना पता चलने के बाद ज़्यादातर माँगें "एक फ़ील्ड निकालो" तक सिमट जाती हैं — फ़ाइल खोलने की ज़रूरत ही नहीं पड़ती। उदाहरण के लिए, हर यूज़र का ईमेल निकालना:
jq -r '.[].email' huge.json | less
# उस पर फ़िल्टर के साथ
jq -r '.[] | select(.active == true) | .email' huge.json
नियम सरल है: "देखने" के लिए वर्चुअल व्यू; "खोजने और निकालने" के लिए jq। दोनों भूमिकाएँ एक टूल में न मिलाएँ।
पाँच: मेमोरी की खाई — सामान्य मोड बनाम स्ट्रीम, 150× का अंतर
उसी 45 MB सैंपल पर /usr/bin/time -v ने दो मोड में jq की चरम मेमोरी मापी:
| मोड | कमांड | चरम मेमोरी (RSS) | समय |
|---|---|---|---|
| सामान्य (पूर्ण लोड) | jq '.[0].email' sample.json |
542 MB | 0.7 s |
| स्ट्रीम | jq --stream 'select(.[0][1]=="email") | .[1]' sample.json |
3.6 MB | 2.5 s |
सामान्य मोड पूरी फ़ाइल पढ़कर ऑब्जेक्ट ग्राफ़ बनाता है; 542 MB का चरम "ऑब्जेक्ट ग्राफ़ ≈ टेक्स्ट साइज़ का 7-12×" नियम की पुष्टि करता है। --stream इनपुट को टोकन-दर-टोकन खाता है और मेमोरी को MB की एक अंक की संख्या पर रखता है — कुल समय थोड़ा लंबा होने की कीमत पर। गीगाबाइट की रेखा पार करते ही यही अंतर "चल रहा है" और "OOM killer द्वारा मारे जाने" को अलग करता है:
# मेमोरी से बड़ी फ़ाइलों के लिए: --stream ही वह एकमात्र मोड है जो कभी सब कुछ लोड नहीं करता
jq --stream -n 'fromstream(1|truncate_stream(inputs))' huge.json
पाइथन में समकक्ष ijson है: ijson.items(f, 'item') ऐरे के तत्व एक-एक करके उत्पन्न करता है, वही स्थिर मेमोरी रखते हुए। इन सब टूल्स की साझा कीमत है रैंडम एक्सेस का त्याग — स्ट्रीम केवल आगे चलती है, दूसरा पास का मतलब फ़ाइल दोबारा पढ़ना है।
छह: ब्राउज़र कितनी दूर तक — लोकल प्रोसेसिंग की सीमाएँ
ऑनलाइन टूल्स अपनी सीमाओं में उपयोगी बने रहते हैं। आधुनिक ब्राउज़र टैब के पास लगभग 1-4 GB मेमोरी होती है; 45 MB की फ़ाइल जो ग्राफ़ प्लस ट्री में पार्स होती है, वह आमतौर पर बच निकलती है। कुछ सौ MB खाई के किनारे पर ही हैं। ऑनलाइन व्यूअर चुनते समय तीन चीज़ें माँगें:
- प्रोसेसिंग लोकल हो (पेस्ट किया गया कभी सर्वर न जाए) — डेटा सुरक्षित रहता है और अपलोड समय बचता है; इस साइट के सभी टूल्स पूरी तरह ब्राउज़र में चलते हैं और ऑफ़लाइन भी काम करते हैं;
- पार्सिंग Web Worker में चले — मुख्य थ्रेड जमता नहीं, और अटकने की कीमत सिर्फ़ एक टैब है, पूरा ब्राउज़र नहीं;
- ट्री वर्चुअलाइज़्ड या लेज़ी हो — मुड़ी शाखाओं की लागत लगभग शून्य; सिर्फ़ खोला हुआ रेंडर होता है।
इस साइट में: /parse कुछ दसियों MB तक की फ़ाइलों में संरचना अन्वेषण और त्रुटि खोज के लिए उपयुक्त है; उससे ऊपर jq या डेस्कटॉप ऐप, ब्राउज़र छोटे टुकड़ों के लिए सुरक्षित रखें।
सात: सही फ़ॉर्मेट आधी समस्या मिटा देता है
अगर फ़ाइल कैसे बनती है इस पर आपका नियंत्रण है, तो बेहतर व्यूअर गलत दवा है — फ़ाइल को "दानव-ऐरे" बनने से रोकें:
- NDJSON/JSONL: हर लाइन में एक रिकॉर्ड। जोड़ने पर फ़ाइल दोबारा नहीं लिखी जाती, और
head,grep,tail,splitसीधे काम करते हैं; कटी हुई फ़ाइल सिर्फ़ आख़िरी लाइन खोती है। हमारे JSONL गाइड में खराब लाइनों को संभालने की पूरी प्रक्रिया है। - पेज-वार एक्सपोर्ट: 100,000 रिकॉर्ड देने वाली API को पेज पैरामीटर स्वीकार करना चाहिए — एक बार में 100 दोनों पक्षों के लिए अधिक सौम्य है।
- तालिका-रूप डेटा JSON के लिए नहीं: हर लाइन में एक रिकॉर्ड, बिना नेस्टिंग के स्थिर फ़ील्ड — यह तो टेबल है। CSV या Parquet छोटे होते हैं और उनके इकोसिस्टम अमीर हैं।
याद रखने योग्य संख्या: 500,000 रिकॉर्ड के ऐरे को दो हिस्सों में काटिए, पहला हिस्सा अब भी मान्य NDJSON फ़ाइल है (आधे रिकॉर्ड बच जाते हैं), जबकि समतुल्य दानव-ऐरे पूरी तरह खो जाता है। 501 में से पाँच सौ रिकॉर्ड बचना शून्य से बेहतर है।
आठ: चेकलिस्ट
- पहले
jq '.[0] | keys'या 500 रिकॉर्ड के सैंपल से संरचना तलाशें; - सिर्फ़ फ़ाइल खोलने के लिए कभी फ़ॉर्मेट न करें — लाइनें दोगुनी करना उसे केवल धीमा करता है;
- 2 MB से नीचे: ऑनलाइन ट्री व्यू; 20 MB से ऊपर: कमांड लाइन; 1 GB से ऊपर: हमेशा
--streamया ijson; - सुनिश्चित करें कि ऑनलाइन टूल लोकल प्रोसेस करे (पेस्ट किया गया ब्राउज़र से बाहर न जाए);
- अगर जेनरेटर पर आपका नियंत्रण है, तो NDJSON या पेजिनेशन पर जाएँ और दानव-ऐरे को स्रोत पर ही मिटाएँ।
सामान्य प्रश्न
एडिटर JSON खोलने में दसियों सेकंड क्यों लेता है जब प्रोग्राम 200 ms में पार्स कर देता है?
पार्सिंग नेटिव कोड है जो टेक्स्ट को डेटा संरचना में बदलता है: हमारे 45 MB सैंपल के लिए 249 ms। एडिटर प्रस्तुति में अटकता है: पाँच मिलियन लाइनें व्यवस्थित करनी हैं, हाइलाइट करनी हैं, अनडू बफ़र के रूप में सहेजनी हैं; ट्री 3.5 मिलियन नोड्स के लिए DOM बनाता है। वर्चुअल व्यू या jq से सीधा निष्कर्षण इन सबको छोड़ देता है।
क्या 1 GB से बड़ी JSON पर jq की मेमोरी खत्म हो जाती है?
सामान्य मोड में, हाँ: वह पूरा दस्तावेज़ लोड करता है, और ऑब्जेक्ट ग्राफ़ फ़ाइल साइज़ के 7-12× तक पहुँचता है। --stream के साथ इनपुट टोकन-दर-टोकन खपत होता है: हमारा 45 MB परीक्षण 3.6 MB के चरम पर पहुँचा, और मेमोरी फ़ाइल साइज़ जो हो, समतल रहती है — कीमत है केवल एक क्रमिक पास।
ऑनलाइन JSON व्यूअर कितनी बड़ी फ़ाइल सँभाल पाते हैं?
अधिकांश 2-5 MB तक आराम से चलते हैं और 10 MB के ऊपर स्पष्ट रूप से लड़खड़ाते हैं। कठोर सीमा टैब की मेमोरी है (1-4 GB), लेकिन कुछ दसियों MB पर ही पार्सिंग और ट्री निर्माण की प्रतीक्षा दर्दनाक हो जाती है। 20 MB से ऊपर लोकल टूल्स या कमांड लाइन अपनाएँ।
दानव JSON में एक फ़ील्ड का मान कैसे देखें?
फ़ाइल खोले बिना jq से निकालें: jq -r '.[].email' huge.json सभी ईमेल प्रिंट करता है; फ़िल्टर के साथ — jq -r '.[] | select(.active == true) | .email'। शुरुआती रिकॉर्ड के लिए: jq '.[0:5]' huge.json — फ़ाइल खोलने से गुना तेज़।
क्या खोलने से पहले फ़ॉर्मेट करना मदद करता है?
नहीं। फ़ॉर्मेटिंग 45 MB कॉम्पैक्ट को 71 MB और एक लाइन को पाँच मिलियन में बदल देती है, एडिटर और व्यूअर पर शुद्ध बोझ जोड़ती है। फ़ॉर्मेटिंग उसी चीज़ के लिए बचाकर रखें जो इंसान पढ़ेगा — और वह भी सिर्फ़ तब जब फ़ाइल काफ़ी छोटी हो।