ਇੱਕ ਅਰਬ ਤੋਂ ਵੱਧ ChatGPT ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਔਨਲਾਈਨ ਸਟੋਰੇਜ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਕੇਲ ਕਰਨਾ

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

Habitat ਉਹ ਔਨਲਾਈਨ ਸਟੋਰੇਜ ਪਲੇਟਫਾਰਮ ਹੈ ਜੋ ਅਸੀਂ OpenAI ਪ੍ਰੋਡਕਟਾਂ ਨੂੰ ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਤੱਕ ਤੇਜ਼ ਅਤੇ ਭਰੋਸੇਯੋਗ ਪਹੁੰਚ ਦੇਣ ਲਈ ਬਣਾਇਆ ਹੈ. Habitat ਹੁਣ ਲਗਭਗ 40 ਭੂਗੋਲਿਕ ਖੇਤਰਾਂ ਵਿੱਚ ਹਰ ਹਫ਼ਤੇ 1 ਅਰਬ ਤੋਂ ਵੱਧ ਲੋਕਾਂ ਵੱਲੋਂ ਵਰਤੇ ਜਾਂਦੇ ਪ੍ਰੋਡਕਟਾਂ ਲਈ ਹਰ ਸਕਿੰਟ 7 ਕਰੋੜ ਤੋਂ ਵੱਧ ਬੇਨਤੀਆਂ ਸੰਭਾਲਦਾ ਹੈ. Habitat ਪਹਿਲੀ ਵਾਰ DevDay 2023 ਵਿੱਚ GPTs ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ. ਇਸਦੀ ਸ਼ੁਰੂਆਤ ਇੱਕੋ ਡਾਟਾਬੇਸ ਨਾਲ ਜੁੜੀ ਸਰਲ Python ਕਲਾਇੰਟ-ਸਾਈਡ ਲਾਇਬ੍ਰੇਰੀ ਵਜੋਂ ਹੋਈ ਸੀ. ਅੱਜ ਇਹ ਇੱਕ ਪੇਚੀਦਾ ਵੰਡਿਆ ਹੋਇਆ ਸਿਸਟਮ ਹੈ ਜੋ 500 ਪੈਟਾਬਾਈਟ ਤੋਂ ਵੱਧ ਡਾਟੇ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ.

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

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

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

Habitat ਇੱਕ ਸਰਲ ਵਿਚਾਰ ਤੋਂ ਸ਼ੁਰੂ ਹੋਇਆ: ਪ੍ਰੋਡਕਟ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਡਾਟਾਬੇਸ ਪ੍ਰਬੰਧਨ ਬਾਰੇ ਸੋਚਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ. Habitat ਪਹਿਲੀ ਵਾਰ DevDay 2023 ਵਿੱਚ GPTs ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ ਇੱਕ ਛੋਟੀ Python ਲਾਇਬ੍ਰੇਰੀ ਵਜੋਂ ਸ਼ੁਰੂ ਹੋਇਆ, ਜੋ ChatGPT ਦੇ ਮੁੱਖ ਸਰਵਰ ਨਾਲ ਸੰਪਰਕ ਕਰਦੀ ਸੀ. ਇਹ ਕਾਰਵਾਈਆਂ ਦੇ ਇੱਕ ਛੋਟੇ ਸਮੂਹ ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਸੀ, ਜੋ ਅੰਦਰੂਨੀ ਤੌਰ ’ਤੇ ਡਾਟਾਬੇਸ ਐਪਲੀਕੇਸ਼ਨ, Azure Cosmos DB, ਵੱਲ ਮੈਪ ਹੁੰਦੀਆਂ ਸਨ.

