פורסם

Qdrant

Qdrant הוא מסד נתונים וקטורי בקוד פתוח שנכתב ב-Rust: הוא שומר embeddings עם payload של JSON ומגיש חיפוש דמיון דרך REST API ו-gRPC, עם Web UI מובנה. הוא מתאים לצוותים שבונים RAG או חיפוש סמנטי ורוצים את מאגר הווקטורים על שרת משלהם; צריכת הזיכרון שלו גדלה עם מספר הווקטורים וגודלם.

משאבים לפי רמת עומס

מה האפליקציה עצמה צריכה בכל רמה, לצד מה שאנחנו ממליצים לשרת שמריץ רק אותה.

רמה	מה זה אומר	דרישות האפליקציה	מומלץ
קלהערכה	עד 100,000 וקטורים של 768 ממדים (float32) עם payload של כ-1 KiB לכל אחד, בלי quantization: אב-טיפוס או מאגר ידע קטן אחד ל-RAG.	0.5 vCPU · 0.5 GiB RAM · 0.8 GiB דיסק	0.72 vCPU · 2.1 GiB RAM · 10.235 GiB דיסק
בינוניהערכה	עד מיליון וקטורים של 768 ממדים (float32) עם payload של כ-1 KiB לכל אחד, בלי quantization: כמה מאגרי ידע או חיפוש סמנטי ב-production.	2 vCPU · 3.75 GiB RAM · 5.6 GiB דיסק	2.52 vCPU · 6 GiB RAM · 15.755 GiB דיסק
כבדהערכה	עד 5 מיליון וקטורים של 768 ממדים (float32) עם payload של כ-1 KiB לכל אחד, בלי quantization, בצומת אחד עם replication factor ‏1.	4 vCPU · 18.5 GiB RAM · 27.1 GiB דיסק	4.92 vCPU · 23.7 GiB RAM · 40.48 GiB דיסק

מומלץ = דרישות האפליקציה + baseline של המערכת + מרווח ביטחון (headroom), לפי מדיניות ה-sizing ‏2026.10.0. האפשרויות נשארות בברירת המחדל. ״הערכה״ פירושה שהמקורות לא נותנים מספר למקרה הזה, ולכן הוא מחושב מהם בשיטה שמפורטת תחת רכיבים. איך המספרים נבנים

לחישוב ב-Stack Sizer

קבצים מוכנים להפעלה

רמת תמיכה נתמך

תבנית Compose מהמקורות הרשמיים; עוד לא נבדקה בהרצה.

צור docker-compose

רכיבים

מה כל רכיב צריך בכל רמת עומס, לפני baseline ו-headroom.

vCPU / GiB RAM / GiB דיסק
רכיב	קל	בינוני	כבד	מקורות
Qdrant (database)	0.5 / 0.5 / 0.8	2 / 3.75 / 5.6	4 / 18.5 / 27.1	[4][10][11][12]

איך ההערכות מחושבות

Qdrant · קל: ‏Capacity planning של Qdrant, צומת יחיד: ‏dense = N × 768 × 4 B; ‏HNSW = N × 16 × 2 × 4 B × 1.2; ‏ID tracker = N × 52 B; ‏payload ‏(cold, ‏1 KiB) = N × 1,024 B × 1.5. ‏RAM = (dense + HNSW + ID) × 1.2, ‏disk = (כל הארבעה) × 1.2 (מרווח 20% של המדריך); ועוד image של 0.189 GiB פרוס. ‏N = 100,000: ‏RAM ‏(0.286 + 0.014 + 0.005) × 1.2 = 0.366 ← 0.5 GiB; ‏disk ‏(0.448) × 1.2 = 0.538 + 0.189 = 0.727 ← 0.8 GiB. ‏vCPU: ‏0.5, הצומת הקטן ביותר ב-Qdrant Cloud.
Qdrant · בינוני: ‏Capacity planning של Qdrant, צומת יחיד: ‏dense = N × 768 × 4 B; ‏HNSW = N × 16 × 2 × 4 B × 1.2; ‏ID tracker = N × 52 B; ‏payload ‏(cold, ‏1 KiB) = N × 1,024 B × 1.5. ‏RAM = (dense + HNSW + ID) × 1.2, ‏disk = (כל הארבעה) × 1.2 (מרווח 20% של המדריך); ועוד image של 0.189 GiB פרוס. ‏N = 1M: ‏RAM ‏(2.861 + 0.143 + 0.048) × 1.2 = 3.663 ← 3.75 GiB; ‏disk ‏(4.483) × 1.2 = 5.380 + 0.189 = 5.569 ← 5.6 GiB. ‏vCPU: היחס של ה-free tier, ‏0.5 vCPU לכל GB של RAM, × כ-4 GB = 2.
Qdrant · כבד: ‏Capacity planning של Qdrant, צומת יחיד: ‏dense = N × 768 × 4 B; ‏HNSW = N × 16 × 2 × 4 B × 1.2; ‏ID tracker = N × 52 B; ‏payload ‏(cold, ‏1 KiB) = N × 1,024 B × 1.5. ‏RAM = (dense + HNSW + ID) × 1.2, ‏disk = (כל הארבעה) × 1.2 (מרווח 20% של המדריך); ועוד image של 0.189 GiB פרוס. ‏N = 5M: ‏RAM ‏(14.305 + 0.715 + 0.242) × 1.2 = 18.315 ← 18.5 GiB; ‏disk ‏(22.415) × 1.2 = 26.898 + 0.189 = 27.087 ← 27.1 GiB. ‏vCPU: ‏4, הקצאה (אין מספר רשמי): ה-threads של החיפוש וה-optimizer מותאמים אוטומטית למספר הליבות.

