חיפוש הטמעות קל עבור 10K וקטורים. עבור 100M וקטורים עם P99 הנמוך מ-100ms, זו בעיית תשתית — וזו הבעיה שהתבנית הזו פותרת.

מערכת ה-RAG pipeline או מערכת ההמלצות שלך עובדת מצוין בפיתוח עם כמה אלפי וקטורים. עכשיו יש לך 50 מיליון הטמעות, שאילתות דורשות latency של פחות מ-100ms, האינדקס ממשיך לגדול, ואתה שורף זיכרון. אתה זקוק לארכיטקטורה של בסיס נתונים וקטורי שמדרג אופקית, מנהל זיכרון ביעילות (לא הכל צריך לחיות ב-RAM), מטפל בכתיבות מקבילות במהלך קליטת נתונים מבלי לפגוע בביצועי השאילתות, ולא עולה 10K דולר לחודש בתשתית עבור מה שבעצם הוא אינדקס חיפוש.
Explore more design patterns and system architectures
אדריכלים שלנו יכולים לעזור לך לעצב ולבנות מערכות תוך שימוש בדפוס זה לדרישות הספציפיות שלך.
צרו קשרארכיטקטורה של בסיס נתונים וקטורי מדרגי מתמודדת עם האתגרים של הפעלת חיפוש וקטורי בקנה מידה של ייצור: חלוקת אינדקסים על פני צמתים (sharding), אחסון מדורג (קטעים חמים בזיכרון, חמים יותר ב-SSD, קרים ב-S3), ניתוב שאילתות עם איזון עומסים, ו-autoscaling המבוסס על עומס שאילתות וגודל האינדקס. התבנית מכסה טופולוגיית פריסה, תכנון קיבולת, הפרדת כתיבה/קריאה, ואופטימיזציית עלויות. זוהי שכבת התשתית שהופכת מערכות RAG ומערכות המלצות לנותנות מענה בקנה מידה גדול.
הארכיטקטורה פורסת צמתי בסיס נתונים וקטוריים בטופולוגיה אשכולית עם הפרדה בין צמתי שאילתות (נתיב קריאה) לבין צמתי נתונים (נתיב כתיבה). pipeline של קליטת נתונים מטפל ביצירת הטמעות ובעדכוני אצווה (batch upserts) עם חציצה לכתיבה כדי למנוע השפעה על latency של שאילתות. נתב שאילתות מפיץ חיפושים על פני העתקי קריאה עם מקביליות ברמת ה-shard. אחסון מדורג מעביר קטעים שפחות נגשים אליהם מזיכרון ל-SSD ל-S3, עם טעינה שקופה בזמן שאילתה. Autoscaling מתאים את מספר העותקים בהתבסס על QPS של שאילתות ו-P99 latency.
| שכבה | טכנולוגיות |
|---|---|
| בסיס נתונים וקטורי | Milvus (מבוזר), Qdrant (צומת יחיד/אשכול קטן), Pinecone (מנוהל) |
| אחסון בקאנד | MinIO / S3 (אחסון קטעים), SSD (שכבה חמה יותר), RAM (שכבה חמה) |
| תיאום | etcd (מטא-נתונים של Milvus), Pulsar/Kafka (write-ahead log) |
| מודלי הטמעה | OpenAI text-embedding-3-large, Cohere embed-v4, BGE-M3, E5-large-v2 |
| תשתית | Kubernetes (EKS/GKE) עם צמתי GPU להטמעה, צמתי זיכרון ממוטבים לשאילתות |
| ניטור | Grafana + Milvus metrics exporter, לוחות מחוונים מותאמים אישית ל-P99/recall |
| השתמש כאשר | הימנע כאשר |
|---|---|
| מספר הווקטורים עולה על 5M וגדל, ודורש מדרגיות אופקית | יש לך פחות מ-1M וקטורים — pgvector על PostgreSQL הקיים שלך מספיק |
| P99 query latency של פחות מ-100ms הוא דרישה קשיחה | latency של שאילתה של 500ms+ מקובל — אפשרויות פשוטות יותר יעבדו |
| יישומים/דיירים מרובים חולקים את תשתית הווקטורים | יישום יחיד עם אוסף יחיד — השתמש בשירות מנוהל |
| אופטימיזציית עלויות דורשת אחסון מדורג (לא הכל ב-RAM) | התקציב מאפשר שירותים מנוהלים במלואם והתמחור של הספק מתאים לקנה המידה שלך |
MW מתכננת תשתית בסיס נתונים וקטורי בגישת "גודל נכון מהיום הראשון, מדרגי כשנמדד". אנו מתחילים בתכנון קיבולת המבוסס על ספירת וקטורים, ממדיות, סוג אינדקס, ו-latency יעד — לא ניחושים. פריסות Milvus שלנו על Kubernetes כוללות לוחות מחוונים של Grafana העוקבים אחר ספירת קטעים, ניצול זיכרון, אחוזי latency של שאילתות, ואומדני recall. יישמנו אשכולות Milvus עם autoscaling המטפלים בעליות תנועה של פי 10 בשעות העבודה ומצטמצמים במהלך הלילה, מה שמפחית את עלויות התשתית ב-40-60% בהשוואה להקצאה סטטית.
הענק ל-LLM שלך גישה לנתונים שלך ללא צורך ב-fine-tuning. RAG מגשר על הפער בין מודלי שפה כלליים לידע ספציפי לתחום.
MicrocosmWorks ממליצה בדרך כלל על pgvector לפרויקטים עם פחות מ-5-10 מיליון וקטורים שבהם הצוות כבר משתמש ב-PostgreSQL, מכיוון שהדבר מונע הכנסת רכיב תשתית חדש ותומך בשאילתות היברידיות של SQL-plus-vector באופן מובנה. מעבר ל-10 מיליון וקטורים או כאשר נדרש זמן אחזור (latency) של פחות מ-50 מילישניות (p99) בעומס גבוה (high concurrency), מסד נתונים וקטורי ייעודי כמו Qdrant, Weaviate או Milvus מספק ביצועים טובים משמעותית באמצעות אלגוריתמי אינדוקס ממוטבים וחיפוש מואץ על ידי GPU. אנו עוזרים ללקוחות לקבל החלטה זו במהלך סקירת ארכיטקטורה (architecture review) על ידי ביצוע בדיקות ביצועים (benchmarking) של דפוסי השאילתות בפועל ותחזיות הצמיחה שלהם.
MicrocosmWorks מתכננת אשכולות מאגרי וקטורים עם אסטרטגיות שארדינג מבוססות גיבוב או מבוססות מטא-דאטה, המפזרות וקטורים על פני צמתים תוך שמירה על נתונים קשורים סמנטית ממוקמים יחד לצורך חיפוש יעיל. אנו מיישמים שכבות ניתוב שאילתות המפזרות בקשות חיפוש לשארדים רלוונטיים ומאחדות תוצאות באמצעות אגרגציית top-K גלובלית, שומרות על שיהוי של פחות מ-100 מילישניות אפילו על פני עשרות שארדים. לוחות המחוונים שלנו לניטור עוקבים אחר איזון שארדים, פיזור שאילתות ופיגור שכפול כדי למנוע נקודות חמות ככל שקבוצת הנתונים שלכם גדלה.
MicrocosmWorks מיישמת קוונטיזציה סקלרית (המפחיתה float32 ל- int8) וקוונטיזציית מכפלה כדי לדחוס את אחסון הווקטורים פי 4-8, עם פחות מ-2% פגיעה ב-recall בדרך כלל, שאנו מאמתים באמצעות בדיקות A/B על עומס העבודה בפועל של השאילתות שלכם לפני פריסה לייצור. אנו מיישמים גם גישת אחזור דו-שלבית שבה וקטורים מקוונטטים משמשים לאחזור מועמדים ראשוני, וווקטורים בדיוק מלא משמשים רק לדירוג מחדש סופי של התוצאות המובילות. אסטרטגיה היברידית זו מאפשרת ללקוחות לאחסן מאות מיליוני וקטורים בשבריר מהעלות תוך שמירה על איכות חיפוש שאינה ניתנת להבחנה מפעולה לא דחוסה.
MicrocosmWorks פורסת מסדי נתונים וקטוריים בתצורות מרובות רפליקות עם שכפול סינכרוני לעמידות כתיבה ורפליקות קריאה המפוזרות על פני אזורי זמינות לסבילות לתקלות ואיזון עומסים. אנו מגדירים automated failover עם בחירת לידר המונעת על ידי בדיקות תקינות כך שכשל בצומת יגרום לפחות מ-10 שניות של חוסר זמינות לקריאה ואפס אובדן נתונים. תבניות ה-infrastructure-as-code שלנו כוללות לוחות זמנים מוגדרים מראש לגיבויים, point-in-time recovery, ו-disaster recovery runbooks המותאמים אישית לכל מנוע מסד נתונים וקטורי.
MicrocosmWorks מתכננת פריסות של מסדי נתונים וקטוריים מרובי collection שבהן כל יישום או embedding model מקבל collection מבודדת משלו עם index configurations מתאימות, תוך שיתוף תשתית ה-cluster הבסיסית ליעילות עלויות. אנו מיישמים unified query gateway שמנתב בקשות ל-collection הנכונה בהתבסס על הקשר היישום, ומיישם pre-processing ספציפי ל-collection, כגון query embedding עם המודל התואם. גישה זו של multi-tenant vector database מפחיתה בדרך כלל את עלויות התשתית ב-40-60% בהשוואה להפעלת clusters נפרדים לכל יישום.