הערכת מודול

1.

אתה מכוון את PostgreSQL לעומס עבודה של חיפוש וקטורי עם 2 מיליון הטמעות 1536 ממדים. השאילתות איטיות ואתה רואה יחס פגיעות במטמון של 85%. איזו שינוי תצורה כדאי לשים בראש סדר העדיפויות?

הגדל shared_buffers כדי לשמור יותר נתונים במטמון PostgreSQL

הקטנה random_page_cost כדי לעודד יותר סריקות אינדקס

הגדל ivfflat.probes לחיפוש יותר מחיצות אינדקס

2.

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

IVFFlat עם רשימות מוגדרות ל-sqrt(שורות)

HNSW עם m=16 ו-ef_construction=64

HNSW עם m=8 ו-ef_construction=32

3.

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

אמת שקיים אינדקס עץ B על העמודה category_id

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

הגדל hnsw.ef_search להרחבת מרחב החיפוש

4.

אתה מיישם ניהול חיבור ליישום AI שמבצע 500 שאילתות וקטוריות בשנייה בשיא התעבורה. מופע Azure Database שלך ל-PostgreSQL תומך ב-1,719 חיבורים מקסימום. באיזו גישה עליך להשתמש?

הפעל PgBouncer במצב עסקה עם גודל מאגר מתאים למופעי האפליקציה שלך

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

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

5.

אתה מגדיל מנוע המלצות שרץ כרגע על מופע vCore של General Purpose 8. ניצול המעבד ממוצע 75% והשהיית השאילתות ב-P95 היא 150 מילישניות, אבל צריך להגיע להשהיה מתחת ל-50ms. איזו גישת סקיילינג כדאי לנסות קודם?

שדרוג לדרגת Memory Optimized עם יותר vCores

הוסף שכפולים לקריאה כדי לפזר את עומס השאילתות

מימוש מטמון ברמת האפליקציה עם Azure Cache for Redis

משוב