ਸਰਵਰ ਰਹਿਤ ਡੇਟਾਬੇਸ ਦੇ ਰਾਹ ਤੇ - ਕਿਵੇਂ ਅਤੇ ਕਿਉਂ

ਸਾਰਿਆਂ ਨੂੰ ਸਤਿ ਸ਼੍ਰੀ ਅਕਾਲ! ਮੇਰਾ ਨਾਮ ਗੋਲੋਵ ਨਿਕੋਲੇ ਹੈ। ਪਹਿਲਾਂ, ਮੈਂ ਅਵੀਟੋ ਵਿਖੇ ਕੰਮ ਕੀਤਾ ਅਤੇ ਛੇ ਸਾਲਾਂ ਲਈ ਡੇਟਾ ਪਲੇਟਫਾਰਮ ਦਾ ਪ੍ਰਬੰਧਨ ਕੀਤਾ, ਯਾਨੀ ਮੈਂ ਸਾਰੇ ਡੇਟਾਬੇਸ 'ਤੇ ਕੰਮ ਕੀਤਾ: ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ (ਵਰਟੀਕਾ, ਕਲਿਕਹਾਊਸ), ਸਟ੍ਰੀਮਿੰਗ ਅਤੇ ਓਐਲਟੀਪੀ (ਰੇਡਿਸ, ਟਾਰਨਟੂਲ, ਵੋਲਟਡੀਬੀ, ਮੋਂਗੋਡੀਬੀ, ਪੋਸਟਗ੍ਰੇਸਕਿਯੂਐਲ)। ਇਸ ਸਮੇਂ ਦੌਰਾਨ, ਮੈਂ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਡੇਟਾਬੇਸ ਨਾਲ ਨਜਿੱਠਿਆ - ਬਹੁਤ ਵੱਖਰੇ ਅਤੇ ਅਸਾਧਾਰਨ, ਅਤੇ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਦੇ ਗੈਰ-ਮਿਆਰੀ ਕੇਸਾਂ ਨਾਲ.

ਮੈਂ ਇਸ ਸਮੇਂ ManyChat 'ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ/ਰਹੀ ਹਾਂ। ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ, ਇਹ ਇੱਕ ਸ਼ੁਰੂਆਤ ਹੈ - ਨਵਾਂ, ਅਭਿਲਾਸ਼ੀ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਰਿਹਾ ਹੈ। ਅਤੇ ਜਦੋਂ ਮੈਂ ਪਹਿਲੀ ਵਾਰ ਕੰਪਨੀ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਇਆ, ਇੱਕ ਸ਼ਾਨਦਾਰ ਸਵਾਲ ਉੱਠਿਆ: "ਇੱਕ ਨੌਜਵਾਨ ਸ਼ੁਰੂਆਤ ਨੂੰ ਹੁਣ DBMS ਅਤੇ ਡੇਟਾਬੇਸ ਮਾਰਕੀਟ ਤੋਂ ਕੀ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ?"

ਇਸ ਲੇਖ ਵਿਚ, 'ਤੇ ਮੇਰੀ ਰਿਪੋਰਟ ਦੇ ਆਧਾਰ 'ਤੇ ਔਨਲਾਈਨ ਤਿਉਹਾਰ RIT++ 2020, ਮੈਂ ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਵਾਂਗਾ। ਰਿਪੋਰਟ ਦਾ ਵੀਡੀਓ ਸੰਸਕਰਣ 'ਤੇ ਉਪਲਬਧ ਹੈ YouTube '.

ਆਮ ਤੌਰ 'ਤੇ ਜਾਣੇ ਜਾਂਦੇ ਡਾਟਾਬੇਸ 2020

ਇਹ 2020 ਹੈ, ਮੈਂ ਆਲੇ ਦੁਆਲੇ ਦੇਖਿਆ ਅਤੇ ਤਿੰਨ ਕਿਸਮਾਂ ਦੇ ਡੇਟਾਬੇਸ ਦੇਖੇ।

ਪਹਿਲੀ ਕਿਸਮ - ਕਲਾਸਿਕ OLTP ਡੇਟਾਬੇਸ: PostgreSQL, SQL ਸਰਵਰ, Oracle, MySQL। ਉਹ ਬਹੁਤ ਸਮਾਂ ਪਹਿਲਾਂ ਲਿਖੇ ਗਏ ਸਨ, ਪਰ ਅਜੇ ਵੀ ਢੁਕਵੇਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਵਿਕਾਸਕਾਰ ਭਾਈਚਾਰੇ ਲਈ ਬਹੁਤ ਜਾਣੂ ਹਨ।

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