פורטים

פורטים ציבוריים נועדו לגישה מחוץ ל-stack, בדרך כלל דרך reverse proxy; פורטים פנימיים נשארים ברשת של ה-stack עצמו.

רכיב	פורט	חשיפה	שימוש	מקורות
Qdrant	6333/tcp	ציבורי, דרך proxy	REST API, Web UI (/dashboard) and health/metrics; only with an API key and HTTPS	[1][4][6][14]
Qdrant	6334/tcp	פנימי בלבד	gRPC API for clients on the internal Docker network	[1][2][4]

כל הפורטים בקטלוג, עם התנגשויות בין אפליקציות

משתמש והרשאות (UID/GID)

המשתמש שהתהליך של כל קונטיינר רץ תחתיו, והנתיבים שהוא כותב אליהם. ‏bind mount לאחד הנתיבים האלה חייב להיות ניתן לכתיבה על ידי ה-UID:GID הזה.

רכיב	UID:GID	משתמש	מתחיל כ-root	כותב אל	מקורות
Qdrant	1000:1000	`qdrant`	לא	`/qdrant/storage/qdrant/snapshots`	[2][3][6][10][19]

Qdrant: ה-tags עם ‎-unprivileged נבנים עם USER_ID=1000: ה-Dockerfile יוצר את המשתמש qdrant ‏(1000:1000), יוצר את ‎/qdrant/storage ו-‎/qdrant/snapshots בבעלותו ומגדיר USER 1000:1000; ‏entrypoint.sh לא מחליף משתמש. ‏Docker מעתיק את הבעלות הזו ל-named volumes ריקים. ה-tags הרגילים רצים כ-root ‏(USER_ID=0).

צמיחת אחסון

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

GiB לחודש
רכיב	קל	בינוני	כבד	מקורות
Qdrantהנחה	0.045	0.448	2.242	[9][11]

על מה מספרי הצמיחה נשענים

Qdrant: הגידול תלוי רק בכמות הנקודות שנוספות. ‏ANAROQ מניחה שה-collection מגיע לגודל של ה-preset ‏(0.538 GiB בדיסק) תוך 12 חודשים (0.538 / 12). ‏snapshots ב-‎/qdrant/snapshots נשמרים עד שמוחקים אותם ולא נספרים כאן.
Qdrant: הגידול תלוי רק בכמות הנקודות שנוספות. ‏ANAROQ מניחה שה-collection מגיע לגודל של ה-preset ‏(5.380 GiB בדיסק) תוך 12 חודשים (5.380 / 12). ‏snapshots ב-‎/qdrant/snapshots נשמרים עד שמוחקים אותם ולא נספרים כאן.
Qdrant: הגידול תלוי רק בכמות הנקודות שנוספות. ‏ANAROQ מניחה שה-collection מגיע לגודל של ה-preset ‏(26.898 GiB בדיסק) תוך 12 חודשים (26.898 / 12). ‏snapshots ב-‎/qdrant/snapshots נשמרים עד שמוחקים אותם ולא נספרים כאן.

שדרוג וחזרה לאחור

איך עוברים לגרסה חדשה בבטחה, ואיך חוזרים אחורה אם משהו נכשל.

קודם גיבוי

