turbopuffer 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 დოკუმენტია), turbopuffer-ის ANN კლასტერები კი 100-200 დოკუმენტზე მუშაობს საუკეთესოდ, ამიტომ უფრო დიდი ბლოკების მსურველი გეგმები ამ ზღვარს ვერ სცდება.

ამის მაგალითად კომპანია საკუთარ ტექსტურ ძებნას ასახელებს: პოსტინგების ფიქსირებულ ბლოკებად (დაახლოებით 256) დაყოფამ ინდექსი 10-ჯერ დააპატარავა და მოთხოვნები 20-ჯერ დააჩქარა.

რა შემდეგ

v3 ჯერ წარმოებაში არ გაშვებულა. სექტემბერში კომპანიამ მნიშვნელოვან ეტაპს მიაღწია: v3-ზე CI ტესტების 100% წარმატებით გადის. გუნდი ახლა სისწორიდან სისწრაფეზე გადადის და ბენჩმარკებს მომდევნო კვირებში turbopuffer.com/v3-ზე საჯაროდ გამოაქვეყნებს, რათა v3 წარმოებაში გაშვებამდე წარმადობის პარიტეტს მიაღწიოს და გასცდეს.

turbopuffer-ის თქმით, სისტემა 1 ტრილიონზე მეტ დოკუმენტს მასპინძლობს, წამში 10 მილიონზე მეტ ჩაწერას ამუშავებს და წამში 25 ათასზე მეტ მოთხოვნას ემსახურება. წინა არქიტექტურისთვის კომპანიამ ვექტორული ძებნა 100 მილიარდზე მეტი ვექტორის მქონე ცალკეულ ინდექსებამდე მიიყვანა: p99 წაკითხვის დრო 200 მილიწამი იყო, სიხშირე კი წამში 1000-ზე მეტი.