"ਜ਼ੀਰੋ" ਖਤਮ ਹੋ ਗਏ ਹਨ, ਸਾਨੂੰ NOSQL ਡੇਟਾਬੇਸ ਦੀ ਆਦਤ ਪੈ ਗਈ ਹੈ, ਅਤੇ ਸੰਸਾਰ ਨੇ, ਮੇਰੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਅਗਲਾ ਕਦਮ ਚੁੱਕਿਆ - ਨੂੰ ਪਰਬੰਧਿਤ ਡਾਟਾਬੇਸ. ਇਹਨਾਂ ਡੇਟਾਬੇਸ ਵਿੱਚ ਕਲਾਸਿਕ OLTP ਡੇਟਾਬੇਸ ਜਾਂ ਨਵੇਂ NoSQL ਡੇਟਾਬੇਸ ਵਰਗਾ ਹੀ ਕੋਰ ਹੁੰਦਾ ਹੈ। ਪਰ ਉਹਨਾਂ ਨੂੰ DBA ਅਤੇ DevOps ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ ਅਤੇ ਬੱਦਲਾਂ ਵਿੱਚ ਪ੍ਰਬੰਧਿਤ ਹਾਰਡਵੇਅਰ 'ਤੇ ਚੱਲਦੇ ਹਨ। ਇੱਕ ਡਿਵੈਲਪਰ ਲਈ, ਇਹ "ਸਿਰਫ਼ ਇੱਕ ਅਧਾਰ" ਹੈ ਜੋ ਕਿ ਕਿਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਕੋਈ ਵੀ ਇਸ ਗੱਲ ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਸਰਵਰ 'ਤੇ ਕਿਵੇਂ ਸਥਾਪਤ ਹੈ, ਸਰਵਰ ਨੂੰ ਕਿਸ ਨੇ ਕੌਂਫਿਗਰ ਕੀਤਾ ਹੈ ਅਤੇ ਕੌਣ ਇਸਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ।

ਅਜਿਹੇ ਡੇਟਾਬੇਸ ਦੀਆਂ ਉਦਾਹਰਨਾਂ:

• AWS RDS PostgreSQL/MySQL ਲਈ ਇੱਕ ਪ੍ਰਬੰਧਿਤ ਰੈਪਰ ਹੈ।
• DynamoDB ਇੱਕ ਦਸਤਾਵੇਜ਼ ਅਧਾਰਤ ਡੇਟਾਬੇਸ ਦਾ ਇੱਕ AWS ਐਨਾਲਾਗ ਹੈ, Redis ਅਤੇ MongoDB ਦੇ ਸਮਾਨ।
• Amazon Redshift ਇੱਕ ਪ੍ਰਬੰਧਿਤ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਡੇਟਾਬੇਸ ਹੈ।

ਇਹ ਮੂਲ ਰੂਪ ਵਿੱਚ ਪੁਰਾਣੇ ਡੇਟਾਬੇਸ ਹਨ, ਪਰ ਇੱਕ ਪ੍ਰਬੰਧਿਤ ਵਾਤਾਵਰਣ ਵਿੱਚ, ਹਾਰਡਵੇਅਰ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਲੋੜ ਤੋਂ ਬਿਨਾਂ ਉਭਾਰਿਆ ਗਿਆ ਹੈ।

ਨੋਟ ਕਰੋ। ਉਦਾਹਰਨਾਂ AWS ਵਾਤਾਵਰਣ ਲਈ ਲਈਆਂ ਗਈਆਂ ਹਨ, ਪਰ ਉਹਨਾਂ ਦੇ ਐਨਾਲਾਗ Microsoft Azure, Google Cloud, ਜਾਂ Yandex.Cloud ਵਿੱਚ ਵੀ ਮੌਜੂਦ ਹਨ।

ਇਸ ਬਾਰੇ ਨਵਾਂ ਕੀ ਹੈ? 2020 ਵਿੱਚ, ਇਸ ਵਿੱਚੋਂ ਕੋਈ ਨਹੀਂ।

ਸਰਵਰ ਰਹਿਤ ਸੰਕਲਪ

2020 ਵਿੱਚ ਮਾਰਕੀਟ ਵਿੱਚ ਅਸਲ ਵਿੱਚ ਨਵਾਂ ਕੀ ਹੈ ਸਰਵਰ ਰਹਿਤ ਜਾਂ ਸਰਵਰ ਰਹਿਤ ਹੱਲ ਹੈ।

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

ਕੀ ਕੋਈ ਹੋਰ ਤਰੀਕਾ ਹੈ? ਸਰਵਰ ਰਹਿਤ ਸੇਵਾਵਾਂ ਨਾਲ ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ।

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

ਮੈਂ ਤਸਵੀਰਾਂ ਨਾਲ ਇਸ ਪਹੁੰਚ ਨੂੰ ਦਰਸਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗਾ.


ਕਲਾਸਿਕ ਤੈਨਾਤੀ. ਸਾਡੇ ਕੋਲ ਇੱਕ ਖਾਸ ਲੋਡ ਵਾਲੀ ਸੇਵਾ ਹੈ। ਅਸੀਂ ਦੋ ਉਦਾਹਰਣਾਂ ਨੂੰ ਵਧਾਉਂਦੇ ਹਾਂ: ਭੌਤਿਕ ਸਰਵਰ ਜਾਂ AWS ਵਿੱਚ ਉਦਾਹਰਨਾਂ। ਬਾਹਰੀ ਬੇਨਤੀਆਂ ਇਹਨਾਂ ਮੌਕਿਆਂ 'ਤੇ ਭੇਜੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਉੱਥੇ ਕਾਰਵਾਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

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

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

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

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

