הגדרת הרחבות PostgreSQL: היכן זה נשבר בפרודקשן
הרחבות מותקנות למשימה מסוימת: שאילתות גיאוגרפיות ומסלולים, חיפוש מקורב לפי שמות, חיפוש וקטורי לפי אמבדינגים, משימות מתוזמנות בתוך מסד הנתונים עצמו. בסביבת בדיקה הגדרת הרחבות PostgreSQL נראית כמו פקודה אחת על מסד נתונים ריק, ולכן דוחים אותה עד הרגע האחרון.
בפרודקשן אותה פקודה מבוצעת על טבלה חיה, תחת נעילה, בתעבורה פעילה — וזה המקום הראשון שבו הפער בין סביבת הבדיקה למציאות נעשה גלוי.
הידרדרות תוכנית השאילתות בדרך כלל לא מגיעה מיד. הרחבה מוסיפה טיפוסים ואופרטורים משלה, אבל סטטיסטיקה עבורם לא נאספת מעצמה: המתכנן טועה בהערכת הסלקטיביות, עובר מסריקת אינדקס לקריאה סדרתית, ושאילתה שהחזיקה זמן תגובה של עשרות מילישניות מתחילה להיתקע בצוואר בקבוק בפרודקשן. זה מתבטא לא כשגיאה, אלא כעלייה שקטה בזמן התגובה על שאילתות בחירה, שם קודם היה הכל תקין.
סיפור נפרד — שכפול. ספריית ההרחבה חייבת להיות נוכחת בכל צומת ולהיות באותה גרסה, חלק מההרחבות דורשות טעינה מוקדמת בעת אתחול האשכול, וחלק מהאובייקטים נוצרים רק בצומת הראשי. אם זה לא נלקח בחשבון, הרפליקה נתפסת בשגיאת שחזור ונעצרת, ומעבר אליה ברגע התקלה מתברר כבלתי אפשרי.
קריסה לאחר עדכון האשכול — השגיאה היקרה ביותר בהתקנת הרחבות. עדכון הבינארים לא מעדכן את ההרחבות עצמן: קבצים ישנים נשארים במקום, הגרסאות במסד ובקובץ נפרדות, ושחזור מדאמפ נתקל בטיפוסים מותאמים אישית. לכן אנו מפרטים כיצד זה נסגר שלב אחר שלב.
מה משתנה בפרודקשן לאחר התקנה נכונה
לאחר הגדרת הרחבות PostgreSQL התמונה בפרודקשן משתנה באופן מדיד.
מודולים מנוהלים של מסד הנתונים מותקנים באותו אשכול, ולכן היישום כבר לא זקוק למאגרים נפרדים עבור כל סוג חיפוש: זמן התגובה של שאילתות בחירה לפי קואורדינטות מצטמצם פי כמה, וחיפוש מקורב לפי שמות מפסיק להיתקע במעבר מלא על שורות.
חיפוש גיאוגרפי באשכול אחד מסיר סוג שלם של כשלים — חוסר סנכרון בין מסד הנתונים הראשי לשירות גיאוגרפי חיצוני, מסלול גיבוי שני, סכמות נתונים שמתפצלות. חיפוש טקסט מלא ללא שירות נפרד נותן את אותו הדבר: נקודת כשל אחת במקום שתיים, ומספר הרכיבים החיצוניים במסלול פוחת.
בחירה וקטורית לפי משמעות עובדת על אותן שורות כמו שאילתות בחירה רגילות, ומשימות מתוזמנות בתוך מסד הנתונים מחליפות מתזמן חיצוני. בנייה מחדש של אינדקסים וניקוי רשומות מיושנות מתבצעים בטרנזקציה, ללא שכבת ביניים שעלולה להתנתק בנפרד ממסד הנתונים.
מה כדאי לתעד בדוח לאחר ההתקנה: זמן תגובה חציוני ואחוזון 95 בשאילתות חיפוש, נפח האינדקסים המתוחזקים והגידול שלהם בחודש, מספר השירותים החיצוניים לפני ואחרי, שיעור המשימות שכבר לא זקוקות למתזמן חיצוני, ורשימת הכשלים שהפכו לבלתי אפשריים.
דרכים לחבר הרחבות: השוואת גישות
ההרחבה חיה באותו אשכול כמו מסד הנתונים, לכן דרך החיבור קובעת מי אחראי לעדכונים ומה יקרה במעבר לשרת אחר. לפני הבחירה בודקים שלושה דברים: האם קיימת בנייה לגרסה הראשית של השרת, מי מתחזק את החבילה וכיצד ההרחבה תתנהג בשחזור מגיבוי.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| התקנה ממאגר חבילות | שרת או קונטיינר בשליטתנו, גרסת השרת תואמת לזו שלשמה נבנתה החבילה | מערך ההרחבות מוגבל למה שהמתחזק בנה; עבור גרסה ראשית חדשה החבילה מופיעה באיחור |
| בנייה מקוד מקור | נדרשת גרסה או תיקון שאינם במאגר | נדרש מערך מהדרים וקבצי כותרת; הבנייה חוזרת בכל עדכון שרת ועוקבים אחרי תאימות |
| תמונת קונטיינר מותקנת מראש | הרכב ההרחבות חייב להיות זהה בכל סביבות הבדיקה, כולל מקומיות | עדכון רק בבנייה מחדש של התמונה; תלות בתג ואובדן שליטה על ההרכב |
| אשכול ענן מנוהל | לא רוצים לתחזק שרת ועדכונים בעצמנו | זמינה רק רשימה שאושרה על ידי הספק; אין הרשאות סופר-משתמש, לא ניתן לחבר קוד הרחבה משלנו |
קבצים על הדיסק עדיין לא הופכים את ההרחבה לפעילה: יוצרים אותה בכל מסד נתונים בנפרד, וחלק מההרחבות דורשות רישום עצמן ברשימת הספריות הנטענות מראש והפעלה מחדש של האשכול. מכאן התקלה הנפוצה ביותר — 'הותקן, אך לא נמצא'; את הבדיקה מבצעים על אשכול בדיקה לפני העלייה לאוויר.
סדר ההטמעה: מביקורת ועד מסירה לתמיכה
הרחבות משנות לא רק את מערך הפונקציות, אלא גם את תוכניות ביצוע השאילתות, פורמט האחסון ודרישות הזיכרון. להתקין אותן מיד על אשכול הייצור פירושו לבדוק על משתמשים חיים, לכן השלבים מתבצעים לפי סדר קפדני, וכל שלב מתחיל לאחר קבלת השלב הקודם.
- ביקורת אשכול ותאימות. משווים את גרסת הליבה לבניות הזמינות, בודקים תלויות, הרשאות תפקידים ונפח טבלאות עבור אינדקסים מרחביים ווקטוריים. בפלט — מפה: מה מופעל מיד, מה דורש עדכון.
- תכנון מיקום. קובעים באילו סכמות חיים PostGIS, pg_trgm, pgvector ו-pg_cron, כיצד הם ייכנסו לגיבויים ולפריסה. עבור pg_cron מתאמים בנפרד פרמטרים להפעלה בקונפיגורציית האשכול.
- הגדרה על עותק של פרודקשן. פורסים עותק עם נפח נתונים דומה, בונים אינדקסים, מודדים זמן ועומס על הדיסק. המספרים מופיעים לפני חלון המעבר, לא במהלכו.
- בדיקה. משווים תוכניות ביצוע לפני ואחרי, מריצים בדיקות פונקציונליות ובוחנים שאילתות בחירה עם ערכים נדירים, שבהם התנהגות ההרחבות פחות צפויה.
- תוכנית נסיגה. קובעים נקודת חזרה וסדר פעולות הפוך. הסרת הרחבה לא תמיד ללא כאב, לכן תמונת מצב ונוהל מוכנים מראש.
- מעבר ללא השבתה. מעבירים עומס דרך רפליקה, מפעילים מנגנונים בזה אחר זה ובודקים השהיות, כדי שמשתמשים לא יבחינו בשינוי התצורה.
- מסירה לתמיכה. מוסרים תיעוד, נוהל עדכון הרחבות וניטור מדדים עיקריים — צוות הלקוח מלווה את האשכול בהמשך באופן עצמאי.
קונפיגורציות, סכמות ונהלים בפלט
הרחבות לא חיות מעצמן: צריך למקם אותן איפשהו, להעניק להן הרשאות למישהו, לסנכרן עם גרסת השרת ולעדכן ללא השבתה. לכן בפלט אתם מקבלים לא סט פקודות מהתיעוד, אלא ערכה שלפיה אפשר להקים את מסד הנתונים מאפס ולהעביר למשמרת תורנית.
- קבצי קונפיגורציה של פרמטרים. צוין בנפרד מה מחובר דרך רשימת הטעינה המוקדמת הכללית (הפעלה מחדש חובה), ומה משתנה תוך כדי תנועה; נבחרו נפחי זיכרון לבניית אינדקסים מרחביים ווקטוריים, הוגדר שם מסד נתונים עבור מתזמן המשימות.
- סכמות מיקום ותפקידים. ההרחבות הועברו לסכמה משלהן, לא לסכמה כללית; נתיב החיפוש מוגדר במפורש ברמת תפקידי היישומים — עדכון ההרחבה לא שובר שאילתות ולא דורש הרשאות סופר-משתמש.
- מדיניות גישה והרשאות. תפקידי קריאה וכתיבה נפרדים, הרשאות ממוקדות לסכמה ולפונקציות, מדיניות ברמת שורה במקום שבו חיפוש וקטורי נוגע בנתוני משתמשים.
- סקריפטים להתקנה ולנסיגה. מיגרציות אידמפוטנטיות עם קיבוע גרסת ההרחבה: הרצה חוזרת לא שוברת דבר, נסיגה מחזירה את המצב הקודם, ולא 'נבנה את מסד הנתונים מחדש'.
- נוהל תחזוקה. מתי בונים מחדש אינדקסים לאחר טעינה המונית, מתי נאספת סטטיסטיקה, באיזה סדר מתעדכנת ההרחבה ובאילו חלונות זמן זה מתבצע.
- הוראות למשמרת תורנית. מה לבדוק בניטור, אילו שגיאות הרחבה להיחשב כאירוע, כיצד להסיר או לדחות משימת רקע בבטחה, למי להסלים.
- שאילתות בדיקה ובדיקות. שאילתות בחירה מוכנות לפי רשימת ההרחבות המותקנות, השוואת הרשאות בפועל מול הצפויות וסט מינימלי של שאילתות הבודקות גאומטריה, חיפוש מקורב וחיפוש וקטורי.
מקרה בוחן: חיפוש גיאוגרפי ובחירה וקטורית באשכול אחד
נקודת התחלה
שירות משלוחים החזיק חיפוש גיאוגרפי ובחירת מוצרים דומים בשני שירותים חיצוניים: אחד שמר עותק משלו של קואורדינטות נקודות, והשני סיפק רשימות מוכנות לפי דמיון.
הצגת הנקודות הקרובות נאספה בשלוש קריאות רשת, וחוסר סנכרון של עותק הקואורדינטות יצר באופן קבוע כפילויות ברדיוס החיפוש והחמצות בגבולות האזורים.
אשכול PostgreSQL עם PostGIS מותקן נשא את העומס העיקרי, אך ההרחבות בו הופעלו באופן פורמלי: אינדקסים מרחביים לא נבנו, והדמיון חושב במעבר על כל השורות. כל הרחבת רדיוס חיפוש נתקלה במעבר מלא על הטבלה.
מה שינו
שתי המשימות הועברו לתוך האשכול: חיפוש גיאוגרפי — לאינדקס מרחבי עם כיוונון דיוק גאומטריה, ובחירה וקטורית — לאינדקס לפי וקטורים עם התאמת מימד למודל אחד. דמיון טקסטים הועבר לחיפוש טריגרמות, והחישובים המחזוריים — למתזמן המשימות בתוך מסד הנתונים.
מדדים לפני ואחרי
זמן התגובה של שאילתת הבחירה הצטמצם פי שלושה על אותה חומרה, שאילתות כבדות הפסיקו לחסום כתיבה. נפח האינדקסים גדל בכשליש בערך, אך נעלמו עותק הקואורדינטות הנפרד והפקות הביניים, לכן המקום לנתונים בסך הכל הצטמצם.
מספר השירותים החיצוניים במסלול החיפוש ירד משלושה לאפס — יחד איתם נעלם סוג שלם של כשלים: אי-זמינות של שירות חיצוני, חוסר סנכרון עותקים וכפילויות בהצגה.
מה לעשות אם המודול הנדרש אינו בהפצה הסטנדרטית?
מאגר החבילות הסטנדרטי מכסה את רוב המשימות, אך עבור מודולים מסוימים — למשל, לעבודה עם נתונים גיאוגרפיים או חיפוש לפי התאמה מקורבת — ייתכן שהחבילה הנדרשת פשוט לא תימצא בו. אז נותרו שלושה נתיבים: להחליף הפצה, לבנות את המודול ידנית או להוציא את הפונקציה לשירות נפרד. הבחירה נקבעת לא לפי נוחות ההתקנה, אלא לפי מי וכיצד יתחזק זאת בעוד שנה.
מעבר לבנייה שהמודול כבר נכלל בה — האפשרות הצפויה ביותר. החבילה מתעדכנת יחד עם הליבה של PostgreSQL, התמיכה בהפצה מתנהלת לפי מחזור סטנדרטי, ונתיב העדכון של גרסאות משנה ברור מראש.
המחיר — העברת נתונים ובדיקת תאימות עם ההגדרות, ההרשאות והשכפול הקיימים; שינויים כאלה אנו מריצים תחילה בסביבת בדיקה שמשחזרת את תצורת הייצור.
בנייה ידנית של המודול מקוד מקור נראית כניצחון מהיר, אך מעבירה אליכם את כל התמיכה. כל מהדורה של הליבה דורשת בנייה מחדש, ועדכון מערכת מתוכנן עלול לשבור מודול שכבר עובד. הסיכון העיקרי כאן אינו כשל בהתקנה, אלא פער גרסאות בין סביבת הבדיקה לייצור, שצף ברגע הכי לא מתאים.
אם המודול נדרש בגלל פונקציה אחת, סביר יותר להוציא אותה לשירות נפרד לצד מסד הנתונים. המאגר הראשי נשאר בתמיכה סטנדרטית, וההרחבה חיה במסלול משלה עם מחזור עדכון משלה ובדיקות משלה. התשלום — קריאת רשת במקום קריאה מקומית, ניטור וגיבוי נפרדים, ובנוסף שאלת עקביות הנתונים בין שני המסלולים.
אנו מתחילים בשאלה 'מה בדיוק מסד הנתונים צריך לדעת לעשות' ולפיה בוחרים את דרך החיבור. תארו את המשימה — נחזור עם הערכה ותוכנית.
ספקות טכניים: תאימות, גיבויים, נסיגה
אספנו שאלות שצפות לרוב בשלב הקבלה. הן לא עוסקות בשאלה אם ההרחבה עובדת כעת, אלא בהתנהגות האשכול בעת עדכון, שחזור והפרדת הרשאות.
האם ההרחבה תואמת לענף האשכול שלנו?
בודקים זאת לפני ההתקנה: החבילה חייבת להיות בנויה עבור הענף הראשי הנוכחי של השרת — pgvector ו-pg_cron מקושרים למבנים הפנימיים שלו. עדכוני משנה לא פוגעים בתאימות, מעבר לענף ראשי חדש דורש בנייה מחדש ו-CREATE EXTENSION חוזר.
מה ייכנס לגיבוי ומה לא?
הפקה לוגית מעבירה טבלאות והוראות CREATE EXTENSION, אך לא את הבינארים — באשכול היעד ההרחבות חייבות להיות מותקנות מראש. גיבוי מלא מכיל הכל. את השחזור בודקים בסביבת בדיקה נפרדת, אחרת הגיבוי נשאר לא מאומת.
כיצד לבצע נסיגה אם לאחר העדכון משהו השתבש?
שדרוג גרסה בפקודת UPDATE עובד, הורדת גרסה — לא. הסדר הוא כזה: עוצרים כתיבה, מצלמים תמונת מצב, מחזירים את החבילה הקודמת ומשחזרים את טבלאות ההרחבה מהגיבוי. אנו מתקינים הרחבות בסכמות נפרדות, לכן הנסיגה לא פוגעת בנתוני היישום.
כיצד לוודא שאחרי העדכון הכל עובד?
משווים את גרסת PostGIS, מחשבים דמיון של זוגות ייחוס ב-pg_trgm, משווים סכומי ביקורת של וקטורים, בודקים קיום משימות ב-cron.job. בנפרד בוחנים תוכניות שאילתות: לאחר בנייה מחדש יש להשתמש באינדקסים, ולא להחליפם בקריאה סדרתית.
אילו הרשאות נדרשות להתקנה ולעבודה של הרחבות?
CREATE EXTENSION דורש הרשאות סופר-משתמש; באשכולות עם גישה מוגבלת, מנהל הפלטפורמה מעניק אותן. משימות pg_cron מבוצעות מבעל המשימה, והוא זקוק להרשאות על הסכמות המעורבות. עבור pg_trgm ו-pgvector די בהרשאות על הסכמה.
נדון במשימה: מה נדרש להערכה ותוכנית
דיון במשימה מתחילים מרשימת דרישות: אילו הרחבות נדרשות ואיזו משימה כל אחת מכסה — גאומטריה ואינדקסים מרחביים, חיפוש מקורב לפי שמות, השוואה וקטורית, משימות מתוזמנות בתוך מסד הנתונים עצמו. מזה תלוי אילו רכיבים יהיה צורך לבנות בנפרד, ואילו מותקנים כסטנדרט דרך מנהל החבילות.
כדי לחזור עם הערכה ותוכנית עבודה, ולא עם שאלות, יש צורך בנתוני מקור ובגישות לביקורת:
- הענף הנוכחי של PostgreSQL, אופן ניהול המופע (שירות מנוהל או שרתים משלנו) והאם קיימות הרשאות סופר-משתמש;
- גישות לביקורת: קריאה בלבד למופע, ליומנים, לקבצי קונפיגורציה ולמאגר עם קוד תשתית;
- רשימת הרחבות עם התנהגות צפויה ודוגמאות לשאילתות שצריכות לעבוד לאחר ההגדרה;
- נפחי נתונים ואופי העומס: כתיבה, קריאה, אנליטיקה, משימות אצווה מתוזמנות;
- נוהל שינויים: חלון עבודה, מי מאשר, זמן אי-זמינות מותר של השירות;
- דרישות לגיבוי ותסריט נסיגה מאומת למצב הקודם;
- פורמט דיווח רצוי: קונפיגורציות כקוד, סכמת מיגרציה, יומן בדיקות, דוח מסכם לפי תוצאות.
לפי נתונים אלה אנו בונים תוכנית עבודה: מה מיישמים, באיזה סדר, היכן אפשריות נעילות וכיצד נבדוק את התוצאה על עותק. תוכנית המעבר במסלול הייצור מתאמתים לפני תחילת השינויים — עם נקודות חזרה ואחראי על ההרצה.