1 ਅਰਬ ਤੋਂ ਵੱਧ ChatGPT ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਔਨਲਾਈਨ ਸਟੋਰੇਜ ਤੇਜ਼ੀ ਨਾਲ ਸਕੇਲ ਕਰਨਾ (ਭਾਗ II)

OpenAI ਦੇ ਸਾਰੇ ਉਤਪਾਦਾਂ ਨੂੰ ਸਾਡੇ ਸਟੋਰੇਜ ਪਲੇਟਫਾਰਮ, Habitat ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਡਾਟਾ ਤੱਕ ਤੇਜ਼ ਅਤੇ ਭਰੋਸੇਯੋਗ ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸ ਨੂੰ 40 ਭੂਗੋਲਿਕ ਖੇਤਰਾਂ ਵਿੱਚ 1 ਅਰਬ ਤੋਂ ਵੱਧ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਮਿਲੀਸਕਿੰਡਾਂ ਵਿੱਚ ਜਵਾਬ ਦੇਣਾ ਪੈਂਦਾ ਹੈ। ਸਾਡੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਅਸਾਧਾਰਨ ਚੁਣੌਤੀ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ: ਭਰੋਸੇਯੋਗਤਾ, ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਉਤਪਾਦ ਵਿਕਾਸ ਦੀ ਰਫ਼ਤਾਰ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨਾ ਜਾਰੀ ਰੱਖਣਾ, ਬੇਹੱਦ ਤੇਜ਼ ਵਾਧੇ ਅਤੇ ਨਵੀਆਂ ਵਰਤੋਂ ਦੀਆਂ ਸਥਿਤੀਆਂ ਦਾ ਸਮਰਥਨ ਕਰਨਾ। ਇਸ ਚੁਣੌਤੀ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਸਾਨੂੰ ਆਪਣੇ ਔਨਲਾਈਨ ਸਟੋਰੇਜ ਪਲੇਟਫਾਰਮ ਦੇ ਡਿਜ਼ਾਈਨ ਅਤੇ ਸੰਚਾਲਨ 'ਤੇ ਮੁੜ ਵਿਚਾਰ ਕਰਨ ਦੀ ਲੋੜ ਪਈ। ਅਸੀਂ ਲਗਾਤਾਰ ਟਰੇਡਆਫ਼ ਦਾ ਮੁਲਾਂਕਣ ਇਸ ਪੈਟਰਨ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹੋਏ ਕੀਤਾ: ਪਹਿਲਾਂ ਮਿਸ਼ਨ-ਕ੍ਰਿਟੀਕਲ ਉਤਪਾਦ ਟ੍ਰੈਫ਼ਿਕ ਲਈ ਕਾਫ਼ੀ ਭਰੋਸੇਯੋਗ ਬਣਨਾ, ਫਿਰ ਗਲੋਬਲ ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਕਾਫ਼ੀ ਤੇਜ਼ ਬਣਨਾ, ਅਤੇ ਅੰਤ ਵਿੱਚ, ਵਿਸ਼ਾਲ ਪੈਮਾਨੇ 'ਤੇ ਕੁਸ਼ਲਤਾ ਨਾਲ ਸੰਚਾਲਨ ਕਰਨਾ।

ਇਹ ਦੋ ਭਾਗਾਂ ਦੀ ਲੜੀ ਦੱਸਦੀ ਹੈ ਕਿ ਅਸੀਂ ਕਿਵੇਂ Habitat ਨੂੰ ਸਧਾਰਨ ਕਲਾਇੰਟ ਲਾਇਬ੍ਰੇਰੀ ਅਤੇ ਡਾਟਾਬੇਸ ਤੋਂ ਵਿਕਸਤ ਕਰਕੇ ਇੱਕ ਗਲੋਬਲ ਪੱਧਰ 'ਤੇ ਵੰਡੇ ਹੋਏ ਸਟੋਰੇਜ ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਬਦਲਿਆ, ਜੋ 500 ਪੈਟਾਬਾਈਟ ਤੋਂ ਵੱਧ ਡਾਟਾ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ। ਭਾਗ I ਵਿੱਚ Habitat ਦੇ Python ਕਲਾਇੰਟ ਤੋਂ ਸੇਵਾ ਵਜੋਂ ਵਿਕਾਸ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਸ ਵਿੱਚ ਉਹ ਤਕਨੀਕਾਂ ਵੀ ਸ਼ਾਮਲ ਸਨ ਜਿਨ੍ਹਾਂ ਨੇ ਸਾਨੂੰ Python-ਅਧਾਰਿਤ ਸੇਵਾ ਨੂੰ ਉਸ ਹੱਦ ਤੋਂ ਕਿਤੇ ਅੱਗੇ ਲਿਜਾਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ, ਜਿਸ ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਵਿਹਾਰਕ ਸਮਝਦੇ ਹਨ।

ਇਸ ਪੋਸਟ, ਭਾਗ II ਵਿੱਚ, ਅਸੀਂ ਇਸ ਗੱਲ ਬਾਰੇ ਚਰਚਾ ਕਰਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਅੰਤਰੀਵ ਸਟੋਰੇਜ ਕੰਪੋਨੈਂਟ: Azure Cosmos DB ਨੂੰ ਕਿਵੇਂ ਸਕੇਲ ਕੀਤਾ। Azure ਟੀਮ ਨਾਲ ਨਜ਼ਦੀਕੀ ਭਾਈਵਾਲੀ ਰਾਹੀਂ, ਅਸੀਂ ਵਿਸ਼ਾਲ, ਗਲੋਬਲ ਪੈਮਾਨੇ 'ਤੇ ਸ਼ਾਨਦਾਰ ਰੀਡ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਨਾਲ, ਸਹਿ-ਪ੍ਰਬੰਧਿਤ ਕੰਟੇਨਰਾਂ ਦੀ ਵਿਹਾਰਕ ਮਲਟੀ-ਟੈਨੈਂਸੀ ਪਹੁੰਚ ਤੱਕ ਪਹੁੰਚੇ।

ਜਿਵੇਂ-ਜਿਵੇਂ ਕੰਪਨੀਆਂ ਦਾ ਪੈਮਾਨਾ ਵਧਦਾ ਹੈ, ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀਆਂ ਟੀਮਾਂ ਅਕਸਰ ਸਿੰਗਲ-ਟੈਨੈਂਟ ਸਿਸਟਮਾਂ ਤੋਂ ਮਲਟੀ-ਟੈਨੈਂਟ ਸਿਸਟਮਾਂ ਵੱਲ ਵਧਦੀਆਂ ਹਨ। ਸਿੰਗਲ-ਟੈਨੈਂਸੀ ਵਿੱਚ, ਜਿੱਥੇ ਉਤਪਾਦ ਦੇ ਹਰੇਕ ਹਿੱਸੇ ਦੀ ਟੀਮ ਆਪਣੇ ਖੁਦ ਦੇ ਸਿਸਟਮ ਦਾ ਰੱਖ-ਰਖਾਅ ਕਰਦੀ ਹੈ, ਪ੍ਰਭਾਵ ਖੇਤਰ ਸੀਮਤ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਆਸਾਨ ਮਾਲਕੀ ਸੀਮਾਵਾਂ ਅਤੇ ਵਰਕਲੋਡ ਅਲੱਗ-ਥਲੱਗ ਪ੍ਰਦਾਨ ਹੁੰਦੇ ਹਨ। ਜਿਵੇਂ-ਜਿਵੇਂ ਟੀਮਾਂ ਅਤੇ ਉਤਪਾਦ ਦੇ ਹਿੱਸੇ ਵਧਦੇ ਹਨ, ਇਸ ਨੂੰ ਚਲਾਉਣਾ ਮਹਿੰਗਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਸਿੰਗਲ-ਟੈਨੈਂਸੀ ਹਰ ਉਤਪਾਦ ਟੀਮ ਨੂੰ ਸਮਰੱਥਾ ਯੋਜਨਾਬੰਦੀ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਬਣਾਉਂਦੀ ਹੈ ਅਤੇ ਅਕਸਰ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਓਵਰ-ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਦਾ ਕਾਰਨ ਬਣਦੀ ਹੈ।

ਇਸ ਦੇ ਉਲਟ, ਮਲਟੀ-ਟੈਨੈਂਸੀ ਕੰਟਰੋਲ ਨੂੰ ਕੇਂਦਰੀਕ੍ਰਿਤ ਡਾਟਾਬੇਸ ਟੀਮ ਨੂੰ ਸੌਂਪ ਦਿੰਦੀ ਹੈ, ਜਿਸ ਕੋਲ ਸਰੋਤਾਂ ਦੀ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਲਈ ਬਿਹਤਰ ਗਿਆਨ ਅਤੇ ਤਜਰਬਾ ਹੁੰਦਾ ਹੈ। ਪਰ ਮਲਟੀ-ਟੈਨੈਂਸੀ ਆਪਣੇ ਨਾਲ ਆਪਣੀਆਂ ਮੁਸ਼ਕਲਾਂ ਵੀ ਪੈਦਾ ਕਰਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ ਨੌਇਜ਼ੀ-ਨੇਬਰ ਦੀ ਸਮੱਸਿਆ, ਜਿੱਥੇ ਇੱਕ ਟੇਨੈਂਟ ਬਾਕੀ ਟੇਨੈਂਟਾਂ ਦਾ ਨੁਕਸਾਨ ਕਰਦਿਆਂ ਸਰੋਤਾਂ ਦਾ ਅਸਾਧਾਰਨ ਤੌਰ 'ਤੇ ਵੱਡਾ ਹਿੱਸਾ ਵਰਤ ਲੈਂਦਾ ਹੈ।

Habitat ਵਿੱਚ, ਸਾਨੂੰ ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਭਰੋਸੇਯੋਗ ਅਤੇ ਕੁਸ਼ਲ ਸਟੋਰੇਜ ਸਿਸਟਮ ਬਣਾਉਣ ਲਈ ਇਨ੍ਹਾਂ ਸਾਰੇ ਟਰੇਡਆਫ਼ ਨੂੰ ਤੋਲਣਾ ਪਿਆ। ਅੱਜ Habitat ਕਈ OpenAI ਉਤਪਾਦਾਂ ਲਈ ਮਲਟੀ-ਟੈਨੈਂਟ ਡਾਟਾਬੇਸ ਪਰਤ ਹੈ, ਪਰ ਅਸੀਂ ਮਲਟੀ-ਟੈਨੈਂਟ Azure Cosmos DB ਕੰਟੇਨਰ ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਲੈ ਕੇ ਸਿੰਗਲ-ਟੈਨੈਂਟ ਬੈਕਿੰਗ ਕੰਟੇਨਰਾਂ ਦੀ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਕਰਨ, ਅਤੇ ਆਖਰਕਾਰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਮੁੜ ਤੋਂ ਮਲਟੀ-ਟੈਨੈਂਟ ਕੰਟੇਨਰ ਵੱਲ ਪਰਤਣ ਤੱਕ ਦਾ ਸਫ਼ਰ ਤੈਅ ਕੀਤਾ। ਅਸੀਂ ਅਜੇ ਵੀ Habitat 'ਤੇ ਆਪਣੀ ਮਲਟੀ-ਟੈਨੈਂਸੀ ਦੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ ਵਿੱਚ ਹਾਂ: ਅਸੀਂ ਵਰਤੋਂ ਦੇ ਕਈ ਤਰ੍ਹਾਂ ਦੇ ਮਾਮਲਿਆਂ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਾਂ, ਪਰ ਅਸੀਂ ਜਿੱਥੇ ਵੀ ਸੰਭਵ ਹੋਵੇ, Azure Cosmos DB ਦੇ ਅੰਦਰੂਨੀ ਬੁਨਿਆਦੀ ਤੱਤਾਂ ਦਾ ਲਾਭ ਉਠਾ ਕੇ ਇਸ ਖੇਤਰ ਵਿੱਚ ਨਿਵੇਸ਼ ਨੂੰ ਮੁਲਤਵੀ ਕਰਨ ਦੇ ਯੋਗ ਹੋਏ ਹਾਂ।

ਸਾਡੇ Azure Cosmos DB ਦੇ ਸਫ਼ਰ ਤੋਂ ਪਹਿਲਾਂ, ਕੁਝ ਬੁਨਿਆਦੀ ਜਾਣਕਾਰੀ:

• Azure Cosmos DB ਖਾਤਾ ਕੰਟੇਨਰਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਅਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੀਤੀ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ

• ਹਰੇਕ ਕੰਟੇਨਰ ਲਈ ਪ੍ਰਤੀ ਸਕਿੰਟ ਬੇਨਤੀ ਯੂਨਿਟਾਂ (RU/s) ਵਿੱਚ ਥਰੂਪੁੱਟ ਦੀ ਇੱਕ ਨਿਸ਼ਚਿਤ ਮਾਤਰਾ ਪ੍ਰੋਵਿਜ਼ਨ ਕੀਤੀ ਜਾਂਦੀ ਹੈ

• ਹਰੇਕ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਡਾਟਾ ਨਿਰਧਾਰਤ ਲਾਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ ਕੁੰਜੀ ਦੇ ਅਨੁਸਾਰ ਸ਼ਾਰਡ ਕਰਕੇ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਪ੍ਰਤੀ ਲਾਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ ਕੁੰਜੀ ਲਈ ਸਟੋਰੇਜ ਅਤੇ ਥਰੂਪੁੱਟ ਦੀਆਂ ਨਿਰਧਾਰਤ ਹੱਦਾਂ ਹੁੰਦੀਆਂ ਹਨ

• Azure Cosmos DB ਲਾਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ ਕੁੰਜੀਆਂ ਨੂੰ ਘੱਟ ਬੈਕਿੰਗ ਫਿਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨਾਂ ਵਿੱਚ ਸ਼ਾਰਡ ਕਰਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਸਟੋਰੇਜ ਕਿਸੇ ਨਿਰਧਾਰਤ ਹੱਦ ਤੋਂ ਵੱਧ ਜਾਂਦੀ ਹੈ ਜਾਂ ਕੰਟੇਨਰ ਨੂੰ ਪ੍ਰੋਵਿਜ਼ਨ ਕੀਤੇ ਥਰੂਪੁੱਟ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ ਵਧੇਰੇ ਫਿਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇਹ ਉਹਨਾਂ ਨੂੰ ਕਈ ਫਿਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨਾਂ ਵਿੱਚ ਵੰਡ ਦਿੰਦਾ ਹੈ

ਅਸੀਂ ਸ਼ੁਰੂ ਵਿੱਚ ਕਿਸੇ ਵੀ ਕਲਾਇੰਟ ਲੋਡ ਨੂੰ ਆਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ, ਅਤੇ ਬੈਕ ਪ੍ਰੈਸ਼ਰ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਪ੍ਰਤੀ ਲਾਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ ਕੁੰਜੀ ਲਈ ਨਿਰਧਾਰਤ 10 ਹਜ਼ਾਰ RU/s ਦੀ ਸੀਮਾ 'ਤੇ ਭਰੋਸਾ ਕੀਤਾ। ਜਦੋਂ ਅਸੀਂ ਪਹਿਲੀ ਵਾਰ ਸ਼ੁਰੂਆਤ ਕੀਤੀ, ਤਾਂ ਅਸੀਂ ਹਰੇਕ ਖਾਤੇ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਡਿਫ਼ਾਲਟ Azure Cosmos DB ਕੰਟੇਨਰ ਦੀ ਵੀ ਵਰਤੋਂ ਕੀਤੀ। ਇਹ ਕਾਫ਼ੀ ਹੱਦ ਤੱਕ ਠੀਕ ਕੰਮ ਕਰਦਾ ਰਿਹਾ, ਪਰ ਕੁਝ ਕਾਰਨਾਂ ਕਰਕੇ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰ ਗਿਆ:

ਸ਼ੁਰੂਆਤੀ API ਵਿਕਲਪਾਂ ਕਾਰਨ, ਅਸੀਂ ਕਲਾਇੰਟਾਂ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਲਾਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ ਕੁੰਜੀ ਦੀ ਚੋਣ ਕਰਨ ਦੀ ਖੁੱਲ੍ਹ ਦਿੱਤੀ ਸੀ। ਇਸ ਦੇ ਨਤੀਜੇ ਵਜੋਂ, ਵੱਖ-ਵੱਖ ਉਤਪਾਦ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਵਰਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਪਾਰਟੀਸ਼ਨ ਕੁੰਜੀਆਂ, ਜਿਵੇਂ ਕਿ user_id ਜਾਂ workspace_id ਉੱਤੇ ਅਕਸਰ ਟਕਰਾਅ ਹੁੰਦੇ ਹਨ। ਕਿਉਂਕਿ ਇਹਨਾਂ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇੱਕੋ ਜਿਹੀਆਂ ਲਾਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ ਕੁੰਜੀਆਂ 'ਤੇ Azure Cosmos DB ਦੀਆਂ ਸੀਮਾਵਾਂ ਸਾਂਝੀਆਂ ਸਨ, ਇਸ ਡਿਜ਼ਾਈਨ ਨੇ ਕਿਸੇ ਦਿੱਤੇ ਗਏ ਯੂਜ਼ਰ ਲਈ ਸਮੁੱਚੇ ਥਰੂਪੁੱਟ ਨੂੰ ਸੀਮਤ ਕਰ ਦਿੱਤਾ।

Habitat ਅਤੇ Azure Cosmos DB ਵਿੱਚ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ Postgres ਨੂੰ ਸਕੇਲ ਕਰਨ ਵੇਲੇ ਸਾਨੂੰ ਆਮ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ ਕਿ ਕਿਸੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੌਟ ਆਰਗੇਨਾਈਜ਼ੇਸ਼ਨ ਜਾਂ ਹੌਟ ਕੀ—ਯਾਨੀ ਅਜਿਹੇ ਟੈਨੈਂਟ ਵੱਲੋਂ ਜੋ ਅਨੁਪਾਤ ਤੋਂ ਬਹੁਤ ਵੱਧ ਲੋਡ ਪੈਦਾ ਕਰ ਰਿਹਾ ਹੋਵੇ—ਤੋਂ ਆਉਂਦੀਆਂ ਅਨੇਕਾਂ ਬੇਨਤੀਆਂ ਵਿੱਚ ਪੂਰੇ ਡਾਟਾਬੇਸ ਨੂੰ ਠੱਪ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੁੰਦੀ ਸੀ। ਉਨ੍ਹਾਂ ਕੁੰਜੀਆਂ ਨੂੰ ਕੈਸ਼ ਕਰਨ ਅਤੇ ਕੈਸ਼ ਮਿਸ ਵਿੱਚ ਲੀਜ਼ ਬਣਾਉਣ ਲਈ ਕਾਫ਼ੀ ਸਾਂਝੀ ਮਿਹਨਤ ਲੱਗੀ, ਤਾਂ ਜੋ ਨਤੀਜੇ ਵਜੋਂ ਪੈਦਾ ਹੋਣ ਵਾਲਾ ਕੈਸ਼ ਮਿਸ ਲੋਡ ਅੰਤਰੀਵ ਡਾਟਾਬੇਸ 'ਤੇ ਭਾਰ ਨਾ ਪਾ ਸਕੇ।

ਹਾਲਾਂਕਿ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਦੱਸੇ ਗਏ ਡੇਟਾ ਆਕਾਰ ਅਤੇ ਥਰੂਪੁੱਟ ਦੀਆਂ ਸੀਮਾਵਾਂ ਲਾਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ ਕੁੰਜੀਆਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ, ਪਰ ਅਸਲ ਵਿੱਚ ਇਹ ਸੀਮਾਵਾਂ ਫਿਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ 'ਤੇ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਅਮਲ ਵਿੱਚ, ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਲਾਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ 10,000 RU/s ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦੇ। ਇਸ ਦੀ ਬਜਾਏ, ਉਹ ਉਸੇ ਫਿਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ 'ਤੇ ਮੌਜੂਦ ਹਰ ਦੂਜੀ ਲਾਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ ਕੁੰਜੀ ਨਾਲ ਉਸ ਫਿਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ।

ਇਸ ਕਾਰਨ ਨੌਇਜ਼ੀ ਨੇਬਰਜ਼ ਕਈ ਅਸੰਬੰਧਿਤ ਲਾਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ ਕੁੰਜੀਆਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਦੇ ਯੋਗ ਹੋ ਗਏ, ਜਿਸ ਨਾਲ ਖਾਸ ਉਤਪਾਦ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਵਰਕਲੋਡਾਂ ਨੇ ਮੁੱਖ ਲੌਗਇਨ ਅਤੇ ਸਾਈਨ-ਅੱਪ ਪ੍ਰਵਾਹ ਵਿੱਚ ਵਿਘਨ ਪਾਇਆ।

ਕਿਸੇ ਖਾਸ ਫਿਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ ਲਈ ਥਰੂਪੁੱਟ ਦੀ ਸੀਮਾ ਵੀ ਬਦਲਦੀ ਰਹਿੰਦੀ ਹੈ, ਜੋ ਕਿ Azure Cosmos DB ਕੰਟੇਨਰ ਨੂੰ ਅਲਾਟ ਕੀਤੇ ਗਏ ਕੁੱਲ ਥਰੂਪੁੱਟ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਕੰਟੇਨਰ ਦਾ ਪ੍ਰੋਵਿਜ਼ਨ ਕੀਤਾ ਗਿਆ ਥਰੂਪੁਟ ਉਸ ਕੰਟੇਨਰ ਦੇ ਫਿਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨਾਂ ਵਿੱਚ ਲਗਭਗ ਬਰਾਬਰ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ।

ਜਿਵੇਂ-ਜਿਵੇਂ ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਵਧਦੀ ਹੈ, ਫਿਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ ਵੰਡੇ ਜਾਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਕੁੱਲ ਪ੍ਰੋਵਿਜ਼ਨ ਕੀਤੇ ਗਏ ਥਰੂਪੁੱਟ ਦੇ ਅਪਰਿਵਰਤਿਤ ਰਹਿਣ ਦੇ ਬਾਵਜੂਦ ਪਾਰਟੀਸ਼ਨਾਂ ਦੀ ਕੁੱਲ ਗਿਣਤੀ ਵਧ ਜਾਂਦੀ ਹੈ। ਨਤੀਜਾ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਡੇਟਾ ਦਾ ਆਕਾਰ ਵਧਣ ਨਾਲ ਪ੍ਰਤੀ ਪਾਰਟੀਸ਼ਨ ਅਸਰਦਾਰ ਥਰੂਪੁੱਟ ਸੀਮਾ ਘੱਟ ਜਾਂਦੀ ਹੈ।

ਸਾਡੇ ਸਭ ਤੋਂ ਵੱਧ ਸਟੋਰੇਜ-ਭਾਰੇ ਅਤੇ ਬਲੌਬ-ਵਰਗੇ ਯੂਜ਼ ਕੇਸਾਂ ਲਈ, ਇਹ ਅਜਿਹਾ ਫੇਲ੍ਹ ਹੋਣ ਦਾ ਮੋਡ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਕੇਵਲ ਸਟੋਰੇਜ ਵਿੱਚ ਵਾਧਾ ਹੋਣ ਨਾਲ ਹੀ ਸਰਗਰਮ ਵਰਕਲੋਡਾਂ ਦੀ ਥਰੂਪੁੱਟ ਸਮਰੱਥਾ ਘਟ ਜਾਂਦੀ ਹੈ, ਭਾਵੇਂ ਕਿ ਬੇਨਤੀਆਂ ਦੀ ਦਰ ਅਤੇ ਵਰਤੋਂ ਸਥਿਰ ਰਹਿਣ।

