MySQL ਨੇ ਸ਼ੁਰੂਆਤੀ LAMP ਸਾਈਟਾਂ ਤੋਂ ਲੈ ਕੇ ਅੱਜ ਦੇ ਉੱਚ-ਵਾਲੀਉਮ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਕਿਵੇਂ ਵਧਿਆ: ਮੁੱਖ ਡਿਜ਼ਾਈਨ ਚੋਣਾਂ, InnoDB, ਰੀਪਲੀਕੇਸ਼ਨ, ਸ਼ਾਰਡਿੰਗ, ਅਤੇ ਪ੍ਰਯੋਗਕ ਤਰੀਕੇ।
MySQL ਸ਼ੁਰੂਆਤੀ ਵੈੱਬ ਦਾ ਜ਼ਿਆਦਾਤਰ ਲੋਕਪ੍ਰਿਯ ਡੇਟਾਬੇਸ ਕਿਉਂ ਬਣਿਆ: ਇੱਕ ਸਧਾਰਨ ਕਾਰਣ ਸੀ — ਇਹ ਉਹੀ ਚੀਜ਼ ਪੂਰੀ ਕਰਦਾ ਸੀ ਜੋ ਵੈੱਬਸਾਈਟਾਂ ਨੂੰ ਉਸ ਸਮੇਂ ਚਾਹੀਦੀ ਸੀ—ਸੰਰਚਿਤ ਡੇਟਾ ਤੇਜ਼ੀ ਨਾਲ ਸਟੋਰ ਅਤੇ ਰੀਟ੍ਰਾਈਵ ਕਰਨਾ, ਅਮਰੀ ਜ਼ਿਆਦਾ ਨਹੀਂ ਹਾਰਡਵੇਅਰ 'ਤੇ ਚੱਲਣਾ, ਅਤੇ ਛੋਟੀ ਟੀਮਾਂ ਲਈ ਸੰਭਾਲਣਾ ਆਸਾਨ ਰਹਿਣਾ।
ਇਹ ਪਹੁੰਚਯੋਗ ਸੀ। ਇੰਸਟਾਲ ਕਰਨਾ ਤੇਜ਼ ਸੀ, ਆਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਤੋਂ ਕਨੈਕਟ ਹੋ ਸਕਦਾ ਸੀ, ਅਤੇ ਇੱਕ ਸਾਈਟ ਨੂੰ ਚਲੂ ਕਰਨ ਲਈ dedicated ਡੇਟਾਬੇਸ ਐਡਮਿਨ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ ਸੀ। "ਔਖਾ ਨਹੀਂ, ਪਰ ਕਾਫ਼ੀ ਚੰਗਾ" ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਘੱਟ ਓਪਰੇਸ਼ਨਲ ਓਵਰਹੈੱਡ ਦੇ ਇਸ ਮਿਲਾਪ ਨੇ ਇਸਨੂੰ startups, ਹੋਬੀ ਪ੍ਰੋਜੈਕਟਾਂ ਅਤੇ ਵੱਧ ਰਹੀਆਂ ਕੰਪਨੀਆਂ ਲਈ ਡੀਫਾਲਟ ਬਣਾ ਦਿੱਤਾ।
ਜਦੋਂ ਲੋਕ ਕਹਿੰਦੇ ਹਨ MySQL "ਸਕੇਲ" ਹੋਇਆ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਮਿਲੀ-ਝੁਲੀ ਗੱਲਾਂ ਨੂੰ ਮਤਲਬ ਰੱਖਦੇ ਹਨ:
ਸ਼ੁਰੂਆਤੀ ਵੈੱਬ ਕੰਪਨੀਆਂ ਨੂੰ ਸਿਰਫ਼ ਸਪੀਡ ਨਹੀਂ ਚਾਹੀਦੀ ਸੀ; ਉਹਨਾਂ ਨੂੰ ਪਰੇਖਣਯੋਗ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ uptime ਦੀ ਲੋੜ ਸੀ ਜਦੋਂ ਉਹ ਇੰਫ੍ਰਾਸਟ੍ਰਕਚਰ ਖ਼ਰਚ ਘੱਟ ਰੱਖ ਰਹੇ ਹੋਣ।
MySQL ਦਾ ਸਕੇਲਿੰਗ ਕਹਾਣੀ ਅਸਲ ਵਿੱਚ ਵਰਤੋਂਯੋਗ tradeoffs ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਪੈਟਰਨਾਂ ਦੀ ਕਹਾਣੀ ਹੈ:
ਇਹ ਉਹ ਪੈਟਰਨਾਂ ਦੀ ਸੈਰ ਹੈ ਜੋ ਟੀਮਾਂ ਨੇ MySQL ਨੂੰ ਅਸਲ ਵੈੱਬ ਟ੍ਰੈਫਿਕ ਹੇਠਾਂ performant ਰੱਖਣ ਲਈ ਵਰਤੇ—ਪੂਰਾ MySQL ਮੈਨੂਅਲ ਨਹੀਂ। ਮਕਸਦ ਇਹ ਸਮਝਾਉਣਾ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਵੈੱਬ ਦੀਆਂ ਲੋੜਾਂ ਨਾਲ ਕਿਵੇਂ ਮਿਲਿਆ ਅਤੇ ਕਿਉਂ ਉਹੇ ਹੀ ਵਿਚਾਰ ਅਜੇ ਵੀ ਵੱਡੇ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮਾਂ ਵਿੱਚ ਵਰਤੇ ਜਾਂਦੇ ਹਨ।
MySQL ਦਾ ਬ੍ਰੇਕਆਊਟ ਲਹਿਰ ਸਾਂਝੇ ਹੋਸਟਿੰਗ ਅਤੇ ਛੋਟੀ ਟੀਮਾਂ ਦੇ ਤੇਜ਼ੀ ਨਾਲ ਵੈੱਬ ਐਪ ਬਣਾਉਣ ਨਾਲ ਗਹਿਰਾਈ ਨਾਲ ਜੁੜੀ ਸੀ। ਇਹ ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਸੀ ਕਿ MySQL "ਕਾਫ਼ੀ ਚੰਗਾ" ਸੀ—ਇਹ ਉਸ ਤਰੀਕੇ ਨਾਲ ਫਿੱਟ ਹੋਇਆ ਜਿਵੇਂ ਸ਼ੁਰੂਆਤੀ ਵੈੱਬ ਤੈਿਆਰ, ਪ੍ਰਬੰਧ ਅਤੇ ਭੁਗਤਾਨ ਕੀਤਾ ਜਾਂਦਾ ਸੀ।
LAMP (Linux, Apache, MySQL, PHP/Perl/Python) ਇਸ ਲਈ ਕੰਮ ਕਰਦਾ ਸੀ ਕਿਉਂਕਿ ਇਹ ਡਿਫਾਲਟ ਸਰਵਰ ਨਾਲ ਮਿਲਦਾ ਸੀ ਜੋ ਜ਼ਿਆਦਾਤਰ ਲੋਕ afford ਕਰ ਸਕਦੇ ਸਨ: ਇੱਕ ਇੱਕਲਿਆ Linux ਬਾਕਸ ਜੋ ਇੱਕ ਵੈੱਬ ਸਰਵਰ ਅਤੇ ਡੇਟਾਬੇਸ ਇੱਕਠੇ ਚਲਾਂਦਾ ਸੀ।
ਹੋਸਟਿੰਗ ਪ੍ਰੋਵਾਈਡਰ ਇਸ ਸੈਟਅਪ ਨੂੰ ਟੈਮਪਲੇਟ ਕਰ ਸਕਦੇ ਸਨ, ਇੰਸਟਾਲਸ ਆਟੋਮੇਟ ਕਰ ਸਕਦੇ ਸਨ, ਅਤੇ ਸਸਤੇ ਵਿੱਚ ਆਫ਼ਰ ਕਰ ਸਕਦੇ ਸਨ। ਡਿਵੈਲਪਰ ਇੱਕੋ ਬੇਸਲਾਈਨ ਮਾਹੌਲ ਅਕਸਰ ਸਭ ਜਗ੍ਹਾ ਉਮੀਦ ਕਰ ਸਕਦੇ ਸਨ, ਜਿਸ ਨਾਲ local development ਤੋਂ production ਵਿੱਚ ਜਾਣ 'ਤੇ ਘੱਟ ਹੈਰਾਨੀਆਂ ਆਉਂਦੀਆਂ।
MySQL ਇੰਸਟਾਲ ਕਰਨਾ, ਸ਼ੁਰੂ ਕਰਨਾ ਅਤੇ ਕਨੈਕਟ ਕਰਨਾ ਸਿੱਧਾ ਸੀ। ਇਹ ਜਾਣ ਪਛਾਣਯੋਗ SQL ਬੋਲਦਾ ਸੀ, ਇੱਕ ਸਧਾਰਨ command-line client ਸੀ, ਅਤੇ ਉਸ ਸਮੇਂ ਪ੍ਰਚਲਿਤ ਭਾਸ਼ਾਵਾਂ ਅਤੇ ਫਰੇਮਵਰਕਾਂ ਨਾਲ ਅਚਛੀ ਤਰ੍ਹਾਂ ਇੰਟੀਗਰੇਟ ਹੁੰਦਾ ਸੀ।
ਜਿਸ ਤਰ੍ਹਾਂ ਨਾਲ ਅਪਰੇਸ਼ਨ ਮਾਡਲ ਸੌਖਾ ਸੀ: ਇਕ ਪ੍ਰਾਇਮਰੀ ਪ੍ਰੋਸੈਸ, ਕੁਝ configuration ਫਾਇਲਾਂ, ਅਤੇ ਸਪੱਸ਼ਟ ਫੇਲਿਯਰ ਮੋਡ। ਇਸ ਨਾਲ ਆਮ sysadmins (ਅਤੇ ਅਕਸਰ ਡਿਵੈਲਪਰ) ਲਈ ਡੇਟਾਬੇਸ ਚਲਾਉਣਾ possible ਹੋ ਗਿਆ ਬਿਨਾਂ ਖ਼ਾਸ ਤਾਲੀਮ ਦੇ।
ਖੁੱਲ੍ਹਾ-ਸਰੋਤ ਹੋਣ ਨਾਲ ਅਗੇ-ਅਗੇ ਲਾਇਸੰਸ ਫ੍ਰਿਕਸ਼ਨ ਘੱਟ ਹੋ ਗਈ। ਇੱਕ ਵਿਦਿਆਰਥੀ ਪ੍ਰੋਜੈਕਟ, ਇੱਕ ਹੋਬੀ ਫੋਰਮ, ਅਤੇ ਇੱਕ ਛੋਟੀ ਵਪਾਰਿਕ ਸਾਈਟ ਇਹੀ ਡੇਟਾਬੇਸ ਇੰਜਣ ਵਰਤ ਸਕਦੇ ਸਨ ਜਿਵੇਂ ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ।
ਡੌਕੂਮੈਂਟੇਸ਼ਨ, ਮੈਲਿੰਗ ਲਿਸਟਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਆਨਲਾਈਨ ਟਿਊਟੋਰਿਯਲਜ਼ ਨੇ momentum ਬਣਾਈ: ਜ਼ਿਆਦਾ ਯੂਜ਼ਰਾਂ ਦਾ ਮਤਲਬ ਹੋਰ ਉਦਾਹਰਣਾਂ, ਹੋਰ ਟੂਲਜ਼, ਅਤੇ ਤੇਜ਼ ਟ੍ਰਬਲਸ਼ੂਟਿੰਗ ਸੀ।
ਅਕਸਰ ਸ਼ੁਰੂਆਤੀ ਸਾਈਟਾਂ read-heavy ਅਤੇ ਕਾਫ਼ੀ ਸਧਾਰਨ ਹੁੰਦੀਆਂ: ਫੋਰਮ, ਬਲੌਗ, CMS-ਚਲਿਤ ਪੇਜ, ਅਤੇ ਛੋਟੇ e-commerce ਕੈਟਲੌਗ। ਇਹ ਐਪਸ ਆਮ ਤੌਰ 'ਤੇ ID ਨਾਲ ਤੇਜ਼ ਲੁੱਕਅੱਪ, ਹਾਲੀਆ ਪੋਸਟ, ਯੂਜ਼ਰ ਅਕਾਊਂਟ, ਅਤੇ ਬੁਨਿਆਦੀ ਖੋਜ ਜਾਂ ਫਿਲਟਰਿੰਗ ਚਾਹੁੰਦੇ ਸਨ—ਬਿਲਕુલ ਉਹ ਵਰਕਲੋਡ ਜੋ MySQL ਨਿੱਜੀ ਹਾਰਡਵੇਅਰ 'ਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲ ਸਕਦਾ ਸੀ।
ਸ਼ੁਰੂਆਤੀ MySQL deployments ਅਕਸਰ "ਇੱਕ ਸਰਵਰ, ਇੱਕ ਡੇਟਾਬੇਸ, ਇੱਕ ਐਪ" ਵਜੋਂ ਸ਼ੁਰੂ ਹੁੰਦੇ ਸਨ। ਇਹ ਇੱਕ ਹੋਬੀ ਫੋਰਮ ਜਾਂ ਛੋਟੀ ਕੰਪਨੀ ਦੀ ਸਾਈਟ ਲਈ ਠੀਕ ਸੀ—ਜਦ ਤਕ ਐਪ ਪ੍ਰਸਿੱਧ ਨਹੀਂ ਹੋ ਜਾਂਦੀ। ਪੇਜ ਵਿਊਜ਼ ਸੈਸ਼ਨ ਬਣ ਗਏ, ਸੈਸ਼ਨ ਲਗਾਤਾਰ ਟ੍ਰੈਫਿਕ ਬਣ ਗਏ, ਅਤੇ ਡੇਟਾਬੇਸ ਇੱਕ ਖਾਮੋਸ਼ ਬੈਕਰੂਮ ਕੰਪੋਨੈਂਟ ਰਹਿਣਾ ਬੰਦ ਹੋ ਗਿਆ।
ਜ਼ਿਆਦਾਤਰ ਵੈੱਬ ਐਪ (ਅਜੇ ਵੀ) read-heavy ਹਨ। ਇੱਕ ਹੋਮਪੇਜ, ਪ੍ਰੋਡਕਟ ਲਿਸਟ, ਜਾਂ ਪ੍ਰੋਫਾਈਲ ਪੇਜ ਹਰ ਇਕ ਅਪਡେਟ ਲਈ ਸੈਂਕੜੇ ਵਾਰੀ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਅਸਮਾਨਤਾ ਸ਼ੁਰੂਆਤੀ ਸਕੇਲਿੰਗ ਫੈਸਲਿਆਂ ਨੂੰ ਆਕਾਰ ਦਿੰਦੀ: ਜੇ ਤੁਸੀਂ reads ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦੇ ਹੋ—ਜਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਡੇਟਾਬੇਸ ਤੱਕ ਨਹੀਂ ਜਾ ਕੇ—ਤਾਂ ਤੁਸੀਂ ਬਿਨਾ ਸਭ ਕੁਝ ਮੁੜ ਲਿਖਣ ਦੇ ਕਾਫ਼ੀ ਨਿਯਮਤ ਯੂਜ਼ਰ ਸਰਵ ਕਰ ਸਕਦੇ ਹੋ।
ਕੈਚ: ਭੀੜ-ਭਰੇ ਐਪਸ ਵੀ ਗੁੰਜਲਦਾਰ ਲਿਖਤਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਸਾਇਨ-ਅਪ, ਖਰੀਦ, ਟਿੱਪਣੀਆਂ, ਅਤੇ ਐਡਮਿਨ ਅਪਡੇਟ ਅਜੇ ਵੀ ਕਟਾਊ ਨਹੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ। ਜਦ ਟ੍ਰੈਫਿਕ ਵਧਦਾ ਹੈ, ਸਿਸਟਮ ਨੂੰ ਇਨ੍ਹਾਂ ਦੋਹਾਂ ਨੂੰ ਸਮੇਂ ਉਤੇ ਸੰਭਾਲਣਾ ਪੈਂਦਾ ਹੈ।
ਉੱਚ ਟ੍ਰੈਫਿਕ 'ਤੇ ਸਮੱਸਿਆਵਾਂ ਸਧਾਰਣ ਸ਼ਬਦਾਂ ਵਿੱਚ ਦਿਸਣ ਲੱਗਦੀਆਂ:
ਟੀਮਾਂ ਨੇ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਵੰਡਣਾ ਸਿੱਖਿਆ: ਐਪ business logic ਸੰਭਾਲਦਾ ਹੈ, ਇੱਕ ਕੈਸ਼ ਦੁਹਰਾਏ ਪੜ੍ਹਨ ਨੂੰ ਜੱਫਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਡੇਟਾਬੇਸ ਸਹੀ ਸਟੋਰੇਜ ਅਤੇ ਅਹੰਕਾਰੀ ਕੁਏਰੀਜ਼ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦਾ ਹੈ। ਇਹ ਮਾਨਸਿਕ ਮਾਡਲ query tuning, ਬਿਹਤਰ indexing, ਅਤੇ ਰੀਪਲਿਕਾਸ ਨਾਲ ਸਕੇਲ ਆਉਟ ਕਰਨ ਲਈ ਸੜਕ ਤਿਆਰ ਕਰਦਾ ਹੈ।
MySQL ਦੀ ਇੱਕ ਖਾਸ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹ ਥੱਲੇ ਇੱਕ “ਇੱਕ ਹੀ ਡੇਟਾਬੇਸ ਇੰਜਣ” ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਡੇਟਾਬੇਸ ਸਰਵਰ ਹੈ ਜੋ ਵੱਖ-ਵੱਖ storage engines ਦੇ ਨਾਲ ਡੇਟਾ ਸਟੋਰ ਅਤੇ ਰੀਟ੍ਰਾਈਵ ਕਰ ਸਕਦਾ ਹੈ।
ਉੱਚ ਪੱਧਰ 'ਤੇ, storage engine ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿਵੇਂ rows ਡਿਸਕ ਤੇ ਲਿਖੇ ਜਾਂਦੇ ਹਨ, ਇੰਡੈਕਸ ਕਿਵੇਂ ਰਖੇ ਜਾਂਦੇ ਹਨ, ਲਾਕ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਅਤੇ ਕ੍ਰੈਸ਼ ਤੋਂ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਡਾ SQL ਇੱਕੋ ਜਿਹਾ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ engine ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਤੇਜ਼ ਕਾਪੀ-ਕਿਤਾਬ ਵਰਗਾ ਹੈ ਜਾਂ ਬੈਂਕ ਲੇਜ਼ਰ ਵਰਗਾ।
ਕਾਫ਼ੀ ਸਮੇਂ ਲਈ ਬਹੁਤ ਸਾਰੇ MySQL ਸੈਟਅਪਾਂ ਨੇ MyISAM ਵਰਤਿਆ। ਇਹ ਸਧਾਰਨ ਅਤੇ ਪੜ੍ਹਨ-ਭਾਰ ਲਈ ਅਕਸਰ ਤੇਜ਼ ਸੀ, ਪਰ ਇਸਦੇ ਆਪਣੇ trade-offs ਸਨ:
InnoDB ਨੇ ਇਹ ਧਾਰਣਾ ਉਲਟ ਦਿੱਤੀ:
ਜਿਵੇਂ-ਜਿਵੇਂ ਵੈੱਬ ਐਪ ਲੋਡ-ਪੇਜ਼ ਤੋਂ ਲਾਗਇਨ, carts, payments ਅਤੇ messaging ਵੱਲ ਵੱਧੇ, ਸਹੀਪਣ ਅਤੇ recovery ਵੀ ਉੱਨੇ ਹੀ ਮਾਇਨੇ ਰੱਖਣ ਲੱਗੇ। InnoDB ਨੇ restart ਜਾਂ ਟ੍ਰੈਫਿਕ spike ਨਾਲ ਡੇਟਾ ਖਰਾਬ ਹੋਣ ਜਾਂ ਪੂਰੇ ਟੇਬਲ ਦੇ ਰੁਕਣ ਦੇ ਡਰ ਤੋਂ ਬਿਨਾਂ ਸਕੇਲ ਕਰਨਾ realistic ਬਣਾ ਦਿੱਤਾ।
ਪ੍ਰੈਕਟਿਕਲ ਨਤੀਜਾ: engine ਦੀ ਚੋਣ ਪ੍ਰਭਾਵ ਪਾਂਦੀ ਹੈ ਦੋਹਾਂ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਸੁਰੱਖਿਆ 'ਤੇ। ਇਹ ਸਿਰਫ਼ ਇੱਕ checkbox ਨਹੀਂ—ਤੁਹਾਡਾ ਲਾਕਿੰਗ ਮਾਡਲ, ਫੇਲਿਅਰ ਬਿਹੇਵਿਅਰ, ਅਤੇ ਐਪ ਦੀਆਂ ਗਾਰੰਟੀਜ਼ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ।
ਸ਼ਾਰਡਿੰਗ, ਰੀਡ ਰੀਪਲਿਕਾਸ, ਜਾਂ ਵਿਸਤਾਰਤ ਕੈਸ਼ਿੰਗ ਤੋਂ ਪਹਿਲਾਂ, ਬਹੁਤ ਸਾਰੀਆਂ ਸ਼ੁਰੂਆਤੀ MySQL ਜਿੱਤਾਂ ਇੱਕ ਸਧਾਰਨ ਬਦਲਾਅ ਤੋਂ ਆਈਆਂ: ਕੁਏਰੀਜ਼ ਨੂੰ predictable ਬਣਾਉਣਾ। ਇੰਡੈਕਸ ਅਤੇ ਕੁਏਰੀ ਡਿਜ਼ਾਈਨ ਪਹਿਲਾ "ਗੁਣਾ" ਸਨ ਕਿਉਂਕਿ ਉਹ ਪ੍ਰਤੀ ਬੇਨਤੀ MySQL ਨੂੰ ਛੁਹਣ ਵਾਲੇ ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਘਟਾ ਦਿੰਦੇ।
ਜ਼ਿਆਦਾਤਰ MySQL ਇੰਡੈਕਸ B-tree ਅਧਾਰਤ ਹੁੰਦੇ ਹਨ। ਇਹਨਾਂ ਨੂੰ ਇਕ ਕ੍ਰਮਬੱਧ ਡਾਇਰੈਕਟਰੀ ਵਜੋਂ ਸੋਚੋ: MySQL ਸਹੀ ਜਗ੍ਹਾ ਤੇ ਛਾਲ ਮਾਰ ਸਕਦਾ ਹੈ ਅਤੇ ਛੋਟਾ, ਲਗਾਤਾਰ ਸਲਾਈਸ ਪੜ੍ਹ ਸਕਦਾ ਹੈ। ਸਹੀ ਇੰਡੈਕਸ ਬਿਨਾਂ ਸਰਵਰ ਅਕਸਰ rows ਨੂੰ ਇੱਕ-ਇਕ ਕਰਕੇ ਸਕੈਨ ਕਰਨ ਲਈ fallback ਕਰਦਾ ਹੈ। ਘੱਟ ਟ੍ਰੈਫਿਕ 'ਤੇ ਇਹ ਸਿਰਫ਼ ਧੀਰਾ ਹੁੰਦਾ ਹੈ; ਸਕੇਲ 'ਤੇ ਇਹ CPU, ਡਿਸਕ I/O, ਲਾਕ ਸਮਾਂ ਅਤੇ ਸਭ ਕੁਝ ਲਈ ਉੱਚ ਲੇਟੈਂਸੀ ਵਧਾ ਦਿੰਦਾ ਹੈ।
ਕੁਝ ਪੈਟਰਨ ਮੁੜ-ਮੁੜ "staging ਵਿੱਚ ਚੱਲਿਆ" ਤੋਂ ਫੇਲ ਹੋਣ ਦਾ ਕਾਰਨ ਬਣੇ:
SELECT *: Unnecessary columns ਤਾਣਦਾ ਹੈ, I/O ਵਧਾਉਂਦਾ ਹੈ, ਅਤੇ covering-index ਲਾਭਾਂ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ।WHERE name LIKE '%shoe' ਆਮ B-tree ਇੰਡੈਕਸ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਵਰਤ ਨਹੀਂ ਸਕਦਾ।WHERE DATE(created_at) = '2025-01-01' ਅਕਸਰ ਇੰਡੈਕਸ ਦੇ ਵਰਤੇ ਜਾਣ ਨੂੰ ਰੋਕਦਾ ਹੈ; range ਫਿਲਟਰ ਵਰਤੋ ਜਿਵੇਂ created_at >= ... AND created_at < ...।EXPLAIN ਅਤੇ slow logs ਨੂੰ ਰੋਜ਼ਾਨਾ ਦੇ ਉਪਕਰਨ ਬਣਾਓਦੋ ਆਦਤਾਂ ਕਿਸੇ ਇੱਕ ਚਤੁਰ ਤਰਕੀਬ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਸਕੇਲ ਕਰਦੀਆਂ ਹਨ:
EXPLAIN ਤਾ ਜੋ ਤੁਸੀਂ ਪੱਕਾ ਕਰ ਸਕੋ ਕਿ ਤੁਸੀਂ ਇੱਛਿਤ ਇੰਡੈਕਸ ਵਰਤ ਰਹੇ ਹੋ ਅਤੇ ਸਕੈਨ ਨਹੀਂ ਕਰ ਰਹੇ।ਸਕੀਮਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਤਰੀਕਿਆਂ ਦੇ ਆਧਾਰ 'ਤੇ ਡਿਜ਼ਾਈਨ ਕਰੋ ਜਿਨ੍ਹਾਂ 'ਤੇ ਉਤਪਾਦ ਕੰਮ ਕਰਦਾ ਹੈ:
(user_id, created_at) ਵਰਗੇ composite indexes "ਤਾਜ਼ਾ ਆਈਟਮ" ਨੂੰ ਤੇਜ਼ ਬਣਾਉਂਦੇ ਹਨ।ਚੰਗੀ indexing "ਜ਼ਿਆਦਾ ਇੰਡੈਕਸ" ਨਹੀਂ ਹੈ। ਇਹ ਓਹੀ ਕੁਝ ਸਹੀ ਇੰਡੈਕਸ ਹਨ ਜੋ ਅਹੰਕਾਰਿਕ read/write paths ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ।
ਜਦੋਂ MySQL-ਆਧਾਰਿਤ ਉਤਪਾਦ धीਮਾ ਹੋਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਪਹਿਲਾ ਵੱਡਾ ਫੈਸਲਾ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਲਈ scale up (vertical) ਕਰਨਾ ਸਹੀ ਹੈ ਜਾਂ scale out (horizontal)। ਇਹ ਵੱਖ-ਵੱਖ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦੇ ਹਨ — ਅਤੇ ਤੁਹਾਡੇ ਓਪਰੇਸ਼ਨਲ ਜੀਵਨ ਨੂੰ ਬਹੁਤ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਬਦਲ ਦਿੰਦੇ ਹਨ।
ਵਰਟੀਕਲ ਸਕੇਲਿੰਗ ਮਤਲਬ ਹੈ MySQL ਨੂੰ ਇੱਕ ਮਸ਼ੀਨ 'ਤੇ ਵੱਧ ਸਰੋਤ ਦੇਣਾ: ਤੇਜ਼ CPU, ਵੱਧ RAM, ਬਿਹਤਰ ਸਟੋਰੇਜ।
ਅਕਸਰ ਇਹ ਹੈਰਾਨੀਜਨਕ ਰੂਪ ਨਾਲ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੀਆਂ ਬੋਟਲਨੇਕਸ ਲੋਕਲ ਹੁੰਦੀਆਂ ਹਨ:
ਵਰਟੀਕਲ ਸਕੇਲਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਨਤੀਜਾ ਦਿੰਦੀ ਹੈ: ਘੱਟ ਮੂਵਿੰਗ ਪਾਰਟ, ਸਧਾਰਣ failure ਮੋਡ, ਅਤੇ ਘੱਟ ਐਪਲੀਕੇਸ਼ਨ ਬਦਲਾਅ। ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਹਮੇਸ਼ਾ ਇੱਕ ਸੀਮਾ ਹੁੰਦੀ ਹੈ (ਅਤੇ upgrades downtime ਜਾਂ ਖਤਰਨਾਕ migrations ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ)।
ਹੋਰੀਜ਼ੌਂਟਲ ਸਕੇਲਿੰਗ ਮਸ਼ੀਨਾਂ ਵਧਾਉਂਦੀ ਹੈ। MySQL ਲਈ, ਇਸਦਾ ਅਰਥ ਆਮ ਤੌਰ 'ਤੇ ਹੈ:
ਇਹ ਔਖਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ coordination ਸਮੱਸਿਆਵਾਂ ਲਿਆਉਂਦੇ ਹੋ: replication lag, failover ਵਿਹਾਰ, consistency trade-offs, ਅਤੇ ਵਧੇਰੇ ਓਪਰੇਸ਼ਨਲ ਟੂਲਿੰਗ। ਤੁਹਾਡੀ ਐਪ ਵੀ ਜਾਣਨੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਕਿਸ ਸਰਵਰ ਨਾਲ ਗੱਲ ਕਰਨੀ ਹੈ (ਜਾਂ ਤੁਹਾਨੂੰ proxy ਤਹਿ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ)।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਲਈ ਸ਼ਾਰਡਿੰਗ ਪਹਿਲਾ ਕਦਮ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਪਹਿਲਾਂ ਇਹ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਮਾਂ ਕਿੱਥੇ ਲੱਗ ਰਿਹਾ ਹੈ (CPU vs I/O vs lock contention), slow queries ਅਤੇ ਇੰਡੈਕਸ ਫਿਕਸ ਕਰੋ, ਅਤੇ memory ਅਤੇ storage ਨੂੰ right-size ਕਰੋ। ਹੋਰੀਜ਼ੌਂਟਲ ਸਕੇਲਿੰਗ ਉਨ੍ਹਾਂ ਹਾਲਤਾਂ 'ਚ ਫਾਇਦਾ ਦਿੰਦੀ ਹੈ ਜਦ ਇੱਕ ਹੀ ਮਸ਼ੀਨ ਤੁਹਾਡੀ write rate, ਸਟੋਰੇਜ ਸਾਈਜ਼, ਜਾਂ availability ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦੀ — ਭਲਕੇ ਉਸ ਦੇ ਬਾਅਦ ਵੀ ਚੰਗੀ tuning ਤੋਂ ਬਾਅਦ।
ਰੀਪਲੀਕੇਸ਼ਨ ਇੱਕ ਸਭ ਤੋਂ ਪ੍ਰਯੋਗੀ ਤਰੀਕਾ ਸੀ ਜਿਹੜਾ MySQL ਸਿਸਟਮਾਂ ਨੇ ਵੱਧ ਦੇ ਨਾਲ ਨਿਭਾਉਣ ਲਈ ਵਰਤਿਆ: ਇੱਕ ਡੇਟਾਬੇਸ ਨੂੰ ਸਭ ਕੁਝ ਕਰਨ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਉਸਦਾ ਡਾਟਾ ਹੋਰ ਸਰਵਰਾਂ 'ਤੇ ਨਕਲ ਕਰ ਦੇਂਦੇ ਹੋ ਅਤੇ ਕੰਮ ਵੰਡ ਦਿੰਦੇ ਹੋ।
ਇਕ primary (ਕਈ ਵਾਰੀ "master" ਕਹਿੰਦੇ) ਉਹ ਡੇਟਾਬੇਸ ਹੁੰਦਾ ਹੈ ਜੋ ਚੇਂਜਜ਼ ਸਵੀਕਾਰ ਕਰਦਾ—INSERTs, UPDATEs, DELETEs। ਇੱਕ ਜਾਂ ਵੱਧ ਰੀਪਲਿਕਾਸ (ਪਹਿਲਾਂ "slaves") ਲਗਾਤਾਰ ਉਹਨਾਂ ਚੇਂਜਜ਼ ਨੂੰ ਖਿੱਚਦੇ ਅਤੇ ਲਾਗੂ ਕਰਦੇ ਹਨ, ਅਤੇ near-real-time copy ਰੱਖਦੇ ਹਨ।
ਤੁਹਾਡੀ ਐਪ ਫਿਰ:
ਇਹ ਪੈਟਰਨ ਆਮ ਹੋ ਗਿਆ ਕਿਉਂਕਿ ਵੈੱਬ ਟ੍ਰੈਫਿਕ ਅਕਸਰ read-heavy ਤੇਜ਼ੀ ਨਾਲ ਵਧਦਾ ਹੈ ਬਨਾਮ write-heavy।
ਰੀਡ ਰੀਪਲਿਕਾਸ ਸਿਰਫ਼ ਪੇਜ ਵਿਊਜ਼ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਲਈ ਨਹੀਂ ਸਨ। ਉਹ ਉਹ ਕੰਮ ਵੀ ਅਲੱਗ ਕਰਦੇ ਜੋ ਮੁੱਖ ਡੇਟਾਬੇਸ ਨੂੰ ਸਲੋ ਕਰਦੇ:
ਰੀਪਲੀਕੇਸ਼ਨ ਮੁਫ਼ਤ ਖਾਣਾ ਨਹੀਂ ਹੈ। ਸਭ ਤੋਂ ਆਮ ਮੁੱਦਾ replication lag ਹੈ—ਰੀਪਲਿਕਾਸ spikes ਦੌਰਾਨ ਸਕਿੰਟਾਂ (ਜਾਂ ਹੋਰ) ਪਿੱਛੇ ਰਹਿ ਸਕਦੇ ਹਨ।
ਇਸ ਨਾਲ ਐਪ-ਪੱਧਰੀ ਸਵਾਲ ਉਤਪੰਨ ਹੁੰਦਾ ਹੈ: read-your-writes consistency। ਜੇ ਇੱਕ ਯੂਜ਼ਰ ਪ੍ਰੋਫਾਈਲ ਅਪਡੇਟ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਤੁਰੰਤ ਰੀਪਲਿਕਾ ਤੋਂ ਪੜ੍ਹਦੇ ਹੋ, ਉਹ ਪੁਰਾਣਾ ਡਾਟਾ ਵੇਖ ਸਕਦਾ ਹੈ। ਬਹੁਤ ਟੀਮਾਂ ਇਸ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ write ਤੋਂ ਬਾਅਦ fresh views ਲਈ primary ਤੋਂ ਪੜ੍ਹਦੇ ਹਨ, ਜਾਂ ਛੋਟਾ "write ਤੋਂ ਬਾਅਦ primary ਤੋਂ ਪੜ੍ਹੋ" ਖਿੜਕੀ ਵਰਤਦੇ ਹਨ।
ਰੀਪਲੀਕੇਸ਼ਨ ਡੇਟਾ ਨੂੰ ਨਕਲ ਕਰਦਾ ਹੈ; ਇਹ ਤੁਹਾਨੂੰ ਫੇਲਅਰ ਦੌਰਾਨ ਆਪਣੇ آپਨੋ ਚਾਲੂ ਰੱਖਣ ਦਾ ਆਟੋਮੈਟਿਕ ਤਰੀਕਾ ਨਹੀਂ ਦਿੰਦਾ। Failover—ਇੱਕ ਰੀਪਲਿਕਾ ਨੂੰ promote ਕਰਨਾ, ਟ੍ਰੈਫਿਕ redirect ਕਰਨਾ, ਅਤੇ ਐਪ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ reconnect ਕਰਵਾਉਣਾ—ਇੱਕ ਵੱਖਰੀ ਸਮਰੱਥਾ ਹੈ ਜਿਸ ਲਈ ਟੂਲਿੰਗ, ਟੈਸਟਿੰਗ ਅਤੇ ਸਪੱਸ਼ਟ ਓਪਰੇਸ਼ਨਲ ਪ੍ਰਕਰੀਆਵਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
High availability (HA) ਉਹ ਅਭਿਆਸ ਹਨ ਜੋ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਚਲਾਉਂਦੇ ਰੱਖਣ ਲਈ ਡੇਟਾਬੇਸ ਸਰਵਰ ਦੇ ਕ੍ਰੈਸ਼, ਨੈੱਟਵਰਕ ਡਰਪ ਜਾਂ ਰਖ-ਰਖਾਅ ਦੌਰਾਨ। ਲਕੜੀ ਦੇ ਟੀਚੇ ਸਧਾਰਣ ਹਨ: downtime ਘਟਾਉਣਾ, maintenance ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਣਾ, ਅਤੇ recovery predictable ਬਣਾਉਣਾ ਨਾ ਕਿ improvisation।
ਸ਼ੁਰੂਆਤੀ MySQL deployments ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਡੇਟਾਬੇਸ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ। HA ਆਮ ਤੌਰ 'ਤੇ ਦੂਜੀ ਮਸ਼ੀਨ ਜੋੜ ਕੇ ਸ਼ੁਰੂ ਹੁੰਦੀ ਤਾਂ ਕਿ ਫੇਲਯੁਰ ਲੰਬਾ outage ਨਾ ਬਣੇ।
ਆਟੋਮੇਸ਼ਨ ਮਦਦ ਕਰਦੀ ਹੈ, ਪਰ ਇਹ ਵੀ ਸਥਰ ਉੱਚਾ ਕਰਦੀ ਹੈ: ਤੁਹਾਡੇ ਟੀਮ ਨੂੰ detection logic 'ਤੇ ਭਰੋਸਾ ਹੋਣਾ ਚਾਹੀਦਾ ਅਤੇ "split brain" (ਦੋ ਸਰਵਰ ਆਪੋ-ਆਪਣੇ ਆਪ ਨੂੰ primary ਸਮਝਣ) ਤੋਂ ਬਚਾਉਣਾ ਚਾਹੀਦਾ।
ਦੋ ਮੈਟ੍ਰਿਕਸ HA ਫੈਸਲਿਆਂ ਨੂੰ ਘੱਟ ਭਾਵੁਕ ਅਤੇ ਜ਼ਿਆਦਾ ਮਾਪਣ ਯੋਗ ਬਣਾਉਂਦੀ:
HA ਸਿਰਫ਼ topology ਨਹੀਂ—ਇਹ ਅਭਿਆਸ ਵੀ ਹੈ।
ਬੈਕਅੱਪ ਰੂਟੀਨ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਪਰ ਮੁੱਖ ਗੱਲ restore tests ਹੈ: ਕੀ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਇੱਕ ਨਵੇਂ ਸਰਵਰ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ recover ਕਰ ਸਕਦੇ ਹੋ, ਦਬਾਅ 'ਤੇ?
ਸਕੀਮਾ ਬਦਲਾਅ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਵੱਡੇ ਟੇਬਲ alterations ਲਿਖਤਾਂ ਨੂੰ ਲਾਕ ਕਰ ਸਕਦੇ ਹਨ ਜਾਂ ਕੁਏਰੀਜ਼ ਨੂੰ ਸਲੋ ਕਰ ਸਕਦੇ ਹਨ। ਸੁਰੱਖਿਅਤ approaches ਵਿੱਚ low-traffic windows ਦੌਰਾਨ changes ਕਰਨਾ, online schema change tools ਦੀ ਵਰਤੋਂ ਅਤੇ ਹਮੇਸ਼ਾ rollback ਯੋਜਨਾ ਰੱਖਣਾ ਸ਼ਾਮਿਲ ਹੈ।
ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੀਤਾ ਹੋਇਆ HA ਫੇਲਯੁਰਾਂ ਨੂੰ emergencies ਤੋਂ planned, rehearse ਕੀਤੇ ਘਟਨਾਵਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਕੈਸ਼ਿੰਗ ਇੱਕ ਸਭ ਤੋਂ ਸਿੱਧਾ ਤਰੀਕਾ ਸੀ ਜਿਸ ਨਾਲ ਸ਼ੁਰੂਆਤੀ ਵੈੱਬ ਟੀਮਾਂ MySQL ਨੂੰ ਜ਼ਿਆਦਾ ਟ੍ਰੈਫਿਕ 'ਤੇ responsive ਰੱਖਦੀਆਂ। ਵਿਚਾਰ ਸਧਾਰਨ ਹੈ: ਵਾਰ-ਵਾਰ ਆਉਂਦੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ डੇਟਾਬੇਸ ਦੇ ਬਜਾਏ ਕੁਝ ਤੇਜ਼ ਚੀਜ਼ ਤੋਂ ਸੇਵ ਕਰੋ, ਅਤੇ ਸਿਰਫ਼ ਜਦ ਲੋੜ ਹੋਵੇ ਡੇਟਾਬੇਸ ਨੂੰ ਛੇੜੋ। ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ ਹੋਏ, ਕੈਸ਼ read load ਨੂੰ ਡਰਾਮੈਟਿਕ ਤੌਰ 'ਤੇ ਘਟਾ ਦਿੰਦਾ ਅਤੇ ਅਚਾਨਕ spikes ਨੂੰ ਨਰਮ ਰੈਂਪ ਵਰਗਾ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ।
ਐਪਲੀਕੇਸ਼ਨ/ਓਬਜੈਕਟ ਕੈਸ਼ ਉਹ "ਟੁਕੜੇ" ਡੇਟਾ ਸਟੋਰ ਕਰਦਾ ਜੋ ਤੁਹਾਡੀ ਕੋਡ ਅਕਸਰ ਮੰਗਦੀ ਹੈ—ਯੂਜ਼ਰ ਪ੍ਰੋਫਾਈਲ, ਉਤਪਾਦ ਵੇਰਵੇ, permission checks। ਬਜਾਏ ਇਸਦੇ ਕਿ ਇਕੋ SELECT ਨੂੰ ਸੈਂਕੜੇ ਵਾਰੀ ਚਲਾਉਣਾ, ਐਪ ਪਹਿਲਾਂ ਤੋਂ ਤਿਆਰ ਕੀਤੇ ਓਬਜੈਕਟ ਨੂੰ key ਨਾਲ ਪੜ੍ਹਦਾ।
ਪੇਜ਼ ਜਾਂ ਫ਼ਰੈਗਮੈਂਟ ਕੈਸ਼ rendered HTML (ਪੂਰੇ ਪੇਜ ਜਾਂ ਹਿੱਸੇ, ਜਿਵੇਂ sidebar) ਸਟੋਰ ਕਰਦਾ ਹੈ। ਇਹ ਖਾਸ ਤੌਰ 'ਤੇ content-heavy ਸਾਈਟਾਂ ਲਈ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ ਜਿੱਥੇ ਬਹੁਤ ਸਾਰੇ ਵਿਜ਼ਟਰ ਇਕੋ ਪੇਜ ਦੇਖਦੇ ਹਨ।
ਕੁਏਰੀ ਨਤੀਜੇ ਕੈਸ਼ ਕਿਸੇ ਨਿਰਧਾਰਤ ਕੁਏਰੀ ਦਾ ਨਤੀਜਾ ਰੱਖਦਾ ਹੈ (ਜਾਂ ਉਸਦਾ ਨਾਰਮਲਾਈਜ਼ਡ ਵਰਜ਼ਨ)। ਜੇ ਤਾਂ ਤੁਸੀਂ SQL-ਸਤਰ ਤੇ ਕੈਸ਼ ਨਹੀਂ ਕਰਦੇ, ਤੁਸੀਂ "ਇਸ endpoint ਦਾ ਨਤੀਜਾ" ਇੱਕ key ਨਾਲ ਕੈਸ਼ ਕਰ ਸਕਦੇ ਹੋ।
ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਟੀਮਾਂ in-memory key/value stores, HTTP caches, ਜਾਂ ਐਪ ਫਰੇਮਵਰਕ ਵਿੱਚ ਬਿਲਟ-ਇਨ ਕੈਸ਼ ਵਰਤਦੀਆਂ ਹਨ। ਅਸਲ ਟੂਲ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ consistent keys, TTLs (expiration), ਅਤੇ ਸਪੱਸ਼ਟ ownership ਹਨ।
ਕੈਸ਼ਿੰਗ ਤਾਜ਼ਗੀ ਲਈ ਤੇਜ਼ੀ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਕੁਝ ਡੇਟਾ ਹਲਕਾ stale ਹੋ ਸਕਦਾ (ਖ਼ਬਰਾਂ, view counts). ਹੋਰ ਡੇਟਾ ਨਹੀਂ ਹੋ ਸਕਦਾ (checkout totals, permissions). ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਚੁਣਦੇ ਹੋ:
ਜੇ invalidation ਫੇਲ ਹੋ ਜਾਵੇ, ਯੂਜ਼ਰ outdated ਕੰਟੈਂਟ ਵੇਖ ਸਕਦੇ ਹਨ। ਜੇ ਇਹ ਬਹੁਤ aggressive ਹੋਵੇ, ਤੁਹਾਡੀ ਕੈਸ਼ ਦਾ ਲਾਭ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ MySQL ਫਿਰ ਮੁੜ ਸੀਧਾ ਭਾਰੀ ਹੋ ਜਾਂਦਾ ਹੈ।
ਜਦ ਟ੍ਰੈਫਿਕ surge ਕਰਦਾ ਹੈ, ਕੈਸ਼ ਦੁਹਰਾਏ ਪੜ੍ਹਨ ਨੂੰ ਅਬਜ਼ੋਰਬ ਕਰਦਾ ਹੈ ਜਦਕਿ MySQL "ਅਸਲੀ ਕੰਮ" (ਲਿਖਤਾਂ, cache misses, ਜਟਿਲ ਕੁਏਰੀਆਂ) 'ਤੇ ਧਿਆਨ ਦਿੰਦਾ ਹੈ। ਇਸ ਨਾਲ queueing ਘਟਦਾ, slowdowns cascade ਨਹੀਂ ਹੁੰਦੇ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸਕੇਲ ਕਰਨ ਲਈ ਸਮਾਂ ਮਿਲਦਾ ਹੈ।
ਇੱਕ ਸਮਾਂ ਆਉਂਦਾ ਹੈ ਜਦ "ਵੱਡਾ ਹਾਰਡਵੇਅਰ" ਅਤੇ ਸੰਭਾਲੀ ਕੁਏਰੀ ਟਿਊਨਿੰਗ ਵੀ ਤੁਹਾਨੂੰ ਹੋਰ ਥਾਂ ਨਹੀਂ ਲਾਉਂਦੀ। ਜੇ ਇੱਕ ਹੀ MySQL ਸਰਵਰ write volume, dataset size, ਜਾਂ maintenance windows ਨੂੰ ਪੂਰਣ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ ਤੁਸੀਂ ਡਾਟਾ ਨੂੰ ਵੰਡਣ ਬਾਰੇ ਸੋਚਦੇ ਹੋ।
Partitioning ਇੱਕ ਸਰਵੇਂ ਵਿੱਚ ਇੱਕ ਟੇਬਲ ਨੂੰ ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ (ਉਦਾਹਰਣ ਲਈ, date ਨਾਲ). ਇਹ deletes, archiving, ਅਤੇ ਕੁਝ ਕੁਏਰੀਜ਼ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਉਸੇ ਸਰਵਰ ਦੇ CPU, RAM ਅਤੇ I/O ਸੀਮਾਵਾਂ ਨੂੰ ਵੱਧ ਨਹੀਂ ਕਰਦਾ।
Sharding ਡਾਟਾ ਨੂੰ ਕਈ MySQL ਸਰਵਰਾਂ 'ਤੇ ਵੰਡਦਾ ਹੈ। ਹਰ ਸ਼ਾਰਡ ਇੱਕ ਉਪਸੈਟ ਰਿਕਾਰਡ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੀ ਐਪ (ਜਾਂ routing layer) ਫ਼ੈਸਲਾ ਕਰਦੀ ਹੈ ਕਿ ਹਰ ਬੇਨਤੀ ਕਿੱਥੇ ਜਾਵੇ।
ਸ਼ਾਰਡਿੰਗ ਅਕਸਰ ਉਹਨਾਂ ਹਾਲਤਾਂ 'ਚ ਆਉਂਦੀ ਹੈ ਜਦ:
ਠੀਕ shard key ਟ੍ਰੈਫਿਕ ਨੂੰ ਬਰਾਬਰ ਵੰਡਦਾ ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਬੇਨਤੀਆਂ ਨੂੰ ਇੱਕ ਹੀ ਸ਼ਾਰਡ 'ਤੇ ਰੱਖਦਾ:
ਸ਼ਾਰਡਿੰਗ ਸੌਖਿਆ ਨੂੰ ਸਕੇਲ ਨਾਲ ਬਦਲਦੀ ਹੈ:
ਪਹਿਲਾਂ ਕੈਸ਼ਿੰਗ ਅਤੇ ਰੀਡ ਰੀਪਲਿਕਾਸ ਨਾਲ primary ਤੋਂ ਦਬਾਅ ਹਟਾਓ। ਫਿਰ, ਸਭ ਤੋਂ ਭਾਰੀ ਟੇਬਲਾਂ ਜਾਂ ਵਰਕਲੋਡ ਨੂੰ ਅਲੱਗ ਕਰੋ (ਕਈ ਵਾਰ feature ਜਾਂ service ਵਾਰ). ਫਿਰ ਹੀ ਸ਼ਾਰਡਿੰਗ ਵੱਲ ਜਾਓ—ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਐੱਡ ਸ਼ਾਰਡਾਂ ਨੂੰ ਕ੍ਰਮਵਾਰ ਜੋੜ ਸਕੋ ਬਿਨਾਂ ਸਭ ਕੁਝ ਇੱਕ ਵਾਰ ਵਿੱਚ redesign ਕਰਨ ਦੇ।
ਇੱਕ ਐਕਟੀਵ ਪ੍ਰੋਡਕਟ ਲਈ MySQL ਚਲਾਉਣਾ clever features ਤੋਂ ਘੱਟ ਅਤੇ ਦਿਸ਼ਾ ਨਿਰਦੇਸ਼ ਓਪਰੇਸ਼ਨ ਤੋਂ ਜ਼ਿਆਦਾ ਹੁੰਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ outage ਡਰਾਮੇਟਿਕ ਫੇਲ੍ਹਤੋਂ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦੇ—ਉਹ ਉਹਨਾਂ ਛੋਟੇ ਸਿਗਨਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ ਜੋ ਕਿਸੇ ਨੇ ਸਮੇਂ 'ਤੇ ਨਹੀਂ ਜੋੜੇ।
ਸਕੇਲ 'ਤੇ, "ਵੱਡੇ ਚਾਰ" ਸੰਕੇਤ ਅਕਸਰ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਮੁਸੀਬਤ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਦੇ ਹਨ:
ਚੰਗੀਆਂ ਡੈਸ਼ਬੋਰਡਸ context ਜੋੜਦੀਆਂ ਹਨ: ਟ੍ਰੈਫਿਕ, ਐਰਰ ਰੇਟ, connection counts, buffer pool hit rate, ਅਤੇ top queries। ਮਕਸਦ ਬਦਲਾਅ ਨੂੰ ਪਛਾਣਣਾ ਹੈ—"ਨਾਰਮਲ" ਦੀ ਯਾਦ ਨਹੀਂ ਰੱਖਣਾ।
ਕਈ ਕੁਏਰੀਜ਼ staging ਵਿੱਚ ਅਤੇ ਅਰਾਮਦਾਇਕ ਸਮਿਆਂ ਵਿੱਚ production ਵਿੱਚ ਠੀਕ ਲੱਗਦੀਆਂ ਹਨ। ਲੋਡ ਹੇਠਾਂ, ਡੇਟਾਬੇਸ ਵੱਖਰਾ ਵਿਹਾਰ ਕਰਦਾ ਹੈ: caches ਮਦਦ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੀਆਂ, concurrent requests lock contention ਨੂੰ ਤੇਜ਼ ਕਰਦੇ, ਅਤੇ ਥੋੜੀ ਜਾਂ ਇਨਫਿਟੀ ਕੁਏਰੀ ਹੋਰ reads, ਵੱਧ temporary tables, ਜਾਂ ਵੱਡੀ sort ਕੰਮ ਕਰਵਾ ਸਕਦੀ ਹੈ।
ਇਸੇ ਲਈ ਟੀਮਾਂ rely ਕਰਦੀਆਂ ਹਨ slow query log, query digests, ਅਤੇ production histograms 'ਤੇ ਬਜ਼ਾਇ ਇੱਕ-ਦਫ਼ਾ benchmarks।
ਸੁਰੱਖਿਅਤ change practices ਜਾਣ-ਪਛਾਣ ਵਾਲੀਆਂ ਹਨ: migrations ਛੋਟੇ ਬੈਚਾਂ ਵਿੱਚ ਚਲਾਉ, minimal locking ਨਾਲ indexes ਜੋੜੋ ਜਦ ਸੰਭਵ ਹੋਵੇ, explain plans ਨਾਲ ਝਾਂਕੋ, ਅਤੇ rollbacks realistic ਰੱਖੋ (ਕਈ ਵਾਰੀ rollback "rollout ਰੋਕਣਾ ਅਤੇ fail over" ਹੁੰਦਾ)। Changes measureable ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ: before/after latency, lock waits, ਅਤੇ replication lag।
ਇਕ incident ਦੌਰਾਨ: ਪ੍ਰਭਾਵ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, top offender (ਇਕ ਕੁਏਰੀ, ਇੱਕ ਹੋਸਟ, ਇੱਕ ਟੇਬਲ) ਦੀ ਪਛਾਣ ਕਰੋ, ਫਿਰ mitigate—ਟ੍ਰੈਫਿਕ throttle ਕਰੋ, runaway queries kill ਕਰੋ, ਇੱਕ ਅਸਥਾਈ ਇੰਡੈਕਸ ਜੋੜੋ, ਜਾਂ reads/writes shift ਕਰੋ।
ਬਾਅਦ ਵਿੱਚ, ਜੋ ਕੁਝ ਹੋਇਆ ਉਸਨੂੰ ਲਿਖੋ, early signals ਲਈ alerts ਜੋੜੋ, ਅਤੇ fix ਨੂੰ repeatable ਬਣਾਓ ਤਾਂ ਕਿ ਉਹੀ ਫੇਲਯੁਰ ਹਫ਼ਤੇ ਬਾਅਦ ਵਾਪਿਸ ਨਾ ਆਵੇ।
MySQL ਅਜੇ ਵੀ ਬਹੁਤ ਸਾਰੀਆਂ ਆਧੁਨਿਕ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮਾਂ ਲਈ ਡੀਫਾਲਟ ਚੋਣ ਹੈ ਕਿਉਂਕਿ ਇਹ ਰੋਜ਼ਾਨਾ ਐਪਲੀਕੇਸ਼ਨ ਡੇਟਾ ਦੀ ਸ਼ਕਲ ਨਾਲ ਮਿਲਦਾ ਹੈ: ਛੋਟੇ reads ਅਤੇ writes ਦੀ ਬਹੁਤਾਤ, ਸਪਸ਼ਟ transactional ਸੀਮਾਵਾਂ, ਅਤੇ predictable ਕੁਏਰੀਜ਼। ਇਸੀ ਲਈ ਇਹ ਅਜੇ ਵੀ OLTP-ਭਾਰ ਵਾਲੇ ਉਤਪਾਦਾਂ ਲਈ ਵਧੀਆ ਹੈ—SaaS ਐਪ, e-commerce, ਮਾਰਕੀਟਪਲੇਸ ਅਤੇ multi-tenant ਪਲੈਟਫਾਰਮ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ ਡੇਟਾ ਨੂੰ ਅਸਲ ਕਾਰੋਬਾਰੀ ਇਕਾਈਆਂ ਦੇ ਆਧਾਰ 'ਤੇ ਮਾਡਲ ਕਰਦੇ ਹੋ ਅਤੇ transactions focused ਰੱਖਦੇ ਹੋ।
ਅੱਜ ਦਾ MySQL ecosystem ਸਾਲਾਂ ਦੀਆਂ ਸਖਤ ਸਿੱਖਿਆਵਾਂ ਨੂੰ ਬਿਹਤਰ defaults ਅਤੇ ਸੁਰੱਖਿਅਤ ਓਪਰੇਸ਼ਨਲ ਅਭਿਆਸਾਂ ਵਿੱਚ ਉਸਾਰ ਚੁੱਕਿਆ ਹੈ। ਅਮਲ ਵਿੱਚ, ਟੀਮਾਂ ਇਨ੍ਹਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ:
ਹੁਣ ਬਹੁਤ ਕੰਪਨੀਆਂ MySQL ਨੂੰ managed services ਰਾਹੀਂ ਚਲਾਉਂਦੀਆਂ ਹਨ, ਜਿੱਥੇ ਪ੍ਰੋਵਾਈਡਰ ਰੋਟੀਨੀ ਕੰਮ—patching, automated backups, encryption, point-in-time recovery, ਅਤੇ ਆਮ ਸਕੇਲਿੰਗ ਕਦਮ (ਵੱਡੇ instances, read replicas, storage growth)—ਸੰਭਾਲਦਾ ਹੈ। ਤੁਸੀਂ ਅਜੇ ਵੀ ਆਪਣਾ ਸਕੀਮਾ, ਕੁਏਰੀਜ਼, ਅਤੇ ਡੇਟਾ access patterns ਦੇ ਮਾਲਕ ਹੋ—ਪਰ ਤੁਸੀਂ maintenance windows ਅਤੇ recovery drills 'ਤੇ ਘੱਟ ਸਮਾਂ خرچ ਕਰਦੇ ਹੋ।
ਇੱਕ ਕਾਰਨ ਜੋ "MySQL ਸਕੇਲਿੰਗ playbook" ਅਜੇ ਵੀ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਇਹ ਹੈ ਕਿ ਅਕਸਰ ਇਹ ਸਿਰਫ਼ ਡੇਟਾਬੇਸ ਸਮੱਸਿਆ ਨਹੀਂ—ਇਹ ਇੱਕ ਐਪ ਆਰਕੀਟੈਕਚਰ ਦੀ ਸਮੱਸਿਆ ਹੈ। read/write separation, cache keys ਅਤੇ invalidation, ਸੁਰੱਖਿਅਤ migrations, ਅਤੇ rollback ਯੋਜਨਾਵਾਂ ਵਰਗੇ ਚੋਣਾਂ ਸਭ ਤੋਂ ਵਧੀਆ ਤਦ ਹੀ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਪ੍ਰੋਡਕਟ ਦੇ ਨਾਲ ਮਿਲ ਕੇ ਡਿਜ਼ਾਈਨ ਕੀਤੀਆਂ ਜਾਣ, ਨਾ ਕਿ incidents ਦੇ ਦੌਰਾਨ ਬਿਨਾਂ ਸੋਚੇ-ਸਮਝੇ ਜੋੜੀਆਂ ਜਾਣ।
ਜੇ ਤੁਸੀਂ ਨਵੇਂ ਸੇਵਾਵਾਂ ਬਣਾ ਰਹੇ ਹੋ ਅਤੇ ਇਹ ਫੈਸਲੇ ਸ਼ੁਰੂ ਤੋਂ encode ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਇੱਕ vibe-coding workflow ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ, Koder.ai ਇੱਕ ਸਧਾਰਨ-ਭਾਸ਼ਾ ਵਿਸ਼ੇਸ਼ (entities, ਟ੍ਰੈਫਿਕ ਉਮੀਦਾਂ, consistency ਲੋੜਾਂ) ਲੈ ਸਕਦਾ ਹੈ ਅਤੇ React वेब ਅਤੇ Go ਸੇਵਾਵਾਂ ਵਾਲਾ ਐਪ scaffold ਸਹਾਇਤਾ ਨਾਲ ਤਿਆਰ ਕਰਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ—ਉਸਦੇ Planning Mode, snapshots, ਅਤੇ rollback ਖਾਸ ਕਰਕੇ ਸਕੀਮਾ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਬਦਲਾਅ ਉੱਤੇ iterate ਕਰਦਿਆਂ ਉੱਚ-ਖਤਰੇ ਵਾਲੇ ਮਾਮਲਿਆਂ ਨੂੰ ਘੱਟ ਕਰਨ ਲਈ ਕਾਰਗਰ ਹਨ।
ਜੇ ਤੁਸੀਂ Koder.ai ਦੀਆਂ ਟੀਅਰਾਂ (Free, Pro, Business, Enterprise) ਬਾਰੇ ਵੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ /pricing ਦੇਖੋ।
MySQL ਚੁਣੋ ਜਦੋਂ ਤੁਹਾਨੂੰ ਲੋੜ ਹੋਵੇ: ਮਜ਼ਬੂਤ transactions, relational ਮਾਡਲ, ਪੱਕੇ ਟੂਲਿੰਗ, predictable ਪ੍ਰਦਰਸ਼ਨ, ਅਤੇ ਵੱਡੀ hiring ਪੂਲ।
ਜਦੋਂ ਤੁਹਾਨੂੰ ਚੁਣੋ alternatives: massive write fan-out ਨਾਲ ਲਚਕੀਲੇ schemas (ਕੁਝ NoSQL ਸਿਸਟਮ), ਗਲੋਬਲੀ consistent multi-region writes (ਖਾਸ distributed ਡੇਟਾਬੇਸ), ਜਾਂ analytics-ਪ੍ਰਧਾਨ ਵਰਕਲੋਡ (columnar warehouses) ਦੀ ਲੋੜ ਹੋਵੇ।
ਪ੍ਰੈਕਟਿਕਲ ਨਤੀਜਾ: latency, consistency, data model, growth rate, ਟੀਮ ਦੀਆਂ ਕਿਸਮਤੀਆਂ ਦੇ ਮਤਲਬਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਸਭ ਤੋਂ ਸਧਾਰਨ ਸਿਸਟਮ ਚੁਣੋ ਜੋ ਉਹਨਾਂ ਨੂੰ ਪੂਰਾ ਕਰੇ—ਅਤੇ ਅਕਸਰ MySQL ਫਿਰ ਵੀ ਕਰ ਲੈਂਦਾ ਹੈ।
MySQL ਸ਼ੁਰੂਆਤੀ ਵੈੱਬਸਾਈਟਾਂ ਲਈ ਇੱਕ ਵਰਤਣ ਯੋਗ ਚੋਣ ਸੀ: ਇੰਸਟਾਲ ਕਰਨਾ ਤੇਜ਼, ਆਮ ਭਾਸ਼ਾਵਾਂ ਤੋਂ ਕਨੈਕਟ ਹੋਣਾ ਆਸਾਨ, ਅਤੇ ਨਿਰਧਾਰਤ ਹਾਰਡਵੇਅਰ 'ਤੇ “ਕਾਫ਼ੀ ਚੰਗਾ” ਪ੍ਰਦਰਸ਼ਨ। ਖੁੱਲ੍ਹਾ-ਸਰੋਤ ਹੋਣ ਅਤੇ LAMP ਸਟੈਕ ਦੀ ਵਿਸ਼ਵਵਿਆਪੀਤਾ ਨਾਲ, ਇਹ ਬਹੁਤ ਸਾਰੀਆਂ ਛੋਟੀਆਂ ਟੀਮਾਂ ਅਤੇ ਵੱਧ ਰਹੀਆਂ ਸਾਈਟਾਂ ਲਈ ਡੀਫਾਲਟ ਡੇਟਾਬੇਸ ਬਣ ਗਿਆ।
ਇਥੇ “ਸਕੇਲ” ਆਮ ਤੌਰ 'ਤੇ ਮਤਲਬ ਹੈ:
ਇਹ ਸਿਰਫ਼ ਕੱਚੀ ਸਪੀਡ ਨਹੀਂ — ਇਹ ਅਸਲ ਵਰਕਲੋਡ ਹੇਠਾਂ ਭਰੋਸੇਯੋਗ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ uptime ਹੈ।
LAMP ਨੇ ਡਿਪਲੋਇਮੈਂਟ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਇਆ: ਇੱਕ ਹੀ Linux ਮਸ਼ੀਨ ਉੱਤੇ Apache + PHP + MySQL ਸਸਤੇ ਵਿੱਚ ਚੱਲ ਸਕਦੇ ਸਨ, ਅਤੇ ਹੋਸਟਿੰਗ ਪ੍ਰੋਵਾਈਡਰ ਇਸਨੂੰ ਸਟੈਂਡਰਡ ਕਰ ਸਕਦੇ ਸਨ। ਇਸ ਲਗਾਤਾਰਤਾ ਨੇ ਲੋਕਾਂ ਨੂੰ ਆਪਣੀ ਕੋਡ ਨੂੰ local ਤੋਂ production ਵਿੱਚ ਲਿਜਾਣ ਵਿੱਚ ਘੱਟ ਰੁਕਾਵਟ ਦਿੱਤੀ ਅਤੇ MySQL ਨੂੰ ਇੱਕ "ਉਪਲਬਧ ਡੀਫਾਲਟ" ਡੇਟਾਬੇਸ ਬਣਾਇਆ।
ਸ਼ੁਰੂਆਤੀ ਵੈੱਬ ਵਰਕਲੋਡ ਆਮ ਤੌਰ 'ਤੇ ਪਾਠ-ਭਾਰ ਵਾਲੇ ਅਤੇ ਸਾਦੇ ਹੁੰਦੇ ਸਨ: ਉਪਭੋਗਤਾ ਖਾਤੇ, ਨਵੀਂਆਂ ਪੋਸਟਾਂ, ਉਤਪਾਦ ਸੂਚੀਆਂ, ਅਤੇ ਆਮ ਫਿਲਟਰਿੰਗ। MySQL ਮੁੱਖ-ਕੁੰਜੀ ਲੁੱਕਅੱਪਸ ਅਤੇ "ਤਾਜ਼ਾ ਆਈਟਮ" ਵਰਗੀਆਂ ਆਮ ਪੈਟਰਨਾਂ ਲਈ ਚੰਗਾ ਪ੍ਰਦਰਸ਼ਨ ਦਿੰਦਾ ਸੀ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ indexes ਪਹੁੰਚ ਪੈਟਰਨਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਸਨ।
ਆਮ ਸ਼ੁਰੂਆਤੀ ਸਮੱਸਿਆਵਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਸਨ:
ਇਹ ਸਮੱਸਿਆਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਸਿਰਫ਼ ਟ੍ਰੈਫਿਕ ਵਧਣ 'ਤੇ ਨਜ਼ਰ ਆਉਂਦੀਆਂ ਹਨ, ਜਿਥੇ “ਛੋਟੀ-ਮੁਟੀਆ ਅਕੁਰੇਟੀਆਂ” ਵੱਡੇ latency spikes ਬਣ ਜਾਂਦੀਆਂ ਹਨ।
ਇੱਕ storage engine ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ rows ਨੂੰ ਡਿਸਕ 'ਤੇ ਕਿਵੇਂ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ, ਇੰਡੈਕਸ ਕਿਵੇਂ ਸੰਭਾਲੇ ਜਾਂਦੇ ਹਨ, ਤੇ ਲਾਕਿੰਗ ਅਤੇ ਕ੍ਰੈਸ਼ ਤੋਂ ਬਾਅਦ recovery ਕਿਵੇਂ ਹੁੰਦੀ ਹੈ। ਸਹੀ engine ਦੀ ਚੋਣ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ correctness ਦੋਹਾਂ 'ਤੇ ਅਸਰ ਪਾਂਦੀ ਹੈ — ਦੋ ਵੱਖ-ਵੱਖ ਸੈਟਅਪ ਇੱਕੋ SQL ਚਲਾਉ ਸਕਦੇ ਹਨ ਪਰ concurrency ਅਤੇ failure ਹਾਲਤਾਂ ਵਿੱਚ ਬਹੁਤ ਵੱਖ-ਵੱਖ ਵਿਹਾਰ ਕਰ ਸਕਦੇ ਹਨ।
MyISAM ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ ਆਮ ਸੀ ਕਿਉਂਕਿ ਇਹ read-heavy ਸੈਟਅਪ ਲਈ ਸਧਾਰਨ ਤੇ ਤੇਜ਼ ਹੋ ਸਕਦਾ ਸੀ, ਪਰ ਇਹ table-level locks ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, transactions ਨਹੀਂ ਸਹਾਰਦਾ ਅਤੇ crash recovery ਕਮਜ਼ੋਰ ਹੁੰਦਾ ਹੈ। InnoDB ਨੇ row-level locking, transactions ਅਤੇ ਮਜ਼ਬੂਤ durability ਦਿੱਤੀ — ਜਿਸ ਨਾਲ ਲਾਗਇਨ, ਕਾਰਟ ਅਤੇ payments ਵਰਗੀਆਂ write-heavy APIs ਲਈ ਵਧੇਰੇ ਭਰੋਸੇਯੋਗ ਹੋਣਾ ਸੰਭਵ ਹੋਇਆ। ਇਸੀ ਲਈ InnoDB production ਦਾ ਡੀਫਾਲਟ ਬਣ ਗਿਆ।
Indexes MySQL ਨੂੰ ਲੋੜੀਂਦੇ rows ਤੇ ਛੇਤੀ ਪੁੱਜਣ ਦੇ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ। ਅਮਲਿਕ ਰਿਵਾਜ ਜੋ ਮਤਲਬ ਰੱਖਦੇ ਹਨ:
SELECT * ਤੋਂ ਬਚੋ; ਸਿਰਫ਼ ਲੋੜੀਂਦੇ ਕਾਲਮ ਫੈਚ ਕਰੋLIKE ਅਤੇ indexed ਕਾਲਮਾਂ 'ਤੇ functions ਤੋਂ ਸਾਵਧਾਨ ਰਹੋEXPLAIN ਨਾਲ ਪੱਕਾ ਕਰੋ ਕਿ intended index ਵਰਤ ਰਿਹਾ ਹੈਮਕਸਦ ਇਹ ਹੈ ਕਿ production ਵੇਲੇ ਕੁਏਰੀ ਦੀ ਲਾਗਤ predictable ਹੋਵੇ।
Vertical scaling ("ਵੱਡਾ ਬਾਕਸ") ਇੱਕ ਸਰਵਰ ਨੂੰ ਵੱਧ CPU/RAM/ਬਿਹਤਰ ਸਟੋਰੇਜ ਦੇਣਾ ਹੈ — ਆਮ ਤੌਰ 'ਤੇ ਜ਼ਰੂਰੀ ਤੇਜ਼ ਨਤੀਜੇ ਦਿੰਦਾ ਹੈ। Horizontal scaling ("ਵੱਧ ਮਸ਼ੀਨਾਂ") ਰੀਪਲਿਕਾ ਤੇ ਸ਼ਾਰਡਿੰਗ ਸ਼ਾਮਲ ਹੈ ਅਤੇ coordination, replication lag ਅਤੇ routing ਵਰਗੀਆਂ complexity ਲਿਆਉਂਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ query/index fixes ਅਤੇ ਰਾਈਟ-ਸਾਈਜ਼ਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਸ਼ਾਰਡਿੰਗ ਵੇਲੇ ਨਹੀਂ ਜਾਣਦੀਆਂ।
ਰੀਡ ਰੀਪਲਿਕਾਸ ਇਸ ਤਰ੍ਹਾਂ ਮਦਦ ਕਰਦੀਆਂ ਹਨ ਕਿ ਬਹੁਤ ਸਾਰੇ reads secondary ਸਰਵਰਾਂ 'ਤੇ ਭੇਜੇ ਜਾ ਸਕਦੇ ਹਨ ਜਦਕਿ writes primary ਤੇ ਰਹਿੰਦੇ ਹਨ। ਮੁੱਖ trade-off replication lag ਹੈ — ਰੀਪਲਿਕਾ spikes ਦੌਰਾਨ ਸਕਿੰਟਾਂ ਲਈ ਪਿੱਛੇ ਰਹਿ ਸਕਦਾ ਹੈ, ਜੋ "read-your-writes" ਦੀ ਉਮੀਦਾਂ ਨੂੰ ਖਰਾਬ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ ਬਹੁਤ ਟੀਮਾਂ ਤੁਰੰਤ write ਤੋਂ ਬਾਅਦ fresh reads ਲਈ primary ਦਾ ਉਪਯੋਗ ਕਰਦੀਆਂ ਹਨ।