trustgraph/docs/tech-specs/vector-store-lifecycle.hi.md

layout	title	parent
default	वेक्टर स्टोर लाइफसाइकिल प्रबंधन	Hindi (Beta)

वेक्टर स्टोर लाइफसाइकिल प्रबंधन

Beta Translation: This document was translated via Machine Learning and as such may not be 100% accurate. All non-English languages are currently classified as Beta.

अवलोकन

यह दस्तावेज़ बताता है कि ट्रस्टग्राफ विभिन्न बैकएंड कार्यान्वयन (क्यूड्रेंट, पाइनकोन, मिल्वस) में वेक्टर स्टोर संग्रहों का प्रबंधन कैसे करता है। डिज़ाइन विभिन्न आयामों वाले एम्बेडिंग का समर्थन करने की चुनौती को संबोधित करता है बिना आयाम मानों को हार्डकोड किए।

समस्या विवरण

वेक्टर स्टोर को संग्रह/इंडेक्स बनाते समय एम्बेडिंग आयाम को निर्दिष्ट करने की आवश्यकता होती है। हालाँकि: विभिन्न एम्बेडिंग मॉडल अलग-अलग आयाम उत्पन्न करते हैं (उदाहरण के लिए, 384, 768, 1536) आयाम तब तक ज्ञात नहीं होता है जब तक कि पहला एम्बेडिंग उत्पन्न नहीं हो जाता एक ही ट्रस्टग्राफ संग्रह कई मॉडलों से एम्बेडिंग प्राप्त कर सकता है एक आयाम को हार्डकोड करना (उदाहरण के लिए, 384) अन्य एम्बेडिंग आकारों के साथ विफलताओं का कारण बनता है

डिज़ाइन सिद्धांत

1. आलसी निर्माण: संग्रह पहली बार लिखने के दौरान ऑन-डिमांड बनाए जाते हैं, संग्रह प्रबंधन कार्यों के दौरान नहीं।
2. आयाम-आधारित नामकरण: संग्रह नामों में एम्बेडिंग आयाम को एक प्रत्यय के रूप में शामिल किया जाता है।
3. सुचारू गिरावट: गैर-मौजूदा संग्रहों के खिलाफ किए गए प्रश्नों से त्रुटियां नहीं, बल्कि खाली परिणाम मिलते हैं।
4. बहु-आयाम समर्थन: एक ही तार्किक संग्रह में कई भौतिक संग्रह (प्रत्येक आयाम के लिए एक) हो सकते हैं।

वास्तुकला

संग्रह नामकरण सम्मेलन

वेक्टर स्टोर संग्रह कई एम्बेडिंग आकारों का समर्थन करने के लिए आयाम प्रत्ययों का उपयोग करते हैं:

दस्तावेज़ एम्बेडिंग: क्यूड्रेंट: d_{user}_{collection}_{dimension} पाइनकोन: d-{user}-{collection}-{dimension} मिल्वस: doc_{user}_{collection}_{dimension}

ग्राफ एम्बेडिंग: क्यूड्रेंट: t_{user}_{collection}_{dimension} पाइनकोन: t-{user}-{collection}-{dimension} मिल्वस: entity_{user}_{collection}_{dimension}

उदाहरण: d_alice_papers_384 - 384-आयामी एम्बेडिंग वाले एलिस के पेपर संग्रह d_alice_papers_768 - 768-आयामी एम्बेडिंग वाले समान तार्किक संग्रह t_bob_knowledge_1536 - 1536-आयामी एम्बेडिंग वाले बॉब के ज्ञान ग्राफ

जीवनचक्र चरण

1. संग्रह निर्माण अनुरोध

अनुरोध प्रवाह:

User/System → Librarian → Storage Management Topic → Vector Stores

व्यवहार: लाइब्रेरियन create-collection अनुरोधों को सभी स्टोरेज बैकएंड्स को भेजता है। वेक्टर स्टोर प्रोसेसर अनुरोध को स्वीकार करते हैं लेकिन भौतिक संग्रह नहीं बनाते हैं। प्रतिक्रिया तुरंत सफलता के साथ वापस की जाती है। वास्तविक संग्रह निर्माण पहले लिखने तक स्थगित रहता है।

तर्क: निर्माण के समय आयाम अज्ञात होता है। गलत आयाम वाले संग्रह बनाने से बचा जाता है। संग्रह प्रबंधन तर्क को सरल बनाता है।

2. लेखन संचालन (आलसी निर्माण)

लेखन प्रवाह:

Data → Storage Processor → Check Collection → Create if Needed → Insert

व्यवहार:

1. वेक्टर से एम्बेडिंग आयाम निकालें: dim = len(vector)
2. आयाम प्रत्यय के साथ संग्रह का नाम बनाएं
3. जांचें कि क्या उस विशिष्ट आयाम के साथ कोई संग्रह मौजूद है
4. यदि मौजूद नहीं है: सही आयाम के साथ संग्रह बनाएं लॉग करें: "Lazily creating collection {name} with dimension {dim}"
5. एम्बेडिंग को आयाम-विशिष्ट संग्रह में डालें