ਵੱਖ-ਵੱਖ ਕੰਟੇਨਰ ਇਹਨਾਂ ਪਾਰਟੀਸ਼ਨ ਕੁੰਜੀ ਸੀਮਾਵਾਂ ਅਤੇ ਨੌਇਜ਼ੀ ਨੇਬਰਜ਼ ਨੂੰ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਹੱਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ। ਵੱਖ-ਵੱਖ ਕੰਟੇਨਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਹਰੇਕ ਨੂੰ ਆਪਣੇ ਖੁਦ ਦੇ ਸੁਤੰਤਰ ਫਿਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ ਅਲਾਟ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ ਅਤੇ ਸਿਰਫ ਉਸ ਕੰਟੇਨਰ 'ਤੇ ਮੌਜੂਦ ਵੱਖੋ-ਵੱਖਰੇ ਵਰਕਲੋਡ ਹੀ ਨੌਇਜ਼ੀ ਨੇਬਰਜ਼ ਹੋ ਸਕਦੇ ਹਨ ਜਾਂ ਪਾਰਟੀਸ਼ਨ ਕੁੰਜੀ ਸਪੇਸ ਵਿੱਚ ਓਵਰਲੈਪ ਕਰ ਸਕਦੇ ਹਨ। ਇਸ ਦੇ ਨੁਕਸਾਨ ਵਜੋਂ, ਨਵੇਂ ਕੰਟੇਨਰਾਂ ਨੂੰ ਪ੍ਰੋਵਿਜ਼ਨ ਕਰਨ ਵਿੱਚ ਕੁਝ ਨਾ ਕੁਝ ਵਾਧੂ ਕੰਮ ਲੱਗਦਾ ਹੈ—ਹਰੇਕ ਕੰਟੇਨਰ ਲਈ ਵਿਅਕਤੀਗਤ ਸਮਰੱਥਾ ਯੋਜਨਾਬੰਦੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ—ਇਸ ਲਈ ਅਸੀਂ ਸਿਰਫ਼ ਉਸੇ ਸੇਵਾ ਜਾਂ ਯੂਜ਼ ਕੇਸ ਦੀ ਸੀਮਾ 'ਤੇ ਕੰਟੇਨਰ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ ਜਿੱਥੇ ਇਹ ਅਰਥ ਰੱਖਦਾ ਹੋਵੇ।

ਅਸੀਂ ਮਜ਼ਬੂਤ ਆਈਸੋਲੇਸ਼ਨ ਦੀ ਮੰਗ ਕਰਨ ਵਾਲੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਨਵੇਂ ਯੂਜ਼ ਕੇਸਾਂ ਲਈ ਵੱਖਰੇ Azure Cosmos DB ਕੰਟੇਨਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ। ਹਰੇਕ ਕੰਟੇਨਰ ਲਈ ਅਲਾਟ ਕੀਤੇ ਗਏ ਕੁੱਲ ਥਰੂਪੁੱਟ ਨੂੰ ਇਸਦੇ ਫਿਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨਾਂ ਦੀ ਗਿਣਤੀ ਨਾਲ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ ਕਰਕੇ ਕਮਜ਼ੋਰ ਪਾਰਟੀਸ਼ਨਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਵਾਲੀ ਸਕ੍ਰਿਪਟ ਦੇ ਸੁਮੇਲ ਨਾਲ, ਅਸੀਂ ਉਨ੍ਹਾਂ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਲਗਭਗ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੁਟਕਾਰਾ ਪਾ ਲਿਆ ਜਿਨ੍ਹਾਂ ਦਾ ਅਸੀਂ ਸਾਹਮਣਾ ਕਰ ਰਹੇ ਸੀ।

ਹਾਲਾਂਕਿ, ਕਿਉਂਕਿ ਅਸੀਂ ਡਿਫ਼ਾਲਟ ਕੰਟੇਨਰ ਤੋਂ ਸ਼ੁਰੂਆਤ ਕੀਤੀ ਸੀ, ਇਸ ਲਈ ਬਹੁਤ ਸਾਰੇ ਪੁਰਾਣੇ ਮਹੱਤਵਪੂਰਨ ਯੂਜ਼ ਕੇਸ ਬਦਕਿਸਮਤੀ ਨਾਲ ਡੇਟਾ ਮਾਈਗ੍ਰੇਸ਼ਨ ਤੋਂ ਬਿਨਾਂ ਉੱਥੇ ਹੀ ਫਸੇ ਰਹੇ। ਸਾਂਝੇ ਕੀਤੇ ਗਏ ਡਿਫ਼ਾਲਟ ਕੰਟੇਨਰ ਵਿੱਚ ਮੌਜੂਦ ਡਾਟਾ 'ਤੇ ਅਜੇ ਵੀ ਨਿਰਭਰ ਅਹਿਮ ਸੇਵਾਵਾਂ ਦੀ ਰੱਖਿਆ ਲਈ, ਅਸੀਂ ਅਕਸਰ ਟੀਮਾਂ ਨੂੰ ਨਵੀਆਂ ਸੇਵਾਵਾਂ ਜਾਂ ਵੱਡੀਆਂ ਉਤਪਾਦ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਈ ਵੱਖਰੇ ਕੰਟੇਨਰ ਬਣਾਉਣ ਦੀ ਸਲਾਹ ਦਿੰਦੇ ਸੀ। ਜਿਵੇਂ-ਜਿਵੇਂ ਸਾਡਾ ਪੈਮਾਨਾ ਵਧਿਆ, ਡਿਫ਼ਾਲਟ ਕੰਟੇਨਰ 'ਤੇ ਦਬਾਅ ਵਧ ਗਿਆ ਅਤੇ ਉਤਪਾਦਨ ਦੀਆਂ ਘਟਨਾਵਾਂ ਵੀ ਵਧ ਗਈਆਂ। ਅਸੀਂ ਸਿਰਫ਼ ਡਿਫ਼ਾਲਟ ਕੰਟੇਨਰ ਨੂੰ ਹੋਰ ਬੋਝ ਤੋਂ ਬਚਾਉਣ ਲਈ ਕਿਸੇ ਵੀ ਨਵੀਂ ਸੇਵਾ ਜਾਂ ਵੱਡੇ ਪ੍ਰੋਡਕਟ ਫੀਚਰ ਲਈ ਕੰਟੇਨਰ ਪ੍ਰੋਵਿਜ਼ਨ ਕਰਨੇ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੇ।

ਇਸ ਨੇ ਸਾਨੂੰ ਪੂਰੀ ਸਾਈਟ ਠੱਪ ਹੋਣ ਦੀਆਂ ਕਈ ਘਟਨਾਵਾਂ ਤੋਂ ਬਚਾਇਆ, ਅਤੇ ਇਸਦੇ ਪ੍ਰਭਾਵ ਦੇ ਦਾਇਰੇ ਨੂੰ ਸਿਰਫ਼ ਕਿਸੇ ਖਾਸ ਫੀਚਰ ਜਾਂ ਸੇਵਾ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਘਟਣ ਤੱਕ ਹੀ ਸੀਮਤ ਰੱਖਿਆ। ਹਾਲਾਂਕਿ, ਨਵੇਂ ਕੰਟੇਨਰਾਂ ਨੂੰ ਪ੍ਰੋਵਿਜ਼ਨ ਕਰਨ ਦਾ ਵਾਧੂ ਬੋਝ ਆਖ਼ਰਕਾਰ ਸਾਡੇ 'ਤੇ ਭਾਰੀ ਪੈ ਗਿਆ:

ਪੁਰਾਣੇ ਸਾਂਝੇ ਕੀਤੇ ਗਏ ਡਿਫ਼ਾਲਟ ਕੰਟੇਨਰ ਵਿੱਚ, ਕਿਸੇ ਖਾਸ ਨਵੇਂ ਯੂਜ਼ ਕੇਸ ਲਈ 0 QPS ਤੋਂ 1 ਮਿਲੀਅਨ QPS ਤੱਕ ਜਾਣਾ ਇਸ ਗੱਲ ਦੀ ਸੰਭਾਵਨਾ ਨਹੀਂ ਸੀ ਕਿ ਇਹ ਕੁੱਲ ਸਮੁੱਚੀ ਵਰਤੋਂ ਵਿੱਚ ਕੋਈ ਵੱਡਾ ਬਦਲਾਅ ਲਿਆਵੇ। ਹਾਲਾਂਕਿ, ਆਈਸੋਲੇਟਡ ਕੰਟੇਨਰ 'ਤੇ, 0 ਤੋਂ 1 ਮਿਲੀਅਨ QPS ਤੱਕ ਜਾਣ ਵਾਲਾ ਕੋਈ ਨਵਾਂ ਯੂਜ਼ ਕੇਸ, ਸਿਰਫ਼ ਅੰਦਰੂਨੀ ਡੌਗਫੂਡਿੰਗ ਲਈ ਮੰਨੇ ਗਏ ਬੇਸਲਾਈਨ ਨਾਲੋਂ 1,000 ਗੁਣਾ ਵੱਧ ਲੋਡ ਨੂੰ ਦਰਸਾ ਸਕਦਾ ਹੈ।

ਸਮਰਪਿਤ ਕੰਟੇਨਰਾਂ ਦੇ ਨਾਲ ਟੀਮਾਂ ਨੂੰ ਹੁਣ ਆਪਣੇ ਉਤਪਾਦਾਂ ਨੂੰ ਜਾਰੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਨੁਮਾਨਿਤ ਥਰੂਪੁੱਟ ਪੱਧਰ ਤੱਕ ਕੰਟੇਨਰਾਂ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਪ੍ਰੋਵਿਜ਼ਨ ਕਰਨਾ ਯਾਦ ਰੱਖਣਾ ਪੈਂਦਾ ਸੀ। ਉਤਪਾਦ ਟੀਮਾਂ ਅਕਸਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜਾਰੀ ਕਰ ਦਿੰਦੀਆਂ ਪਰ ਪਹਿਲਾਂ ਸਮਰੱਥਾ ਵਧਾਉਣਾ ਭੁੱਲ ਜਾਂਦੀਆਂ ਸਨ, ਜਿਸ ਕਾਰਨ ਸਾਨੂੰ ਜਾਰੀ ਕਰਨ ਵਾਲੇ ਦਿਨ SEV ਰੂਮਾਂ ਵਿੱਚ ਬੈਠ ਕੇ ਆਖਰੀ ਸਮੇਂ 'ਤੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਸਕੇਲ ਅੱਪ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਪੈਂਦੀ ਸੀ।

ਇਹ ਮਲਟੀ-ਟੇਨੈਂਟ ਸਿਸਟਮਾਂ ਦਾ ਅਜਿਹਾ ਮੁੱਖ ਵਰਕਲੋਡ ਮਿਕਸਿੰਗ ਫਾਇਦਾ ਹੈ, ਜਿਸ ਨੂੰ ਅਸੀਂ ਇਸ ਕੰਟੇਨਰ ਰਣਨੀਤੀ ਨਾਲ ਬਿਹਤਰ ਆਈਸੋਲੇਸ਼ਨ ਦੇ ਪੱਖ ਵਿੱਚ ਗੁਆ ਬੈਠਦੇ ਹਾਂ।

ਸਮੇਂ ਦੇ ਨਾਲ, ਸਮਰਪਿਤ ਕੰਟੇਨਰਾਂ ਦੀ ਵਰਤੋਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖਣ ਲਈ ਉਤਪਾਦ ਦੀ ਡੂੰਘੀ ਸਮਝ ਦੀ ਵੀ ਲੋੜ ਪੈਣ ਲੱਗੀ ਕਿ ਟ੍ਰੈਫ਼ਿਕ ਕਦੋਂ ਬਦਲੇਗੀ ਜਾਂ ਵਧੇਗੀ।

ਅਸੀਂ ਵਾਧੇ ਦੇ ਰੁਝਾਨਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਹਰੇਕ ਕੰਟੇਨਰ ਲਈ ਪ੍ਰੋਵਿਜ਼ਨ ਕੀਤੇ ਗਏ ਥਰੂਪੁੱਟ ਨੂੰ ਵਧਾਉਣ ਲਈ ਬੁਨਿਆਦੀ ਕੰਟਰੋਲ ਪਲੇਨ ਸਕ੍ਰਿਪਟ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੇ ਹਾਂ, ਪਰ ਸਥਿਰ ਸਮੁੱਚਾ ਵਾਧਾ ਨਾ ਹੋਣ ਕਰਕੇ, ਇਨ੍ਹਾਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਸਕੇਲ ਕਰਨ ਲਈ OpenAI ਦੀ ਲਗਭਗ ਹਰ ਉਤਪਾਦ ਟੀਮ ਨੂੰ ਸਮਰੱਥਾ ਵਧਾਉਣ ਦੀ ਯੋਜਨਾਬੰਦੀ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣਾ ਪਿਆ।

ਇਹ ਸੰਗਠਨਾਤਮਕ ਤੌਰ 'ਤੇ ਸਕੇਲ ਕਰਨ ਵਿੱਚ ਅਸਫ਼ਲ ਰਿਹਾ ਕਿਉਂਕਿ ਹਰੇਕ ਸੇਵਾ ਦੀ ਮਾਲਕ ਟੀਮ ਨੇ ਆਪਣੇ Azure Cosmos DB ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਵੱਲ ਵੱਖ-ਵੱਖ ਪੱਧਰ ਦੀ ਗੰਭੀਰਤਾ ਅਤੇ ਧਿਆਨ ਦਿੱਤਾ।