ਲਾਇਬ੍ਰੇਰੀ ਦਾ ਕੰਮ ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ ਨੂੰ ਅੰਦਰੂਨੀ ਵੇਰਵਿਆਂ ਵਿੱਚ ਮੁਹਾਰਤ ਹਾਸਲ ਕੀਤੇ ਬਿਨਾਂ ਡਾਟਾ ਸਟੋਰ ਕਰਨ ਅਤੇ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਸਰਲ ਤਰੀਕਾ ਦੇਣਾ ਸੀ. Habitat ਲੋੜੀਂਦਾ ਕੰਮ ਆਪ ਸੰਭਾਲਦਾ ਸੀ: ਡਾਟੇ ਦੀ ਕਿਸਮ ਪਛਾਣਨਾ, ਇਹ ਕਿੱਥੋਂ ਆਉਣਾ (ਜਾਂ ਕਿੱਥੇ ਜਾਣਾ) ਚਾਹੀਦਾ ਹੈ, ਬੇਨਤੀ ਦੀ ਇਜਾਜ਼ਤ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਹੋਰ ਅਜਿਹੇ ਕੰਮ.

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

ਇਹ Python ਲਾਇਬ੍ਰੇਰੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਰਹੀ ਅਤੇ OpenAI ਦੇ ਪ੍ਰੋਡਕਟ ਇੰਜੀਨੀਅਰਾਂ ਵਿੱਚ Habitat ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅਪਣਾਇਆ ਗਿਆ, ਹਾਲਾਂਕਿ ਸਵੈ-ਸੇਵਾ Postgres ਅਤੇ Azure Cosmos DB ਦੀ ਵਰਤੋਂ ਤੋਂ ਦੂਰ ਜਾਣ ਲਈ ਕੇਂਦਰੀ ਪੱਧਰ ’ਤੇ ਕੋਈ ਵਿਸ਼ੇਸ਼ ਯਤਨ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ.

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

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

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

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

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

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

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

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

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

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

ਕਾਰਗੁਜ਼ਾਰੀ ਪੱਖੋਂ Habitat ਨੂੰ Python ਸੇਵਾ ਵਜੋਂ ਚਲਾਉਣਾ ਸਰਬੋਤਮ ਨਹੀਂ ਸੀ, ਪਰ ਇਹ ਜ਼ਰੂਰੀ ਚੋਣ ਸੀ. Python ਸਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣ ਦਿੰਦਾ ਹੈ, ਪਰ ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਸੀ ਕਿ ਅਸੀਂ ਸਾਵਧਾਨੀ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਕਾਫ਼ੀ ਮਾੜੀ ਲੇਟੈਂਸੀ ਸਵੀਕਾਰ ਕਰ ਲੈਂਦੇ. ਜਦੋਂ ਔਸਤ ਵਰਤੋਂਕਾਰ ਬੇਨਤੀ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਸੈਂਕੜੇ ਡਾਟਾਬੇਸ ਕਾਲਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਵਰਤੋਂਕਾਰ ਨੂੰ ਸਭ ਤੋਂ ਹੌਲੀ ਡਾਟਾਬੇਸ ਕਾਲ ਦੀ ਲੇਟੈਂਸੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ. ਅਸੀਂ ਪਾਇਆ ਹੈ ਕਿ ਇਸ ਪੈਮਾਨੇ ’ਤੇ Python ਸੇਵਾ ਚਲਾਉਣ ਦੀ ਮੁੱਖ ਚੁਣੌਤੀ ਇਨ੍ਹਾਂ ਟੇਲ ਲੇਟੈਂਸੀਆਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ ਹੈ.

Asyncio Python ਨੂੰ I/O-ਅਧਾਰਿਤ ਕੰਮ ਇਕੱਠੇ ਚਲਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਪਰ Python GIL ਦੀ ਸੀਮਾ ਤੋਂ ਪਾਰ ਕੰਮ ਕਰਨ ਅਤੇ CPU ਸਮਾਂਤਰਤਾ ਦੇਣ ਵਿੱਚ ਮਦਦ ਨਹੀਂ ਕਰਦਾ. I/O-ਭਾਰੀ ਬੇਨਤੀ ਪ੍ਰੌਕਸੀਕਰਨ ਤੋਂ ਇਲਾਵਾ Habitat ਕਈ CPU-ਭਾਰੀ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਅਤੇ ਬੈਕਗ੍ਰਾਊਂਡ ਟਾਸਕ ਸੰਭਾਲਦਾ ਹੈ: ਰੂਟਿੰਗ, ਕੰਪ੍ਰੈਸ਼ਨ, ਇਨਕ੍ਰਿਪਸ਼ਨ, ਚੈੱਕਸਮਿੰਗ, ਡਾਊਨਸਟ੍ਰੀਮ ਸਿਹਤ ਜਾਂਚ, ਬੇਨਤੀ ਸ਼ੈਡੋਇੰਗ ਅਤੇ ਹੈਜਿੰਗ.

