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

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

הערה: יצירה או הגדלה של נפח האחסון ל-64TB עשויה להגדיל את זמן האחזור של פעולות נפוצות, כמו גיבויים, בהתאם לעומס העבודה.

ב-Cloud SQL Admin API משתמשים בכותרות HTTP רגילות ובהתאמה אישית, כמו x-goog-user-project. הכותרת הזו של הבקשה מציינת את פרויקט המשתמש שישמש לחישוב המכסה בבקשה.

ערך תקין לבקשה הזו הוא מזהה הפרויקט של פרויקט Google Cloud קיים (לדוגמה,
x-goog-user-project: my-project). למשתמש ששולח את הבקשה צריכה להיות ההרשאה serviceusage.services.use למזהה הפרויקט הזה.

מכסות

מכסה מגבילה את כמות המשאבים של Google Cloud שאפשר להשתמש בהם בפרויקט ב- Google Cloud . ‫Cloud SQL הוא דוגמה לסוג כזה של משאב.

ב-Cloud SQL, המכסות הן חלק ממערכת שמבצעת את הפעולות הבאות:

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

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

הרשאות לבדיקה ולהגדלה של המכסות

כדי לבדוק ולהגדיל את המכסות, נדרשות ההרשאות הבאות:

• ‫serviceusage.quotas.get: בדיקת המכסות
• serviceusage.quotas.update: להגדיל את המכסות

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

בדיקת המכסות

כדי לבדוק את המכסות הנוכחיות של המשאבים בפרויקט, נכנסים לדף Quotas במסוףGoogle Cloud ומסננים לפי Cloud SQL Admin API. המכסות האלה חלות רק על קריאות ל-API, ולא כוללות שאילתות למסד הנתונים.

הגדלת המכסות

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

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

כדי להגדיל את המכסות:

1. נכנסים לדף Quotas במסוף Google Cloud .

   לדף Quotas

2. מסננים לפי השירות Cloud SQL Admin API.

   אם השירות לא מופיע, מפעילים את Cloud SQL Admin API.

3. מסמנים את התיבות לצד המכסות שרוצים לשנות ולוחצים על Edit quotas.

4. בשדה New limit של כל מכסה שבחרתם, מזינים את הערך של המגבלה הרצויה.

5. בשדה Reason description, מזינים את הסיבה לבקשה להגדלת המכסה ולוחצים על Done.

6. לוחצים על הבא.

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

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

איך מכסות המשאבים מתחדשות

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

מכסות וזמינות של משאבים

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

מכסות לקצב שליחת בקשות

ב-Cloud SQL יש תמיכה במכסות לקצב הגשת בקשות, שנקראות גם הגבלת קצב של יצירת בקשות או מכסות API. מכסות לקצב שליחת בקשות מגדירות כמה בקשות אפשר לשלוח ל-Cloud SQL Admin API.

כל מכסה לקצב הגשת בקשות תואמת לכל הבקשות לקטגוריה של שיטה אחת או יותר של Cloud SQL Admin API. המכסות לקצב שליחת בקשות מתאפסות אחרי פרק זמן שמוגדר ל-Cloud SQL (לדוגמה, מספר בקשות API לדקה).

כשאתם משתמשים ב-CLI של gcloud או במסוף Google Cloud , אתם שולחים בקשות ל-Cloud SQL Admin API והבקשות האלה נספרות במכסות לקצב הגשת הבקשות. אם אתם משתמשים בחשבונות שירות כדי לגשת ל-API, גם הבקשות האלה נכללות במכסות לקצב הגשת הבקשות.

‫Cloud SQL אוכף וממלא מחדש את המכסות לקצב הגשת הבקשות באופן אוטומטי במרווחים של 60 שניות. אם הפרויקט שלכם יגיע למגבלה של מכסה לקצב הגשת בקשות בפרק זמן של 60 שניות, תצטרכו להמתין עד שהמכסה תתמלא מחדש לפני שתוכלו לשלוח בקשות נוספות באותה קטגוריה. אם הפרויקט שלכם חורג מהמגבלה הזו, תקבלו קוד סטטוס HTTP‏ 429 עם הסיבה rateLimitExceeded.