ਇਹਨਾਂ ਸਾਰੇ ਡੇਟਾਬੇਸ ਦੀ ਸਾਂਝੀ ਸੀਮਾ ਕੀ ਹੈ? ਇਹ ਲਗਾਤਾਰ ਵਰਤੇ ਜਾਂਦੇ ਕਲਾਉਡ ਜਾਂ ਹਾਰਡਵੇਅਰ ਸਰਵਰ (ਜਾਂ ਕਈ ਸਰਵਰਾਂ) ਦੇ ਖਰਚੇ ਹਨ। ਇਸ ਨਾਲ ਕੋਈ ਫ਼ਰਕ ਨਹੀਂ ਪੈਂਦਾ ਕਿ ਅਸੀਂ ਇੱਕ ਕਲਾਸਿਕ ਜਾਂ ਪ੍ਰਬੰਧਿਤ ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਭਾਵੇਂ ਸਾਡੇ ਕੋਲ Devops ਅਤੇ ਇੱਕ ਪ੍ਰਸ਼ਾਸਕ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਸੀਂ ਅਜੇ ਵੀ ਹਾਰਡਵੇਅਰ, ਬਿਜਲੀ ਅਤੇ ਡਾਟਾ ਸੈਂਟਰ ਦੇ ਕਿਰਾਏ ਲਈ 24/7 ਭੁਗਤਾਨ ਕਰਦੇ ਹਾਂ। ਜੇ ਸਾਡੇ ਕੋਲ ਕਲਾਸਿਕ ਅਧਾਰ ਹੈ, ਤਾਂ ਅਸੀਂ ਮਾਲਕ ਅਤੇ ਨੌਕਰ ਲਈ ਭੁਗਤਾਨ ਕਰਦੇ ਹਾਂ. ਜੇਕਰ ਇਹ ਇੱਕ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੋਡ ਕੀਤਾ ਹੋਇਆ ਸ਼ਾਰਡ ਡੇਟਾਬੇਸ ਹੈ, ਤਾਂ ਅਸੀਂ 10, 20 ਜਾਂ 30 ਸਰਵਰਾਂ ਲਈ ਭੁਗਤਾਨ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਅਸੀਂ ਲਗਾਤਾਰ ਭੁਗਤਾਨ ਕਰਦੇ ਹਾਂ।

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

ਸਰਵਰ ਰਹਿਤ ਡਾਟਾਬੇਸ - ਥਿਊਰੀ

2020 ਦਾ ਸਵਾਲ: ਕੀ ਡੇਟਾਬੇਸ ਨੂੰ ਸਰਵਰ ਰਹਿਤ ਵੀ ਬਣਾਉਣਾ ਸੰਭਵ ਹੈ? ਹਰ ਕਿਸੇ ਨੇ ਸਰਵਰ ਰਹਿਤ ਬੈਕਐਂਡ ਬਾਰੇ ਸੁਣਿਆ ਹੈ... ਆਓ ਡੇਟਾਬੇਸ ਨੂੰ ਸਰਵਰ ਰਹਿਤ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ?

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

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

ਇਸ ਅਨੁਸਾਰ, ਵਿਚਾਰ ਇਹ ਹੈ: ਜੇਕਰ ਤਰਕ ਦਾ ਹਿੱਸਾ ਸਟੇਟਲੈਸ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਕਿਉਂ ਨਾ ਬੇਸ ਨੂੰ ਸਟੇਟਫੁੱਲ ਅਤੇ ਸਟੇਟਲੈੱਸ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਵੇ।

OLAP ਹੱਲਾਂ ਲਈ ਸਰਵਰ ਰਹਿਤ

ਆਉ ਵੇਖੀਏ ਕਿ ਇੱਕ ਡੇਟਾਬੇਸ ਨੂੰ ਸਟੇਟਫੁੱਲ ਅਤੇ ਸਟੇਟਲੈੱਸ ਭਾਗਾਂ ਵਿੱਚ ਕੱਟਣਾ ਵਿਹਾਰਕ ਉਦਾਹਰਣਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਿਹੋ ਜਿਹਾ ਲੱਗ ਸਕਦਾ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਡੇਟਾਬੇਸ ਹੈ: ਬਾਹਰੀ ਡੇਟਾ (ਖੱਬੇ ਪਾਸੇ ਲਾਲ ਸਿਲੰਡਰ), ਇੱਕ ETL ਪ੍ਰਕਿਰਿਆ ਜੋ ਡੇਟਾਬੇਸ ਵਿੱਚ ਡੇਟਾ ਲੋਡ ਕਰਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਵਿਸ਼ਲੇਸ਼ਕ ਜੋ ਡੇਟਾਬੇਸ ਨੂੰ SQL ਸਵਾਲ ਭੇਜਦਾ ਹੈ। ਇਹ ਇੱਕ ਕਲਾਸਿਕ ਡਾਟਾ ਵੇਅਰਹਾਊਸ ਓਪਰੇਸ਼ਨ ਸਕੀਮ ਹੈ।

ਇਸ ਸਕੀਮ ਵਿੱਚ, ETL ਸ਼ਰਤ ਅਨੁਸਾਰ ਇੱਕ ਵਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਫਿਰ ਤੁਹਾਨੂੰ ਲਗਾਤਾਰ ਉਹਨਾਂ ਸਰਵਰਾਂ ਲਈ ਭੁਗਤਾਨ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ ਜਿਸ 'ਤੇ ਡੇਟਾਬੇਸ ETL ਨਾਲ ਭਰੇ ਹੋਏ ਡੇਟਾ ਨਾਲ ਚੱਲਦਾ ਹੈ, ਤਾਂ ਜੋ ਸਵਾਲਾਂ ਨੂੰ ਭੇਜਣ ਲਈ ਕੁਝ ਹੋਵੇ.

ਆਉ AWS Athena Serverless ਵਿੱਚ ਲਾਗੂ ਕੀਤੇ ਗਏ ਇੱਕ ਵਿਕਲਪਿਕ ਪਹੁੰਚ ਨੂੰ ਵੇਖੀਏ। ਇੱਥੇ ਕੋਈ ਸਥਾਈ ਤੌਰ 'ਤੇ ਸਮਰਪਿਤ ਹਾਰਡਵੇਅਰ ਨਹੀਂ ਹੈ ਜਿਸ 'ਤੇ ਡਾਊਨਲੋਡ ਕੀਤਾ ਡਾਟਾ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਦੀ ਬਜਾਏ:

• ਉਪਭੋਗਤਾ ਐਥੀਨਾ ਨੂੰ ਇੱਕ SQL ਪੁੱਛਗਿੱਛ ਦਰਜ ਕਰਦਾ ਹੈ। ਐਥੀਨਾ ਆਪਟੀਮਾਈਜ਼ਰ SQL ਪੁੱਛਗਿੱਛ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦਾ ਹੈ ਅਤੇ ਪੁੱਛਗਿੱਛ ਨੂੰ ਚਲਾਉਣ ਲਈ ਲੋੜੀਂਦੇ ਖਾਸ ਡੇਟਾ ਲਈ ਮੈਟਾਡੇਟਾ ਸਟੋਰ (ਮੈਟਾਡੇਟਾ) ਦੀ ਖੋਜ ਕਰਦਾ ਹੈ।
• ਆਪਟੀਮਾਈਜ਼ਰ, ਇਕੱਤਰ ਕੀਤੇ ਡੇਟਾ ਦੇ ਅਧਾਰ ਤੇ, ਬਾਹਰੀ ਸਰੋਤਾਂ ਤੋਂ ਜ਼ਰੂਰੀ ਡੇਟਾ ਨੂੰ ਅਸਥਾਈ ਸਟੋਰੇਜ (ਆਰਜ਼ੀ ਡੇਟਾਬੇਸ) ਵਿੱਚ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ।
• ਉਪਭੋਗਤਾ ਤੋਂ ਇੱਕ SQL ਪੁੱਛਗਿੱਛ ਅਸਥਾਈ ਸਟੋਰੇਜ ਵਿੱਚ ਚਲਾਈ ਜਾਂਦੀ ਹੈ ਅਤੇ ਨਤੀਜਾ ਉਪਭੋਗਤਾ ਨੂੰ ਵਾਪਸ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
• ਅਸਥਾਈ ਸਟੋਰੇਜ ਸਾਫ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਸਰੋਤ ਜਾਰੀ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

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

ਇਹ ਇੱਕ ਕਾਰਜਸ਼ੀਲ ਪਹੁੰਚ ਹੈ ਅਤੇ ਨਾ ਸਿਰਫ਼ ਐਥੀਨਾ ਸਰਵਰਲੇਸ ਵਿੱਚ, ਸਗੋਂ ਰੈੱਡਸ਼ਿਫਟ ਸਪੈਕਟ੍ਰਮ (AWS ਵਿੱਚ) ਵਿੱਚ ਵੀ ਲਾਗੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਐਥੀਨਾ ਉਦਾਹਰਨ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਸਰਵਰ ਰਹਿਤ ਡੇਟਾਬੇਸ ਦਸਾਂ ਅਤੇ ਸੈਂਕੜੇ ਟੈਰਾਬਾਈਟ ਡੇਟਾ ਦੇ ਨਾਲ ਅਸਲ ਪੁੱਛਗਿੱਛਾਂ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ। ਸੈਂਕੜੇ ਟੈਰਾਬਾਈਟ ਲਈ ਸੈਂਕੜੇ ਸਰਵਰਾਂ ਦੀ ਲੋੜ ਹੋਵੇਗੀ, ਪਰ ਸਾਨੂੰ ਉਹਨਾਂ ਲਈ ਭੁਗਤਾਨ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ - ਅਸੀਂ ਬੇਨਤੀਆਂ ਲਈ ਭੁਗਤਾਨ ਕਰਦੇ ਹਾਂ। ਵਰਟੀਕਾ ਵਰਗੇ ਵਿਸ਼ੇਸ਼ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਡੇਟਾਬੇਸ ਦੇ ਮੁਕਾਬਲੇ ਹਰੇਕ ਬੇਨਤੀ ਦੀ ਗਤੀ (ਬਹੁਤ) ਘੱਟ ਹੈ, ਪਰ ਅਸੀਂ ਡਾਊਨਟਾਈਮ ਪੀਰੀਅਡਾਂ ਲਈ ਭੁਗਤਾਨ ਨਹੀਂ ਕਰਦੇ ਹਾਂ।

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

OLTP ਹੱਲਾਂ ਲਈ ਸਰਵਰ ਰਹਿਤ

ਪਿਛਲੀ ਉਦਾਹਰਨ OLAP (ਵਿਸ਼ਲੇਸ਼ਣ ਸੰਬੰਧੀ) ਕਾਰਜਾਂ ਨੂੰ ਵੇਖਦੀ ਹੈ। ਆਉ ਹੁਣ OLTP ਕਾਰਜਾਂ ਨੂੰ ਵੇਖੀਏ।

