Dedicated вектор сантай салах ёс гүйцэтгэх үү? Timescale 100 сая векторт 6мс хурдтай "pg_vectorsearch"-ийг нээлттэй болголоо

Орчин үеийн AI болон RAG (Retrieval-Augmented Generation) систем хөгжүүлэгчдийн хувьд өгөгдлийн сангийн сонголт үргэлж хүндхэн сонголт байсаар ирсэн. Бид өөрсдийн танил дотно PostgreSQL дээр pgvector ашиглах уу, эсвэл тусад нь Pinecone, Qdrant, Milvus зэрэг dedicated вектор санг архитектуртаа нэмж, өгөгдлийн синхрончлолын төвөгтэй pipeline-тай зууралдах уу?

Энэхүү маргаанд Timescale компани маш хүчтэй хариулт өгч, сүүлийн 24 цагийн дотор технологийн нийгэмлэгийг шуугиулсан шинэ нээлттэй эх бүхий өргөтгөлөө танилцууллаа: pg_vectorsearch. Тэдний бүтээсэн цоо шинэ PRISM индекс нь pgvector-ийн HNSW индексийн хамгийн том сул талуудыг үндсээр нь шийдэж, энгийн реляци өгөгдлийн санг дэлхийн жишигт нийцсэн өндөр ачаалалт вектор хайлтын хүчирхэг систем болгон хувиргажээ.

Өнөөгийн HNSW-ийн "зовлон": Хэт их RAM, хэт удаан Build

PostgreSQL-д вектор хайлт хийхэд өнөөг хүртэл HNSW (Hierarchical Navigable Small World) хамгийн шилдэг сонголт байсан. Гэвч масштаб томрох тусам инженерийн багууд хоёр том ханыг мөргөдөг:

RAM-ийн асар их өлсгөлөн: HNSW нь хайлтын өндөр нарийвчлалыг (recall) хадгалахын тулд графыг бүхэлд нь санах ойд (RAM) барихыг шахдаг. Хэдэн арван сая өндөр хэмжээст (high-dimensional) вектортой системд энэ нь хэдэн зуун гигабайт санах ой шаардаж, дэд бүтцийн зардлыг огцом өсгөдөг.
Индекс үүсгэх аймшигт хугацаа: 50–100 сая векторт HNSW индекс барих нь зарим тохиолдолд бүтэн өдөр эсвэл хэд хоног үргэлжилж, production орчинд maintenance window гаргахад туйлын хүндрэлтэй болдог байв.

Харин нөгөө сонголт болох IVFFlat нь санах ойд хэмнэлттэй ч том өгөгдөл дээр хайлтын хурд болон нарийвчлал нь шаардлага хангадаггүй сул талтай байлаа.

PRISM архитектур: 100M векторт 6ms латент, 4 дахин бага RAM

Timescale-ийн инженерүүдийн бүтээсэн PRISM (Partitioning, Re-ordering, and Indexing for Scalable Metric-search) индекс нь quantized IVF (Inverted File Index) бүтцийг шаталсан чиглүүлэлттэй (hierarchical routing) хослуулсан шийдэл юм.

Туршилтын бодит үр дүнгүүдээс дурдвал:

6 миллисекундийн хайлтын хугацаа: 100 сая вектор бүхий асар том өгөгдлийн багц дээр хайлтын латентийг 6ms болгон бууруулсан.
4 дахин бага санах ойн зарцуулалт: HNSW-тэй ижил түвшний нарийвчлал (~95% recall) гаргахдаа 4 дахин бага RAM шаардана. Санах ойд багтахгүй датаг SSD диск рүү offload хийхдээ ч гүйцэтгэлээ алдахгүй байхаар оновчлогджээ.
Индекс барих хугацаа 2 цаг хүрэхгүй: HNSW дээр өдөржин болдог байсан 100 сая векторын индексийг ердөө 2 цаг хүрэхгүй хугацаанд босгодог.

Энэхүү огцом үсрэлтийг тэд хоёр гол түвшний инновацаар шийджээ:

RaBitQ Quantization: Векторуудын хэмжээг квантчлан шахахдаа онолын алдааны хязгаарыг (theoretical error bounds) урьдчилан баталгаажуулж, хоёр шатлалт (two-stage) хайлт хийдэг. Эхлээд шахсан өгөгдөл дээр хурдан шүүж, дараа нь бодит зайн тооцооллыг гүйцэтгэдэг.
Hardware-Level SIMD оптимизаци: Векторын зайн тооцооллыг (Cosine, L2/Euclidean гэх мэт) техник хангамжийн түвшинд AVX2, AVX-512 болон ARM чипүүдэд зориулсан NEON зааварчилгааны багцаар шууд хурдасгасан.