ਸਾਡੀ ਸੇਵਾ ਵਿੱਚ ਇੰਨੇ CPU-ਭਾਰੀ ਵਰਕਲੋਡ ਅਤੇ ਬੈਕਗ੍ਰਾਊਂਡ ਟਾਸਕਾਂ ਕਾਰਨ asyncio ਸ਼ੈਡਿਊਲਿੰਗ ਦੀ ਦੇਰੀ ਬੇਨਤੀਆਂ ਦੀ ਟੇਲ ਲੇਟੈਂਸੀ ਉੱਤੇ ਆਸਾਨੀ ਨਾਲ ਹਾਵੀ ਹੋ ਸਕਦੀ ਹੈ. ਮੁੱਢਲੀ ਸੇਵਾ ਦੀ ਸ਼ੁਰੂਆਤ ਲਈ ਟਿਊਨਿੰਗ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਸੀਂ p99 ਜਾਂ ਵੱਧ ਲੇਟੈਂਸੀ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਦੇ ਟ੍ਰੇਸਾਂ ਵਿੱਚ ਦੇਖਿਆ ਕਿ ਡਾਊਨਸਟ੍ਰੀਮ ਸਟੋਰੇਜ ਛੇਤੀ ਜਵਾਬ ਦਿੰਦੀ ਸੀ, ਪਰ ਜਵਾਬ ਪਾਰਸ ਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਕੋਰੂਟੀਨ ਦੇ ਮੁੜ ਸ਼ੈਡਿਊਲ ਹੋਣ ਦੀ ਉਡੀਕ ਵਿੱਚ ਬੇਨਤੀਆਂ ਅਕਸਰ ਰੁਕ ਜਾਂਦੀਆਂ ਸਨ.

OpenAI ਦੀਆਂ Python ਸੇਵਾਵਾਂ ਲਈ ਮੈਮੋਰੀ, CPU, ਨੈੱਟਵਰਕ ਅਤੇ ਡਿਸਕ ਵਰਤੋਂ ਦੇ ਮਿਆਰੀ ਉਪਯੋਗ ਤੇ ਸੈਚੁਰੇਸ਼ਨ ਮੈਟ੍ਰਿਕਸ ਦੇ ਨਾਲ asyncio ਲੂਪ ਅਤੇ ਇਹ ਕਿੰਨਾ ਵਿਆਸਤ ਹੈ, ਉਸਦੀ ਨਿਗਰਾਨੀ ਕਰਨੀ ਅਤੇ ਉਸ ਅਨੁਸਾਰ ਟਿਊਨਿੰਗ ਕਰਨੀ ਬਹੁਤ ਜ਼ਰੂਰੀ ਹੈ.

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

ਇਸ ਕਰਕੇ ਅਸੀਂ ਹਰੇਕ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਸਿਰਫ਼ ਕੁਝ ਬੇਨਤੀਆਂ ਸੰਭਾਲਣ ਦਿੰਦੇ ਹਾਂ ਅਤੇ ਇਸਦੀ ਥਾਂ Python ਵਰਕਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਗਿਣਤੀ ਬਹੁਤ ਵਧਾ ਦਿੰਦੇ ਹਾਂ.