‫Cloud SQL Admin API מחולק לקטגוריות הבאות:

• Connect: חיפוש ערכים שנדרשים כדי להתחבר למסד נתונים של Cloud SQL.
• ‫Get: אחזור מידע על משאב (לדוגמה, מכונה, פעולה או גיבוי).
• ‫List: הצגת רשימת משאבים.
• Mutate: יצירה, שינוי ומחיקה של משאבים.
• ברירת המחדל לכל אזור: אינטראקציה עם מכונה של Cloud SQL בלי להתחבר אליה, לאחזר אותה, להציג אותה ברשימה או לשנות אותה.
• ברירת מחדל: הצגת רשימה של דגלים לניהול מסדי נתונים וסוגי מכונות (רמות) של מכונות Cloud SQL. ממשקי ה-API בקטגוריה הזו הם גלובליים.

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

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

בטבלה הבאה מפורטים המדד, ממשקי ה-API ומגבלת ברירת המחדל לכל קטגוריה:

קטגוריה	מדד	ממשקי API	מגבלת ברירת המחדל
חיבור	sqladmin.googleapis.com/connect מספר הבקשות שנשלחות לדקה לכל משתמש בכל אזור כדי להשתמש בממשקי ה-API בקטגוריה הזו.	SqlConnectService. GetConnectSettings SqlConnectService. GenerateEphermalCertificates	1000
הורדה	sqladmin.googleapis.com/get מספר הבקשות לדקה לכל משתמש בכל אזור לשימוש בממשקי ה-API בקטגוריה הזו.	SqlBackupRunsService.Get SqlDatabasesService.Get SqlInstancesService.Get SqlOperationsService.Get SqlSslCertsService.Get SqlUsersService.Get	500
רשימה	sqladmin.googleapis.com/list מספר הבקשות לדקה לכל משתמש בכל אזור לשימוש בממשקי ה-API בקטגוריה הזו.	SqlBackupRunsService.List SqlDatabasesService.List SqlInstancesService.List SqlInstancesService. ListServerCas SqlOperationsService.List SqlSslCertsService.List SqlUsersService.List	500
שינוי	sqladmin.googleapis.com/mutate מספר הבקשות לדקה לכל משתמש בכל אזור לשימוש בממשקי ה-API בקטגוריה הזו.	SqlBackupRunsService.Delete SqlBackupRunsService.Insert SqlDatabasesService.Delete SqlDatabasesService.Insert SqlDatabasesService.Patch SqlDatabasesService.Update SqlInstancesService. AddServerCa SqlInstancesService.Clone SqlInstancesService.Delete SqlInstancesService. DemoteMaster SqlInstancesService.Import SqlInstancesService.Insert SqlInstancesService.Patch SqlInstancesService. PromoteReplica SqlInstancesService. ResetSslConfig SqlInstancesService. RestoreBackup SqlInstancesService. RotateServerCa SqlInstancesService. TruncateLog SqlInstancesService.Update SqlSslCertsService. CreateEphemeral SqlSslCertsService.Delete SqlSslCertsService.Insert SqlUsersService.Delete SqlUsersService.Insert SqlUsersService.Update	180
ברירת המחדל לפי אזור	sqladmin.googleapis.com/ default_per_region מספר הבקשות האזוריות שמוגדרות כברירת מחדל, שמתבצעות בכל דקה לכל משתמש בכל אזור, כדי להשתמש בממשקי ה-API בקטגוריה הזו.	SqlInstancesService.Export SqlInstancesService.Failover SqlInstancesService.Restart SqlInstancesService. StartReplica SqlInstancesService. StopReplica	180
ברירת מחדל	sqladmin.googleapis.com/default מספר ברירת המחדל של הבקשות שמשתמש יכול לשלוח בדקה כדי להשתמש בממשקי ה-API בקטגוריה הזו.	SqlFlagsService.List SqlTiersService.List	180

פתרון בעיות שקשורות לשגיאות של הגבלת קצב של יצירת בקשות

