התקרה של Google Sheets היא 10 מיליון תאים לכל הקובץ, אבל גיליון תפעולי נשבר הרבה קודם. מה באמת מאט, אילו תיקונים קונים זמן, ומתי עוברים לבסיס נתונים.
עיקרי הדברים
- 10 מיליון תאים ו-18,278 עמודות (עד עמודה ZZZ) הם מגבלת הקובץ כולו, לא של לשונית בודדת.
- 50,000 שורות על פני 40 עמודות הן 2,000,000 תאים - חמישית מהתקרה. אם הגיליון כבד, זו לא בעיית נפח.
- מה שמאט הוא כמות התאים הנגזרים: כל `VLOOKUP` על טווח פתוח, כל עיצוב מותנה, וכל פונקציה תנודתית שמחשבת את עצמה בכל שינוי.
- Apps Script מוגבל ל-6 דקות להרצה ול-30 שניות לפונקציה מותאמת. סקריפט שנוגע בכל השורות ייקטע לפני שיסיים.
- הצעד הנכון הוא בדרך כלל להוציא את הנתונים לבסיס נתונים ולהשאיר את הגיליון כממשק - לא להחליף את הגיליון.
Google מגבילה קובץ גיליון בודד ל-10 מיליון תאים, המשותפים לכל הלשוניות שבו. גיליון תפעולי עם 50,000 שורות כמעט אף פעם לא מגיע לתקרה הזו - הוא הופך לבלתי שמיש הרבה לפניה, כי כל עריכה מפעילה מחדש גרף תלויות שגדל יחד איתו. נקודת ההחלטה היא החישוב מחדש, לא הנפח.
שתי התקרות: זו שמתועדת וזו שפוגשים ראשונה
התקרה המתועדת ברורה ומספרית. התקרה המעשית לא כתובה בשום מקום, כי היא תלויה במה שבנוי בתוך הקובץ.
| המגבלה | הערך | על מה היא חלה |
|---|---|---|
| תאים בקובץ | 10,000,000 | הקובץ כולו, מחולק בין כל הלשוניות |
| עמודות | 18,278 (עד ZZZ) | לגיליון |
| תווים בתא בייבוא מ-Excel | מעל 50,000 - התא מוסר | בהמרה מ-Excel ל-Sheets |
| Connected Sheets - טבלת ציר | עד 200,000 שורות | תוצאת שאילתה מ-BigQuery |
| Connected Sheets - חילוץ | עד 500,000 שורות או 5 מיליון תאים | חילוץ לתוך הגיליון |
| הרצת Apps Script | 6 דקות | להרצה בודדת |
| פונקציה מותאמת ב-Apps Script | 30 שניות | לקריאה בודדת |
הטעות הנפוצה היא ההנחה שכל לשונית מקבלת מכסה משלה. היא לא. קובץ עם 20 לשוניות מחלק ביניהן את אותם 10 מיליון תאים, ולכן פיצול לשוניות אינו פותר נפח - הוא רק מפזר אותו.
מה בעצם איטי כשגיליון של 50,000 שורות מרגיש איטי?
לא הנתונים. מה שאיטי הוא כמות התאים שצריך לחשב מחדש אחרי כל הקלדה. חמישה דפוסים מייצרים את רוב העומס:
- טווחים פתוחים.
VLOOKUPעלA:Dנבדק מול כל השורות שהגיליון מקצה, לא רק מול המלאות. - חיפוש לכל שורה. 50,000 שורות עם שתי נוסחאות חיפוש כל אחת הן 100,000 חישובים על כל שינוי.
- פונקציות תנודתיות.
NOW,TODAY,RANDו-OFFSETמחשבות את עצמן מחדש כל פעם, וגוררות איתן כל תא שתלוי בהן. - עיצוב מותנה על עמודה שלמה. כל כלל הוא בדיקה לכל תא בטווח.
- קישור בין קבצים.
IMPORTRANGEמוסיף המתנה לרשת לתוך גרף החישוב.
הסימן המובהק הוא שההאטה תלויה בפעולה ולא בגודל: פתיחת הקובץ סבירה, אבל הקלדת ערך בודד תוקעת את הדפדפן לכמה שניות. גיליון שאיטי רק בפתיחה הוא בדרך כלל בעיית נפח או תמונות; גיליון שאיטי בכל הקלדה הוא בעיית גרף חישוב.
החשבון על גיליון אמיתי
נניח גיליון הזמנות: 50,000 שורות, 40 עמודות. זה 2,000,000 תאים בלשונית אחת. נוסיף שש לשוניות עזר של 5,000 שורות על 20 עמודות - עוד 600,000. הקובץ נמצא על 2.6 מיליון תאים, רבע מהתקרה, ואף אחד לא יתלונן על נפח.
עכשיו נניח שבכל שורה יש שלוש נוסחאות חיפוש אל לשונית לקוחות ואל לשונית מוצרים. זה 150,000 חישובי חיפוש. אם הטווחים פתוחים, כל חישוב סורק את מלוא השורות שהוקצו. הקובץ יגיע לתקרת התאים רק בעוד ארבע שנים - אבל הוא כבר בלתי שמיש היום.
תיקונים שקונים שנה, ומה כל אחד עולה
- סגירת טווחים.
A2:D50000במקוםA:D. שינוי זול, השפעה מיידית, אבל דורש עדכון כשהנתונים גדלים. - החלפת שרשרת חיפושים ב-
QUERYאחד. פחות תאים נגזרים, אבל קשה יותר לתחזוקה למי שלא כתב אותו. - הקפאת היסטוריה. העברת נתוני שנים קודמות ללשונית ארכיון או לקובץ נפרד, והפיכתם לערכים. מוריד עומס, ומוותר על חיתוך חופשי לאורך זמן.
- הסרת פונקציות תנודתיות. החלפת
TODAY()בתאריך שנכתב פעם ביום על ידי סקריפט. - צמצום כללי עיצוב מותנה לטווחים המדויקים. משעמם, ולעיתים קרובות ההשפעה הגדולה ביותר.
לכל אלה יש תקרה. הם מקטינים את גרף החישוב, אבל אינם משנים את העובדה שכל משתמש טוען את כל הנתונים לדפדפן שלו כדי לראות שורה אחת.
מתי זו כבר לא בעיית נוסחאות?
כשהתסמין עובר מ"איטי" ל"לא ניתן להסתמך עליו". אלה חמשת הסימנים שמחליפים את השאלה:
| הסימן | מה הוא אומר בפועל |
|---|---|
| נדרש להוציא משתמשים כדי להריץ עדכון | אין בקרת עדכון מקבילית |
| סקריפט נקטע אחרי 6 דקות | היקף העיבוד גדול מכלי ההרצה |
| כל שינוי במבנה שובר דוח אחר | אין הפרדה בין נתונים לתצוגה |
| מספרים שונים בין שני דוחות על אותו נתון | קיימים כמה עותקים של אותה עובדה |
| רק אדם אחד מבין את הקובץ | הידע לא נמצא במערכת |
שלוש השורות האחרונות אינן בעיות ביצועים כלל. הן בעיות מודל נתונים, וגיליון מהיר יותר לא יפתור אותן.
הארכיטקטורה שמשאירה את הגיליון כממשק
המעבר המקובל אינו נטישת הגיליון אלא הורדתו לתפקידו הנכון: תצוגה וקלט, לא אחסון.
- הגדירו איזו לשונית היא מקור האמת לכל ישות - הזמנות, לקוחות, מוצרים. בדרך כלל מתגלה שיש יותר מאחת.
- העבירו את הטבלאות האלה לבסיס נתונים, עם מפתח ראשי לכל שורה ושדה תאריך עדכון.
- השאירו את הגיליון כתצוגה: הוא שולף חתך רלוונטי, לא את כל ההיסטוריה.
- העבירו את הלוגיקה הכבדה - חיפושים, צבירות, בדיקות - לצד השרת, שם אין תקרת 6 דקות.
- שמרו את הקלט בגיליון אם כך העובדים רגילים לעבוד. אין סיבה לאלץ מסך חדש בשלב הזה.
המאמר חריגה ממכסת Google Sheets באוטומציה עוסק בשכבה אחרת של אותה בעיה - מכסת הבקשות של ה-API ושגיאת 429. כאן מדובר בקובץ עצמו. ראו גם השוואה בין Airtable ל-Google Sheets וחיבור Google Sheets לכלים אחרים.
מה להכין לפני שמוציאים את הנתונים החוצה
- רשימת כל הלשוניות, ומי כותב לכל אחת מהן בפועל.
- זיהוי המפתח הייחודי של כל שורה. אם אין כזה, זו העבודה הראשונה.
- רשימת כל הדוחות והקבצים החיצוניים שמושכים מהקובץ הזה.
- הבחנה בין נתונים תפעוליים לנתוני ארכיון, כולל מאיזה תאריך אפשר להקפיא.
- החלטה מי ממשיך לעבוד בגיליון אחרי המעבר, ומי עובר למסך.
מקורות
שאלות נפוצות
האם פיצול ללשוניות נוספות מגדיל את הנפח?
לא. מגבלת 10 מיליון התאים חלה על הקובץ כולו, ולשוניות מחלקות ביניהן את אותה מכסה. פיצול עוזר לארגון ולהרשאות, ולעיתים מקטין את גרף החישוב אם הוא מנתק תלויות, אבל הוא לא מוסיף קיבולת ולא מאיץ קובץ שסובל מנוסחאות פתוחות.
כמה שורות זה "יותר מדי" ב-Google Sheets?
אין מספר כזה. גיליון של 200,000 שורות בעמודות של ערכים בלבד יתפקד היטב, וגיליון של 8,000 שורות עם שלוש נוסחאות חיפוש על טווחים פתוחים יזחל. המדד הנכון הוא כמה תאים מחושבים מחדש אחרי הקלדה בודדת, לא כמה שורות קיימות.
מה קורה כשמייצאים גיליון גדול ל-Excel?
Excel מגביל גיליון ל-1,048,576 שורות, כך שרוב הקבצים ייכנסו. הסיכון אינו בגודל אלא בהמרה: נוסחאות ייחודיות ל-Sheets כמו QUERY או IMPORTRANGE לא קיימות ב-Excel, והקישורים ייהפכו לשגיאות או לערכים קפואים.
האם מעבר ל-BigQuery דרך Connected Sheets פותר את זה?
הוא פותר את הצד האנליטי. Connected Sheets מאפשר טבלת ציר על עד 200,000 שורות וחילוץ של עד 500,000 שורות או 5 מיליון תאים, בלי להכניס את הנתונים לקובץ. הוא אינו פותר קלט ועדכון תפעולי - לשם כך נדרש בסיס נתונים שאפשר לכתוב אליו.
להמשך קריאה
שירות רלוונטי
אוטומציה לעסקים
אני בונה אוטומציות מותאמות שמורידות עבודה חוזרת מקצה לקצה.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.