ਸਿਲੈਕਟ ਅਤੇ ਡਿਸਕ ਦੇ ਵਿਚਕਾਰ ਤਿੰਨ ਕੈਸ਼ ਲੇਅਰਸ

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

ਉਸ ਪਲ ਕੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ SELECT ਪੁੱਛਗਿੱਛ ਤੁਹਾਡੀ ਅਰਜ਼ੀ ਛੱਡ ਦਿੰਦੀ ਹੈ?

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

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

ਬਫਰ ਪੂਲ ਕੀ ਹੈ ਅਤੇ ਇਹ ਤੁਹਾਡੇ ਸੋਚਣ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮਾਇਨੇ ਕਿਉਂ ਰੱਖਦਾ ਹੈ?

ਦੂਜੀ ਕੈਸ਼ ਪਰਤ — ਅਤੇ ਦਲੀਲ ਨਾਲ ਉਤਪਾਦਨ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ — ਹੈ ਬਫਰ ਪੂਲ (ਜਿਸ ਨੂੰ PostgreSQL ਵਿੱਚ ਸਾਂਝਾ ਬਫਰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, MySQL ਵਿੱਚ InnoDB ਬਫਰ ਪੂਲ)। ਇਹ RAM ਦਾ ਇੱਕ ਖੇਤਰ ਹੈ ਜੋ ਡਾਟਾਬੇਸ ਇੰਜਣ ਹਾਲ ਹੀ ਵਿੱਚ ਐਕਸੈਸ ਕੀਤੇ ਡੇਟਾ ਪੰਨਿਆਂ ਨੂੰ ਰੱਖਣ ਲਈ ਵਰਤਦਾ ਹੈ। ਜਦੋਂ ਨਤੀਜਾ ਕੈਸ਼ ਤੋਂ ਪੁੱਛਗਿੱਛ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ, ਤਾਂ ਇੰਜਣ ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਕੋਈ ਵੀ ਡਿਸਕ ਰੀਡ ਜਾਰੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲੋੜੀਂਦੇ ਡੇਟਾ ਪੰਨੇ ਪਹਿਲਾਂ ਹੀ ਬਫਰ ਪੂਲ ਵਿੱਚ ਮੌਜੂਦ ਹਨ।

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

ਮੁੱਖ ਸੂਝ: ਜ਼ਿਆਦਾਤਰ OLTP ਵਰਕਲੋਡਾਂ ਵਿੱਚ, ਇੱਕ ਚੰਗੀ-ਆਕਾਰ ਦੇ ਬਫਰ ਪੂਲ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਾਰੇ ਡਾਟਾ ਰੀਡ ਦਾ 95-99% RAM ਤੋਂ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਕਾਰਜਸ਼ੀਲ ਸੈੱਟ — ਤੁਹਾਡੇ ਡੇਟਾ ਦਾ ਸਬਸੈੱਟ ਜੋ ਕਿ ਅਸਲ ਵਿੱਚ ਅਕਸਰ ਛੂਹਦਾ ਹੈ — ਅਕਸਰ ਕੁੱਲ ਡਾਟਾਬੇਸ ਆਕਾਰ ਤੋਂ ਬਹੁਤ ਛੋਟਾ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਡੇ ਕੰਮਕਾਜੀ ਸੈੱਟ ਨੂੰ ਫਿੱਟ ਕਰਨ ਲਈ ਤੁਹਾਡੇ ਬਫਰ ਪੂਲ ਨੂੰ ਆਕਾਰ ਦੇਣਾ, ਤੁਹਾਡੇ ਪੂਰੇ ਡੇਟਾਸੈਟ ਨੂੰ ਨਹੀਂ, ਤੁਹਾਡੇ ਦੁਆਰਾ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਸਭ ਤੋਂ ਵੱਧ ਵਾਪਸੀ ਵਾਲੀ ਟਿਊਨਿੰਗ ਕਾਰਵਾਈ ਹੈ।

ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਕੈਸ਼ ਰੈਮ ਅਤੇ ਡਿਸਕ ਦੇ ਵਿਚਕਾਰਲੇ ਪਾੜੇ ਨੂੰ ਕਿਵੇਂ ਭਰਦਾ ਹੈ?