ਸੰਗਠਨ ਵਧਣ ਨਾਲ ਸੰਚਾਲਨ ਦੀਆਂ ਉਨ੍ਹਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਸੰਭਾਲਣਾ ਔਖਾ ਹੁੰਦਾ ਗਿਆ. ਯੋਜਨਾਬੰਦੀ ਲਈ ਇੱਕ ਕੇਂਦਰੀ ਟੀਮ ਨਾ ਹੋਣ ਕਰਕੇ ਕਈ ਟੀਮਾਂ ਦੀ ਯੋਜਨਾਬੰਦੀ ਕਮਜ਼ੋਰ ਰਹੀ. ਇਸ ਲਈ ਅਸੀਂ ਮੁੜ ਮਲਟੀ-ਟੈਨੈਂਟ ਹੱਲ ਵੱਲ ਗਏ ਅਤੇ Azure ਟੀਮ ਨਾਲ ਨੇੜਿਓਂ ਕੰਮ ਕਰਕੇ ਸਾਂਝੀ ਟੈਨੈਂਸੀ ਵਾਲੇ ਡਿਜ਼ਾਈਨ ਰਾਹੀਂ ਮਲਟੀ-ਟੈਨੈਂਸੀ ਦੀਆਂ ਮੂਲ ਸਮੱਸਿਆਵਾਂ ਦੇ ਹੱਲ ਬਣਾਏ:

ਸਭ ਤੋਂ ਵੱਧ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਕੁੰਜੀਆਂ ਦੀ ਦਰ ਪਹਿਲਾਂ ਸੀਮਤ ਕਰਨ ਨਾਲ ਬੋਝ ਪਾਉਣ ਵਾਲੇ ਸਹਿ-ਵਰਕਲੋਡ ਕਿਸੇ ਫ਼ਿਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ ਦੀ ਸਾਰੀ ਉਪਲਬਧ ਥਰੂਪੁੱਟ ਨਹੀਂ ਵਰਤ ਸਕਦੇ. ਇਸ ਨਾਲ ਇੱਕੋ ਬਹੁਤ ਸਰਗਰਮ ਕੁੰਜੀ ਕਾਰਨ ਪੂਰੀ ਸਾਈਟ ਪ੍ਰਭਾਵਿਤ ਹੋਣ ਦਾ ਖ਼ਤਰਾ ਘਟਦਾ ਹੈ.

ਬੇਨਤੀਆਂ ਨੂੰ ਤਰਜੀਹੀ ਪੱਧਰਾਂ ਵਿੱਚ ਵੰਡਣ ਵਾਲੀ QoS ਵੀ ਆਫ਼ਲਾਈਨ ਵਰਕਲੋਡਾਂ, ਜਿਵੇਂ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਡਾਟਾ ਜੋੜਨਾ ਜਾਂ ਕੱਢਣਾ, ਨੂੰ ਕਿਸੇ ਫ਼ਿਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ ਦੀ ਸਾਰੀ ਥਰੂਪੁੱਟ ਵਰਤਣ ਤੋਂ ਰੋਕਦੀ ਹੈ. ਇਨ੍ਹਾਂ ਵਰਕਲੋਡਾਂ ਦੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਘੱਟ ਤਰਜੀਹ ਦੇਣ ਨਾਲ ਉਨ੍ਹਾਂ ਦੀ ਦਰ ਪਹਿਲਾਂ ਸੀਮਤ ਹੁੰਦੀ ਹੈ. ਇਸ ਤਰ੍ਹਾਂ ਅੰਤਿਮ ਵਰਤੋਂਕਾਰਾਂ ਦੀਆਂ ਉੱਚ ਤਰਜੀਹ ਵਾਲੀਆਂ ਇੰਟਰਐਕਟਿਵ ਬੇਨਤੀਆਂ ਦੀ ਦਰ ਸੀਮਤ ਨਹੀਂ ਕਰਨੀ ਪੈਂਦੀ.

Azure Cosmos DB ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਸਰਵਰਲੈੱਸ ਮੋਡ ਸੀ, ਜੋ ਨਿਰਧਾਰਤ ਸਮਰੱਥਾ ਵਾਲੇ ਮੋਡ ਵਿੱਚ ਆਉਂਦੀ ਸਾਡੀ ਕਮਜ਼ੋਰ ਪਾਰਟੀਸ਼ਨਾਂ ਦੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰ ਸਕਦਾ ਸੀ. ਪਰ ਇਸ ਦੀ ਵੱਡੀ ਕਮੀ ਸੀ: ਇਹ ਸਿਰਫ਼ ਸਟੋਰੇਜ ਦੀ ਵਰਤੋਂ ਅਨੁਸਾਰ ਵਧਦਾ ਸੀ ਅਤੇ ਹਰ ਫ਼ਿਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ ਦੀ RU ਵਰਤੋਂ 5 ਹਜ਼ਾਰ RU/s ਤੱਕ ਸੀਮਤ ਸੀ. ਇਸ ਨਾਲ ਕਮਜ਼ੋਰ ਪਾਰਟੀਸ਼ਨਾਂ ਦੀ ਸਮੱਸਿਆ ਤਾਂ ਹੱਲ ਹੁੰਦੀ, ਪਰ ਵੱਧ RU ਮੰਗਣ ਵਾਲੀਆਂ ਵਰਤੋਂਆਂ ਦਾ ਪੈਮਾਨਾ ਨਹੀਂ ਵਧਾ ਸਕਦੇ ਸਾਂ.

Azure Cosmos DB ਟੀਮ ਨੇ ਸਾਡੇ ਲਈ ਸੁਧਰਿਆ ਸਰਵਰਲੈੱਸ ਮੋਡ ਬਣਾਇਆ, ਜਿਸ ਵਿੱਚ ਹਰ ਫ਼ਿਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ 10 ਹਜ਼ਾਰ RU/s ਤੱਕ ਵਧ ਸਕਦਾ ਸੀ. ਸਟੋਰੇਜ ਦੀ ਵਰਤੋਂ ਤੋਂ ਇਲਾਵਾ RU ਵਰਤੋਂ ਦੇ ਆਧਾਰ 'ਤੇ ਵੀ ਪਾਰਟੀਸ਼ਨ ਵੰਡਣ ਦੀ ਸਹੂਲਤ ਆਈ. ਇਸ ਨਾਲ ਕੰਟੇਨਰਾਂ ਦੀ ਹੱਥੀਂ ਨਿਗਰਾਨੀ ਅਤੇ ਸਮਰੱਥਾ ਵਧਾਉਣ ਦੀ ਲੋੜ ਖ਼ਤਮ ਹੋਈ.

ਇਨ੍ਹਾਂ ਤਬਦੀਲੀਆਂ ਨਾਲ ਅਸੀਂ ਮੁੜ ਇੱਕ ਸਾਂਝਾ ਕੰਟੇਨਰ ਵਰਤ ਸਕੇ ਹਾਂ. ਵਰਕਲੋਡਾਂ ਦਾ ਅਲੱਗਾਵ ਬਰਕਰਾਰ ਰੱਖਦਿਆਂ, ਇਸ ਨੇ ਉਤਪਾਦ ਟੀਮਾਂ ਲਈ ਸ਼ੁਰੂਆਤੀ ਜਾਂ ਲਗਾਤਾਰ ਸਮਰੱਥਾ ਯੋਜਨਾਬੰਦੀ ਦਾ ਕੰਮ ਕਾਫ਼ੀ ਸੌਖਾ ਕਰ ਦਿੱਤਾ ਹੈ. ਉਤਪਾਦ ਵਿਕਾਸ ਤੇਜ਼ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਉਸ ਤੋਂ ਬਾਅਦ ਦੇ ਮਹੀਨਿਆਂ ਵਿੱਚ ਸਾਨੂੰ ਸਰੋਤਾਂ ਦੀ ਵਿਵਸਥਾ ਜਾਂ ਸਹਿ-ਵਰਕਲੋਡਾਂ ਦੇ ਬੋਝ ਕਾਰਨ ਕੋਈ ਘਟਨਾ ਨਹੀਂ ਝੱਲਣੀ ਪਈ.

ਜਦੋਂ ਕੰਪਨੀਆਂ OpenAI ਦੇ ਪੈਮਾਨੇ ਤੱਕ ਵਧਦੀਆਂ ਹਨ, ਤਾਂ ਪ੍ਰਬੰਧਿਤ ਸੇਵਾਵਾਂ ਘੱਟ “ਪ੍ਰਬੰਧਿਤ” ਰਹਿ ਜਾਂਦੀਆਂ ਹਨ. ਕਈ ਵਰਕਲੋਡ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ ਦੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਆਮ ਵਰਤੋਂ ਤੋਂ ਵੱਖਰੇ ਹੋ ਜਾਂਦੇ ਹਨ. OpenAI ਦੇ Azure Cosmos DB ਦੇ ਸਭ ਤੋਂ ਵੱਡੇ ਵਰਤੋਂਕਾਰਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਨਾਲ, ਇਸ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਚਲਾਉਣ ਲਈ ਵੱਖਰਾ ਤਰੀਕਾ ਲੋੜੀਂਦਾ ਸੀ: ਸਾਂਝੇ ਟੈਸਟ, ਸਾਂਝੇ ਡੈਸ਼ਬੋਰਡ, ਸਿੱਧੇ ਇੰਜੀਨੀਅਰਿੰਗ ਸੰਪਰਕ ਅਤੇ ਸਿਰਫ਼ ਸਾਡੇ ਪੈਮਾਨੇ 'ਤੇ ਉਭਰਦੀਆਂ ਖ਼ਰਾਬੀਆਂ ਦੀ ਸਾਂਝੀ ਜ਼ਿੰਮੇਵਾਰੀ. ਅੱਜ ਸਾਡਾ ਸਭ ਤੋਂ ਵੱਡਾ Azure Cosmos DB ਖਾਤਾ ਕਈ ਦਹਾਕੇ ਪੈਟਾਬਾਈਟ ਡਾਟਾ ਸਟੋਰ ਕਰਦਾ ਹੈ ਅਤੇ 2 ਕਰੋੜ ਤੋਂ ਵੱਧ QPS ਸੰਭਾਲਦਾ ਹੈ. ਸਾਡੀ ਜਾਣਕਾਰੀ ਅਨੁਸਾਰ, ਅਸੀਂ ਇਕੱਲੀ ਕੰਪਨੀ ਹਾਂ ਜਿਸ ਨੇ Azure Cosmos DB ਇਸ ਪੈਮਾਨੇ 'ਤੇ ਤੈਨਾਤ ਕੀਤਾ ਹੈ.

2024 ਦੇ ਅੰਤ ਵਿੱਚ ਇੱਕ ਖੇਤਰੀ ਸੇਵਾ-ਬੰਦੀ ਨੇ ਸਪੱਸ਼ਟ ਕਰ ਦਿੱਤਾ ਕਿ ਇਹ ਸਹਿਯੋਗ ਕਿਉਂ ਲਾਜ਼ਮੀ ਸੀ. ਉਸ ਵੇਲੇ ਸਾਡੇ ਸਭ ਤੋਂ ਵੱਡੇ Azure Cosmos DB ਖਾਤਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਦੇ ਮੁੱਖ Azure ਖੇਤਰ ਵਿੱਚ ਬਿਜਲੀ ਬੰਦ ਹੋ ਗਈ ਸੀ. ਇਸ ਤੋਂ ਬਾਅਦ ਬਦਲਵੇਂ ਖੇਤਰ ਵਿੱਚ ਸੇਵਾ ਲਿਜਾਣ ਵੇਲੇ ਪਤਾ ਲੱਗਿਆ ਕਿ ਸਾਡੇ ਸਭ ਤੋਂ ਵੱਡੇ ਖਾਤਿਆਂ ਨੂੰ ਸੈਕੰਡਰੀ ਖੇਤਰ ਵਿੱਚ ਲਿਜਾਣ ਲਈ ਕਈ ਘੰਟੇ ਲੱਗਣਗੇ. ਨਾ ਸਾਡੀ ਟੀਮ ਨੇ ਅਤੇ ਨਾ ਹੀ Azure Cosmos DB ਟੀਮ ਨੇ ਇਸ ਦੀ ਸਾਡੇ ਪੈਮਾਨੇ 'ਤੇ ਜਾਂਚ ਕੀਤੀ ਸੀ.