ਚਲੋ ਸਕੇਲੇਬਲ PostgreSQL ਜਾਂ MySQL ਦੀ ਕਲਪਨਾ ਕਰੀਏ। ਆਉ ਘੱਟੋ-ਘੱਟ ਸਰੋਤਾਂ ਦੇ ਨਾਲ ਇੱਕ ਨਿਯਮਤ ਪ੍ਰਬੰਧਿਤ ਉਦਾਹਰਨ PostgreSQL ਜਾਂ MySQL ਨੂੰ ਉਭਾਰੀਏ। ਜਦੋਂ ਉਦਾਹਰਣ ਨੂੰ ਵਧੇਰੇ ਲੋਡ ਮਿਲਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਵਾਧੂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਨੂੰ ਜੋੜਾਂਗੇ ਜਿਸ ਨਾਲ ਅਸੀਂ ਰੀਡਿੰਗ ਲੋਡ ਦਾ ਹਿੱਸਾ ਵੰਡਾਂਗੇ। ਜੇਕਰ ਕੋਈ ਬੇਨਤੀਆਂ ਜਾਂ ਲੋਡ ਨਹੀਂ ਹਨ, ਤਾਂ ਅਸੀਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਨੂੰ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਾਂ। ਪਹਿਲੀ ਉਦਾਹਰਣ ਮਾਸਟਰ ਹੈ, ਅਤੇ ਬਾਕੀ ਪ੍ਰਤੀਰੂਪ ਹਨ.

ਇਹ ਵਿਚਾਰ Aurora Serverless AWS ਨਾਮਕ ਇੱਕ ਡੇਟਾਬੇਸ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ। ਸਿਧਾਂਤ ਸਧਾਰਨ ਹੈ: ਬਾਹਰੀ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀਆਂ ਬੇਨਤੀਆਂ ਪ੍ਰੌਕਸੀ ਫਲੀਟ ਦੁਆਰਾ ਸਵੀਕਾਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਲੋਡ ਵਧਣ ਨੂੰ ਦੇਖਦੇ ਹੋਏ, ਇਹ ਪੂਰਵ-ਗਰਮ ਘੱਟੋ-ਘੱਟ ਉਦਾਹਰਣਾਂ ਤੋਂ ਕੰਪਿਊਟਿੰਗ ਸਰੋਤ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ - ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ ਕਨੈਕਸ਼ਨ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ. ਅਸਮਰੱਥ ਉਦਾਹਰਨਾਂ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਵਾਪਰਦੀਆਂ ਹਨ।

Aurora ਦੇ ਅੰਦਰ Aurora Capacity Unit, ACU ਦਾ ਸੰਕਲਪ ਹੈ। ਇਹ (ਸ਼ਰਤ) ਇੱਕ ਉਦਾਹਰਣ (ਸਰਵਰ) ਹੈ। ਹਰੇਕ ਖਾਸ ACU ਇੱਕ ਮਾਲਕ ਜਾਂ ਗੁਲਾਮ ਹੋ ਸਕਦਾ ਹੈ। ਹਰੇਕ ਸਮਰੱਥਾ ਯੂਨਿਟ ਦੀ ਆਪਣੀ ਰੈਮ, ਪ੍ਰੋਸੈਸਰ ਅਤੇ ਨਿਊਨਤਮ ਡਿਸਕ ਹੁੰਦੀ ਹੈ। ਇਸ ਅਨੁਸਾਰ, ਇੱਕ ਮਾਸਟਰ ਹੈ, ਬਾਕੀ ਸਿਰਫ ਰੀਡਿਊਲ ਰੀਪਲੇਸ ਹਨ.

ਚੱਲ ਰਹੀਆਂ ਇਹਨਾਂ ਔਰੋਰਾ ਸਮਰੱਥਾ ਯੂਨਿਟਾਂ ਦੀ ਗਿਣਤੀ ਇੱਕ ਸੰਰਚਨਾਯੋਗ ਪੈਰਾਮੀਟਰ ਹੈ। ਘੱਟੋ-ਘੱਟ ਮਾਤਰਾ ਇੱਕ ਜਾਂ ਜ਼ੀਰੋ ਹੋ ਸਕਦੀ ਹੈ (ਇਸ ਕੇਸ ਵਿੱਚ, ਡੇਟਾਬੇਸ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਜੇਕਰ ਕੋਈ ਬੇਨਤੀਆਂ ਨਹੀਂ ਹਨ)।

ਜਦੋਂ ਅਧਾਰ ਨੂੰ ਬੇਨਤੀਆਂ ਪ੍ਰਾਪਤ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਪ੍ਰੌਕਸੀ ਫਲੀਟ ਸਿਸਟਮ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਸਰੋਤਾਂ ਨੂੰ ਵਧਾਉਂਦੇ ਹੋਏ, Aurora CapacityUnits ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ। ਸਰੋਤਾਂ ਨੂੰ ਵਧਾਉਣ ਅਤੇ ਘਟਾਉਣ ਦੀ ਯੋਗਤਾ ਸਿਸਟਮ ਨੂੰ ਸਰੋਤਾਂ ਨੂੰ "ਜੁਗਲ" ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ: ਵਿਅਕਤੀਗਤ ACUs ਨੂੰ ਆਪਣੇ ਆਪ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ (ਉਨ੍ਹਾਂ ਨੂੰ ਨਵੇਂ ਨਾਲ ਬਦਲਣਾ) ਅਤੇ ਵਾਪਸ ਲਏ ਗਏ ਸਰੋਤਾਂ ਲਈ ਸਾਰੇ ਮੌਜੂਦਾ ਅਪਡੇਟਾਂ ਨੂੰ ਰੋਲ ਆਊਟ ਕਰਦਾ ਹੈ।

Aurora Serverless ਬੇਸ ਰੀਡਿੰਗ ਲੋਡ ਨੂੰ ਸਕੇਲ ਕਰ ਸਕਦਾ ਹੈ। ਪਰ ਦਸਤਾਵੇਜ਼ ਇਹ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਨਹੀਂ ਕਹਿੰਦੇ ਹਨ. ਇਹ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਉਹ ਇੱਕ ਬਹੁ-ਮਾਸਟਰ ਚੁੱਕ ਸਕਦੇ ਹਨ. ਕੋਈ ਜਾਦੂ ਨਹੀਂ ਹੈ।

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

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

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