Хөгжүүлэгчид хэрхэн ашиглах вэ? Төвөгтэй тохиргоо үгүй

PostgreSQL-ийн олон өргөтгөлүүдийн толгойн өвчин нь олон арван тохиргооны параметрүүд (tuning hyperparameters) байдаг бол pg_vectorsearch дээр асуудлыг туйлын хялбаршуулжээ.

Query түвшинд хөгжүүлэгч тааруулах шаардлагатай цорын ганц параметр нь prism.nprobe юм. Хэрэв та утгыг 0 (default) хэвээр үлдээвэл систем өөрөө автоматаар 95%-ийн нарийвчлалыг онилон тооцоолдог.

Суулгах болон ашиглах SQL синтаксыг харвал:

-- Өргөтгөлийг идэвхжүүлэх
CREATE EXTENSION pg_vectorsearch;

-- PRISM индекс үүсгэх
CREATE INDEX ON my_documents 
USING prism (embedding vector_cosine_ops);

-- Хайлт хийх (PostgreSQL-ийн танил оператороор)
SELECT title, content
FROM my_documents
ORDER BY embedding <=> '[0.012, -0.045, ...]'
LIMIT 5;

Гаднын ямар нэг нэмэлт microservice асаах шаардлагагүй, PostgreSQL-ийн Native Index Access Method хэлбэрээр ажиллах тул гүйлгээний бүрэн бүтэн байдал (ACID), transactional consistency зэрэг PostgreSQL-ийн бүх давуу тал бүрэн хадгалагдана.

Багаараа нэвтрүүлэхээс өмнө анхаарах 3 зүйл

Хэдийгээр үзүүлэлтүүд нь үнэхээр сэтгэл хөдөлгөм боловч одоогийн alpha шатанд дараах техникийн хязгаарлалтуудыг бодолцох хэрэгтэй:

PostgreSQL хувилбарын шаардлага: Одоогоор зөвхөн PostgreSQL 18 болон түүнээс дээш хувилбарт ажиллана. Хэрэв танай баг legacy систем дээр (жишээ нь PG 14/15/16) байгаа бол upgrade хийх шаардлага үүснэ.
Dimension-ий хязгаар: PRISM нь одоогоор дээд тал нь 1968 хэмжээст (dimensions) вектор дэмждэг. Ихэнх орчин үеийн embedding модель (OpenAI text-embedding-3-small нь 1536 dim, Cohere нь 1024 dim)-д бүрэн хангалттай боловч түүнээс том моделиуд дээр truncation эсвэл subvector ашиглах хэрэгтэй болно.
Rebalancing механизм: Одоогоор өгөгдөл маш ихээр шинэчлэгдэх (heavy write/churn) үед recall унахаас сэргийлж гараар prism_rebalance хийх шаардлагатай байгаа ба автоматаар тэнцвэржүүлдэг incremental update-ийг удахгүй гарах GA хувилбарт багтаахаар ажиллаж байна.

Дүгнэлт: "Just Use Postgres" зарчим дахин ялав уу?

Хөгжүүлэгчдийн дунд түгээмэл байдаг "You probably just need Postgres" гэх үг AI эрин зуунд улам бүр батлагдсаар байна. Эхлээд энгийн relational өгөгдөл, дараа нь JSON, дараа нь Full-text search, цагийн цуваа өгөгдөл (TimescaleDB), одоо харин 100 сая+ векторын масштабын хайлтыг PostgreSQL дангаараа өлхөн шийдэх боломжтой боллоо.

Хэрэв танай бүтээгдэхүүнд RAG, semantic search эсвэл recommendation систем хөгжүүлж байгаа бөгөөд дэд бүтцээ энгийн, найдвартай, зардал багатай байлгахыг хүсвэл pg_vectorsearch бол заавал судалж турших ёстой гол технологийн шинэчлэл юм.

Эх сурвалж:

Timescale Engineering: Announcing pg_vectorsearch: Scalable Open-Source Vector Search in PostgreSQL
GitHub Repository: timescale/pg_vectorsearch