
ينتقل turbopuffer إلى v3: الفهرس المتجهي يصبح فهرسًا ثانويًا
وفقًا لـ turbopuffer، في بنية v3 لن تكون المستندات وفهارس ANN مرتبطة بالعنوان المتجهي، وسينتقل الفهرس المتجهي إلى دور ثانوي. ووفقًا للشركة، تجتاز 100% من اختبارات CI على v3 بنجاح.
في 30 سبتمبر، نُشر في مدونة turbopuffer لنظام البحث الخادمي مقال بعنوان «RIP, vector database». فيه وصف مهندس الشركة دان هاريسون بنية التخزين الجديدة، turbopuffer v3: لن تكون المستندات وفهارس ANN مرتبطة بالعنوان المتجهي، وسينتقل الفهرس المتجهي إلى دور ثانوي، بينما تنتقل وظيفة الفهرس الرئيسي إلى بنية جديدة.
وفقًا لإعلان الشركة، سيسرّع التغيير جميع أنواع البحث، بما في ذلك البحث النصي وregex والمتجهي، ويخلق أساسًا لتنفيذ عدد أكبر بكثير من استعلامات SQL بسرعة على turbopuffer.
من v1 إلى v2
بدأ turbopuffer كقاعدة بيانات متجهية خادمية: كان المستند يتكون من ID ومتجه فقط، وكانت البيانات الأصلية تُخزن في مخزن كائنات، وكانت السرعة توفرها أقراص NVMe وكاشات الذاكرة. كانت المتجهات تُجمّع في عناقيد هرمية: أولًا بـ SPANN، ثم بـ SPFresh الذي اختارته الشركة للفهرسة التزايدية. من بين العملاء الأوائل Cursor وNotion. أضاف الجيل الثاني التصفية بالسمات والبحث النصي BM25، ثم بحث regex، والمطابقة الضبابية، والمتجهات المتفرقة، والتجميعات. يُستخدم المحرك أيضًا في مهام غير بحثية، مثل نظام المزامنة في Linear. كانت قدرات البحث تتزايد، بينما ظل تنظيم التخزين مبنيًا على الفهرس المتجهي، مما يحد من خطط GROUP BY والتجميعات.
ثلاث مشاكل
يذكر المقال ثلاث عيوب في التنظيم المبني على الفهرس المتجهي. أولًا، تكرار البيانات في المخزن: يُخزن المحتوى الكامل للمستند عند عنوان المتجه، لذا فإن التمثيلات متعددة المتجهات، مثل تضمين المستندات أو late interaction، تكرر نفس البيانات على كل متجه. ثانيًا، تكرار الكتابة: SPFresh يعيد بناء العناقيد عند كل كتابة أو تحديث أو حذف، ولأن السمات والفهارس العكسية مرتبطة بنفس العنوان أيضًا، فقد يؤدي تحديث متجه واحد إلى نقل مئات السمات وفهارسها. ثالثًا، قيد التحويل إلى متجهات: المحركات الحديثة تعالج القيم في كتل (DuckDB يستخدم 2048 صفًا، وClickHouse نحو 65 ألفًا، وكتل Lucene تحتوي 256 مستندًا)، بينما تعمل عناقيد ANN في turbopuffer بشكل أفضل مع 100-200 مستند، لذا فإن الخطط الراغبة في كتل أكبر لا تتجاوز هذا الحد.
كمثال على ذلك، تذكر الشركة بحثها النصي الخاص: تقسيم الفهارس إلى كتل منشورات ثابتة (نحو 256) صغّر الفهرس بمقدار 10 مرات وسرّع الطلبات بمقدار 20 مرة.
ما التالي
لم يتم إطلاق v3 في الإنتاج بعد. في سبتمبر، بلغت الشركة مرحلة مهمة: تجتاز 100% من اختبارات CI على v3 بنجاح. ينتقل الفريق الآن من الصحة إلى السرعة وسينشر المعايير المرجعية علنًا على turbopuffer.com/v3 في الأسابيع القادمة، حتى يحقق v3 ويتجاوز تكافؤ الأداء قبل إطلاقه في الإنتاج.
وفقًا لـ turbopuffer، يستضيف النظام أكثر من 1 تريليون مستند، ويعالج أكثر من 10 ملايين كتابة في الثانية، ويخدم أكثر من 25 ألف طلب في الثانية. بالنسبة للبنية السابقة، وصلت الشركة بالبحث المتجهي إلى فهارس منفصلة تحتوي على أكثر من 100 مليار متجه: كان وقت القراءة p99 هو 200 مللي ثانية، والمعدل أكثر من 1000 في الثانية.
SiTech — تطوير ويب مدعوم بالذكاء الاصطناعي
نبني مواقع سريعة وعصرية وندمج الذكاء الاصطناعي في سير عمل الشركات. لديك مشروع أو سؤال؟ يسعدنا مساعدتك.