ਲਗਭਗ ਇੱਕ ਮਹੀਨੇ ਬਾਅਦ, ਉਨ੍ਹਾਂ ਖਾਤਿਆਂ ਨੂੰ ਮੁੜ ਮੂਲ ਖੇਤਰ ਵਿੱਚ ਲਿਆਉਂਦੇ ਸਮੇਂ ਸਾਡੇ ਕਾਰਨ ਇੱਕ ਹੋਰ ਗੰਭੀਰ ਸੇਵਾ-ਬੰਦੀ ਹੋਈ. ਮੂਲ ਖੇਤਰ ਵੱਲ ਇੱਕੋ ਵਾਰ ਆਏ ਬੇਹੱਦ ਕਨੈਕਸ਼ਨਾਂ ਨੇ ਉੱਥੋਂ ਦੇ Azure Cosmos DB ਗੇਟਵੇ ਨੂੰ ਹੱਦੋਂ ਵੱਧ ਲੋਡ ਕਰ ਦਿੱਤਾ. ਗੇਟਵੇ-ਮੋਡ ਵਾਲੇ Azure Cosmos DB ਕਲਾਇੰਟ ਦੇ ਫੇਲਓਵਰ ਸੰਭਾਲਣ ਦੇ ਇੱਕ ਅਣਕਿਆਸੇ ਵਿਹਾਰ ਕਾਰਨ ਸਾਰੇ ਕਲਾਇੰਟ ਤੁਰੰਤ ਮੂਲ ਖੇਤਰ ਨਾਲ ਕਨੈਕਸ਼ਨ ਬਣਾ ਕੇ ਬੇਨਤੀਆਂ ਭੇਜਣ ਲੱਗੇ, ਹਾਲਾਂਕਿ ਸਿਰਫ਼ ਕੁਝ ਫ਼ਿਜ਼ੀਕਲ ਪਾਰਟੀਸ਼ਨ ਹੀ ਉੱਥੇ ਵਾਪਸ ਆਏ ਸਨ.

ਹਰ ਸੇਵਾ-ਬੰਦੀ ਵੇਲੇ OpenAI ਅਤੇ Azure ਦੋਵਾਂ ਨੇ ਆਪਣੀਆਂ ਘਟਨਾ-ਪ੍ਰਬੰਧਨ ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਪਣਾਈਆਂ, ਕਈ ਮੂਲ ਕਾਰਨ ਲੱਭੇ ਅਤੇ ਹੱਲ ਲਾਗੂ ਕੀਤੇ. ਪਰ ਇਹ ਸੇਵਾ-ਬੰਦੀਆਂ ਸਾਡੀ ਅਤੇ Azure Cosmos DB ਟੀਮ ਦੀ ਸੰਚਾਲਨ ਅਤੇ ਜਾਂਚ-ਪੜਤਾਲ ਦੀ ਕਾਰਜਸ਼ੈਲੀ ਵਿਚਲੀ ਇੱਕ ਵੱਡੀ ਪ੍ਰਣਾਲੀਗਤ ਸਮੱਸਿਆ ਦੇ ਲੱਛਣ ਸਨ. ਸ਼ੁਰੂ ਵਿੱਚ ਪ੍ਰਬੰਧਿਤ ਸੇਵਾਵਾਂ ਵਰਤਣ ਨਾਲ ਅਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧ ਸਕੇ ਅਤੇ ਕਾਰੋਬਾਰੀ ਟੀਚਿਆਂ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕੇ. ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਪ੍ਰਬੰਧਿਤ ਸੇਵਾਵਾਂ ਘੱਟ ਪ੍ਰਬੰਧਿਤ ਰਹਿੰਦੀਆਂ ਹਨ ਅਤੇ ਡਿਜ਼ਾਈਨ ਤੋਂ ਸੰਚਾਲਨ ਤੱਕ ਹਰ ਪੱਧਰ 'ਤੇ ਸੇਵਾ ਪ੍ਰਦਾਤਾ ਨਾਲ ਡੂੰਘੇ ਤਾਲਮੇਲ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ.

ਅੱਜ Habitat ਅਤੇ Azure ਦੀਆਂ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮਾਂ ਸਾਡੀਆਂ ਸੇਵਾ ਪਰਤਾਂ ਤੋਂ ਲੈ ਕੇ Azure Cosmos DB ਦੀਆਂ ਭੌਤਿਕ ਸਟੋਰੇਜ ਪਰਤਾਂ ਤੱਕ, Habitat ਦੀ ਹਰ ਪਰਤ ਦੀ ਮਿਲ ਕੇ ਨਿਗਰਾਨੀ ਕਰਦੀਆਂ ਹਨ. ਅਸੀਂ ਅਸਲ ਸੇਵਾ ਜਿੰਨੇ ਵੱਡੇ, ਪਰ ਅਸਲ ਵਰਤੋਂਕਾਰਾਂ ਦੀ ਸੇਵਾ ਨਾ ਕਰਨ ਵਾਲੇ Azure Cosmos DB ਖਾਤੇ 'ਤੇ ਤਬਦੀਲੀਆਂ ਚਲਾ ਕੇ ਪਰਖਦੇ ਹਾਂ. ਅਸੀਂ ਮਿਲ ਕੇ SDK ਪਰਖਦੇ ਅਤੇ ਸੁਧਾਰਦੇ ਹਾਂ ਅਤੇ ਆਪਣੇ Azure Cosmos DB ਖਾਤਿਆਂ ਦਾ ਆਕਾਰ ਅਤੇ ਪੈਮਾਨਾ ਵਧਾਉਣ ਦੇ ਬਿਹਤਰੀਨ ਤਰੀਕੇ ਤੈਅ ਕਰਦੇ ਹਾਂ. Teams ਰਾਹੀਂ ਸਾਡੀਆਂ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮਾਂ ਸਿੱਧਾ ਸੰਪਰਕ ਕਰ ਸਕਦੀਆਂ ਹਨ. ਅਸੀਂ ਸਹਾਇਤਾ ਦੇ ਵੱਖਰੇ ਪੱਧਰਾਂ ਵਿੱਚੋਂ ਲੰਘੇ ਬਿਨਾਂ ਇੱਕ-ਦੂਜੇ ਨੂੰ ਸਿੱਧੇ ਜ਼ਰੂਰੀ ਅਲਰਟ ਭੇਜਣ ਦੇ ਤਰੀਕੇ ਵੀ ਉਪਲਬਧ ਕਰਾਏ ਹਨ.

ਪਿਛਲੇ ਸਾਲ ਦੌਰਾਨ Azure Cosmos DB ਦੇ ਕੰਟਰੋਲ-ਪਲੇਨ ਅਤੇ ਗੇਟਵੇ ਦੀ ਸਕੇਲੇਬਿਲਟੀ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਕਾਫ਼ੀ ਸਾਂਝਾ ਕੰਮ ਕੀਤਾ ਗਿਆ ਹੈ, ਗੇਟਵੇ ਵਿੱਚ ਲੋਡ ਪ੍ਰੋਟੈਕਸ਼ਨ ਅਤੇ ਵੱਖ-ਵੱਖ Azure Cosmos DB ਮੈਟਾਡਾਟਾ ਦੀ ਕੈਚਿੰਗ ਜੋੜੀ ਗਈ ਹੈ ਤਾਂ ਜੋ Azure Cosmos DB ਮੈਟਾਡਾਟਾ ਪਾਰਟੀਸ਼ਨ ਦੀ ਸੁਰੱਖਿਆ ਕੀਤੀ ਜਾ ਸਕੇ, ਕਨੈਕਸ਼ਨ ਪੂਲਿੰਗ ਅਤੇ ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਵੱਧ ਮੁੜ ਵਰਤੋਂ ਰਾਹੀਂ ਸਾਡੀਆਂ Python habitat-service ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਫਲੀਟ ਦਾ ਦਬਾਅ ਘਟਾਇਆ ਗਿਆ ਹੈ, ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ ਵਰਕਲੋਡਾਂ ਨੂੰ ਆਪਸ ਵਿੱਚ ਨੇੜੇ ਰੱਖਿਆ ਗਿਆ ਹੈ, ਅਤੇ ਵੱਖ-ਵੱਖ VPCs ਰਾਹੀਂ ਅਹਿਮ ਵਰਕਲੋਡਾਂ ਨੂੰ ਆਫ਼ਲਾਈਨ ਵਰਕਲੋਡਾਂ ਤੋਂ ਅਲੱਗ ਕੀਤਾ ਗਿਆ ਹੈ।

ਪਿਛਲੇ ਸਾਲ ਸਾਡੇ Azure Cosmos DB ਦੀ ਸਥਿਰਤਾ ਲਈ ਇਸ ਪੱਧਰ ਦਾ ਸਹਿ-ਇੰਜੀਨੀਅਰਿੰਗ ਕੰਮ ਬਹੁਤ ਅਹਿਮ ਰਿਹਾ ਹੈ। ਕਿਸੇ ਵੀ ਵੱਡੇ ਜਾਂ ਅਹਿਮ ਸਿਸਟਮ ਲਈ ਅਜਿਹਾ ਟੀਮ ਵਰਕ ਜ਼ਰੂਰੀ ਹੈ: ਮਾਲਕੀ ਦੀਆਂ ਕੰਧਾਂ ਨੂੰ ਤੋੜਨਾ ਅਤੇ ਸੰਗਠਨ ਦੀਆਂ ਸੀਮਾਵਾਂ ਤੋਂ ਪਾਰ ਹੋ ਕੇ ਕੰਮ ਕਰਨਾ।

ਜਿਵੇਂ ਕਿ ਭਾਗ I ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਸਾਡਾ ਮੁੱਖ ਸਿਧਾਂਤ ਹੈ: ਇਸਨੂੰ ਕੰਮ ਕਰਨ ਯੋਗ ਬਣਾਓ, ਇਸਨੂੰ ਤੇਜ਼ ਬਣਾਓ, ਇਸਨੂੰ ਕਿਫ਼ਾਇਤੀ ਬਣਾਓ। ਪਹਿਲਾਂ ਭਰੋਸੇਯੋਗਤਾ, ਫਿਰ ਪ੍ਰਦਰਸ਼ਨ, ਅਤੇ ਫਿਰ ਕੁਸ਼ਲਤਾ। Habitat, OpenAI ਲਈ ਇੱਕ ਅਹਿਮ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਬਣ ਚੁੱਕਾ ਸੀ, ਇਸ ਲਈ ਪਹਿਲੀ ਤਰਜੀਹ ਇਸ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਣਾ ਸੀ। 2025 ਵਿੱਚ ਸਿਸਟਮ ਦੇ ਸਥਿਰ ਹੋਣ ਅਤੇ OpenAI ਦੇ ਵਿਸ਼ਵ ਪੱਧਰ 'ਤੇ ਵਿਸਤਾਰ ਨਾਲ ਲੇਟੈਂਸੀ ਵਰਤੋਂਕਾਰਾਂ ਅਤੇ ਉਤਪਾਦ ਟੀਮਾਂ ਲਈ ਅਗਲੀ ਰੁਕਾਵਟ ਬਣ ਗਈ।

ਕੰਪਿਊਟ ਅਤੇ ਸਟੋਰੇਜ ਸਮਰੱਥਾ ਅਕਸਰ ਵੱਖ-ਵੱਖ ਖੇਤਰਾਂ ਵਿੱਚ ਹੁੰਦੀ ਸੀ, ਜਿਸ ਕਰਕੇ ਖੇਤਰਾਂ ਵਿਚਕਾਰ ਬੇਨਤੀਆਂ ਭੇਜਣੀਆਂ ਲਾਜ਼ਮੀ ਹੋ ਜਾਂਦੀਆਂ ਸਨ।