ਮੁੱਢਲੀ ਸੇਵਾ ਸ਼ੁਰੂ ਕਰਨ ਵੇਲੇ ਲਾਈਵ ਸੇਵਾ CPU ਪ੍ਰੋਫਾਈਲਿੰਗ ਰਾਹੀਂ ਸਾਨੂੰ asyncio ਦੀ ਵੱਧ ਦੇਰੀ (ਅਤੇ ਇਸ ਤੋਂ ਪੈਦਾ ਹੋਣ ਵਾਲੀਆਂ ਵੱਧ ਟੇਲ ਲੇਟੈਂਸੀਆਂ) ਦਾ ਇੱਕ ਮੁੱਖ ਕਾਰਨ ਮਿਲਿਆ: Statsig (ਇੱਕ ਅਜਿਹਾ ਟੂਲ ਹੈ ਜੋ ਫੀਚਰ ਫਲੈਗ ਸੰਭਾਲਦਾ ਹੈ ਅਤੇ A/B ਟੈਸਟ ਚਲਾਉਣ ਅਤੇ ਹੋਰ ਕੰਮਾਂ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ) ਰਾਹੀਂ ਸਾਡੀਆਂ ਫੀਚਰ ਫਲੈਗ ਕੌਂਫਿਗਰੇਸ਼ਨਾਂ ਦੀ ਨਿਯਮਤ JSON ਪਾਰਸਿੰਗ.

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

CPU ਪ੍ਰੋਫਾਈਲਿੰਗ ਨਾਲ ਮੁੱਖ ਕਾਰਨ ਮਿਲਣ ਤੋਂ ਬਾਅਦ ਹੱਲ ਸਿੱਧਾ ਸੀ: ਛੋਟੀ ਤੇ ਨਿਸ਼ਾਨਾਬੱਧ ਕੌਂਫਿਗ ਡਿਪਲੌਇ ਕਰਨੀ, ਰਿਫਰੈੱਸ਼ ਕਰਨ ਦਾ ਅੰਤਰਾਲ ਵਧਾਉਣਾ ਅਤੇ ਅਜਿਹੇ ਬੈਕਗ੍ਰਾਊਂਡ ਟਾਸਕਾਂ ਵਿੱਚ ਕੁਝ ਜਿਟਰ ਜੋੜਨਾ.

asyncio ਦੀ ਦੇਰੀ ਘੱਟ ਰੱਖਣ ਲਈ ਸਰਵਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿੱਚ ਬੇਨਤੀਆਂ ਦਾ ਚੰਗਾ ਲੋਡ ਸੰਤੁਲਨ ਕਾਇਮ ਰੱਖਣਾ ਵੀ ਜ਼ਰੂਰੀ ਹੈ. ਬਿਨਾਂ ਟਿਊਨਿੰਗ ਦੇ ਕਨੈਕਸ਼ਨ ਪੂਲਿੰਗ ਇਸਦੇ ਉਲਟ ਅਸਰ ਪਾ ਸਕਦੀ ਹੈ.

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

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

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

ਅੱਜ ਅਸੀਂ OpenAI ਦੇ ਪੂਰੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਕਨੈਕਸ਼ਨ ਪੂਲਿੰਗ ਅਤੇ ਸਰਵਰ ਦੇ ਬੋਝ ਤੋਂ ਜਾਣੂ ਬਿਹਤਰ ਸੰਤੁਲਨ ਰਣਨੀਤੀਆਂ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਮੁੱਖ ਤੌਰ ਉੱਤੇ Istio ਅਤੇ Envoy ਉੱਤੇ ਨਿਰਭਰ ਹਾਂ ਅਤੇ ਇਸ ਸਮੱਸਿਆ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਚਦੇ ਹਾਂ.