ליצור snapshot מלא של האחסון (POST /snapshots) ולהעתיק אותו מחוץ לשרת, או להעתיק את ה-volume ‏‎/qdrant/storage כשה-container עצור. [9][13]נגזרמדריך השדרוג לא מציין שלב גיבוי; ה-API של snapshots וכללי השחזור לקוחים ממדריך ה-snapshots, והעתקת ה-volume העצור היא הסקה.

שלבי השדרוג

לקרוא את פוסט ה-release של כל גרסת minor שעוברים, ולעדכן קודם את ה-SDKs של הלקוחות: הם נבדקים מול 3 גרסאות ה-minor האחרונות. [13][15]
לא לדלג על גרסאות minor, גם בצומת יחיד: לעבור דרך ה-patch האחרון של כל אחת (למשל 1.17.x ← 1.18.x ← 1.19.2) כדי שכל מיגרציית נתונים תרוץ. [13][16]
לשנות את ה-tag המוצמד של ה-image בקובץ ה-Compose ולהריץ docker compose pull ו-docker compose up -d. בצומת יחיד יש השבתה קצרה בזמן ההפעלה מחדש. [13]

חזרה לאחור

להפעיל את ה-tag הקודם על עותק משוחזר של ה-volume, או לשחזר את ה-snapshot ‏(‎./qdrant --storage-snapshot) לגרסה הקודמת. ‏snapshot משוחזר רק לאותה גרסת minor או לבאה אחריה, ולכן snapshot שנלקח אחרי השדרוג לא יחזור אחורה. [9]נגזרupstream לא מתעדים downgrade; הרצת ה-tag הקודם על נתונים שנשמרו לפני השדרוג היא הסקה מכלל הגרסאות של snapshots.

שינויים שוברים ידועים

בגרסה 1.19.0: נקודות הקצה הישנות ‎/search, ‏‎/recommend ו-‎/discover הוסרו: יש להעביר קודם את הלקוחות ל-API של ‎/query. הדגלים on_disk, ‏always_ram ו-on_disk_payload לכל רכיב הוצאו משימוש (deprecated) לטובת שכבות הזיכרון האחידות. [15]

מגבלות

וקטורים dense ואינדקס HNSW נשמרים כברירת מחדל ב-cache ב-RAM, ולכן הזיכרון גדל לינארית עם מספר הווקטורים × הממדים. ‏quantization או שכבת cold מקטינים RAM במחיר של דיוק או latency; ה-presets לא מניחים אף אחד מהם. [11][15]
האחסון חייב להיות התקן block מקומי עם מערכת קבצים POSIX, עדיף SSD או NVMe. ‏NFS ואחסון אובייקטים כמו S3 לא עובדים. [1]
זה צומת יחיד: אין replication ואין זמינות גבוהה, ולכל שדרוג יש השבתה קצרה. ‏upstream ממליצים על שלושה צמתים לפחות ו-replication factor ‏2 ל-HA ב-production. [1][11][13]
שחזור snapshot דורש פי שניים מהדיסק שה-collection תופס, ו-snapshots שנשמרים ב-‎/qdrant/snapshots נשארים על אותו דיסק עד שמוחקים אותם. [9][11]

אבטחה

Qdrant ב-self-hosting הוא בלי אימות כברירת מחדל ומאזין על כל הממשקים. התבנית הזו תמיד מגדירה מפתח API של מנהל; יש לשלוח אותו רק ב-HTTPS, כי מפתח ב-HTTP רגיל ניתן ליירוט. [4][6]
לאפליקציות שרק שואלות יש לתת מפתח לקריאה בלבד (QDRANT__SERVICE__READ_ONLY_API_KEY) או JWT לכל collection ‏(jwt_rbac) במקום מפתח המנהל. [6]
שחזור snapshot מכתובת URL גורם ל-Qdrant לגשת לכתובת הזו (נתיב SSRF); אם לא צריך, יש להגדיר enable_snapshot_url_recovery כ-false. טלמטריית שימוש אנונימית פעילה אלא אם telemetry_disabled הוא true. [4][6]

גיבוי

לגבות עם snapshots: ‏snapshot מלא של האחסון (POST /snapshots) בצומת יחיד, או snapshot לכל collection; להוריד אותם ולשמור מחוץ לשרת. ‏snapshot מלא משוחזר בהפעלה עם ‎./qdrant --storage-snapshot. [9]
‏snapshot משוחזר רק לאותה גרסת minor או לבאה אחריה, ולכן יש לקחת snapshot חדש לפני כל שדרוג ולשמור את זה שלפניו. [9][13]