ਡੇਟਾ ਕਿੱਥੇ ਸਟੋਰ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਬੇਨਤੀ ਕਿੱਥੇ ਸਰਵ ਕੀਤੀ ਗਈ ਸੀ, ਇਸ ਦੇ ਆਧਾਰ 'ਤੇ ਲੇਟੈਂਸੀ ਵਿੱਚ ਕਾਫ਼ੀ ਫ਼ਰਕ ਹੁੰਦਾ ਸੀ। Habitat ਦੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਅਤੇ ਤੇਜ਼ ਬਣਾਉਣ ਲਈ, ਉਤਪਾਦ ਡਿਵੈਲਪਰਾਂ ਨੇ ਵਾਧੂ ਕਲਾਇੰਟ-ਸਾਈਡ ਕੈਚਿੰਗ, ਬੇਨਤੀ ਬੈਚਿੰਗ, ਡੇਟਾਬੇਸ ਵਿੱਚ ਪੜ੍ਹਨ-ਲਿਖਣ ਨੂੰ ਘੱਟ ਕਰਨ, ਅਤੇ ਜਿੱਥੇ ਵੀ ਸੰਭਵ ਹੋਵੇ ਕੰਮ ਨੂੰ ਕ੍ਰਿਟੀਕਲ ਪਾਥ ਤੋਂ ਹਟਾਉਣ 'ਤੇ ਭਰੋਸਾ ਕੀਤਾ। ਹਾਲਾਂਕਿ ਇਸ ਨਾਲ ਕੁਝ ਅਜਿਹੇ ਦਿਲਚਸਪ ਉਤਪਾਦ ਡਿਜ਼ਾਈਨ ਬਣੇ ਜੋ ਡੇਟਾਬੇਸ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਬਿਹਤਰ ਢੰਗ ਨਾਲ ਸਹਿ ਸਕਦੇ ਸਨ, ਪਰ ਇਸ ਨੇ ਉਤਪਾਦਾਂ ਨੂੰ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਵੀ ਬਣਾ ਦਿੱਤਾ ਅਤੇ ਉਤਪਾਦ ਦੇ ਵਿਕਾਸ ਦੀ ਰਫ਼ਤਾਰ ਨੂੰ ਹੌਲੀ ਕਰ ਦਿੱਤਾ: ਜੋ ਕਿ Habitat ਦੇ ਉਸ ਉਦੇਸ਼ ਦੇ ਉਲਟ ਸੀ ਜਿਸ ਦਾ ਮਕਸਦ ਡੇਟਾਬੇਸ ਨੂੰ ਸਮਝਣ ਦੀ ਲੋੜ ਤੋਂ ਬਿਨਾਂ ਉਤਪਾਦਾਂ ਦਾ ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਾਸ ਕਰਨਾ ਸੀ।

2026 ਵਿੱਚ ਇਹ ਸਾਡਾ ਵੱਡਾ ਫੋਕਸ ਰਿਹਾ ਹੈ, ਅਤੇ ਪੜ੍ਹਨ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਅਸੀਂ ਬਹੁ-ਪੱਧਰੀ ਰਣਨੀਤੀ ਬਣਾਈ ਹੈ ਕਿਉਂਕਿ Habitat ਦੀਆਂ 90% ਤੋਂ ਵੱਧ ਬੇਨਤੀਆਂ ਡਾਟਾ ਪੜ੍ਹਨ ਨਾਲ ਸਬੰਧਤ ਹੁੰਦੀਆਂ ਹਨ:

ਡਾਟਾ ਰੈਜ਼ਿਡੈਂਸੀ ਦੀਆਂ ਲੋੜਾਂ ਵਾਲੇ ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਸਾਡੇ ਕੋਲ ਦੁਨੀਆ ਭਰ ਦੇ ਵੱਖ-ਵੱਖ Azure ਖੇਤਰਾਂ ਵਿੱਚ ਕਈ Azure Cosmos DB ਖਾਤੇ ਮੌਜੂਦ ਹਨ। ਇੱਥੋਂ ਤੱਕ ਕਿ ਸਖ਼ਤ ਡਾਟਾ ਰੈਜ਼ਿਡੈਂਸੀ ਲੋੜਾਂ ਤੋਂ ਬਿਨਾਂ ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਵੀ ਵਰਤੋਂਕਾਰਾਂ ਦੇ ਨੇੜੇ ਡੇਟਾ ਨੂੰ ਰੱਖਣਾ ਘੱਟ ਲੇਟੈਂਸੀ ਰਾਹੀਂ ਉਨ੍ਹਾਂ ਦੇ ਤਜ਼ਰਬੇ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਂਦਾ ਹੈ।

ਅਸਲ ਵਿੱਚ, ਡਾਟਾ ਰੈਜ਼ਿਡੈਂਸੀ ਦੇ ਮਾਮਲਿਆਂ ਤੋਂ ਇਲਾਵਾ ਅਸੀਂ ਇਸਨੂੰ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹਾਂ ਕਿਉਂਕਿ ਡੇਟਾ ਦਾ ਰੱਖ-ਰਖਾਅ ਭੌਤਿਕ ਕਲਾਉਡ ਸਮਰੱਥਾ ਤੱਕ ਸੀਮਤ ਹੁੰਦਾ ਹੈ। ਸਾਡੇ ਡੇਟਾ ਸੈੱਟ ਇੰਨੇ ਵੱਡੇ ਹਨ ਕਿ ਕਈ ਖੇਤਰ ਆਪਣੇ ਹਿੱਸੇ ਦੀ ਵਰਤੋਂਕਾਰ ਟ੍ਰੈਫ਼ਿਕ ਲਈ ਲੋੜੀਂਦੀ ਵਿਸ਼ਾਲ ਸਟੋਰੇਜ ਨਹੀਂ ਦੇ ਸਕਦੇ।

ਸੀਮਤ ਡਾਟਾਸੈਂਟਰ ਸਮਰੱਥਾ, ਬਿਜਲੀ ਜਾਂ ਕੂਲਿੰਗ ਵਾਲੇ ਖੇਤਰਾਂ ਵਿੱਚ ਸਾਨੂੰ ਕਈ ਵਾਰ ਸਿੱਧਾ ਸਮਝੌਤਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ: ਨੇੜੇ ਸਟੋਰੇਜ ਰੱਖ ਕੇ Habitat ਦੀ ਲੇਟੈਂਸੀ ਘਟਾਉਣ ਲਈ ਸਮਰੱਥਾ ਰਾਖਵੀਂ ਰੱਖੀਏ, ਜਾਂ ਉਸ ਸਮਰੱਥਾ ਦੀ ਵਰਤੋਂ ਵਾਧੂ ਸਰਵਿੰਗ ਕੰਪਿਊਟ ਲਈ ਕਰੀਏ ਅਤੇ ਸਟੋਰੇਜ ਬੇਨਤੀਆਂ ਨੂੰ ਹੋਰ ਦੂਰ ਰੂਟ ਕਰੀਏ।

ਸਿੱਟੇ ਵਜੋਂ, ਪਲੇਸਮੈਂਟ ਦੇ ਫ਼ੈਸਲੇ ਅਕਸਰ ਹੇਠ ਲਿਖੀਆਂ ਦੋ ਚੀਜ਼ਾਂ ਵਿਚਕਾਰ ਉਤਪਾਦ ਟਰੇਡ-ਆਫ਼ ਹੁੰਦੇ ਹਨ: A) ਵੱਖ-ਵੱਖ ਉਤਪਾਦਾਂ ਅਤੇ ਵਰਤੋਂਕਾਰਾਂ ਦੇ ਸਮੂਹਾਂ ਲਈ ਲੇਟੈਂਸੀ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ, ਅਤੇ B) ਕੱਚੀ ਸਟੋਰੇਜ ਅਤੇ ਕੰਪਿਊਟ ਸਮਰੱਥਾ।

ਸਭ ਤੋਂ ਵੱਧ ਲੇਟੈਂਸੀ-ਕ੍ਰਿਟੀਕਲ ਵਰਕਲੋਡਾਂ ਲਈ, ਜਿਵੇਂ ਕਿ ਪ੍ਰਮਾਣੀਕਰਨ ਮੈਟਾਡਾਟਾ ਜਿਸਦੀ ਹਰ ਬੇਨਤੀ 'ਤੇ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਸੀਂ ਕਈ ਸੈਕੰਡਰੀ ਖੇਤਰਾਂ ਵਾਲੇ ਉੱਚ ਪੱਧਰ 'ਤੇ ਕਾਪੀਆਂ ਰੱਖਣ ਵਾਲੇ Azure Cosmos DB ਖਾਤਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੰਪਿਊਟ ਅਤੇ Habitat ਵਿਚਕਾਰ ਆਉਣ-ਜਾਣ ਦਾ ਸਮਾਂ (RTT) ਘਟਾਉਂਦੇ ਹਾਂ। ਕੁਝ ਖਾਤਿਆਂ ਦੀਆਂ ਕਾਪੀਆਂ ਉਨ੍ਹਾਂ ਸਾਰੇ 40 Azure ਖੇਤਰਾਂ ਵਿੱਚ ਹਨ ਜਿੱਥੇ ਅਸੀਂ ਟ੍ਰੈਫ਼ਿਕ ਸੰਭਾਲਦੇ ਹਾਂ; ਜਦੋਂ ਕਿ ਹੋਰਾਂ ਦੀਆਂ ਹਰ ਮਹਾਂਦੀਪ ਦੇ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਖੇਤਰ ਵਿੱਚ ਹਨ।

ਸਾਨੂੰ Habitat ਵਿੱਚ ਉਮੀਦ ਨਾਲੋਂ ਪਹਿਲਾਂ ਇੱਕ ਪਾਰਦਰਸ਼ੀ ਡੇਟਾ ਮੂਵਮੈਂਟ ਅਤੇ ਰੂਟਿੰਗ ਲੇਅਰ ਬਣਾਉਣੀ ਪਈ ਹੈ, ਤਾਂ ਜੋ ਅਸੀਂ ਵੱਖ-ਵੱਖ ਰਿਪਲੀਕੇਸ਼ਨ ਟੋਪੋਲੋਜੀਜ਼ ਵਾਲੇ ਖਾਤਿਆਂ ਵਿਚਕਾਰ ਡੇਟਾਸੈੱਟਾਂ ਨੂੰ ਮੂਵ ਕਰ ਸਕੀਏ।

ਹਾਲਾਂਕਿ, ਇਹ ਪਹੁੰਚ ਵੀ ਆਖਰਕਾਰ ਸਮਰੱਥਾ ਪੱਖੋਂ ਸੀਮਤ ਹੈ ਅਤੇ ਇਸ ਕਾਰਨ ਇਹ ਕੇਵਲ ਕੁਝ ਚੁਨਿੰਦਾ ਡੇਟਾਸੈੱਟਾਂ ਤੱਕ ਹੀ ਸੀਮਤ ਹੈ।

Habitat ਦੇ ਵਰਕਲੋਡ ਮੁੱਖ ਤੌਰ 'ਤੇ ਰੀਡ-ਹੈਵੀ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਗਾਤਾਰ ਸੈਟਿੰਗਾਂ, ਸਥਿਤੀ ਅਤੇ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ; ਟ੍ਰੈਫ਼ਿਕ ਦਾ ਇੱਕ ਵੱਡਾ ਹਿੱਸਾ ਅਕਸਰ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਡਾਟਾ ਦੇ ਮੁਕਾਬਲਤਨ ਛੋਟੇ ਸਰਗਰਮ ਸਮੂਹ ਤੋਂ ਆਉਂਦਾ ਹੈ। ਇਹ ਸਿਸਟਮ ਨੂੰ ਡਿਸਟ੍ਰੀਬਿਊਟਿਡ ਕੈਸ਼ਿੰਗ ਲਈ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਢੁਕਵਾਂ ਬਣਾਉਂਦਾ ਹੈ। ਹਾਲਾਂਕਿ ਕੈਸ਼ਿੰਗ ਇੱਕੋ ਖੇਤਰ ਦੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਂਦੀ ਹੈ, ਪਰ ਜਦੋਂ ਕੰਮ ਵੱਖ-ਵੱਖ ਖੇਤਰਾਂ ਵਿੱਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਇਹ ਸੁਧਾਰ ਹੋਰ ਵੀ ਵੱਧ ਜਾਂਦੇ ਹਨ, ਜਿੱਥੇ ਇਸਦੀ ਵਰਤੋਂ ਖੇਤਰਾਂ ਵਿਚਕਾਰਲੀ ਦੇਰੀ ਨੂੰ “ਲੁਕਾਉਣ” ਲਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

