pgvector თუ Pinecone: სწრაფი ძიება თუ მყისიერი ინდექსაცია

თუ აპლიკაცია უკვე PostgreSQL-ზე მუშაობს, pgvector ხშირად საკმარისია ვექტორული ძიებისთვის: ჩანაწერი, ვექტორი და მასთან დაკავშირებული მონაცემები ერთ ტრანზაქციაში ინახება. ნაგულისხმევი იზოლაციის რეჟიმში დასრულებული ტრანზაქციის მონაცემი მომდევნო მოთხოვნისთვის ხელმისაწვდომია. Pinecone უფრო ძლიერი კანდიდატია, როცა ვექტორული ძიების დაყოვნება განსაკუთრებით მკაცრია, ფილტრები მრავალფეროვანია და გუნდს ინდექსის რესურსების მართვა არ სურს.

ამ არჩევანს მხოლოდ კორპუსის ზომა არ წყვეტს. ერთსა და იმავე რაოდენობის ვექტორებს განსხვავებული მოთხოვნები შეიძლება ჰქონდეს: ერთი პროდუქტი ახლად გამოქვეყნებულ ჩანაწერს მაშინვე ეძებს, მეორე კი დიდ, იშვიათად განახლებულ არქივში მრავალ პირობას აერთიანებს. ამიტომ შესადარებელია ძიების დაყოვნება, შედეგების სისრულე, ჩანაწერის ხილვადობის დრო და მთელი სისტემის ხარჯი.

რას ამბობს დიდი დატვირთვის გამოქვეყნებული შედეგი

The Stack Stories-ის ანგარიშის ავტორი აღწერს 90-დღიან დატვირთვას დაახლოებით 4,8 მილიონი დოკუმენტითა და დღეში საშუალოდ 110 400 ძიებით: მხოლოდ ვექტორული ძიების p95 Pinecone-ზე 47 მწმ, Neon-ზე გაშვებულ pgvector-ზე 71 მწმ იყო; მითითებული თვიური ხარჯი შესაბამისად 1 887 და 548 დოლარს შეადგენდა, ხოლო pgvector-ში ახალი ჩანაწერი 100 მწმ-ზე ნაკლებში ხდებოდა საძიებელი. ეს ავტორის მიერ აღწერილი ერთი მედია პლატფორმის შედეგებია და არა დამოუკიდებლად გამეორებული შედარება.

p95 ნიშნავს, რომ გაზომილი მოთხოვნების დიდი უმრავლესობა მითითებულ ზღვარს არ გასცდა. გამოქვეყნებული დაყოვნების მაჩვენებლები მხოლოდ ვექტორულ ძიებას ეხება; RAG პასუხს ასევე ემატება შეკითხვის ვექტორად გარდაქმნა, შესაძლო ხელახალი დალაგება და ენობრივი მოდელის მუშაობა. თუ ძიება საერთო პასუხის მცირე ნაწილია, მის დაჩქარებას მომხმარებელი შეიძლება ნაკლებად გრძნობდეს, ვიდრე ცალკე გაზომვა მიანიშნებს.

ტესტის ორივე მხარეს მნიშვნელობა აქვს კონკრეტულ გარემოსაც: pgvector მუშაობდა მართვად Neon Postgres-ში HNSW ინდექსით, Pinecone კი ცალკე მართვად სერვისად გამოიყენებოდა. ასეთ შედარებაში ფასი მხოლოდ პროგრამის თვისება არ არის; მას ცვლის ღრუბლის ტარიფი, შენახული მეტამონაცემები, მოთხოვნების რაოდენობა და გამოთვლითი რესურსის შერჩევა. ერთი კონფიგურაციის უპირატესობა სხვა სამუშაო დატვირთვაზე ავტომატურად არ გადადის.

როდის არის სიახლე უფრო მნიშვნელოვანი, ვიდრე ძიების სიჩქარე

თუ მომხმარებელმა ახლახან გამოქვეყნებული სტატია იმავე მოქმედების შემდეგ უნდა იპოვოს, საძიებო სისტემისთვის გადამწყვეტია არა ჩაწერის დადასტურება, არამედ ახალი ჩანაწერის გამოჩენა შედეგებში. PostgreSQL-ის ტრანზაქციის წესებით, ნაგულისხმევ Read Committed რეჟიმში ახალი SELECT ხედავს მის დაწყებამდე დასრულებულ ტრანზაქციებს, ხოლო მიმდინარე ტრანზაქცია საკუთარ ადრინდელ ცვლილებებსაც ხედავს. როცა ვექტორი იმავე PostgreSQL ჩანაწერში ინახება, აპლიკაციას გარე ინდექსამდე ცვლილებების გადატანის ცალკე ეტაპი არ სჭირდება.