asyncio ਦੀ ਘੱਟ ਦੇਰੀ ਲਈ ਟਿਊਨਿੰਗ ਕਰਨ ਅਤੇ ਬਹੁਤ ਸਾਰੀਆਂ Python ਪ੍ਰਕਿਰਿਆਵਾਂ ਹੋਣ ਦਾ ਇੱਕ ਮਾੜਾ ਪ੍ਰਭਾਵ ਇਹ ਹੈ ਕਿ ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਵਿਸ਼ਾਲ ਗਿਣਤੀ ਨਾਲ ਡਾਊਨਸਟ੍ਰੀਮ ਨਿਰਭਰਤਾਵਾਂ ਉੱਤੇ ਬੇਹੱਦ ਬੋਝ ਪਾਉਣਾ ਬਹੁਤ ਸੌਖਾ ਹੋ ਜਾਂਦਾ ਹੈ (ਜਿਸਨੂੰ “ਥੰਡਰਿੰਗ ਹਰਡ” ਕਿਹਾ ਜਾਂਦਾ ਹੈ).

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

ਕਨੈਕਸ਼ਨ ਫੈਨ-ਇਨ ਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਕਰਨ ਲਈ ਵੀ ਅਸੀਂ Envoy ਉੱਤੇ ਨਿਰਭਰ ਹਾਂ. ਅਸੀਂ ਇਸ ਨਾਲ Python ਦੇ HTTP/1 ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ HTTP/2 ਵਿੱਚ ਅੱਪਗ੍ਰੇਡ ਕਰਕੇ ਮਲਟੀਪਲੈਕਸਿੰਗ ਦਾ ਲਾਭ ਲੈਂਦੇ ਹਾਂ, ਫਿਰ ਉਨ੍ਹਾਂ ਕਨੈਕਸ਼ਨਾਂ ਦਾ ਪੂਲ ਬਣਾਉਂਦੇ ਅਤੇ ਉਹਨਾਂ ਦੀ ਮਿਆਦ ਵਧਾਉਂਦੇ ਹਾਂ. Envoy ਸਾਨੂੰ ਦਰ ਸੀਮਾਵਾਂ ਅਤੇ ਸਰਕਟ ਬ੍ਰੇਕਰ ਲਾਗੂ ਕਰਨ ਲਈ ਕੇਂਦਰੀ ਥਾਂ ਵੀ ਦਿੰਦਾ ਹੈ, ਜੋ ਹਰੇਕ ਸੁਤੰਤਰ Python ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਘੱਟ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦੇ.

Python ਨੂੰ ਇਸ ਪੱਧਰ ਤੱਕ ਸਕੇਲ ਕਰਨ ਦਾ ਇੱਕ ਕਾਰਨ Habitat ਦਾ ਸੀਮਤ API ਸੀ, ਜੋ ਬੇਨਤੀ ਦੀ ਲਾਗਤ ਨੂੰ ਅਨੁਮਾਨਯੋਗ ਰੱਖਦਾ ਹੈ. ਕਲਾਇੰਟਾਂ ਨੂੰ ਮਨਮਾਨੀਆਂ SQL ਕੁਐਰੀਆਂ ਬਣਾਉਣ ਦੇਣ ਦੀ ਥਾਂ, ਜੋ ਵੱਡੀਆਂ ਟੇਬਲ ਸਕੈਨਾਂ ਜਾਂ ਕਈ ਟੇਬਲਾਂ ਵਿਚਕਾਰ ਜੋਇਨ ਕਰਵਾ ਸਕਦੀਆਂ ਹਨ, Habitat ਇੱਕ ਸਰਲ NoSQL API ਦਿੰਦਾ ਹੈ. ਸ਼ਕਤੀਸ਼ਾਲੀ API ਦੀ ਘਾਟ Habitat ਦੇ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਸਪਸ਼ਟ ਤੌਰ ’ਤੇ ਸਵੀਕਾਰਿਆ ਗਿਆ ਸਮਝੌਤਾ ਹੈ.

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

