Index आकार, Build समय और IVFFlat

Index vectors से बड़ा हो सकता है

HNSW index vectors के अलावा graph links भी रखता है, इसलिए अक्सर कच्चे डेटा से बड़ा होता है और तब सबसे अच्छा चलता है जब memory में समाए (PostgreSQL के shared buffers और OS cache)। लाखों rows पर बनाने में लंबा समय और बहुत memory लग सकती है, और भारी inserts व deletes रखरखाव लागत जोड़ते हैं। IVFFlat pgvector का दूसरा index प्रकार है: build के समय vectors को lists में बाँटता है (इसलिए build से पहले डेटा मौजूद होना और lists की समझदार संख्या चाहिए), निकटतम probes lists खोजता है, तेज़ बनता है और कम memory लेता है, पर समान गति पर आम तौर पर HNSW से कम recall देता है और डेटा वितरण बदलने पर दोबारा build चाहिए हो सकता है। अंगूठे का नियम: HNSW से शुरू करें जब तक build समय या memory IVFFlat के लिए मजबूर न करे।

Table और index आकार, चलाकर

मैंने यह SQL Docker container में pgvector extension संस्करण 0.8.6 के साथ PostgreSQL 16 पर चलाया। 32 आयामों के 20,000 vectors के लिए कच्चा vector डेटा लगभग 2.6 MB, table लगभग 4 MB और HNSW index लगभग 9 MB है, यानी अकेला index कच्चे vectors का कई गुना है। 768 आयामों के दस लाख vectors पर वही प्रभाव gigabytes में है।

SELECT 'rows' AS what, count(*)::text AS value FROM big
UNION ALL SELECT 'table size (MB)', round(pg_table_size('big') / 1e6)::text
UNION ALL SELECT 'hnsw index size (MB)', round(pg_relation_size('big_hnsw') / 1e6)::text
UNION ALL SELECT 'raw vectors: 20000 x 32 x 4 bytes (MB)', round(20000 * 32 * 4 / 1e6, 1)::text;

Output:

                  what                  | value 
----------------------------------------+-------
 rows                                   | 20000
 table size (MB)                        | 4
 hnsw index size (MB)                   | 9
 raw vectors: 20000 x 32 x 4 bytes (MB) | 2.6
(4 rows)

Bulk loading के बाद build करें

डेटा लोड करने के बाद index बनाना आम तौर पर मौजूदा index में insert करने से कहीं तेज़ है।

त्वरित जाँच: pgvector में समान गति पर आम तौर पर बेहतर recall कौन-सा index प्रकार देता है?

• IVFFlat
• HNSW
• कोई नहीं; वे समान हैं
• B-tree