MicrocosmWorksחדשנות ותכנון קוסמוס דיגיטלי
אודותצור קשר
MicrocosmWorksמחדשים ומתכננים קוסמוס דיגיטלי

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

[email protected]
+91 7011868196
New Delhi, India

מרכז צמיחה AI

מרכז AIחדשנות סטארטאפמאיץ ארגוני

פתרונות

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

משאבים

תובנותמדריכי תעשייהתוכניות מקרה שימושתבניות ארכיטקטורהמחקרי מקרה

חברה

אודותינוצור קשרהעבודה שלנו

שירותים

ייעוץ דיגיטליתשתית ענןפיתוח SaaSפיתוח AIטכנולוגיית וידאו
פיתוח ERPהתאמה אישית של Zohoפיתוח Odooאינטגרציה של Salesforceפיתוח CRM מותאם אישית
אינטגרציה של QuickBooksפתרונות IoTפיתוח בלוקצ'יין
ייעוץ סייברתמיכה טכנית - L3

© 2026 MicrocosmWorks. כל הזכויות שמורות.

מדיניות פרטיותתנאי שירות
חזרה לתבניות ארכיטקטורה
AI / DataEnterprise

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

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

June 22, 2026
|
2 topics covered
דיון בארכיטקטורה זו
scalable-vector-database-architecture.webp
AI / Data
Category
Enterprise
Complexity
AI/ML, E-Commerce
Industries
2+
Technologies

מתי זה נדרש לך

מערכת ה-RAG pipeline או מערכת ההמלצות שלך עובדת מצוין בפיתוח עם כמה אלפי וקטורים. עכשיו יש לך 50 מיליון הטמעות, שאילתות דורשות latency של פחות מ-100ms, האינדקס ממשיך לגדול, ואתה שורף זיכרון. אתה זקוק לארכיטקטורה של בסיס נתונים וקטורי שמדרג אופקית, מנהל זיכרון ביעילות (לא הכל צריך לחיות ב-RAM), מטפל בכתיבות מקבילות במהלך קליטת נתונים מבלי לפגוע בביצועי השאילתות, ולא עולה 10K דולר לחודש בתשתית עבור מה שבעצם הוא אינדקס חיפוש.

Related Architecture Patterns

Explore more design patterns and system architectures

ai-ml-pipeline-architecture.webp
AI / Data

ארכיטקטורת Pipeline של AI/ML

מודלים לא מריצים את עצמם. ה-Pipeline שמכשיר, מאמת, פורס ומנטר את המודלים שלך הוא המוצר האמיתי – המודל הוא רק תוצר אחד.

EnterpriseView
rag-pipeline-architecture.webp

האם אתה זקוק לעזרה בהטמעת ארכיטקטורה זו?

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

צרו קשר

סקירת התבנית

ארכיטקטורה של בסיס נתונים וקטורי מדרגי מתמודדת עם האתגרים של הפעלת חיפוש וקטורי בקנה מידה של ייצור: חלוקת אינדקסים על פני צמתים (sharding), אחסון מדורג (קטעים חמים בזיכרון, חמים יותר ב-SSD, קרים ב-S3), ניתוב שאילתות עם איזון עומסים, ו-autoscaling המבוסס על עומס שאילתות וגודל האינדקס. התבנית מכסה טופולוגיית פריסה, תכנון קיבולת, הפרדת כתיבה/קריאה, ואופטימיזציית עלויות. זוהי שכבת התשתית שהופכת מערכות RAG ומערכות המלצות לנותנות מענה בקנה מידה גדול.

ארכיטקטורת ייחוס

הארכיטקטורה פורסת צמתי בסיס נתונים וקטוריים בטופולוגיה אשכולית עם הפרדה בין צמתי שאילתות (נתיב קריאה) לבין צמתי נתונים (נתיב כתיבה). pipeline של קליטת נתונים מטפל ביצירת הטמעות ובעדכוני אצווה (batch upserts) עם חציצה לכתיבה כדי למנוע השפעה על latency של שאילתות. נתב שאילתות מפיץ חיפושים על פני העתקי קריאה עם מקביליות ברמת ה-shard. אחסון מדורג מעביר קטעים שפחות נגשים אליהם מזיכרון ל-SSD ל-S3, עם טעינה שקופה בזמן שאילתה. Autoscaling מתאים את מספר העותקים בהתבסס על QPS של שאילתות ו-P99 latency.

רכיבי ליבה
  • ניהול אשכול: Milvus (ברירת המחדל שלנו לקנה מידה) עם etcd לתיאום מטא-נתונים, MinIO/S3 לאחסון קטעים, ו-Pulsar/Kafka לרישום לפני כתיבה (write-ahead logging). לחלופין, שירותים מנוהלים (Pinecone, Zilliz Cloud) כאשר פשטות תפעולית עולה על שיקולי עלות
  • אסטרטגיית Shard ו-Partition: partitions לוגיים מיושרים לגבולות נתונים (לפי דייר, לפי אוסף מסמכים, לפי חלון זמן). כל partition ניתן לחיפוש באופן עצמאי, ומאפשר שאילתות מסוננות ללא סריקת האינדקס המלא. Shards מפוזרים על פני צמתים לביצוע שאילתות מקבילי
  • מנוע אחסון מדורג: שכבה חמה (אינדקס HNSW/IVF בזיכרון) עבור אוספים שנשאלו לעיתים קרובות. שכבה חמה (SSD ממופה זיכרון) עבור אוספים גדולים עם עומס שאילתות מתון. שכבה קרה (מגובה ב-S3) עבור אוספי ארכיון שניתנים לחיפוש אך סובלים latency גבוה יותר. קידום/הורדת דרגות ברמת הקטע בהתבסס על דפוסי גישה
  • בקר Autoscaling: Horizontal pod autoscaler (HPA) ב-Kubernetes המרחיב צמתי שאילתות בהתבסס על מדדי QPS ו-P99 latency. הרחבה למעלה (scale-up) בהפרת latency, והרחבה למטה (scale-down) בשימוש נמוך מתמשך. הרחבה נפרדת עבור עובדי קליטת נתונים (ingestion workers) לטיפול בהעלאות פתאומיות מבלי להשפיע על ביצועי שאילתות

