বড় JSON ফাইল খোলা যাচ্ছে না? সাইজ অনুযায়ী সঠিক টুল বেছে নিন

৪৫ MB-র একটি JSON ফাইল পার্স হয় ২৪৯ মিলিসেকেন্ডে। আধা মিনিট অপেক্ষার আসল কারণ পাঁচ মিলিয়ন লাইনের টেক্সট ও ৩.৫ মিলিয়ন ট্রি নোড রেন্ডার করা। এ দুটো গুলিয়ে ফেললে প্রতিবারই ভুল দোষীকে খুঁজবেন।

এক: আগে মাপুন — পার্সিং কখনোই বাধা নয়

কয়েক ডজন মেগাবাইটের .json এক্সপোর্টে ডাবল ক্লিক করুন, এডিটর ত্রিশ সেকেন্ড ঘুরছে দেখে সহজাত সিদ্ধান্ত: "JSON পার্সিং ধীর।" পরিমাপ বলছে উল্টো কথা। আমাদের মেশিনে (Node 22) ৫ লক্ষ রেকর্ডের নমুনা নিয়েছি, প্রতিটিতে পাঁচটি ফিল্ড (id, email, active, score, tags), কমপ্যাক্ট রূপে ৪৫ MB:

পার্সিং শেষ হলো চতুর্থাংশ সেকেন্ডে। আপনি মাউস ছাড়ার আগেই পার্সারের কাজ শেষ। এরপরের প্রতিটি সেকেন্ড গেছে "ফলাফল মানুষকে দেখানো" স্তরে: টেক্সট এডিটরকে পাঁচ মিলিয়ন লাইন সাজাতে হয়, লাইনে লাইনে সিনট্যাক্স হাইলাইট করতে হয়, আনডু বাফার ধরে রাখতে হয়; ট্রি ভিউয়ারকে ৩৫ লক্ষ নোডের প্রতিটির জন্য DOM এলিমেন্ট বানাতে হয় — ব্রাউজার এক লক্ষ নোডের কাছেই হোঁচট খায়, দশ লক্ষের বহু আগেই সাড়া হারায়।

এই সিদ্ধান্ত সম্পূর্ণ ভিন্ন দিক নির্দেশ করে: রেন্ডারিংয়ের সঙ্গে যুদ্ধ না করে এমন টুল নিন যা সবকিছু রেন্ডার করে না।

দুই: কেন আটকায় — লাইন ও নোড সংখ্যাই আসল খরচ

ফাইলের আকার শুধু বাইরের চেহারা। টুল ভেঙে ফেলে দুটি ডেরিভড সংখ্যা:

1. লাইন সংখ্যা। ৪৫ MB-র কমপ্যাক্ট JSON সুন্দর করলে পাঁচ মিলিয়ন লাইন হয়। আপনি যে অংশই দেখুন, এডিটরকে আগে পুরো ফাইলের লাইন স্ট্রাকচার বানাতে হয়, হাইলাইট স্টেট মেটাতে হয়, বাফার বরাদ্দ করতে হয় — খরচ মোট লাইনের সমানুপাতিক।
2. নোড সংখ্যা। পাঁচ লক্ষ রেকর্ড × (একটি অবজেক্ট + পাঁচ ফিল্ড) = ৩৫ লক্ষ নোড। যে ভিউয়ার দেখানোর আগে পুরো ট্রি বানায়, আপনি এক শাখা খুলুন বা সব, সমান মেমরি ও সময় দিতে বাধ্য।

এখান থেকে দুটি অন্তর্দৃষ্টি-বিরোধী সিদ্ধান্ত। দেখার আগে সুন্দর করা ক্ষতিকর — ফাইল ৪৫ থেকে ৭১ MB হয়, লাইন ৪০ গুণ হয়, টুলের উপর বিশুদ্ধ অতিরিক্ত চাপ। cat দিয়ে ফাইল টার্মিনালে ঢালাও ক্ষতিকর — স্ক্রলব্যাক বাফার নতুন বাধা হয়ে দাঁড়ায়; শুরুর কয়েকশো বাইট দেখতে head -c 2000-ই যথেষ্ট।

তিন: সাইজ অনুযায়ী টুল নির্বাচন — সিদ্ধান্ত টেবিল

ভিন্ন সাইজে ভিন্ন টুল চাই। উপরের পরিমাপ ও প্রকাশিত গাইডলাইন (OpenFormatter অনলাইন টুলের আরামদায়ক অঞ্চল ২-৫ MB ধরে; PureJSON ৫০০ MB ডকুমেন্ট পার্সের পর মেমরি ২-৪ GB অনুমান করে) মিলিয়ে টেবিল দাঁড়ায়:

এই সাইটের /parse প্রথম ধাপ কভার করে: ট্রি ভিউ ও ভ্যালিডেশন। বড় ফাইলের জন্য ডেস্কটপ অ্যাপ নিন, যাতে কয়েক ডজন MB ওয়েবপেজে পেস্ট না হয়।

চার: ফাইল খুলবেন না — আগে স্ট্রাকচার জিজ্ঞেস করুন

অপরিচিত বড় JSON পেলে প্রথম কাজ খোলা নয়, কয়েক সেকেন্ডে গঠন বোঝা। jq প্রায় ২০০ 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। দুই কাজ এক টুলে মেশাবেন না।

পাঁচ: মেমরির খাড়া ঢাল — সাধারণ মোড বনাম স্ট্রিমিং, ১৫০ গুণ পার্থক্য

একই ৪৫ MB নমুনায় /usr/bin/time -v দিয়ে jq-র দুই মোডের মেমরি পিক মেপেছি:

সাধারণ মোড পুরো ফাইল পড়ে অবজেক্ট গ্রাফ বানায়; ৫৪২ MB পিক "অবজেক্ট গ্রাফ ≈ টেক্সটের ৭-১২ গুণ" নিয়ম নিশ্চিত করে। --stream ইনপুট টোকেনে টোকেনে খায়, মেমরি এক ডিজিটের MB-তে স্থির — মোট সময় কিছুটা বেশি। জিগাবাইট ছাড়ালে এই পার্থক্যই "চলে" আর "OOM কিলারের হাতে মরে"-এর বিভাজন:

复制# মেমরির চেয়ে বড় ফাইলের জন্য: --stream-ই একমাত্র মোড যা কখনো পুরোটা লোড করে না
jq --stream -n 'fromstream(1|truncate_stream(inputs))' huge.json

Python-এ সমতুল্য ijson: ijson.items(f, 'item') অ্যারের উপাদান একটি একটি দেয়, একই স্থায়ী মেমরিতে। এই টুলগুলোর সাধারণ মূল্য র‍্যান্ডম অ্যাক্সেস ছেড়ে দেওয়া — স্ট্রিম মানে একবার সামনে গিয়ে শেষ, দ্বিতীয়বার চাইলে আবার পড়তে হবে।

ছয়: ব্রাউজার কতদূর যায় — লোকাল প্রসেসিংয়ের সীমা

অনলাইন টুল চলে, সীমার ভেতরে। আধুনিক ব্রাউজার ট্যাবে প্রায় ১-৪ GB মেমরি থাকে; ৪৫ MB ফাইল গ্রাফ + ট্রি হিসেবে সাধারণত টিকে যায়। কয়েকশো MB গেলে খাড়া পাড়ের ধারে। অনলাইন ভিউয়ার বাছতে তিনটি শর্ত দাবি করুন:

1. প্রসেসিং লোকাল হয় (পেস্ট করা কনটেন্ট কখনো সার্ভারে যায় না) — এতে ডেটা সুরক্ষিত থাকে ও আপলোডের সময় বাঁচে; এই সাইটের সব টুল সম্পূর্ণ ব্রাউজারে চলে, অফলাইনেও কাজ করে;
2. পার্সিং Web Worker-এ চলে — মূল থ্রেড জমে না, আটকালে খরচ একটি ট্যাব, পুরো ব্রাউজার নয়;
3. ট্রি ভার্চুয়ালাইজড বা lazy-এক্সপ্যান্ড — ভাঁজ করা শাখার খরচ প্রায় শূন্য, যতটা খোলা হয় ততটাই রেন্ডার হয়।

এই সাইটে /parse কয়েক ডজন মেগাবাইট পর্যন্ত ফাইলের স্ট্রাকচার অন্বেষণ ও ত্রুটির লাইন-কলাম শনাক্তকরণে মানানসই; তার বেশি হলে jq বা ডেস্কটপ অ্যাপ, ব্রাউজার ছোট টুকরোর নিশ্চিতকরণের জন্য।

সাত: ফরম্যাট ঠিক করলে অর্ধেক সমস্যা মিলিয়ে যায়

ফাইল কীভাবে তৈরি হচ্ছে তা আপনি নিয়ন্ত্রণ করলে, ভালো ভিউয়ার ভুল ওষুধ — ফাইলকে "একটি বিশাল অ্যারে" হতে দেবেন না:

• NDJSON/JSONL: প্রতি লাইনে এক রেকর্ড। যোগ করলে পুরো ফাইল আবার লেখা হয় না, head, grep, tail, split সরাসরি চলে; কাটা ফাইল শুধু শেষ লাইন হারায়। আমাদের JSONL হ্যান্ডবুকে ভাঙা লাইন নির্ণয়ের পূর্ণ পদ্ধতি আছে।
• পেজিনেটেড এক্সপোর্ট: ১ লক্ষ রেকর্ড দেওয়া API-র পেজিনেশন প্যারামিটার থাকা উচিত — একবারে ১০০টি দুই পক্ষের জন্যই ভালো।
• টেবিলগত ডেটা JSON নয়: লাইনে এক রেকর্ড, ফিল্ড স্থির, নেস্টিং নেই — এটা টেবিল। CSV বা Parquet ছোট ও তাদের ইকোসিস্টেম সমৃদ্ধ।

মনে রাখার মতো সংখ্যা: ৫ লক্ষ রেকর্ডের অ্যারে মাঝখানে কাটলে প্রথমার্ধ তখনো বৈধ NDJSON ফাইল (অর্ধেক রেকর্ড বাঁচে), কিন্তু একক বিশাল অ্যারে সম্পূর্ণ বাতিল। ৫০১-এর মধ্যে ৫০০ উদ্ধার হওয়া শূন্যের চেয়ে অনেক ভালো।

আট: চেকলিস্ট

• আগে jq '.[0] | keys' বা ৫০০ রেকর্ডের নমুনায় গঠন বুঝুন;
• শুধু খোলার জন্য সুন্দর করবেন না — লাইন দ্বিগুণ হলে আরও ধীর হবে;
• ২ MB-র নিচে অনলাইন ট্রি ভিউ, ২০ MB-র উপরে কমান্ড লাইন, ১ GB পার হলে সবসময় --stream বা ijson;
• নিশ্চিত করুন অনলাইন টুল লোকালে প্রসেস করে (পেস্ট করা কনটেন্ট ব্রাউজার ছাড়ে না);
• জেনারেটর আপনার হাতে থাকলে NDJSON বা পেজিনেশনে যান, বিশাল অ্যারে উৎসেই দূর করুন।

সাধারণ প্রশ্ন

এডিটরে খুলতে কয়েক ডজন সেকেন্ড লাগে, কিন্তু প্রোগ্রামে পার্স হয় ২০০ ms-এ কেন?

পার্সিং নেটিভ কোড যা টেক্সটকে ডেটা স্ট্রাকচারে বদলায়: ৪৫ MB নমুনায় ২৪৯ ms। এডিটর আটকায় উপস্থাপনায়: পাঁচ মিলিয়ন লাইন সাজানো, হাইলাইট, আনডু বাফার; ট্রি ৩৫ লক্ষ নোডের DOM। ভার্চুয়ালাইজড ভিউয়ার বা jq দিয়ে সরাসরি এক্সট্রাকশন সব এড়িয়ে যায়।

jq ১ GB-র বেশি JSON-এ মেমরি ওভারফ্লো করবে?

সাধারণ মোডে হ্যাঁ: পুরো ডকুমেন্ট লোড করে, অবজেক্ট গ্রাফ পিক ফাইলের ৭-১২ গুণ। --stream দিলে ইনপুট টোকেনে টোকেনে খাওয়া হয়: ৪৫ MB পরীক্ষায় পিক ৩.৬ MB, ফাইল যত বড়ই হোক মেমরি সমতল থাকে — মূল্য একবার ক্রমিক পাস।

অনলাইন JSON টুল কত বড় ফাইল সামলায়?

বেশিরভাগ ২-৫ MB পর্যন্ত আরামে চলে এবং ১০ MB-র পরে স্পষ্টভাবে দুর্বল হয়। কঠিন সীমা ট্যাব মেমরি (প্রায় ১-৪ GB), কিন্তু কয়েক ডজন MB-তেই পার্সিং + ট্রি নির্মাণের অপেক্ষা কষ্টদায়ক। ২০ MB পার হলে লোকাল টুল বা CLI নিন।

বিশাল JSON-এ এক ফিল্ডের মান দেখব কীভাবে?

ফাইল না খুলে jq দিয়ে বের করুন: jq -r '.[].email' huge.json সব ইমেইল দেয়; ফিল্টারসহ jq -r '.[] | select(.active == true) | .email'। প্রথম কয়েকটি রেকর্ডে jq '.[0:5]' huge.json — ফাইল খোলার চেয়ে গুণে গুণে দ্রুত।

আগে সুন্দর করে তারপর খোলা সাহায্য করে?

না। সুন্দর করা কমপ্যাক্ট ৪৫ MB-কে ৭১ MB ও এক লাইনকে পাঁচ মিলিয়ন বানায় — এডিটর ও ভিউয়ারের জন্য বিশুদ্ধ বাড়তি বোঝা। সুন্দর করা কেবল তখনই মূল্যবান যখন মানুষ পড়বে এবং ফাইল যথেষ্ট ছোট।