File JSON besar tidak bisa dibuka? Pilih alat yang tepat sesuai ukuran

File JSON 45 MB bisa di-parse dalam 249 milidetik. Setengah menit yang Anda tunggu berasal dari perenderan lima juta baris teks dan 3,5 juta node pohon. Keliru membedakan keduanya, dan Anda akan menyalahkan pihak yang salah setiap kali.

Satu: ukur dulu — parsing bukanlah biang keladi

Klik dua kali ekspor .json berukuran puluhan MB, editor berputar selama tiga puluh detik, dan refleks pun muncul: "parsing JSON lambat". Pengukuran justru berkata sebaliknya. Di mesin kami (Node 22), kami membuat sampel 500.000 rekaman dengan lima field per rekaman (id, email, active, score, tags), 45 MB dalam bentuk padat:

Parsing selesai dalam seperempat detik. Parser sudah selesai bekerja bahkan sebelum Anda melepas mouse. Semua detik setelahnya dihabiskan di lapisan "tampilkan hasilnya ke manusia": editor teks harus menata lima juta baris, menghitung pewarnaan sintaks, dan merawat buffer undo; tampilan pohon harus membuat elemen DOM untuk masing-masing dari 3,5 juta node — dan browser mulai tersandung di sekitar seratus ribu node, kehilangan daya tanggap jauh sebelum menyentuh satu juta.

Kesimpulannya mengarah ke tempat yang sama sekali berbeda: berhenti berperang dengan perenderan — pakailah alat yang tidak menampilkan semuanya sekaligus.

Dua: mengapa membeku — jumlah baris dan node adalah biaya sesungguhnya

Ukuran file hanyalah permukaan. Dua angka turunan yang menghancurkan alat:

1. Jumlah baris. JSON padat 45 MB menjadi lima juta baris begitu diformat. Bagian mana pun yang Anda buka, editor harus membangun struktur baris seluruh file terlebih dahulu, menyelesaikan status pewarnaan, dan mengalokasikan buffer — biayanya sebanding dengan total baris.
2. Jumlah node. Setengah juta rekaman × (satu objek + lima field) berarti 3,5 juta node. Tampilan apa pun yang membangun seluruh pohon sebelum menampilkan harus membayar memori dan waktu yang sama — entah Anda membuka satu cabang atau semuanya.

Dua implikasi yang melawan intuisi muncul dari sini. Memformat dulu sebelum melihat justru merugikan — file membengkak dari 45 ke 71 MB dan jumlah baris berlipat empat puluh kali, beban murni tambahan bagi alat. Meng-CAT file ke terminal juga merugikan — buffer scroll menjadi masalah baru; untuk bait pertama, head -c 2000 sudah cukup.

Tiga: pilih alat sesuai ukuran — tabel keputusan

Ukuran berbeda menuntut alat yang sama sekali berbeda. Menggabungkan pengukuran di atas dengan panduan yang dipublikasikan (OpenFormatter menempatkan zona nyaman alat daring di 2-5 MB; PureJSON memperkirakan memori setelah parsing dokumen 500 MB mencapai 2-4 GB), tabel ini terbentuk:

Alat /parse di situs ini mencakup anak tangga pertama: tampilan pohon dan validasi. File yang lebih besar sebaiknya menuju aplikasi desktop, agar puluhan MB tidak pernah ditempel ke halaman web.

Empat: jangan langsung membuka — tanya dulu strukturnya

Menghadapi JSON besar yang asing, langkah pertama bukanlah membuka, melainkan meluangkan beberapa detik memahami bentuknya. jq menjawab tiga pertanyaan dalam sekitar 200 ms:

复制# Di atas: array atau objek? Berapa rekaman?
jq 'if type == "array" then {type: "array", count: length} else {type: "object", keys: (keys|length)} end' huge.json

# Seperti apa rekaman pertama (satu saja, tanpa banjir)?
jq '.[0]' huge.json | head -40

# Semua nama field (dari rekaman pertama)
jq '.[0] | keys' huge.json

Setelah struktur diketahui, sebagian besar permintaan menyempit menjadi "ekstrak satu field" — bahkan tidak perlu membuka file. Misalnya untuk mengambil email setiap pengguna:

复制jq -r '.[].email' huge.json | less
# Dengan filter
jq -r '.[] | select(.active == true) | .email' huge.json

Aturannya sederhana: untuk "melihat", pakai tampilan virtual; untuk "mencari dan mengekstrak", pakai jq. Jangan gabungkan dua peran itu dalam satu alat.

Lima: jurang memori — mode biasa vs stream, selisih 150×

Pada sampel 45 MB yang sama, /usr/bin/time -v mengukur memori puncak jq dalam dua mode:

Mode biasa membaca seluruh file dan membangun graf objek; puncak 542 MB mengonfirmasi perkiraan "graf objek ≈ 7-12× ukuran teks". --stream memakan input token demi token, menjaga memori di angka satu digit MB — dengan konsekuensi waktu total lebih lama. Lewati batas gigabyte, selisih inilah yang memisahkan "berjalan" dari "dibunuh oleh OOM killer":

复制# Untuk file lebih besar daripada memori: --stream adalah satu-satunya mode yang tak pernah memuat semuanya
jq --stream -n 'fromstream(1|truncate_stream(inputs))' huge.json