ਜਦੋਂ ਵੀ ਡੇਟਾਬੇਸ ਦਾ ਆਪਣਾ ਬਫਰ ਪੂਲ ਖੁੰਝ ਜਾਂਦਾ ਹੈ, ਇੱਕ ਪੁੱਛਗਿੱਛ ਅਜੇ ਵੀ ਇੱਕ ਸੱਚੀ ਡਿਸਕ ਰੀਡ ਲਈ ਨਿਯਤ ਨਹੀਂ ਹੈ। ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਇੱਕ ਪੰਨਾ ਕੈਸ਼ (ਜਿਸ ਨੂੰ ਫਾਈਲ ਸਿਸਟਮ ਕੈਸ਼ ਵੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ), ਕਰਨਲ-ਪ੍ਰਬੰਧਿਤ RAM ਦਾ ਇੱਕ ਖੇਤਰ ਰੱਖਦਾ ਹੈ ਜੋ ਡਿਵਾਈਸਾਂ ਨੂੰ ਬਲਾਕ ਕਰਨ ਲਈ ਪੜ੍ਹਨ ਅਤੇ ਲਿਖਣ ਨੂੰ ਬਫਰ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਡੇਟਾਬੇਸ ਇੰਜਣ ਇੱਕ ਪੰਨੇ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ ਜੋ ਇਸਦੇ ਬਫਰ ਪੂਲ ਤੋਂ ਗੈਰਹਾਜ਼ਰ ਹੈ, ਤਾਂ OS ਕਰਨਲ ਸਟੋਰੇਜ਼ ਕੰਟਰੋਲਰ ਨੂੰ ਭੌਤਿਕ I/O ਕਮਾਂਡ ਜਾਰੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਪੇਜ ਕੈਸ਼ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ।

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

ਅਭਿਆਸ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਪ੍ਰਦਰਸ਼ਨ ਜਿੱਤਾਂ ਲਈ ਕਿਹੜੀ ਕੈਸ਼ ਲੇਅਰ ਜ਼ਿੰਮੇਵਾਰ ਹੈ?

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

• ਪੁੱਛਗਿੱਛ ਨਤੀਜਾ ਕੈਸ਼: ਰੀਡ-ਹੈਵੀ, ਜ਼ਿਆਦਾਤਰ ਸਥਿਰ ਡੇਟਾਸੇਟਾਂ 'ਤੇ ਸਭ ਤੋਂ ਵੱਧ ਲਾਭ — ਰਿਪੋਰਟਿੰਗ ਪੁੱਛਗਿੱਛ, ਕੈਸ਼ਡ ਡੈਸ਼ਬੋਰਡ, ਜਨਤਕ ਸਮੱਗਰੀ ਅੰਤਮ ਬਿੰਦੂ। ਲਿਖਣ-ਭਾਰੀ ਟੇਬਲ 'ਤੇ ਬੇਕਾਰ।
• ਡਾਟਾਬੇਸ ਬਫਰ ਪੂਲ: ਯੂਨੀਵਰਸਲ ਵਰਕ ਹਾਰਸ। ਹਰੇਕ ਉਤਪਾਦਨ ਡੇਟਾਬੇਸ ਸਰਵਰ ਨੂੰ ਪਹਿਲਾਂ ਇੱਥੇ ਟਿਊਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਬੇਤਰਤੀਬ ਅਤੇ ਕ੍ਰਮਵਾਰ ਪਹੁੰਚ ਪੈਟਰਨਾਂ ਨੂੰ ਕੁਸ਼ਲਤਾ ਨਾਲ ਹੈਂਡਲ ਕਰਦਾ ਹੈ।
• OS ਪੇਜ ਕੈਸ਼: ਇੱਕ ਸੁਰੱਖਿਆ ਜਾਲ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜਦੋਂ ਬਫਰ ਪੂਲ ਦਾ ਆਕਾਰ ਘੱਟ ਹੁੰਦਾ ਹੈ। ਵੱਡੀਆਂ ਟੇਬਲਾਂ ਦੇ ਕ੍ਰਮਵਾਰ ਸਕੈਨ ਦੌਰਾਨ ਵੀ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਮਦਦ ਕਰਦਾ ਹੈ ਜੋ ਕਿ ਬਫਰ ਪੂਲ ਤੋਂ ਗਰਮ ਪੰਨਿਆਂ ਨੂੰ ਬਾਹਰ ਕੱਢ ਦੇਵੇਗਾ।
• ਸਟੋਰੇਜ ਕੰਟਰੋਲਰ ਕੈਸ਼ (ਹਾਰਡਵੇਅਰ ਲੇਅਰ): ਇੱਕ ਚੌਥੀ, ਅਕਸਰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤੀ ਪਰਤ — NVMe SSDs ਅਤੇ RAID ਕੰਟਰੋਲਰ ਬੈਟਰੀ ਜਾਂ ਕੈਪੇਸੀਟਰ ਬੈਕਅੱਪ ਦੇ ਨਾਲ ਆਨਬੋਰਡ ਰਾਈਟ ਕੈਚਾਂ ਨੂੰ ਬਣਾਈ ਰੱਖਦੇ ਹਨ। ਇਹ fsync ਲੇਟੈਂਸੀ ਦੀ ਕੀਮਤ 'ਤੇ ਰਾਈਟ ਥ੍ਰੁਪੁੱਟ ਦੀ ਬਲੀ ਦਿੱਤੇ ਬਿਨਾਂ ਟਿਕਾਊਤਾ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ।
• ਐਪਲੀਕੇਸ਼ਨ-ਲੇਅਰ ਕੈਸ਼ (Redis, Memcached): ਪੂਰੀ ਤਰ੍ਹਾਂ ਡਾਟਾਬੇਸ ਦੇ ਉੱਪਰ ਬੈਠਦਾ ਹੈ, ਸੀਰੀਅਲਾਈਜ਼ਡ ਪੁੱਛਗਿੱਛ ਦੇ ਨਤੀਜਿਆਂ ਜਾਂ ਗਣਿਤ ਕੀਤੀਆਂ ਵਸਤੂਆਂ ਨੂੰ ਕੈਸ਼ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਡੇਟਾਬੇਸ ਨੂੰ ਬਿਲਕੁਲ ਵੀ ਹਿੱਟ ਕਰਨ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ — ਹਜ਼ਾਰਾਂ ਸਮਕਾਲੀ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਸੇਵਾ ਕਰਨ ਵਾਲੇ ਬਹੁ-ਕਿਰਾਏਦਾਰ SaaS ਪਲੇਟਫਾਰਮਾਂ ਲਈ ਆਦਰਸ਼।

