Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

במאמר הזה מפורטות המכסות והמגבלות של המערכת שחלות על 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, ועליכם לשנות את האפליקציה במקום לבקש להגדיל את מכסת הפעולות של Admin API.

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

שם	תיאור	מכסת ברירת מחדל
Instances and clusters
בקשות קריאה של מופעים ושל אשכולות	קריאת ההגדרה של מופע או אשכול (לדוגמה, שם המופע או מספר הצמתים באשכול), או קריאת רשימה של מופעים	לכל פרויקט ביום: 864,000 פעולות (ממוצע של 10 פעולות בשנייה) לדקה לכל משתמש: 1,000 פעולות
בקשות כתיבה למופע ולצביר	שינוי ההגדרה של מופע או אשכול (לדוגמה, שם המופע או מספר הצמתים באשכול), או יצירת מופע חדש	ביום לכל פרויקט: 500 פעולות לדקה לכל משתמש: 100 פעולות
פרופילים של אפליקציות
בקשות קריאה של פרופיל האפליקציה	קריאת ההגדרות של פרופיל אפליקציה	לדקה לכל פרויקט: 5,000 פעולות לדקה לכל משתמש: 1,000 פעולות
בקשות כתיבה לפרופיל האפליקציה	שינוי ההגדרות של פרופיל אפליקציה	לדקה לכל פרויקט: 500 פעולות לדקה לכל משתמש: 100 פעולות
טבלאות
בקשות קריאה של מנהל מערכת בטבלה	קריאת ההגדרה של טבלה (לדוגמה, פרטים על משפחות העמודות שלה) או קריאת רשימה של טבלאות	לכל פרויקט ביום: 864,000 פעולות (ממוצע של 10 פעולות בשנייה) לדקה לכל משתמש: 1,000 פעולות
בקשות כתיבה של אדמינים בטבלה	שינוי התצורה של טבלה (לדוגמה, הגדרות איסוף האשפה עבור משפחת עמודות)	לכל פרויקט ביום: 5,000 פעולות לדקה לכל משתמש: 100 פעולות
`DropRowRange` method	מחיקת טווח של שורות מטבלה בפעולה אחת.	לכל פרויקט ביום: 5,000 פעולות לדקה לכל משתמש: 100 פעולות
גיבויים
פעולות גיבוי	יצירה, עדכון ומחיקה של גיבוי.	ביום לכל פרויקט: 1,000 פעולות לכל דקה לכל משתמש: 10 פעולות¹
בקשות לאחזור גיבוי	קבלת גיבויים והצגתם ברשימה.	ביום לכל פרויקט: 864,000 פעולות
`RestoreTable` method	שחזור גיבוי לטבלה חדשה.	לכל פרויקט ביום: 5,000 פעולות לדקה לכל משתמש: 100 פעולות
ניהול זהויות והרשאות גישה
בקשות אחזור של רשימות 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 (מכסות) ומשתמשים בתפריט הנפתח Service (שירות) כדי לבחור את שירות Bigtable Admin API.

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

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

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

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

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

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

מגבלות

בקטע הזה מתוארות מגבלות שחלות על השימוש שלכם ב-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), כאשר ‎1 KB שווה ל-‎2¹⁰ בייט, ובמגה-בייט בינארי (MB), כאשר ‎1 MB שווה ל-‎2²⁰ בייט. יחידות המידה האלה נקראות גם kibibytes (KiB) ו-mebibytes (MiB).

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

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

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

מגבלות של רמת שירות בזיכרון

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

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

מגבלות על תצוגות לוגיות לכל מופע

‫Bigtable תומך ב-1,000 תצוגות לוגיות לכל היותר בכל מופע.

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

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

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

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

במופע Bigtable יכולים להיות אשכולות בעד 8 אזורים שבהם Bigtable זמין. אפשר ליצור אשכול אחד בכל אזור באזור. רשימת האזורים הזמינים מופיעה במאמר מיקומי Bigtable.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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