एक डायरेक्टरी लुकअप।
एक सन्निहित स्कैन।
फ़िल्टर्ड वेक्टर सर्च सामान्यतः एक ऐसे इंडेक्स पर स्कैटर-गैदर होता है जो आपके फ़िल्टर से अनजान है। Telys इसके बजाय भौतिक लेआउट का स्वामित्व लेता है: पार्टीशन कुंजी पर, nearest-neighbours-where-key-equals-x एक O(1) डायरेक्टरी लुकअप और एक सन्निहित ब्लॉक का एक अनुक्रमिक स्कैन है। यह पृष्ठ आज शिप होने वाले रनटाइम को, फिर उस आर्किटेक्चर को — जिस पर यह अभिसरित हो रहा है — स्पेक के रूप में लेबल करके प्रस्तुत करता है।
इंजन तय करता है कि प्रत्येक वेक्टर कहाँ रहता है।
एक कलेक्शन निर्माण के समय partition_by घोषित करता है, और लेआउट कुंजी का अनुसरण करता है। बेस सेगमेंट पार्टीशन द्वारा क्लस्टर किया गया है — प्रत्येक कुंजी एक सन्निहित स्लाइस से मैप होती है — और हालिया राइट उसके बगल में एक परिवर्तनीय, Arrow-आकार के डेल्टा में रहते हैं।
पार्टीशन-क्लस्टर्ड
वेक्टर पार्टीशन कुंजी द्वारा क्रमबद्ध संग्रहीत हैं, इसलिए प्रत्येक पार्टीशन एक सन्निहित ब्लॉक है। एक स्कोप्ड क्वेरी मेमोरी का एक अनुक्रमिक रन पढ़ती है, किसी इंडेक्स में बिखरी पंक्तियाँ नहीं।
O(1) key → slice
एक डायरेक्टरी प्रत्येक पार्टीशन मान को बेस सेगमेंट में उसके (offset, length) से मैप करती है। फ़िल्टर हल करना एक डिक्शनरी लुकअप है, इंडेक्स ट्रैवर्सल नहीं।
Arrow-आकार के राइट
add और upsert यहाँ जोड़े जाते हैं, प्रत्येक पंक्ति एक मोनोटोनिक राइट LSN से अंकित। डेल्टा तुरंत क्वेरी योग्य है और एक स्कैन पाथ के माध्यम से बेस स्लाइस के साथ संयुक्त होता है।
एक स्कोप्ड क्वेरी क्या निष्पादित करती है।
col.search(qvec, where={"tenant_id": "acme"}, top_k=10)
फ़िल्टर उस पार्टीशन कुंजी का नाम लेता है जिसके साथ कलेक्शन बनाया गया था।
O(1) लुकअप: पार्टीशन मान बेस सेगमेंट में (offset, length) से हल होता है। कोई कैंडिडेट जनरेशन नहीं, कोई ग्राफ एंट्री पॉइंट नहीं।
एक sequential block पर SIMD exact scoring। इस path पर recall 1.0 है — यह scan है, अनुमान नहीं। इस step के मापे गए p50/p95 benchmarks page पर प्रकाशित हैं, हर अंक अपने recall gate और rig से बँधा है।
एक ही key की rows Arrow-shaped delta में उसी path से score होती हैं। एक write अगली query को तुरंत दिखता है।
Snapshot LSN पर hits फ़िल्टर होते हैं: tombstoned और superseded versions कभी सामने नहीं आतीं। Top-k, explain payload के साथ लौटता है।
बड़े partitions एक declared fork लेते हैं: build_ivf, row threshold से ऊपर के हर partition पर per-partition IVF रखता है, और queries उससे exact rerank के साथ route होती हैं — recall floor के अनुसार calibrated, और plan में नामित।
हर result अपना plan बताता है।
explain=True वह physical plan लौटाता है जो query ने वास्तव में लिया। Partition key पर contiguous-slice scan मिलता है। Oversized partitions IVF fork declare करते हैं। Off-key filters scatter-gather पर fall back करते हैं — और payload बताता है क्यों।
hits = col.search(qvec, where={"tenant_id": "acme"}, top_k=10, explain=True)
hits["explain"]["plan"]
# on the partition key → "PartitionSliceExactF32" # one contiguous slice, exact, recall 1.0
# oversized partition → "PartitionIVFRerankF32" # per-partition IVF + exact rerank
# off-key filter → "ScatterGatherExact" # fallback — and it says why:
hits["explain"]["fallback_reason"]
# "path is not the physical partition key"कुछ overwrite नहीं होता। Versions superseded होते हैं।
Write model append-only MVCC है। upsert एक logical id का नया version लिखता है और पिछले को superseded mark करता है; delete एक delete LSN पर tombstone रखता है; snapshot() एक consistent read view pin करता है; compact() delta को base में fold करता है और जो कोई snapshot नहीं देख सकता उसे हटा देता है।
col.upsert(vectors, ids=ids, metadata=metadata) # a new version; the prior one is superseded col.delete(["doc-41"]) # tombstone at a delete LSN — no in-place erase lsn = col.snapshot() # pin a consistent read view at an LSN col.compact() # fold delta into base; drop superseded rows col.build_ivf(min_rows=20000, target_recall=0.98)
| Call | क्या करता है |
|---|---|
| जोड़ें / add_texts | नई rows insert करें। Duplicate ids अस्वीकार होते हैं — एक logical id के लिए दूसरी physical row के लिए जानबूझकर upsert आवश्यक है। |
| अपसर्ट / upsert_texts | एक logical id का नया version लिखें; पिछला version superseded होता है, in place कभी overwrite नहीं होता। |
| खोजें / search_text | Filtered top-k। explain=True physical plan को result से जोड़ता है। |
| delete | Logical rows को एक delete LSN पर tombstone करें। |
| compact | Delta को base segment में fold करें; tombstoned और superseded versions हटाएँ। |
| build_ivf | Row threshold से ऊपर के partitions पर per-partition IVF बनाएँ, recall floor के अनुसार calibrated। |
| snapshot | एक LSN लौटाएँ जो consistent read view pin करे। |
| save / stats | Collection को disk पर persist करें; row counts, partitions, और layout facts रिपोर्ट करें। |
नीचे सब कुछ specification है, shipped API reference नहीं। यह वह substrate है जिस पर runtime converge हो रहा है। SDK-facing seam frozen है, इसलिए नीचे का swap callers को दिखाई नहीं देता।
एक planner। एक flat IR। एक executor।
तीन front ends एक planner में lower होते हैं, जो एक flat physical intermediate representation emit करता है, जिसे एक Mojo vectorized executor सीधे Arrow buffers पर execute करता है।
Memory model (remember · recall · as_of), query API (point_get · scan · search · hybrid_search), और fabric। एक entry contract; कोई per-API engine नहीं।
Logical और physical planning एक ही जगह। Selectivity segment statistics से estimate होती है; plan explicit है और result के साथ लौटता है।
Integer slots से bound operators की एक flat array। Inter-operator register एक row set है — bitmap, sorted row-ids, या selection vector।
Arrow buffers और FAISS candidate arrays पर vectorized execution। SIMD hot path Python से बाहर रहता है; compressed Parquet pages पहले scratch buffers में decode होते हैं।
Mutation layer
Durability और ordering के लिए write-ahead log, और तत्काल visibility के लिए mutable Arrow-shaped delta — वह table layer जो Parquet अकेले नहीं दे सकता।
सील, अपरिवर्तनीय
Durable compressed columnar segments। Footer statistics, segment और row-group pruning चलाते हैं; sealed files कभी mutate नहीं होतीं।
FAISS ANN
Per-segment FAISS indexes, segment के checksum और version से bound, read-only mapped, जिनकी lifetime read snapshot से जुड़ी है।
Pruning और lexical
Pruning के लिए zone maps, bloom filters, और bitmaps; sparse retrieval और score fusion के लिए BM25 sidecar।
SCAN FILTER PROJECT POINT_GET RANGE_GET AGGREGATE TOP_K HASH_JOIN HASH_GROUP_BY SORT ANN_SEARCH SPARSE_SEARCH FUSE RERANK MATERIALIZE
पहले WAL। तुरंत visible। Background में sealed।
Checksums और monotonic LSNs के साथ append-only frames। Recovery, last sealed LSN के बाद records replay करती है और पहले bad checksum पर truncate करती है।
Write mutable delta में land होता है और तुरंत queryable होता है — sealed segments और delta एक scan path से union होते हैं।
आकार, पंक्ति, या आयु सीमा पार होने पर, delta को क्रमबद्ध कर एक Parquet सेगमेंट के रूप में उसके .vidx और sidecars सहित लिखा जाता है, फिर एक atomic manifest swap द्वारा प्रकाशित किया जाता है।
बैकग्राउंड मर्ज छोटे सेगमेंट को एकत्र करते हैं, tombstoned पंक्तियाँ हटाते हैं, और sidecars पुनर्निर्मित करते हैं — budget-controlled, ताकि on-device deployments शांत रहें।
Sealed सेगमेंट कभी परिवर्तित नहीं होते। एक read (manifest snapshot, LSN) को pin करता है; writers नए सेगमेंट seal करते हैं और in-flight readers को बाधित किए बिना manifest swap करते हैं। Garbage collection सबसे पुराने live snapshot की प्रतीक्षा करता है।
फ़िल्टर योजना चुनता है, न कि इसके विपरीत।
Filtered ANN, selectivity द्वारा adaptive planning है: planner सेगमेंट आँकड़ों से अनुमान लगाता है कि कितनी पंक्तियाँ फ़िल्टर से बचती हैं, फिर वह सबसे किफ़ायती रणनीति चुनता है जो recall contract बनाए रखे।
Prefilter → सटीक
पहले scalar या bitmap prefilter, फिर बचे हुए पर exact SIMD scoring। एक पंक्ति सीमा से नीचे ANN पूरी तरह छोड़ा जाता है — exact scan, recall 1.0।
Allow-bitmap ट्रैवर्सल
ANN traversal एक allow-bitmap वहन करता है, इसलिए index केवल वही पंक्तियाँ सामने लाता है जिन्हें फ़िल्टर स्वीकार करता है।
ANN → पोस्ट-फ़िल्टर
पहले adaptive over-fetch के साथ ANN, फिर post-filter। फ़िल्टर बहुत कम हटाता है, इसलिए candidate generation आगे रहती है।
शुद्धता की जाँच किसी भी गति संख्या से पहले आती है।
शिप किया गया runtime दोनों engine implementations के विरुद्ध चलाए गए parity suites द्वारा सत्यापित है, और प्रत्येक query उस physical plan का नाम बता सकती है जो उसने लिया। यहाँ संचालन का क्रम यही है: पहले शुद्धता की जाँच, फिर माप।
Benchmarks एक fairness contract के तहत प्रकाशित होते हैं — matched recall, matched hardware, transport-separated results, win / tie / lose रिपोर्ट किए जाते हैं। पहले मापे गए परिणाम अब benchmarks page पर live हैं, हर अंक अपनी पूरी शर्तों के साथ: hardware, dataset, dimension, selectivity, recall, और transport। हर multiplier अपनी stated conditions के बाहर एक hypothesis है।