NoSQL डेटा मॉडलिंगExplained

28 of 28 rows

पैटर्न↕	यह क्या है↕	किसके लिए उपयोग करें↕
Document
⤢Embedding	नेस्टेड सब-डॉक्युमेंट अलग-अलग टेबल की जगह एक ही पैरेंट डॉक्युमेंट के अंदर रहते हैं।	वे one-to-few रिश्ते जो साथ पढ़े जाते हैं। अपनी line items के साथ एक order। तीन पतों वाला एक user।
⤢Referencing	डेटा नहीं, एक foreign id स्टोर करें। इसे दूसरे read या $lookup से हल करें।	बड़ी, साझा या स्वतंत्र रूप से अपडेट होने वाली सब-एंटिटी। कई collections के बीच many-to-many लिंक।
⤢One-to-few	पैरेंट बच्चों की एक छोटी array embed करता है; पूरा सेट एक डॉक्युमेंट की तरह फिट और लोड होता है।	प्रोफ़ाइल पर कुछ फ़ोन नंबर या प्रेफ़रेंस। एक read पैरेंट और बच्चों को साथ लौटाता है।
⤢One-to-many	बच्चे अपने collection में रहते हैं; हर बच्चे के पास पैरेंट id होता है, या पैरेंट एक सीमित id array रखता है।	ऐसे सेट जो embed करने के लिए बहुत बड़े या बहुत स्वतंत्र हैं। पैरेंट id से बच्चों को query करें।
⤢One-to-squillions	बच्चा पैरेंट id स्टोर करता है; पैरेंट कभी बच्चों को list नहीं करता क्योंकि सेट असीमित है।	किसी host या user से जुड़े events, logs या votes। पैरेंट id से बच्चों को filter करें और paginate करें।
⤢Polymorphic document	अलग-अलग entity प्रकार के डॉक्युमेंट एक collection साझा करते हैं, और एक type फ़ील्ड से पहचाने जाते हैं।	कई तरह के पैरेंट से जुड़ी comments या notifications, सभी एक ही तरह query होती हैं।
⤢Outlier pattern	कुछ चरम entities को साझा आकार से अलग किया जाता है ताकि उनका आकार या ट्रैफ़िक बाकी को विकृत न करे।	सेलिब्रिटी अकाउंट, जिनकी follower सूचियाँ या काउंटर सामान्य डॉक्युमेंट से बड़े हो जाते।
⤢Document versioning	हर revision एक नया डॉक्युमेंट है — वही id और बढ़ता हुआ version नंबर; query सबसे नए को चुनती है।	audit trails और edit history, जहाँ पुराने revisions query करने योग्य बने रहते हैं।
⤢Computed pattern	व्युत्पन्न मान write के समय गणना करके उस डेटा के पास स्टोर किए जाते हैं जिनका वे सारांश हैं।	कुल, रेटिंग और top-N, जो वरना हर read पर एक aggregation चलाते।
Key-value और wide-column
⤢Single-table	DynamoDB डिज़ाइन शब्द: overloaded partition और sort keys का उपयोग करके कई entity प्रकारों को एक टेबल में समेटना।	बिना join के एक ही query में विविध प्रकार के items लाना।
⤢Overloaded key	एक key attribute कई entity प्रकारों की सेवा करता है, USER# या ORDER# जैसे prefixes से चिह्नित।	Single-table डिज़ाइन। संबंधित items को एक partition के नीचे समूहबद्ध करें और एक query में लाएँ।
⤢Partition + sort	partition key पंक्तियों को nodes पर फैलाता है; sort key हर partition को क्रमबद्ध करता है।	Cassandra और DynamoDB। Range scans, क्रमबद्ध logs, पदानुक्रमित composite keys।
⤢Composite sort key	कई attributes को एक delimiter वाले sort key में जोड़ें — country#region#city — ताकि prefix match पदानुक्रम में नीचे चल सके।	पदानुक्रम और multi-facet फ़िल्टर। एक क्रमबद्ध range query कई indexed lookups की जगह ले लेती है।
⤢Time bucketing	events को निश्चित विंडो में समूहबद्ध करें — घंटा, दिन, महीना — समर्पित partitions या टेबल के नीचे।	Metrics, logs और IoT telemetry। Partition आकार को सीमित करता है और ठंडा डेटा पुराना करता है।
⤢Denormalization	read-भारी फ़ील्ड को records में duplicate करें ताकि query कभी दूसरे lookup के पीछे न भागे।	Read-भारी workloads जहाँ eventual consistency स्वीकार्य है और storage सस्ता है।
⤢GSI / sparse index	एक secondary index ऐसे attribute पर बना होता है जो केवल कुछ items रखते हैं; इसके बिना वाले items index में कभी नहीं आते।	वैकल्पिक एक्सेस पथ। Sparse subset खोजें — खुले orders, अनशिप्ड items — बिना full scan के।
⤢Query-first modeling	पहले सटीक queries लिखें; टेबल layout उनसे निकलता है, entities या normal form से नहीं।	Cassandra और DynamoDB schema कार्य। हर query परिवार के लिए एक टेबल; डेटा मॉडल प्रश्न की नकल करता है।
⤢Scatter-gather anti-pattern	एक query को समानांतर में कई partitions या nodes को छूना पड़ता है क्योंकि कोई key प्रश्न से नहीं मिलता।	एक smell है जिसे डिज़ाइन से हटाना है, लक्ष्य नहीं। टेबल को दोबारा key करें ताकि सामान्य query एक partition पर आए।
⤢Fan-out on write vs read	कॉपियाँ write के समय हर पाठक के view में भेजी जाती हैं, या read के समय इकट्ठा करके merge की जाती हैं।	Feeds और timelines। छोटे audiences के लिए write-time fan-out, विशाल के लिए read-time।
⤢Materialized view	पहले से बनी query परिणाम जो अपनी टेबल की तरह स्टोर होता है, और base बदलने पर current रखा जाता है।	एक write पथ पर वैकल्पिक read आकार। वे queries भरता है जिनका base टेबल जवाब नहीं दे सकता।
Graph
⤢Adjacency list	हर edge एक पंक्ति या tuple है जो source node से target node की ओर इशारा करती है।	Graph और property stores। Friend-of-friend lookups, routing, recommendations।
⤢Edge document	हर रिश्ता अपने collection में एक डॉक्युमेंट है, जिसमें from और to ids और link attributes होते हैं।	Document stores में graphs। लिंक पर ही attributes — rating, role, timestamp।
⤢Nested sets	हर node एक depth-first walk से निकले left और right काउंटर रखता है; subtree अपने पैरेंट की range के अंदर रहता है।	Read-भारी trees। एक BETWEEN query एक subtree लौटाती है; inserts walk को दोबारा नंबर देते हैं।
⤢Closure table	एक समर्पित टेबल हर ancestor-to-descendant जोड़ी दर्ज करती है, depth zero पर हर node सहित।	किसी भी depth पर पूरी-शाखा की queries। सरल joins, भुगतान storage और maintenance में।
⤢Property graph vs RDF	Property graphs nodes और edges पर key-value attributes लगाते हैं; RDF सब कुछ subject-predicate-object triples के रूप में कहता है।	समृद्ध traversal के लिए property graphs (Neo4j); linked open data और ontology exchange के लिए RDF।
Vector
⤢Vector embedding	एक high-dimensional float array metadata के पास रहता है। एक ANN index निकटतम पड़ोसियों को ढूँढता है।	Semantic search, RAG retrieval, recommendations और unstructured content पर समानता।
⤢Chunking strategy	स्रोत डॉक्युमेंट विभाजित होते हैं — आकार, overlap या संरचना से — इससे पहले कि हर टुकड़ा अलग से embed हो।	RAG retrieval गुणवत्ता। Chunk आकार precision और recall के बीच सौदा करता है; overlap बँटे वाक्यों की रक्षा करता है।
⤢Hybrid search	Dense vector similarity keyword matching के साथ चलता है; दोनों ranked सूचियाँ एक परिणाम में fuse होती हैं।	ऐसी queries जिन्हें एक साथ सटीक शब्द और अर्थ चाहिए, ऊपर से metadata filters।