ਅਸੀਂ Habitat ਵਿੱਚ ਡਿਸਟ੍ਰੀਬਿਊਟਿਡ ਲੁੱਕਸਾਈਡ ਕੈਸ਼ਿੰਗ ਪਰਤ ਨੂੰ ਏਕੀਕ੍ਰਿਤ ਕੀਤਾ ਹੈ। ਇਹ ਸਾਡੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਸਥਿਤ Valkey ਸਰਵਰਾਂ ਵਿੱਚ ਹਾਲ ਹੀ ਵਿੱਚ ਵਰਤੇ ਗਏ ਆਬਜੈਕਟਾਂ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਸੰਬੰਧਾਂ ਦੀ ਕਾਪੀ ਸਟੋਰ ਕਰਦੀ ਹੈ, ਜੋ ਉਸ ਥਾਂ ਦੇ ਨੇੜੇ ਹੁੰਦੇ ਹਨ ਜਿੱਥੇ ਵਰਤੋਂਕਾਰ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਇਸ ਕਿਸਮ ਦੇ ਕੈਸ਼ ਇੱਕ TTL ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਜੋ ਕੈਸ਼ ਵਿੱਚ ਡਾਟਾ ਮਿਲਣ ਦੀ ਦਰ ਅਤੇ ਡਾਟੇ ਦੇ ਪੁਰਾਣੇਪਣ ਵਿਚਕਾਰ ਸੰਤੁਲਨ ਬਣਾਉਂਦਾ ਹੈ। ਛੋਟੀ TTL ਪੁਰਾਣਾਪਣ ਘਟਾਉਂਦੀ ਹੈ ਪਰ ਕੈਸ਼ਿੰਗ ਦੇ ਸਕਾਰਾਤਮਕ ਪ੍ਰਭਾਵ ਨੂੰ ਘਟਾ ਦਿੰਦੀ ਹੈ ਕਿਉਂਕਿ ਆਈਟਮਾਂ ਕੈਸ਼ ਵਿੱਚੋਂ ਜਲਦੀ ਖਤਮ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਵਾਰ-ਵਾਰ ਮੁੜ ਲਿਆਉਣਾ ਪੈਂਦਾ ਹੈ। ਲੰਮੀ TTL ਨਾਲ ਕੈਸ਼ ਵਿੱਚ ਡਾਟਾ ਮਿਲਣ ਦੀ ਦਰ ਵਧਦੀ ਹੈ, ਪਰ ਲੰਬੇ ਸਮੇਂ ਲਈ ਪੁਰਾਣਾ ਡਾਟਾ ਮਿਲਦਾ ਰਹਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਮਾੜਾ ਵਰਤੋਂਕਾਰ ਅਨੁਭਵ ਅਤੇ ਉਤਪਾਦ ਦਾ ਅਣਕਿਆਸਾ ਵਿਹਾਰ ਪੈਦਾ ਹੁੰਦਾ ਹੈ।

ਇੱਕ ਹੋਰ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਮੂਲ ਡਾਟੇ ਉੱਤੇ ਰਾਈਟ ਓਪਰੇਸ਼ਨ ਕਰ ਰਹੀ ਹੋਵੇ, ਤਾਂ ਸਪੱਸ਼ਟ ਇਨਵੈਲੀਡੇਸ਼ਨ ਓਪਰੇਸ਼ਨ ਕੀਤੇ ਜਾਣ। ਇਸ ਨਾਲ ਕੈਸ਼ ਕੀਤੇ ਗਏ ਡਾਟਾ ਦੀ ਤਾਜ਼ਗੀ ਵਿੱਚ ਕਾਫ਼ੀ ਸੁਧਾਰ ਹੁੰਦਾ ਹੈ, ਪਰ ਇਸ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਕਈ ਤਰ੍ਹਾਂ ਦੇ ਖਾਸ ਮਾਮਲਿਆਂ, ਜਿਵੇਂ ਕਿ ਅੰਸ਼ਕ ਅਸਫਲਤਾਵਾਂ ਦੇ ਅਧੀਨ ਵੀ ਰਹਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਕੈਸ਼ ਪੁਰਾਣਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਮਲਟੀ-ਰੀਜਨ ਡਿਪਲਾਇਮੈਂਟਸ ਇਨ੍ਹਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੋਰ ਵਧਾ ਦਿੰਦੇ ਹਨ, ਜਿਸ ਵਿੱਚ ਘੱਟ ਭਰੋਸੇਯੋਗ ਕਰਾਸ-ਰੀਜਨ ਨੈੱਟਵਰਕ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਕੈਸ਼ ਮੂਲ ਸਟੋਰੇਜ ਦੇ ਰਿਪਲੀਕੇਸ਼ਨ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦਾ ਹੈ। TTL ਨਾਲ ਇਸ ਦੀ ਪੂਰਤੀ ਕਰਨ ਨਾਲ ਵੱਧ ਤੋਂ ਵੱਧ ਪੁਰਾਣੇਪਣ ਦੀ ਹੱਦ ਤੈਅ ਹੋ ਜਾਂਦੀ ਹੈ, ਪਰ ਫਿਰ ਵੀ ਇਹ ਉਪਰ ਚਰਚਾ ਕੀਤੇ ਗਏ ਉਸੇ ਮੂਲ TTL ਸਮਝੌਤੇ ਤੋਂ ਪ੍ਰਭਾਵਿਤ ਰਹਿੰਦਾ ਹੈ।

ਅਸੀਂ Meta ਦੇ TAO ਵਰਗੇ ਸਿਸਟਮਾਂ ਤੋਂ ਸੇਧ ਲੈ ਕੇ ਇਨਵੈਲੀਡੇਸ਼ਨ ਲਈ ਵਧੇਰੇ ਉੱਨਤ ਪਹੁੰਚ ਅਪਣਾਈ ਹੈ। Habitat ਦਾ ਏਕੀਕ੍ਰਿਤ ਕੈਸ਼ Azure Cosmos DB ਦੀ ਚੇਂਜ ਫੀਡ ਰਾਹੀਂ ਚੇਂਜ ਡਾਟਾ ਕੈਪਚਰ (CDC) 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਕੁਝ ਸਕਿੰਟਾਂ ਦੇ ਅੰਦਰ-ਅੰਦਰ ਗਲੋਬਲ ਪੱਧਰ 'ਤੇ ਇਨਵੈਲੀਡੇਸ਼ਨਾਂ ਨੂੰ ਅੱਗੇ ਵਧਾਇਆ ਜਾ ਸਕੇ, ਜਿਸ ਨਾਲ ਘੱਟ ਪੁਰਾਣੇਪਣ ਨੂੰ ਬਣਾਈ ਰੱਖਦੇ ਹੋਏ ਉੱਚ ਹਿੱਟ ਰੇਟ ਪ੍ਰਾਪਤ ਹੁੰਦੇ ਹਨ। ਸਾਡੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਇੱਕ ਸੇਵਾ ਇਸ ਚੇਂਜ ਫੀਡ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ ਅਤੇ ਜਦੋਂ ਮੂਲ ਡਾਟਾ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਥਾਨਕ ਕੈਸ਼ਾਂ ਉੱਤੇ ਇਨਵੈਲੀਡੇਸ਼ਨ ਓਪਰੇਸ਼ਨ ਕਰਦੀ ਹੈ। ਇਸ ਨਾਲ ਅਗਲੀ ਵਾਰ ਡਾਟਾ ਪੜ੍ਹੇ ਜਾਣ 'ਤੇ ਕੈਸ਼ ਮਿਸ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਕੈਸ਼ ਡਾਟਾ ਦੇ ਨਵੀਨਤਮ ਸੰਸਕਰਣ ਨਾਲ ਭਰ ਜਾਂਦਾ ਹੈ।

ਅਸੀਂ ਮੂਲ Python ਨਾਲੋਂ ਵਧੇਰੇ ਕਾਰਗੁਜ਼ਾਰ Rust ਵਿੱਚ ਕੋਡ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖ ਕੇ Habitat ਸੇਵਾ ਦੇ ਆਪਣੇ ਅੰਦਰੋਂ ਓਵਰਹੈੱਡ ਨੂੰ ਹਟਾ ਕੇ ਲੇਟੈਂਸੀ ਨੂੰ ਵੀ ਕਾਫ਼ੀ ਹੱਦ ਤੱਕ ਘਟਾ ਦਿੱਤਾ ਹੈ।

ਇਨ੍ਹਾਂ ਸਾਰਿਆਂ ਨੂੰ ਮਿਲਾ ਕੇ ਕੀਤੇ ਗਏ ਬਦਲਾਵਾਂ ਨੇ ਸਾਡੇ ਸਮੁੱਚੇ ਗਲੋਬਲ ਰੀਡ p50 ਨੂੰ ਲਗਭਗ 120 ਮਿਲੀਸਕਿੰਟ ਤੋਂ ਘਟਾ ਕੇ ਲਗਭਗ 10 ਮਿਲੀਸਕਿੰਟ ਕਰ ਦਿੱਤਾ ਹੈ, ਜੋ ਕਿ ਇਸ ਸਾਲ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਧਿਆਨ ਦੇਣਾ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਬਾਅਦ 12 ਗੁਣਾ ਸੁਧਾਰ ਹੈ।

ਭਾਵੇਂ ਕੈਸ਼ਿੰਗ ਨੇ ਔਸਤ ਲੇਟੈਂਸੀ ਨੂੰ ਕਾਫ਼ੀ ਹੱਦ ਤੱਕ ਘਟਾ ਦਿੱਤਾ ਹੈ, ਪਰ ਸਭ ਤੋਂ ਹੌਲੀ ਬੇਨਤੀਆਂ ਲਈ ਅਜੇ ਵੀ ਮੂਲ ਸਟੋਰੇਜ ਤੋਂ ਬਿਨਾਂ-ਕੈਸ਼ ਕੀਤੇ ਡਾਟਾ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜੋ ਕਿ ਅਕਸਰ ਦੂਰ-ਦੁਰਾਡੇ ਦੇ ਖੇਤਰਾਂ ਤੋਂ ਹੁੰਦਾ ਹੈ। ਜਿਵੇਂ-ਜਿਵੇਂ ਵਧੇਰੇ ਸਮਰੱਥਾ ਉਪਲਬਧ ਹੋ ਰਹੀ ਹੈ ਅਤੇ ਅਸੀਂ ਸਟੋਰੇਜ ਦੀ ਕੁਸ਼ਲਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰ ਰਹੇ ਹਾਂ, ਅਸੀਂ ਇੱਕ ਹੋਰ ਬੁਨਿਆਦੀ ਚੁਣੌਤੀ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ: ਡਾਟਾ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਉਸ ਥਾਂ ਦੇ ਨੇੜੇ ਰੱਖਣਾ ਜਿੱਥੇ ਇਸ ਤੱਕ ਪਹੁੰਚ ਕੀਤੀ ਜਾਣੀ ਹੈ।