החלטות עיצוב ופשרות

Milvus לעומת Pinecone לעומת Qdrant לעומת pgvector
pgvector מתאים עבור פחות מ-1M וקטורים כאשר כבר יש לך PostgreSQL ואתה יכול לסבול latency של כ-200ms. Pinecone לצוותים שרוצים נטל תפעולי אפסי ויכולים לקבל את התמחור (מדרגי היטב אך נעשה יקר מעל 10M וקטורים). Qdrant עבור API נקי עם ביצועים טובים של צומת בודד. Milvus לקנה מידה רציני — זו האפשרות היחידה בקוד פתוח עם ארכיטקטורה מבוזרת אמיתית, אחסון מדורג, ו-sharding ברמת ייצור. MW מגדירה ברירת מחדל ל-Milvus עבור >5M וקטורים ול-Pinecone עבור צוותים שמעדיפים פשטות מנוהלת.
HNSW לעומת IVF_FLAT לעומת IVF_PQ
HNSW (Hierarchical Navigable Small World) מספק את ה-recall הטוב ביותר ב-latency נמוך אך משתמש בזיכרון הרב ביותר (וקטורים מלאים ב-RAM). IVF_FLAT מקבץ וקטורים ומחפש רק באשכולות רלוונטיים — איזון טוב בין מהירות וזיכרון. IVF_PQ (Product Quantization) דוחס וקטורים לחיסכון עצום בזיכרון אך מפחית את ה-recall ב-3-8%. MW משתמש ב-HNSW עבור אוספים מתחת ל-10M וקטורים ועובר ל-IVF_PQ עם שיפור PQ (ניקוד מחדש של המועמדים המובילים מול וקטורים מלאים) עבור אוספים גדולים יותר שבהם עלות הזיכרון חשובה.
בידוד כתיבה
כתיבות מקבילות במהלך קליטת נתונים פוגעות ב-latency של שאילתות ברוב בסיסי הנתונים הווקטוריים. MW מפרידה את נתיב הכתיבה: וקטורים חדשים נאגרים ב-write-ahead log, נשטפים מעת לעת לקטעים סגורים, ומוזגים לאינדקס הניתן לחיפוש במהלך חלונות תנועה נמוכה. עבור מערכות הדורשות קליטה בזמן אמת (לדוגמה, עיבוד מסמכים חי), אנו פורסים מאגרי צמתים נפרדים לקליטה ולשאילתות עם הקצאות משאבים שונות.
אופטימיזציית עלויות
בסיסי נתונים וקטוריים צורכים זיכרון רב. אוסף של 100M וקטורים עם הטמעות בעלות 1536 ממדים דורש כ-600GB של RAM במצב HNSW. MW מבצעת אופטימיזציית עלויות באמצעות: (א) הפחתת ממדים היכן שניתן (Matryoshka embeddings, PCA), (ב) קוונטיזציה (scalar או product quantization), (ג) אחסון מדורג כדי לדחוף קטעים קרים מחוץ ל-RAM, ו-(ד) התאמת גודל ממדי ההטמעות — 768 ממדים לעיתים קרובות מספיקים כאשר 1536 הוא מוגזם.

בחירות טכנולוגיות

שכבהטכנולוגיות
בסיס נתונים וקטורי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% בהשוואה להקצאה סטטית.

תוכניות קשורות

  • סוכן תמיכת לקוחות AI — חיפוש וקטורי המניע שליפת ידע לתגובות תמיכה
  • pipeline לעיבוד מסמכים מבוסס AI — הטמעה ואינדוקס תוכן מסמכים שחולץ
  • פלטפורמת למידה מותאמת אישית מונעת AI — דמיון וקטורי להמלצות תוכן

מקרי בוחן קשורים

  • Milvus Autoscaling — אשכול Milvus ייצורי עם Kubernetes HPA ואחסון מדורג מגובה ב-S3
  • בינת מסמכים — חיפוש וקטורי לאחזור וניתוח מסמכים מקומיים
Related Technologies
פיתוח AIפתרונות ענן
AI / Data

ארכיטקטורת RAG Pipeline

הענק ל-LLM שלך גישה לנתונים שלך ללא צורך ב-fine-tuning. RAG מגשר על הפער בין מודלי שפה כלליים לידע ספציפי לתחום.

AdvancedView
cloud-native-infrastructure.webp
Infrastructure

תשתית Cloud-Native

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

EnterpriseView

שאלות נפוצות

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 נפרדים לכל יישום.