מדריך

פלטפורמת מסחר אלקטרוני גלובלית הדורשת עסקאות ACID, עקביות חזקה וזמינות של 99.999% על פני יבשות מרובות.

→Cloud Spanner בתצורה מרובת אזורים (לדוגמה, nam-eur-asia).

למה: Spanner הוא שירות GCP המנוהל היחיד המספק עסקאות ACID מבוזרות גלובלית ועקביות חזקה בקנה מידה עם SLA של 99.999%.

מקור↗

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

→AlloyDB for PostgreSQL.

למה: AlloyDB מציע ביצועי PostgreSQL מעולים, תכונות תאימות ל-Oracle ומנוע עמודתי להאצת שאילתות אנליטיות (HTAP) מבלי להשפיע על עומסי עבודה טרנזקציוניים.

מקור↗

הזנה בתפוקה גבוהה (מיליוני OPS) של נתוני סדרות זמן (לדוגמה, IoT, לוגים) הדורשת קריאות עם השהיה נמוכה ותפוגת נתונים אוטומטית.

→Cloud Bigtable עם עיצוב מפתח שורה `(entity_id)#(reverse_timestamp)` ומדיניות איסוף זבל.

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

מקור↗

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

→Firestore במצב Native.

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

מקור↗

חיפוש דמיון בקנה מידה גדול (10M+ וקטורים) עבור יישומי AI/ML (לדוגמה, RAG, המלצות) הדורש השהיה של פחות מ-100 אלפיות השנייה.

→AlloyDB for PostgreSQL עם הרחבת pgvector ואינדקס ScaNN.

למה: AlloyDB משלב את אלגוריתם ScaNN בעל הביצועים הגבוהים של גוגל לחיפוש approximate nearest neighbor (ANN), ועולה על יישומי חיפוש וקטוריים סטנדרטיים בקנה מידה.

תכנון סכימת Cloud Spanner לעומס עבודה כבד בכתיבה כדי למנוע נקודות חמות בשרת יחיד.

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

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

מקור↗

לסכימת Spanner יש קשר חזק של הורה-ילד (לדוגמה, Customers ו-Orders) ושאילתות מאחזרות לעיתים קרובות הורה עם כל ילדיו.

→השתמש בטבלאות משולבות (interleaved tables), והגדר את טבלת הילד עם `INTERLEAVE IN PARENT`.

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

מעקב אחר מיקומים בזמן אמת עבור צי רכבים ענק (50k+ כתיבות/שנייה) עם שאילתות למציאת כלי רכב באזור גיאוגרפי.

→Cloud Bigtable עם מפתח שורה המקודם על ידי GeoHash של מיקום הרכב.

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

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

→אחסן נתונים גולמיים ב-Cloud Storage ושלף אותם ישירות מ-BigQuery באמצעות טבלאות חיצוניות, או טען לאחסון BigQuery מקורי.

למה: BigQuery הוא מחסן נתונים ללא שרת שנבנה עבור אנליטיקה בקנה מידה של פטה-בייטים. הפרדת האחסון והמחשוב שלו מספקת ביצועי שאילתות ללא תחרות וחסכוניות עבור עומסי עבודה של OLAP.

מטמון בזיכרון בזמינות גבוהה עבור מבני נתונים מורכבים (hashes, sets) עם יכולות pub/sub לביטול תוקף מטמון.

→Memorystore for Redis Standard Tier עם עותקים לקריאה (read replicas).

למה: Standard Tier מספק SLA של 99.9% עם כשל אוטומטי (automatic failover). Redis תומך בסוגי נתונים מורכבים ו-pub/sub, בניגוד ל-Memcached. עותקים לקריאה יכולים להגדיל את תפוקת הקריאה.

תכנון יישום SaaS מרובה דיירים ב-Spanner הדורש בידוד נתונים חזק ואבטחת ביצועים לכל דייר.

→השתמש ב-tenant_id כמרכיב הראשון של המפתח הראשי עבור כל הטבלאות. לבידוד חזק יותר, השתמש במודל מסד נתונים לכל דייר בתוך מופע Spanner יחיד.

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

מסד נתונים של Cloud SQL חווה ביצועי שאילתות איטיים ושימוש גבוה במעבד.

→השתמש ב-Query Insights כדי לזהות את השאילתות עתירות המשאבים ביותר, נתח את תוכניות הביצוע שלהן, וזהה אינדקסים חסרים או דפוסים לא יעילים.

למה: Query Insights הוא הכלי העיקרי המובנה לאבחון ביצועי שאילתות ב-Cloud SQL. הוא מדמיין את עומס השאילתות, מזהה אירועי המתנה, ועוזר לאתר את שורש הבעיה ללא כלי צד שלישי.

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