Padanan di Python adalah ijson: ijson.items(f, 'item') menghasilkan elemen array satu per satu dengan memori konstan yang sama. Harga bersama semua alat ini adalah melepaskan akses acak — stream hanya berjalan maju satu arah, dan putaran kedua berarti membaca ulang file.

Enam: seberapa jauh kemampuan browser — batas pemrosesan lokal

Alat daring tetap bisa dipakai, dalam batasnya. Tab browser modern memiliki sekitar 1-4 GB memori; file 45 MB yang di-parse menjadi graf ditambah pohon biasanya masih selamat. Beberapa ratus MB sudah berada di tepi jurang. Saat memilih tampilan daring, tuntut tiga hal:

1. Pemrosesan berjalan lokal (yang ditempel tidak pernah dikirim ke server) — melindungi data sekaligus menghemat waktu unggah; semua alat di situs ini berjalan penuh di browser dan bisa dipakai offline;
2. Parsing berjalan di Web Worker — thread utama tidak membeku, dan macet hanya mengorbankan satu tab, bukan seluruh browser;
3. Pohon divirtualisasi atau dilongokkan — cabang terlipat nyaris tanpa biaya; hanya yang dibuka yang dirender.

Di situs ini: /parse cocok untuk eksplorasi struktur dan pencarian kesalahan file hingga puluhan MB; lebih dari itu, pakai jq atau aplikasi desktop, sisakan browser untuk fragmen kecil.

Tujuh: format yang tepat memangkas separuh masalah

Jika Anda bisa mengendalikan cara file dihasilkan, tampilan yang lebih baik adalah obat yang salah — pastikan filenya tidak tumbuh menjadi "satu raksasa array":

• NDJSON/JSONL: satu rekaman per baris. Penambahan tidak menulis ulang file, dan head, grep, tail, split langsung bekerja; file terpotong hanya kehilangan baris terakhir. Buku panduan JSONL kami memuat prosedur lengkap menangani baris rusak.
• Ekspor berhalaman: API yang mengirim 100.000 rekaman seharusnya menerima parameter halaman — 100 sekaligus lebih ramah bagi kedua belah pihak.
• Data tabular bukan untuk JSON: satu rekaman per baris, field tetap tanpa sarang — itu tabel. CSV atau Parquet lebih kecil dan ekosistemnya lebih kaya.

Angka untuk diingat: potong array 500.000 rekaman menjadi dua bagian, bagian pertama tetap menjadi file NDJSON yang sah (separuh rekaman selamat), sementara raksasa array tunggal yang setara hilang seluruhnya. Lima ratus rekaman terselamatkan dari 501 jauh lebih baik daripada nol.

Delapan: daftar periksa

• Eksplorasi struktur dulu dengan jq '.[0] | keys' atau sampel 500 rekaman;
• Jangan pernah memformat hanya demi membuka file — menggandakan baris hanya memperlambat;
• Di bawah 2 MB: tampilan pohon daring; di atas 20 MB: baris perintah; di atas 1 GB: selalu --stream atau ijson;
• Pastikan alat daring memproses secara lokal (yang ditempel tidak keluar dari browser);
• Bila Anda mengendalikan generatornya, beralihlah ke NDJSON atau paginasi dan hapus raksasa array di sumbernya.

Pertanyaan umum

Mengapa editor butuh puluhan detik membuka JSON padahal program mem-parse dalam 200 ms?

Parsing adalah kode native yang mengubah teks menjadi struktur data: 249 ms untuk sampel 45 MB kami. Editor tersangkut di penyajian: lima juta baris untuk ditata, diwarnai, dan disimpan sebagai buffer undo; pohon membangun DOM untuk 3,5 juta node. Tampilan virtual atau ekstraksi langsung lewat jq melewati semuanya.

Apakah jq kehabisan memori pada JSON di atas 1 GB?

Dalam mode biasa, ya: ia memuat seluruh dokumen, dan graf objek memuncak di 7-12× ukuran file. Dengan --stream, input dimakan token demi token: uji 45 MB kami memuncak di 3,6 MB, dan memori tetap datar apa pun ukuran file — dengan harga satu lintasan berurutan saja.

Sebesar apa file yang sanggup ditangani alat JSON daring?

Kebanyakan nyaman sampai 2-5 MB dan menurun jelas di atas 10 MB. Batas kerasnya adalah memori tab (sekitar 1-4 GB), tetapi pada puluhan MB saja menunggu parsing dan pembangunan pohon sudah menyiksa. Di atas 20 MB, pakai alat lokal atau baris perintah.

Bagaimana melihat nilai satu field di JSON raksasa?

Ekstrak lewat jq tanpa membuka file: jq -r '.[].email' huge.json mencetak semua email; dengan filter — jq -r '.[] | select(.active == true) | .email'. Untuk rekaman awal: jq '.[0:5]' huge.json — berlipat kali lebih cepat daripada membuka file.

Apakah memformat dulu sebelum membuka membantu?

Tidak. Memformat mengubah 45 MB padat menjadi 71 MB dan satu baris menjadi lima juta, menambah beban murni bagi editor dan tampilan. Simpan pemformatan untuk apa yang akan dibaca manusia — dan hanya jika filenya cukup kecil.