‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

מכסות ומגבלות

במאמר הזה מוסבר על מכסות ומגבלות המערכת של Bigtable.

המכסות נקבעות כברירת מחדל, אבל בדרך כלל אפשר לבקש לשנות אותן.
מגבלות המערכת קבועות ואי אפשר לשנות אותן.

המכסות שלGoogle Cloud עוזרות לשמור על הוגנות ולצמצם עליות חדות בשימוש במשאבים ובזמינות שלהם. הן מגבילות את כמות המשאבים שלGoogle Cloud שאפשר להשתמש בהם בפרויקט ב- Google Cloud . המכסות רלוונטיות למגוון רחב של סוגי משאבים, כולל רכיבי חומרה, תוכנה ורשתות. לדוגמה, המכסות יכולות להגביל את מספר הקריאות ל-API בשירות מסוים, את מספר מאזני העומסים שאפשר להשתמש בהם בו-זמנית בפרויקט או את מספר הפרויקטים שאפשר ליצור. בשורה התחתונה, המכסות מגינות על משתמשיGoogle Cloud בכך שהן מונעות עומס יתר על השירותים, אבל גם עוזרות לשלוט על השימוש במשאבי Google Cloud .

מערכת המכסות ב-Cloud:

עוקבת אחרי השימוש במוצרים ובשירותים של Google Cloud
מגבילה את השימוש במשאבים האלה
כוללת כלי שבאמצעותו אפשר לשלוח בקשות לשינוי המכסות ולשנות אותן אוטומטית

ברוב המקרים, כשאתם מנסים להשתמש ביותר משאבים מהמכסה, הגישה למשאב נחסמת ומה שאתם מנסים לעשות נכשל.

בדרך כלל, המכסות ב- Google Cloud הן ברמת הפרויקט. כלומר, השימוש במשאב מסוים בפרויקט כלשהו לא משפיע על המכסה שלכם בפרויקטים אחרים. ברמת הפרויקט ב- Google Cloud , המכסות משותפות לכל האפליקציות וכתובות ה-IP.

לסקירה כללית על מכסות ב-Cloud

כדי לשנות את רוב המכסות, משתמשים במסוף Google Cloud . איך שולחים בקשה לשינוי המכסות

למשאבי Bigtable יש גם מגבלות מערכת. שאי אפשר לשנות.

מכסות

בקטע הזה מתוארות מכסות ברירת המחדל שחלות על כל השימוש ב-Bigtable.

מכסות לפעולות של אדמינים

המכסות הבאות משפיעות על מספר הפעולות הניהוליות ב-Bigtable (קריאות ל-Admin API) שאפשר לבצע בפרק זמן נתון.

באופן כללי, אי אפשר לבקש להגדיל את המכסות של פעולות הניהול, חוץ מהמקרים שבהם צוין אחרת. לפעמים אנחנו מאשרים חריגות אם יש הצדקה חזקה. עם זאת, מספר הקריאות שהאפליקציה מבצעת ל-Admin API לא אמור לעלות כשהשימוש עולה. אם זה קורה, בדרך כלל זה סימן שקוד האפליקציה מבצע קריאות מיותרות ל-Admin API, וצריך לשנות את האפליקציה במקום לבקש להגדיל את מכסת הפעולות של האדמין.

המכסות היומיות מתאפסות בחצות, לפי שעון החוף המערבי של ארה"ב.