→צור סביבת עבודה של Cloud Monitoring בפרויקט מרכזי והגדר את "היקף המדדים" שלה לכלול את כל הפרויקטים המכילים מופעי מסד נתונים.

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

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

→השתמש ב-Terraform עם ספק Google Cloud. הגדר מודול Cloud SQL והשתמש בקבצי `.tfvars` נפרדים לכל סביבה.

למה: Terraform מספקת Infrastructure as Code (IaC), המאפשרת פריסות חוזרות, ניתנות לביקורת ובקרת גרסאות. זה מונע שגיאות תצורה ידניות ומבטיח עקביות בין הסביבות.

קבלן זקוק לגישת מסד נתונים זמנית מוגברת שיש לבטל אוטומטית לאחר 4 שעות.

→הענק את תפקיד IAM הדרוש עם תנאי IAM המשתמש בביטוי מבוסס זמן (`request.time < timestamp(...)`).

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

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

→הגדר את מופע Cloud SQL או AlloyDB להשתמש במפתח מ-Cloud KMS. הגדר רוטציה אוטומטית במפתח KMS.

למה: CMEK מספקת שליטה ויכולת ביקורת על המפתחות המשמשים להצפנה במנוחה. Cloud KMS מטפל בניהול מחזור חיי המפתח, כולל רוטציה אוטומטית, בצורה חלקה.

דרישות תאימות מחייבות ללכוד את כל שאילתות SQL שבוצעו במופע Cloud SQL for PostgreSQL, עם שמירת לוגים למשך 7 שנים.

→אפשר את הרחבת `pgaudit` במופע. הגדר Cloud Audit Logs לגישת נתונים. צור כיור לוגים מ-Cloud Logging ל-BigQuery לשמירה וניתוח לטווח ארוך.

למה: pgaudit מספק ביקורת מפורטת ברמת SQL. הטמעת לוגים ל-BigQuery היא התבנית הסטנדרטית והחסכונית לשמירת לוגים לטווח ארוך וניתנים לחיפוש מעבר לברירת המחדל של Cloud Logging.

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

→צור עותק לקריאה (read replica) והפנה אליו את כל השאילתות האנליטיות. עבור אנליטיקה מורכבת יותר, השתמש ב-BigQuery federated queries מול העותק לקריאה.

למה: עותק לקריאה מבודד לחלוטין תעבורת קריאה אנליטית מהמופע הראשי, ומגן על ביצועי OLTP. פדרציה מאפשרת שימוש במנוע החזק של BigQuery ללא צינור ETL נפרד.

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

→השתמש בכלי Key Visualizer במסוף Cloud כדי לנתח את דפוסי הגישה ולזהות את טווחי מפתחות השורות הספציפיים אליהם ניגשים לעיתים קרובות מדי (hotspotting).

למה: Key Visualizer הוא כלי האבחון הייעודי לבעיות ביצועים ב-Bigtable. הוא מספק מפת חום של גישת מפתחות, ומקל על זיהוי נקודות חמות שיש לטפל בהן באמצעות עיצוב סכימה מחדש.

צורך לשכפל שינויים ממסד נתונים של Cloud SQL OLTP למחסן נתונים של BigQuery בזמן אמת כמעט.

→השתמש ב-Datastream כדי להגדיר זרם Change Data Capture (CDC) ממופע Cloud SQL המקור ישירות ל-BigQuery.

למה: Datastream הוא שירות CDC מנוהל עם השהיה נמוכה שקורא לוגי מסד נתונים, ממזער השפעה על המקור. הוא מטפל בהזזת סכימה ומספק שינויים באופן אמין ל-BigQuery.

יישום Cloud Run ממצה חיבורי מסד נתונים עקב התרחבות מהירה במהלך שיאי תעבורה.

→פרוס את Cloud SQL Auth Proxy כקונטיינר צדדי והגדר אותו לאיגום חיבורים (או השתמש בו עם pooler ייעודי כמו PgBouncer).

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

העברת מסד נתונים גדול (5TB) של MySQL מקומי ל-Cloud SQL for MySQL עם זמן השבתה מרבי של 30 דקות.

→השתמש ב-Database Migration Service (DMS) כדי להגדיר משימת שכפול רציפה. DMS מבצע טעינה ראשונית ולאחר מכן מזרימה שינויים עד למעבר (cutover).

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

מקור↗

העברת מסד נתונים של Oracle ל-AlloyDB for PostgreSQL, כולל פרוצדורות שמורות מורכבות של PL/SQL.

→השתמש ב-DMS להעברת נתונים. השתמש בכלי המרת סכימה (כמו Ora2Pg או DMS Schema Conversion) כדי להמיר סכימות ו-PL/SQL ל-PL/pgSQL, ולאחר מכן בביקורת ובדיקה ידנית.

