קובץ JSON גדול לא נפתח? בחרו את הכלי הנכון לפי הגודל

קובץ JSON של 45 MB מפוענח ב-249 אלפיות השנייה. חצי הדקה שאתם ממתינים מגיע מרינדור של חמישה מיליון שורות טקסט ו-3.5 מיליון צמתי עץ. לבלבל בין השניים, ותאשימו בכל פעם את הגורם הלא נכון.

אחד: מדדו קודם — הפענוח אף פעם לא האשם

דאבל-קליק על ייצוא .json בגודל עשרות MB, העורך מסתובב שלושים שניות, והרפלקס קופץ: "פענוח JSON איטי". המדידה אומרת בדיוק ההפך. על המכונה שלנו (Node 22) יצרנו דגימה של 500,000 רשומות עם חמישה שדות כל אחת (id, email, active, score, tags), 45 MB בפורמט דחוס:

הפענוח מסתיים ברבע שנייה. המפענח סיים את עבודתו עוד לפני ששחררתם את העכבר. כל השניות שאחרי כן מוקדשות לשכבת "הצג את התוצאה לבן אדם": עורך הטקסט צריך לסדר חמישה מיליון שורות, לחשב הדגשת תחביר ולתחזק מאגר ביטול פעולה; צפיית עץ צריכה ליצור אלמנט DOM לכל אחד מ-3.5 מיליון הצמתים — והדפדפן נתקע סביב מאה אלף צמתים, מאבד תגובתיות הרבה לפני המיליון.

המסקנה מצביעה לכיוון שונה לגמרי: הפסיקו להיאבק ברינדור — השתמשו בכלים שלא מציגים הכול בבת אחת.

שניים: למה זה קופא — מספר השורות והצמתים הוא העלות האמיתית

גודל הקובץ הוא רק פני השטח. שני מספרים נגזרים הם אלה ששוברים את הכלים:

1. מספר השורות. JSON דחוס של 45 MB הופך לחמישה מיליון שורות בעיצוב. באיזה חלק שתפתחו, העורך צריך קודם כל לבנות את מבנה השורות של הקובץ כולו, לפתור מצבי הדגשה ולהקצות מאגרים — העלות פרופורציונלית לסך השורות.
2. מספר הצמתים. חצי מיליון רשומות × (אובייקט אחד + חמישה שדות) = 3.5 מיליון צמתים. כל צפייה שבונה את העץ המלא לפני התצוגה משלמת אותו זיכרון וזמן — תפתחו ענף אחד או את כולם.

מכאן נובעות שתי מסקנות המנוגדות לאינטואיציה. עיצוב לפני הצפייה מזיק — הקובץ תופח מ-45 ל-71 MB ומספר השורות גדל פי ארבעים, עומק נטו נוסף על הכלי. דחיפת הקובץ עם cat לטרמינל גם מזיקה — מאגר הגלילה הופך לבעיה החדשה; לבייטים הראשונים, head -c 2000 מספיק.

שלושה: בחרו כלי לפי גודל — טבלת החלטות

גדלים שונים מחייבים כלים שונים לחלוטין. בשילוב המדידות לעיל עם מדריכים מפורסמים (OpenFormatter ממקם את אזור הנוחות של הכלים המקוונים ב-2-5 MB; PureJSON מעריך שהזיכרון אחרי פענוח מסמך של 500 MB מגיע ל-2-4 GB), מתגבשת הטבלה הזו:

הכלי /parse באתר הזה מכסה את המדרגה הראשונה: צפיית עץ ואימות. קבצים גדולים יותר צריכים להגיע לאפליקציית הדסקטופ, כדי שעשרות MB לא יודבקו לעמוד אינטרנט לעולם.

ארבעה: אל תפתחו את הקובץ — שאלו קודם על המבנה שלו

מול JSON גדול וזר, הצעד הראשון אינו פתיחה אלא השקעת כמה שניות בהבנת הצורה. jq עונה על שלוש שאלות בכ-200 אלפיות השנייה:

复制# מה למעלה: מערך או אובייקט? כמה רשומות?
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 בשני מצבים:

המצב הרגיל קורא את הקובץ כולו ובונה גרף אובייקטים; שיא של 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 כבר על שפת המצוק. כשבוחרים צפייה מקוונת, דרשו שלושה דברים:

1. העיבוד מתרחש מקומית (מה שמודבק לעולם לא נשלח לשרת) — מגן על הנתונים וחוסך זמן העלאה; כל הכלים באתר הזה רצים במלואם בדפדפן ועובדים גם ללא אינטרנט;
2. הפענוח רץ ב-Web Worker — התהליך הראשי לא קופא, ומעצור עולה רק בטאב אחד, לא בדפדפן כולו;
3. עץ וירטואלי או עצלן — ענפים מקופלים כמעט לא עולים כלום; מוצג רק מה שנפתח.

באתר הזה: /parse מתאים לחקירת מבנה ואיתור שגיאות בקבצים עד כמה עשרות MB; מעל זה, jq או אפליקציית הדסקטופ, והדפדפן נשמר לקטעים קטנים.

שבעה: הפורמט הנכון מוחק חצי מהבעיה

אם אתם יכולים להשפיע על אופן יצירת הקובץ, צפייה משופרת היא התרופה הלא נכונה — מנעו ממנו לצמוח ל"ענק-מערך":

• NDJSON/JSONL: רשומה אחת לכל שורה. הוספה לא כותבת מחדש את הקובץ, ו-head, grep, tail, split עובדים ישירות; קובץ קטוע מאבד רק את השורה האחרונה. המדריך ל-JSONL שלנו כולל את ההליך המלא לטיפול בשורות פגומות.
• ייצוא מדורג לעמודים: API שמחזיר 100,000 רשומות צריך לקבל פרמטר עמוד — 100 בבת אחת נחמד יותר לשני הצדדים.
• נתונים טבלאיים לא ל-JSON: רשומה אחת לכל שורה, שדות קבועים בלי קינון — זו טבלה. CSV או Parquet קטנים יותר ועם מערכות אקולוגיות עשירות יותר.

מספר לזכור: חצו מערך של 500,000 רשומות לשניים, והחצי הראשון עדיין קובץ NDJSON תקין (חצי מהרשומות שורדות), בעוד שהענק-מערך המקביל אובד כולו. חמש מאות רשומות שניצלו מתוך 501 עדיפות על אפס.

שמונה: רשימת תיוג

• חקרו את המבנה קודם עם jq '.[0] | keys' או דגימה של 500 רשומות;
• לעולם אל תעצבו רק כדי לפתוח את הקובץ — הכפלת שורות רק מאטה אותו;
• מתחת ל-2 MB: צפיית עץ מקוונת; מעל 20 MB: שורת פקודה; מעל 1 GB: תמיד --stream או ijson;
• ודאו שהכלי המקוון מעבד מקומית (מה שמודבק לא יוצא מהדפדפן);
• אם אתם שולטים במחולל, עברו ל-NDJSON או לדירוג לעמודים וחסלו את הענק-מערך במקור.

שאלות נפוצות

למה העורך לוקח עשרות שניות לפתוח JSON בזמן שהתוכנה מפענחת ב-200 אלפיות השנייה?

הפענוח הוא קוד נייטיב שהופך טקסט למבנה נתונים: 249 אלפיות השנייה לדגימה שלנו של 45 MB. העורך נתקע בהצגה: חמישה מיליון שורות לסדר, להדגיש ולשמור כמאגר ביטול; העץ בונה DOM ל-3.5 מיליון צמתים. צפייה וירטואלית או חילוץ ישיר עם jq מדלגים על כל זה.

האם jq נגמר לו הזיכרון עם JSON מעל 1 GB?

במצב הרגיל, כן: הוא טוען את המסמך כולו, וגרף האובייקטים מגיע ל-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 ושורה אחת לחמישה מיליון, מוסיף עומס נטו לעורך ולצפייה. שמרו עיצוב למה שבן אדם יקרא — ורק אם הקובץ קטן מספיק.