שם	תיאור	מכסת ברירת המחדל
מכונות ואשכולות
בקשות קריאה של מכונות ואשכולות	קריאת ההגדרות של מכונה או אשכול (לדוגמה, שם המכונה או מספר הצמתים באשכול), או קריאת רשימה של מכונות	ליום לפרויקט: 864,000 פעולות (ממוצע של 10 פעולות לשנייה) ‫לדקה לכל משתמש: 1,000 פעולות
בקשות כתיבה של מכונות ואשכולות	שינוי ההגדרות של מכונה או אשכול (לדוגמה, שם המכונה או מספר הצמתים באשכול), או יצירת מכונה חדשה	לכל יום לכל פרויקט: 500 פעולות לדקה לכל משתמש: 100 פעולות
פרופילים של אפליקציות
בקשות קריאה של פרופיל האפליקציה	קריאת ההגדרות של פרופיל האפליקציה	‫לדקה לכל פרויקט: 5,000 פעולות ‫לדקה לכל משתמש: 1,000 פעולות
בקשות כתיבה של פרופיל האפליקציה	שינוי ההגדרות של פרופיל האפליקציה	‫לדקה לכל פרויקט: 500 פעולות לדקה לכל משתמש: 100 פעולות
טבלאות
בקשות קריאה של אדמין בטבלה	קריאת ההגדרות של טבלה (לדוגמה, פרטים על קבוצות העמודות שלה) או קריאת רשימה של טבלאות	ליום לפרויקט: 864,000 פעולות (ממוצע של 10 פעולות לשנייה) ‫לדקה לכל משתמש: 1,000 פעולות
בקשות כתיבה של אדמין בטבלה	שינוי ההגדרות של טבלה (לדוגמה, הגדרות איסוף האשפה של קבוצת עמודות)	ליום לכל פרויקט: 5,000 פעולות לדקה לכל משתמש: 100 פעולות
אמצעי תשלום אחד (`DropRowRange`)	מחיקת טווח של שורות מטבלה בפעולה אחת.	ליום לכל פרויקט: 5,000 פעולות לדקה לכל משתמש: 100 פעולות
גיבויים
פעולות גיבוי	יצירה, עדכון ומחיקה של גיבוי.	ליום לכל פרויקט: 1,000 פעולות לדקה לכל משתמש: 10 פעולות¹
בקשות לאחזור גיבויים	קבלת גיבויים והצגת רשימה שלהם.	ליום לכל פרויקט: 864,000 פעולות
אמצעי תשלום אחד (`RestoreTable`)	שחזור גיבוי לטבלה חדשה.	ליום לכל פרויקט: 5,000 פעולות לדקה לכל משתמש: 100 פעולות
ניהול זהויות והרשאות גישה
בקשות GET של רשימות ACL ברמת פירוט גבוהה	קריאת מידע על מדיניות ה-IAM של מכונה ב-Bigtable, או בדיקת הרשאות ה-IAM של מכונה.	ליום לפרויקט: 864,000 פעולות (ממוצע של 10 פעולות לשנייה) ‫לדקה לכל משתמש: 1,000 פעולות
בקשות להגדרת רשימות ACL מפורטות	שינוי מדיניות ה-IAM של מכונה ב-Bigtable.	ליום לפרויקט: 864,000 פעולות (ממוצע של 10 פעולות לשנייה) ‫לדקה לכל משתמש: 1,000 פעולות
עומדים בדרישות להגדלת המכסה.

מכסות לצמתים

פרויקט ב- Google Cloud מכיל מכונות של Bigtable, שהן קונטיינרים של אשכולות. אשכול מייצג את שירות Bigtable שפועל באזור אחד. אשכולות מכילים צמתים, שהם משאבי מחשוב שמאפשרים ל-Bigtable לנהל את הנתונים שלכם.

מספר ברירת המחדל של הצמתים שאפשר להקצות לכל אזור בכל פרויקט תלוי באזור. אתם יכולים להקצות עד למספר ברירת המחדל של צומתי HDD ועד למספר ברירת המחדל של צומתי SSD לכל אזור בפרויקט.

מכסות ברירת המחדל לצמתים הן:

אזור	SSD	HDD
asia-east1	100	100
europe-west1	200	200
us-central1	200	200
us-east1	50	50
us-east4	50	50
us-west1	100	100
כל שאר המיקומים של Bigtable	30	30

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

מכסות וזמינות של צמתים