ਸਕੇਲ 'ਤੇ ਭਰੋਸੇਯੋਗਤਾ ਲਈ ਆਧੁਨਿਕ ਵਪਾਰਕ ਪਲੇਟਫਾਰਮ ਕੈਸ਼ ਆਰਕੀਟੈਕਚਰ ਦਾ ਲਾਭ ਕਿਵੇਂ ਲੈ ਸਕਦੇ ਹਨ?

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

ਮੇਵੇਜ਼ ਬਿਲਕੁਲ ਇਸੇ ਫ਼ਲਸਫ਼ੇ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ। 138,000 ਤੋਂ ਵੱਧ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸ਼ਕਤੀ ਪ੍ਰਦਾਨ ਕਰਨ ਵਾਲੇ 207 ਏਕੀਕ੍ਰਿਤ ਵਪਾਰਕ ਮੋਡੀਊਲ ਦੇ ਨਾਲ, ਪਲੇਟਫਾਰਮ ਦੀ ਡਾਟਾ ਪਰਤ ਨੂੰ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਹੈ ਤਾਂ ਕਿ ਬਹੁਤ ਜ਼ਿਆਦਾ ਰੀਡ ਕੈਸ਼ ਤੋਂ ਪੇਸ਼ ਕੀਤੇ ਜਾ ਸਕਣ — ਜਵਾਬ ਦੇ ਸਮੇਂ ਨੂੰ ਤੇਜ਼ ਰੱਖਣ ਅਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਖਰਚਿਆਂ ਦਾ ਅਨੁਮਾਨ ਲਗਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਭਾਵੇਂ ਤੁਸੀਂ $19/ਮਹੀਨੇ ਦੀ ਸਟਾਰਟਰ ਯੋਜਨਾ ਜਾਂ $49/ਮਹੀਨੇ ਦੇ ਪੇਸ਼ੇਵਰ ਟੀਅਰ 'ਤੇ ਚੱਲ ਰਹੇ ਹੋ।

ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ

ਕੀ ਪੁੱਛਗਿੱਛ ਕੈਸ਼ ਨੂੰ ਅਯੋਗ ਕਰਨ ਨਾਲ ਹਮੇਸ਼ਾ ਡਾਟਾਬੇਸ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਸੁਧਾਰ ਹੁੰਦਾ ਹੈ?

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