Pinecone-ში ჩაწერის მიღება და ძიებაში გამოჩენა განცალკევებული ეტაპებია. Pinecone-ის არქიტექტურის აღწერით, ჩაწერა სწრაფად დასტურდება, ახალი მონაცემი კი ჩვეულებრივ რამდენიმე წამში ჩანს საძიებო მოთხოვნებში; მუდმივი შენახვა და ინდექსის ოპტიმიზაცია ფონურად მიმდინარეობს. ეს პრაქტიკულად საკმარისია პერიოდულად განახლებული კატალოგისთვის, მაგრამ მყისიერი ხილვადობის მკაცრი მოთხოვნისას PostgreSQL-ის ტრანზაქციული გზა უფრო მარტივ პირობას იძლევა.

სიახლის მოთხოვნა მკაფიოდ უნდა ეხებოდეს საძიებო შედეგს და არა მხოლოდ API-ს წარმატებულ პასუხს. თუ დოკუმენტის ტექსტი PostgreSQL-შია, ვექტორი კი Pinecone-ში, გამოქვეყნებასა და საძიებო შედეგს შორის დამატებით ჩნდება სინქრონიზაციის დრო. ცვლილება, წაშლა და წვდომის უფლების შეცვლაც იმავე გზით უნდა აისახოს, რათა ძიებამ ძველი ან უკვე მიუწვდომელი ჩანაწერი არ დააბრუნოს.

რას ცვლის HNSW ინდექსის მეხსიერება

pgvector-ის HNSW ინდექსი IVFFlat-თან შედარებით უკეთეს კომპრომისს იძლევა ძიების სიჩქარესა და შესაბამისი შედეგების პოვნას შორის, თუმცა უფრო ნელა იგება და მეტ მეხსიერებას იყენებს. pgvector-ის დოკუმენტაცია აღწერს, რომ ინდექსის აგება საგრძნობლად ნელდება, როცა HNSW გრაფი მისთვის გამოყოფილ სამუშაო მეხსიერებაში აღარ ეტევა. ამიტომ მხოლოდ ვექტორების ფაილების ზომით საჭირო რესურსის დათვლა შეცდომაში შემყვანია.

მეხსიერება მხოლოდ საწყის იმპორტს არ სჭირდება. ზრდად კორპუსში ინდექსი, ერთდროული ძიებები და სხვა PostgreSQL სამუშაოები ერთსა და იმავე გარემოს რესურსებს იყოფს. თუ ვექტორული ძიება უკვე მოქმედი ტრანზაქციული ბაზის პასუხის დროს აუარესებს, დანაზოგის ნაწილს უფრო დიდი ბაზა ან ძიებისთვის გამოყოფილი ინფრასტრუქტურა წაიღებს.

Pinecone-ის შედარებაში აღწერილ ოთხ საჯარო მონაცემთა ნაკრებზე pgvector-ის HNSW ინდექსის მეხსიერება ნედლი მონაცემის მოცულობის 1,2-ჯერიდან 5-ზე მეტ ჯერამდე მერყეობდა; იმავე, 2024 წლის ტესტში Pinecone-ის გამოთვლილი მიმდინარე ხარჯი უფრო დაბალი გამოვიდა. ეს მომწოდებლის ტესტია: მასში pgvector-ის ფასი EC2-ისა და EBS-ის დაშვებებით დათვალეს, ხოლო მოთხოვნებისა და განახლებების რეჟიმი მედია პლატფორმის ზემოთ აღწერილ დატვირთვას არ ემთხვევა. განსხვავებული გარემო და ხარჯის მოდელი ხსნის, რატომ არ იძლევა ორი გამოქვეყნებული შედარება ერთ უნივერსალურ ფასობრივ გამარჯვებულს.

როგორ მოქმედებს ფილტრი შედეგების სისრულეზე