Habitat ਅਤੇ Azure Cosmos DB ਵੱਲ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ OpenAI ਦਾ ਜ਼ਿਆਦਾਤਰ ਔਨਲਾਈਨ ਡਾਟਾ Postgres ਉੱਤੇ ਸਟੋਰ ਹੁੰਦਾ ਸੀ. ਉਸ ਵੇਲੇ ਸਾਰੀਆਂ ਕੁਐਰੀਆਂ ਅਤੇ ਸਕੀਮਾ ਤਬਦੀਲੀਆਂ ਦੀ ਸਮੀਖਿਆ ਕਰਕੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਸੌਖਾ ਸੀ ਕਿ ਉਹ ਉਚਿਤ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦੀਆਂ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਡਿਪਲੌਇ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੰਡੈਕਸ ਕੀਤੇ ਡਾਟੇ ਉੱਤੇ ਚੱਲਦੀਆਂ ਸਨ. ਟੀਮ ਅਤੇ ਪ੍ਰੋਡਕਟ ਵਧਣ ਨਾਲ ਇਹ ਛੇਤੀ ਹੀ ਸੰਭਾਲ ਤੋਂ ਬਾਹਰ ਹੋ ਗਿਆ ਅਤੇ ਸੇਵਾ ਵਿੱਚ ਵਿਘਨ ਪੈਣ ਦਾ ਇੱਕ ਆਮ ਕਾਰਨ ਬਣ ਗਿਆ, ਜਿੱਥੇ ਹੌਟ ਪਾਥ ਉੱਤੇ ਇੱਕ ਨਵੀਂ ਮਹਿੰਗੀ ਕੁਐਰੀ ਡਾਟਾਬੇਸ ਨੂੰ ਹੀ ਠੱਪ ਕਰ ਦਿੰਦੀ ਸੀ.

ਇੱਥੇ ਸਮੱਸਿਆ ਲਾਗਤ ਦੇ ਅਸੰਤੁਲਨ ਦੀ ਹੈ: ਅਜਿਹੀਆਂ SQL ਕੁਐਰੀਆਂ ਲਿਖਣੀਆਂ ਸਸਤੀਆਂ ਤੇ ਸੌਖੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਚਲਾਉਣਾ ਮਹਿੰਗਾ ਤੇ ਔਖਾ ਹੈ. Habitat ਵਿੱਚ ਅਸੀਂ ਇਸ ਤੋਂ ਬਚਦੇ ਹਾਂ ਅਤੇ ਮਹਿੰਗੀਆਂ ਕੁਐਰੀਆਂ ਨੂੰ ਕਲਾਇੰਟ ਪਾਸੇ ਹੀ ਬਹੁਤ ਸਪੱਸ਼ਟ ਤੌਰ ’ਤੇ ਪਛਾਣਯੋਗ ਬਣਾ ਦਿੰਦੇ ਹਾਂ. Habitat ਉੱਤੇ ਬੋਝ ਪਾ ਸਕਣ ਵਾਲੀਆਂ ਕੋਈ ਅਨਬਾਊਂਡਡ ਕੁਐਰੀਆਂ ਨਹੀਂ ਹਨ, ਅਤੇ ਪੇਚੀਦਾ ਜੋਇਨਾਂ ਅਤੇ ਗ੍ਰਾਫ ਟ੍ਰੈਵਰਸਲ ਲਈ ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ ਨੂੰ ਕੁਝ ਭਾਰੀ ਕੰਮ ਆਪ ਸੰਭਾਲਣਾ ਪੈਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸਮੁੱਚੇ ਤੌਰ ’ਤੇ ਵਧੇਰੇ ਕੁਸ਼ਲ ਡਿਜ਼ਾਈਨਾਂ ਨੂੰ ਤਰਜੀਹ ਦੇਣ ਵਿੱਚ ਮਦਦ ਮਿਲਦੀ ਹੈ.