מכסת הצמתים היא המספר המקסימלי של צמתים שאפשר להקצות לכל אזור בכל פרויקט. המכסות לא מבטיחות שתמיד תוכלו להוסיף צמתים לאשכול. אם באזור מסוים אין יותר צמתים, יכול להיות שלא תוכלו להוסיף צמתים לאשכול באותו אזור, גם אם נשארה לכם מכסה בפרויקט.

לדוגמה, אם תנסו להוסיף 10 צומתי SSD לאשכול שכבר יש בו 20 צמתים, אבל באזור אין יותר צמתים, לא תוכלו להוסיף את 10 הצמתים האלה, גם אם המכסה של צומתי SSD באזור הזה היא 30.

במצבים כאלה, אנחנו מנסים להגדיל את משאבי הצמתים באזור, ואז מאשרים את הבקשות שלכם אחרי שהמשאבים האלה זמינים, בלי להבטיח את התזמון וההשלמה.

הצמתים שהקציתם תמיד יהיו זמינים.

מכסות של Data Boost

המכסות הבאות של יחידות עיבוד בשרת (SPU) חלות על כל פרויקט בכל אזור.

אזור	SPUs
asia-east1	100,000
europe-west1	200,000
us-central1	200,000
us-east1	100,000
us-east4	100,000
us-west1	100,000
כל שאר המיקומים של Bigtable	30,000

מידע נוסף על Data Boost זמין בסקירה הכללית של Data Boost.

איך רואים את פרטי המכסות?

כדי לראות כמה צומתי SSD ו-HDD כבר יש בפרויקט ב- Google Cloud בכל אזור, משתמשים ב- Google Cloud console. בחלונית הניווט שמימין, מעבירים את העכבר מעל IAM & admin, לוחצים על Quotas ובוחרים את השירות Bigtable Admin API בתפריט הנפתח Service.

בדף מוצגות שורות עם המכסות לכל שילוב של שירות, סוג צומת ומיקום. מחפשים את השורות עם כותרת המשנה SSD nodes per zone או HDD nodes per zone. בעמודה Limit מוצג המספר המקסימלי של צמתים שמותרים לסוג הצומת ולמיקום הנתונים, ובעמודה Current usage מוצג מספר הצמתים הקיימים. ההפרש בין שני המספרים האלה הוא מספר הצמתים שאפשר להוסיף בלי לבקש עוד.

בקשה להגדלת מכסת הצמתים

כדי שיהיה מספיק זמן לטפל בבקשה, תמיד כדאי לתכנן מראש ולבקש משאבים נוספים כמה ימים לפני שצריך אותם. לא בטוח שהבקשות להגדלת מכסת הצמתים יאושרו. למידע נוסף, קראו את המאמר עבודה עם מכסות.

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

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

נכנסים לדף Quotas.
לדף Quotas
בדף Quotas, בוחרים את המכסות שרוצים לשנות.
לוחצים על הכפתור Edit Quotas בחלק העליון של הדף.
בחלונית השמאלית, מקלידים את השם, כתובת האימייל ומספר הטלפון ולוחצים על Next.
מזינים את המכסה החדשה ולוחצים על Next.
שולחים בקשת תמיכה.

מגבלות

בקטע הזה מתוארות המגבלות שחלות על השימוש ב-Bigtable. המגבלות מובנות בשירות ואי אפשר לשנות אותן.

מגבלות על מספר הפרופילים של האפליקציה לכל מכונה

לכל מכונה יכולים להיות עד 2,000 פרופילי אפליקציות.

מגבלות על תצוגות מורשות

תצוגות מורשות לכל מכונה של Bigtable: עד 10,000
תחיליות של מגדירי עמודות לכל תצוגה מורשית: 10

מגבלות על גיבויים

