30 नव॰ 2025·8 मिनट
Amazon DynamoDB समझाया गया: विस्तार योग्य प्रणालियाँ बनाना
जानें Amazon DynamoDB क्या है, इसका NoSQL मॉडल कैसे काम करता है, और विस्तार योग्य, कम-लेटेंसी प्रणालियों व माइक्रोसर्विसेज़ के लिए व्यावहारिक डिज़ाइन पैटर्न।
जानें Amazon DynamoDB क्या है, इसका NoSQL मॉडल कैसे काम करता है, और विस्तार योग्य, कम-लेटेंसी प्रणालियों व माइक्रोसर्विसेज़ के लिए व्यावहारिक डिज़ाइन पैटर्न।
Amazon DynamoDB AWS की एक पूरी तरह प्रबंधित NoSQL डेटाबेस सेवा है, जो उन एप्लिकेशन्स के लिए डिज़ाइन की गई है जिन्हें लगभग किसी भी पैमाने पर लगातार कम-लेटेंसी रीड और राइट चाहिए। “पूरी तरह प्रबंधित” का मतलब है कि AWS इन्फ्रास्ट्रक्चर का काम—हार्डवेयर प्रोविज़निंग, रेप्लिकेशन, पैचिंग और कई ऑपरेशनल टास्क—हैंडल करता है, ताकि टीमें डेटाबेस सर्वरों को चलाने की बजाय फीचर्स पर ध्यान दे सकें।
मूल रूप से, DynamoDB डेटा को items (पंक्तियों) के रूप में tables के अंदर स्टोर करता है, लेकिन प्रत्येक item में लचीले attributes हो सकते हैं। डेटा मॉडल को सबसे अच्छा इस मिश्रण के रूप में समझा जा सकता है:
टीमें DynamoDB तब चुनती हैं जब उन्हें प्रेडिक्टेबल परफॉर्मेंस और सरल ऑपरेशन्स चाहिए उन वर्कलोड्स के लिए जो रिलेशनल जॉइन में अच्छी तरह फ़िट नहीं होते। यह आमतौर पर माइक्रोसर्विसेज़ (प्रत्येक सर्विस अपना डेटा खुद रेखांकित करती है), बर्स्टरी ट्रैफ़िक वाले सर्वरलेस ऐप्स, और डेटा परिवर्तन पर रिएक्ट करने वाले इवेंट-ड्रिवन सिस्टम्स के लिए उपयोग किया जाता है।
यह पोस्ट बिल्डिंग ब्लॉक्स (टेबल्स, कीज़, और इंडेक्सेस), एक्सेस पैटर्न के आसपास मॉडलिंग (सिंगल-टेबल डिज़ाइन सहित), स्केलिंग और कैपेसिटी मोड कैसे काम करते हैं, और स्ट्रीमिंग के लिए व्यावहारिक पैटर्न — सब चर्चा करता है।
DynamoDB कुछ सरल बिल्डिंग ब्लॉक्स के इर्द-गिर्द व्यवस्थित है, लेकिन डिटेल्स मायने रखते हैं क्योंकि वे यह निर्धारित करते हैं कि आप डेटा कैसे मॉडल करेंगे और अनुरोध कितने तेज़ (और लागत-प्रभावी) होंगे।
एक टेबल शीर्ष-स्तरीय कंटेनर है। टेबल में प्रत्येक रिकॉर्ड एक item होता है (रो की तरह), और प्रत्येक item कई attributes का सेट है (कॉलम्स की तरह)।
रिलेशनल डेटाबेस के विपरीत, एक ही टेबल के items को एक ही attributes साझा करने की ज़रूरत नहीं होती। एक आइटम में {status, total, customerId} हो सकता है, जबकि दूसरे में {status, shipmentTracking} — DynamoDB को फिक्स्ड स्कीमा की आवश्यकता नहीं होती।
हर item को एक प्राइमरी की द्वारा यूनिक रूप से पहचाना जाता है, और DynamoDB दो प्रकार सपोर्ट करता है:
प्रैक्टिस में, कम्पोजिट कीज़ “ग्रुप्ड” एक्सेस पैटर्न सक्षम करती हैं जैसे “एक ग्राहक के सभी ऑर्डर, नए पहले।”
Query प्राइमरी की (या किसी इंडेक्स की) द्वारा आइटम्स पढ़ता है। यह एक विशेष partition key को टार्गेट करता है और sort key रेंज के आधार पर फ़िल्टर कर सकता है—यह कुशल और वांछनीय पथ है।
Scan पूरी टेबल (या इंडेक्स) को वॉक करता है और फिर फ़िल्टर करता है। यह शुरू करने में आसान है, लेकिन बड़े पैमाने पर यह आमतौर पर धीमा और महंगा होता है।
कुछ सीमाएँ जो जल्दी महसूस होंगी:
ये मूल बातें आगे की सभी चर्चाओं के लिए आधार तय करती हैं: एक्सेस पैटर्न, इंडेक्सिंग विकल्प, और परफॉर्मेंस चरित्र।
DynamoDB को अक्सर key-value स्टोर और डॉक्युमेंट डेटाबेस दोनों के रूप में बताया जाता है। यह सटीक है, लेकिन यह समझना उपयोगी है कि रोज़मर्रा की डिज़ाइन में प्रत्येक का क्या मतलब होता है।
मूल रूप से आप कुंजी द्वारा डेटा पुनः प्राप्त करते हैं। प्राइमरी की वैल्यूज़ दें और DynamoDB एकल item लौटाता है। यह की-आधारित लुकअप वह है जो कई वर्कलोड्स के लिए प्रेडिक्टेबल, कम-लेटेंसी स्टोरेज देता है।
साथ ही, एक आइटम नेस्टेड attributes (maps और lists) रख सकता है, जिससे यह डॉक्युमेंट डेटाबेस जैसा महसूस होता है: आप बिना कड़े स्कीमा के संरचित पेलोड रख सकते हैं।
Items प्राकृतिक रूप से JSON-जैसी डाटा को मैप करते हैं:
profile.name, profile.address)।यह तब अच्छा बैठता है जब एक एंटिटी आमतौर पर पूरे-पठित (read as a whole) होती है—जैसे user profile, शॉपिंग कार्ट, या configuration bundle।
DynamoDB सर्वर-साइड जॉइन्स सपोर्ट नहीं करता। अगर आपकी ऐप को “एक ऑर्डर और उसके लाइन आइटम्स और शिपिंग स्टेटस” एक ही पढ़ने के पाथ पर चाहिए, तो आप अक्सर denormalize करेंगे: कुछ attributes को कई आइटम्स में कॉपी करना, या छोटे सब-स्ट्रक्चर को सीधे किसी आइटम में एम्बेड करना।
डेनॉर्मलाइज़ेशन लिखने की जटिलता बढ़ाता है और अपडेट फैनोंड का कारण बन सकता है। इसका लाभ यह है कि रीड्स के लिए राउंड-ट्रिप्स कम होते हैं और रीड तेज़ होते हैं—अक्सर स्केलेबल सिस्टम्स में यही क्रिटिकल पाथ होता है।
सबसे तेज़ DynamoDB क्वेरीज वे हैं जिन्हें आप “मुझे यह partition दो” (और वैकल्पिक रूप से “इस partition के भीतर यह रेंज दो”) के रूप में व्यक्त कर सकते हैं। इसलिए की चुनना मुख्य रूप से इस बारे में है कि आप डेटा को कैसे पढ़ते हैं, सिर्फ यह नहीं कि आप उसे कैसे स्टोर करते हैं।
partition key यह निर्धारित करता है कि कौन सा फिज़िकल partition एक आइटम स्टोर करेगा। DynamoDB इस वैल्यू को हैश करता है ताकि डेटा और ट्रैफ़िक फैल सके। अगर बहुत सारी रिक्वेस्ट्स कुछ ही partition key वैल्यूज़ पर केंद्रित हों, तो आप “हॉट” partitions बना सकते हैं और थ्रूपुट लिमिट्स से टकरा सकते हैं।
अच्छे partition keys:
"GLOBAL")sort key के साथ, एक ही partition key साझा करने वाले आइटम्स साथ-साथ स्टोर होते हैं और sort key के अनुसार ऑर्डर्ड होते हैं। इससे कुशल रूप से ये संभव हो पाते हैं:
BETWEEN, begins_with)एक सामान्य पैटर्न है sort key बनाना, जैसे TYPE#id या TS#2025-12-22T10:00:00Z, ताकि कई क्वेरी शेप्स बिना अतिरिक्त टेबल्स के सपोर्ट हो सकें।
PK = USER#<id> (सिंपल GetItem)PK = USER#<id>, SK begins_with ORDER# (या SK = CREATED_AT#...)PK = DEVICE#<id>, SK = TS#<timestamp> और BETWEEN का उपयोग समय विंडो के लिएअगर आपका partition key आपके उच्च-आयतन क्वेरीज के साथ मेल खाता है और समान रूप से वितरित होता है, तो आपको लगातार कम-लेटेंसी रीड और राइट मिलेंगे। अगर यह मेल नहीं खाता, तो आप स्कैन, फ़िल्टर, या अतिरिक्त इंडेक्सेस के साथ समझौता करेंगे—जो हर बार लागत बढ़ाते हैं और हॉट कीज़ के जोखिम को बढ़ाते हैं।
सेकंडरी इंडेक्सेज़ DynamoDB को आपके टेबल की प्राइमरी की के अलावा विकल्पी क्वेरी पाथ देती हैं। हर बार जब कोई नया एक्सेस पैटर्न दिखाई दे, तब आप बेस टेबल को बदलने के बजाय एक इंडेक्स जोड़ सकते हैं जो उन्हीं आइटम्स को अलग तरीके से री-की करता है।
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 यह तय करता है कि इंडेक्स में कौन से attributes स्टोर किए जाते हैं:
बेस टेबल पर हर लिखावट एक या अधिक इंडेक्सेस पर भी लिखावट ट्रिगर कर सकती है। अधिक GSIs और विस्तृत projections लिखने की लागत और कैपेसिटी उपयोग बढ़ाते हैं। स्थिर एक्सेस पैटर्न के आसपास इंडेक्स प्लान करें और जहाँ संभव हो प्रोजेक्ट किए गए attributes को न्यूनतम रखें।
DynamoDB में स्केलिंग एक विकल्प के साथ शुरू होती है: On-Demand या Provisioned कैपेसिटी। दोनों बहुत उच्च थ्रूपुट तक पहुँच सकते हैं, लेकिन वे बदलते ट्रैफ़िक पर अलग तरह से व्यवहार करते हैं।
On-Demand सबसे सरल है: आप अनुरोध के लिए भुगतान करते हैं और DynamoDB स्वचालित रूप से परिवर्तनीय लोड को समायोजित करता है। यह अप्रत्याशित ट्रैफ़िक, शुरुआती-स्टेज उत्पादों, और स्पाइकी वर्कलोड्स के लिए उपयुक्त है जहाँ आप कैपेसिटी टार्गेट्स नहीं प्रबंधित करना चाहते।
Provisioned कैपेसिटी प्लानिंग है: आप पढ़ने और लिखने की थ्रूपुट निर्दिष्ट करते हैं (या ऑटो-स्केल करते हैं) और स्थिर उपयोग पर अधिक प्रेडिक्टेबल प्राइसिंग पाते हैं। यह अक्सर ज्ञात, स्थिर वर्कलोड्स के लिए सस्ता होता है और उन टीमों के लिए जो मांग का पूर्वानुमान लगा सकते हैं।
Provisioned थ्रूपुट को मापा जाता है:
आपका आइटम साइज और एक्सेस पैटर्न वास्तविक लागत निर्धारित करते हैं: बड़े आइटम, स्ट्रोंग कंसिस्टेंसी, और स्कैन जल्दी से कैपेसिटी जला सकते हैं।
ऑटो स्केलिंग उपयोगिता लक्ष्यों के आधार पर provisioned RCUs/WCUs को समायोजित करती है। यह धीरे बढ़ते विकास और प्रेडिक्टेबल चक्रों में मदद करता है, पर यह तात्कालिक नहीं है। अचानक स्पाइक्स अभी भी थ्रॉटल कर सकते हैं अगर कैपेसिटी तेज़ी से नहीं बढ़ती, और यह उस समस्या को ठीक नहीं कर सकता जहाँ ट्रैफ़िक एक हॉट partition key पर केंद्रित हो।
DynamoDB Accelerator (DAX) एक इन-मेमोरी कैश है जो रीड लेटेंसी घटा सकता है और दोहराए जाने वाले रीड्स को ऑफलोड कर सकता है (उदा., लोकप्रिय प्रोडक्ट पेजेस, session lookups, leaderboards)। यह उन मामलों में सबसे उपयोगी है जब कई क्लाइंट्स बार-बार वही आइटम्स अनुरोध करें; यह राइट-हेवी पैटर्न्स में मदद नहीं करेगा, और यह सावधान की डिज़ाइन का विकल्प नहीं है।
DynamoDB आपको पढ़ने की गारंटी और लेटेंसी/लागत के बीच व्यापार करने देता है, इसलिए यह महत्वपूर्ण है कि आप हर ऑपरेशन के लिए “सही” का क्या मतलब है, स्पष्ट करें।
डिफ़ॉल्ट रूप से, GetItem और Query eventually consistent रीड्स उपयोग करते हैं: आप लिखने के तुरंत बाद थोड़ी देर तक पुराना वैल्यू देख सकते हैं। यह अक्सर फ़ीड्स, प्रोडक्ट कैटलॉग्स, और अन्य रीड-मोस्टली दृश्य के लिए ठीक है।
strongly consistent रीड्स के साथ (एक रीजन में बेस टेबल से रीड्स के लिए विकल्प), DynamoDB गारंटी देता है कि आप लेटेस्ट acknowleged लिखावट देखें। स्ट्रॉन्ग कंसिस्टेंसी अधिक रीड कैपेसिटी खर्च करती है और टेल लेटेंसी बढ़ा सकती है, इसलिए इसे सिर्फ़ सचमुच क्रिटिकल रीड्स के लिए रखें।
स्ट्रॉन्ग कंसिस्टेंसी उन रीड्स के लिए मूल्यवान है जो अपरिवर्तनीय क्रियाओं को नियंत्रित करते हैं:
काउंटर के लिए, सबसे सुरक्षित तरीका आमतौर पर “स्ट्रॉन्ग रीड फिर राइट” नहीं बल्कि एक atomic update (उदा., UpdateItem के साथ ADD) है ताकि increments खो न जाएँ।
DynamoDB ट्रांज़ैक्शंस (TransactWriteItems, TransactGetItems) ACID semantics प्रदान करते हैं और एक साथ 25 आइटम तक काम कर सकते हैं। ये तब उपयोगी हैं जब आपको कई आइटम एक साथ अपडेट करने हों—जैसे एक ऑर्डर लिखना और इन्वेंटरी रिज़र्व करना—या ऐसे इनवेरिएंट्स लागू करने हों जो मध्यवर्ती अवस्थाओं को बर्दाश्त न करें।
रिट्राइज़ वितरण प्रणालियों में सामान्य हैं। लिखाइयों को idempotent बनाइए ताकि रिट्राइज़ प्रभावों को डुप्लिकेट न कर दे:
ConditionExpression के साथ यूनिकनेस लागू करें (उदा., “only create if attribute_not_exists”)DynamoDB में correctness ज्यादातर सही कंसिस्टेंसी स्तर चुनने और ऑपरेशंस को इस तरह डिजाइन करने के बारे में है कि रिट्राइज़ डेटा को बिगाड़ न सकें।
DynamoDB टेबल डेटा को कई फिज़िकल पार्टिशन्स में स्टोर करता है। हर पार्टिशन की पढ़ने/लिखने की सीमित थ्रूपुट होती है, साथ ही उसके पास कितना डेटा रख सकता है उसकी सीमा भी होती है। आपका partition key तय करता है कि कोई आइटम कहां रहेगा; अगर बहुत सारी रिक्वेस्ट्स एक ही partition key वैल्यू (या थोड़े से वैल्यूज़) को लक्षित करें, तो वह पार्टिशन बॉटलनेक बन जाता है।
हॉट पार्टिशन्स आमतौर पर उन की डिज़ाइनों से होते हैं जो ट्रैफ़िक को केंद्रीकृत करती हैं: एक “global” partition key जैसे USER#1, TENANT#default, या STATUS#OPEN, या टाइम-ऑर्डर्ड पैटर्न जहाँ हर कोई “अब” में लिखता है।
आम तौर पर आप देखेंगे:
ProvisionedThroughputExceededException) कुछ कीज़ के लिएडिस्ट्रीब्यूशन को पहले डिज़ाइन करें, फिर क्वेरी सुविधा पर विचार करें:
TENANT#<id> को साझा कांस्टेंट के बजाय)ORDER#<id>#<shard> ताकि लिखाइयाँ N shards में फैली जा सकें, और जरूरत पड़ने पर shards पर क्वेरी करें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 list अच्छा काम करती है: edges को आइटम्स के रूप में स्टोर करें.
PK = USER#123, SK = FOLLOWS#USER#456रिवर्स लुकअप या सच्ची many-to-many सपोर्ट करने के लिए, एक inverted edge आइटम जोड़ें या पढ़ने के पाथ के आधार पर GSI में प्रोजेक्ट करें।
इवेंट्स और मेट्रिक्स के लिए, अनबाउंडेड partitions से बचें:
PK = DEVICE#9#2025-12-22 (डिवाइस + दिन)SK = TS#1734825600 (टाइमस्टैम्प)पुराने पॉइंट्स को स्वतः समाप्त करने के लिए TTL का उपयोग करें, और डैशबोर्ड्स के लिए अलग आइटम्स में aggregates (hourly/daily rollups) रखें ताकि तेज़ डैशबोर्ड मिलें।
यदि आप कीज़ कन्वेंशन्स पर गहरा रिफ्रेश चाहते हैं, तो देखें /blog/partition-key-and-sort-key-design.
DynamoDB Streams DynamoDB का बिल्ट-इन चेंज डेटा कैप्चर (CDC) फ़ीड है। जब किसी टेबल पर यह इनेबल होता है, तो हर insert, update, या delete एक स्ट्रीम रिकॉर्ड उत्पन्न करता है जिसे डाउनस्ट्रीम कंज्यूमर्स रिएक्ट कर सकते हैं—बिना टेबल को पोल किए।
एक स्ट्रीम रिकॉर्ड में कीज़ और (वैकल्पिक रूप से) आइटम का पुराना और/या नया इमेज होता है, जो कि आप जिस stream view type का चयन करते हैं उस पर निर्भर करता है (keys only, new image, old image, both)। रिकॉर्ड्स को shards में समूहित किया जाता है, जिन्हें आप अनुक्रमिक रूप से पढ़ते हैं।
एक सामान्य सेटअप है DynamoDB Streams → AWS Lambda, जहाँ हर रिकॉर्ड बैच एक फ़ंक्शन को ट्रिगर करता है। अन्य कंज्यूमर्स भी संभव हैं (कस्टम कंज्यूमर्स, या एनालिटिक्स/लॉगिंग सिस्टम्स में पाइपिंग)।
आम वर्कफ़्लोज़ में शामिल हैं:
इससे प्राथमिक टेबल कम-लेटेंसी रीड/राइट के लिए अनुकूल रहती है और व्युत्पन्न काम असिंक्रोनस कंज्यूमर्स को सौंप दिया जाता है।
Streams प्रति शार्ड अनुक्रमित प्रोसेसिंग प्रदान करते हैं (जो आम तौर पर partition key के साथ संबंधित होती है), पर सभी कीज़ के बीच कोई वैश्विक ऑर्डर नहीं होता। डिलीवरी at-least-once है, इसलिए डुप्लिकेट्स हो सकते हैं।
इसे सुरक्षित रूप से हैंडल करने के लिए:
इन गारंटीज़ को ध्यान में रखकर, Streams DynamoDB को इवेंट-ड्रिवन सिस्टम्स के लिए एक मज़बूत रीढ़ बना सकते हैं।
DynamoDB को उच्च उपलब्धता के लिए डिज़ाइन किया गया है, जो डेटा को एक रीजन के कई Availability Zones में फैलाता है। अधिकांश टीमों के लिए व्यावहारिक विश्वसनीयता लाभ स्पष्ट बैकअप रणनीति रखने, रेप्लिकेशन विकल्प समझने, और सही मेट्रिक्स मॉनिटर करने से आते हैं।
On-demand backups मैन्युअल (या स्वचालित) स्नैपशॉट होते हैं जिन्हें आप किसी ज्ञात रीस्टोर पॉइंट के रूप में लेते हैं—माइग्रेशन से पहले, रिलीज के बाद, या बड़े बैकफिल से पहले। वे “बुकमार्क” क्षणों के लिए उपयुक्त हैं।
Point-in-time recovery (PITR) लगातार परिवर्तनों को कैप्चर करता है ताकि आप टेबल को रोकथाम विंडो के भीतर किसी भी सेकंड पर पुनर्स्थापित कर सकें। PITR आकस्मिक डिलीट्स, खराब डिप्लॉयस, या malformed writes के लिए एक सुरक्षा नेट है।
यदि आपको मल्टी-रीजन रेजिलिएंस या उपयोगकर्ताओं के नज़दीक लो-लेटेंसी रीड्स चाहिए, तो Global Tables चयनित क्षेत्रों में डेटा की नकल करती हैं। ये फ़ेलओवर प्लानिंग को सरल बनाती हैं, पर क्रॉस-रीजन रेप्लिकेशन देरी और कॉन्फ़्लिक्ट-रिज़ॉल्यूशन विचार लाती हैं—इसलिए लिखने के पैटर्न और आइटम मालिकाना स्पष्ट रखें।
न्यूनतम के रूप में, इन पर अलर्ट रखें:
ये संकेत आम तौर पर हॉट-पार्टिशन समस्याओं, अपर्याप्त कैपेसिटी, या अप्रत्याशित एक्सेस पैटर्न को उजागर करते हैं।
थ्रॉटलिंग के लिए, पहले वह एक्सेस पैटर्न पहचानें जो कारण बना रहा है, फिर अस्थायी रूप से on-demand में स्विच करें या provisioned कैपेसिटी बढ़ाएँ, और हॉट कीज़ शार्ड करने पर विचार करें।
आंशिक आउटेज या बढ़ी हुई त्रुटियों के लिए, ब्लास्ट रेडियस कम करें: गैर-आवश्यक ट्रैफ़िक अक्षम करें, jittered backoff के साथ रिट्राइज़ करें, और टेबल स्थिर होने तक विनम्र विफलता (उदा., cached reads सर्व करना) अपनाएँ।
DynamoDB सुरक्षा मुख्यतः इस बारे में है कि कौन किन API क्रियाओं को कॉल कर सकता है, कहाँ से, और किस कीज़ पर। क्योंकि एक टेबल कई एंटिटी टाइप्स (और कभी-कभी कई टेनेंट) रख सकती है, एक्सेस कंट्रोल को डेटा मॉडल के साथ-साथ डिज़ाइन करना चाहिए।
पहले identity-based IAM नीतियों के साथ शुरू करें जो क्रियाओं (उदा., dynamodb:GetItem, Query, PutItem) को न्यूनतम सेट तक सीमित करें और उन्हें विशिष्ट टेबल ARNs तक स्कोप करें।
और भी सूक्ष्म नियंत्रण के लिए dynamodb:LeadingKeys का उपयोग करें ताकि partition key वैल्यूज़ द्वारा एक्सेस को प्रतिबंधित किया जा सके—यह उपयोगी है जब किसी सर्विस या टेनेंट को केवल अपनी ही keyspace तक पहुँच होनी चाहिए।
DynamoDB डिफ़ॉल्ट रूप से डेटा को रेस्ट पर एन्क्रिप्ट करता है AWS-owned keys या customer-managed KMS key के साथ। अगर आपकी अनुपालन आवश्यकताएँ हैं, तो सत्यापित करें:
ट्रांसिट में एन्क्रिप्शन के लिए, सुनिश्चित करें कि क्लाइंट्स 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 कंडीशंस के साथ टेनेंट अलगाव लागू करें।
यदि आपको अधिक कड़ा अलगाव चाहिए, तो प्रत्येक टेनेंट के लिए अलग टेबल या अलग एनवायरनमेंट टेबल विचार करें, और साझा-टेबल डिज़ाइनों को उन मामलों के लिए सुरक्षित रखें जहाँ संचालन सरलता और लागत-कुशलता भयंकर ब्लास्ट-रेडियस आवश्यकताओं से अधिक महत्वपूर्ण हों।
DynamoDB अक्सर “जब आप सटीक हों तो सस्ता, जब आप अस्पष्ट हों तो महंगा” होता है। लागत आम तौर पर आपके एक्सेस पैटर्न्स का अनुसरण करती है, इसलिए बेहतरीन अनुकूलन काम उन पैटर्न्स को स्पष्ट करने से शुरू होता है।
आपका बिल मुख्यतः इन चीज़ों से आकार लेता है:
एक सामान्य आश्चर्य: बेस टेबल पर हर राइट संबंधित GSI पर भी राइट बनाता है, इसलिए “बस एक और इंडेक्स” लिखने की लागत को गुणा कर सकता है।
अच्छी की डिज़ाइन महंगा ऑपरेशंस करने की आवश्यकता को घटाती है। यदि आप अक्सर Scan की ओर जा रहे हैं, तो आप उन डेटा को पढ़ने के लिए भुगतान कर रहे हैं जिन्हें आप बाद में फेंक देते हैं।
प्राथमिकता दें:
Query द्वारा partition key का उपयोग (और वैकल्पिक रूप से sort key conditions)यदि कोई एक्सेस पैटर्न दुर्लभ है, तो उसे एक अलग टेबल, ETL जॉब, या कैश्ड रीड मॉडल के जरिये सर्व करने पर विचार करें बजाय स्थायी GSI के।
अस्थायी आइटम्स (sessions, temporary tokens, मध्यवर्ती वर्कफ़्लो स्टेट) को स्वतः हटाने के लिए TTL का उपयोग करें। यह स्टोरेज कम करता है और समय के साथ इंडेक्सेस को छोटा रख सकता है।
ऐपेंड-हेवी डेटा (इवेंट्स, लॉग्स) के लिए, TTL को sort-key डिज़ाइनों के साथ मिलाएँ जो आपको “सिर्फ हाल का” क्वेरी करने देते हैं, ताकि आप नियमित रूप से ठंडी हिस्ट्री को छूने से बचें।
Provisioned मोड में, वास्तविक मेट्रिक्स के आधार पर कंज़र्वेटिव बेसलाइन्स सेट करें और ऑटो-स्केलिंग के साथ स्केल करें। On-demand मोड में, बड़े आइटम्स या चैटी क्लाइंट्स जैसी अनावश्यक पैटर्न्स पर नज़र रखें जो अनुरोध मात्रा बढ़ा सकते हैं।
Scan को अंतिम विकल्प मानें—जब आपको वाकई पूरा-टेबल प्रोसेस करना हो, तो इसे ऑफ-पीक शेड्यूल करें या नियंत्रित बैच के रूप में pagination और backoff के साथ चलाएँ।
DynamoDB तब उज्जवल होता है जब आपकी एप्लिकेशन को स्पष्ट, की-आधारित एक्सेस-पैटर्न्स के सेट के रूप में व्यक्त किया जा सके और आपको बड़े पैमाने पर लगातार कम-लेटेंसी की आवश्यकता हो। यदि आप अपनी पढ़ाइयों और लिखाइयों को पहले से बता सकते हैं (partition key, sort key, और कुछ इंडेक्सेस द्वारा), तो यह अक्सर एक उच्च उपलब्धता वाला स्टोर चलाने का सबसे सरल तरीका होता है।
DynamoDB एक मजबूत विकल्प है जब आपके पास हो:
दूसरी ओर विचार करें अगर आपकी कोर ज़रूरतें शामिल करती हैं:
कई टीमें गर्म (hot) ऑपरेशनल रीड्स और राइट्स के लिए DynamoDB रखती हैं और फिर जोड़ती हैं:
यदि आप एक्सेस पैटर्न्स और सिंगल-टेबल कन्वेंशन्स को मान्य कर रहे हैं, तो गति मायने रखती है। टीमें कभी-कभी आस-पास की सर्विस और UI को प्रोटोटाइप करने के लिए Koder.ai का उपयोग करती हैं (एक चैट-आधारित वाइब-कोडिंग प्लेटफ़ॉर्म जो वेब, सर्वर, और मोबाइल ऐप्स बनाता है) और फिर वास्तविक क्वेरी पाथ्स उभरने पर DynamoDB की की डिज़ाइन को इटररेट करती हैं। भले ही आपका प्रोडक्शन बैकएंड अलग हो, तेज़ एंड-टू-एंड प्रोटोटाइप यह बताने में मदद करते हैं कि कौन सी क्वेरीज Query होनी चाहिए बनाम कौन सी गलती से महंगे Scan बन जाएँगी।
मान्य करें: (1) आपके शीर्ष क्वेरीज ज्ञात और key-based हैं, (2) correctness ज़रूरतें कंसिस्टेंसी मॉडल से मेल खाती हैं, (3) अपेक्षित आइटम साइज और वृद्धि समझी गई है, और (4) लागत मॉडल (on-demand बनाम provisioned प्लस autoscaling) आपके बजट से मेल खाता है।
DynamoDB AWS का एक पूरी तरह प्रबंधित NoSQL डेटाबेस है जो बहुत बड़े पैमाने पर भी लगातार कम लेटेंसी वाले रीड/राइट के लिए बनाया गया है। जब आपकी पहुँच-केंद्रित (key-based) क्वेरीज — जैसे ID से फेच करना, किसी मालिक के अनुसार सूची बनाना, या टाइम-रेंज क्वेरीज — स्पष्ट हों और आप डेटाबेस सर्वर्स चलाने से बचना चाहें, तब टीमें इसे चुनती हैं.
यह माइक्रोसर्विसेज़, सर्वरलेस ऐप्स और इवेंट-ड्रिवन सिस्टम्स में खासकर आम है।
एक टेबल में items होते हैं (पंक्तियों जैसे)। हर item लचीले सेट ऑफ़ attributes रखता है (कॉलम्स की तरह) और इसमें नेस्टेड डेटा भी हो सकता है.
जब एक रिक्वेस्ट आमतौर पर ‘‘पूरे एंटिटी’’ को मांगती है, तब DynamoDB अच्छा काम करता है—क्योंकि items में maps और lists (JSON-जैसे) हो सकते हैं।
केवल partition key वाला एक attribute आइटम को यूनिकली पहचानता है (सिंपल प्राइमरी की)। partition key + sort key (कम्पोजिट की) कई आइटमों को एक ही partition key के तहत समूहित होने देती है जबकि sort key उन्हें यूनिक और क्रमबद्ध रखती है।
कम्पोजिट की से ये पैटर्न संभव होते हैं:
जब आप partition key (और वैकल्पिक रूप से sort key शर्त) बता सकते हों तो Query का उपयोग करें। यह तेज़ और स्केलेबल तरीका है.
Scan का उपयोग तब करें जब आपको वाकई पूरी टेबल पढ़नी हो; यह पूरे टेबल/इंडेक्स को पढ़ता है और बाद में फ़िल्टर करता है, इसलिए आमतौर पर धीमा और महंगा होता है.
अगर आप बार-बार स्कैन कर रहे हैं, तो यह संकेत है कि आपकी की/इंडेक्स डिज़ाइन में समायोजन की ज़रूरत है।
सैकंडरी इंडेक्स वैकल्पिक क्वेरी पाथ देते हैं.
partition key (और वैकल्पिक sort key) रख सकता है; इसे बाद में जोड़ा जा सकता है।इंडेक्स लिखने की लागत बढ़ाते हैं क्योंकि हर लिखावट इंडेक्स में भी रिप्लिकेट होती है।
यदि ट्रैफ़िक अनिश्चित या स्पाइकी है, तो On-Demand चुनें—आप प्रति अनुरोध भुगतान करते हैं और DynamoDB स्वतः लोड समायोजित करता है.
यदि उपयोग स्थिर/पूर्वानुमान योग्य है और आप लागत नियंत्रित रखना चाहते हैं, तो Provisioned चुनें और ऑटो-स्केलिंग के साथ मिलाकर चलाएँ। ध्यान रखें कि यह अचानक स्पाइक्स पर तुरंत प्रतिक्रिया नहीं दे सकता।
डिफ़ॉल्ट रूप से रीड्स eventually consistent होते हैं — मतलब लिखने के तुरंत बाद थोड़ी देर के लिए पुराना वैल्यू दिख सकता है.
जब आपको हकीकत में नवीनतम वैल्यू चाहिए—जैसे ऑथराइज़ेशन चेक या वर्कफ़्लो स्टेट — तब strongly consistent रीड का उपयोग करें।
कन्करेंसी-सेफ्टी के लिए अक्सर atomic updates (जैसे UpdateItem के साथ ADD) पढ़-पर-लिखो चक्रों से बेहतर होते हैं।
Transactions (TransactWriteItems, TransactGetItems) ACID गारंटी देती हैं और एक साथ अधिकतम 25 आइटम्स को कवर कर सकती हैं.
उन्हें तब उपयोग करें जब आपको कई आइटम एक साथ अपडेट करने हों (जैसे ऑर्डर बनाना और इन्वेंटरी रिज़र्व करना) या ऐसे इनवेरिएंट्स जिनमें आंशिक अपडेट बर्दाश्त नहीं होते।
वे अधिक लागत और लेटेंसी जोड़ते हैं, इसलिए केवल उन फ्लोज़ के लिए प्रयोग करें जिन्हें वास्तव में इसकी ज़रूरत है।
हॉट पार्टिशन तब बनते हैं जब बहुत सारी रिक्वेस्ट्स एक ही partition key वैल्यू (या बहुत ही सीमित वैल्यू सेट) को लक्षित करें, जिसके कारण थ्रॉटलिंग होती है भले ही टेबल बाकी समय खाली हो।
सामान्य उपाय:
DynamoDB Streams enable करके आप inserts, updates, deletes के लिए एक चेंज-फीड पाते हैं। एक सामान्य पैटर्न है Streams → Lambda ताकि प्रत्येक रिकॉर्ड बैच पर डाउनस्ट्रीम काम ट्रिगर हो सके.
महत्वपूर्ण गारंटीज़:
per shard होता है (ग्लोबल ऑर्डर नहीं)at-least-once होती है (डुप्लिकेट्स संभव हैं)कंस्यूमर्स को आईडेम्पोटेंट बनाएँ (key द्वारा upsert करें, conditional writes, या प्रोसेस किए गए ईवेंट IDs ट्रैक करें)।