Habitat ਕਲਾਇੰਟ ਵੱਲੋਂ ਪਰਿਭਾਸ਼ਿਤ ਔਬਜੈਕਟ ਅਤੇ ਐਜ ਕਿਸਮਾਂ ਉੱਤੇ ਆਧਾਰਿਤ NoSQL API ਦਿੰਦਾ ਹੈ, ਜੋ TAO⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਤੋਂ ਪ੍ਰੇਰਿਤ ਹੈ. ਕਲਾਇੰਟ ਔਬਜੈਕਟਾਂ, ਐਜਾਂ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਆਪਸੀ ਸੰਬੰਧਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ, ਪਰ ਹਰੇਕ ਕਿਸਮ ਦੀ ਸਮੱਗਰੀ ਨੂੰ ਨਹੀਂ. ਇਸ ਤਰ੍ਹਾਂ ਬਣੇ ਸੰਬੰਧ ਗ੍ਰਾਫ ਵਰਗੇ ਦਿਸਦੇ ਹਨ, ਪਰ ਕਿਸੇ ਖ਼ਾਸ ਔਬਜੈਕਟ ਦੇ ਸਿੱਧੇ ਐਜਾਂ ਬਾਰੇ ਕੁਐਰੀ ਕਰਨ ਤੋਂ ਇਲਾਵਾ Habitat ਆਮ ਗ੍ਰਾਫ ਟ੍ਰੈਵਰਸਲ ਕੁਐਰੀਆਂ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ.

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

ਵਧੇਰੇ ਪੇਚੀਦਾ ਕੁਐਰੀ ਲੋੜਾਂ ਵਾਲੇ ਕਲਾਇੰਟਾਂ ਲਈ ਅਸੀਂ Rockset ਰਾਹੀਂ Habitat ਦਾ ਔਫਲਾਈਨ ਸੈਕੰਡਰੀ ਵਿਊ ਵੀ ਦਿੰਦੇ ਹਾਂ. ਅਸੀਂ ਚੇਂਜ ਡਾਟਾ ਕੈਪਚਰ (CDC) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਔਨਲਾਈਨ ਸਟੋਰੇਜ ਤੋਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਲਗਭਗ ਰੀਅਲ ਟਾਈਮ ਵਿੱਚ ਅਲੱਗ-ਥਲੱਗ Rockset ਇੰਸਟੈਂਸਾਂ ਤੱਕ ਸਟ੍ਰੀਮ ਕਰਦੇ ਹਾਂ. ਹਰੇਕ ਕਲਾਇੰਟ ਟੀਮ ਆਪਣੀਆਂ ਪੇਚੀਦਾ ਕੁਐਰੀ ਲੋੜਾਂ ਲਈ ਆਪਣੇ Rockset ਇੰਸਟੈਂਸ ਨੂੰ ਸਕੇਲ ਕਰਨ ਦੀ ਜ਼ਿੰਮੇਵਾਰ ਹੈ.

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

Python ਨੂੰ ਮੁੜ ਲਿਖਣ ਦਾ ਕੰਮ ਇੱਕ ਸਾਲ ਟਾਲਣ ਨਾਲ ਅਸੀਂ ਬੇਹੱਦ ਤੇਜ਼ ਵਾਧੇ ਦੌਰਾਨ ਵਧੇਰੇ ਜ਼ਰੂਰੀ ਅਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਚੁਣੌਤੀਆਂ ਉੱਤੇ ਧਿਆਨ ਦੇ ਸਕੇ. ਪਲੇਟਫਾਰਮ ਦੇ ਪਰਿਪੱਕ ਹੋਣ, ਵਾਧੇ ਦੇ ਲਗਾਤਾਰ ਤੇਜ਼ ਹੋਣ ਅਤੇ OpenAI ਵਿੱਚ ਕੋਰ ਗਿਣਤੀ ਮੁਤਾਬਕ ਦੂਜੀ ਸਭ ਤੋਂ ਵੱਡੀ ਸੇਵਾ (ਅਤੇ Envoy ਫੁੱਟਪ੍ਰਿੰਟ ਦੇ ਹਿਸਾਬ ਨਾਲ ਚੌਥੀ) ਹੋਣ ਕਰਕੇ, ਆਖ਼ਰਕਾਰ Python ਤੋਂ ਅੱਗੇ ਵਧਣ ਦਾ ਸਮਾਂ ਆ ਗਿਆ ਸੀ. ਆਪਣੇ ਸਿਖਰ ਉੱਤੇ Python ਨੇ ਸਾਨੂੰ ਹਰ ਸਕਿੰਟ 2 ਕਰੋੜ ਤੋਂ ਵੱਧ ਬੇਨਤੀਆਂ ਸੰਭਾਲਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ.