מכיוון ש-Cloud SQL אוכף מכסות לקצב הגשת בקשות לדקה, לכל משתמש ולכל אזור, בדף Cloud Quotas במסוף Google Cloud לא מוצג השימוש במכסות לכל משתמש. אם משתמש או חשבון שירות יחיד ממצה את המכסה לקצב הגשת בקשות לכל משתמש, Cloud SQL Admin API מחזיר קוד סטטוס HTTP‏ 429 Too Many Requests עם הסיבה rateLimitExceeded. במקרה כזה, יכול להיות שבמדדי המכסות המצטברים ברמת הפרויקט בדף Cloud Quotas יופיע שיש עדיין מכסה זמינה.

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

1. במסוף Google Cloud , בוחרים את הפרויקט הצרכני שממנו נשלחות הבקשות ל-Cloud SQL, ואז נכנסים לדף Metrics Explorer.
2. לוחצים על Select a metric ומזינים serviceruntime.googleapis.com/api/request_count בסרגל הסינון. בתפריטי המשנה, בוחרים באפשרות Consumed API > Api > Request count, ואז לוחצים על Apply.
3. ברכיב Filter, מוסיפים את המסננים הבאים כדי לבודד את הבקשות שבוצע להן ויסות:
   1. לוחצים על הוספת מסנן ואז על response_code. בתיבת הדו-שיח של המסנן, משאירים את Comparator מוגדר ל-= (equals), מזינים 429 בשדה Value ולוחצים על Apply.
   2. לוחצים שוב על הוספת מסנן ובוחרים באפשרות service. משאירים את Comparator מוגדר ל-= (equals), מזינים sqladmin.googleapis.com בשדה Value ולוחצים על Apply.
   3. אופציונלי: כדי לסנן לפי שיטת API ספציפית, לוחצים על Add filter ובוחרים את method. משאירים את Comparator מוגדר כ-= (equals), מזינים את שם השיטה בשדה Value (למשל google.cloud.sql.v1.SqlInstancesService.Get) ולוחצים על Apply.
4. ברכיב Aggregation, מוודאים שהתפריט הראשון מוגדר לערך Sum, ובתפריט השני (לצד by) בוחרים באפשרות credential_id כדי לקבץ את מספר הבקשות לפי פרטי כניסה ספציפיים.
5. בתוצאות, מחפשים את מזהה פרטי הכניסה (credential_id) עם הנפח הגבוה ביותר של קודי התגובה 429. הערך הזה הוא מזהה הלקוח ב-OAuth 2.0 של חשבון השירות או של פרטי הכניסה של המשתמש שמנצל את המכסה של קצב הבקשות לכל משתמש.
6. כדי למצוא את חשבון השירות שתואם למזהה הלקוח, נכנסים לדף Service accounts במסוףGoogle Cloud ומזינים את מזהה הלקוח ב-OAuth 2.0 בתיבת הסינון. הרשומה התואמת היא חשבון השירות שמנצל את מגבלת הקצב לכל משתמש.

כדי לפתור את השגיאה אחרי שזיהיתם את חשבון השירות, אתם יכולים להשתמש באחת או יותר מהדרכים הבאות:

• הטמעת שמירה במטמון בצד הלקוח: אם האפליקציה שלכם דוגמת לעיתים קרובות את המטא-נתונים של המכונה – למשל במהלך הפעלה מחדש של קונטיינרים או בדיקות תקינות – כדאי לשמור במטמון את המטא-נתונים של המכונה כדי להימנע מקריאות חוזרות ל-SqlInstancesService.Get.
• השהיה מעריכית לפני ניסיון חוזר (exponential backoff): צריך לוודא שלוגיקת הניסיון החוזר של הלקוח משתמשת בהשהיה מעריכית לפני ניסיון חוזר עם רעידות, כדי להימנע משליחת פרצים של בקשות שחורגות ממגבלת הקצב.
• חלוקת עומסי עבודה בין חשבונות שירות: אם כמה עומסי עבודה משתמשים באותו חשבון שירות או באותו פרויקט צרכן, צרו חשבונות שירות ייעודיים לכל עומס עבודה כדי למנוע מצב שבו עומס עבודה אחד ינצל את המכסה המשותפת.
• לבקש שינוי במכסה: אם האפליקציה דורשת תפוקה גבוהה יותר, בקשו להגדיל את המכסה לקצב הגשת בקשות של Cloud SQL Admin API.

