חזרה
turbopuffer עובר ל-v3: אינדקס וקטורי הופך לאינדקס משני
SiTech AI Team2 דק׳ קריאה

turbopuffer עובר ל-v3: אינדקס וקטורי הופך לאינדקס משני

לפי turbopuffer, בארכיטקטורת v3 מסמכים ואינדקסי ANN לא יהיו מחוברים יותר לכתובת הווקטורית והאינדקס הווקטורי יעבור לתפקיד משני. לפי החברה, 100% מבדיקות ה-CI עוברות בהצלחה על v3.

בבלוג של מערכת החיפוש השרתית turbopuffer פורסם ב-30 בספטמבר פוסט בכותרת „RIP, vector database". בו מהנדס החברה דן האריסון תיאר את ארכיטקטורת האחסון החדשה, turbopuffer v3: מסמכים ואינדקסי ANN לא יהיו מחוברים יותר לכתובת הווקטורית, האינדקס הווקטורי יעבור לתפקיד משני, ותפקיד האינדקס הראשי יועבר למבנה חדש.

לפי הצהרת החברה, השינוי יאיץ את כל סוגי החיפוש, כולל טקסטואלי, regex וווקטורי, וייצור בסיס לכך שב-turbopuffer יופעלו במהירות בקשות SQL רבות יותר.

מ-v1 ל-v2

turbopuffer החל כמסד נתונים וקטורי שרת: מסמך כלל רק ID וווקטור, הנתונים המקוריים אוחסנו במאגר אובייקטים, והמהירות הובטחה על ידי דיסקי NVMe ומטמונות זיכרון. וקטורים מקובצים לאשכולות היררכיים: תחילה באמצעות SPANN, ולאחר מכן באמצעות SPFresh, שהחברה בחרה עבור אינדקסציה אינקרמנטלית. בין הלקוחות הראשונים היו Cursor ו-Notion. הדור השני הוסיף סינון לפי מאפיינים וחיפוש טקסטואלי BM25, ולאחר מכן חיפוש regex, התאמה פרזיזית, וקטורים דלילים ואגרגציות. את המנוע משתמשים גם במשימות לא-חיפושיות, למשל במערכת הסנכרון של Linear. יכולות החיפוש גדלו, אך מבנה האחסון נותר מבוסס על אינדקס וקטורי, מה שהגביל תוכניות GROUP BY ואגרגציות.

שלוש בעיות

בפוסט מוזכרות שלושה חסרונות של מבנה האחסון המבוסס על אינדקס וקטורי. ראשון, כפל נתונים באחסון: תוכן המסמך המלא מאוחסן בכתובת הווקטור, ולכן ייצוגים רבי-ווקטור, כמו הטמעת מסמכים או late interaction, משכפלים את אותם נתונים על כל וקטור. שני, כפל כתיבות: SPFresh בונה מחדש אשכולות בכל כתיבה, עדכון או מחיקה, ומכיוון שגם מאפיינים וגם אינדקסים הפוכים מחוברים לאותה כתובת, עדכון וקטור אחד עשוי להזיז מאות מאפיינים ואת האינדקסים שלהם. שלישי, מגבלת הוקטוריזציה: מנועים מודרניים מעבדים ערכים בבלוקים (DuckDB משתמש ב-2,048 שורות, ClickHouse בכ-65 אלף, בבלוקים של Lucene יש 256 מסמכים), ואילו אשכולות ANN של turbopuffer פועלים בצורה מיטבית על 100-200 מסמכים, ולכן תוכניות המעוניינות בבלוקים גדולים יותר לא יכולות להתגבר על מגבלה זו.

כדוגמה לכך החברה מציינת את החיפוש הטקסטואלי שלה: חלוקת הפוסטינגים לבלוקים קבועים (כ-256) הקטינה את האינדקס פי 10 והאיצה את הבקשות פי 20.

מה הלאה

v3 עדיין לא הושק לייצור. בספטמבר החברה הגיעה לאבן דרך משמעותית: 100% מבדיקות ה-CI עוברות בהצלחה על v3. הצוות עובר כעת מדיוק למהירות ויפרסם בנצ'מרקים בשבועות הקרובים ב-turbopuffer.com/v3 באופן ציבורי, כדי ש-v3 יגיע לפריטט ביצועים לפני השקתו לייצור ויחגור אותו.

לפי turbopuffer, המערכת מארחת מעל טריליון מסמכים, מעבדת מעל 10 מיליון כתיבות לשנייה ומשרתת מעל 25 אלף בקשות לשנייה. עבור הארכיטקטורה הקודמת החברה הביאה את החיפוש הווקטורי לאינדקסים נפרדים עם מעל 100 מיליארד וקטורים: זמן קריאה p99 היה 200 מילישנייה, והתדר היה מעל 1000 לשנייה.

SSiTech

SiTech — פיתוח אתרים בכוח ה-AI

אנחנו בונים אתרים מהירים ומודרניים ומשלבים AI בתהליכי עבודה אמיתיים. יש לכם פרויקט או שאלה? נשמח לעזור.