ਮੈਨੂੰ ਕਿਵੇਂ ਪਤਾ ਲੱਗੇਗਾ ਕਿ ਮੇਰੇ ਬਫਰ ਪੂਲ ਦਾ ਆਕਾਰ ਸਹੀ ਹੈ?

ਆਪਣੇ ਬਫਰ ਪੂਲ ਹਿੱਟ ਅਨੁਪਾਤ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ: ਪੂਲ ਤੋਂ ਦਿੱਤੀਆਂ ਗਈਆਂ ਪੇਜ ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਤੀਸ਼ਤ ਬਨਾਮ ਡਿਸਕ ਰੀਡ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। OLTP ਵਰਕਲੋਡ 'ਤੇ 95% ਤੋਂ ਘੱਟ ਹਿੱਟ ਅਨੁਪਾਤ ਪੂਲ ਦਾ ਆਕਾਰ ਵਧਾਉਣ ਦਾ ਸੰਕੇਤ ਹੈ। MySQL ਵਿੱਚ, ਸ਼ੋ ਇੰਜਨ INNODB ਸਥਿਤੀ ਪੁੱਛਗਿੱਛ ਕਰੋ ਅਤੇ ਬਫਰ ਪੂਲ ਹਿੱਟ ਰੇਟ ਦੇਖੋ। PostgreSQL ਵਿੱਚ, pg_statio_user_tables ਦ੍ਰਿਸ਼ ਡਿਸਕ ਤੋਂ ਪੜ੍ਹੇ ਗਏ ਹੀਪ ਬਲਾਕਾਂ ਨੂੰ ਬਫਰ ਪੂਲ ਤੋਂ ਪਰੋਸਦਾ ਹੈ। ਤੁਹਾਡੇ ਪੂਰੇ ਕੰਮਕਾਜੀ ਸੈੱਟ ਨੂੰ ਰੱਖਣ ਦਾ ਟੀਚਾ ਰੱਖੋ — ਤੁਹਾਡਾ ਪੂਰਾ ਡੇਟਾਸੈਟ ਨਹੀਂ — ਰੈਮ ਵਿੱਚ ਰਹਿਣ ਵਾਲਾ।

ਕੈਸ਼ ਲੇਅਰਾਂ ਅਤੇ ਮਲਟੀ-ਟੇਨੈਂਟ SaaS ਭਰੋਸੇਯੋਗਤਾ ਵਿਚਕਾਰ ਕੀ ਸਬੰਧ ਹੈ?

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

ਕੈਸ਼ ਲੇਅਰਾਂ ਡੇਟਾਬੇਸ ਟ੍ਰੀਵੀਆ ਨਹੀਂ ਹਨ — ਇਹ ਆਰਕੀਟੈਕਚਰਲ ਫਾਊਂਡੇਸ਼ਨ ਹਨ ਜੋ ਪਲੇਟਫਾਰਮਾਂ ਨੂੰ ਉਹਨਾਂ ਪਲੇਟਫਾਰਮਾਂ ਤੋਂ ਵੱਖ ਕਰਦੀਆਂ ਹਨ ਜੋ ਪੈਮਾਨੇ 'ਤੇ ਤੇਜ਼ ਰਹਿੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਲਈ ਨਿਰੰਤਰ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਅੱਗ ਬੁਝਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਕੋਈ ਅਜਿਹਾ ਕਾਰੋਬਾਰ ਬਣਾ ਰਹੇ ਹੋ ਜਾਂ ਚਲਾ ਰਹੇ ਹੋ ਜਿਸ ਨੂੰ ਇਹਨਾਂ ਹਕੀਕਤਾਂ ਲਈ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਅਨੁਕੂਲਿਤ ਪਲੇਟਫਾਰਮ ਦੀ ਲੋੜ ਹੈ, app.mewayz.com 'ਤੇ Mewayz ਦੀ ਪੜਚੋਲ ਕਰੋ — 207 ਮੋਡੀਊਲ, ਇੱਕ ਸੁਮੇਲ ਪਲੇਟਫਾਰਮ, ਤੁਹਾਡੇ ਪਹਿਲੇ ਉਪਭੋਗਤਾ ਤੋਂ ਲੈ ਕੇ ਤੁਹਾਡੇ ਸੌ-ਹਜ਼ਾਰਵੇਂ ਤੱਕ ਭਰੋਸੇਯੋਗ ਪ੍ਰਦਰਸ਼ਨ ਕਰਨ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ।