Amazon DynamoDB समझाया गया: विस्तार योग्य प्रणालियाँ बनाना

DynamoDB क्या है और टीमें इसे क्यों चुनती हैं

Amazon DynamoDB AWS की एक पूरी तरह प्रबंधित NoSQL डेटाबेस सेवा है, जो उन एप्लिकेशन्स के लिए डिज़ाइन की गई है जिन्हें लगभग किसी भी पैमाने पर लगातार कम-लेटेंसी रीड और राइट चाहिए। “पूरी तरह प्रबंधित” का मतलब है कि AWS इन्फ्रास्ट्रक्चर का काम—हार्डवेयर प्रोविज़निंग, रेप्लिकेशन, पैचिंग और कई ऑपरेशनल टास्क—हैंडल करता है, ताकि टीमें डेटाबेस सर्वरों को चलाने की बजाय फीचर्स पर ध्यान दे सकें।

मूल रूप से, DynamoDB डेटा को items (पंक्तियों) के रूप में tables के अंदर स्टोर करता है, लेकिन प्रत्येक item में लचीले attributes हो सकते हैं। डेटा मॉडल को सबसे अच्छा इस मिश्रण के रूप में समझा जा सकता है:

• Key-value: प्राथमिक कुंजी से किसी आइटम को जल्दी फ़ेच करना, जैसे किसी ID से रिकॉर्ड देखना।
• Document: नेस्टेड attributes (maps और lists) स्टोर करना, JSON जैसा, जो संबंधित फ़ील्ड्स के लिए उपयोगी है बिना कड़ाई से schema के।

टीमें DynamoDB तब चुनती हैं जब उन्हें प्रेडिक्टेबल परफॉर्मेंस और सरल ऑपरेशन्स चाहिए उन वर्कलोड्स के लिए जो रिलेशनल जॉइन में अच्छी तरह फ़िट नहीं होते। यह आमतौर पर माइक्रोसर्विसेज़ (प्रत्येक सर्विस अपना डेटा खुद रेखांकित करती है), बर्स्टरी ट्रैफ़िक वाले सर्वरलेस ऐप्स, और डेटा परिवर्तन पर रिएक्ट करने वाले इवेंट-ड्रिवन सिस्टम्स के लिए उपयोग किया जाता है।

यह पोस्ट बिल्डिंग ब्लॉक्स (टेबल्स, कीज़, और इंडेक्सेस), एक्सेस पैटर्न के आसपास मॉडलिंग (सिंगल-टेबल डिज़ाइन सहित), स्केलिंग और कैपेसिटी मोड कैसे काम करते हैं, और स्ट्रीमिंग के लिए व्यावहारिक पैटर्न — सब चर्चा करता है।

मुख्य अवधारणाएँ: टेबल्स, आइटम्स, और प्राइमरी कीज़

DynamoDB कुछ सरल बिल्डिंग ब्लॉक्स के इर्द-गिर्द व्यवस्थित है, लेकिन डिटेल्स मायने रखते हैं क्योंकि वे यह निर्धारित करते हैं कि आप डेटा कैसे मॉडल करेंगे और अनुरोध कितने तेज़ (और लागत-प्रभावी) होंगे।

टेबल्स, आइटम्स और एट्रिब्यूट्स

एक टेबल शीर्ष-स्तरीय कंटेनर है। टेबल में प्रत्येक रिकॉर्ड एक item होता है (रो की तरह), और प्रत्येक item कई attributes का सेट है (कॉलम्स की तरह)।

रिलेशनल डेटाबेस के विपरीत, एक ही टेबल के items को एक ही attributes साझा करने की ज़रूरत नहीं होती। एक आइटम में {status, total, customerId} हो सकता है, जबकि दूसरे में {status, shipmentTracking} — DynamoDB को फिक्स्ड स्कीमा की आवश्यकता नहीं होती।

प्राइमरी कीज़: सिंपल बनाम कम्पोजिट

हर item को एक प्राइमरी की द्वारा यूनिक रूप से पहचाना जाता है, और DynamoDB दो प्रकार सपोर्ट करता है:

• सिंपल प्राइमरी की (सिर्फ partition key): एक attribute हर आइटम को यूनिकली पहचानता है।
• कम्पोजिट प्राइमरी की (partition key + sort key): कई आइटम एक ही partition key साझा कर सकते हैं, जबकि sort key उन्हें अलग करती है और उस partition के भीतर ऑर्डर निर्धारित करती है।

प्रैक्टिस में, कम्पोजिट कीज़ “ग्रुप्ड” एक्सेस पैटर्न सक्षम करती हैं जैसे “एक ग्राहक के सभी ऑर्डर, नए पहले।”

Query बनाम Scan (ऊपर-स्तर)

Query प्राइमरी की (या किसी इंडेक्स की) द्वारा आइटम्स पढ़ता है। यह एक विशेष partition key को टार्गेट करता है और sort key रेंज के आधार पर फ़िल्टर कर सकता है—यह कुशल और वांछनीय पथ है।

Scan पूरी टेबल (या इंडेक्स) को वॉक करता है और फिर फ़िल्टर करता है। यह शुरू करने में आसान है, लेकिन बड़े पैमाने पर यह आमतौर पर धीमा और महंगा होता है।

ध्यान में रखने लायक सीमाएँ

कुछ सीमाएँ जो जल्दी महसूस होंगी:

• Max item size: 400 KB।
• Attribute types: scalars (string/number/binary/boolean/null), sets, lists, और maps।
• Key attributes scalar होना चाहिए (partition या sort keys के रूप में lists/maps नहीं हो सकते)।

ये मूल बातें आगे की सभी चर्चाओं के लिए आधार तय करती हैं: एक्सेस पैटर्न, इंडेक्सिंग विकल्प, और परफॉर्मेंस चरित्र।

DynamoDB का डेटा मॉडल: Key-Value और Document

DynamoDB को अक्सर key-value स्टोर और डॉक्युमेंट डेटाबेस दोनों के रूप में बताया जाता है। यह सटीक है, लेकिन यह समझना उपयोगी है कि रोज़मर्रा की डिज़ाइन में प्रत्येक का क्या मतलब होता है।

Key-value एक्सेस बनाम डॉक्युमेंट-स्टाइल आइटम्स

मूल रूप से आप कुंजी द्वारा डेटा पुनः प्राप्त करते हैं। प्राइमरी की वैल्यूज़ दें और DynamoDB एकल item लौटाता है। यह की-आधारित लुकअप वह है जो कई वर्कलोड्स के लिए प्रेडिक्टेबल, कम-लेटेंसी स्टोरेज देता है।

साथ ही, एक आइटम नेस्टेड attributes (maps और lists) रख सकता है, जिससे यह डॉक्युमेंट डेटाबेस जैसा महसूस होता है: आप बिना कड़े स्कीमा के संरचित पेलोड रख सकते हैं।

आइटम्स में हाइरार्किकल JSON-जैसी संरचनाएँ मॉडल करना

Items प्राकृतिक रूप से JSON-जैसी डाटा को मैप करते हैं:

• Maps ऑब्जेक्ट्स का प्रतिनिधित्व करते हैं (उदा., profile.name, profile.address)।
• Lists ऐरे का प्रतिनिधित्व करती हैं (उदा., recent actions, tags)।

यह तब अच्छा बैठता है जब एक एंटिटी आमतौर पर पूरे-पठित (read as a whole) होती है—जैसे user profile, शॉपिंग कार्ट, या configuration bundle।

कब डेनॉर्मलाइज़ करें (और क्यों यह सामान्य है)

DynamoDB सर्वर-साइड जॉइन्स सपोर्ट नहीं करता। अगर आपकी ऐप को “एक ऑर्डर और उसके लाइन आइटम्स और शिपिंग स्टेटस” एक ही पढ़ने के पाथ पर चाहिए, तो आप अक्सर denormalize करेंगे: कुछ attributes को कई आइटम्स में कॉपी करना, या छोटे सब-स्ट्रक्चर को सीधे किसी आइटम में एम्बेड करना।

रिलेशनल नॉर्मलाइज़ेशन के विरुद्ध ट्रेड-ऑफ़

डेनॉर्मलाइज़ेशन लिखने की जटिलता बढ़ाता है और अपडेट फैनोंड का कारण बन सकता है। इसका लाभ यह है कि रीड्स के लिए राउंड-ट्रिप्स कम होते हैं और रीड तेज़ होते हैं—अक्सर स्केलेबल सिस्टम्स में यही क्रिटिकल पाथ होता है।

Partition Key और Sort Key: एक्सेस पैटर्न के लिए डिज़ाइन

सबसे तेज़ DynamoDB क्वेरीज वे हैं जिन्हें आप “मुझे यह partition दो” (और वैकल्पिक रूप से “इस partition के भीतर यह रेंज दो”) के रूप में व्यक्त कर सकते हैं। इसलिए की चुनना मुख्य रूप से इस बारे में है कि आप डेटा को कैसे पढ़ते हैं, सिर्फ यह नहीं कि आप उसे कैसे स्टोर करते हैं।

Partition key: वितरण और प्रेडिक्टेबल रीड्स

partition key यह निर्धारित करता है कि कौन सा फिज़िकल partition एक आइटम स्टोर करेगा। DynamoDB इस वैल्यू को हैश करता है ताकि डेटा और ट्रैफ़िक फैल सके। अगर बहुत सारी रिक्वेस्ट्स कुछ ही partition key वैल्यूज़ पर केंद्रित हों, तो आप “हॉट” partitions बना सकते हैं और थ्रूपुट लिमिट्स से टकरा सकते हैं।

अच्छे partition keys:

• high cardinality होते हैं (कई अलग-अलग मान)
• किसी आम पहुँच पैटर्न से मेल खाते हैं (ताकि रीड्स डायरेक्ट हों, फ़िल्टर किए हुए नहीं)
• ऐसी वैल्यूज़ से बचें जो “लोकप्रिय” बन जाती हैं (उदा., एक कांस्टेंट जैसे "GLOBAL")

Sort key: रेंज क्वेरीज और समूहबद्ध एंटिटी

sort key के साथ, एक ही partition key साझा करने वाले आइटम्स साथ-साथ स्टोर होते हैं और sort key के अनुसार ऑर्डर्ड होते हैं। इससे कुशल रूप से ये संभव हो पाते हैं:

• रेंज क्वेरीज (BETWEEN, begins_with)
• टाइम-ऑर्डर्ड रीड्स (नए पहले रिवर्स स्कैन के साथ)
• एंटिटी ग्रुपिंग (एक ही partition key के तहत कई आइटम टाइप्स)

एक सामान्य पैटर्न है sort key बनाना, जैसे TYPE#id या TS#2025-12-22T10:00:00Z, ताकि कई क्वेरी शेप्स बिना अतिरिक्त टेबल्स के सपोर्ट हो सकें।

सामान्य एक्सेस पैटर्न को कीज़ में मैप करना

• Get by ID: PK = USER#<id> (सिंपल GetItem)
• List by user: PK = USER#<id>, SK begins_with ORDER# (या SK = CREATED_AT#...)
• Time-series ranges: PK = DEVICE#<id>, SK = TS#<timestamp> और BETWEEN का उपयोग समय विंडो के लिए

कीज़ का प्रदर्शन और स्केलेबिलिटी पर प्रभाव

अगर आपका partition key आपके उच्च-आयतन क्वेरीज के साथ मेल खाता है और समान रूप से वितरित होता है, तो आपको लगातार कम-लेटेंसी रीड और राइट मिलेंगे। अगर यह मेल नहीं खाता, तो आप स्कैन, फ़िल्टर, या अतिरिक्त इंडेक्सेस के साथ समझौता करेंगे—जो हर बार लागत बढ़ाते हैं और हॉट कीज़ के जोखिम को बढ़ाते हैं।

सेकंडरी इंडेक्सेज़: GSI और LSI की व्याख्या

सेकंडरी इंडेक्सेज़ DynamoDB को आपके टेबल की प्राइमरी की के अलावा विकल्पी क्वेरी पाथ देती हैं। हर बार जब कोई नया एक्सेस पैटर्न दिखाई दे, तब आप बेस टेबल को बदलने के बजाय एक इंडेक्स जोड़ सकते हैं जो उन्हीं आइटम्स को अलग तरीके से री-की करता है।

GSI बनाम LSI: अंतर क्या है?

Global Secondary Index (GSI) का अपना partition key (और वैकल्पिक sort key) होता है जो टेबल के अलग भी हो सकता है। यह “global” है क्योंकि यह सभी टेबल partitions में फैला होता है और इसे किसी भी समय जोड़ा या हटाया जा सकता है। जब आपको कोई नया एक्सेस पैटर्न चाहिए जो मौजूदा की डिज़ाइन में फिट नहीं बैठता—उदा., टेबल orderId से की गई हो और आप customerId द्वारा क्वेरी करना चाहें—तो GSI का उपयोग करें।

Local Secondary Index (LSI) बेस टेबल के साथ वही partition key साझा करता है लेकिन अलग sort key उपयोग करता है। LSI को टेबल बनाते समय परिभाषित करना होता है। ये तब उपयोगी हैं जब आप एक ही एंटिटी समूह (एक ही partition key) के भीतर कई sort ऑर्डर्स चाहें—जैसे ग्राहक के ऑर्डर्स को createdAt बनाम status द्वारा अलग-अलग खोजना।

Projection: इंडेक्स में क्या कॉपी होता है

Projection यह तय करता है कि इंडेक्स में कौन से attributes स्टोर किए जाते हैं:

• KEYS_ONLY: सबसे सस्ता स्टोरेज, लेकिन अक्सर आपको बेस टेबल से अतिरिक्त रीड की ज़रूरत पड़ेगी।
• INCLUDE: केवल वे attributes कॉपी करें जो आप आमतौर पर रिटर्न करते हैं।
• ALL: सरल लेकिन स्टोरेज और राइट कॉस्ट बढ़ा सकता है।

Write amplification (छिपा हुआ बिल)

बेस टेबल पर हर लिखावट एक या अधिक इंडेक्सेस पर भी लिखावट ट्रिगर कर सकती है। अधिक GSIs और विस्तृत projections लिखने की लागत और कैपेसिटी उपयोग बढ़ाते हैं। स्थिर एक्सेस पैटर्न के आसपास इंडेक्स प्लान करें और जहाँ संभव हो प्रोजेक्ट किए गए attributes को न्यूनतम रखें।

कैपेसिटी मोड्स और स्केलिंग व्यवहार

DynamoDB में स्केलिंग एक विकल्प के साथ शुरू होती है: On-Demand या Provisioned कैपेसिटी। दोनों बहुत उच्च थ्रूपुट तक पहुँच सकते हैं, लेकिन वे बदलते ट्रैफ़िक पर अलग तरह से व्यवहार करते हैं।

On-Demand बनाम Provisioned: कैसे चुनें

On-Demand सबसे सरल है: आप अनुरोध के लिए भुगतान करते हैं और DynamoDB स्वचालित रूप से परिवर्तनीय लोड को समायोजित करता है। यह अप्रत्याशित ट्रैफ़िक, शुरुआती-स्टेज उत्पादों, और स्पाइकी वर्कलोड्स के लिए उपयुक्त है जहाँ आप कैपेसिटी टार्गेट्स नहीं प्रबंधित करना चाहते।

Provisioned कैपेसिटी प्लानिंग है: आप पढ़ने और लिखने की थ्रूपुट निर्दिष्ट करते हैं (या ऑटो-स्केल करते हैं) और स्थिर उपयोग पर अधिक प्रेडिक्टेबल प्राइसिंग पाते हैं। यह अक्सर ज्ञात, स्थिर वर्कलोड्स के लिए सस्ता होता है और उन टीमों के लिए जो मांग का पूर्वानुमान लगा सकते हैं।

रीड/राइट कैपेसिटी व्यवहार में

Provisioned थ्रूपुट को मापा जाता है:

• RCUs (Read Capacity Units): लगभग एक strongly consistent रीड प्रति सेकंड तक 4 KB के लिए (या दो eventually consistent रीड्स)।
• WCUs (Write Capacity Units): लगभग एक राइट प्रति सेकंड तक 1 KB के लिए।

आपका आइटम साइज और एक्सेस पैटर्न वास्तविक लागत निर्धारित करते हैं: बड़े आइटम, स्ट्रोंग कंसिस्टेंसी, और स्कैन जल्दी से कैपेसिटी जला सकते हैं।

ऑटो स्केलिंग मूल बातें (और सीमाएँ)