ਡਿਜ਼ਾਈਨ ਦੁਆਰਾ ਸਰਵਰ ਰਹਿਤ

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

ਇਸ ਅਧਾਰ ਨੂੰ ਸਨੋਫਲੇਕ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਤਿੰਨ ਮੁੱਖ ਬਲਾਕ ਹਨ।

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

ਦੂਸਰਾ ਬਲਾਕ ਗਣਨਾ ਲਈ ਵਰਚੁਅਲ ਕੰਪਿਊਟਿੰਗ ਕਲੱਸਟਰਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ (ਦ੍ਰਿਸ਼ਟੀ ਵਿੱਚ ਨੀਲੇ ਚੱਕਰਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ)।

ਤੀਜਾ ਬਲਾਕ S3 'ਤੇ ਆਧਾਰਿਤ ਡਾਟਾ ਸਟੋਰੇਜ ਸਿਸਟਮ ਹੈ। S3 AWS ਵਿੱਚ ਆਯਾਮ ਰਹਿਤ ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਹੈ, ਕਾਰੋਬਾਰ ਲਈ ਅਯਾਮ ਰਹਿਤ ਡ੍ਰੌਪਬਾਕਸ ਦੀ ਤਰ੍ਹਾਂ।

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

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

ਅੱਗੇ, ਸੇਵਾ ਕੰਪਿਊਟਿੰਗ ਕਲੱਸਟਰ ਦੀ ਸ਼ੁਰੂਆਤ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ। ਇੱਕ ਕੰਪਿਊਟਿੰਗ ਕਲੱਸਟਰ ਸਰਵਰਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ ਜੋ ਗਣਨਾ ਕਰਦੇ ਹਨ। ਭਾਵ, ਇਹ ਇੱਕ ਕਲੱਸਟਰ ਹੈ ਜਿਸ ਵਿੱਚ 1 ਸਰਵਰ, 2 ਸਰਵਰ, 4, 8, 16, 32 - ਜਿੰਨੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਹੋ ਸਕਦੇ ਹਨ। ਤੁਸੀਂ ਇੱਕ ਬੇਨਤੀ ਭੇਜਦੇ ਹੋ ਅਤੇ ਇਸ ਕਲੱਸਟਰ ਦੀ ਸ਼ੁਰੂਆਤ ਤੁਰੰਤ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਹ ਸੱਚਮੁੱਚ ਸਕਿੰਟ ਲੈਂਦਾ ਹੈ.

ਅੱਗੇ, ਕਲੱਸਟਰ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਡੀ ਬੇਨਤੀ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਲਈ ਲੋੜੀਂਦੇ ਮਾਈਕ੍ਰੋਪਾਰਟੀਸ਼ਨਾਂ ਨੂੰ S3 ਤੋਂ ਕਲੱਸਟਰ ਵਿੱਚ ਕਾਪੀ ਕੀਤਾ ਜਾਣਾ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦਾ ਹੈ। ਭਾਵ, ਆਓ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਇੱਕ SQL ਪੁੱਛਗਿੱਛ ਨੂੰ ਚਲਾਉਣ ਲਈ ਤੁਹਾਨੂੰ ਇੱਕ ਟੇਬਲ ਤੋਂ ਦੋ ਭਾਗਾਂ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਇੱਕ ਦੂਜੇ ਤੋਂ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸਿਰਫ਼ ਤਿੰਨ ਲੋੜੀਂਦੇ ਭਾਗ ਕਲੱਸਟਰ ਵਿੱਚ ਨਕਲ ਕੀਤੇ ਜਾਣਗੇ, ਅਤੇ ਸਾਰੇ ਟੇਬਲਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਹੀਂ। ਇਹੀ ਕਾਰਨ ਹੈ, ਅਤੇ ਬਿਲਕੁਲ ਕਿਉਂਕਿ ਸਭ ਕੁਝ ਇੱਕ ਡੇਟਾ ਸੈਂਟਰ ਦੇ ਅੰਦਰ ਸਥਿਤ ਹੈ ਅਤੇ ਬਹੁਤ ਤੇਜ਼ ਚੈਨਲਾਂ ਦੁਆਰਾ ਜੁੜਿਆ ਹੋਇਆ ਹੈ, ਸਮੁੱਚੀ ਟ੍ਰਾਂਸਫਰ ਪ੍ਰਕਿਰਿਆ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਰਦੀ ਹੈ: ਸਕਿੰਟਾਂ ਵਿੱਚ, ਬਹੁਤ ਘੱਟ ਹੀ ਮਿੰਟਾਂ ਵਿੱਚ, ਜਦੋਂ ਤੱਕ ਅਸੀਂ ਕੁਝ ਭਿਆਨਕ ਬੇਨਤੀਆਂ ਬਾਰੇ ਗੱਲ ਨਹੀਂ ਕਰ ਰਹੇ ਹਾਂ। ਇਸ ਅਨੁਸਾਰ, ਮਾਈਕ੍ਰੋਪਾਰਟੀਸ਼ਨਾਂ ਨੂੰ ਕੰਪਿਊਟਿੰਗ ਕਲੱਸਟਰ ਵਿੱਚ ਕਾਪੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ, ਪੂਰਾ ਹੋਣ 'ਤੇ, ਇਸ ਕੰਪਿਊਟਿੰਗ ਕਲੱਸਟਰ 'ਤੇ SQL ਪੁੱਛਗਿੱਛ ਨੂੰ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਬੇਨਤੀ ਦਾ ਨਤੀਜਾ ਇੱਕ ਲਾਈਨ, ਕਈ ਲਾਈਨਾਂ ਜਾਂ ਇੱਕ ਸਾਰਣੀ ਹੋ ਸਕਦਾ ਹੈ - ਉਹ ਉਪਭੋਗਤਾ ਨੂੰ ਬਾਹਰੋਂ ਭੇਜੇ ਜਾਂਦੇ ਹਨ ਤਾਂ ਜੋ ਉਹ ਇਸਨੂੰ ਡਾਉਨਲੋਡ ਕਰ ਸਕੇ, ਇਸਨੂੰ ਆਪਣੇ BI ਟੂਲ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰ ਸਕੇ, ਜਾਂ ਇਸਨੂੰ ਕਿਸੇ ਹੋਰ ਤਰੀਕੇ ਨਾਲ ਵਰਤ ਸਕੇ।

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

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

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