ਭਰੋਸੇਯੋਗ ਅਤੇ ਸਕੇਲੇਬਲ CDC—ਡਾਟਾਬੇਸ ਤਬਦੀਲੀਆਂ ਨੂੰ ਡਾਊਨਸਟ੍ਰੀਮ ਸਿਸਟਮਾਂ ਤੱਕ ਪਹੁੰਚਾਉਣਾ—ਕੇਵਲ Habitat ਦੀ ਕੈਸ਼ਿੰਗ ਰਣਨੀਤੀ ਵਿੱਚ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਇਸ ਤੋਂ ਵੀ ਵੱਧ ਇੱਕ ਅਹਿਮ ਹਿੱਸਾ ਹੈ। ਹਜ਼ਾਰਾਂ ਕੰਟੇਨਰਾਂ ਅਤੇ ਲੱਖਾਂ ਕੰਟੇਨਰ ਪਾਰਟੀਸ਼ਨਾਂ ਵਿੱਚ ਫੈਲੀਆਂ ਹੋਈਆਂ ਪ੍ਰਤੀ ਸਕਿੰਟ ਲੱਖਾਂ ਕੈਪਚਰ ਕੀਤੀਆਂ ਤਬਦੀਲੀਆਂ ਸੌ ਤੋਂ ਵੱਧ Kafka ਟੌਪਿਕਸ ਰਾਹੀਂ ਅੱਗੇ ਵਧਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਅੰਤ ਵਿੱਚ ਇਕਸਾਰ ਰਹਿਣ ਵਾਲੇ ਸੈਕੰਡਰੀ ਇੰਡੈਕਸ, ਡਾਟਾ-ਮੂਵਮੈਂਟ ਪਾਈਪਲਾਈਨਾਂ, ਆਫ਼ਲਾਈਨ ਵਿਸ਼ਲੇਸ਼ਣ, ਅਤੇ ਹੋਰ ਰੀਅਲ-ਟਾਈਮ ਉਤਪਾਦ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਵੀ ਸੰਚਾਲਿਤ ਕੀਤਾ ਜਾ ਸਕੇ। ਜਿਵੇਂ-ਜਿਵੇਂ ਸਾਡਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਗਲੋਬਲ ਪੱਧਰ 'ਤੇ ਵਧਿਆ ਹੈ, ਰੋਅ ਤਬਦੀਲੀਆਂ ਨੂੰ ਸੁਣਨਾ ਵੱਧ ਤੋਂ ਵੱਧ ਗੁੰਝਲਦਾਰ ਹੋ ਗਿਆ ਹੈ। ਜੇ ਕੋਈ ਕਲਾਇੰਟ ਕਾਲਬੈਕ ਰਜਿਸਟਰ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ ਤਾਂ ਜੋ ਉਸ ਦੀ ਕਿਸਮ ਦੀਆਂ ਰੋਅ ਬਦਲਣ 'ਤੇ ਚੱਲ ਸਕੇ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਹੋਰ ਚੀਜ਼ਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਪਹਿਲਾਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿਹੜੇ Cosmos ਅਕਾਊਂਟ ਅਤੇ ਕੰਟੇਨਰਾਂ ਵਿੱਚ ਉਨ੍ਹਾਂ ਦਾ ਡਾਟਾ ਹੈ, ਕਿਹੜੀ CDC ਸੇਵਾ ਡਿਪਲਾਇਮੈਂਟ ਸੰਬੰਧਿਤ ਖੇਤਰਾਂ ਵਿੱਚ ਉਨ੍ਹਾਂ ਕੰਟੇਨਰਾਂ ਨੂੰ ਸੁਣ ਰਹੀ ਹੈ, ਅਤੇ CDC ਸੇਵਾ ਵਰਕਰ ਫਲੀਟ, Kafka, ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਕੰਜ਼ਿਊਮਰ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਸਕੇਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਸਾਡਾ CDC ਪਲੇਟਫਾਰਮ ਇਸ ਸਭ ਨੂੰ ਪ੍ਰੋਡਕਟ ਡਿਵੈਲਪਰਾਂ ਤੋਂ ਦੂਰ ਰੱਖਣ ਦਾ ਉਦੇਸ਼ ਰੱਖਦਾ ਹੈ ਅਤੇ ਇਸ ਦੀ ਬਜਾਏ ਇੱਕ ਸਧਾਰਨ ਇੰਟਰਫੇਸ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਕਲਾਇੰਟ ਇੱਕ ਫੰਕਸ਼ਨ ਰਜਿਸਟਰ ਕਰਦੇ ਹਨ ਜਿਸ ਨੂੰ ਉਹ ਆਪਣੇ ਬਦਲੇ ਹੋਏ ਰੋਅ ਉੱਤੇ ਕਾਲ ਕਰਵਾਉਣਾ ਚਾਹੁੰਦੇ ਹਨ ਅਤੇ ਅਸੀਂ ਸਾਰੇ ਪਲੰਬਿੰਗ ਅਤੇ ਸਕੇਲਿੰਗ ਨੂੰ ਸੰਭਾਲਦੇ ਹਾਂ।

ਇੱਕ ਅੰਦਰੂਨੀ ਕੰਟਰੋਲ ਪਲੇਨ ਲਗਾਤਾਰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਸਾਰੇ ਲੋੜੀਂਦੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਕੈਪਚਰ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ, ਇਹ ਚੁਣਦਾ ਹੈ ਕਿ ਕਿਨ੍ਹਾਂ Cosmos ਖੇਤਰਾਂ ਤੋਂ ਪੜ੍ਹਨਾ ਹੈ, ਅਤੇ ਕਈ ਭੂਗੋਲਿਕ ਖੇਤਰਾਂ ਵਿੱਚ ਫੈਲੇ ਹਜ਼ਾਰਾਂ ਵਰਕਰਾਂ ਵਿੱਚ ਕੰਮ ਨੂੰ ਕੁਸ਼ਲਤਾ ਨਾਲ ਵੰਡਦਾ ਹੈ। ਰਿਪਲੀਕਾ ਖੇਤਰਾਂ ਅਤੇ ਘੱਟ-ਪ੍ਰਾਥਮਿਕਤਾ ਵਾਲੇ ਫੀਡ ਪਾਠਨ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਲੇਟੈਂਸੀ-ਸੰਵੇਦਨਸ਼ੀਲ Habitat ਟ੍ਰੈਫਿਕ ਨੂੰ ਬੈਕਗ੍ਰਾਊਂਡ ਕੈਪਚਰ ਵਰਕਲੋਡਾਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ। ਇੰਨੇ ਵੱਡੇ ਫਲੀਟ ਵਿੱਚ ਵਰਕਰ ਕਰੈਸ਼, ਕੰਟੇਨਰ ਸਮੱਸਿਆਵਾਂ, ਲੀਜ਼-ਸਟੋਰ ਗਲਤੀਆਂ, ਗਲਤ ਕੌਂਫਿਗਰੇਸ਼ਨ, ਅਤੇ ਡੈਸਟੀਨੇਸ਼ਨ ਅਸਫਲਤਾਵਾਂ ਲਗਾਤਾਰ ਵਾਪਰਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ। ਅਸੀਂ CDC ਵਰਕਰ ਲਾਈਫਸਾਈਕਲ ਅਤੇ ਲੀਜ਼ ਹੈਂਡਲਿੰਗ ਨੂੰ ਮਜ਼ਬੂਤ ਕੀਤਾ ਹੈ, ਸਟ੍ਰੀਮਾਂ ਵਿਚਕਾਰ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਆਈਸੋਲੇਟ ਕੀਤਾ ਹੈ, ਅਤੇ ਕੌਂਫਿਗਰੇਸ਼ਨ ਤਬਦੀਲੀਆਂ ਅਤੇ ਰੋਲਆਊਟਸ ਲਈ ਸੇਫਗਾਰਡ ਬਣਾਏ ਹਨ। ਅਸੀਂ ਸਥਾਈ ਡਿਲੀਵਰੀ ਅਸਫਲਤਾਵਾਂ ਤੋਂ ਹੈੱਡ-ਆਫ਼-ਲਾਈਨ ਬਲੌਕਿੰਗ ਨੂੰ ਰੋਕਣ ਲਈ ਡੈਡ ਲੇਟਰ ਕਿਊਜ਼ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਰੀਡਰਾਂ ਨੂੰ ਬਦਲਵੇਂ Cosmos ਖੇਤਰਾਂ ਵਿੱਚ ਸਵਿੱਚ ਕਰਕੇ ਖੇਤਰੀ ਆਊਟੇਜ ਨੂੰ ਬਰਦਾਸ਼ਤ ਕਰਦੇ ਹਾਂ। ਸਾਡੇ ਸਕੇਲ 'ਤੇ, ਸਾਨੂੰ ਚੈਕਪੁਆਇੰਟਿੰਗ ਨੂੰ ਮੈਮੋਰੀ ਵਿੱਚ ਬੈਚ ਕਰਕੇ ਅਤੇ ਸਿਰਫ਼ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਫਲੱਸ਼ ਕਰਕੇ ਇਸ ਦੇ ਲਾਗੂਕਰਨ ਨੂੰ ਵਧੇਰੇ ਕੁਸ਼ਲ ਬਣਾਉਣ ਲਈ Azure ਦੇ CDC SDK ਵਿੱਚ ਵੀ ਤਬਦੀਲੀਆਂ ਕਰਨੀਆਂ ਪਈਆਂ ਹਨ।

ਭਾਵੇਂ Habitat ਦਾ Azure Cosmos DB ਦੀ ਵਰਤੋਂ ਗੁੰਝਲਦਾਰ ਹੈ, ਪਰ ਇਸ ਦਾ ਮੁੱਲ ਪ੍ਰਸਤਾਵ ਹਮੇਸ਼ਾ ਉਤਪਾਦ ਵਿਕਾਸ ਦੀ ਰਫ਼ਤਾਰ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਪ੍ਰੋਡਕਟ ਡਿਵੈਲਪਰਾਂ ਤੋਂ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਵੇਰਵਿਆਂ ਨੂੰ ਦੂਰ ਰੱਖਣਾ ਰਿਹਾ ਹੈ, ਅਤੇ ਸਾਡਾ CDC ਪਲੇਟਫਾਰਮ ਵੀ ਇਸ ਤੋਂ ਵੱਖਰਾ ਨਹੀਂ ਹੈ।

ਸਟੋਰੇਜ API ਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਸੀਮਤ ਰੱਖ ਕੇ, Python ਸੇਵਾ ਨੂੰ ਸਕੇਲ ਕਰਨਾ ਜਾਰੀ ਰੱਖ ਕੇ, ਅਤੇ ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਇੰਜੀਨੀਅਰਿੰਗ ਚੁਣੌਤੀਆਂ ਨੂੰ ਪਹਿਲ ਦੇ ਕੇ ਇੱਕ ਛੋਟੀ ਟੀਮ ਨੇ ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਰਹੇ ਸਟੋਰੇਜ ਪਲੇਟਫਾਰਮ ਨੂੰ ਸਹਾਰਾ ਦਿੱਤਾ। ਅਸੀਂ ਪਹਿਲਾਂ ਮਿਸ਼ਨ-ਕ੍ਰਿਟੀਕਲ ਪ੍ਰੋਡਕਟ ਟ੍ਰੈਫਿਕ ਲਈ ਭਰੋਸੇਯੋਗਤਾ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕੀਤਾ, ਫਿਰ ਗਲੋਬਲ ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਰੀਡ ਪ੍ਰਦਰਸ਼ਨ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਕਾਰਜਸ਼ੀਲ ਕੁਸ਼ਲਤਾ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕੀਤਾ। ਇਸ ਪਹੁੰਚ ਨੇ ਭਰੋਸੇਯੋਗਤਾ, ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਉਤਪਾਦ ਵਿਕਾਸ ਦੀ ਰਫ਼ਤਾਰ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਂਦੇ ਹੋਏ ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਾਸ ਅਤੇ ਨਵੇਂ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਨੂੰ ਸਮਰੱਥ ਬਣਾਇਆ।

ਅਗਲੇ ਇੱਕ ਅਰਬ ਵਰਤੋਂਕਾਰਾਂ ਲਈ Habitat ਅਤੇ ਕਨਵਰਸੇਸ਼ਨ ਸਟੋਰੇਜ ਨੂੰ ਸਕੇਲ ਕਰਨ ਵਾਸਤੇ, ਸਾਨੂੰ ਹੋਰ ਵੀ ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਆਪਣੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਆਪਣੇ ਡਾਟਾ ਨੂੰ ਰਿਪਲੀਕੇਟ ਕਰਨ ਦੀ ਮੁਸ਼ਕਲ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਇਹ ਸਮੱਸਿਆ ਬਣੇ, ਅਸੀਂ ਇੱਕ ਕਸਟਮ ਇਨ-ਹਾਊਸ ਐਕਸਾਬਾਈਟ-ਸਕੇਲ ਔਨਲਾਈਨ ਸਟੋਰੇਜ ਸਿਸਟਮ ਤਿਆਰ ਕਰ ਰਹੇ ਹਾਂ, ਜੋ ਵੱਡੇ ਆਕਾਰ ਦੇ Habitat ਡਾਟਾ ਪ੍ਰਕਾਰਾਂ ਲਈ ਅਨੁਕੂਲ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਇਹ ਵਿਕਾਸ ਅਧੀਨ ਸਿਸਟਮ Rockset ਦੇ RocksDB ਕਲਾਊਡ ਕੋਰ ਨੂੰ Raft-ਆਧਾਰਿਤ ਰਿਪਲੀਕੇਸ਼ਨ ਨਾਲ ਜੋੜਦਾ ਹੈ। ਇਹ Azure Cosmos DB ਵਾਂਗ ਹੀ ਡਾਕੂਮੈਂਟ ਮਾਡਲ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਪਰ ਘੱਟ ਪੀਕ QPS ਦੇ ਬਦਲੇ ਲੋੜੀਂਦੀ ਫਲੈਸ਼ ਸਮਰੱਥਾ ਨੂੰ ਘਟਾਉਣ ਲਈ ਡਿਸਐਗ੍ਰੀਗੇਟਿਡ ਸਟੋਰੇਜ ਅਤੇ ਫਿਜ਼ੀਕਲ ਰਿਪਲੀਕੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ ਅਤਿ-ਆਧੁਨਿਕ ਪੈਮਾਨੇ 'ਤੇ ਅਜਿਹੇ ਡਾਟਾ ਢਾਂਚੇ ਦੇ ਕੰਮਾਂ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਸਾਡੀਆਂ ਖ਼ਾਲੀ ਅਸਾਮੀਆਂ ਦੇਖੋ⁠।