ऑटो स्केलिंग उपयोगिता लक्ष्यों के आधार पर provisioned RCUs/WCUs को समायोजित करती है। यह धीरे बढ़ते विकास और प्रेडिक्टेबल चक्रों में मदद करता है, पर यह तात्कालिक नहीं है। अचानक स्पाइक्स अभी भी थ्रॉटल कर सकते हैं अगर कैपेसिटी तेज़ी से नहीं बढ़ती, और यह उस समस्या को ठीक नहीं कर सकता जहाँ ट्रैफ़िक एक हॉट partition key पर केंद्रित हो।

DAX: रीड-हेवी वर्कलोड्स के लिए कैशिंग

DynamoDB Accelerator (DAX) एक इन-मेमोरी कैश है जो रीड लेटेंसी घटा सकता है और दोहराए जाने वाले रीड्स को ऑफलोड कर सकता है (उदा., लोकप्रिय प्रोडक्ट पेजेस, session lookups, leaderboards)। यह उन मामलों में सबसे उपयोगी है जब कई क्लाइंट्स बार-बार वही आइटम्स अनुरोध करें; यह राइट-हेवी पैटर्न्स में मदद नहीं करेगा, और यह सावधान की डिज़ाइन का विकल्प नहीं है।

कंसिस्टेंसी, ट्रांज़ैक्शंस और सठिकता

DynamoDB आपको पढ़ने की गारंटी और लेटेंसी/लागत के बीच व्यापार करने देता है, इसलिए यह महत्वपूर्ण है कि आप हर ऑपरेशन के लिए “सही” का क्या मतलब है, स्पष्ट करें।

Eventually consistent बनाम strongly consistent रीड्स

डिफ़ॉल्ट रूप से, GetItem और Query eventually consistent रीड्स उपयोग करते हैं: आप लिखने के तुरंत बाद थोड़ी देर तक पुराना वैल्यू देख सकते हैं। यह अक्सर फ़ीड्स, प्रोडक्ट कैटलॉग्स, और अन्य रीड-मोस्टली दृश्य के लिए ठीक है।

strongly consistent रीड्स के साथ (एक रीजन में बेस टेबल से रीड्स के लिए विकल्प), DynamoDB गारंटी देता है कि आप लेटेस्ट acknowleged लिखावट देखें। स्ट्रॉन्ग कंसिस्टेंसी अधिक रीड कैपेसिटी खर्च करती है और टेल लेटेंसी बढ़ा सकती है, इसलिए इसे सिर्फ़ सचमुच क्रिटिकल रीड्स के लिए रखें।

कब स्ट्रॉन्ग कंसिस्टेंसी मायने रखती है

स्ट्रॉन्ग कंसिस्टेंसी उन रीड्स के लिए मूल्यवान है जो अपरिवर्तनीय क्रियाओं को नियंत्रित करते हैं:

• ऑर्डर पुष्टि से पहले उपलब्ध इन्वेंटरी की जाँच
• एक्सेस देने से पहले ऑथराइज़ेशन फ़्लैग पढ़ना
• अगले चरण को निष्पादित करने से पहले वर्कफ़्लो की वर्तमान स्थिति पढ़ना

काउंटर के लिए, सबसे सुरक्षित तरीका आमतौर पर “स्ट्रॉन्ग रीड फिर राइट” नहीं बल्कि एक atomic update (उदा., UpdateItem के साथ ADD) है ताकि increments खो न जाएँ।

ट्रांज़ैक्शनल रीड्स/राइट्स

DynamoDB ट्रांज़ैक्शंस (TransactWriteItems, TransactGetItems) ACID semantics प्रदान करते हैं और एक साथ 25 आइटम तक काम कर सकते हैं। ये तब उपयोगी हैं जब आपको कई आइटम एक साथ अपडेट करने हों—जैसे एक ऑर्डर लिखना और इन्वेंटरी रिज़र्व करना—या ऐसे इनवेरिएंट्स लागू करने हों जो मध्यवर्ती अवस्थाओं को बर्दाश्त न करें।

सुरक्षित retries के लिए Idempotency

रिट्राइज़ वितरण प्रणालियों में सामान्य हैं। लिखाइयों को idempotent बनाइए ताकि रिट्राइज़ प्रभावों को डुप्लिकेट न कर दे:

• एक client request token (idempotency key) का उपयोग करें और परिणाम के साथ संग्रहीत करें
• ConditionExpression के साथ यूनिकनेस लागू करें (उदा., “only create if attribute_not_exists”)
• पढ़-पर-लिखो लूप्स की बजाय atomic updates पसंद करें

DynamoDB में correctness ज्यादातर सही कंसिस्टेंसी स्तर चुनने और ऑपरेशंस को इस तरह डिजाइन करने के बारे में है कि रिट्राइज़ डेटा को बिगाड़ न सकें।

पार्टिशन्स, हॉट कीज़, और ट्रैफ़िक स्पाइक्स

DynamoDB टेबल डेटा को कई फिज़िकल पार्टिशन्स में स्टोर करता है। हर पार्टिशन की पढ़ने/लिखने की सीमित थ्रूपुट होती है, साथ ही उसके पास कितना डेटा रख सकता है उसकी सीमा भी होती है। आपका partition key तय करता है कि कोई आइटम कहां रहेगा; अगर बहुत सारी रिक्वेस्ट्स एक ही partition key वैल्यू (या थोड़े से वैल्यूज़) को लक्षित करें, तो वह पार्टिशन बॉटलनेक बन जाता है।

हॉट पार्टिशन्स क्यों होते हैं

हॉट पार्टिशन्स आमतौर पर उन की डिज़ाइनों से होते हैं जो ट्रैफ़िक को केंद्रीकृत करती हैं: एक “global” partition key जैसे USER#1, TENANT#default, या STATUS#OPEN, या टाइम-ऑर्डर्ड पैटर्न जहाँ हर कोई “अब” में लिखता है।

