mirror of
https://github.com/trustgraph-ai/trustgraph.git
synced 2026-04-25 08:26:21 +02:00
8954fa3ad7
Native CLI i18n: The TrustGraph CLI has built-in translation support that dynamically loads language strings. You can test and use different languages by simply passing the --lang flag (e.g., --lang es for Spanish, --lang ru for Russian) or by configuring your environment's LANG variable. Automated Docs Translations: This PR introduces autonomously translated Markdown documentation into several target languages, including Spanish, Swahili, Portuguese, Turkish, Hindi, Hebrew, Arabic, Simplified Chinese, and Russian.
410 lines
45 KiB
Markdown
410 lines
45 KiB
Markdown
---
|
|
layout: default
|
|
title: "संग्रह प्रबंधन तकनीकी विनिर्देश"
|
|
parent: "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.
|
|
|
|
## अवलोकन
|
|
|
|
यह विनिर्देश ट्रस्टग्राफ के लिए संग्रह प्रबंधन क्षमताओं का वर्णन करता है, जिसमें स्पष्ट संग्रह निर्माण की आवश्यकता होती है और संग्रह जीवनचक्र पर प्रत्यक्ष नियंत्रण प्रदान किया जाता है। उपयोग से पहले संग्रहों को स्पष्ट रूप से बनाया जाना चाहिए, जिससे लाइब्रेरियन मेटाडेटा और सभी स्टोरेज बैकएंड के बीच उचित सिंक्रोनाइज़ेशन सुनिश्चित हो सके। यह सुविधा चार प्राथमिक उपयोग मामलों का समर्थन करती है:
|
|
|
|
1. **संग्रह निर्माण**: डेटा संग्रहीत करने से पहले स्पष्ट रूप से संग्रह बनाएं
|
|
2. **संग्रह सूची**: सिस्टम में सभी मौजूदा संग्रह देखें
|
|
3. **संग्रह मेटाडेटा प्रबंधन**: संग्रह नामों, विवरणों और टैगों को अपडेट करें
|
|
4. **संग्रह विलोपन**: संग्रह और उनके संबंधित डेटा को सभी स्टोरेज प्रकारों से हटा दें
|
|
|
|
## लक्ष्य
|
|
|
|
**स्पष्ट संग्रह निर्माण**: डेटा संग्रहीत करने से पहले संग्रह बनाए जाने की आवश्यकता होती है
|
|
**स्टोरेज सिंक्रोनाइज़ेशन**: सुनिश्चित करें कि संग्रह सभी स्टोरेज बैकएंड (वेक्टर, ऑब्जेक्ट, ट्रिपल) में मौजूद हैं
|
|
**संग्रह दृश्यता**: उपयोगकर्ताओं को अपने वातावरण में सभी संग्रहों को सूचीबद्ध और निरीक्षण करने में सक्षम करें
|
|
**संग्रह सफाई**: अब आवश्यक नहीं होने वाले संग्रहों को हटाने की अनुमति दें
|
|
**संग्रह संगठन**: बेहतर संग्रह ट्रैकिंग और खोज के लिए लेबल और टैग का समर्थन करें
|
|
**मेटाडेटा प्रबंधन**: परिचालन स्पष्टता के लिए संग्रहों के साथ सार्थक मेटाडेटा संबद्ध करें
|
|
**संग्रह खोज**: फ़िल्टरिंग और खोज के माध्यम से विशिष्ट संग्रहों को खोजना आसान बनाएं
|
|
**परिचालन पारदर्शिता**: संग्रह जीवनचक्र और उपयोग में स्पष्ट दृश्यता प्रदान करें
|
|
**संसाधन प्रबंधन**: अप्रयुक्त संग्रहों को साफ करके संसाधन उपयोग को अनुकूलित करें
|
|
**डेटा अखंडता**: स्टोरेज में मेटाडेटा ट्रैकिंग के बिना अनाथ संग्रहों को रोकें
|
|
|
|
## पृष्ठभूमि
|
|
|
|
पहले, ट्रस्टग्राफ में संग्रह डेटा लोडिंग कार्यों के दौरान निहित रूप से बनाए जाते थे, जिससे सिंक्रोनाइज़ेशन संबंधी समस्याएं होती थीं, जहाँ संग्रह स्टोरेज बैकएंड में मौजूद हो सकते थे लेकिन लाइब्रेरियन में संबंधित मेटाडेटा नहीं होता था। इससे प्रबंधन में चुनौतियां और संभावित अनाथ डेटा उत्पन्न होता था।
|
|
|
|
स्पष्ट संग्रह निर्माण मॉडल इन मुद्दों को संबोधित करता है:
|
|
`tg-set-collection` के माध्यम से उपयोग से पहले संग्रह बनाने की आवश्यकता होती है
|
|
सभी स्टोरेज बैकएंड में संग्रह निर्माण का प्रसारण
|
|
लाइब्रेरियन मेटाडेटा और स्टोरेज के बीच सिंक्रोनाइज़ स्थिति बनाए रखना
|
|
गैर-मौजूदा संग्रहों में लेखन को रोकना
|
|
स्पष्ट संग्रह जीवनचक्र प्रबंधन प्रदान करना
|
|
|
|
यह विनिर्देश स्पष्ट संग्रह प्रबंधन मॉडल को परिभाषित करता है। स्पष्ट संग्रह निर्माण की आवश्यकता करके, ट्रस्टग्राफ यह सुनिश्चित करता है:
|
|
संग्रह निर्माण से लाइब्रेरियन मेटाडेटा में ट्रैक किए जाते हैं
|
|
सभी स्टोरेज बैकएंड डेटा प्राप्त करने से पहले संग्रहों के बारे में जानते हैं
|
|
स्टोरेज में कोई अनाथ संग्रह नहीं है
|
|
संग्रह जीवनचक्र पर स्पष्ट परिचालन दृश्यता और नियंत्रण
|
|
गैर-मौजूदा संग्रहों को संदर्भित करने वाले कार्यों के लिए सुसंगत त्रुटि हैंडलिंग
|
|
|
|
## तकनीकी डिजाइन
|
|
|
|
### वास्तुकला
|
|
|
|
संग्रह प्रबंधन प्रणाली को मौजूदा ट्रस्टग्राफ बुनियादी ढांचे के भीतर लागू किया जाएगा:
|
|
|
|
1. **लाइब्रेरियन सेवा एकीकरण**
|
|
संग्रह प्रबंधन संचालन मौजूदा लाइब्रेरियन सेवा में जोड़े जाएंगे
|
|
किसी नई सेवा की आवश्यकता नहीं है - मौजूदा प्रमाणीकरण और एक्सेस पैटर्न का लाभ उठाता है
|
|
संग्रह सूची, विलोपन और मेटाडेटा प्रबंधन को संभालता है
|
|
|
|
मॉड्यूल: trustgraph-librarian
|
|
|
|
2. **कैसेंड्रा संग्रह मेटाडेटा तालिका**
|
|
मौजूदा लाइब्रेरियन कीस्पेस में एक नई तालिका
|
|
उपयोगकर्ता-स्कोप किए गए एक्सेस के साथ संग्रह मेटाडेटा संग्रहीत करता है
|
|
प्राथमिक कुंजी: उचित मल्टी-टेनेंसी के लिए (user_id, collection_id)
|
|
|
|
मॉड्यूल: trustgraph-librarian
|
|
|
|
3. **संग्रह प्रबंधन CLI**
|
|
संग्रह संचालन के लिए कमांड-लाइन इंटरफ़ेस
|
|
सूची, हटाएं, लेबल और टैग प्रबंधन कमांड प्रदान करता है
|
|
मौजूदा CLI फ्रेमवर्क के साथ एकीकृत
|
|
|
|
मॉड्यूल: trustgraph-cli
|
|
|
|
### डेटा मॉडल
|
|
|
|
#### कैसेंड्रा संग्रह मेटाडेटा तालिका
|
|
|
|
संग्रह मेटाडेटा को लाइब्रेरियन कीस्पेस में एक संरचित कैसेंड्रा तालिका में संग्रहीत किया जाएगा:
|
|
|
|
```sql
|
|
CREATE TABLE collections (
|
|
user text,
|
|
collection text,
|
|
name text,
|
|
description text,
|
|
tags set<text>,
|
|
created_at timestamp,
|
|
updated_at timestamp,
|
|
PRIMARY KEY (user, collection)
|
|
);
|
|
```
|
|
|
|
तालिका संरचना:
|
|
**user**: **collection**: समग्र प्राथमिक कुंजी जो उपयोगकर्ता अलगाव सुनिश्चित करती है
|
|
**name**: संग्रह का मानव-पठनीय नाम
|
|
**description**: संग्रह के उद्देश्य का विस्तृत विवरण
|
|
**tags**: वर्गीकरण और फ़िल्टरिंग के लिए टैग का सेट
|
|
**created_at**: संग्रह निर्माण का टाइमस्टैम्प
|
|
**updated_at**: अंतिम संशोधन टाइमस्टैम्प
|
|
|
|
यह दृष्टिकोण अनुमति देता है:
|
|
उपयोगकर्ता अलगाव के साथ बहु-किरायेदार संग्रह प्रबंधन
|
|
उपयोगकर्ता और संग्रह द्वारा कुशल क्वेरी
|
|
संगठन के लिए लचीला टैगिंग सिस्टम
|
|
परिचालन अंतर्दृष्टि के लिए जीवनचक्र ट्रैकिंग
|
|
|
|
#### संग्रह जीवनचक्र
|
|
|
|
डेटा संचालन शुरू करने से पहले संग्रह को स्पष्ट रूप से लाइब्रेरियन में बनाया जाना चाहिए:
|
|
|
|
1. **संग्रह निर्माण** (दो रास्ते):
|
|
|
|
**रास्ता A: उपयोगकर्ता-आरंभित निर्माण** `tg-set-collection` के माध्यम से:
|
|
उपयोगकर्ता संग्रह आईडी, नाम, विवरण और टैग प्रदान करता है
|
|
लाइब्रेरियन `collections` तालिका में मेटाडेटा रिकॉर्ड बनाता है
|
|
लाइब्रेरियन सभी स्टोरेज बैकएंड पर "create-collection" प्रसारित करता है
|
|
सभी स्टोरेज प्रोसेसर संग्रह बनाते हैं और सफलता की पुष्टि करते हैं
|
|
संग्रह अब डेटा संचालन के लिए तैयार है
|
|
|
|
**रास्ता B: दस्तावेज़ सबमिशन पर स्वचालित निर्माण**:
|
|
उपयोगकर्ता एक संग्रह आईडी निर्दिष्ट करते हुए एक दस्तावेज़ सबमिट करता है
|
|
लाइब्रेरियन जांचता है कि क्या संग्रह मेटाडेटा तालिका में मौजूद है
|
|
यदि मौजूद नहीं है: लाइब्रेरियन डिफ़ॉल्ट के साथ मेटाडेटा बनाता है (नाम = संग्रह_आईडी, खाली विवरण/टैग)
|
|
लाइब्रेरियन सभी स्टोरेज बैकएंड पर "create-collection" प्रसारित करता है
|
|
सभी स्टोरेज प्रोसेसर संग्रह बनाते हैं और सफलता की पुष्टि करते हैं
|
|
दस्तावेज़ प्रसंस्करण संग्रह स्थापित होने के साथ आगे बढ़ता है
|
|
|
|
दोनों रास्ते यह सुनिश्चित करते हैं कि संग्रह लाइब्रेरियन मेटाडेटा में और सभी स्टोरेज बैकएंड में मौजूद है, डेटा संचालन से पहले।
|
|
|
|
2. **भंडारण सत्यापन**: लेखन संचालन संग्रह के अस्तित्व को मान्य करते हैं:
|
|
स्टोरेज प्रोसेसर लेखन स्वीकार करने से पहले संग्रह की स्थिति की जांच करते हैं
|
|
गैर-मौजूदा संग्रह में लेखन त्रुटि लौटाते हैं
|
|
यह लाइब्रेरियन के संग्रह निर्माण तर्क को बायपास करने वाले सीधे लेखन को रोकता है
|
|
|
|
3. **क्वेरी व्यवहार**: क्वेरी संचालन गैर-मौजूदा संग्रह को सुचारू रूप से संभालते हैं:
|
|
गैर-मौजूदा संग्रह में क्वेरी खाली परिणाम लौटाती है
|
|
कोई त्रुटि नहीं फेंकी जाती है क्वेरी संचालन के लिए
|
|
संग्रह के मौजूद होने की आवश्यकता के बिना अन्वेषण की अनुमति देता है
|
|
|
|
4. **मेटाडेटा अपडेट**: उपयोगकर्ता निर्माण के बाद संग्रह मेटाडेटा को अपडेट कर सकते हैं:
|
|
`tg-set-collection` के माध्यम से नाम, विवरण और टैग अपडेट करें
|
|
अपडेट केवल लाइब्रेरियन मेटाडेटा पर लागू होते हैं
|
|
स्टोरेज बैकएंड संग्रह बनाए रखते हैं लेकिन मेटाडेटा अपडेट प्रसारित नहीं होते हैं
|
|
|
|
5. **स्पष्ट विलोपन**: उपयोगकर्ता `tg-delete-collection` के माध्यम से संग्रह को हटाते हैं:
|
|
लाइब्रेरियन सभी स्टोरेज बैकएंड पर "delete-collection" प्रसारित करता है
|
|
सभी स्टोरेज प्रोसेसर से पुष्टिकरण की प्रतीक्षा करता है
|
|
केवल स्टोरेज क्लीनअप पूरा होने के बाद लाइब्रेरियन मेटाडेटा रिकॉर्ड को हटाता है
|
|
यह सुनिश्चित करता है कि कोई भी डेटा स्टोरेज में नहीं बचा है
|
|
|
|
**मुख्य सिद्धांत**: लाइब्रेरियन संग्रह निर्माण के लिए एकल नियंत्रण बिंदु है। चाहे उपयोगकर्ता कमांड द्वारा शुरू किया गया हो या दस्तावेज़ सबमिशन द्वारा, लाइब्रेरियन डेटा संचालन की अनुमति देने से पहले उचित मेटाडेटा ट्रैकिंग और स्टोरेज बैकएंड सिंक्रोनाइज़ेशन सुनिश्चित करता है।
|
|
|
|
आवश्यक संचालन:
|
|
**संग्रह बनाएं**: `tg-set-collection` के माध्यम से उपयोगकर्ता ऑपरेशन या दस्तावेज़ सबमिशन पर स्वचालित
|
|
**संग्रह मेटाडेटा अपडेट करें**: नाम, विवरण और टैग को संशोधित करने के लिए उपयोगकर्ता ऑपरेशन
|
|
**संग्रह हटाएं**: सभी स्टोर में संग्रह और उसके डेटा को हटाने के लिए उपयोगकर्ता ऑपरेशन
|
|
**संग्रह सूचीबद्ध करें**: टैग द्वारा फ़िल्टर करके संग्रह देखने के लिए उपयोगकर्ता ऑपरेशन
|
|
|
|
#### मल्टी-स्टोर संग्रह प्रबंधन
|
|
|
|
संग्रह ट्रस्टग्राफ में कई स्टोरेज बैकएंड में मौजूद हैं:
|
|
**वेक्टर स्टोर** (Qdrant, Milvus, Pinecone): एम्बेडिंग और वेक्टर डेटा संग्रहीत करें
|
|
**ऑब्जेक्ट स्टोर** (Cassandra): दस्तावेज़ और फ़ाइल डेटा संग्रहीत करें
|
|
**ट्रिपल स्टोर** (Cassandra, Neo4j, Memgraph, FalkorDB): ग्राफ/RDF डेटा संग्रहीत करें
|
|
|
|
प्रत्येक स्टोर प्रकार निम्नलिखित लागू करता है:
|
|
**संग्रह स्थिति ट्रैकिंग**: यह जानकारी बनाए रखें कि कौन से संग्रह मौजूद हैं
|
|
**संग्रह निर्माण**: "संग्रह बनाएं" संचालन स्वीकार करें और संसाधित करें
|
|
**संग्रह सत्यापन**: लिखने को स्वीकार करने से पहले जांचें कि संग्रह मौजूद है या नहीं
|
|
**संग्रह विलोपन**: निर्दिष्ट संग्रह के लिए सभी डेटा हटाएं
|
|
|
|
लाइब्रेरियन सेवा सभी स्टोर प्रकारों में संग्रह संचालन का समन्वय करती है, यह सुनिश्चित करते हुए:
|
|
सभी बैकएंड में संग्रह का निर्माण उपयोग से पहले किया जाता है
|
|
सभी बैकएंड निर्माण की पुष्टि करते हैं इससे पहले कि सफलता वापस की जाए
|
|
भंडारण प्रकारों में संग्रह जीवनचक्र का सिंक्रनाइज़ेशन
|
|
जब संग्रह मौजूद नहीं होते हैं तो सुसंगत त्रुटि हैंडलिंग
|
|
|
|
#### संग्रहण स्थिति ट्रैकिंग, संग्रहण प्रकार द्वारा
|
|
|
|
प्रत्येक संग्रहण बैकएंड अपनी क्षमताओं के आधार पर संग्रह स्थिति को अलग-अलग तरीके से ट्रैक करता है:
|
|
|
|
**कैसेंड्रा ट्रिपल स्टोर:**
|
|
मौजूदा `triples_collection` तालिका का उपयोग करता है
|
|
संग्रह बनने पर सिस्टम मार्कर ट्रिपल बनाता है
|
|
क्वेरी: `SELECT collection FROM triples_collection WHERE collection = ? LIMIT 1`
|
|
संग्रह के अस्तित्व की जांच के लिए कुशल सिंगल-पार्टिशन चेक
|
|
|
|
**Qdrant/Milvus/Pinecone वेक्टर स्टोर:**
|
|
मूल संग्रह एपीआई अस्तित्व जांच प्रदान करते हैं
|
|
उचित वेक्टर कॉन्फ़िगरेशन के साथ संग्रह बनाए जाते हैं
|
|
`collection_exists()` विधि संग्रहण एपीआई का उपयोग करती है
|
|
संग्रह निर्माण आयाम आवश्यकताओं को मान्य करता है
|
|
|
|
**Neo4j/Memgraph/FalkorDB ग्राफ स्टोर:**
|
|
संग्रह को ट्रैक करने के लिए `:CollectionMetadata` नोड्स का उपयोग करें
|
|
नोड गुण: `{user, collection, created_at}`
|
|
क्वेरी: `MATCH (c:CollectionMetadata {user: $user, collection: $collection})`
|
|
डेटा नोड्स से अलग, स्पष्ट अलगाव के लिए
|
|
कुशल संग्रह लिस्टिंग और सत्यापन को सक्षम करता है
|
|
|
|
**कैसेंड्रा ऑब्जेक्ट स्टोर:**
|
|
संग्रह मेटाडेटा तालिका या मार्कर पंक्तियों का उपयोग करता है
|
|
ट्रिपल स्टोर के समान पैटर्न
|
|
दस्तावेज़ लेखन से पहले संग्रह को मान्य करता है
|
|
|
|
### एपीआई
|
|
|
|
संग्रह प्रबंधन एपीआई (लाइब्रेरियन):
|
|
**संग्रह बनाएं/अपडेट करें**: `tg-set-collection` के माध्यम से एक नया संग्रह बनाएं या मौजूदा मेटाडेटा को अपडेट करें
|
|
**संग्रह सूचीबद्ध करें**: वैकल्पिक टैग फ़िल्टरिंग के साथ एक उपयोगकर्ता के लिए संग्रह पुनर्प्राप्त करें
|
|
**संग्रह हटाएं**: संग्रह और उससे जुड़े डेटा को हटाएं, सभी स्टोर प्रकारों में कैस्केड करें
|
|
|
|
संग्रहण प्रबंधन एपीआई (सभी संग्रहण प्रोसेसर):
|
|
**संग्रह बनाएं**: "संग्रह बनाएं" ऑपरेशन को संभालें, संग्रहण में संग्रह स्थापित करें
|
|
**संग्रह हटाएं**: "संग्रह हटाएं" ऑपरेशन को संभालें, सभी संग्रह डेटा को हटाएं
|
|
**संग्रह मौजूद है जांच**: लेखन संचालन को स्वीकार करने से पहले आंतरिक सत्यापन
|
|
|
|
डेटा ऑपरेशन एपीआई (संशोधित व्यवहार):
|
|
**लिखने एपीआई**: डेटा स्वीकार करने से पहले जांचें कि संग्रह मौजूद है या नहीं, यदि नहीं तो त्रुटि लौटाएं
|
|
**क्वेरी एपीआई**: त्रुटि के बिना गैर-मौजूद संग्रह के लिए खाली परिणाम लौटाएं
|
|
|
|
### कार्यान्वयन विवरण
|
|
|
|
कार्यान्वयन सेवा एकीकरण और CLI कमांड संरचना के लिए मौजूदा ट्रस्टग्राफ पैटर्न का पालन करेगा।
|
|
|
|
#### संग्रह विलोपन कैस्केड
|
|
|
|
जब कोई उपयोगकर्ता लाइब्रेरियन सेवा के माध्यम से संग्रह विलोपन शुरू करता है:
|
|
|
|
1. **मेटाडेटा सत्यापन**: सत्यापित करें कि संग्रह मौजूद है और उपयोगकर्ता के पास हटाने की अनुमति है
|
|
2. **स्टोर कैस्केड**: लाइब्रेरियन सभी स्टोर लेखकों में विलोपन का समन्वय करता है:
|
|
वेक्टर स्टोर लेखक: उपयोगकर्ता और संग्रह के लिए एम्बेडिंग और वेक्टर इंडेक्स हटाएं
|
|
ऑब्जेक्ट स्टोर लेखक: उपयोगकर्ता और संग्रह के लिए दस्तावेज़ और फ़ाइलें हटाएं
|
|
ट्रिपल स्टोर लेखक: उपयोगकर्ता और संग्रह के लिए ग्राफ डेटा और ट्रिपल हटाएं
|
|
3. **मेटाडेटा सफाई**: कैसेंड्रा से संग्रह मेटाडेटा रिकॉर्ड हटाएं
|
|
4. **त्रुटि हैंडलिंग**: यदि किसी भी स्टोर विलोपन में विफलता होती है, तो रोलबैक या पुनः प्रयास तंत्र के माध्यम से स्थिरता बनाए रखें
|
|
|
|
#### संग्रह प्रबंधन इंटरफ़ेस
|
|
|
|
⚠️ लेगेसी अप्रोच - कॉन्फ़िग-आधारित पैटर्न द्वारा प्रतिस्थापित
|
|
|
|
नीचे वर्णित कतार-आधारित आर्किटेक्चर को `CollectionConfigHandler` का उपयोग करके एक कॉन्फ़िग-आधारित दृष्टिकोण से बदल दिया गया है। अब सभी संग्रहण बैकएंड समर्पित प्रबंधन कतारों के बजाय कॉन्फ़िग पुश संदेशों के माध्यम से संग्रह अपडेट प्राप्त करते हैं।
|
|
|
|
~~सभी स्टोर लेखक एक मानकीकृत संग्रह प्रबंधन इंटरफ़ेस को लागू करते हैं जिसमें एक सामान्य स्कीमा है:~~
|
|
|
|
~~**संदेश स्कीमा (`StorageManagementRequest`):~~
|
|
```json
|
|
{
|
|
"operation": "create-collection" | "delete-collection",
|
|
"user": "user123",
|
|
"collection": "documents-2024"
|
|
}
|
|
```
|
|
|
|
~~**क्यू आर्किटेक्चर:**~~
|
|
~~**वेक्टर स्टोर मैनेजमेंट क्यू** (`vector-storage-management`): वेक्टर/एम्बेडिंग स्टोर~~
|
|
~~**ऑब्जेक्ट स्टोर मैनेजमेंट क्यू** (`object-storage-management`): ऑब्जेक्ट/डॉक्यूमेंट स्टोर~~
|
|
~~**ट्रिपल स्टोर मैनेजमेंट क्यू** (`triples-storage-management`): ग्राफ/आरडीएफ स्टोर~~
|
|
~~**स्टोरेज रिस्पांस क्यू** (`storage-management-response`): सभी प्रतिक्रियाएं यहां भेजी जाती हैं~~
|
|
|
|
**वर्तमान कार्यान्वयन:**
|
|
|
|
सभी स्टोरेज बैकएंड अब `CollectionConfigHandler` का उपयोग करते हैं:
|
|
**कॉन्फ़िग पुश इंटीग्रेशन**: स्टोरेज सेवाएं कॉन्फ़िग पुश नोटिफिकेशन के लिए पंजीकरण करती हैं
|
|
**स्वचालित सिंक्रोनाइज़ेशन**: कॉन्फ़िग परिवर्तनों के आधार पर संग्रह बनाए/हटाए जाते हैं
|
|
**घोषणात्मक मॉडल**: संग्रह कॉन्फ़िग सेवा में परिभाषित हैं, बैकएंड मिलान के लिए सिंक्रोनाइज़ होते हैं
|
|
**कोई अनुरोध/प्रतिक्रिया नहीं**: समन्वय ओवरहेड और प्रतिक्रिया ट्रैकिंग को समाप्त करता है
|
|
**संग्रह स्थिति ट्रैकिंग**: `known_collections` कैश के माध्यम से बनाए रखा जाता है
|
|
**आइडेंपोटेंट ऑपरेशन**: एक ही कॉन्फ़िग को कई बार संसाधित करना सुरक्षित है
|
|
|
|
प्रत्येक स्टोरेज बैकएंड लागू करता है:
|
|
`create_collection(user: str, collection: str, metadata: dict)` - संग्रह संरचनाएं बनाएं
|
|
`delete_collection(user: str, collection: str)` - सभी संग्रह डेटा हटाएं
|
|
`collection_exists(user: str, collection: str) -> bool` - लिखने से पहले मान्य करें
|
|
|
|
#### कैसेंड्रा ट्रिपल स्टोर रीफैक्टर
|
|
|
|
इस कार्यान्वयन के हिस्से के रूप में, कैसेंड्रा ट्रिपल स्टोर को एक टेबल-प्रति-संग्रह मॉडल से एक एकीकृत टेबल मॉडल में रीफैक्टर किया जाएगा:
|
|
|
|
**वर्तमान आर्किटेक्चर:**
|
|
प्रति उपयोगकर्ता की स्पेस, प्रत्येक संग्रह के लिए अलग टेबल
|
|
स्कीमा: `(s, p, o)` with `PRIMARY KEY (s, p, o)`
|
|
टेबल नाम: उपयोगकर्ता संग्रह अलग-अलग कैसेंड्रा टेबल बन जाते हैं
|
|
|
|
**नया आर्किटेक्चर:**
|
|
प्रति उपयोगकर्ता की स्पेस, सभी संग्रहों के लिए एक सिंगल "ट्रिपल्स" टेबल
|
|
स्कीमा: `(collection, s, p, o)` with `PRIMARY KEY (collection, s, p, o)`
|
|
संग्रह विभाजन के माध्यम से संग्रह अलगाव
|
|
|
|
**आवश्यक परिवर्तन:**
|
|
|
|
1. **ट्रस्टग्राफ क्लास रीफैक्टर** (`trustgraph/direct/cassandra.py`):
|
|
कंस्ट्रक्टर से `table` पैरामीटर हटाएं, फिक्स्ड "ट्रिपल्स" टेबल का उपयोग करें
|
|
सभी विधियों में `collection` पैरामीटर जोड़ें
|
|
स्कीमा को संग्रह को पहले कॉलम के रूप में शामिल करने के लिए अपडेट करें
|
|
**इंडेक्स अपडेट**: सभी 8 क्वेरी पैटर्न का समर्थन करने के लिए नए इंडेक्स बनाए जाएंगे:
|
|
विषय-आधारित प्रश्नों के लिए `(s)` पर इंडेक्स
|
|
विधेय-आधारित प्रश्नों के लिए `(p)` पर इंडेक्स
|
|
ऑब्जेक्ट-आधारित प्रश्नों के लिए `(o)` पर इंडेक्स
|
|
ध्यान दें: कैसेंड्रा मल्टी-कॉलम सेकेंडरी इंडेक्स का समर्थन नहीं करता है, इसलिए ये सिंगल-कॉलम इंडेक्स हैं
|
|
|
|
**क्वेरी पैटर्न प्रदर्शन:**
|
|
✅ `get_all()` - `collection` पर विभाजन स्कैन
|
|
✅ `get_s(s)` - प्राथमिक कुंजी का कुशलतापूर्वक उपयोग करता है (`collection, s`)
|
|
✅ `get_p(p)` - `idx_p` का उपयोग `collection` फ़िल्टरिंग के साथ
|
|
✅ `get_o(o)` - `idx_o` का उपयोग `collection` फ़िल्टरिंग के साथ
|
|
✅ `get_sp(s, p)` - प्राथमिक कुंजी का कुशलतापूर्वक उपयोग करता है (`collection, s, p`)
|
|
⚠️ `get_po(p, o)` - `ALLOW FILTERING` की आवश्यकता है (या तो `idx_p` या `idx_o` प्लस फ़िल्टरिंग का उपयोग करता है)
|
|
✅ `get_os(o, s)` - `idx_o` का उपयोग अतिरिक्त फ़िल्टरिंग के साथ `s` पर
|
|
✅ `get_spo(s, p, o)` - पूरी प्राथमिक कुंजी का कुशलतापूर्वक उपयोग करता है
|
|
|
|
**ALLOW FILTERING पर नोट:** `get_po` क्वेरी पैटर्न को `ALLOW FILTERING` की आवश्यकता होती है क्योंकि इसे उपयुक्त कंपाउंड इंडेक्स के बिना विधेय और ऑब्जेक्ट बाधाओं दोनों की आवश्यकता होती है। यह स्वीकार्य है क्योंकि यह क्वेरी पैटर्न विशिष्ट ट्रिपल स्टोर उपयोग में विषय-आधारित प्रश्नों की तुलना में कम सामान्य है
|
|
|
|
2. **स्टोरेज राइटर अपडेट** (`trustgraph/storage/triples/cassandra/write.py`):
|
|
प्रति (उपयोगकर्ता, संग्रह) के बजाय प्रति उपयोगकर्ता सिंगल ट्रस्टग्राफ कनेक्शन बनाए रखें
|
|
सम्मिलित कार्यों में संग्रह पास करें
|
|
कम कनेक्शन के साथ बेहतर संसाधन उपयोग
|
|
|
|
3. **क्वेरी सर्विस अपडेट** (`trustgraph/query/triples/cassandra/service.py`):
|
|
प्रति उपयोगकर्ता सिंगल ट्रस्टग्राफ कनेक्शन
|
|
सभी क्वेरी कार्यों में संग्रह पास करें
|
|
संग्रह पैरामीटर के साथ समान क्वेरी लॉजिक बनाए रखें
|
|
|
|
**लाभ:**
|
|
**सरलीकृत संग्रह विलोपन:** सभी 4 तालिकाओं में `collection` विभाजन कुंजी का उपयोग करके हटाएं
|
|
**संसाधन दक्षता:** कम डेटाबेस कनेक्शन और टेबल ऑब्जेक्ट
|
|
**क्रॉस-संग्रह संचालन:** कई संग्रहों को कवर करने वाले संचालन को लागू करना आसान है
|
|
**संगत आर्किटेक्चर:** एकीकृत संग्रह मेटाडेटा दृष्टिकोण के साथ संरेखित
|
|
**संग्रह सत्यापन:** `triples_collection` टेबल के माध्यम से संग्रह अस्तित्व की जांच करना आसान है
|
|
|
|
संग्रह संचालन संभव होने पर परमाणु होंगे और उचित त्रुटि प्रबंधन और सत्यापन प्रदान करेंगे।
|
|
|
|
## सुरक्षा संबंधी विचार
|
|
|
|
संग्रह प्रबंधन कार्यों के लिए उचित प्राधिकरण की आवश्यकता होती है ताकि अनधिकृत पहुंच या संग्रहों के हटाने को रोका जा सके। पहुंच नियंत्रण मौजूदा ट्रस्टग्राफ सुरक्षा मॉडल के अनुरूप होगा।
|
|
|
|
## प्रदर्शन संबंधी विचार
|
|
|
|
बड़ी संख्या में संग्रहों वाले वातावरण में संग्रह सूची संचालन के लिए पेजिंग की आवश्यकता हो सकती है। सामान्य फ़िल्टरिंग पैटर्न के लिए मेटाडेटा प्रश्नों को अनुकूलित किया जाना चाहिए।
|
|
|
|
## परीक्षण रणनीति
|
|
|
|
व्यापक परीक्षण में शामिल होंगे:
|
|
संग्रह निर्माण वर्कफ़्लो का एंड-टू-एंड परीक्षण
|
|
स्टोरेज बैकएंड सिंक्रोनाइज़ेशन
|
|
गैर-मौजूदा संग्रहों के लिए लेखन सत्यापन
|
|
गैर-मौजूदा संग्रहों के लिए क्वेरी हैंडलिंग
|
|
सभी स्टोरों में संग्रह हटाने का क्रम
|
|
त्रुटि प्रबंधन और पुनर्प्राप्ति परिदृश्य
|
|
प्रत्येक स्टोरेज बैकएंड के लिए यूनिट परीक्षण
|
|
क्रॉस-स्टोर संचालन के लिए एकीकरण परीक्षण
|
|
|
|
## कार्यान्वयन स्थिति
|
|
|
|
### ✅ पूर्ण घटक
|
|
|
|
1. **लाइब्रेरियन संग्रह प्रबंधन सेवा** (`trustgraph-flow/trustgraph/librarian/collection_manager.py`)
|
|
संग्रह मेटाडेटा CRUD संचालन (सूची, अपडेट, हटाएं)
|
|
`LibraryTableStore` के माध्यम से कैसेंड्रा संग्रह मेटाडेटा तालिका एकीकरण
|
|
सभी स्टोरेज प्रकारों में संग्रह हटाने का समन्वय
|
|
उचित त्रुटि प्रबंधन के साथ एसिंक्रोनस अनुरोध/प्रतिक्रिया हैंडलिंग
|
|
|
|
2. **संग्रह मेटाडेटा स्कीमा** (`trustgraph-base/trustgraph/schema/services/collection.py`)
|
|
`CollectionManagementRequest` और `CollectionManagementResponse` स्कीमा
|
|
संग्रह रिकॉर्ड के लिए `CollectionMetadata` स्कीमा
|
|
संग्रह अनुरोध/प्रतिक्रिया कतार विषय परिभाषाएँ
|
|
|
|
3. **स्टोरेज प्रबंधन स्कीमा** (`trustgraph-base/trustgraph/schema/services/storage.py`)
|
|
`StorageManagementRequest` और `StorageManagementResponse` स्कीमा
|
|
स्टोरेज प्रबंधन कतार विषय परिभाषित
|
|
स्टोरेज-स्तरीय संग्रह संचालन के लिए संदेश प्रारूप
|
|
|
|
4. **कैसेंड्रा 4-टेबल स्कीमा** (`trustgraph-flow/trustgraph/direct/cassandra_kg.py`)
|
|
क्वेरी प्रदर्शन के लिए कंपाउंड पार्टीशन कुंजी
|
|
SPO प्रश्नों और हटाने ट्रैकिंग के लिए `triples_collection` तालिका
|
|
संग्रह हटाने को रीड-देन-डिलीट पैटर्न के साथ लागू किया गया
|
|
|
|
### ✅ कॉन्फ़िग-आधारित पैटर्न में माइग्रेशन - पूर्ण
|
|
|
|
**सभी स्टोरेज बैकएंड को कतार-आधारित पैटर्न से कॉन्फ़िग-आधारित `CollectionConfigHandler` पैटर्न में माइग्रेट किया गया है।**
|
|
|
|
माइग्रेशन पूर्ण:
|
|
✅ `trustgraph-flow/trustgraph/storage/triples/cassandra/write.py`
|
|
✅ `trustgraph-flow/trustgraph/storage/triples/neo4j/write.py`
|
|
✅ `trustgraph-flow/trustgraph/storage/triples/memgraph/write.py`
|
|
✅ `trustgraph-flow/trustgraph/storage/triples/falkordb/write.py`
|
|
✅ `trustgraph-flow/trustgraph/storage/doc_embeddings/qdrant/write.py`
|
|
✅ `trustgraph-flow/trustgraph/storage/graph_embeddings/qdrant/write.py`
|
|
✅ `trustgraph-flow/trustgraph/storage/doc_embeddings/milvus/write.py`
|
|
✅ `trustgraph-flow/trustgraph/storage/graph_embeddings/milvus/write.py`
|
|
✅ `trustgraph-flow/trustgraph/storage/doc_embeddings/pinecone/write.py`
|
|
✅ `trustgraph-flow/trustgraph/storage/graph_embeddings/pinecone/write.py`
|
|
✅ `trustgraph-flow/trustgraph/storage/objects/cassandra/write.py`
|
|
|
|
सभी बैकएंड अब:
|
|
`CollectionConfigHandler` से विरासत में मिला है
|
|
`self.register_config_handler(self.on_collection_config)` के माध्यम से कॉन्फ़िग पुश नोटिफिकेशन के लिए पंजीकरण करें
|
|
`create_collection(user, collection, metadata)` और `delete_collection(user, collection)` को लागू करें
|
|
लिखने से पहले `collection_exists(user, collection)` का उपयोग करके सत्यापन करें
|
|
कॉन्फ़िग सेवा परिवर्तनों के साथ स्वचालित रूप से सिंक करें
|
|
|
|
विरासत कतार-आधारित बुनियादी ढांचा हटाया गया:
|
|
✅ `StorageManagementRequest` और `StorageManagementResponse` स्कीमा हटाए गए
|
|
✅ स्टोरेज प्रबंधन कतार विषय परिभाषाएँ हटाई गईं
|
|
✅ सभी बैकएंड से स्टोरेज प्रबंधन उपभोक्ता/उत्पादक हटाए गए
|
|
✅ सभी बैकएंड से `on_storage_management` हैंडलर हटाए गए
|