mirror of
https://github.com/trustgraph-ai/trustgraph.git
synced 2026-07-11 06:12:11 +02:00
134 lines
No EOL
9.7 KiB
Markdown
134 lines
No EOL
9.7 KiB
Markdown
# Neo4j उपयोगकर्ता/संग्रह अलगाव समर्थन
|
|
|
|
## समस्या विवरण
|
|
|
|
Neo4j ट्रिपल भंडारण और क्वेरी कार्यान्वयन में वर्तमान में उपयोगकर्ता/संग्रह अलगाव का अभाव है, जिससे बहु-किरायेदारी सुरक्षा समस्या उत्पन्न होती है। सभी ट्रिपल एक ही ग्राफ स्पेस में संग्रहीत किए जाते हैं, बिना किसी तंत्र के जो उपयोगकर्ताओं को अन्य उपयोगकर्ताओं के डेटा तक पहुंचने या संग्रहों को मिलाने से रोके।
|
|
|
|
अन्य ट्रस्टग्राफ स्टोरेज बैकएंड के विपरीत:
|
|
- **कैसेंड्रा**: प्रत्येक उपयोगकर्ता के लिए अलग-अलग कीस्पेस और प्रत्येक संग्रह के लिए अलग-अलग टेबल का उपयोग करता है।
|
|
- **वेक्टर स्टोर** (मिलवस, क्यूड्रांट, पाइनकोन): संग्रह-विशिष्ट नेमस्पेस का उपयोग करते हैं।
|
|
- **Neo4j**: वर्तमान में सभी डेटा को एक ही ग्राफ में साझा करता है (सुरक्षा भेद्यता)।
|
|
|
|
## वर्तमान आर्किटेक्चर
|
|
|
|
### डेटा मॉडल
|
|
- **नोड**: `:Node` लेबल जिसमें `uri` प्रॉपर्टी है, `:Literal` लेबल जिसमें `value` प्रॉपर्टी है।
|
|
- **रिलेशनशिप**: `:Rel` लेबल जिसमें `uri` प्रॉपर्टी है।
|
|
- **इंडेक्स**: `Node.uri`, `Literal.value`, `Rel.uri`
|
|
|
|
### संदेश प्रवाह
|
|
- `Triples` संदेशों में `metadata.user` और `metadata.collection` फ़ील्ड होते हैं।
|
|
- स्टोरेज सेवा उपयोगकर्ता/संग्रह जानकारी प्राप्त करती है लेकिन उसे अनदेखा करती है।
|
|
- क्वेरी सेवा `TriplesQueryRequest` में `user` और `collection` की अपेक्षा करती है लेकिन उन्हें अनदेखा करती है।
|
|
|
|
### वर्तमान सुरक्षा समस्या
|
|
```cypher
|
|
# कोई भी उपयोगकर्ता किसी भी डेटा को क्वेरी कर सकता है - कोई अलगाव नहीं
|
|
MATCH (src:Node)-[rel:Rel]->(dest:Node)
|
|
RETURN src.uri, rel.uri, dest.uri
|
|
```
|
|
|
|
## प्रस्तावित समाधान: प्रॉपर्टी-आधारित फ़िल्टरिंग (अनुशंसित)
|
|
|
|
### अवलोकन
|
|
सभी नोड्स और रिलेशनशिप में `user` और `collection` प्रॉपर्टी जोड़ें, और फिर सभी ऑपरेशनों को इन प्रॉपर्टीज़ द्वारा फ़िल्टर करें। यह दृष्टिकोण मजबूत अलगाव प्रदान करता है, जबकि क्वेरी लचीलापन और पिछड़े अनुकूलता बनाए रखता है।
|
|
|
|
### डेटा मॉडल परिवर्तन
|
|
|
|
#### उन्नत नोड संरचना
|
|
```cypher
|
|
// नोड एंटिटीज
|
|
CREATE (n:Node {
|
|
uri: "http://example.com/entity1",
|
|
user: "john_doe",
|
|
collection: "production_v1"
|
|
})
|
|
|
|
// लिटरल एंटिटीज
|
|
CREATE (n:Literal {
|
|
value: "लिटरल वैल्यू",
|
|
user: "john_doe",
|
|
collection: "production_v1"
|
|
})
|
|
```
|
|
|
|
#### उन्नत रिलेशनशिप संरचना
|
|
```cypher
|
|
// उपयोगकर्ता/संग्रह प्रॉपर्टीज़ के साथ रिलेशनशिप
|
|
CREATE (src)-[:Rel {
|
|
uri: "http://example.com/predicate1",
|
|
user: "john_doe",
|
|
collection: "production_v1"
|
|
}]->(dest)
|
|
```
|
|
|
|
#### अद्यतित इंडेक्स
|
|
```cypher
|
|
// कुशल फ़िल्टरिंग के लिए कंपाउंड इंडेक्स
|
|
CREATE INDEX node_user_collection_uri FOR (n:Node) ON (n.user, n.collection, n.uri);
|
|
CREATE INDEX literal_user_collection_value FOR (n:Literal) ON (n.user, n.collection, n.value);
|
|
CREATE INDEX rel_user_collection_uri FOR ()-[r:Rel]-() ON (r.user, r.collection, r.uri);
|
|
|
|
// पिछड़े अनुकूलता के लिए मौजूदा इंडेक्स बनाए रखें (वैकल्पिक)
|
|
CREATE INDEX Node_uri FOR (n:Node) ON (n.uri);
|
|
CREATE INDEX Literal_value FOR (n:Literal) ON (n.value);
|
|
CREATE INDEX Rel_uri FOR ()-[r:Rel]-() ON (r.uri);
|
|
```
|
|
|
|
### कार्यान्वयन परिवर्तन
|
|
|
|
#### स्टोरेज सेवा (`write.py`)
|
|
|
|
**वर्तमान कोड:**
|
|
```python
|
|
# (कोड यहां)
|
|
```
|
|
|
|
**अद्यतित कोड:**
|
|
```python
|
|
# (अद्यतित कोड यहां)
|
|
```
|
|
|
|
#### क्वेरी सेवा (उदाहरण)
|
|
```cypher
|
|
# मौजूदा क्वेरी:
|
|
MATCH (n:Node) WHERE n.name = 'example'
|
|
|
|
# अद्यतित क्वेरी:
|
|
MATCH (n:Node) WHERE n.name = 'example' AND n.user = $user AND n.collection = $collection
|
|
```
|
|
|
|
### परफॉर्मेंस पर विचार
|
|
|
|
- कंपाउंड इंडेक्स का उपयोग करें।
|
|
- क्वेरी कैशिंग पर विचार करें।
|
|
- डेटा आकार और कनेक्शन पूल उपयोग की निगरानी करें।
|
|
|
|
### सुरक्षा और अनुपालन
|
|
|
|
- डेटा अलगाव गारंटी
|
|
- ऑडिट आवश्यकताएं
|
|
- अनुपालन विचार
|
|
|
|
### जोखिम और निवारण
|
|
|
|
| जोखिम | प्रभाव | संभावना | निवारण |
|
|
|------|--------|------------|------------|
|
|
| क्वेरी में उपयोगकर्ता/संग्रह फ़िल्टर गायब | उच्च | मध्यम | अनिवार्य सत्यापन, व्यापक परीक्षण |
|
|
| परफॉर्मेंस में गिरावट | मध्यम | निम्न | इंडेक्स अनुकूलन, क्वेरी प्रोफाइलिंग |
|
|
| माइग्रेशन डेटा भ्रष्टाचार | उच्च | निम्न | बैकअप रणनीति, रोलबैक प्रक्रियाएं |
|
|
| जटिल मल्टी-संग्रह क्वेरी | मध्यम | मध्यम | क्वेरी पैटर्न का दस्तावेजीकरण, उदाहरण प्रदान करें |
|
|
|
|
### सफलता मानदंड
|
|
|
|
1. सुरक्षा: उत्पादन में शून्य क्रॉस-उपयोगकर्ता डेटा एक्सेस
|
|
2. परफॉर्मेंस: अनफ़िल्टर किए गए क्वेरी की तुलना में <10% क्वेरी परफॉर्मेंस प्रभाव
|
|
3. माइग्रेशन: 100% मौजूदा डेटा बिना किसी नुकसान के सफलतापूर्वक माइग्रेट किया गया
|
|
4. उपयोगिता: सभी मौजूदा क्वेरी पैटर्न उपयोगकर्ता/संग्रह संदर्भ के साथ काम करते हैं
|
|
5. अनुपालन: उपयोगकर्ता/संग्रह डेटा एक्सेस का पूर्ण ऑडिट ट्रेल
|
|
|
|
## निष्कर्ष
|
|
|
|
प्रॉपर्टी-आधारित फ़िल्टरिंग दृष्टिकोण Neo4j में उपयोगकर्ता/संग्रह अलगाव जोड़ने के लिए सुरक्षा, परफॉर्मेंस और रखरखाव का सबसे अच्छा संतुलन प्रदान करता है। यह ट्रस्टग्राफ के मौजूदा बहु-किरायेदारी पैटर्न के साथ संरेखित होता है, जबकि ग्राफ क्वेरी और इंडेक्सिंग में Neo4j की ताकत का लाभ उठाता है।
|
|
|
|
यह समाधान यह सुनिश्चित करता है कि ट्रस्टग्राफ का Neo4j बैकएंड अन्य स्टोरेज बैकएंड के समान सुरक्षा मानकों को पूरा करे, डेटा अलगाव भेद्यताओं को रोकते हुए ग्राफ क्वेरी की लचीलापन और शक्ति को बनाए रखता है। |