מגבלות

יש הגבלות על חלק מהמשאבים של Cloud SQL שלא מתחדשים באופן תקופתי ולא מוצגים בדף Quotas במסוף Google Cloud . חלק מהמגבלות אפשר להגדיל, ואחרות לא.

מגבלות שניתן להגדיר

מכונות לכל פרויקט

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

• ארכיטקטורת רשת חדשה של SQL: אפשר ליצור עד 1,000 מכונות בכל פרויקט.
• ארכיטקטורת רשת SQL ישנה: אפשר ליצור עד 100 מכונות בכל פרויקט.
• שימוש בשתי הארכיטקטורות: המגבלה תהיה בין 100 ל-1,000, בהתאם להתפלגות המכונות בין שתי הארכיטקטורות.

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

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

מספר מקסימלי של חיבורים בו-זמניים

MySQL

אפשר להשתמש בדגל max_connections כדי להגדיר מגבלת חיבורים. כשיוצרים מכונה של Cloud SQL ל-MySQL, בוחרים סוג מכונה שקובע את כמות הזיכרון. כמות הזיכרון הזמין קובעת את מגבלות החיבור של המכונה.

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

כדי למצוא את מגבלת החיבורים של המכונה, מתחברים למסד הנתונים ומריצים את הפקודה הבאה: SHOW VARIABLES LIKE "max_connections";

PostgreSQL

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

כדי למצוא את מגבלות החיבור של המכונה, מתחברים למסד הנתונים ומריצים את הפקודה הבאה: SELECT * FROM pg_settings WHERE name = 'max_connections';

הערה: כדי לקבוע את הערך המקסימלי שאפשר להגדיר לדגל הזה, קודם צריך לחשב את מספר החיבורים לקצה העורפי שכבר נמצאים בשימוש. החישוב הזה הוא הסכום של הערכים של max_connections (המספר המקסימלי של חיבורי לקוחות), autovacuum_max_workers (המספר המקסימלי של תהליכי autovacuum) ו-max_worker_processes. הסכום לא יכול להיות גבוה מ-262142.

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

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

שרת SQL

מספר החיבורים בפועל תלוי בגרסת SQL Server שבה אתם משתמשים, וגם במגבלות של האפליקציה או האפליקציות והחומרה שלכם. ב-SQL Server אפשר ליצור עד 32,767 חיבורי משתמשים.

מידע נוסף על הגדרת חיבורי משתמשים ב-SQL Server זמין במאמרי העזרה.

נקודות שצריך לשים לב אליהן

ניצול המכסות של מחברי Cloud SQL

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

השימוש במכסה מחושב כך:

Quota usage = connector processes running * instances * 2 API calls per hour

לדוגמה, אם יש לכם שלושה תהליכים שמריצים מחבר, המחבר מוגדר להתחבר לשתי מכונות של Cloud SQL, ושתי קריאות ל-API מתבצעות במשך שעה, אז ניצול המכסה שלכם הוא 12 (3 תהליכים * 2 מכונות * 2 קריאות ל-API).

אם אתם מתחילים להשתמש ב-Cloud SQL, כדאי לשים לב לנוסחה שלמעלה ולזכור את הדברים הבאים:

• כמה מהר אתם מגדילים את מספר הלקוחות החדשים של DB

• כמה מהר אתם מוסיפים עוד מכונות

• שימוש בחשבונות שירות שונים לכל אפליקציה

אימות של מסד נתונים ב-Cloud SQL IAM

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

מכסת כללי העברה

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

רשת ה-VPC של יצרן Cloud SQL מקושרת לרשת ה-VPC של הלקוח, ולכן לעיתים קרובות אנחנו מגיעים למכסה לכל רשת של רשת היצרן של Cloud SQL, ולמכסה לכל קבוצת רשתות שכנות (peering) של רשת ה-VPC של הלקוח.