ਇੱਕ ਸਿੰਗਲ-ਉਪਭੋਗਤਾ ਸੈਟਿੰਗ ਵਿੱਚ ਸਨੋਫਲੇਕ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਪਹਿਲਾ ਦ੍ਰਿਸ਼। ਹੁਣ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਬਹੁਤ ਸਾਰੇ ਉਪਭੋਗਤਾ ਹਨ, ਜੋ ਅਸਲ ਦ੍ਰਿਸ਼ ਦੇ ਨੇੜੇ ਹਨ.

ਮੰਨ ਲਓ ਕਿ ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਵਿਸ਼ਲੇਸ਼ਕ ਅਤੇ ਝਾਂਕੀ ਦੀਆਂ ਰਿਪੋਰਟਾਂ ਹਨ ਜੋ ਸਾਡੇ ਡੇਟਾਬੇਸ ਨੂੰ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਸਧਾਰਨ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ SQL ਸਵਾਲਾਂ ਨਾਲ ਲਗਾਤਾਰ ਬੰਬਾਰੀ ਕਰਦੀਆਂ ਹਨ।

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

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

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

ਉਸੇ ਸਮੇਂ, ਜੇਕਰ ਵਿਸ਼ਲੇਸ਼ਕ ਸੁੱਤੇ ਹੋਏ ਹਨ ਅਤੇ ਕੋਈ ਵੀ ਰਿਪੋਰਟਾਂ ਨੂੰ ਨਹੀਂ ਦੇਖਦਾ, ਤਾਂ ਕਲੱਸਟਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਨੇਰੇ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਉਹਨਾਂ ਲਈ ਭੁਗਤਾਨ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ.

ਇਸ ਦੇ ਨਾਲ ਹੀ, ਭਾਰੀ ਸਵਾਲਾਂ ਲਈ (ਡੇਟਾ ਵਿਗਿਆਨੀਆਂ ਤੋਂ), ਤੁਸੀਂ 32 ਮਸ਼ੀਨਾਂ ਲਈ ਇੱਕ ਬਹੁਤ ਵੱਡਾ ਕਲੱਸਟਰ ਬਣਾ ਸਕਦੇ ਹੋ। ਇਸ ਕਲੱਸਟਰ ਨੂੰ ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਮਿੰਟਾਂ ਅਤੇ ਘੰਟਿਆਂ ਲਈ ਭੁਗਤਾਨ ਕੀਤਾ ਜਾਵੇਗਾ ਜਦੋਂ ਤੁਹਾਡੀ ਵਿਸ਼ਾਲ ਬੇਨਤੀ ਉੱਥੇ ਚੱਲ ਰਹੀ ਹੈ।

ਉੱਪਰ ਦੱਸਿਆ ਗਿਆ ਮੌਕਾ ਤੁਹਾਨੂੰ ਨਾ ਸਿਰਫ਼ 2, ਸਗੋਂ ਹੋਰ ਕਿਸਮਾਂ ਦੇ ਕੰਮ ਦੇ ਬੋਝ ਨੂੰ ਕਲੱਸਟਰਾਂ (ETL, ਨਿਗਰਾਨੀ, ਰਿਪੋਰਟ ਸਮੱਗਰੀਕਰਨ,...) ਵਿੱਚ ਵੰਡਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਆਉ ਬਰਫ਼ਬਾਰੀ ਦਾ ਸਾਰ ਕਰੀਏ। ਅਧਾਰ ਇੱਕ ਸੁੰਦਰ ਵਿਚਾਰ ਅਤੇ ਇੱਕ ਕਾਰਜਸ਼ੀਲ ਲਾਗੂਕਰਨ ਨੂੰ ਜੋੜਦਾ ਹੈ। ManyChat 'ਤੇ, ਅਸੀਂ ਸਾਡੇ ਕੋਲ ਮੌਜੂਦ ਸਾਰੇ ਡੇਟਾ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ Snowflake ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਸਾਡੇ ਕੋਲ ਤਿੰਨ ਕਲੱਸਟਰ ਨਹੀਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਉਦਾਹਰਨ ਵਿੱਚ, ਪਰ 5 ਤੋਂ 9 ਤੱਕ, ਵੱਖ-ਵੱਖ ਆਕਾਰਾਂ ਦੇ। ਸਾਡੇ ਕੋਲ ਕੁਝ ਕੰਮਾਂ ਲਈ ਰਵਾਇਤੀ 16-ਮਸ਼ੀਨ, 2-ਮਸ਼ੀਨ, ਅਤੇ ਸੁਪਰ-ਛੋਟੀ 1-ਮਸ਼ੀਨ ਵੀ ਹਨ। ਉਹ ਸਫਲਤਾਪੂਰਵਕ ਲੋਡ ਨੂੰ ਵੰਡਦੇ ਹਨ ਅਤੇ ਸਾਨੂੰ ਬਹੁਤ ਕੁਝ ਬਚਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ.

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