מספר הגיבויים הרגילים שאפשר ליצור: 150 לכל טבלה בכל אשכול
מספר הגיבויים החמים המקסימלי שאפשר ליצור: 10 לכל טבלה בכל אשכול
תקופת השמירה המינימלית של גיבוי: 6 שעות אחרי זמן היצירה הראשוני
תקופת השמירה המקסימלית של גיבוי: 90 ימים במהדורת Enterprise או 365 ימים במהדורת Enterprise Plus, החל מתאריך היצירה הראשוני

מגבלות על סנכרון שינויים בזרמי נתונים

תקופת השמירה המקסימלית של סנכרון שינויים בזרמי נתונים בטבלה היא שבעה ימים.

מגבלות על תצוגות מהותיות רציפות

תצוגות מהותיות רציפות לכל מכונה: 50
תצוגות מהותיות רציפות לכל טבלה: 5

מגבלות של Data Boost

אשכול לא יכול לקבל יותר מ-1,000 בקשות קריאה של Data Boost בשנייה.

מגבלות על גודל הנתונים בטבלאות

המגבלות המומלצות

תכננו את הסכימה כך שגודל הנתונים לא יחרוג מהמגבלות המומלצות.

קבוצות עמודות לכל טבלה: 100
מגדיר עמודה יחיד: 16KB
ערך בודד בתא בטבלה: 10MB
כל הערכים בשורה אחת: 100MB

מגבלות קשיחות

בנוסף, אתם חייבים לוודא שהנתונים שלכם עומדים במגבלות הבאות:

מפתח שורה יחיד: 4KB
ערך בודד בתא בטבלה: 100MB
כל הערכים בשורה אחת: 256MB
מוטציה אחת: 200MB

מגבלות הגודל האלה נמדדות בקילובייטים בינאריים (KB), כאשר 1KB הוא 2¹⁰ בייטים, ובמגה-בייטים בינאריים (MB), כאשר 1MB הוא 2²⁰ בייטים. יחידות המידה האלה נקראות גם קיבי-בייטים (KiB) ומבי-בייטים (MiB).

מגבלות האורך של המזהה

אלה האורכים המינימליים והמקסימליים של מזהים (מספר התווים) שנתמכים ב-Bigtable.

פרופיל אפליקציה: 1-50
תצוגה מורשית: 1-50
גיבוי: 1-50
אשכול: 6-40
קבוצת עמודות: 1-64
דוגמה: 6-33
חבילת סכימות: 1-50
טבלה: 1-50
תצוגה: 1-128

מגבלות על רמת הזיכרון

המגבלות הבאות חלות על השכבה בזיכרון:

שינוי קנה מידה: שכבת הזיכרון הפנימי תומכת גם בשינוי קנה מידה אופקי (באמצעות התאמה אוטומטית לעומס) וגם בשינוי קנה מידה אנכי. כל צומת של Enterprise Plus כולל קיבולת בסיסית של 40,000 שאילתות לשנייה בזיכרון. כשהשכבה בזיכרון מופעלת, הצומת יכול להתאים את הגודל באופן אנכי כדי לתמוך בנפחים גדולים יותר במרווחים של 40,000 שאילתות לשנייה, עד למקסימום של 120,000 שאילתות לשנייה בזיכרון לכל צומת. מידע נוסף על הביצועים
גודל השורה: השכבה בזיכרון לא מציגה שורות שגדולות מ-‎1 MiB לכל מפתח שורה.

מגבלות על תצוגות לוגיות לכל מכונה

ב-Bigtable יש תמיכה בעד 1,000 תצוגות לוגיות בכל מכונה.

מגבלות על פעולות

כששולחים כמה מוטציות ל-Bigtable כאצווה אחת, חלות המגבלות הבאות:

אצווה של מוטציות מותנות, שקוראות ל-CheckAndMutate, יכולה לכלול עד 100,000 מוטציות TRUE וגם עד 100,000 מוטציות FALSE באצווה.
בכל שאר סוגי המוטציות, אפשר לכלול עד 100,000 מוטציות באצווה.