כשהמכסה מתמלאת, פעולות מסוימות עלולות להיכשל, כולל:

• פעולת יצירה: אנחנו צריכים כללי העברה חדשים כשאנחנו יוצרים מכונות חדשות.

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

• פעולת תחזוקה: כללי ההעברה נוצרים מחדש.

כדי למנוע בעיות, מומלץ להגביל את המספר הכולל של המופעים לכל רשת לפחות מ-500.

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

מגבלות קבועות

IOPS

‫IOPS הוא מספר פעולות הקלט/פלט (או קריאה/כתיבה) שהדיסק יכול לעבד בשנייה.

ב-Cloud SQL משתמשים במכונות וירטואליות (VM) של Compute Engine עם דיסקים לאחסון מתמיד. לפרטים על מאפייני ביצועים ספציפיים של מכונות וירטואליות, עיינו בטבלה maximum sustained IOPS בדף persistent disk performance.

מגבלת הטבלה

כברירת מחדל, ב-Cloud SQL ל-MySQL יש מגבלה של 50,000 טבלאות, או 500,000 טבלאות למכונה אם אתם עומדים בדרישות החומרה המינימליות של לפחות 32 ליבות וזיכרון מינימלי של 200G. כדי ליהנות מביצועים אופטימליים, מומלץ שמספר הטבלאות במסד נתונים אחד לא יעלה על 50,000.

מקרים שחורגים מהמגבלות האלה לא נכללים בהסכם ה-SLA. אם הדגל לניהול מסד הנתונים innodb_file_per_table מופעל וגודל הטבלה מגיע ל-16TB (הגודל המקסימלי למחיצות של Linux), אי אפשר להוסיף עוד נתונים.

כמות הזיכרון שנדרשת למכונה תלויה בגורמים שונים. במאמר איך MySQL משתמש בזיכרון מוסבר בהרחבה על השימוש של Cloud SQL ל-MySQL בזיכרון.

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

• כדי לקבל אפשרויות עם יותר זיכרון, שדרגו ל-Cloud SQL Enterprise Plus.
• כדי להוסיף זיכרון למכונה, שדרגו את המכונה של Cloud SQL.
• מקטינים את הערך של הדגל לניהול מסד הנתונים innodb_buffer_pool_size.

אפשר להשתמש בדגלים table_open_cache ו-table_definition_cache כדי לשנות את המטמון של הטבלה ב-Cloud SQL ל-MySQL. אתם יכולים להשתמש בסכימת הביצועים כדי לקבל אומדן של גודל המטמון של הטבלה במכונה שלכם. מידע נוסף זמין במסמכי התיעוד של MySQL.

אם מספר הטבלאות הפעילות גדול משמעותית גם מברירות המחדל של הטבלאות ב-Cloud SQL וגם מההמלצה של MySQL לגבי טבלאות פתוחות, Cloud SQL ממליץ להגדיר את הדגלים לניהול מסד הנתונים table_open_cache ו-table_definition_cache עם מספר הטבלאות הפעילות של המכונה. למידע נוסף, קראו את המאמר איך MySQL פותח וסוגר טבלאות.

גודל הטבלה המקסימלי ב-Cloud SQL ל-PostgreSQL הוא 32TB. כשטבלה מגיעה לגודל של 32TB, אי אפשר להוסיף לה עוד נתונים.

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

סוגי מכונות ברמת Micro ו-Small מגבילים את מספר הפעולות בו-זמנית. חריגה מהמגבלות האלה גורמת לשגיאת Too many operations.

המגבלה של סוג המכונה db-custom-1-3840 (מעבד (CPU) יחיד) היא 50 פעולות בו-זמנית.

מגבלות ExecuteSQL

בקשות ל-API בארכיטקטורת REST של ExecuteSql כפופות למגבלות הבאות:

• בכל מכונה אפשר להריץ עד 10 שאילתות בו-זמנית.
• קצב השאילתות מוגבל ל-100 שאילתות לדקה לכל פרויקט בכל אזור.
• הבקשות מוגבלות ל-‎512KiB ‏ (‎0.5MiB) והתשובות לא יכולות להיות גדולות מ-‎10MiB.

מגבלת איסוף המדדים

המדדים של PostgreSQL נאספים מעד 500 מסדי נתונים. אם יש יותר מ-500 מסדי נתונים, המדדים הספציפיים למסד הנתונים, כמו חיבורים לכל מסד נתונים, נצברים לערך יחיד ומוצגים בתור __ALL__.

מגבלות האחסון ב-Cloud SQL

• ליבה ייעודית: עד 64TB.

• ליבת מעבד משותפת: עד 3TB.

  מידע נוסף זמין במאמר תמחור של מכונות.

אפשרויות האחסון ב-Cloud SQL

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

המגבלות של App Engine

לכל מכונה של App Engine שפועלת בסביבה רגילה יכולים להיות עד 100 חיבורים בו-זמניים למכונה. באפליקציות PHP 5.5, המגבלה היא 60 חיבורים בו-זמניים.

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

אפליקציות App Engine כפופות גם למכסות ולמגבלות נוספות של App Engine, כפי שמתואר בדף מכסות של App Engine.

מגבלות ב-Cloud Run

אם אתם משתמשים בחיבור המובנה של Cloud SQL ב-Cloud Run, למכונות של מארזים ב-Cloud Run יש מגבלה של 100 חיבורים לכל מסד נתונים של Cloud SQL.

לכל מכונה של שירות או משימה ב-Cloud Run יכולים להיות 100 חיבורים למסד הנתונים, וככל שהשירות או המשימה גדלים, המספר הכולל של החיבורים לכל פריסה יכול לגדול.

המגבלה הזו לא חלה כשמשתמשים בשיטות חיבור אחרות, כמו Cloud SQL Auth Proxy ב-sidecar, מחברי השפה של Cloud SQL או כשמתחברים ישירות לכתובת ה-IP של המכונה ב-Cloud SQL.

המגבלות של פונקציות Cloud Run

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

פונקציות Cloud Run (דור שני) מבוססות על Cloud Run, והן מוגבלות ל-100 חיבורים למסד הנתונים לכל מכונה.

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

תצוגה מקדימה — שאילתות שמורות

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

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

מגבלות האחסון ב-Cloud SQL

• ליבה ייעודית: עד 64TB.

• ליבת מעבד משותפת: עד 3TB.

  מידע נוסף זמין במאמר תמחור של מכונות.

אפשרויות האחסון ב-Cloud SQL

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

המגבלות של App Engine

לכל מכונה של App Engine שפועלת בסביבה רגילה יכולים להיות עד 100 חיבורים בו-זמניים למכונה. באפליקציות PHP 5.5, המגבלה היא 60 חיבורים בו-זמניים.

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

אפליקציות App Engine כפופות גם למכסות ולמגבלות נוספות של App Engine, כפי שמתואר בדף מכסות של App Engine.

מגבלות ב-Cloud Run

אם אתם משתמשים בחיבור המובנה של Cloud SQL ב-Cloud Run, למכונות של מארזים ב-Cloud Run יש מגבלה של 100 חיבורים לכל מסד נתונים של Cloud SQL.

לכל מכונה של שירות או משימה ב-Cloud Run יכולים להיות 100 חיבורים למסד הנתונים, וככל שהשירות או המשימה גדלים, המספר הכולל של החיבורים לכל פריסה יכול לגדול.

המגבלה הזו לא חלה כשמשתמשים בשיטות חיבור אחרות, כמו Cloud SQL Auth Proxy ב-sidecar, מחברי השפה של Cloud SQL או כשמתחברים ישירות לכתובת ה-IP של המכונה ב-Cloud SQL.

המגבלות של פונקציות Cloud Run

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

פונקציות Cloud Run (דור שני) מבוססות על Cloud Run, והן מוגבלות ל-100 חיבורים למסד הנתונים לכל מכונה.