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 attribute ਦਾ ਸੈੱਟ ਹੁੰਦਾ ਹੈ (ਕਾਲਮ ਵਰਗਾ)।
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸਾਂ ਦੇ ਵਿਰੁੱਧ, ਇੱਕੋ ਟੇਬਲ ਦੇ items ਨੂੰ ਇਕੱਲੇ attributes ਸਾਂਝੇ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਕ item ਕੋਲ {status, total, customerId} ਹੋ ਸਕਦੇ ਹਨ, ਜਦਕਿ ਦੂਜੇ ਕੋਲ {status, shipmentTracking} ਹੋ ਸਕਦਾ ਹੈ—DynamoDB ਨੂੰ ਫਿਕਸ ਸਕੀਮਾ ਦੀ ਲੋੜ ਨਹੀਂ।
ਹਰ item ਨੂੰ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਕੀ ਨਾਲ ਵਿਲੱਖਣਤਾ ਮਿਲਦੀ ਹੈ, ਅਤੇ DynamoDB ਦੋ ਕਿਸਮਾਂ ਨੂੰ ਸਹਾਰਦਾ ਹੈ:
ਅਮਲ ਵਿੱਚ, ਕਾਂਪੋਜ਼ਿਟ ਕੀ “ਗਰੁੱਪਡ” ਐਕਸੇਸ ਪੈਟਰਨਾਂ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ, ਜਿਵੇਂ “ਕਿਸੇ ਗ੍ਰਾਹਕ ਲਈ ਸਾਰੇ ਆਰਡਰ, ਨਵੇਂ ਪਹਿਲਾਂ।”
Query ਪ੍ਰਾਇਮਰੀ ਕੀ (ਜਾਂ ਕਿਸੇ ਇੰਡੈਕਸ ਕੀ) ਦੁਆਰਾ items ਪੜ੍ਹਦਾ ਹੈ। ਇਹ ਇਕ ਨਿਰਧਾਰਿਤ partition key ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ sort key ਰੇਂਜਾਂ ਦੁਆਰਾ ਛਾਣ ਸਕਦਾ ਹੈ—ਇਹ ਕੁਸ਼ਲ ਅਤੇ ਪਸੰਦੀਦਾ ਰਸਤਾ ਹੈ।
Scan ਪੂਰੀ ਟੇਬਲ (ਜਾਂ ਇੰਡੈਕਸ) ਨੂੰ ਦੇਖਦਾ ਹੈ ਅਤੇ ਫਿਰ ਫਿਲਟਰ ਲਗਾਉਂਦਾ ਹੈ। ਇਹ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਆਸਾਨ ਹੈ, ਪਰ ਪੈਮਾਨੇ ਤੇ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਧੀਮਾ ਅਤੇ ਮਹਿੰਗਾ ਹੋ ਸਕਦਾ ਹੈ।
ਇਹ ਮੁੱਢਲੀਆਂ ਗੱਲਾਂ ਸਾਰੇ ਅੱਗੇ ਆਉਣ ਵਾਲੇ ਵਿਸ਼ਿਆਂ ਦਾ ਬੇਸ ਬਣਾਉਂਦੀਆਂ ਹਨ: ਐਕਸੇਸ ਪੈਟਰਨ, ਇੰਡੈਕਸ ਚੋਣ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ।
DynamoDB ਨੂੰ ਅਕਸਰ key-value ਸਟੋਰ ਅਤੇ ਡੌਕਯੂਮੈਂਟ ਡੇਟਾਬੇਸ ਦੋਹਾਂ ਵਜੋਂ ਵਰਣਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਸਹੀ ਹੈ, ਪਰ ਦਿਨ-ਪ੍ਰਤੀਦਿਨ ਡਿਜ਼ਾਇਨ ਵਿੱਚ ਹਰ ਇੱਕ ਦਾ ਕੀ ਅਰਥ ਹੁੰਦਾ ਹੈ ਇਹ ਸਮਝਣਾ ਲਾਭਕਾਰੀ ਹੈ।
ਮੂਲ ਤੌਰ 'ਤੇ, ਤੁਸੀਂ ਕੀ ਰਾਹੀਂ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ। ਪ੍ਰਾਇਮਰੀ ਕੀ ਮੁਹੱਈਆ ਕਰੋ ਅਤੇ DynamoDB ਇੱਕ item ਵਾਪਸ ਕਰੇਗਾ। ਇਹ ਕੀਡ ਲੁੱਕਅਪ ਉਹ ਹੈ ਜੋ ਕਈ ਵਰਕਲੋਡ ਲਈ ਪੇਸ਼ਗੋਈਯੋਗ, ਘੱਟ-ਲੇਟੈਂਸੀ ਸਟੋਰੇਜ ਦਿੰਦਾ ਹੈ।
ਇਸੇ ਸਮੇਂ, ਇੱਕ item nested attributes (maps ਅਤੇ lists) ਰੱਖ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਇਹ ਡੌਕਯੂਮੈਂਟ ਡੇਟਾਬੇਸ ਵਰਗਾ ਹੋ ਜਾਂਦਾ ਹੈ: ਤੁਸੀਂ ਬਿਨਾਂ ਸਕੀਮਾ ਤਿਆਰ ਕੀਤੇ ਸਫਰੂਚਿਤ ਪੇਲੋਡ ਰੱਖ ਸਕਦੇ ਹੋ।
Items ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ JSON-ਵਾਂਗ ਡੇਟਾ ਨੂੰ ਨਕਸ਼ਾ ਕਰਦੇ ਹਨ:
profile.name, profile.address).ਇਹ ਉਹਨਾਂ ਹੇਠਾਂ-ਪੜ੍ਹਨ ਵਾਲੇ ਏਂਟਿਟੀਜ਼ ਲਈ ਵਧੀਆ ਹੈ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਪੂਰੇ ਪੇਅਥ ਨਾਲ ਪੜ੍ਹੀਆਂ ਜਾਂਦੀਆਂ ਹਨ—ਜਿਵੇਂ ਯੂਜ਼ਰ ਪ੍ਰੋਫਾਈਲ, ਸ਼ਾਪਿੰਗ ਕਾਰਟ, ਜਾਂ ਕੰਫਿਗਰੇਸ਼ਨ ਬੰਡਲ।
DynamoDB ਸਰਵਰ-ਸਾਈਡ ਜੋਇਨ ਨੂੰ ਸਹਾਰ ਨਹੀਂ ਕਰਦਾ। ਜੇ ਤੁਹਾਡੀ ਐਪ ਨੂੰ “ਇੱਕ ਆਰਡਰ ਅਤੇ ਉਸ ਦੇ ਲਾਈਨ ਆਈਟਮ ਅਤੇ ਸ਼ਿਪਿੰਗ ਸਟੇਟਸ” ਇਕੱਠੇ ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਅਕਸਰ ਡੇਨਰਮਲਾਈਜ਼ ਕਰੋਗੇ: ਕੁਝ attributes ਕਈ items ਵਿੱਚ ਕਾਪੀ ਕਰਨਾ, ਜਾਂ ਛੋਟੇ ਸਭ-ਸਟ੍ਰਕਚਰ ਨੂੰ ਸਿੱਧਾ ਇੱਕ item ਵਿੱਚ ਐਂਬੈੱਡ ਕਰਨਾ।
ਡੇਨਰਮਲਾਈਜ਼ੇਸ਼ਨ ਨਾਲ ਲਿਖਣ ਦੀ ਜਟਿਲਤਾ ਵਧਦੀ ਹੈ ਅਤੇ ਅਪਡੇਟ ਫੈਨ-ਆਉਟ ਹੋ ਸਕਦਾ ਹੈ। ਪਰ ਇਸਦਾ ਨਤੀਜਾ ਘੱਟ ਰਾਊਂਡ ਟ੍ਰਿਪਸ ਅਤੇ ਤੇਜ਼ ਪੜ੍ਹਾਈਆਂ ਹੁੰਦਾ ਹੈ—ਜੋ ਕਿ ਅਕਸਰ ਸਕੇਲਯੋਗ ਸਿਸਟਮਾਂ ਵਿੱਚ ਇਕ ਆਵਸ਼ਯਕ ਲਾਬ ਹੈ।
ਸਭ ਤੋਂ ਤੇਜ਼ DynamoDB ਕਵੇਰੀਆਂ ਉਹ ਹਨ ਜੋ “ਮੈਨੂੰ ਇਹ partition ਦਿੰਦੇ” (ਅਤੇ ਵਿਕਲਪਿਕ ਤੌਰ 'ਤੇ “ਇਸ partition ਦੇ ਅੰਦਰ ਇਸ ਰੇਂਜ ਨੂੰ ਦਿਖਾਓ”) ਕਹਿ ਸਕਦੀਆਂ ਹਨ। ਇਸ ਲਈ ਕਿ ਕੀ ਚੋਣ ਮੁੱਖ ਤੌਰ 'ਤੇ ਇਸ ਬਾਰੇ ਹੁੰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਡੇਟਾ ਨੂੰ ਕਿਵੇਂ ਪੜ੍ਹਦੇ ਹੋ, ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਸਟੋਰ ਕਰਦੇ ਹੋ।
Partition key ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ ਕਿਹੜੀ ਫਿਜ਼ੀਕਲ partition ਇੱਕ item ਰੱਖਦੀ ਹੈ। DynamoDB ਇਸ ਮੁੱਲ ਨੂੰ ਹੈਸ਼ ਕਰਕੇ ਡੇਟਾ ਅਤੇ ਟ੍ਰੈਫਿਕ ਫੈਲਾਉਂਦਾ ਹੈ। ਜੇ ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਛੋਟੇ ਕੁਝ partition key ਮੁੱਲਾਂ 'ਤੇ ਕੇਂਦਰਤ ਹੋਣ, ਤਾਂ ਤੁਸੀਂ “ਹਾਟ” partitions ਬਣਾਉਂਦੇ ਹੋ ਅਤੇ throughput ਸੀਮਾਵਾਂ ਨਾਲ ਜੂਝਦੇ ਹੋ, ਭਾਵੇਂ ਟੇਬਲ ਮੁਕੰਮਲ ਤੌਰ 'ਤੇ ਨਿਸ਼ਕ੍ਰਿਆ ਹੋਵੇ।
ਚੰਗੀਆਂ partition keys:
"GLOBAL" ਵਰਗਾ constant)Sort key ਦੇ ਨਾਲ, ਉਹ items ਜਿਹਨਾਂ ਦਾ partition key ਇੱਕੋ ਹੋਵੇ ਇੱਕੱਠੇ ਸਟੋਰ ਹੁੰਦੇ ਹਨ ਅਤੇ sort key ਮੁਤਾਬਕ ਕ੍ਰਮ ਦਿਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਕੁਸ਼ਲ ਤਰੀਕੇ ਨਾਲ ਇਹ ਸਮਰੱਥ ਕਰਦਾ ਹੈ:
BETWEEN, begins_with)ਆਮ ਰੂਪ ਵਿੱਚ sort key ਤਿਆਰ ਕਰਨ ਦਾ ਪੈਟਰਨ ਹੈ, ਜਿਵੇਂ TYPE#id ਜਾਂ TS#2025-12-22T10:00:00Z, ਤਾਂ ਜੋ ਵੱਖ-ਵੱਖ ਕਵੇਰੀ ਆਕਾਰਾਂ ਦੇ ਸਮਰਥਨ ਲਈ ਬਿਨਾਂ ਵੱਖ ਟੇਬਲਾਂ ਦੇ ਹੋ ਸਕੇ।
PK = USER#\u003cid\u003e (GetItem)PK = USER#\u003cid\u003e, SK begins_with ORDER# (ਜਾਂ SK = CREATED_AT#...)PK = DEVICE#\u003cid\u003e, SK = TS#\u003ctimestamp\u003e BETWEEN ਨਾਲ ਸਮੇਂ ਦੀ ਖਿੜਕੀ ਲਈਜੇ ਤੁਹਾਡੀ partition key ਤੁਹਾਡੇ ਸਭ ਤੋਂ ਉੱਚ-ਭਰੋਸੇਮੰਦ ਕਵੇਰੀਆਂ ਨਾਲ ਖਾਰੀਦ ਕੰਮ ਕਰਦੀ ਹੈ ਅਤੇ ਬਰਾਬਰ ਵੰਡਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਲਗਾਤਾਰ ਘੱਟ-ਲੇਟੈਂਸੀ ਰੀਡਸ ਅਤੇ ਰਾਈਟਸ ਮਿਲਣਗੀਆਂ। ਜੇ ਨਹੀਂ, ਤਾਂ ਤੁਸੀਂ scans, filters ਜਾਂ ਵਾਧੂ ਇੰਡੈਕਸਾਂ ਨਾਲ ਬਦਲੀ ਕਰੋਂਗੇ—ਹਰ ਇੱਕ ਨਾਲ ਲਾਗਤ ਵੱਧਦੀ ਹੈ ਅਤੇ ਹਾਟ ਕੀਜ਼ ਦਾ ਖ਼ਤਰਾ ਬਣਦਾ ਹੈ।
ਸੈਕੰਡਰੀ ਇੰਡੈਕਸ DynamoDB ਨੂੰ ਤੁਹਾਡੇ ਮੇਨ ਟੇਬਲ ਦੇ ਪ੍ਰਾਇਮਰੀ ਕੀ ਤੋਂ ਹਟ ਕੇ ਬਦਲੇ ਹੋਏ ਕਵੇਰੀ ਪਾਥ ਦਿੰਦੀਆਂ ਹਨ। ਹਰ ਵਾਰੀ ਨਵੇਂ ਐਕਸੇਸ ਪੈਟਰਨ ਦੇ ਆਉਣ 'ਤੇ ਤੁਸੀਂ ਮੇਨ ਟੇਬਲ ਨੂੰ ਮੁੜ-ਡਿਜ਼ਾਈਨ ਕਰਨ ਦੀ ਥਾਂ ਇੱਕ ਇੰਡੈਕਸ ਜੋੜ ਸਕਦੇ ਹੋ ਜੋ ਉਨ੍ਹਾਂ ਆਈਟਮਾਂ ਨੂੰ ਵੱਖਰੀ ਕੁੰਜੀ 'ਤੇ ਰੀ-ਕੀ ਕਰਦਾ ਹੈ।
Global Secondary Index (GSI) ਆਪਣੀ partition key (ਅਤੇ ਵਿਕਲਪਕ sort key) ਰੱਖਦਾ ਹੈ ਜੋ ਮੇਨ ਟੇਬਲ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰ ਹੋ ਸਕਦੀ ਹੈ। ਇਹ “ਗਲੋਬਲ” ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਾਰੇ ਟੇਬਲ partitions 'ਤੇ ਫੈਲਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਵੀ ਸਮੇਂ ਜੋੜਿਆ ਜਾਂ ਹਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਤੁਹਾਨੂੰ ਕੋਈ ਨਵਾਂ ਐਕਸੇਸ ਪੈਟਰਨ ਚਾਹੀਦਾ ਹੈ ਜੋ ਅਸਲ ਕੀ ਡਿਜ਼ਾਇਨ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦਾ—ਉਦਾਹਰਣ ਵਜੋਂ, ਜਦੋਂ ਟੇਬਲ orderId ਦੇ ਨਾਲ ਕੀਡ ਹੈ ਪਰ ਤੁਾਨੂੰ customerId ਨਾਲ ਕਵੀਰੀ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇ—ਤਾਂ GSI ਵਰਤੋ।
Local Secondary Index (LSI) base table ਨਾਲ ਉਹੀ partition key ਸਾਂਝਾ ਕਰਦਾ ਹੈ ਪਰ ਵੱਖਰਾ sort key ਵਰਤਦਾ ਹੈ। LSIs ਨੂੰ ਟੇਬਲ ਬਣਾਉਂਦੇ ਸਮੇਂ ਹੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੁੰਦਾ ਹੈ। ਇਹ ਉਨ੍ਹਾਂ ਸਥਿਤੀਆਂ ਲਈ ਲਾਭਕਾਰੀ ਹਨ ਜਿੱਥੇ ਤੁਸੀਂ ਇੱਕੋ ਏਂਟਿਟੀ ਗਰੁੱਪ (ਉਸੇ partition key) ਦੇ ਅੰਦਰ ਕਈ sort ਆਰਡਰ ਚਾਹੁੰਦੇ ਹੋ—ਜਿਵੇਂ ਕਿਸੇ ਗ੍ਰਾਹਕ ਦੇ ਆਰਡਰ createdAt ਦੇ ਮੁਤਾਬਕ ਬਣਾਮ status ਦੇ ਮੁਤਾਬਕ।
Projection ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ DynamoDB ਇੰਡੈਕਸ ਵਿੱਚ ਕਿਹੜੇ attributes ਸਟੋਰ ਕਰਦਾ ਹੈ:
ਮੇਨ ਟੇਬਲ 'ਤੇ ਹਰ ਲਿਖਾਈ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਇੰਡੈਕਸਾਂ ਵਿੱਚ ਲਿਖਾਈਆਂ ਤਰ੍ਹਾਂ ਟ੍ਰਿਗਰ ਹੋ ਸਕਦੀ ਹੈ। ਹੋਰ GSIs ਅਤੇ ਵਿਆਪਕ ਪ੍ਰੋਜੇਕਸ਼ਨ ਲਿਖਾਈਆਂ ਦੀ ਲਾਗਤ ਅਤੇ ਕੈਪੇਸਿਟੀ ਖਪਤ ਵਧਾਉਂਦੀਆਂ ਹਨ। ਇੰਡੈਕਸਾਂ ਨੂੰ ਸਥਿਰ ਐਕਸੇਸ ਪੈਟਰਨਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਯੋਜਨਾ ਬਣਾਉ ਅਤੇ ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ ਪ੍ਰੋਜੈਕਟ ਕੀਤੀਆਂ attributes ਘੱਟ ਰੱਖੋ।
DynamoDB ਦੀ ਸਕੇਲਿੰਗ ਇੱਕ ਚੋਣ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ: On-Demand ਜਾਂ Provisioned ਕੈਪੇਸਿਟੀ। ਦੋਹਾਂ ਨੇ ਬਹੁਤ ਉੱਚ throughput ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਬਦਲਦੇ ਟ੍ਰੈਫਿਕ ਹੇਠਾਂ ਵੱਖ-ਵੱਖ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੇ ਹਨ।
On-Demand ਸਭ ਤੋਂ ਸਧਾਰਨ ਹੈ: ਤੁਸੀਂ ਹਰ ਬੇਨਤੀ ਲਈ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ ਅਤੇ DynamoDB ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਬਦਲਦਿਆਂ ਲੋਡ ਦੇ ਅਨੁਸਾਰ ਅਨੁਕੂਲਤਾ ਦਿੰਦਾ ਹੈ। ਇਹ ਅਣਪੇਸ਼ਕਸ ਟ੍ਰੈਫਿਕ, ਸ਼ੁਰੂਆਤੀ ਉਤਪਾਦ, ਅਤੇ ਸਪਾਈਕੀ ਵਰਕਲੋਡ ਲਈ ਵਧੀਆ ਹੈ।
Provisioned ਕੈਪੇਸਿਟੀ ਯੋਜਨਾ ਬਣਾਉਣ ਹੈ: ਤੁਸੀਂ ਪੜ੍ਹਾਈ ਅਤੇ ਲਿਖਾਈ throughput ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋ (ਜਾਂ auto-scale) ਅਤੇ ਮੁੜ-ਮੁੜ ਵਰਤੇ ਜਾਣ 'ਤੇ ਵੱਧ ਪੇਸ਼ਗੋਈਯੋਗ ਕੀਮਤ ਮਿਲਦੀ ਹੈ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਸਥਿਰ ਵਰਤੋਂ ਲਈ ਸਸਤਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਟੀਮਾਂ ਲਈ ਮਾਨਯੋਗ ਹੈ ਜੋ ਮਗਰੋ-ਮਗਰੋ ਡਿਮਾਂਡ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰ ਸਕਦੀਆਂ ਹਨ।
Provisioned throughput ਮਾਪਿਆ ਜਾਂਦਾ ਹੈ:
ਤੁਹਾਡੇ item ਦਾ ਆਕਾਰ ਅਤੇ ਐਕਸੇਸ ਪੈਟਰਨ ਅਸਲੀ ਖ਼ਰਚ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ: ਵੱਡੇ items, strong consistency, ਅਤੇ scans ਕੈਪੇਸਿਟੀ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਖਤਮ ਕਰ ਸਕਦੇ ਹਨ।
Auto scaling provisioned RCUs/WCUs ਨੂੰ ਵਰਤੋਂ ਦੇ ਲਕੜਾਂ ਦੇ ਅਨੁਸਾਰ ਅਨੁਕੂਲ ਕਰਦਾ ਹੈ। ਇਹ ਧੀਰੇ ਤੇ ਵਧਣ ਅਤੇ ਪੇਸ਼ਗੋਈਯੋਗ ਚੱਕਰਾਂ ਲਈ ਮਦਦਗਾਰ ਹੈ, ਪਰ ਇਹ ਤੁਰੰਤ ਨਹੀਂ ਹੁੰਦਾ। ਅਚਾਨਕ spike ਹਜੇ ਵੀ throttle ਕਰ ਸਕਦੇ ਹਨ ਜੇ capacity ਤੇਜ਼ੀ ਨਾਲ ਨਹੀਂ ਵਧਦੀ, ਅਤੇ ਇਹ ਇੱਕ ਹਾਟ partition key ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦਾ।
DynamoDB Accelerator (DAX) ਇੱਕ ਇਨ-ਮੇਮੋਰੀ cache ਹੈ ਜੋ ਰੀਡ ਲੇਟੈਂਸੀ ਘਟਾ ਸਕਦਾ ਅਤੇ ਦੁਹਰਾਏ ਗਏ ਰੀਡਸ ਨੂੰ offload ਕਰ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਣ ਲਈ, ਲੋਕਪ੍ਰਿਯ ਉਤਪਾਦ ਪੇਜ, session lookups, leaderboards)। ਇਹ ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਲਈ ਸਭ ਤੋਂ ਲਾਭਕਾਰੀ ਹੈ ਜਿੱਥੇ ਬਹੁਤ ਸਾਰੇ ਕਲਾਇੰਟ ਇੱਕੋ items ਨੂੰ ਦੁਹਰਾਉਂਦੇ ਹਨ; ਇਹ write-ਭਾਰੀ ਪੈਟਰਨਾਂ ਵਿੱਚ ਮਦਦ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਇਹ ਸੰਭਾਲੇ ਹੋਏ ਕੀ ਡਿਜ਼ਾਇਨ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ।
DynamoDB ਤੁਹਾਨੂੰ ਪੜ੍ਹਾਈ ਦੀਆਂ ਗਾਰੰਟੀਆਂ ਨੂੰ ਲੇ ਕੇ ਲੇਟੈਂਸੀ ਅਤੇ ਲਾਗਤ ਦੇ ਵਿਚਕਾਰ ਵਪਾਰ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਹਰ ਆਪਰੇਸ਼ਨ ਲਈ "ਸਹੀ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ ਇਹ ਸਪਸ਼ਟ ਹੋਣਾ ਜ਼ਰੂਰੀ ਹੈ।
ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ, GetItem ਅਤੇ Query eventually consistent ਪੜ੍ਹਾਈਆਂ ਵਰਤਦੇ ਹਨ: ਤੁਸੀਂ ਲਿਖਾਈ ਦੇ ਬਾਅਦ ਥੋੜ੍ਹੀ ਦੇਰ ਲਈ ਪੁਰਾਣਾ ਮੁੱਲ ਦੇਖ ਸਕਦੇ ਹੋ। ਇਹ feeds, product catalogs, ਅਤੇ ਹੋਰ ਰੀਡ-ਮੁੱਖ ਦਰਸ਼ਨਾਂ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਠੀਕ ਹੁੰਦਾ ਹੈ।
Strongly consistent ਪੜ੍ਹਾਈਆਂ (ਇੱਕ ਖੇਤਰ ਵਿੱਚ ਬੇਨਤੀ ਲਈ ਵਿਕਲਪ) ਯਕੀਨੀ ਬਣਾਉਂਦੀਆਂ ਹਨ ਕਿ ਤੁਸੀਂ ਸਭ ਤੋਂ ਨਵੀਂ ਸਵੀਕਾਰ ਕੀਤੀ ਲਿਖਾਈ ਵੇਖਦੇ ਹੋ। Strong consistency ਵੱਧ ਰੀਡ ਕੈਪੇਸਿਟੀ ਲੈਂਦੀ ਹੈ ਅਤੇ tail latency ਵਧਾ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਸਿਰਫ਼ ਅਸਲ ਚਾਹਵੀਂ ਪੜ੍ਹਾਈਆਂ ਲਈ ਰੱਖੋ।
Strong consistency ਉਹਨਾਂ ਪੜ੍ਹਾਈਆਂ ਲਈ ਕੀਮਤੀ ਹੈ ਜੋ irreversible ਕਾਰਵਾਈਆਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦੀਆਂ ਹਨ:
ਕਾਊਂਟਰਾਂ ਲਈ, ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਰਵੱਈਆ ਆਮ ਤੌਰ 'ਤੇ “strong read ਫਿਰ write” ਨਹੀਂ, ਪਰ ਇੱਕ atomic update (ਜਿਵੇਂ UpdateItem ਨਾਲ ADD) ਹੈ ਤਾਂ ਜੋ increments ਖੋ ਨਾ ਜਾਣ।
DynamoDB ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ (TransactWriteItems, TransactGetItems) ACID semantics ਦਿੰਦੀਆਂ ਹਨ 25 items ਤੱਕ। ਇਹ ਉਨ੍ਹਾਂ ਹੇਠਾਂ ਵਰਤੇ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਤੁਹਾਨੂੰ ਇਕੱਠੇ ਕਈ items ਅਪਡੇਟ ਕਰਨੇ ਹੋਣ—ਜਿਵੇਂ ਇੱਕ ਆਰਡਰ ਲਿਖਣਾ ਅਤੇ ਇਨਵੈਂਟਰੀ ਰਿਜ਼ਰਵ ਕਰਨਾ—ਜਾਂ ਅਜਿਹੇ ਇਨਵੈਰੀਆਂਸਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਜੋ ਦਰਮਿਆਨ-ਅਵਸਥਾਵਾਂ ਬਰਦਾਸ਼ਤ ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ।
Retries ਵਿਤਰਿਤ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਆਮ ਗੱਲ ਹਨ। ਲਿਖਾਈਆਂ ਨੂੰ idempotent ਬਣਾਓ ਤਾਂ ਜੋ ਰੀ-ਟ੍ਰਾਈਜ਼ ਦੁਆਰਾ ਪ੍ਰਭਾਵ ਦੋਹਰਾਏ ਨਾ ਜਾਣ:
ConditionExpression ਨਾਲ uniqueness ਨੂੰ enforce ਕਰੋ (ਉਦਾਹਰਣ: “only create if attribute_not_exists”)DynamoDB ਵਿੱਚ ਸਹੀਟਾ ਜਿਆਦਾਤਰ ਇਸ ਦਿੱਖ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਸਹੀ consistency ਲੈਵਲ ਚੁਣੋ ਅਤੇ retry-ਸੁਰੱਖਿਅਤ ਓਪਰੇਸ਼ਨਾਂ ਲਈ ਡਿਜ਼ਾਇਨ ਕਰੋ।
DynamoDB ਟੇਬਲ ਡੇਟਾ ਨੂੰ ਕਈ ਫਿਜ਼ੀਕਲ partitions ਵਿੱਚ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਹਰ partition ਦੀ ਪੜ੍ਹਾਈ ਅਤੇ ਲਿਖਾਈ ਲਈ ਸੀਮਿਤ throughput ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਸਦੇ ਕੋਲ ਡੇਟਾ ਰੱਖਣ ਦੀ ਸੀਮਾ ਵੀ ਹੁੰਦੀ ਹੈ। ਤੁਹਾਡੀ partition key ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ ਕੋਈ item ਕਿੱਥੇ ਰਹੇਗਾ; ਜੇ ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਇੱਕੋ partition key ਮੁੱਲ (ਜਾਂ ਛੋਟੇ ਮੁੱਲਾਂ ਦੇ ਸੈੱਟ) ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਤਾਂ ਉਹ partition ਬੋਤਲਨੈਕ ਬਣ ਜਾਂਦਾ ਹੈ।
ਹਾਟ partitions ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਸ਼ੁਰੂਆਂ ਤੋਂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਕੀ ਚੋਣ ਟ੍ਰੈਫਿਕ ਨੂੰ ਕੇਂਦਰਤ ਕਰ ਦਿੰਦੀ ਹੈ: USER#1, TENANT#default, ਜਾਂ STATUS#OPEN ਵਰਗਾ "ਗਲੋਬਲ" partition key, ਜਾਂ ਸਮੇ-ਅਨੁਕ੍ਰਮਿਕ ਪੈਟਰਨ ਜਿੱਥੇ ਹਰ ਕੋਈ ਇੱਕੋ partition key ਦੇ "ਹੁਣ" ਉੱਤੇ ਲਿਖਦਾ ਹੈ।
ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਵੇਖੋਗੇ:
ProvisionedThroughputExceededException)ਪਹਿਲਾਂ distribution ਲਈ ਡਿਜ਼ਾਇਨ ਕਰੋ, ਫਿਰ ਕਵੇਰੀ ਸੁਵਿਧਾ:
TENANT#\u003cid\u003e ਸਾਂਝੇ constant ਦੀ ਥਾਂ)ORDER#\u003cid\u003e#\u003cshard\u003e) ਜੋ N shards 'ਤੇ ਲਿਖਾਈ ਵੰਡੇ, ਅਤੇ ਲੋੜ ਪੈਣ 'ਤੇ shards 'ਤੇ ਕਵੇਰੀ ਕਰੋMETRIC#2025-12-22T10) ਤਾਂ ਜੋ “ਸਭ ਲਿਖਾਈਆਂ ਹਮੇਸ਼ਾ ਨਵੇਂ item ‘ਤੇ ਨਾ ਜਾਣ।”ਅਣਪੇਸ਼ਕਸ spikes ਲਈ, on-demand capacityBurst ਨੂੰ ਜ਼ਿਆਦਾਤਰ ਹਾਲਤਾਂ ਵਿੱਚ ਅੱਡਾਪਟ ਕਰ ਸਕਦਾ ਹੈ (ਸੇਵਾ ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ)। Provisioned ਮੋਡ ਵਿੱਚ, auto scaling ਵਰਤੋਂ ਅਤੇ throttles 'ਤੇ client-ਸਾਈਡ exponential backoff with jitter ਲਾਗੂ ਕਰੋ ਤਾਂ ਜੋ synchronized retries spike ਨੂੰ ਹੋਰ ਵਧਾਉਣ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕੇ।
DynamoDB ਡੇਟਾ ਮਾਡਲਿੰਗ ਐਕਸੇਸ ਪੈਟਰਨਾਂ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਨਾ ਕਿ ER diagrams ਤੋਂ। ਤੁਸੀਂ ਕੁੰਜੀਆਂ ਇੰਝ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹੋ ਤਾਂ ਕਿ ਜਿਨ੍ਹਾਂ ਕਵੇਰੀਆਂ ਦੀ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ ਉਹ ਤੇਜ਼ Query ਆਪਰੇਸ਼ਨ ਬਣ ਜਾਣ, ਅਤੇ ਹੋਰ ਸਾਰਾ ਕੰਮ ਜਾਂ ਤਾਂ ਬਚਿਆ ਜਾਂ asynchronous ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ ਜਾਵੇ।
“Single-table design” ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਈ ਐਂਟਿਟੀ ਕਿਸਮਾਂ (users, orders, messages) ਨੂੰ ਇੱਕ ਹੀ ਟੇਬਲ ਵਿੱਚ ਰੱਖਣਾ ਅਤੇ ਸਮਾਨ ਕੀ ਕਨਵੈਨਸ਼ਨਾਂ ਵਰਤਦੇ ਹੋਏ ਸਬੰਧਿਤ ਡੇਟਾ ਨੂੰ ਇੱਕ Query ਨਾਲ ਪ੍ਰਾਪਤ ਕਰਨ ਯੋਗ ਬਣਾਉਣਾ। ਇਸ ਨਾਲ ਕ੍ਰਾਸ-ਏਂਟਿਟੀ ਰਾਊਂਡ-ਟ੍ਰਿਪ ਘਟਦੀਆਂ ਹਨ ਅਤੇ ਲੇਟੈਂਸੀ ਪੇਸ਼ਗੋਈਯੋਗ ਰਹਿੰਦੀ ਹੈ।
ਆਮ ਪਹੁੰਚ ਕਾਂਪੋਜ਼ਿਟ ਕੀਜ਼ ਹੈ:
PK ਇੱਕ ਲਾਜਿਕਲ partition ਗਰੁੱਪ (ਉਦਾਹਰਣ: USER#123)SK ਉਸ ਗਰੁੱਪ ਦੇ ਅੰਦਰ ਆਈਟਮਾਂ ਨੂੰ ਕ੍ਰਮਬੱਧ ਕਰਦੀ ਹੈ (ਉਦਾਹਰਣ: PROFILE, ORDER#2025-12-01, MSG#000123)ਇਸ ਨਾਲ ਤੁਸੀਂ “ਉਸ ਯੂਜ਼ਰ ਲਈ ਸੱਬ ਕੁਝ” ਜਾਂ “ਸਿਰਫ਼ ਉਸ ਯੂਜ਼ਰ ਦੇ ਆਰਡਰ” ਨੂੰ sort-key prefix ਦੀ ਚੋਣ ਨਾਲ ਫੈਚ ਕਰ ਸਕਦੇ ਹੋ।
ਗ੍ਰਾਫ-ਜਿਹੇ ਰਿਸ਼ਤਿਆਂ ਲਈ, ਇੱਕ adjacency list ਚੰਗੀ ਕੰਮ ਆਉਂਦੀ ਹੈ: edges ਨੂੰ items ਵਜੋਂ ਸਟੋਰ ਕਰੋ।
PK = USER#123, SK = FOLLOWS#USER#456ਰਿਵਰਸ ਲੁਕਅਪ ਜਾਂ ਸੱਚੀ many-to-many ਨੂੰ ਸਪੋਰਟ ਕਰਨ ਲਈ, ਇੱਕ inverted edge item ਜੋੜੋ ਜਾਂ ਪੜ੍ਹਨ ਦੇ ਰਾਸਤੇ ਦੇ ਆਧਾਰ 'ਤੇ GSI 'ਤੇ ਪ੍ਰੋਜੈਕਟ ਕਰੋ।
ਈਵੈਂਟਸ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਲਈ, ਅਨੰਤ partitions ਤੋਂ ਬਚਣ ਲਈ ਬੱਕੇਟਿੰਗ ਕਰੋ:
PK = DEVICE#9#2025-12-22 (ਡਿਵਾਈਸ + ਦਿਨ)SK = TS#1734825600 (ਟਾਈਮਸਟੈਂਪ)TTL ਵਰਤ ਕੇ ਪੁਰਾਣੇ ਪੌਇੰਟ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਖਤਮ ਕਰ ਦਿਓ, ਅਤੇ ਢੇਰ-ਘੰਟੇ/ਦਿਨਾ aggregate items ਨੂੰ ਵੱਖ-ਵੱਖ ਰੱਖੋ ਤਾਂ ਕਿ dashboards ਤੇ ਤੇਜ਼ ਪੁਕਾਰ ਹੋ ਸਕੇ।
If you want a deeper refresher on key conventions, see /blog/partition-key-and-sort-key-design.
DynamoDB Streams DynamoDB ਦਾ ਨਿਰਮਿਤ change data capture (CDC) ਫੀਡ ਹੈ। ਜਦੋਂ ਇੱਕ ਟੇਬਲ 'ਤੇ Streams ਐਨੇਬਲ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਹਰ insert, update, ਜਾਂ delete ਇੱਕ stream record ਬਣਾਉਂਦਾ ਹੈ ਜਿਸ 'ਤੇ ਡਾਉਨਸਟ੍ਰੀਮ ਕੰਜਿਊਮਰ ਪਰਤਿਕਿਰਿਆ ਕਰ ਸਕਦੇ ਹਨ—ਬਿਨਾਂ ਟੇਬਲ ਨੂੰ ਪੋਲਿੰਗ ਕੀਤੇ।
ਇੱਕ stream record ਵਿੱਚ ਕੁੰਜੀਆਂ ਅਤੇ (ਵਿਕਲਪਿਕ ਤੌਰ 'ਤੇ) ਆਈਟਮ ਦੀ ਪੁਰਾਣੀ ਅਤੇ/ਜਾਂ ਨਵੀਂ ਇਮੇਜ ਹੁੰਦੀ ਹੈ, ਜੋ ਕਿ ਤੁਸੀਂ stream view type ਚੁਣਦੇ ਹੋ ਉਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ (keys only, new image, old image, both). Records ਨੂੰ shards ਵਿੱਚ ਗਰੂਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਲਗਾਤਾਰ ਪੜ੍ਹਦੇ ਹੋ।
ਅਮਲਗਤ ਵਿਉਂਤ DynamoDB Streams → AWS Lambda ਹੈ, ਜਿੱਥੇ ਹਰ record ਬੈਚ ਇੱਕ ਫੰਕਸ਼ਨ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ। ਹੋਰ ਕੰਜਿਊਮਰ ਵੀ ਸੰਭਵ ਹਨ (ਕਸਟਮ ਕੰਜਿਊਮਰ, ਜਾਂ analytics/logging ਸਿਸਟਮਾਂ ਵਿੱਚ ਪਾਈਪ ਕਰਨ ਵਾਲੇ)।
ਆਮ ਵਰਕਫਲੋਜ਼ ਸ਼ਾਮਲ ਹਨ:
ਇਸ ਨਾਲ ਪ੍ਰਾਇਮਰੀ ਟੇਬਲ ਘੱਟ-ਲੇਟੈਂਸੀ ਰੀਡਸ/ਰਾਈਟਸ ਲਈ optimized ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਪਰਿਵਤਨਸੰਬੰਧੀ ਕੰਮ asynchronous consumers ਨੂੰ ਧਕੇਲ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
Streams shard-ਪੱਧਰ 'ਤੇ ordered processing ਦਿੰਦੇ ਹਨ (ਅਕਸਰ partition key ਨਾਲ ਸੰਬੰਧਿਤ), ਪਰ ਗਲੋਬਲ ਆਰਡਰਿੰਗ ਨਹੀਂ ਹੁੰਦੀ। ਡਿਲਿਵਰੀ at-least-once ਹੈ, ਇਸ ਲਈ duplicates ਹੋ ਸਕਦੇ ਹਨ।
ਇਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸੰਭਾਲਣ ਲਈ:
ਇਨ੍ਹਾਂ ਗਾਰੰਟੀਜ਼ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ, Streams DynamoDB ਨੂੰ ਇੱਕ ਮਜ਼ਬੂਤ ਬੈਕਬੋਨ ਬਣਾਉਂਦੇ ਹਨ ਇवੈਂਟ-ਡ੍ਰੀਵਨ ਸਿਸਟਮਾਂ ਲਈ।
DynamoDB ਉੱਚ ਉਪਲਬਧਤਾ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ, ਖੇਤਰ ਦੇ ਅੰਦਰ ਕਈ Availability Zones 'ਤੇ ਡੇਟਾ ਫੈਲਾਕੇ। ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਲਈ ਅਸਲੀ ਭਰੋਸਾ ਸਫਲਤਾ ਇੱਕ ਸਾਫ਼ ਬੈਕਅੱਪ ਰਣਨੀਤੀ, ਨਕਲ ਵਿਕਲਪਾਂ ਦੀ ਸਮਝ, ਅਤੇ ਸਹੀ ਮੈਟ੍ਰਿਕਸ ਦੀ ਨਿਗਰਾਨੀ ਰੱਖਣ ਵਿੱਚ ਆਉਂਦਾ ਹੈ।
On-demand backups ਮੈਨੁਅਲ (ਜਾਂ ਆਟੋਮੇਟਿਕ) snapshots ਹਨ ਜੋ ਤੁਸੀਂ ਕਿਸੇ ਜਾਣੂ ਰੀਸਟੋਰ ਪੁਆਇੰਟ ਲਈ ਲੈਂਦੇ ਹੋ—ਮਾਈਗ੍ਰੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ, ਰਿਲੀਜ਼ ਦੇ ਬਾਅਦ, ਜਾਂ ਕਿਸੇ ਵੱਡੇ ਬੈਕਫਿੱਲ ਤੋਂ ਪਹਿਲਾਂ। ਇਹ "ਬੁੱਕਮਾਰਕ" ਮੋਮੈਂਟ ਲਈ ਵਧੀਆ ਹਨ।
Point-in-time recovery (PITR) ਲਗਾਤਾਰ ਬਦਲਾਅ ਕੈਪਚਰ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਟੇਬਲ ਨੂੰ ਰਿਟੈਂਸ਼ਨ ਵਿੰਡੋ ਦੇ ਕਿਸੇ ਵੀ ਸਕਿੰਡ 'ਤੇ ਰੀਸਟੋਰ ਕਰ ਸਕੋ। PITR ਅਕਸਿਲ਼-ਡਿਲੀਟ, ਖਰਾਬ ਡਿਪਲਾਇ, ਜਾਂ ਮਾਲਫਾਰਮਡ ਲਿਖਾਈਆਂ ਲਈ ਸੇਫਟੀ ਨੈੱਟ ਹੈ।
ਜੇ ਤੁਹਾਨੂੰ ਮਲਟੀ-ਰੀਜਨ ਰੀਜ਼ੀਲੀਅੰਸ ਜਾਂ ਉਪਭੋਗਤਿਆਂ ਦੇ ਨੇੜੇ ਘੱਟ-ਲੇਟੈਂਸੀ ਰੀਡ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ Global Tables ਡੇਟਾ ਨੂੰ ਚੁਣੀਆਂ ਹੋਈਆਂ ਰੀਜਨਾਂ ਵਿੱਚ ਰੈਪਲੀਕੇਟ ਕਰਦੀਆਂ ਹਨ। ਇਹ failover ਯੋਜਨਾ ਬਣਾਉਣਾ ਸੁਗਮ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਪਰ ਇਸ ਨਾਲ cross-region ਰੈਪਲੀਕੇਸ਼ਨ ਦੇ ਡਿਲੇ ਅਤੇ conflict-resolution ਬਿੰਦੂ ਆ ਜਾਂਦੇ ਹਨ—ਇਸ ਲਈ ਲਿਖਣ ਦੇ ਪੈਟਰਨ ਅਤੇ item ownership ਨੂੰ ਸਾਫ਼ ਰੱਖੋ।
ਘੱਟੋ-ਘੱਟ, ਇਨ੍ਹਾਂ 'ਤੇ ਅਲਾਰਮ ਰੱਖੋ:
ਇਹ ਸੰਕੇਤ ਅਕਸਰ ਹਾਟ-ਪਾਰਟੀਸ਼ਨ ਮੁੱਦੇ, ਅਪਰਿਆਪਤ ਕੈਪੇਸਿਟੀ, ਜਾਂ ਅਣਜਾਣੇ ਐਕਸੇਸ ਪੈਟਰਨਾਂ ਨੂੰ ਬਾਹਰ ਲਿਆਉਂਦੇ ਹਨ।
Throttle ਹੋਣ ਤੇ, ਪਹਿਲਾਂ ਉਸ ਐਕਸੇਸ ਪੈਟਰਨ ਨੂੰ ਪਛਾਣੋ ਜੋ ਕਾਰਨ ਬਣ ਰਿਹਾ ਹੈ, ਫਿਰ ਰਾਹਤ ਲਈ ਅਸਥਾਈ ਤੌਰ 'ਤੇ on-demand ਵੇਖੋ ਜਾਂ provisioned capacity ਵਧਾਓ, ਅਤੇ ਹਾਟ ਕੀਜ਼ ਨੂੰ shard ਕਰਨ 'ਤੇ ਵਿਚਾਰ ਕਰੋ।
ਆੰਸ਼ਿਕ ਆਉਟੇਜ ਜਾਂ ਉੱਚ ਤਰਾਂ ਦੀਆਂ ਗਲਤੀਆਂ ਲਈ, ਨੁਕਸਾਨ ਘਟਾਓ: ਗੈਰ-ਮਹੱਤਵਪੂਰਨ ਟ੍ਰੈਫਿਕ ਨੂੰ ਦਿੜ੍ਹੋ, jittered backoff ਨਾਲ retry ਕਰੋ, ਅਤੇ ਟੇਬਲ ਸਥਿਰ ਹੋਣ ਤੱਕ cached reads ਵਰਗੇ graceful fallbacks ਦੇਵੋ।
DynamoDB ਸੁਰੱਖਿਆ ਜ਼ਿਆਦਾਤਰ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਕੌਣ ਕਿਹੜੀਆਂ API actions ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ, ਕਿੱਥੋਂ, ਅਤੇ ਕਿਹੜੀਆਂ keys 'ਤੇ। ਕਿਉਂਕਿ ਟੇਬਲਾਂ ਵਿੱਚ ਕਈ ਐਂਟਿਟੀ ਕਿਸਮਾਂ (ਅਤੇ ਕਈ ਵਾਰੀ ਕਈ tenants) ਹੁੰਦੀਆਂ ਹਨ, ਐਕਸੇਸ ਕੰਟਰੋਲ ਨੂੰ ਡੇਟਾ ਮਾਡਲ ਦੇ ਨਾਲ-ਨਾਲ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
identity-based IAM policies ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਕਾਰਵਾਈਆਂ (dynamodb:GetItem, Query, PutItem) ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਲੋੜ ਵਾਲੇ ਸੈੱਟ ਤੱਕ ਸੀਮਿਤ ਕਰਨ ਅਤੇ ਖਾਸ ਟੇਬਲ ARNs ਤੱਕ ਸਕੋਪ ਕਰਨ।
ਫਾਈਨ ਦਾ ਨਿਯੰਤਰਣ ਲਈ dynamodb:LeadingKeys ਵਰਤੋ ਤਾਂ ਜੋ partition key ਮੁੱਲਾਂ ਦੁਆਰਾ ਐਕਸੇਸ ਸੀਮਤ ਕੀਤਾ ਜਾ ਸਕੇ—ਇਹ ਤਦੋਂ ਜ਼ਰੂਰੀ ਹੈ ਜਦੋਂ ਇੱਕ ਸਰਵਿਸ ਜਾਂ ਟੇਨੈਂਟ ਸਿਰਫ਼ ਆਪਣੀ keyspace ਨੂੰ ਪੜ੍ਹ/ਲਿਖ ਸਕੇ।
DynamoDB defaults ਵਿੱਚ data at rest encrypt ਕਰਦਾ ਹੈ AWS owned keys ਜਾਂ customer-managed KMS ਕੀ ਨਾਲ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ compliance ਲੋੜਾਂ ਹਨ, ਤਾਂ ਇਹ ਚੀਜ਼ਾਂ ਜਾਂਚੋ:
Transit ਵਿੱਚ ਇਨਕ੍ਰਿਪਸ਼ਨ ਲਈ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ clients HTTPS ਵਰਤ ਰਹੇ ਹਨ (AWS SDKs ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਐਸਾ ਕਰਦੇ ਹਨ)। ਜੇ ਤੁਹਾਡਾ TLS ਇੱਕ ਪ੍ਰੋਕਸੀ 'ਤੇ terminate ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਪੱਕਾ ਕਰੋ ਕਿ ਪ੍ਰੋਕਸੀ ਅਤੇ DynamoDB ਦਰਮਿਆਨ ਵਾਲੀ ਹਾਪ ਵੀ ਇਨਕ੍ਰਿਪਟਡ ਰਹੇ।
DynamoDB ਲਈ VPC Gateway Endpoint ਵਰਤੋ ਤਾਂ ਕਿ ਟ੍ਰੈਫਿਕ AWS ਨੈੱਟਵਰਕ 'ਤੇ ਹੀ ਰਹੇ ਅਤੇ ਤੁਸੀਂ endpoint policies ਨਾਲ ਐਕਸੇਸ ਸੀਮਤ ਕਰ ਸਕੋ। ਇਸ ਨੂੰ egress controls (NACLs, security groups, ਅਤੇ routing) ਨਾਲ ਜੋੜੋ ਤਾਂ ਜੋ "ਕੋਈ ਵੀ ਪਬਲਿਕ ਇੰਟਰਨੈੱਟ ਤੱਕ ਪਹੁੰਚ ਸਕੇ" ਰਾਹਾਂ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ।
ਸਾਂਝੀ ਟੇਬਲਾਂ ਲਈ, partition key ਵਿੱਚ tenant identifier ਸ਼ਾਮਲ ਕਰੋ (ਉਦਾਹਰਣ: TENANT#\u003cid\u003e), ਫਿਰ tenant isolation ਨੂੰ IAM conditions dynamodb:LeadingKeys ਨਾਲ enforce ਕਰੋ।
ਜੇ ਤੁਹਾਨੂੰ ਜ਼ਿਆਦਾ ਮਜ਼ਬੂਤ ਆਇਸੋਲੇਸ਼ਨ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਹਰ ਟੇਨੈਂਟ ਲਈ ਵੱਖਰੀ ਟੇਬਲ (ਜਾਂ ਵਾਤਾਵਰਨ-ਵਾਰ) ਚਿੰਤ ਕਰੋ, ਅਤੇ ਜਦੋਂ operational ਸਾਦਗੀ ਅਤੇ ਲਾਗਤ ਦੀ ਬਚਤ ਇਸ ਤੋਂ ਵੱਧ ਜਰੂਰੀ ਹੋਵੇ ਤਦ shared-table designs ਰੱਖੋ।
DynamoDB ਅਕਸਰ "ਅਚੁਕ ਹੋਣ ਤੇ ਸਸਤਾ, ਅਸਪਸ਼ਟ ਹੋਣ ਤੇ ਮਹਿੰਗਾ" ਹੈ। ਖ਼ਰਚ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਐਕਸੇਸ ਪੈਟਰਨਾਂ ਦੇ ਅਨੁਸਾਰ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਉਹ ਹੈ ਜੋ ਇਹ ਪੈਟਰਨ ਸਪੱਸ਼ਟ ਕਰੇ।
ਤੁਹਾਡੀ ਬਿੱਲ ਮੁੱਖ ਰੂਪ ਵਿੱਚ ਇਹਨਾਂ ਚੀਜ਼ਾਂ ਦੁਆਰਾ ਬਣਦੀ ਹੈ:
ਇੱਕ ਆਮ ਹੈਰਾਨੀ: ਟੇਬਲ 'ਤੇ ਹਰ ਲਿਖਾਈ ਹਰ ਪ੍ਰਭਾਵਤ GSI ਵਿੱਚ ਵੀ ਲਿਖਾਈ ਬਣਾਉਂਦੀ ਹੈ, ਇਸ ਲਈ “ਸਿਰਫ਼ ਇਕ ਹੋਰ ਇੰਡੈਕਸ” ਲਿਖਾਈ ਖ਼ਰਚ ਨੂੰ ਗੁਣਾ ਕਰ ਸਕਦਾ ਹੈ।
ਚੰਗਾ key design waste ਘਟਾਉਂਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਅਕਸਰ Scan ਤੱਕ ਜਾ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਉਹ ਡੇਟਾ ਪੜ੍ਹ ਰਹੇ ਹੋ ਜੋ ਤੁਸੀਂ ਅੰਤੇ ਵਿੱਚ ਫੈਕਅਵੇ ਕਰ ਦਿੰਦੇ ਹੋ।
ਤਰਜੀਹ ਦਿਓ:
ਜੇ ਕੋਈ ਐਕਸੇਸ ਪੈਟਰਨ ਦੁਰਲਭ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਇੱਕ ਵੱਖਰੀ ਟੇਬਲ, ETL ਜੌਬ, ਜਾਂ cached read model ਰਾਹੀਂ ਸਰਵ ਕਰਨ 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਬਜਾਏ ਇਸ ਦੇ ਕਿ ਇੱਕ ਸਥਾਈ GSI ਬਣਾਇਆ ਜਾਵੇ।
ਛੋਟੀ ਉਮਰ ਵਾਲੀਆਂ items (sessions, temporary tokens, intermediate workflow state) ਨੂੰ ਆਟੋਮੈਟਿਕ ਮਿਟਾਉਣ ਲਈ TTL ਵਰਤੋ। ਇਹ ਸਟੋਰੇਜ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਇੰਡੈਕਸਾਂ ਨੂੰ ਛੋਟਾ ਰੱਖਦਾ ਹੈ।
Append-ਭਾਰੀ ਡੇਟਾ (events, logs) ਲਈ TTL ਨੂੰ sort-key ਡਿਜ਼ਾਇਨ ਨਾਲ ਜੋੜੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਸਿਰਫ਼ “ਤਾਜ਼ਾ” ਕੁਏਰੀਆਂ ਕਰੋ, ਅਤੇ history ਨੂੰ ਬਾਰ-ਬਾਰ ਛੇੜੋ ਨਾ।
Provisioned ਮੋਡ ਵਿੱਚ, ਹੌਲੀ ਬੇਸਲਾਈਨ ਸੈੱਟ ਕਰੋ ਅਤੇ ਅਸਲ ਮੈਟ੍ਰਿਕਸ ਦੇ ਆਧਾਰ 'ਤੇ auto scaling ਨਾਲ ਵਧਾਓ। On-demand ਵਿੱਚ, ਅਣਉਪਯੋਗ ਪੈਟਰਨ (ਵੱਡੇ items, chatty clients) ਨੂੰ ਦੇਖੋ ਜੋ request volume ਨੂੰ ਧੱਕਾ ਦੇ ਰਹੇ ਹਨ।
Scan ਨੂੰ ਆਖਰੀ ਚੋਣ ਰੱਖੋ—ਜਦੋਂ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਪੂਰੀ-ਟੇਬਲ ਪ੍ਰੋਸੈਸਿੰਗ ਦੀ ਲੋੜ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਆਫ-ਪੀਕ ਸਮੇਂ ਵਿੱਚ ਚਲਾਓ ਜਾਂ pagination ਅਤੇ backoff ਨਾਲ ਨਿਯੰਤਰਿਤ ਬੈਚ ਰਣ ਕਰੋ।
DynamoDB ਉਹਨਾਂ ਟਿਕਾਣਿਆਂ 'ਤੇ ਚਮਕਦਾ ਹੈ ਜਿੱਥੇ ਤੁਹਾਡੀ ਐਪ ਕੁਝ ਵਧ-ਨਿਰਧਾਰਿਤ ਐਕਸੇਸ ਪੈਟਰਨਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਦਰਜ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਬਹੁਤ ਵੱਡੇ ਸਕੇਲ 'ਤੇ ਲਗਾਤਾਰ ਘੱਟ-ਲੇਟੈਂਸੀ ਦੀ ਲੋੜ ਹੈ। ਜੇ ਤੁਸੀਂ ਆਪਣੀਆਂ ਰੀਡਸ ਅਤੇ ਰਾਈਟਸ upfront (partition key, sort key, ਅਤੇ ਕੁਝ ਇੰਡੈਕਸ) ਦੇ ਰੂਪ ਵਿੱਚ ਵੇਰਵਾ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਇਹ ਅਕਸਰ ਉੱਚ ਉਪਲਬਧ ਡੇਟਾ ਸਟੋਰ ਚਲਾਉਣ ਦਾ ਇੱਕ ਸਧਾਰਣ ਤਰੀਕਾ ਹੁੰਦਾ ਹੈ।
DynamoDB ਇੱਕ ਮਜ਼ਬੂਤ ਚੋਣ ਹੈ ਜਦੋਂ:
ਹੋਰ ਥਾਂ ਤੱਕ ਵੇਖੋ ਜੇ ਤੁਹਾਡੀਆਂ ਮੁੱਖ ਲੋੜਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਕਈ ਟੀਮ DynamoDB ਨੂੰ “hot” operational reads ਅਤੇ writes ਲਈ ਰੱਖਦੀਆਂ ਹਨ ਅਤੇ ਫਿਰ ਜੋੜਦੀਆਂ ਹਨ:
ਜੇ ਤੁਸੀਂ access patterns ਅਤੇ single-table conventions ਦੀ ਜਾਂਚ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੇਜ਼ੀ ਮੱਤੇਰ ਹੈ। ਟੀਮਾਂ ਕਈ ਵਾਰ ਆਲੇ-ਦੁਆਲੇ ਦੀ ਸਰਵਿਸ ਅਤੇ UI ਨੂੰ Koder.ai ਵਿੱਚ ਪ੍ਰੋਟੋਟਾਇਪ ਕਰਦੀਆਂ ਹਨ (ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਜੋ chat ਤੋਂ web, server, ਅਤੇ mobile apps ਬਣਾਉਂਦਾ ਹੈ) ਅਤੇ ਫਿਰ ਜਿਵੇਂ-ਤਿਵੇਂ ਅਸਲ ਕਵੇਰੀ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ key design ਨੂੰ ਦੁਬਾਰਾ ਤਰਤੀਬ ਦਿੰਦੀਆਂ ਹਨ। ਭਾਵੇਂ ਤੁਹਾਡੀ ਪ੍ਰੋਡਕਸ਼ਨ ਬੈਕਐਂਡ ਵੱਖਰੀ ਹੋਵੇ, ਤੇਜ਼ end-to-end ਪ੍ਰੋਟੋਟਾਇਪਸ ਇਹ ਦੱਸਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ ਕਿ ਕਿਹੜੇ ਕਵੇਰੀ Query ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਕਿਹੜੇ ਮਹਿੰਗੇ Scan ਬਣ ਸਕਦੇ ਹਨ।
ਪ੍ਰਮਾਣਿਤ ਕਰੋ: (1) ਤੁਹਾਡੇ ਵੱਡੇ ਕਵੇਰੀਆਂ ਜਾਣੇ ਹੋਏ ਹਨ ਅਤੇ key-ਅਧਾਰਤ ਹਨ, (2) correctness ਦੀਆਂ ਲੋੜਾਂ consistency ਮਾਡਲ ਨਾਲ ਮਿਲਦੀਆਂ ਹਨ, (3) ਉਮੀਦ ਕੀਤੇ item ਸਾਈਜ਼ ਅਤੇ ਵਿਕਾਸ ਦੀ ਸਮਝ ਹੈ, ਅਤੇ (4) ਲਾਗਤ ਮਾਡਲ (on-demand vs provisioned ਅਤੇ autoscaling) ਤੁਹਾਡੇ ਬਜਟ ਵਿੱਚ ਫਿੱਟ ਬੈਠਦਾ ਹੈ।
DynamoDB ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪ੍ਰਬੰਧਿਤ NoSQL ਡੇਟਾਬੇਸ ਹੈ ਜੋ AWS ਉੱਤੇ ਚਲਦਾ ਹੈ ਅਤੇ ਬਹੁਤ ਵੱਡੇ ਸਕੇਲ 'ਤੇ ਲਗਾਤਾਰ ਘੱਟ-ਲੇਟੈਂਸੀ ਪੜ੍ਹਾਈ/ਲਿਖਾਈ ਦੀਆਂ ਲੋੜਾਂ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ। ਟੀਮਾਂ ਇਹ ਤਦੋਂ ਵਰਤਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਕੁੰਜੀ-ਅਧਾਰਤ ਐਕਸੇਸ ਪੈਟਰਨ (ID ਰਾਹੀਂ ਲਿਆਉਣਾ, ਮਾਲਕ-ਅਨੁਸਾਰ ਸੂਚੀ, ਸਮੇਂ ਦੀ ਰੇਂਜ) ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਡੇਟਾਬੇਸ ਇੰਫ੍ਰਾਸਟ੍ਰਕਚਰ ਚਲਾਉਣ ਤੋਂ ਬਚਣਾ ਚਾਹੁੰਦੀਆਂ ਹਨ।
ਇਹ ਖਾਸ ਕਰਕੇ ਮਾਈਕਰੋਸਰਵਿਸਜ਼, ਸਰਵਰਲੈੱਸ ਐਪਲਿਕੇਸ਼ਨ ਅਤੇ ਇਵੈਂਟ-ਚਲਿਤ ਸਿਸਟਮਾਂ ਵਿੱਚ ਆਮ ਹੈ।
ਇੱਕ ਟੇਬਲ ਵਿੱਚ items ਹੁੰਦੇ ਹਨ (ਜਿਵੇਂ ਕਤਾਰਾਂ)। ਹਰ item ਇੱਕ ਲਚਕੀਲਾ ਸਮੂਹ ਹੁੰਦਾ ਹੈ ਜੋ attributes (ਕਾਲਮ ਵਰਗੇ) ਰੱਖਦਾ ਹੈ ਅਤੇ nested ਡੇਟਾ ਵੀ ਰੱਖ ਸਕਦਾ ਹੈ।
DynamoDB ਉਨ੍ਹਾਂ ਸਥਿਤੀਆਂ ਲਈ ਚੰਗਾ ਹੈ ਜਿੱਥੇ ਇੱਕ ਬੇਨਤੀ ਆਮ ਤੌਰ 'ਤੇ “ਪੂਰਾ ਏਂਟਿਟੀ” ਲੈਂਦੀ ਹੈ, ਕਿਉਂਕਿ items ਵਿੱਚ maps ਅਤੇ lists (JSON-ਵਰਗੇ ਸਟ੍ਰਕਚਰ) ਹੋ ਸਕਦੇ ਹਨ।
ਇੱਕ partition key (ਸਿਰਫ) ਇੱਕ item ਨੂੰ ਵਿਲੱਖਣ ਤੌਰ ਤੇ ਪਛਾਣਦਾ ਹੈ (ਸਾਦਾ ਪ੍ਰਾਇਮਰੀ ਕੀ)। ਇੱਕ partition key + sort key (ਕਾਂਪੋਜ਼ਿਟ ਕੀ) ਮਲਟੀਪਲ items ਨੂੰ ਇੱਕੋ partition key ਸਾਂਝੇ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ ਜਦਕਿ sort key ਉਹਨਾਂ ਨੂੰ ਵਿਲੱਖਣ ਅਤੇ ਕ੍ਰਮਬੱਧ ਰੱਖਦੀ ਹੈ।
ਕਾਂਪੋਜ਼ਿਟ ਕੀ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਪੈਟਰਨ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ:
ਜਦੋਂ ਤੁਸੀਂ partition key (ਅਤੇ ਈਕ ਮਹਾਂਕਮ sort key ਸ਼ਰਤ) ਦਿੱਤੀਆਂ ਹੋਣ, ਤਾਂ Query ਵਰਤੋਂ—ਇਹ ਤੇਜ਼ ਅਤੇ ਸਕੇਲਬਲ ਰਸਤਾ ਹੈ।
Scan ਸਿਰਫ਼ ਤਦੋਂ ਵਰਤੋ ਜਦੋਂ ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ ਸਾਰੀ ਟੇਬਲ ਪੜ੍ਹਨੀ ਹੈ; ਇਹ ਪੂਰੀ ਟੇਬਲ ਜਾਂ ਇੰਡੈਕਸ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਫਿਰ ਛਾਣਦਾ ਹੈ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਮਹਿੰਗਾ ਅਤੇ ਹੌਲਾ ਹੁੰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਬਾਰ-ਬਾਰ Scan ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਇਸ ਗੱਲ ਦਾ ਇਸ਼ਾਰਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੀ ਜਾਂ ਇੰਡੈਕਸ ਡਿਜ਼ਾਇਨ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
ਸੈਕੰਡਰੀ ਇੰਡੈਕਸ ਵੱਖਰੇ ਕਵੈਰੀ ਮਾਰਗ ਪੈਦਾ ਕਰਦੇ ਹਨ।
ਯਾਦ ਰੱਖੋ: ਇੰਡੈਕਸਾਂ ਨਾਲ ਲਿਖਾਈ ਖ਼ਰਚ ਵੱਧਦੀ ਹੈ ਕਿਉਂਕਿ ਲਿਖਾਈਆਂ ਇੰਡੈਕਸਾਂ ਵਿੱਚ ਵੀ ਰਿਕਾਰਡ ਹੁੰਦੀਆਂ ਹਨ।
On-Demand ਚੁਣੋ ਜੇ ਟ੍ਰੈਫਿਕ ਅਣਪੇਸ਼ਕਸ ਅਤੇ ਝਟਕਿਆਂ ਵਾਲੀ ਹੋਵੇ ਜਾਂ ਤੁਸੀਂ capacity ਨਹੀਂ ਸੰਭਾਲਣਾ ਚਾਹੁੰਦੇ। ਤੁਸੀਂ ਹਰ ਬੇਨਤੀ ਲਈ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ।
Provisioned ਚੁਣੋ ਜੇ ਵਰਤੋਂ مستقًم/ਪੇਸ਼ਗੋਈਯੋਗ ਹੈ ਅਤੇ ਤੁਸੀਂ ਲਾਗਤ ਨੂੰ ਕਾਬੂ 'ਚ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹੋ; ਇਸ ਨੂੰ auto scaling ਨਾਲ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ ਪਰ ਇਹ ਤੁਰੰਤ ਹਰ spike ਨੂੰ ਨਹੀਂ ਭਰਪਾਈ ਕਰੇਗਾ।
ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਪੜ੍ਹਾਈਆਂ eventually consistent ਹੁੰਦੀਆਂ ਹਨ: ਲਿਖਾਈ ਦੇ ਬਾਅਦ ਅਸੋਰੇ ਸਮੇਂ ਲਈ ਤੁਸੀਂ ਥੋੜ੍ਹਾ ਪੁਰਾਣਾ ਮੁੱਲ ਦੇਖ ਸਕਦੇ ਹੋ।
Strongly consistent ਪੜ੍ਹਾਈਆਂ (ਜਦ ਉਪਲੱਬਧ) ਉਹ 최신 ਲਿਖਾਈ ਦਿਖਾਉਂਦੀਆਂ ਹਨ, ਪਰ ਇਹ ਵੱਧ ਰੀਡ ਖ਼ਰਚ ਅਤੇ ਲੇਟੈਂਸੀ ਲੈ ਸਕਦੀਆਂ ਹਨ।
Concurrency ਵਿੱਚ ਸਹੀ ਨਤੀਜੇ ਲਈ ਆਮ ਤੌਰ 'ਤੇ atomic updates (ਜਿਵੇਂ UpdateItem ਨਾਲ ADD) ਦੀ ਸਿਫਾਰਿਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
Transactions (TransactWriteItems, TransactGetItems) ACID ਗਾਰੰਟੀ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ 25 items ਤੱਕ ਕੰਮ ਕਰਦੀਆਂ ਹਨ.
ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਤੋ ਜਦੋਂ ਤੁਹਾਨੂੰ ਕਈ items ਨੂੰ ਇੱਕੱਠੇ ਅਪਡੇਟ ਕਰਨਾ ਹੋਵੇ (ਜਿਵੇਂ ਆਰਡਰ ਬਣਾਉਣਾ ਅਤੇ ਇਨਵੈਂਟਰੀ ਰਿਜ਼ਰਵ ਕਰਨਾ) ਜਾਂ ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਜਿੱਥੇ ਅਧੂਰੇ ਅਪਡੇਟ ਸਹਿਣਯੋਗ ਨਹੀਂ।
ਇਹ ਮਹਿੰਗੀਆਂ ਅਤੇ ਲੈਟੈਂਸੀ ਵਧਾਉਂਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਸਿਰਫ਼ ਉਹੀ ਫਲੋਜ਼ ਲਈ ਵਰਤੋ ਜੋ ਸੱਚਮੁੱਚ ਲੋੜੀਦੇ ਹਨ।
ਜਦੋਂ ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਇੱਕੋ partition key 'ਤੇ ਕੇਂਦਰਤ ਹੋ ਜੰਦੀਆਂ ਹਨ ਤਾਂ hot partitions ਬਣਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਕੁਝ ਕੀਜ਼ ਲਈ throttling ਹੁੰਦੀ ਹੈ ਭਾਵੇਂ ਟੇਬਲ ਹੋਰਥਾਂ ਖਾਲੀ ਹੋਵੇ।
ਆਮ ਰਾਹਤਾਂ:
DynamoDB Streams ਨੂੰ ਸਰਗਰਮ ਕਰਕੇ ਤੁਸੀਂ inserts, updates, ਅਤੇ deletes ਲਈ ਇੱਕ change feed ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ। ਆਮ ਪੈਟਰਨ ਹੈ Streams → Lambda ਜਿਥੇ ਹਰ ਬੈਚ records ਇੱਕ ਫੰਕਸ਼ਨ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ।
ਮੁੱਖ ਗਰਾਂਟੀਜ਼:
ਕੰਜ਼ਿਊਮਰਾਂ ਨੂੰ idempotent ਬਣਾਓ (ਉਪਰਸੈਟ ਦੁਆਰਾ, conditional writes, ਜਾਂ ਪ੍ਰੋਸੈਸ ਕੀਤੇ ਇਵੈਂਟ IDs ਟਰੈਕ ਕਰਕੇ)।