קנה מידה עבור עומסי עבודה בנפח גבוה
ככל שעומסי העבודה הווקטוריים גדלים מעבר למה ששרת מסד נתונים יחיד יכול להתמודד איתו ביעילות, יש צורך באסטרטגיות להגדלת קיבולת תוך ניהול עלויות. Azure Database for PostgreSQL מספק מספר אפשרויות סקיילינג שמטפלות בהיבטים שונים של אתגר הביצועים.
קנה מידה אנכי ב-Azure
קנה מידה אנכי מגדיל את משאבי המחשוב והזיכרון הזמינים לשרת מסד הנתונים שלך. בעומסי עבודה וקטוריים, זה מתייחס ישירות לאופי הכבד של חישובי הדמיון ולדרישות הזיכרון לשמירת אינדקסים במטמון.
Azure Database for PostgreSQL מציע שלוש שכבות חישוב עם הקצאות משאבים שונות. כל שכבה מתמקדת בפרופילי עומס עבודה שונים, ומאזנת בין עלות ליכולות ביצועים. בעומסי עבודה בחיפוש וקטורי, יחס הזיכרון ל-vCore חשוב כי הוא קובע כמה נתוני אינדקס יכולים להישאר בזיכרון.
| הרמה | vCores | זיכרון לפי vCore | הכי טוב עבור |
|---|---|---|---|
| ניתן לפרץ | 1-20 | 2 ג'יגה בייט | פיתוח, עומסי עבודה עם תנועה נמוכה |
| מטרה כללית | 2-96 | 4 GB | עומסי עבודה מאוזנים בייצור |
| אופטימיזציה לזיכרון | 2-96 | 8 GB | ערכות עבודה גדולות, עומסי עבודה וקטוריים |
לתרחיש המלצת מוצר עם שני מיליון וקטורים וקונקורציה גבוהה, שכבות Memory Optimized מספקות את ההתאמה הטובה ביותר. הזיכרון הנוסף לכל vCore מסייע לשמור על אינדקסים של HNSW במטמון, ומפחית את הקלט/פלט של הדיסק במהלך שאילתות.
ביצועי שאילתת וקטור משתנים הן עם ליבות המעבד (לחישובי מרחקים מקבילים) והן עם זיכרון (למטמון אינדקס). למערכי נתונים מתחת למיליון וקטורים, התחילו עם 4-8 vCores כלליים, עקוב אחרי לחץ הזיכרון ויחסי פגיעות במטמון, והגדיל אם השימוש במעבד עולה בעקביות על 70% בעומס שיא. עבור מערכי נתונים של אחד עד עשרה מיליון וקטורים, התחל עם 8-16 vCores מותאם לזיכרון, ודא שהזיכרון עולה על גודל אינדקס הווקטורים לפחות ב-50%, ושקול 32+ vCores למקבילות גבוהה (מאות שאילתות מקבילות). עבור מערכי נתונים מעל עשרה מיליון וקטורים, בדרך כלל נדרש 32+ vCores מותאם לזיכרון. העריך האם רפליקות קריאה יכולות להפיץ עומס, ושקול שינויים אדריכליים (חלוקה, שכבת מטמון).
לסקיילינג אנכי יש תשואות פוחתות ומגבלות קשות. הגדל (שרת גדול יותר) כאשר השהיה בשאילה בודדת גבוהה מדי, לחץ זיכרון גורם לקלט/פלט מופרז בדיסק, או כאשר לא הגעת למשאבים המקסימליים של הרמה. תצטרף (replicas או cacheing) כאשר נפח השאילתות הכולל עולה על מה ששרת אחד יכול להתמודד איתו, יש לך עומס קריאה כבד עם עייפות מקובלת, או שאתה מגיע למגבלות קנה מידה אנכי. קנה מידה אנכי פשוט יותר ליישום ולניהול. תתחיל בלהגדיל עד שתגיע למגבלות או שהעלות הופכת לגבוהה, ואז תוסיף סקיילינג אופקי.
קריאת רפליקות להפצת שאילתות
רפליקות קריאה שומרות עותקים של מסד הנתונים הראשי שלך שמטפלים בשאילתות קריאה באופן עצמאי. בעומסי עבודה בחיפוש וקטורי שהם בעיקר קריאות, רפליקות יכולות להכפיל את קיבולת השאילתות שלך.
Azure Database for PostgreSQL משתמש בשכפול סטרימינג פיזי כדי לשמור על סנכרון העתקים עם השרת הראשי. שינויים שנכתבים לראשי מוזרים לרפליקים, שמיישמים אותם באופן אסינכרוני. השרת הראשי מטפל גם בקריאות וגם בכתיבה, בעוד שכל שכפול מטפל רק בשאילתות קריאה. ניתן ליצור עד חמש רפליקות קריאה לכל גרסה ראשונית, והעתקים יכולים להיות ממוקמים באזורים שונים של Azure. לכל העתק יש נקודת קצה חיבור משלו, ולכן האפליקציה שלך חייבת לנתב את השאילתות לשרת המתאים.
מכיוון ששכפול הוא אסינכרוני, הרפליקות עשויות להיות מעט מאחור מהראשי. ההשהיה הזו היא בדרך כלל מילישניות עד שניות בתנאים רגילים, אך יכולה לגדול במהלך פעילות כתיבה כבדה על הראשי, עסקאות גדולות או עומסים מרוכזים, עומס רשת בין אזורים, או מגבלות משאבים משוחזרות. לגבי המלצות מוצרים, עיכוב רפליקה הוא לעיתים קרובות מקובל. אם מתווסף מוצר חדש, הופעתו בהמלצות כמה שניות לאחר מכן לא משפיעה על חוויית המשתמש. עם זאת, אם האפליקציה שלך דורשת עקביות מיידית (כמו הצגת העדפות משתמש שעודכנו זה עתה), השאילתות האלה צריכות לעבור לראשי. מנטרים את השהיית הרפליקה באמצעות מדדי Azure Monitor או שאילתרו את השכפול ישירות עם SELECT EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp())) AS lag_seconds;.
האפליקציה שלך חייבת להפנות שאילתות לשרתים מתאימים. דפוסים נפוצים כוללים ניתוב ברמת האפליקציה (בחירת חיבור לפי סוג השאילתה), ניתוב מבוסס DNS (באמצעות Azure Traffic Manager או DNS מותאם אישית להפצת חיבורים בין רפליקים), ופרוקסי חיבור (PgBouncer או פרוקסי דומים שמנתבים שאילתות לפי דפוסים). בתרחיש מנוע ההמלצה, חיפושי דמיון וקטורי הם מועמדים אידיאליים לניתוב רפליקה כי הם קריאה בלבד והסבילות לעייפות קלה גבוהה.
ניתן לגדל את הרפליקות באופן עצמאי מהראשי. לעומסי עבודה וקטוריים כבדים בקריאה, ייתכן שתשתמש ברפליקות קטנות יותר אם נפח השאילתות הוא המגבלה (יותר שכפולים, קטנים כל אחד), תשתמש ברפליקות שווות או גדולות יותר אם ביצועי השאילתות הבודדות חשובות, או תמקם עותקים באזורים קרובים למשתמשים לזמן השהייה נמוך יותר.
אסטרטגיות מטמון לחיפוש וקטורי
מטמון מפחית עומס מסד נתונים על ידי הגשת שאילתות חוזרות מאחסון מהיר יותר. עומסי עבודה בחיפוש וקטורי כוללים הזדמנויות ספציפיות למטמון.
לא כל תוצאות החיפוש הווקטוריות נהנות באותה מידה ממטמון. המועמדים הטובים ביותר בעלי תדירות בקשות גבוהה, קצבי שינוי נמוכים ומרחבי מפתחות חסומים. שאילתות דמיון אקראיות מול וקטורים שרירותיים כוללות מרחב שאילתות אינסופי ואינן שומרות היטב, אבל חיפושים של פריטים ספציפיים או המלצות מחושבות מראש מטמונים ביעילות. מועמדים טובים למטמון כוללים הטמעות-מוצרים פופולריים המבוקשים לעיתים קרובות, "פריטים דומים" מחושבים מראש למוצרים מובילים, חיפושי הטמעת משתמשים להתאמה אישית, והטמעות מצטברות ברמת הקטגוריה. מועמדי מטמון גרועים כוללים שאילתות דמיון וקטורי שרירותיות (מרחב שאילתות אינסופי), נתונים משתנים במהירות (שיעור אי-אימות גבוה), ושאילתות עם שילובי מסננים רבים.
Azure Cache עבור Redis מספק זמני תגובה של תת-מילישניות עבור נתונים שמורים במטמון. לגבי עומסי עבודה וקטוריים, שקול הטמעת מטמון, חיפושים והמלצות מחושבות מראש. הדוגמה הבאה מדגימה הטמעת מוצר במטמון עם TTL של שעה.
import redis
import json
redis_client = redis.Redis(host='your-cache.redis.cache.windows.net',
port=6380, ssl=True, password='your-key')
def get_product_embedding(product_id):
cache_key = f"embedding:{product_id}"
cached = redis_client.get(cache_key)
if cached:
return json.loads(cached)
# Fetch from database
embedding = fetch_embedding_from_db(product_id)
# Cache for 1 hour
redis_client.setex(cache_key, 3600, json.dumps(embedding))
return embedding
המלצות מיושנות בדרך כלל מקובלות לפרקי זמן קצרים, אבל בסופו של דבר המטמונים צריכים רענון. אסטרטגיית הביטול הנכונה תלויה במהירות שבה הנתונים שלך משתנים וכמה המשתמשים רגישים לתוצאות מיושנות. רוב יישומי החיפוש הווקטורי יכולים לסבול דקות של עייפון, מה שהופך תפוגה פשוטה מבוססת זמן ליעילה. הגדר TTL (זמן לחיות) לפי עייפות מקובלת. להמלצות מוצרים, 15-60 דקות זה לרוב סביר. לצורך אי-אימות מונחה אירועים, נקה רשומות מטמון ספציפיות כאשר הנתונים הבסיסיים משתנים. לרענון רקע, רענן באופן יזום פריטים פופולריים לפני תוקפם כדי למנוע פספוסים במטמון.
מעקב אחרי הקיבולת ותכנון לצמיחה
ניטור פרואקטיבי עוזר לך להתרחב לפני שהביצועים יורדים בצורה ניכרת.
עקבו אחרי מדדים ברמת מסד הנתונים דרך Azure Monitor כולל אחוז מעבד (70% מתמשכים >מציין צורך בקנה מידה), אחוז זיכרון (התקרבות למגבלות גורמת להחלפה), אחוז קלט של אחסון (ערכים גבוהים מצביעים על חוסר מטמון מספק), וחיבורים פעילים (גישה max_connections מצביעה על בעיות איחוד). כמו כן, עוקבים אחרי מדדים ברמת השאילתה, כולל השהיית שאילתות P95/P99 לחיפושי וקטור, קצב העברת שאילתות (שאילתות לשנייה), ויחס פגיעות במטמון (אם משתמשים במטמון המטמון של PostgreSQL בצורה יעילה).
הגדר התראות Azure Monitor כדי להודיע לך לפני שהבעיות משפיעות על המשתמשים. הגדר התרעת אזהרה כאשר אחוז המעבד עולה על 80% למשך 5 דקות כדי לשלוח מייל לצוות התפעול. הגדר התראה קריטית כאשר אחוז הזיכרון עולה על 90% למשך 5 דקות כדי לקרוא למהנדס התורן.
תכנון קיבולת יעיל דורש הבנה של דפוסי השימוש הנוכחיים שלך וחיזוי הצרכים העתידיים. בלי הבסיס הזה, אתה מסתכן או בהקצאת יתר (בזבוז תקציב) או בחסר (פגיעה בחוויית המשתמש במהלך הצמיחה). קבע קווי בסיס על ידי מדידת נפח השאילתות הנוכחי, השהיה וניצול המשאבים בתקופות רגילות ושיא. זהה מנועי צמיחה כמו גידול גודל הקטלוג, גידול משתמשים או שינויים במורכבות השאילתות. מודל עומס עתידי על ידי תחזית צרכי המשאבים על בסיס קצב הצמיחה. אם הקטלוג שלך מוכפל מדי שנה ואתה מגיע ל-60% מעבד, תכנן להרחיב תוך שישה חודשים. בדוק אפשרויות סקיילינג לפני שתצטרך אותן על ידי אימות קנה מידה אנכי ופריסת רפליקה בסביבות שאינן ייצור. תעד ספים שמגדירים מתי כל פעולת הגדלה צריכה לפעול.
אופטימיזציה של עלויות
אופטימיזציה של ביצועים חייבת לאזן מול מגבלות תקציב. מספר אסטרטגיות מסייעות לשלוט בעלויות תוך שמירה על ביצועים מקובלים.
הקצאת יתר מבזבזת כסף בעוד שחוסר הספקנות פוגע במשתמשים. בדוק את השימוש במשאבים באופן קבוע. אם הממוצע של המעבד מתחת ל-30%, שקול להקטין. אם השימוש בזיכרון נמוך באופן עקבי, ייתכן ש-General Purpose יספיק במקום Memory Optimized. אם יש לך שכפולים עם שימוש נמוך, תאחד.
Azure מציעה הנחות משמעותיות (עד 65%) עבור התחייבויות קיבולת שמורה לשנה אחת או שלוש שנים. אם עומס העבודה הבסיסי שלך צפוי, הזמנות מפחיתות משמעותית את העלויות. חשב את קו הבסיס שלך (הקיבולת המינימלית שתמיד פועלת) ושמור את הסכום הזה. השתמש בתמחור לפי דרישה לקיבולת פיצוץ מעל קו הבסיס.
עלויות האחסון מצטברות עבור מערכי נתונים וקטוריים גדולים. הסר אינדקסים שלא נוצלו (כל אינדקס HNSW מוסיף ~50% לאחסון וקטורי). ארכוב וקטורים ישנים שלעיתים רחוקות שואלים אותם. השתמש בדיוק המתאים (float4 מול float8) לצרכי הדיוק שלך.
סביבות שאינן ייצור אינן זקוקות למשאבים בקנה מידה ייצור. השתמש ב-Burstable tier לפיתוח. להקטין את השלב כשלא בבדיקות אקטיביות. השתמש במאגרי נתונים קטנים יותר בלא ייצור (דגימות מייצגות, לא עותקים מלאים).