ਇਸ ਅਨੁਸਾਰ, ਡੇਟਾਬੇਸ OLAP ਕਾਰਜਾਂ ਲਈ ਚੰਗੀ ਤਰ੍ਹਾਂ ਅਨੁਕੂਲ ਹੈ। ਹਾਲਾਂਕਿ, ਬਦਕਿਸਮਤੀ ਨਾਲ, ਇਹ ਅਜੇ OLTP ਵਰਕਲੋਡਾਂ ਲਈ ਲਾਗੂ ਨਹੀਂ ਹੈ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਡੇਟਾਬੇਸ ਕਾਲਮ ਹੈ, ਜਿਸ ਵਿੱਚ ਆਉਣ ਵਾਲੇ ਸਾਰੇ ਨਤੀਜੇ ਹਨ। ਦੂਜਾ, ਪਹੁੰਚ ਆਪਣੇ ਆਪ, ਜਦੋਂ ਹਰੇਕ ਬੇਨਤੀ ਲਈ, ਜੇ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਕੰਪਿਊਟਿੰਗ ਕਲੱਸਟਰ ਬਣਾਉਂਦੇ ਹੋ ਅਤੇ ਇਸਨੂੰ ਡੇਟਾ ਨਾਲ ਭਰ ਦਿੰਦੇ ਹੋ, ਬਦਕਿਸਮਤੀ ਨਾਲ, OLTP ਲੋਡ ਕਰਨ ਲਈ ਅਜੇ ਵੀ ਤੇਜ਼ ਨਹੀਂ ਹੈ। OLAP ਕਾਰਜਾਂ ਲਈ ਸਕਿੰਟਾਂ ਦੀ ਉਡੀਕ ਕਰਨਾ ਆਮ ਗੱਲ ਹੈ, ਪਰ OLTP ਕਾਰਜਾਂ ਲਈ ਇਹ ਅਸਵੀਕਾਰਨਯੋਗ ਹੈ; 100 ms ਬਿਹਤਰ ਹੋਵੇਗਾ, ਜਾਂ 10 ms ਹੋਰ ਵੀ ਵਧੀਆ ਹੋਵੇਗਾ।

ਨਤੀਜਾ

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

SQL ਸਵਾਲਾਂ ਨੂੰ ਐਗਜ਼ੀਕਿਊਟ ਕਰਨਾ ਲਾਈਟ-ਸਟੇਟ ਸੇਵਾਵਾਂ ਵਜੋਂ ਵੀ ਸਮਝਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜੋ ਸਰਵਰ ਰਹਿਤ ਮੋਡ ਵਿੱਚ ਪੌਪ-ਅੱਪ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਸਨੋਫਲੇਕ ਕੰਪਿਊਟਿੰਗ ਕਲੱਸਟਰ, ਸਿਰਫ਼ ਲੋੜੀਂਦਾ ਡਾਟਾ ਡਾਊਨਲੋਡ ਕਰਨਾ, ਪੁੱਛਗਿੱਛ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਅਤੇ "ਬਾਹਰ ਜਾਣਾ"।

ਸਰਵਰ ਰਹਿਤ ਉਤਪਾਦਨ ਪੱਧਰ ਦੇ ਡੇਟਾਬੇਸ ਪਹਿਲਾਂ ਹੀ ਵਰਤੋਂ ਲਈ ਉਪਲਬਧ ਹਨ, ਉਹ ਕੰਮ ਕਰ ਰਹੇ ਹਨ। ਇਹ ਸਰਵਰ ਰਹਿਤ ਡੇਟਾਬੇਸ OLAP ਕਾਰਜਾਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਪਹਿਲਾਂ ਹੀ ਤਿਆਰ ਹਨ। ਬਦਕਿਸਮਤੀ ਨਾਲ, OLTP ਕਾਰਜਾਂ ਲਈ ਉਹ ਵਰਤੇ ਜਾਂਦੇ ਹਨ... ਸੂਖਮਤਾ ਦੇ ਨਾਲ, ਕਿਉਂਕਿ ਸੀਮਾਵਾਂ ਹਨ। ਇੱਕ ਪਾਸੇ, ਇਹ ਇੱਕ ਘਟਾਓ ਹੈ. ਪਰ, ਦੂਜੇ ਪਾਸੇ, ਇਹ ਇੱਕ ਮੌਕਾ ਹੈ. ਸ਼ਾਇਦ ਪਾਠਕਾਂ ਵਿੱਚੋਂ ਕੋਈ ਇੱਕ OLTP ਡੇਟਾਬੇਸ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਰਵਰ ਰਹਿਤ ਬਣਾਉਣ ਦਾ ਤਰੀਕਾ ਲੱਭੇਗਾ, ਬਿਨਾਂ ਔਰੋਰਾ ਦੀਆਂ ਸੀਮਾਵਾਂ ਦੇ।

ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਇਹ ਦਿਲਚਸਪ ਲੱਗਿਆ। ਸਰਵਰ ਰਹਿਤ ਭਵਿੱਖ ਹੈ :)

ਸਰੋਤ: www.habr.com