למה: העברות הטרוגניות דורשות גם העברת נתונים (מטופלת על ידי DMS) וגם המרת סכימה/קוד. כלים אוטומטיים מטפלים בכ-80% מההמרה, אך תמיד נדרשת עבודה ידנית עבור תכונות ספציפיות ל-Oracle.

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

→השתמש בכלי אימות הנתונים בקוד פתוח (DVT). הגדר אותו להשוות ספירות שורות, אגרגציות ברמת עמודה (min, max, sum), ו-hashes ברמת שורה בין המקור ליעד.

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

העברת יישום MySQL מחולק (sharded) למסד נתונים יחיד ועקבי גלובלית.

→השתמש במספר עבודות Dataflow מקבילות כדי להעביר כל shard באופן מקבילי למסד נתונים יחיד של Cloud Spanner. עצב מחדש את הסכימה כדי לבטל את הצורך בשיתוף ברמת היישום.

למה: Spanner מיועד להחליף ארכיטקטורות מחולקות מורכבות. גישת הגירה מקבילה עם Dataflow היא הדרך היעילה ביותר מבחינת זמן לאחד מערכי נתונים גדולים ומחולקים ל-Spanner.

העברת מסד נתונים של SQL Server המשתמש באימות Windows (Active Directory) ל-Cloud SQL for PostgreSQL.

→שלב את Cloud SQL עם Cloud Identity באמצעות אימות מסד נתונים של IAM. סנכרן קבוצות AD לקבוצות Google באמצעות GCDS, ומפה תפקידי מסד נתונים לקבוצות אלו.

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

העברת יישום מ-Amazon DynamoDB ל-Cloud Bigtable.

→מפה את המפתח הראשי המורכב של DynamoDB (מפתח מחיצה + מפתח מיון) למפתח שורה משורשר של Bigtable, מופרד באמצעות מפריד (לדוגמה, `partitionKey#sortKey`).

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

יישום המתחבר למופע Cloud SQL בזמינות גבוהה חייב לשרוד כשל אזורי (zonal failover) ללא התערבות ידנית.

→התחבר למסד הנתונים באמצעות Cloud SQL Auth Proxy עם שם חיבור המופע (project:region:instance), ולא כתובת IP סטטית.

למה: כתובת ה-IP של המופע משתנה במהלך כשל. ה-Auth Proxy ושם חיבור המופע מספקים נקודת קצה יציבה המתורגמת אוטומטית לכתובת ה-IP של המופע הראשי הנוכחי.

מקור↗

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

→השתמש בתצורה מרובת אזורים עם אזור המנהיג (leader region) בצפון אמריקה (`nam*`). קריאות באסיה יוגשו על ידי עותקים מקומיים לקריאה בלבד.

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

לאפליקציה המגובה ב-AlloyDB יחס קריאה-כתיבה של 10:1 והיא צריכה להתרחב כדי לטפל בתעבורת קריאה גבוהה תוך שמירה על זמינות של 99.99%.

→הגדר את המופע הראשי עם זמינות גבוהה והוסף מספר מופעי read pool. הפנה תעבורת קריאה ל-read pool.

למה: זמינות גבוהה של AlloyDB מספקת את ה-SLA של 99.99%. מופעי read pool מיועדים להרחבת קריאה אופקית, מורידים עומס תעבורה מהמופע הראשי לצמתים ייעודיים הממוטבים לקריאה.

מופע Cloud SQL רגיש להשהיה עם אחסון SSD בעל ביצועי I/O בלתי מספקים.

→הגדל את גודל האחסון המסופק של המופע.

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

צורך לפרוס שינוי סכימה מסוכן למסד נתונים קריטי של Cloud SQL עם יכולת חזרה מהירה.

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

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

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

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

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

שירות Cloud Run צריך להתחבר למופע Cloud SQL בצורה מאובטחת ללא תעבורה העוברת דרך האינטרנט הציבורי.

→הגדר את Cloud SQL עם כתובת IP פרטית. צור מחבר Serverless VPC Access באותו VPC והגדר את שירות Cloud Run לנתב תעבורה דרכו.

למה: זוהי התבנית הסטנדרטית והמאובטחת לחיבור מחשוב ללא שרת למשאבי VPC-native. המחבר מגשר על סביבת ללא השרת וה-VPC שלך, ושומר את כל התעבורה ברשת הפרטית של גוגל.

הוספת עמודה חדשה, שאינה ניתנת לאיפוס (non-nullable), לטבלת Cloud Spanner ענקית שנכתבת באופן פעיל ללא זמן השבתה.

→1. הוסף את העמודה כניתנת לאיפוס (nullable). 2. עדכן את קוד היישום כדי לכתוב לעמודה החדשה. 3. מלא מחדש שורות קיימות בקבוצות באמצעות Dataflow. 4. לאחר המילוי מחדש, שנה את העמודה ל-NOT NULL.

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