ფილტრის მნიშვნელობების რაოდენობა და შერჩევითობა ძიების არქიტექტურას ცვლის. თუ მოთხოვნა მხოლოდ ერთი მომხმარებლის, ენის ან კატეგორიის ჩანაწერებს ეხება, pgvector-ის მიახლოებითი HNSW ძიება თავდაპირველად ვექტორულ კანდიდატებს არჩევს და პირობა შემდეგ გამოიყენება. ვიწრო ფილტრმა შეიძლება ამ კანდიდატების დიდი ნაწილი გამორიცხოს და მოთხოვნილზე ნაკლები შედეგი დატოვოს, მიუხედავად იმისა, რომ შესაფერისი ჩანაწერები ბაზაში არსებობს.

PostgreSQL-ში გამოსავალი დამოკიდებულია მონაცემის განაწილებაზე. იშვიათ მნიშვნელობაზე ჩვეულებრივი ინდექსით ჯერ გაფილტვრა და შემდეგ ზუსტი ვექტორული დალაგება შეიძლება გამოდგეს; რამდენიმე სტაბილური კატეგორიისთვის ნაწილობრივი HNSW ინდექსი არსებობს. მრავალი განსხვავებული მნიშვნელობის შემთხვევაში ცხრილის დაყოფა ან იტერაციული სკანირების ჩართვა განიხილება, მაგრამ დამატებითი სკანირება რესურსს ხარჯავს და კონფიგურაციის ზღვრამდე მიდის.

Pinecone ფილტრებს უშუალოდ ძიების პროცესში ამუშავებს და შერჩევითი პირობებისთვის საძიებო არეალს ამცირებს. ეს განსაკუთრებით სასარგებლო შეიძლება იყოს მრავალმომხმარებლიან პროდუქტში, სადაც თითო მოთხოვნას სხვა წვდომის არეალი აქვს. თუმცა უპირატესობის ზომა დამოკიდებულია იმაზე, რამდენ ჩანაწერს ტოვებს კონკრეტული ფილტრი და რა სიზუსტე სჭირდება პროდუქტს; ზოგადი p95 ამ პირობებს ვერ ანაცვლებს.

გადაწყვეტილების მატრიცა

• კორპუსი და მეხსიერება: თუ PostgreSQL-ის არსებული სერვერი ვექტორებსა და HNSW ინდექსს იტევს ისე, რომ სხვა მოთხოვნებს არ აფერხებს, pgvector ეკონომიური საწყისი არჩევანია. სწრაფი ზრდა და გაურკვეველი ინდექსის მოცულობა Pinecone-ის მართვად რესურსებს მეტ ღირებულებას ანიჭებს.
• ფილტრების მნიშვნელობათა მრავალფეროვნება: რამდენიმე განმეორებადი კატეგორია PostgreSQL-ის ინდექსებით მარტივად იმართება. მრავალი მომხმარებელი, განსხვავებული ფილტრი და მკაცრი მოთხოვნა შედეგების რაოდენობაზე Pinecone-ისკენ წონის არგუმენტს.
• სიახლის SLO: ტრანზაქციის დასრულებისთანავე საძიებო ჩანაწერი pgvector-ის მხარესაა ძლიერი არგუმენტი. თუ მისაღებია რამდენიმე წამში გამოჩენა, Pinecone-ის ასინქრონული გზა პრაქტიკული ვარიანტია.
• გუნდი და დრო: PostgreSQL-ის გამოცდილ გუნდს ერთ ბაზაში შეუძლია ინდექსის, მონაცემისა და უფლებების მართვა, თუმცა HNSW-ის გამართვას დრო სჭირდება. თუ ამ დროს ვერ გამოყოფს და ცალკე სერვისის საფასური მისაღებია, Pinecone ოპერაციულ ტვირთს ამცირებს.

არჩევანი პროდუქტის რეალურ შეზღუდვაზე უნდა დაეყრდნოს. თუ არსებული PostgreSQL აკმაყოფილებს ძიების დაყოვნებისა და შედეგების სისრულის მოთხოვნებს, ხოლო ახლად ჩაწერილი მონაცემი დაუყოვნებლივ უნდა იძებნებოდეს, pgvector დამატებითი სისტემის საჭიროებას ხსნის. Pinecone-ის ფასი გამართლდება მაშინ, როცა მართვადი ინდექსი, რთული ფილტრები ან უფრო დაბალი ვექტორული ძიების დაყოვნება ამ დამატებით ხარჯსა და სინქრონიზაციის გზას გადაწონის.