מגבלות על מספר האזורים לכל מכונה

למכונה של Bigtable יכולים להיות אשכולות ב-8 אזורים לכל היותר שבהם Bigtable זמין. אפשר ליצור אשכול אחד בכל אזור (zone) בתוך אזור (region). רשימת האזורים הזמינים של Bigtable

מגבלות על מסנני שורות

מסנן שורות לא יכול לחרוג מ-20KB. אם מופיעה הודעת שגיאה, צריך לעצב מחדש או לקצר את המסנן.

מגבלות על שאילתות שמורות

ערך	הגבלה
מספר השאילתות השמורות המקסימלי לכל פרויקט (כולל שאילתות שמורות למוצרים אחרים של Google Cloud )	10,000
הגודל המקסימלי של כל שאילתה	‎1 MiB

מגבלות על חבילות סכימות

המגבלות הבאות חלות על חבילות סכימה:

חבילות סכימה לכל טבלה: אפשר ליצור עד 10 חבילות סכימה לכל טבלה. המגבלה הזו חלה גם על חבילות סכימות של protobuf וגם על חבילות סכימות של Avro.
גודל חבילת הסכימה: התיאורים של מאגר האחסון לפרוטוקולים שעברו סריאליזציה או סכימות Avro בפורמט JSON בתוך חבילת סכימה לא יכולים להיות גדולים מ-4MB.

מגבלות האחסון לכל צומת

אם באשכול אין מספיק צמתים, בהתאם לעומס העבודה הנוכחי שלו ולכמות הנתונים שמאוחסנים בו, ל-Bigtable לא יהיו מספיק משאבי מעבד (CPU) כדי לנהל את כל הטאבלטים שמשויכים לאשכול. בנוסף, Bigtable לא יוכל לבצע משימות תחזוקה חיוניות ברקע. כתוצאה מכך, יכול להיות שהאשכול לא יוכל לטפל בבקשות נכנסות, וזמן האחזור יגדל. למידע נוסף, קראו את המאמר הפשרות בין נפח אחסון נדרש לביצועים.

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

הגדרת האחסון	Enterprise Edition	מהדורת Enterprise Plus
אשכולות SSD בלי אחסון מדורג (גרסת טרום-השקה (Preview))	‫5TB לכל צומת	‫5TB לכל צומת
אשכולות SSD עם אחסון מדורג	‫32TB לכל צומת, מתוכם עד 5TB של אחסון SSD.	‫64TB לכל צומת, מתוכם עד 5TB של אחסון SSD.
אשכולות HDD	‫16TB לכל צומת	‫16TB לכל צומת
שכבת In-memory (תצוגה מקדימה)	לא נתמך	‫8GB לכל צומת

ערכי TB נמדדים בטרה-בייט בינארי (TB), כאשר 1TB הוא 2‎⁴⁰‎ בייטים. יחידת המידה הזו נקראת גם tebibyte‏ (TiB).

מומלץ להוסיף מספיק צמתים לאשכול כדי להשתמש רק ב-70% מהמגבלות האלה, וכך להתמודד עם עליות פתאומיות בנפח אחסון נדרש. לדוגמה, אם אתם מאחסנים 50TB של נתונים באשכול שמשתמש באחסון SSD, כדאי להקצות לפחות 15 צמתים, שיטפלו בנתונים בנפח של עד 75TB. אם אתם לא מוסיפים כמויות גדולות של נתונים לאשכול, אתם יכולים לחרוג מההמלצה הזו ולאחסן עד 100% מהמגבלה.

מגבלות על מספר הטבלאות בכל מכונה

ב-Bigtable אפשר ליצור עד 1,000 טבלאות בכל מכונה. תצוגות מהותיות נספרות במספר הטבלאות.

מדיניות השימוש

השימוש בשירות הזה כפוף לתנאים ולהגבלות וגם למדיניות הפרטיות של Google.