उदाहरण परिदृश्य:

1. User creates collection "papers"
   → No physical collections created yet

2. First document with 384-dim embedding arrives
   → Creates d_user_papers_384
   → Inserts data

3. Second document with 768-dim embedding arrives
   → Creates d_user_papers_768
   → Inserts data

Result: Two physical collections for one logical collection

3. क्वेरी ऑपरेशन

क्वेरी प्रवाह:

Query Vector → Determine Dimension → Check Collection → Search or Return Empty

व्यवहार:

1. क्वेरी वेक्टर से आयाम निकालें: dim = len(vector)
2. आयाम प्रत्यय के साथ संग्रह नाम बनाएं
3. जांचें कि संग्रह मौजूद है या नहीं
4. यदि मौजूद है: समानता खोज करें परिणाम लौटाएं
5. यदि मौजूद नहीं है: लॉग करें: "Collection {name} does not exist, returning empty results" खाली सूची लौटाएं (कोई त्रुटि नहीं)

एक ही क्वेरी में कई आयाम: यदि क्वेरी में विभिन्न आयामों वाले वेक्टर हैं प्रत्येक आयाम अपने संबंधित संग्रह को क्वेरी करता है परिणाम एकत्रित किए जाते हैं गुम संग्रह को छोड़ दिया जाता है (त्रुटियों के रूप में नहीं माना जाता है)

तर्क: एक खाली संग्रह को क्वेरी करना एक वैध उपयोग मामला है खाली परिणाम लौटाना अर्थपूर्ण रूप से सही है सिस्टम स्टार्टअप के दौरान या डेटा इनपुट से पहले त्रुटियों से बचाता है

4. संग्रह हटाना

हटाने की प्रक्रिया:

Delete Request → List All Collections → Filter by Prefix → Delete All Matches

व्यवहार:

1. उपसर्ग पैटर्न का निर्माण करें: d_{user}_{collection}_ (अंतिम अंडरस्कोर पर ध्यान दें)
2. वेक्टर स्टोर में सभी संग्रहों की सूची बनाएं
3. उपसर्ग से मेल खाने वाले संग्रहों को फ़िल्टर करें
4. सभी मेल खाने वाले संग्रहों को हटाएं
5. प्रत्येक हटाने को लॉग करें: "Deleted collection {name}"
6. सारांश लॉग: "Deleted {count} collection(s) for {user}/{collection}"

उदाहरण:

Collections in store:
- d_alice_papers_384
- d_alice_papers_768
- d_alice_reports_384
- d_bob_papers_384

Delete "papers" for alice:
→ Deletes: d_alice_papers_384, d_alice_papers_768
→ Keeps: d_alice_reports_384, d_bob_papers_384

तर्क: सभी आयाम रूपों की पूरी तरह से सफाई सुनिश्चित करता है। पैटर्न मिलान से असंबंधित संग्रहों को गलती से हटाने से रोका जाता है। उपयोगकर्ता के दृष्टिकोण से परमाणु ऑपरेशन (सभी आयाम एक साथ हटा दिए जाते हैं)।

व्यवहार संबंधी विशेषताएं

सामान्य संचालन

संग्रह निर्माण: ✓ तुरंत सफलता देता है। ✓ कोई भौतिक भंडारण आवंटित नहीं किया जाता है। ✓ तेज़ ऑपरेशन (कोई बैकएंड I/O नहीं)।

पहला लेखन: ✓ सही आयाम के साथ संग्रह बनाता है। ✓ संग्रह निर्माण के ओवरहेड के कारण थोड़ा धीमा। ✓ उसी आयाम में बाद के लेखन तेज़ होते हैं।

किसी भी लेखन से पहले प्रश्न: ✓ खाली परिणाम देता है। ✓ कोई त्रुटि या अपवाद नहीं। ✓ सिस्टम स्थिर रहता है।

मिश्रित आयाम लेखन: ✓ स्वचालित रूप से प्रत्येक आयाम के लिए अलग-अलग संग्रह बनाता है। ✓ प्रत्येक आयाम अपने स्वयं के संग्रह में अलग-थलग होता है। ✓ कोई आयाम संघर्ष या स्कीमा त्रुटि नहीं होती है।

संग्रह हटाना: ✓ सभी आयाम रूपों को हटा देता है। ✓ पूर्ण सफाई। ✓ कोई अनाथ संग्रह नहीं।

विशेष स्थितियाँ

एकाधिक एम्बेडिंग मॉडल:

Scenario: User switches from model A (384-dim) to model B (768-dim)
Behavior:
- Both dimensions coexist in separate collections
- Old data (384-dim) remains queryable with 384-dim vectors
- New data (768-dim) queryable with 768-dim vectors
- Cross-dimension queries return results only for matching dimension

एक साथ प्रारंभिक लेखन:

Scenario: Multiple processes write to same collection simultaneously
Behavior:
- Each process checks for existence before creating
- Most vector stores handle concurrent creation gracefully
- If race condition occurs, second create is typically idempotent
- Final state: Collection exists and both writes succeed

आयाम प्रवासन:

Scenario: User wants to migrate from 384-dim to 768-dim embeddings
Behavior:
- No automatic migration
- Old collection (384-dim) persists
- New collection (768-dim) created on first new write
- Both dimensions remain accessible
- Manual deletion of old dimension collections possible

खाली संग्रह प्रश्नों:

Scenario: Query a collection that has never received data
Behavior:
- Collection doesn't exist (never created)
- Query returns empty list
- No error state
- System logs: "Collection does not exist, returning empty results"

कार्यान्वयन नोट्स

स्टोरेज बैकएंड विशिष्ट विवरण

Qdrant: अस्तित्व जांच के लिए collection_exists() का उपयोग करता है हटाने के दौरान लिस्टिंग के लिए get_collections() का उपयोग करता है संग्रह निर्माण के लिए VectorParams(size=dim, distance=Distance.COSINE) की आवश्यकता होती है

Pinecone: अस्तित्व जांच के लिए has_index() का उपयोग करता है हटाने के दौरान लिस्टिंग के लिए list_indexes() का उपयोग करता है इंडेक्स निर्माण के लिए "तैयार" स्थिति की प्रतीक्षा करने की आवश्यकता होती है सर्वरलेस विनिर्देश क्लाउड/क्षेत्र के साथ कॉन्फ़िगर किया गया है

Milvus: डायरेक्ट क्लासेस (DocVectors, EntityVectors) लाइफसाइकिल का प्रबंधन करती हैं प्रदर्शन के लिए आंतरिक कैश self.collections[(dim, user, collection)] संग्रह नामों को सैनिटाइज किया जाता है (केवल अल्फ़ान्यूमेरिक + अंडरस्कोर) ऑटो-इंक्रीमेंटिंग आईडी के साथ स्कीमा का समर्थन करता है

प्रदर्शन संबंधी विचार

पहली लेखन विलंबता: संग्रह निर्माण के कारण अतिरिक्त ओवरहेड Qdrant: ~100-500ms Pinecone: ~10-30 सेकंड (सर्वरलेस प्रावधान) Milvus: ~500-2000ms (इसमें इंडेक्सिंग शामिल है)

क्वेरी प्रदर्शन: अस्तित्व जांच से न्यूनतम ओवरहेड जुड़ता है (~1-10ms) एक बार संग्रह मौजूद होने पर कोई प्रदर्शन प्रभाव नहीं पड़ता है प्रत्येक आयाम संग्रह स्वतंत्र रूप से अनुकूलित है

स्टोरेज ओवरहेड: प्रति संग्रह न्यूनतम मेटाडेटा मुख्य ओवरहेड प्रति-आयाम स्टोरेज है ट्रेड-ऑफ: स्टोरेज स्पेस बनाम आयाम लचीलापन

भविष्य के विचार

स्वचालित आयाम समेकन: अप्रयुक्त आयाम वेरिएंट की पहचान और विलय करने के लिए एक पृष्ठभूमि प्रक्रिया जोड़ी जा सकती है इसके लिए पुनः एम्बेडिंग या आयाम में कमी की आवश्यकता होगी

आयाम खोज: एक संग्रह के लिए उपयोग किए जा रहे सभी आयामों को सूचीबद्ध करने के लिए एपीआई उजागर किया जा सकता है प्रशासन और निगरानी के लिए उपयोगी

डिफ़ॉल्ट आयाम प्राथमिकता: प्रति संग्रह "प्राथमिक" आयाम को ट्रैक किया जा सकता है जब आयाम संदर्भ अनुपलब्ध हो तो प्रश्नों के लिए इसका उपयोग करें

स्टोरेज कोटा: प्रति-संग्रह आयाम सीमाएं आवश्यक हो सकती हैं आयाम वेरिएंट के प्रसार को रोकें

माइग्रेशन नोट्स

प्री-डायमेंशन-सफिक्स सिस्टम से: पुराने संग्रह: d_{user}_{collection} (कोई आयाम प्रत्यय नहीं) नए संग्रह: d_{user}_{collection}_{dim} (आयाम प्रत्यय के साथ) कोई स्वचालित माइग्रेशन नहीं - पुराने संग्रह सुलभ रहते हैं यदि आवश्यक हो तो एक मैनुअल माइग्रेशन स्क्रिप्ट पर विचार करें दोनों नामकरण योजनाओं को एक साथ चलाया जा सकता है

संदर्भ

संग्रह प्रबंधन: docs/tech-specs/collection-management.md स्टोरेज स्कीमा: trustgraph-base/trustgraph/schema/services/storage.py लाइब्रेरियन सेवा: trustgraph-flow/trustgraph/librarian/service.py