हॉट कीज़ और असमान ट्रैफ़िक के लक्षण

आम तौर पर आप देखेंगे:

• थ्रॉटलिंग (ProvisionedThroughputExceededException) कुछ कीज़ के लिए
• कुछ एक्सेस पैटर्न के लिए बढ़ी हुई और स्पाइकी लेटेंसी जबकि अन्य तेज़ बने रहते हैं
• CloudWatch मैट्रिक्स में असमान consumed capacity और अचानक बर्स्ट दिखना

निवारण तकनीकें

डिस्ट्रीब्यूशन को पहले डिज़ाइन करें, फिर क्वेरी सुविधा पर विचार करें:

• की डिज़ाइन: उच्च-कार्डिनैलिटी partition keys सुनिश्चित करें (उदा., TENANT#<id> को साझा कांस्टेंट के बजाय)
• Write sharding: छोटे रैंडम या हैश सुफिक्स/प्रिफिक्स जोड़ें जैसे ORDER#<id>#<shard> ताकि लिखाइयाँ N shards में फैली जा सकें, और जरूरत पड़ने पर shards पर क्वेरी करें
• Time buckets: घंटे/दिन द्वारा बकेट करें (METRIC#2025-12-22T10) ताकि “सभी लिखाइयाँ नवीनतम आइटम पर जाएँ” की समस्या न हो

बर्सटी वर्कलोड्स को हैंडल करना

अनअपेक्षित स्पाइक्स के लिए, on-demand कैपेसिटी बर्स्ट्स को (सर्विस सीमाओं के भीतर) समाहित कर सकती है। Provisioned मोड में, ऑटो-स्केलिंग का उपयोग करें और थ्रॉटल पर क्लाइंट-साइड exponential backoff with jitter लागू करें ताकि सिंक्रोनाइज़्ड रिट्राइज़ स्पाइक को बढ़ा न दें।

स्केलेबल सिस्टम्स के लिए डेटा मॉडलिंग पैटर्न

DynamoDB डेटा मॉडलिंग एक्सेस-पैटर्न्स से शुरू होती है, ER डायग्राम से नहीं। आप कीज़ इस तरह डिज़ाइन करते हैं कि जिन क्वेरीज की आपको ज़रूरत है वे तेज Query ऑपरेशंस बन जाएँ, जबकि बाकी या तो टाला जाए या असिंक्रोनस तरीके से संभाला जाए।

सिंगल-टेबल डिज़ाइन (और टीमें इसे क्यों पसंद करती हैं)

“सिंगल-टेबल डिज़ाइन” का मतलब है कई एंटिटी टाइप्स (users, orders, messages) को एक ही टेबल में स्टोर करना और संबंधित डेटा को एक ही Query में लाने के लिए सुसंगत की कन्वेंशन्स का उपयोग करना। इससे क्रॉस-एंटिटी राउंड-ट्रिप्स कम होते हैं और लेटेंसी प्रेडिक्टेबल रहती है।

एक सामान्य अप्रोच है कम्पोजिट कीज़ का उपयोग:

• PK एक तार्किक परत (उदा., USER#123) को समूहित करता है
• SK उस समूह के भीतर आइटम्स को क्रमबद्ध करता है (उदा., PROFILE, ORDER#2025-12-01, MSG#000123)

इससे आप “एक यूज़र के लिए सब कुछ” या “सिर्फ़ यूज़र के ऑर्डर्स” को sort-key प्रीफ़िक्स चुनकर फेच कर सकते हैं।

संबंध: adjacency lists और many-to-many

ग्राफ़-लाइक रिश्तों के लिए, adjacency list अच्छा काम करती है: edges को आइटम्स के रूप में स्टोर करें.

• PK = USER#123, SK = FOLLOWS#USER#456

रिवर्स लुकअप या सच्ची many-to-many सपोर्ट करने के लिए, एक inverted edge आइटम जोड़ें या पढ़ने के पाथ के आधार पर GSI में प्रोजेक्ट करें।

टाइम-सीरीज़: बकेट + sort key + TTL

इवेंट्स और मेट्रिक्स के लिए, अनबाउंडेड partitions से बचें:

• PK = DEVICE#9#2025-12-22 (डिवाइस + दिन)
• SK = TS#1734825600 (टाइमस्टैम्प)

पुराने पॉइंट्स को स्वतः समाप्त करने के लिए TTL का उपयोग करें, और डैशबोर्ड्स के लिए अलग आइटम्स में aggregates (hourly/daily rollups) रखें ताकि तेज़ डैशबोर्ड मिलें।

यदि आप कीज़ कन्वेंशन्स पर गहरा रिफ्रेश चाहते हैं, तो देखें /blog/partition-key-and-sort-key-design.

Streams और इवेंट-ड्रिवन आर्किटेक्चर

DynamoDB Streams DynamoDB का बिल्ट-इन चेंज डेटा कैप्चर (CDC) फ़ीड है। जब किसी टेबल पर यह इनेबल होता है, तो हर insert, update, या delete एक स्ट्रीम रिकॉर्ड उत्पन्न करता है जिसे डाउनस्ट्रीम कंज्यूमर्स रिएक्ट कर सकते हैं—बिना टेबल को पोल किए।

DynamoDB Streams मूल बातें

एक स्ट्रीम रिकॉर्ड में कीज़ और (वैकल्पिक रूप से) आइटम का पुराना और/या नया इमेज होता है, जो कि आप जिस stream view type का चयन करते हैं उस पर निर्भर करता है (keys only, new image, old image, both)। रिकॉर्ड्स को shards में समूहित किया जाता है, जिन्हें आप अनुक्रमिक रूप से पढ़ते हैं।

इवेंट-ड्रिवन वर्कफ़्लोज़ बनाना

एक सामान्य सेटअप है DynamoDB Streams → AWS Lambda, जहाँ हर रिकॉर्ड बैच एक फ़ंक्शन को ट्रिगर करता है। अन्य कंज्यूमर्स भी संभव हैं (कस्टम कंज्यूमर्स, या एनालिटिक्स/लॉगिंग सिस्टम्स में पाइपिंग)।

आम वर्कफ़्लोज़ में शामिल हैं:

• Materialized views: स्रोत टेबल बदलने पर एक डेनॉर्मलाइज़्ड रीड-मॉडल टेबल लिखें।
• Cache invalidation: राइट्स के बाद Redis/ElastiCache में आइटम्स को समाप्त या रिफ्रेश करें।
• Audit logs: परिवर्तन घटनाओं को ऑडिट टेबल या बाहरी स्टोर में जोड़ें।

इससे प्राथमिक टेबल कम-लेटेंसी रीड/राइट के लिए अनुकूल रहती है और व्युत्पन्न काम असिंक्रोनस कंज्यूमर्स को सौंप दिया जाता है।

ऑर्डरिंग, रिट्राइज़, और सठिकता

Streams प्रति शार्ड अनुक्रमित प्रोसेसिंग प्रदान करते हैं (जो आम तौर पर partition key के साथ संबंधित होती है), पर सभी कीज़ के बीच कोई वैश्विक ऑर्डर नहीं होता। डिलीवरी at-least-once है, इसलिए डुप्लिकेट्स हो सकते हैं।

इसे सुरक्षित रूप से हैंडल करने के लिए:

• हेंडलर्स को idempotent बनाएं (उदा., key द्वारा upsert, conditional writes, या प्रोसेस किए गए ईवेंट IDs स्टोर करें)
• रिट्राइज़ और आंशिक बैच फ़ेल्यर्स की उम्मीद रखें; जहाँ संभव हो DLQs/on-failure destinations का उपयोग करें
• साइड-इफेक्ट्स (ईमेल, पेमेंट्स) के पीछे डुप्लिकेट-रोकथाम या ट्रांज़ैक्शनल सुरक्षा रखें

इन गारंटीज़ को ध्यान में रखकर, Streams DynamoDB को इवेंट-ड्रिवन सिस्टम्स के लिए एक मज़बूत रीढ़ बना सकते हैं।

विश्वसनीयता, बैकअप, और निगरानी

DynamoDB को उच्च उपलब्धता के लिए डिज़ाइन किया गया है, जो डेटा को एक रीजन के कई Availability Zones में फैलाता है। अधिकांश टीमों के लिए व्यावहारिक विश्वसनीयता लाभ स्पष्ट बैकअप रणनीति रखने, रेप्लिकेशन विकल्प समझने, और सही मेट्रिक्स मॉनिटर करने से आते हैं।

बैकअप: ऑन-डिमांड बनाम पॉइंट-इन-टाइम रिकवरी

On-demand backups मैन्युअल (या स्वचालित) स्नैपशॉट होते हैं जिन्हें आप किसी ज्ञात रीस्टोर पॉइंट के रूप में लेते हैं—माइग्रेशन से पहले, रिलीज के बाद, या बड़े बैकफिल से पहले। वे “बुकमार्क” क्षणों के लिए उपयुक्त हैं।

Point-in-time recovery (PITR) लगातार परिवर्तनों को कैप्चर करता है ताकि आप टेबल को रोकथाम विंडो के भीतर किसी भी सेकंड पर पुनर्स्थापित कर सकें। PITR आकस्मिक डिलीट्स, खराब डिप्लॉयस, या malformed writes के लिए एक सुरक्षा नेट है।

रेप्लिकेशन और मल्टी-रीजन विकल्प

यदि आपको मल्टी-रीजन रेजिलिएंस या उपयोगकर्ताओं के नज़दीक लो-लेटेंसी रीड्स चाहिए, तो Global Tables चयनित क्षेत्रों में डेटा की नकल करती हैं। ये फ़ेलओवर प्लानिंग को सरल बनाती हैं, पर क्रॉस-रीजन रेप्लिकेशन देरी और कॉन्फ़्लिक्ट-रिज़ॉल्यूशन विचार लाती हैं—इसलिए लिखने के पैटर्न और आइटम मालिकाना स्पष्ट रखें।

निगरानी के मूल ततत्त्व

न्यूनतम के रूप में, इन पर अलर्ट रखें:

• रीड्स और राइट्स के लिए लेटेंसी (p95/p99)
• थ्रॉटल्ड रिक्वेस्ट्स और सिस्टम एरर्स
• Consumed capacity (और provisioned के मुकाबले हेडरूम)

ये संकेत आम तौर पर हॉट-पार्टिशन समस्याओं, अपर्याप्त कैपेसिटी, या अप्रत्याशित एक्सेस पैटर्न को उजागर करते हैं।

घटना प्लेबुक्स

थ्रॉटलिंग के लिए, पहले वह एक्सेस पैटर्न पहचानें जो कारण बना रहा है, फिर अस्थायी रूप से on-demand में स्विच करें या provisioned कैपेसिटी बढ़ाएँ, और हॉट कीज़ शार्ड करने पर विचार करें।

आंशिक आउटेज या बढ़ी हुई त्रुटियों के लिए, ब्लास्ट रेडियस कम करें: गैर-आवश्यक ट्रैफ़िक अक्षम करें, jittered backoff के साथ रिट्राइज़ करें, और टेबल स्थिर होने तक विनम्र विफलता (उदा., cached reads सर्व करना) अपनाएँ।

सुरक्षा और एक्सेस कंट्रोल

DynamoDB सुरक्षा मुख्यतः इस बारे में है कि कौन किन API क्रियाओं को कॉल कर सकता है, कहाँ से, और किस कीज़ पर। क्योंकि एक टेबल कई एंटिटी टाइप्स (और कभी-कभी कई टेनेंट) रख सकती है, एक्सेस कंट्रोल को डेटा मॉडल के साथ-साथ डिज़ाइन करना चाहिए।

IAM permissions: सबसे कम आवश्यक अधिकार डिफ़ॉल्ट रखें

पहले identity-based IAM नीतियों के साथ शुरू करें जो क्रियाओं (उदा., dynamodb:GetItem, Query, PutItem) को न्यूनतम सेट तक सीमित करें और उन्हें विशिष्ट टेबल ARNs तक स्कोप करें।

और भी सूक्ष्म नियंत्रण के लिए dynamodb:LeadingKeys का उपयोग करें ताकि partition key वैल्यूज़ द्वारा एक्सेस को प्रतिबंधित किया जा सके—यह उपयोगी है जब किसी सर्विस या टेनेंट को केवल अपनी ही keyspace तक पहुँच होनी चाहिए।

एन्क्रिप्शन: क्या सत्यापित करना चाहिए

DynamoDB डिफ़ॉल्ट रूप से डेटा को रेस्ट पर एन्क्रिप्ट करता है AWS-owned keys या customer-managed KMS key के साथ। अगर आपकी अनुपालन आवश्यकताएँ हैं, तो सत्यापित करें:

• टेबल इच्छित KMS key के साथ कॉन्फ़िगर है
• कॉलिंग रोल के पास आवश्यक KMS अनुमतियाँ हैं (और कुछ भी अतिरिक्त नहीं)

ट्रांसिट में एन्क्रिप्शन के लिए, सुनिश्चित करें कि क्लाइंट्स HTTPS का उपयोग करते हैं (AWS SDKs डिफ़ॉल्ट रूप से ऐसा करते हैं)। अगर आप प्रॉक्सी में TLS समाप्त करते हैं, तो पुष्टि करें कि प्रॉक्सी और DynamoDB के बीच का हॉप भी एन्क्रिप्टेड है।

नेटवर्क नियंत्रण: एक्सफ़िल्ट्रेशन पाथ कम करें

DynamoDB के लिए VPC Gateway Endpoint का उपयोग करें ताकि ट्रैफ़िक AWS नेटवर्क पर रहे और आप endpoint policies लागू कर सकें ताकि पहुँच को सीमित किया जा सके। इसे egress controls (NACLs, security groups, और routing) के साथ जोड़े ताकि “कुछ भी पब्लिक इंटरनेट तक पहुँचता है” पाथों से बचा जा सके।

मल्टी-टेनेंट डिज़ाइन और अलगाव पैटर्न

शेयर की गयी टेबल्स के लिए, partition key में टेनेंट पहचानक शामिल करें (उदा., TENANT#<id>), और फिर dynamodb:LeadingKeys पर IAM कंडीशंस के साथ टेनेंट अलगाव लागू करें।

यदि आपको अधिक कड़ा अलगाव चाहिए, तो प्रत्येक टेनेंट के लिए अलग टेबल या अलग एनवायरनमेंट टेबल विचार करें, और साझा-टेबल डिज़ाइनों को उन मामलों के लिए सुरक्षित रखें जहाँ संचालन सरलता और लागत-कुशलता भयंकर ब्लास्ट-रेडियस आवश्यकताओं से अधिक महत्वपूर्ण हों।

लागत अनुकूलन (Cost Optimization)

DynamoDB अक्सर “जब आप सटीक हों तो सस्ता, जब आप अस्पष्ट हों तो महंगा” होता है। लागत आम तौर पर आपके एक्सेस पैटर्न्स का अनुसरण करती है, इसलिए बेहतरीन अनुकूलन काम उन पैटर्न्स को स्पष्ट करने से शुरू होता है।

लागत ड्राइवरों को जानें

आपका बिल मुख्यतः इन चीज़ों से आकार लेता है:

• रीड्स और राइट्स (Provisioned मोड में RCUs/WCUs, on-demand में अनुरोध यूनिट्स)
• स्टोरेज (टेबल डेटा और आइटम साइज)
• सेकंडरी इंडेक्सेस (हर GSI की अपनी राइट और स्टोरेज लागत)
• Streams (स्ट्रीम रिकॉर्ड्स के खिलाफ रीड रिक्वेस्ट्स और किसी भी डाउनस्ट्रीम कंज्यूमर)

एक सामान्य आश्चर्य: बेस टेबल पर हर राइट संबंधित GSI पर भी राइट बनाता है, इसलिए “बस एक और इंडेक्स” लिखने की लागत को गुणा कर सकता है।

बेकार खर्च से बचने के लिए कीज़ डिज़ाइन करें

अच्छी की डिज़ाइन महंगा ऑपरेशंस करने की आवश्यकता को घटाती है। यदि आप अक्सर Scan की ओर जा रहे हैं, तो आप उन डेटा को पढ़ने के लिए भुगतान कर रहे हैं जिन्हें आप बाद में फेंक देते हैं।

प्राथमिकता दें:

• Query द्वारा partition key का उपयोग (और वैकल्पिक रूप से sort key conditions)
• अपनी GSIs में सीमित projections रखें (सिर्फ उन attributes को प्रोजेक्ट करें जिनकी आपको वाकई आवश्यकता है)

यदि कोई एक्सेस पैटर्न दुर्लभ है, तो उसे एक अलग टेबल, ETL जॉब, या कैश्ड रीड मॉडल के जरिये सर्व करने पर विचार करें बजाय स्थायी GSI के।

TTL और लाइफसायकल से स्टोरेज नियंत्रित करें

अस्थायी आइटम्स (sessions, temporary tokens, मध्यवर्ती वर्कफ़्लो स्टेट) को स्वतः हटाने के लिए TTL का उपयोग करें। यह स्टोरेज कम करता है और समय के साथ इंडेक्सेस को छोटा रख सकता है।

ऐपेंड-हेवी डेटा (इवेंट्स, लॉग्स) के लिए, TTL को sort-key डिज़ाइनों के साथ मिलाएँ जो आपको “सिर्फ हाल का” क्वेरी करने देते हैं, ताकि आप नियमित रूप से ठंडी हिस्ट्री को छूने से बचें।

क्षमता का सही आकार चुनें और आकस्मिक स्पाइक्स से बचें

Provisioned मोड में, वास्तविक मेट्रिक्स के आधार पर कंज़र्वेटिव बेसलाइन्स सेट करें और ऑटो-स्केलिंग के साथ स्केल करें। On-demand मोड में, बड़े आइटम्स या चैटी क्लाइंट्स जैसी अनावश्यक पैटर्न्स पर नज़र रखें जो अनुरोध मात्रा बढ़ा सकते हैं।

Scan को अंतिम विकल्प मानें—जब आपको वाकई पूरा-टेबल प्रोसेस करना हो, तो इसे ऑफ-पीक शेड्यूल करें या नियंत्रित बैच के रूप में pagination और backoff के साथ चलाएँ।

कब DynamoDB चुनें (और कब न करें)

DynamoDB तब उज्जवल होता है जब आपकी एप्लिकेशन को स्पष्ट, की-आधारित एक्सेस-पैटर्न्स के सेट के रूप में व्यक्त किया जा सके और आपको बड़े पैमाने पर लगातार कम-लेटेंसी की आवश्यकता हो। यदि आप अपनी पढ़ाइयों और लिखाइयों को पहले से बता सकते हैं (partition key, sort key, और कुछ इंडेक्सेस द्वारा), तो यह अक्सर एक उच्च उपलब्धता वाला स्टोर चलाने का सबसे सरल तरीका होता है।

बेहतरीन फ़िट्स

DynamoDB एक मजबूत विकल्प है जब आपके पास हो:

• प्रेडिक्टेबल क्वेरीज (यूज़र प्रोफ़ाइल फेच करना, किसी यूज़र के ऑर्डर्स को समय के अनुसार सूचीबद्ध करना, एक सत्र ID से लोड करना)
• उच्च राइट थ्रूपुट या स्पाइकी ट्रैफ़िक जिसे आप प्रबंधित नहीं करना चाहते
• सर्वर रहित ऑपरेशन के बिना हॉरिज़ॉन्टल स्केलिंग की जरूरत
• Streams का उपयोग करके इवेंट-ड्रिवन डिज़ाइनों की आवश्यकता

कब विकल्पों पर विचार करें

दूसरी ओर विचार करें अगर आपकी कोर ज़रूरतें शामिल करती हैं:

• कई एंटिटीज़ में जटिल जॉइन्स या बार-बार होने वाले रिलेशनशिप ट्रैवर्सल
• हफ़्ते-दर-हफ़्ते बदलने वाली ऐड-हॉक क्वेरीज़ और एनालिटिक्स (group-bys, exploratory filters)
• भारी टेक्स्ट सर्च और relevance ranking बिना बाहरी इंडेक्स के

हाइब्रिड अप्रोच जो अच्छा काम करते हैं

कई टीमें गर्म (hot) ऑपरेशनल रीड्स और राइट्स के लिए DynamoDB रखती हैं और फिर जोड़ती हैं:

• ऐनालिटिक्स और ऐतिहासिक रिपोर्टिंग के लिए S3 + Athena
• फ़ुल-टेक्स्ट सर्च और faceting के लिए OpenSearch (या समान)
• कुछ कीज़ बहुत अधिक रीड-हेवी हों तो कैश लेयर

प्रोटोटाइप नोट: मॉडल से ऐप तक का रास्ता छोटा करें

यदि आप एक्सेस पैटर्न्स और सिंगल-टेबल कन्वेंशन्स को मान्य कर रहे हैं, तो गति मायने रखती है। टीमें कभी-कभी आस-पास की सर्विस और UI को प्रोटोटाइप करने के लिए Koder.ai का उपयोग करती हैं (एक चैट-आधारित वाइब-कोडिंग प्लेटफ़ॉर्म जो वेब, सर्वर, और मोबाइल ऐप्स बनाता है) और फिर वास्तविक क्वेरी पाथ्स उभरने पर DynamoDB की की डिज़ाइन को इटररेट करती हैं। भले ही आपका प्रोडक्शन बैकएंड अलग हो, तेज़ एंड-टू-एंड प्रोटोटाइप यह बताने में मदद करते हैं कि कौन सी क्वेरीज Query होनी चाहिए बनाम कौन सी गलती से महंगे Scan बन जाएँगी।

त्वरित निर्णय चेकलिस्ट

मान्य करें: (1) आपके शीर्ष क्वेरीज ज्ञात और key-based हैं, (2) correctness ज़रूरतें कंसिस्टेंसी मॉडल से मेल खाती हैं, (3) अपेक्षित आइटम साइज और वृद्धि समझी गई है, और (4) लागत मॉडल (on-demand बनाम provisioned प्लस autoscaling) आपके बजट से मेल खाता है।