2026 ਦੀ ਦੂਜੀ ਤਿਮਾਹੀ ਵਿੱਚ ਸਿਰਫ਼ 2 ਇੰਜੀਨੀਅਰਾਂ, Codex ਅਤੇ GPT‑5.5 ਨਾਲ ਅਸੀਂ ਪੂਰੀ ਸੇਵਾ Rust ਵਿੱਚ ਮੁੜ ਲਿਖ ਸਕੇ. ਇਹ ਨਵੀਂ Rust ਸੇਵਾ ਹੁਣ ਸਾਡੀਆਂ 95% ਪ੍ਰੋਡਕਸ਼ਨ ਬੇਨਤੀਆਂ ਸੰਭਾਲ ਰਹੀ ਹੈ; ਆਉਣ ਵਾਲੇ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਅਸੀਂ Python ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵਰਤੋਂ ਤੋਂ ਹਟਾ ਦੇਵਾਂਗੇ. ਸਾਡਾ ਡਾਟਾ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ Rust ਸੇਵਾ Python ਵਰਜ਼ਨ ਨਾਲੋਂ CPU ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਛੇ ਗੁਣਾ ਅਤੇ ਮੈਮੋਰੀ ਦੇ ਮਾਮਲੇ ਵਿੱਚ 15 ਗੁਣਾ ਵੱਧ ਕੁਸ਼ਲ ਹੈ, ਅਤੇ ਇਸਦੀ ਔਸਤ ਅਤੇ ਟੇਲ ਲੇਟੈਂਸੀ ਵੀ ਕਾਫ਼ੀ ਘੱਟ ਹੈ. ਅਸੀਂ ਭਵਿੱਖ ਦੀ ਇੱਕ ਬਲੌਗ ਪੋਸਟ ਵਿੱਚ ਹੋਰ ਸਿੱਖਿਆਵਾਂ ਸਾਂਝੀਆਂ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਈ ਹੈ.

Python ਅਤੇ ਹੁਣ Rust ਸੇਵਾ Habitat ਦਾ ਸਿਰਫ਼ ਇੱਕ ਪੱਖ ਹੈ. 1 ਅਰਬ ਤੋਂ ਵੱਧ ChatGPT ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਔਨਲਾਈਨ ਸਟੋਰੇਜ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਕੇਲ ਕਰਨ ਬਾਰੇ ਇਸ ਲੜੀ ਦੇ ਭਾਗ II ਵਿੱਚ ਅਸੀਂ ਸਟੋਰੇਜ ਲੇਅਰ ਅਤੇ Habitat ਵੱਲੋਂ 500 ਪੈਟਾਬਾਈਟ ਤੋਂ ਵੱਧ ਡਾਟਾ ਤੇ ਹਰ ਸਕਿੰਟ 7 ਕਰੋੜ ਤੋਂ ਵੱਧ ਬੇਨਤੀਆਂ ਸੰਭਾਲਣ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ.

ਜੇ ਤੁਸੀਂ ਅਤਿ-ਆਧੁਨਿਕ ਪੈਮਾਨੇ ਦੇ OLTP ਸਿਸਟਮਾਂ ਉੱਤੇ ਕੰਮ ਕਰਨਾ ਅਤੇ ਇਸ ਕਿਸਮ ਦੀ ਇੰਜੀਨੀਅਰਿੰਗ ਕਰਨੀ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਸਾਡੀ ਟੀਮ ਵਿੱਚ ਇਸ ਖੁੱਲ੍ਹੀ ਭੂਮਿਕਾ ਨੂੰ ਦੇਖੋ⁠.