29 ਅਗ 2025·8 ਮਿੰਟ
ਡੇਟਾਬੇਸ ਨੂੰ ਪਹੁੰਚ ਪੈਟਰਨ ਦੇ ਅਧਾਰ ਤੇ ਚੁਣੋ — ਰੁਝਾਨਾਂ ਨਹੀਂ
ਰੀਡ/ਰਾਈਟ ਪਥ, ਲੈਟੈਂਸੀ, ਸਹੀਪਣ ਅਤੇ ਵਾਧੇ ਦੀਆਂ ਲੋੜਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਡੇਟਾਬੇਸ ਚੁਣਨ ਲਈ ਪ੍ਰਾਇਕਟਿਕ ਗਾਈਡ — ਤਾਂ ਜੋ ਰੁਝਾਨਾਂ ਤੋਂ ਬੇਚੈਨੀ ਵਾਲੀ ਟੈਕ ਡੈਬਟ ਨਾ ਬਣੇ।
ਰੀਡ/ਰਾਈਟ ਪਥ, ਲੈਟੈਂਸੀ, ਸਹੀਪਣ ਅਤੇ ਵਾਧੇ ਦੀਆਂ ਲੋੜਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਡੇਟਾਬੇਸ ਚੁਣਨ ਲਈ ਪ੍ਰਾਇਕਟਿਕ ਗਾਈਡ — ਤਾਂ ਜੋ ਰੁਝਾਨਾਂ ਤੋਂ ਬੇਚੈਨੀ ਵਾਲੀ ਟੈਕ ਡੈਬਟ ਨਾ ਬਣੇ।
ਕਿਸੇ ਡੇਟਾਬੇਸ ਨੂੰ ਇਹ ਸੋਚ ਕੇ ਚੁਣਨਾ ਕਿ ਉਹ “ਪਾਪੁਲਰ” ਹੈ, ਉਸੇ ਤਰ੍ਹਾਂ ਹੈ ਜਿਵੇਂ ਕਿਸੇ ਵਾਹਨ ਨੂੰ ਇਸ ਲਈ ਖਰੀਦ ਲੈਣਾ ਕਿ ਹਰ ਕੋਈ ਉਸ ਬਾਰੇ ਗੱਲ ਕਰ ਰਿਹਾ ਹੈ—ਬਿਨਾਂ ਇਹ ਦੇਖੇ ਕਿ ਤੁਹਾਨੂੰ ਸਕooter, ਪਿਕਅਪ ਜਾਂ ਬੱਸ ਦੀ ਲੋੜ ਹੈ ਕਿ ਨਹੀਂ। ਰੁਝਾਨ ਦੂਜਿਆਂ ਦੀ ਉਤਪਾਦ, ਟੀਮ ਆਕਾਰ, ਬਜਟ ਅਤੇ ਰਿਸਕ ਸਹਿਣਸ਼ੀਲਤਾ ਤੇ ਆਧਾਰਿਤ ਹੁੰਦੇ ਹਨ। ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਤੁਹਾਡੇ ਵਰਕਲੋਡ ਨਾਲ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ: ਉਹ ਕੰਮ ਜੋ ਤੁਹਾਡੀ ਐਪ ਸਾਰਾ ਦਿਨ ਕਰਦੀ ਹੈ।
ਵਰਕਲੋਡ ਤੁਹਾਡੇ ਸਿਸਟਮ ਦਾ ਉਤਪਾਦਨ ਵਿੱਚ ਅਸਲ ਵਰਤਾਰਾ ਹੈ:
ਇਹ ਵਰਤਾਰਾ ਤੁਹਾਡੇ ਪਹੁੰਚ ਪੈਟਰਨ ਹਨ—ਉਹ ਦੁਹਰਾਉਣ ਯੋਗ ਢੰਗ ਜਿਨ੍ਹਾਂ ਨਾਲ ਤੁਹਾਡੀ ਐਪ ਡੇਟਾ ਨੂੰ ਛੂਹਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਪਹੁੰਚ ਪੈਟਰਨ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਡੇਟਾਬੇਸ ਚੋਣ ਘੱਟ ਰਹੱਸਮਈ ਹੋ ਜਾਂਦੀ ਹੈ।
ਇਕ-ਸਾਈਜ਼-ਸਭ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀ। ਬਹੁਤ ਸਾਰੀਆਂ ਸਫ਼ਲ ਸਿਸਟਮਾਂ ਇੱਕ ਹਾਈਬ੍ਰਿਡ ਰਵਾਯੇ ਵਰਤਦੀਆਂ ਹਨ: ਇੱਕ ਡੇਟਾਬੇਸ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਾਂ ਲਈ, ਦੂਜਾ ਐਨਾਲਿਟਿਕਸ ਲਈ, ਅਤੇ ਕਈ ਵਾਰੀ ਇੱਕ ਚੁਣੀ ਹੋਈ ਸੋਧ-ਖੋਜ ਇੰਜਣ ਜਾਂ ਕੈਸ਼। ਇਹ “ਫਿਰ ਵੀ ਆਸਾਨੀ ਵਾਸਤੇ ਜਟਿਲਤਾ” ਨਹੀਂ—ਇਹ ਮੰਨਣਾ ਹੈ ਕਿ ਵੱਖ-ਵੱਖ ਪਹੁੰਚ ਪੈਟਰਨ ਵੱਖ-ਵੱਖ ਸਟੋਰੇਜ ਅਤੇ ਕਵੈਰੀ ਇੰਜਣਾਂ ਤੋਂ ਲਾਭ ਲੈਂਦੇ ਹਨ।
“SQL ਵਿਰੁੱਧ NoSQL” ਦੀਆਂ ਚਰਚਾਵਾਂ ਜਾਂ ਜੋ ਵੀ ਹੁਣ ਹਿੱਟ ਹੈ ਉਸ ਦੇ ਪਿੱਛੇ ਦੌੜਨ ਤੋਂ ਪਹਿਲਾਂ, ਆਪਣੀਆਂ ਟਾਪ 5–10 ਰੀਡਸ ਅਤੇ ਰਾਈਟਸ ਲਿਖੋ। ਉੱਥੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ; ਬਾਕੀ ਸਭ ਵਿਵਰਣ ਹਨ।
ਇੱਕ ਪਹੁੰਚ ਪੈਟਰਨ ਐਸਾ ਪ੍ਰਾਇਕਟਿਕ ਵਰਣਨ ਹੈ ਕਿ ਤੁਹਾਡੀ ਐਪ ਹਰ ਰੋਜ਼ ਡੇਟਾ ਨੂੰ ਕਿਵੇਂ ਛੂਹਦੀ ਹੈ: ਕੀ ਪੜ੍ਹਦੀ ਹੈ, ਕੀ ਲਿਖਦੀ ਹੈ, ਕਿੰਨੀ ਵਾਰੀ, ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ, ਅਤੇ ਕਿਸ ਸ਼ਕਲਾਂ ਵਿੱਚ। ਇਹ ਇਸ ਗੱਲ ਤੋਂ ਘੱਟ ਹੈ ਕਿ ਤੁਹਾਡਾ ਡੇਟਾ ਕੀ ਹੈ (“orders” ਜਾਂ “users”) ਅਤੇ ਜ਼ਿਆਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਉਸ ਨਾਲ ਕੀ ਕਰਦੇ ਹੋ (“ID ਦੁਆਰਾ ਇੱਕ ਆਰਡਰ ਨੂੰ 10,000 ਵਾਰੀ ਪ੍ਰਾਪਤ ਕਰੋ” ਜਾਂ “ਪਿਛਲੇ ਮਹੀਨੇ ਦੇ ਸਾਰੇ ਆਰਡਰ ਸਕੈਨ ਕਰੋ ਇੱਕ ਰਿਪੋਰਟ ਬਣਾਉਣ ਲਈ”)।
ਅਧਿਕਤਰ ਰੀਡ ਟਰੈਫਿਕ ਕੁਝ ਪਛਾਣਯੋਗ ਬੱਕਟਾਂ ਵਿੱਚ ਆਉਂਦਾ ਹੈ:
ਇੱਕ ਸੋਸ਼ਲ ਫੀਡ ਮਿਲੇ-ਜੁਲੇ ਪੜ੍ਹਾਈ ਆਕਾਰ ਦਾ ਚੰਗਾ ਉਦਾਹਰਣ ਹੈ: ਪ੍ਰੋਫਾਈਲਾਂ ਲਈ ਪੌਇੰਟ ਲੁੱਕਅੱਪ, “ਆਖਰੀ ਪੋਸਟ” ਲਈ ਰੇਂਜ ਰੀਡ, ਅਤੇ ਗਿਣਤੀ ਲਈ ਐਗਰੀਗੇਸ਼ਨ ਹੋ ਸਕਦੇ ਹਨ।
ਲਿਖਣ ਦੇ ਪੈਟਰਨ ਵੀ ਉੱਤਨੇ ਹੀ ਮਹੱਤਵਪੂਰਕ ਹਨ:
ਲੌਗ ਅਕਸਰ “ਲਿਖਣ-ਭਾਰ ਵਾਲੇ ਅਤੇ ਐਪੈਂਡ-ਓਨਲੀ” ਹੁੰਦੇ ਹਨ (ਬਹੁਤ ਸਾਰੇ ਇਨਸਰਟ, ਘੱਟ ਅੱਪਡੇਟ)। ਆਰਡਰ ਆਮ ਤੌਰ 'ਤੇ “ਲਿਖੋ-ਫਿਰ-ਅਪਡੇਟ” ਹੁੰਦੇ ਹਨ (ਬਣਾਉਣਾ, ਫਿਰ ਸਥਿਤੀ ਬਦਲਾਉਣਾ)।
ਕਈ ਉਤਪਾਦ ਹਰ ਚੀਜ਼ ਇੱਕ ਵੇਲੇ ਚਾਹੁੰਦੇ ਹਨ: ਐਪ ਲਈ ਤੇਜ਼ ਪੌਇੰਟ ਲੁੱਕਅੱਪ, ਗਾਹਕ ਸਮਰਥਨ ਲਈ ਜਟਿਲ ਕਵੈਰੀਜ਼, ਅਤੇ ਐਨਾਲਿਟਿਕਸ ਲਈ ਵੱਡੇ ਸਕੈਨ। ਇੱਕ ਡੇਟਾਬੇਸ ਕੁਝ ਮਿਲਾਅ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਹੰਡਲ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਕੁਝ ਜੋੜੇ ਇਕ ਦੂਜੇ ਨਾਲ ਲੜਦੇ ਹਨ—ਉਦਾਹਰਣ ਲਈ, ਭਾਰੀ ਐਨਾਲਿਟਿਕਲ ਸਕੈਨ ਉਹ ਛੋਟੇ, ਲੈਟੈਂਸੀ-ਸੰਵੇਦਨਸ਼ੀਲ ਰੀਡਾਂ ਨੂੰ ਜਿਹੜੀਆਂ ਚੈਕਆਉਟ ਜਾਂ ਫੀਡ ਚਲਾਉਂਦੀਆਂ ਹਨ, ਢੀਲਾ ਕਰ ਸਕਦੇ ਹਨ।
ਜਦ ਤੱਕ ਤੁਸੀਂ ਆਪਣੇ ਪਹੁੰਚ ਪੈਟਰਨ ਨਾਂ ਕਰਕੇ ਸਪਸ਼ਟ ਕਰ ਸਕਦੇ ਹੋ, ਤੁਸੀਂ ਡੇਟਾਬੇਸਾਂ ਨੂੰ ਲੋਕਪ੍ਰਿਯਤਾ ਦੀ ਥਾਂ ਅਸਲ ਵਰਤਾਰਾ ਦੇ ਆਧਾਰ 'ਤੇ ਅੰਕਲਣ ਕਰ ਸਕਦੇ ਹੋ।
ਡੇਟਾਬੇਸ ਦੇ ਉਸ ਏਰੇ ਦੇ ਮੁਕਾਬਲੇ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਉਸ ਵਰਕਲੋਡ ਦਾ ਨਾਮ ਰੱਖੋ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਸਰਵ ਕਰ ਰਹੇ ਹੋ। ਜ਼ਿਆਦਾਤਰ ਉਤਪਾਦ “ਇੱਕ ਵਰਕਲੋਡ” ਨਹੀਂ ਹੁੰਦੇ—ਉਹ ਕੁਝ ਵੱਖ-ਵੱਖ ਵਰਕਲੋਡ ਹੁੰਦੇ ਹਨ ਜੋ ਇਕੱਠੇ ਬੈਠੇ ਹੁੰਦੇ ਹਨ (ਅਤੇ ਕਈ ਵਾਰੀ ਮੁਕਾਬਲਾ ਵੀ ਕਰਦੇ ਹਨ)। ਸ਼ੁਰੂ ਵਿੱਚ ਇਹ ਦਰੁਸਤ ਵਰਗੀਕਰਨ ਤੁਹਾਨੂੰ ਇੱਕ ਡੇਟਾਬੇਸ ਨੂੰ ਉਸ ਕੰਮ 'ਤੇ ਜ਼ਬਰਦਸਤੀ ਨਾਲ ਹਿਲਾਉਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਜਿਸ ਲਈ ਉਹ ਨਿਰਧਾਰਤ ਨਹੀਂ ਸੀ।
OLTP ਜ਼ਿਆਦਾਤਰ ਐਪਸ ਦੀ ਦੈਨਿਕ ਧੜਕਣ ਹੈ: ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ ਰੀਡ ਅਤੇ ਰਾਈਟ, ਬਹੁਤ ਸਾਰੇ ਸਮਕਾਲੀ ਯੂਜ਼ਰ, ਅਤੇ ਅਜਿਹੀਆਂ ਬੇਨਤੀਆਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੇਜ਼ ਖਤਮ ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ।
ਸੋਚੋ: “ਕਾਰਟ ਅਪਡੇਟ ਕਰੋ,” “ਆਰਡਰ ਬਣਾਓ,” “ਪਤਾ ਬਦਲੋ,” “ਇਨਵੈਂਟਰੀ ਚੈਕ ਕਰੋ।” ਇਹ ਆਪਰੇਸ਼ਨ ਛੋਟੇ, ਲਕੜੀਆਂ, ਅਤੇ ਸਹੀਪਣ-ਸੰਵੇਦਨਸ਼ੀਲ ਹੁੰਦੇ ਹਨ। ਜੇ ਇਕ ਭੁਗਤਾਨ ਕੈਪਚਰ ਹੋਈ, ਤਾਂ ਉਹ ਗਾਇਬ ਨਹੀਂ ਹੋ ਸਕਦੀ; ਜੇ ਇੱਕ ਸੀਟ ਰਿਜ਼ਰਵ ਹੋਈ, ਤਾਂ ਦੋ ਲੋਕਾਂ ਨੂੰ ਇੱਕੋ ਹੀ ਸੀਟ ਨਹੀਂ ਮਿਲਣੀ ਚਾਹੀਦੀ।
OLTP ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਸਿਸਟਮਾਂ ਵੱਲ ਧکیلਦਾ ਹੈ ਜੋ ਉੱਚ ਸਮਕਾਲੀਤਾ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਹੰਡਲ ਕਰਦੇ ਹਨ ਅਤੇ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਾਂ ਅਤੇ ਡੇਟਾ ਇੰਟੈਗ੍ਰਿਟੀ ਬਾਰੇ ਸਪਸ਼ਟ ਗਾਰੰਟੀ ਦਿੰਦੇ ਹਨ।
ਐਨਾਲਿਟਿਕਸ ਕੰਮ ਦੇ ਆਕਾਰ ਨੂੰ ਉਲਟ ਦਿੰਦੀ ਹੈ: ਘੱਟ ਕਵੈਰੀਆਂ ਪਰ ਹਰ ਇੱਕ ਬਹੁਤ ਜ਼ਿਆਦਾ ਡੇਟਾ ਨੂੰ ਛੂਹਦੀ ਹੈ।
ਸੋਚੋ: “ਪਿਛਲੇ ਤਿਮਾਹੀ ਵਿੱਚ ਖੇਤਰ ਅਨੁਸਾਰ ਆਮਦਨੀ,” “ਚੈਨਲ ਅਨੁਸਾਰ ਕਨਵਰਜ਼ਨ,” “ਸ਼੍ਰੇਣੀ ਪ੍ਰਤੀ ਊਪਰਲੇ ਉਤਪਾਦ,” “ਦੈਨੀਕ ਸਰਗਰਮ ਯੂਜ਼ਰ ਟ੍ਰੈਂਡ।” ਇਹ ਕਵੈਰੀਆਂ ਅਕਸਰ ਬਹੁਤ ਸਾਰੀਆਂ ਪੰਗਤੀਆਂ ਸਕੈਨ, ਗਰੂਪ, ਐਗਰੀਗੇਟ ਅਤੇ ਸੋਰਟ ਕਰਦੀਆਂ ਹਨ। ਲੈਟੈਂਸੀ ਦੀ ਉਮੀਦ ਢੀਲੀ ਹੋ ਸਕਦੀ ਹੈ (ਕਈ ਵਾਰੀ ਸਕਿੰਡ ਠੀਕ ਹੁੰਦੇ ਹਨ), ਪਰ ਭਾਰੀ ਸਕੈਨ ਦੀ ਲਾਗਤ ਮਹੱਤਵਪੂਰਣ ਹੁੰਦੀ ਹੈ—ਖਾਸ ਕਰਕੇ ਜੇ ਡੈਸ਼ਬੋਰਡ ਸਾਰਾ ਦਿਨ ਚਲ ਰਹੇ ਹਨ।
ਜੇ ਤੁਸੀਂ OLAP-ਟਾਈਪ ਸਕੈਨ ਨੂੰ ਉਹੀ ਸਿਸਟਮ ਤੇ ਚਲਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਜੋ ਚੈਕਆਉਟ ਚਲਾਂਉਂਦਾ ਹੈ, ਤਾਂ ਅਕਸਰ ਇੱਕ ਦੂਜੇ 'ਤੇ ਦੋਨਾਂ ਵਿਚੋਂ ਇੱਕ ਥੱਲੇ ਰਹਿ ਜਾਂਦਾ ਹੈ।
ਟਾਈਮ-ਸਿਰੀਜ਼ ਅਤੇ ਲੌਗ ਆਮ ਤੌਰ 'ਤੇ ਐਪੈਂਡ-ਭਰਪੂਰ ਹੁੰਦੇ ਹਨ: ਨਵੇਂ ਇਵੈਂਟ ਲਗਾਤਾਰ ਆਉਂਦੇ ਹਨ ਅਤੇ ਤੁਸੀਂ ਅਕਸਰ ਸਮੇਂ-ਰੇਂਜ ਦੁਆਰਾ ਕਵੈਰੀ ਕਰਦੇ ਹੋ।
ਸੋਚੋ: ਮੈਟ੍ਰਿਕਸ, ਕਲਿੱਕਸਟਰੀਮ, ਡਿਵਾਈਸ ਟੈਲੀਮੇਟਰੀ, ਆਡੀਟ ਲੌਗ। ਆਮ ਲੋੜਾਂ ਵਿੱਚ ਰੀਟੈਂਸ਼ਨ ਪਾਲਿਸੀਆਂ (ਪੁਰਾਣਾ ਡੇਟਾ ਮਿਟਾਓ/ਮੁਦਤ ਨੂੰ ਸਮਾਪਤ ਕਰੋ), ਰੋਲਅਪਸ (ਕੱਚੇ ਇਵੈਂਟ 7 ਦਿਨਾਂ ਲਈ ਰੱਖੋ, 12 ਮਹੀਨੇ ਲਈ ਐਗਰੀਗੇਟਸ), ਅਤੇ ਸਪੀਕਸ ਦੌਰਾਨ ਤੇਜ਼ ਲਿਖਤਾਂ ਸ਼ਾਮਲ ਹਨ।
ਇਹ ਵਰਕਲੋਡ ਜੋਇਨਜ਼ ਵਿੱਚ ਜਟਿਲਤਾ ਤੋਂ ਘੱਟ ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਟਾਈਮਸਟੈਂਪਡ ਰਿਕਾਰਡਾਂ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਇੰਜੈਸਟ ਅਤੇ ਰੱਖਣ ਬਾਰੇ ਹੈ।
ਖੋਜ ਕੇਵਲ “ਪੰਗਤਾਂ ਲੱਭੋ” ਹੀ ਨਹੀਂ ਹੈ। ਇਹ ਟੈਕਸਟ ਮੇਚਿੰਗ, ਰੀਲੇਵੈਂਸ ਰੈਂਕਿੰਗ, ਅਧੂਰੇ ਮੇਚ, ਅਤੇ ਯੂਜ਼ਰ-ਅਨੁਕੂਲ ਫਿਲਟਰਿੰਗ ਹੈ।
ਸੋਚੋ: ਕੀਵਰਡ ਦੁਆਰਾ ਉਤਪਾਦ ਖੋਜਣਾ, ਫਰੇਜ਼ਾਂ ਦੁਆਰਾ ਟਿਕਟ ਲੱਭਣਾ, ਫੈਸੈਟ (ਬ੍ਰਾਂਡ, ਕੀਮਤ, ਰੰਗ) ਦੁਆਰਾ ਛਾਂਟਣਾ ਅਤੇ “ਬੈਸਟ ਮੈਚ” ਅਨੁਸਾਰ ਸੋਰਟ ਕਰਨਾ। ਇਹ ਵਿਸ਼ੇਸ਼ ਇੰਡੈਕਸਿੰਗ ਅਤੇ ਕਵੈਰੀ ਯੋਗਤਾਵਾਂ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ ਜੋ ਆਮ-ਉਦੇਸ਼ ਡੇਟਾਬੇਸ ਕਦਾਚਿਤ ਅਨੁਕਰਨ ਕਰ ਸਕਦੇ ਹਨ—ਪਰ ਬਹੁਤ ਘੱਟ ਵਾਰੀ ਉਹ ਸ਼ਾਨਦਾਰ ਹੁੰਦੇ ਹਨ।
ਜੇ ਖੋਜ ਤੁਹਾਡੇ ਉਤਪਾਦ ਦੀ ਮੁੱਖ ਵਿਸੇਅ ਹੈ, ਤਾਂ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਇਸਨੂੰ ਆਪਣੀ ਵਰਕਲੋਡ ਸਮਝੋ, ਨਾ ਕਿ “ਬਾਦ ਵਿੱਚ ਜੋੜਾਂਗੇ” ਵਾਲੀ ਚੀਜ਼।
ਪਰਫਾਰਮੈਂਸ ਇੱਕ ਸਿਰਫ਼ ਨੰਬਰ ਨਹੀਂ ਹੁੰਦੀ। ਦੋ ਡੇਟਾਬੇਸ ਦੋਹਾਂ “ਤੇਜ਼” ਹੋ ਸਕਦੇ ਹਨ, ਫਿਰ ਵੀ ਯੂਜ਼ਰਾਂ ਅਤੇ ਓਪਰੇਟਰਾਂ ਲਈ ਬਿਲਕੁਲ ਵੱਖ-ਵੱਖ ਅਨੁਭਵ ਹੋ ਸਕਦਾ ਹੈ। ਚੰਗਾ ਚੋਣ ਕਰਨ ਲਈ, ਇਸ ਗੱਲ ਨੂੰ ਵੱਖ ਕਰੋ ਕਿ ਮਨੁੱਖ ਕੀ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ (ਲੈਟੈਂਸੀ) ਅਤੇ ਤੁਹਾਡੀ ਸਿਸਟਮ ਨੂੰ ਕਿੰਨੀ ਬੋਝ ਝੇਲਣਾ ਪੈਣਾ ਹੈ (ਥਰੂਪੁੱਟ), ਫਿਰ ਸਪੀਕਸ ਨਾਲ ਆਪਣੇ ਅਨੁਮਾਨਾਂ ਨੂੰ ਤਾਣ-ਜੋਖੋਂ ਕਰੋ।
ਲੈਟੈਂਸੀ ਇੱਕ ਇਕੱਲੀ ਬੇਨਤੀ ਲਈ ਲੱਗਣ ਵਾਲਾ ਸਮਾਂ ਹੈ—“ਬਟਨ ਦਬਾਓ, ਨਤੀਜਾ ਮਿਲੇ।” ਯੂਜ਼ਰ ਲੈਟੈਂਸੀ ਨੂੰ ਸਿੱਧਾ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ।
ਥਰੂਪੁੱਟ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਪ੍ਰਤੀ ਸਕਿੰਡ ਕਿੰਨੀਆਂ ਬੇਨਤੀਆਂ ਪ੍ਰਕਿਰਿਆ ਕਰ ਸਕਦੇ ਹੋ—ਸਿਸਟਮ ਕੁੱਲ ਵਿੱਚ ਕਿੰਨਾ ਟ੍ਰੈਫਿਕ ਸਮਭਾਲ ਸਕਦਾ ਹੈ।
ਇੱਕ ਡੇਟਾਬੇਸ ਬੈਚਿੰਗ ਨਾਲ ਉੱਚ ਥਰੂਪੁੱਟ ਦਿੱਲਾ ਸਕਦਾ ਹੈ ਪਰ ਹਰ-ਰਿਕਵੈਸਟ ਦੇਸ਼ਤੀਕ ਰੁਕਾਵਟ ਦਿਖਾ ਸਕਦਾ ਹੈ। ਦੂਜਾ ਤੇਜ਼ ਪੌਇੰਟ ਰੀਡ ਲਈ ਅਪਟਿਮਾਈਜ਼ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਬਹੁਤ ਸਾਰੇ ਲਿਖਤ ਆਉਣ 'ਤੇ ਸੰਘਰਸ਼ ਕਰ ਸਕਦਾ ਹੈ।
ਔਸਤ ਲੈਟੈਂਸੀ ਦਰਦ ਨੂੰ ਛੁਪਾ ਦਿੰਦੀ ਹੈ। ਜੇ 99 ਬੇਨਤੀਆਂ 50 ms ਵਿੱਚ ਖਤਮ ਹੋ ਜਾ ਰਹੀਆਂ ਹਨ ਪਰ 1 ਬੇਨਤੀ 2 ਸਕਿੰਡ ਲੈਂਦੀ ਹੈ, ਤਾਂ ਔਸਤ ਠੀਕ ਲੱਗੇਗਾ—ਪਰ ਉਹ 1% “ਐਪ ਧੀਮਾ ਹੈ” ਪਲ ਬਣ ਜਾਏਗਾ।
ਇਹੀ P99 ਲੈਟੈਂਸੀ ਦਾ ਮਤਲਬ ਹੈ: ਸਭ ਤੋਂ ਧੀਮੇ 1% ਬੇਨਤੀਆਂ ਲਈ ਲੱਗਣ ਵਾਲਾ ਸਮਾਂ। ਯੂਜ਼ਰ-ਸੰਬੰਧਤ ਵਿਸ਼ੇਅ (ਚੈਕਆਉਟ, ਲੌਗਇਨ, ਖੋਜ ਨਤੀਜੇ) ਲਈ, P99 ਅਕਸਰ ਉਹ ਮੈਟ੍ਰਿਕ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਡਿਜ਼ਾਈਨ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਜਾਂ ਨਾ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰਦੀ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਸਿਸਟਮ ਔਸਤ ਟ੍ਰੈਫਿਕ 'ਤੇ ਨਾਹੀਂ ਫੇਲ ਹੁੰਦੇ; ਉਹ ਪੀਕਸ ਦੌਰਾਨ ਫੇਲ ਹੁੰਦੇ ਹਨ: ਇੱਕ ਮਾਰਕੀਟਿੰਗ ਈਮੇਲ, ਇਕ ਬ੍ਰੇਕਿੰਗ-ਨਿਊਜ਼ ਮੋਮੈਂਟ, ਪੇਰੋਲ ਦਿਨ, ਮਹੀਨੇ ਦੇ ਅਖੀਰ ਦੀ ਰਿਪੋਰਟਿੰਗ।
ਸਪੀਕਸ ਡੇਟਾਬੇਸ ਗੱਲਬਾਤ ਨੂੰ ਬਦਲ ਦਿੰਦੇ ਹਨ:
ਕੈਸ਼ਿੰਗ ਪੜ੍ਹ-ਭਾਰ ਵਾਲੀਆਂ ਵਰਕਲੋਡਜ਼ ਨੂੰ ਛੋਟਾ ਦਿਖਾ ਸਕਦੀ ਹੈ—ਜਦ ਤੱਕ ਕੋਈ ਕੈਸ਼ ਮਿਸ ਜਾਂ ਕੈਸ਼ ਪੁਰਜ ਨਾ ਹੋਵੇ।
ਜੇ ਜ਼ਿਆਦਾਤਰ ਰੀਡ ਕੈਸ਼ 'ਤੇ ਲੱਗਦੇ ਹਨ, ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਪ੍ਰਧਾਨ ਤੌਰ 'ਤੇ ਲਿਖਤਾਂ ਅਤੇ ਕਦੇ-ਕਦੇ ਮਹਿੰਗੀਆਂ ਰੀਡਾਂ ਨੂੰ ਸੇਵਾ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਉਨ੍ਹਾਂ ਚੋਣਾਂ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਕਰਦੇ ਹੋ। “ਕੋਲਡ ਕੈਸ਼” ਘਟਨਾਂ ਅਤੇ ਮਿਸਜ਼ ਦੀ ਪੂਛ-ਪਠਤ ਲੈਟੈਂਸੀ ਲਈ ਯੋਜਨਾ ਬਣਾਓ, ਨਾ ਕਿ ਸਿਰਫ਼ ਐਨੀ-ਪਾਥ।
ਡੇਟਾਬੇਸ ਚੁਣਨਾ ਸਿਰਫ ਤੇਜ਼ੀ ਬਾਰੇ ਨਹੀਂ—ਇਹ ਵੀ ਹੈ ਕਿ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ, ਕਿੰਨੀ ਡਾਊਨਟਾਈਮ ਮਨਜ਼ੂਰ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਉਪਭੋਗਤਾ ਕਿੱਥੇ ਹਨ।
ਉਹ ਡੇਟਾ ਨਾਂ ਧਾਰੋ ਜੋ ਹਰ ਵਾਰੀ ਸਹੀ ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ। ਭੁਗਤਾਨ, ਖਾਤਾ ਬੈਲੈਂਸ, ਅਤੇ ਇਨਵੈਂਟਰੀ ਗਿਣਤੀ ਇਸਦੇ ਕਲਾਸਿਕ ਉਦਾਹਰਣ ਹਨ। ਜੇ ਗਾਹਕ ਨੂੰ ਦੋ ਵਾਰੀ ਚਾਰਜ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਾਂ ਤੁਸੀਂ ਓਵਰਸੈਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਕੀਮਤ ਸਿਰਫ਼ ਧੀਮੀ ਐਪ ਨਹੀਂ ਹੁੰਦੀ—ਇਹ ਰਿਫੰਡ, ਸਹਾਇਤਾ ਟਿਕਟ, ਅਤੇ ਭਰੋਸੇ ਦਾ ਨੁਕਸਾਨ ਹੁੰਦੀ ਹੈ।
ਇਨ੍ਹਾਂ ਹਿੱਸਿਆਂ ਲਈ, ਤੁਸੀਂ ਆਮਤੌਰ 'ਤੇ ਮਜ਼ਬੂਤ ਗਾਰੰਟੀਆਂ ਚਾਹੁੰਦੇ ਹੋ: ਲਿਖਤਾਂ ਨੂੰ ਪੁਸ਼ਟੀ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨਾਂ ਨੂੰ ਮੁਕੰਮਲ ਨਹੀਂ ਮੰਨੋ, ਅਤੇ ਰੀਡਰ ਅੱਧ-ਪੂਰੇ ਅੱਪਡੇਟ ਨਾ ਵੇਖਣ। ਵਪਸੇਦਾ ਇਹ ਹੈ ਕਿ ਮਜ਼ਬੂਤ ਸਹੀਪਣ ਆਮ ਤੌਰ 'ਤੇ ਲਚਕੀਲਤਾ ਘਟਾ ਦਿੰਦਾ ਹੈ: ਕੁਝ ਸਕੇਲਿੰਗ ਰਣਨੀਤੀਆਂ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਕ੍ਰਾਸ-ਰੀਜਨ ਲਿਖਤਾਂ ਥੱਲੇ ਹੋ ਸਕਦੀਆਂ ਹਨ।
ਅਗਲਾ, ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਜੇ ਡੇਟਾਬੇਸ 5 ਮਿੰਟ ਲਈ ਅਣਉਪਲੱਬਧ ਹੋ ਜਾਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ।
ਜੇ ਡਾਊਨਟਾਈਮ ਨਾਲ “ਆਰਡਰ ਰੁਕ ਜਾਂਦੇ ਹਨ ਅਤੇ ਰੈਵੇਨਿਊ ਰੁਕ ਜਾਂਦੀ ਹੈ”, ਤਾਂ ਤੁਹਾਨੂੰ ਉੱਚ ਉਪਲੱਬਧਤਾ ਦੀ ਲੋੜ ਹੈ: ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ, ਚੰਗੇ ਬੈਕਅਪ, ਅਤੇ ਐਪ ਨੂੰ ਆਫਲਾਈਨ ਕੀਤੇ ਬਿਨਾਂ ਰਖ-ਪਛਤਾਵੇ ਦੀ ਯੋਜਨਾ। ਜੇ ਡਾਊਨਟਾਈਮ ਦਾ ਅਰਥ “ਅੰਤਰਿਕ ਡੈਸ਼ਬੋਰਡ ਰਿਪੋਰਟ ਦੇਰ ਨਾਲ ਆਉਂਦੇ ਹਨ” ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਧਾਰਨ ਸੈਟਅੱਪ ਰੱਖ ਸਕਦੇ ਹੋ।
ਉੱਚ ਉਪਲੱਬਧਤਾ ਆਮ ਤੌਰ 'ਤੇ ਲਾਗਤ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਜਟਿਲਤਾ ਵਧਾਉਂਦੀ ਹੈ (ਵੱਧ ਰੇਪਲਿਕਾ, ਵਧੀਆ ਮੋਨਿਟਰਿੰਗ, ਧਿਆਨ-ਪੂਰਵਕ ਅਪਗਰੇਡ)। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਸ ਨਿਵੇਸ਼ ਨੂੰ ਕਾਰੋਬਾਰੀ ਪ੍ਰਭਾਵ ਨਾਲ ਮੇਲ ਖਾਓ।
ਜੇ ਤੁਹਾਡੇ ਉਪਭੋਗਤਾ ਜ਼ਿਆਦਾਤਰ ਇੱਕ ਖੇਤਰ ਵਿੱਚ ਹਨ, ਤਾਂ ਡੇਟਾ ਇੱਕ ਥਾਂ 'ਤੇ ਰੱਖਣਾ ਸਸਤਾ ਅਤੇ ਤੇਜ਼ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕਾਂਟਿਨੇਂਟ-ਵਿਆਪੀ ਯੂਜ਼ਰ ਹਨ—ਜਾਂ ਰੈਗੂਲੇਟਰੀ ਲੋੜ ਹੈ ਕਿ ਡੇਟਾ ਕਿੱਥੇ ਰਹੇ—ਤਾਂ ਤੁਹਾਨੂੰ ਮਲਟੀ-ਰੀਜਨ ਰੀਪਲੀਕੇਸ਼ਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।
ਮਲਟੀ-ਰੀਜਨ ਡਿਜ਼ਾਈਨ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਅਤੇ ਰੇਜੀਲਿਏਂਸ ਵਧਾਉਂਦੇ ਹਨ, ਪਰ ਇਹ ਮੁਸ਼ਕਲ ਚੌਣ ਲਿਆੁਂਦੇ ਹਨ: ਕੀ ਤੁਸੀਂ ਥੋੜ੍ਹਾ-ਸੁੱਟੇ ਪੜ੍ਹਨ ਦੀ ਆਗਿਆ ਦਿਓਗੇ, ਜਾਂ ਸਾਰੇ ਕੁੱਝ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਮਕਾਲੀ ਬਣਾਏ ਰੱਖਣ ਲਈ ਲਿਖਤਾਂ ਨੂੰ ধੀਮਾ ਕਰ ਲਵੋਗੇ? ਸਹੀ ਜਵਾਬ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡੀ ਵਰਕਲੋਡ ਕੀ ਸਹਿ ਸਕਦੀ ਹੈ।
ਬਹੁਤ ਸਾਰੀਆਂ “ਡੇਟਾਬੇਸ बहਸਾਂ” ਅਸਲ ਵਿੱਚ ਕਵੈਰੀ ਆਕਾਰ ਬਾਰੇ ਹੋਂਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਕਿਹੜੇ ਸਵਾਲ ਪੁੱਛਣੇ ਹੋਣਗੇ—ਜੋਇਨ, ਐਗਰੀਗੇਸ਼ਨ, ਫਿਲਟਰ, ਟਾਈਮ ਵਿੰਡੋ—ਤਾਂ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਡੇਟਾਬੇਸ ਵਿਕਲਪਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਘਟਾ ਸਕਦੇ ਹੋ।
ਰਿਸ਼ਤੇਦਾਰ ਮਾਡਲ ਉਸ ਵੇਲੇ ਚਮਕਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਬਹੁ-ਇਕਾਈਆਂ 'ਤੇ ਲਚਕੀਲੇ ਫਿਲਟਰ ਅਤੇ ਜੋਇਨ ਦੀ ਲੋੜ ਹੋਵੇ (customers → orders → items), ਖਾਸ ਤੌਰ 'ਤੇ ਜਦੋਂ ਮੰਗਾਂ ਵਿਕਸਤ ਹੁੰਦੀਆਂ ਹਨ। ਜੇ ਤੁਹਾਡੇ ਉਤਪਾਦ ਨੂੰ ਐਡ-ਹਾਕ ਰਿਪੋਰਟਿੰਗ ਦੀ ਲੋੜ ਹੈ (“ਦਿਖਾਓ ਸਾਰੇ ਗਾਹਕ ਜੋ X ਖਰੀਦੇ ਅਤੇ Y ਵਾਪਸ ਕਰ ਦਿੱਤਾ”), ਤਦ SQL ਅਤੇ ਜੋਇਨ ਸਮੇਂ ਦੇ ਨਾਲ ਸਧਾਰਨ ਰਹਿੰਦੇ ਹਨ।
ਜੇ ਤੁਹਾਡੀਆਂ ਕਵੈਰੀਆਂ ਪੂਰਵ-ਅਨੁਮਾਨਿਤ ਹਨ ਅਤੇ ਮੁੱਖ ਤੌਰ 'ਤੇ primary key ਦੁਆਰਾ ਪੜ੍ਹੀਆਂ ਜਾਂਦੀਆਂ ਹਨ (“user_id ਦੁਆਰਾ ਪ੍ਰੋਫਾਈਲ ਲਵੋ”), ਤਾਂ ਦਸਤਾਵੇਜ਼ ਜਾਂ ਕੀ-ਵੈਲਯੂ ਮਾਡਲ ਚੰਗਾ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ—ਅਕਸਰ ਉਨ੍ਹਾਂ ਵਿੱਚ ਡੇਟਾ ਉਸੇ ਰੂਪ ਵਿੱਚ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ ਜਿਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਪੜ੍ਹਦੇ ਹੋ। ਵਪਸੇਦਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਜੋਇਨ ਬਚਾਉਣ ਲਈ ਡੇਟਾ ਨਕਲ ਕਰ ਸਕਦੇ ਹੋ, ਜੋ ਕਿ ਲਿਖਤਾਂ ਅਤੇ ਅੱਪਡੇਟਸ ਨੂੰ ਜਟਿਲ ਬਣਾਉਂਦਾ ਹੈ।
ਇੰਡੈਕਸ ਤੁਹਾਨੂੰ ਡੇਟਾਬੇਸ ਨੂੰ ਦੱਸਣ ਦਾ ਢੰਗ ਹੈ, “ਇਹ ਮੇਰੇ ਪਹੁੰਚ ਪੈਟਰਨ ਹਨ।” ਇੱਕ ਕਵੈਰੀ ਜੋ ਮੌਕੇ 'ਤੇ ਠੀਕ ਦਿਖਦੀ ਹੈ, ਡੇਟਾ ਆਕਾਰ ਜਾਂ ਸਮੇਤ ਨਾਲ ਬਹੁਤ धीਮੀ ਹੋ ਸਕਦੀ ਹੈ ਜੇ ਇਹ ਗੈਰ-ਇੰਡੈਕਸਡ ਫੀਲਡਾਂ 'ਤੇ ਫਿਲਟਰ ਕਰਦੀ ਹੈ।
ਇਕ ਸਹਾਇਕ ਨਿਯਮ: ਹਰ ਅਕਸਰ ਫਿਲਟਰ, ਸੋਰਟ, ਜਾਂ ਜੋਇਨ ਕੀ ਲਈ ਇੱਕ ਇੰਡੈਕਸ ਯੋਜਨਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਪਰ ਇੰਡੈਕਸ ਮੁਫਤ ਨਹੀਂ ਹੁੰਦੇ: ਉਹ ਸਟੋਰੇਜ ਖਾਂਦੇ ਹਨ ਅਤੇ ਲਿਖਤਾਂ ਨੂੰ ਭਾਰ ਕਰਦੇ ਹਨ।
“ਤੇਜ਼ ਲਿਖਤ” ਦਾਵਿਆਂ ਅਕਸਰ ਲਿਖਤ-ਅੰਪਲੀਫਿਕੇਸ਼ਨ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ—ਦੂਜੇ ਇੰਡੈਕਸ, ਕੰਪੈਕਸ਼ਨ, ਰੀਪਲੀਕੇਸ਼ਨ, ਜਾਂ ਡੀਨਾਰਮਲਾਈਜ਼ਡ ਡੇਟਾ ਦੇ ਅਪਡੇਟ ਨਾਲ ਬਣਿਆ ਜਿਆਦਾ ਕੰਮ। ਇੱਕ ਡਿਜ਼ਾਈਨ ਜੋ ਪੜ੍ਹਾਈਆਂ ਨੂੰ ਅਪਟਿਮਾਈਜ਼ ਕਰਨ ਲਈ ਇੰਡੈਕਸ ਜਾਂ ਡੇਟਾ ਨਕਲ ਕਰਦਾ ਹੈ ਉਹ ਅਚਾਨਕ ਇੱਕ ਉੱਚ-ਲਿਖਤ ਵਰਕਲੋਡ ਨੂੰ ਬੋਤਲਨੇਕ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ।
ਸਕੀਮਾ-ਲੈਸ ਦਾ ਮਤਲਬ ਢਾਂਚਾ-ਮੁਕਤ ਨਹੀਂ ਹੁੰਦਾ। ਲਚਕਦਾਰ ਸਕੀਮਾਂ ਸ਼ੁਰੂ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਇਤਰਾਓਂ ਨੂੰ ਤੇਜ਼ ਕਰਦੀਆਂ ਹਨ, ਪਰ ਬਿਨਾਂ ਰੀਤਾਂ ਦੇ ਉਹ ਅਸਮਰਥ ਖੇਤਰ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਜੋ ਗੱਲ-ਬਾਤ ਖਰਾਬ ਕਰ ਦਿੰਦੇ ਹਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਮਹਿੰਗੀਆਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਬਣਾਉਂਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ, ਬਹੁਤ ਸਾਰੇ ਫੀਚਰ, ਜਾਂ ਲੰਬੀ ਰੀਟੈਂਸ਼ਨ ਦੀ ਉਮੀਦ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਕਸਰ-ਵਾਧੂ ਸਕੀਮਾ ਅਤੇ ਸਪਸ਼ਟ ਪਾਬੰਦੀਆਂ ਆਮ ਤੌਰ 'ਤੇ ਕੁਲ ਲਾਗਤ ਘਟਾਉਂਦੇ ਹਨ—ਭਾਵੇਂ ਇਹ ਸ਼ੁਰੂ ਵਿੱਚ ਢੀਲਾ ਮਹਿਸੂਸ ਹੋਵੇ।
ਇੱਕ ਡੇਟਾਬੇਸ ਨੂੰ ਲੋਕਪ੍ਰਿਯਤਾ ਦੇ ਆਧਾਰ 'ਤੇ ਚੁਣਨਾ ਬਾਅਦ ਵਿੱਚ ਅਕਸਰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦਾ ਹੈ: ਇਸਨੂੰ ਚਲਾਉਣਾ, ਸੁਰੱਖਿਅਤ ਰੱਖਣਾ, ਅਤੇ ਮਹੀਨੇ-ਬ-ਮਹੀਨਾ ਬਿੱਲ ਭਰਨਾ। ਦੋ ਡੇਟਾਬੇਸ ਇੱਕੋ ਹੀ ਕਾਰਜਕਾਰੀ ਮੰਗਾਂ ਨੂੰ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹਨ, ਫਿਰ ਵੀ ਓਪਰੇਸ਼ਨਲ ਕੋਸ਼ਿਸ਼ ਅਤੇ ਕੁੱਲ ਲਾਗਤ ਵਿੱਚ ਵੱਡਾ ਫਰਕ ਹੋ ਸਕਦਾ ਹੈ।
ਸ਼ੁਰੂ ਵਿੱਚ ਪੁੱਛੋ ਕਿ 2 AM 'ਤੇ ਇਹ ਸਿਸਟਮ ਕੌਣ ਚਲਾਏਗਾ। ਬੈਕਅਪ, ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ, ਅਪਗ੍ਰੇਡ, ਪੈਚਿੰਗ, ਫੇਲਓਵਰ ਡ੍ਰਿੱਲ, ਅਤੇ ਮੋਨਿਟਰਿੰਗ “ਬਾਅਦ” ਦੇ ਕੰਮ ਨਹੀਂ ਹਨ—ਉਹ ਤੁਹਾਡੇ ਰਿਸਕ ਅਤੇ ਸਟਾਫਿੰਗ ਨੂੰ ਆਕਾਰ ਦਿੰਦੇ ਹਨ।
Managed ਸਰਵਿਸਜ਼ ਤੋਇਲ ਘਟਾ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਇਸਨੂੰ ਖ਼ਤਮ ਨਹੀਂ ਕਰਦੇ। ਕੁਝ ਸਿਸਟਮ ਨਿਯਮਤ ਕੰਪੈਕਸ਼ਨ, ਧਿਆਨ-ਪੂਰਵਕ ਟਿਊਨਿੰਗ, ਜਾਂ ਡਿਗਰੀ ਦੀ ਮਹਾਰਤ ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ ਤਾਂ ਕਿ ਸਲੋਡਾਊਨ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ। ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਛੋਟੀ ਹੈ, ਇੱਕ ਆਸਾਨੀ ਨਾਲ ਚਲਣ ਵਾਲਾ ਡੇਟਾਬੇਸ ਕਈ ਵਾਰ ਕਾਗਜ਼ 'ਤੇ “ਪੂਰਾ ਵਿਕਲਪ” ਨਾਲੋਂ ਬਿਹਤਰ ਹੋ ਜਾਂਦਾ ਹੈ।
ਡੇਟਾਬੇਸ ਦੀਆਂ ਲਾਗਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਨ੍ਹਾਂ ਚੀਜ਼ਾਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ:
ਇੱਕ ਪਹੁੰਚ ਪੈਟਰਨ ਜੋ ਲਿਖਤਾਂ ਅਤੇ ਸੈਕੰਡਰੀ ਇੰਡੈਕਸਾਂ 'ਤੇ ਭਾਰੀ ਹੁੰਦਾ ਹੈ ਉਹ I/O ਅਤੇ ਸਟੋਰੇਜ ਨੂੰ ਗੁਣਾ ਕਰ ਸਕਦਾ ਹੈ ਭਾਵੇਂ ਡੇਟਾਸੈੱਟ ਛੋਟਾ ਹੋਵੇ।
ਪ੍ਰੋਪ੍ਰਾਇਟਰੀ ਕਵੈਰੀ ਭਾਸ਼ਾਵਾਂ, ਵਿਲੱਖਣ ਸਹੀਪਣ ਫੀਚਰ, ਜਾਂ ਸਰਵਰਲੈੱਸ “ਮੈਜਿਕ” ਡਿਲਿਵਰੀ ਤੇਜ਼ੀ ਨਾਲ ਸਪਲਾਈ ਕਰ ਸਕਦਾ ਹੈ—ਪਰ ਭਵਿੱਖ ਵਿੱਚ ਚੱਲਣ-ਫਿਰਣ ਨੂੰ ਸੀਮਤ ਕਰ ਸਕਦਾ ਹੈ। ਸੋਚੋ ਕਿ ਕੀ ਤੁਸੀਂ ਡੇਟਾ ਐਕਸਪੋਰਟ ਕਰ ਸਕਦੇ ਹੋ, ਟੈਸਟਿੰਗ ਲਈ ਲੋਕਲ ਚਲਾ ਸਕਦੇ ਹੋ, ਜਾਂ ਬਿਨਾ ਐਪ ਦੁਬਾਰਾ ਲਿਖੇ ਪ੍ਰਦਾਤਾ ਬਦਲ ਸਕਦੇ ਹੋ।
ਘੱਟੋ-ਘੱਟ, ਇਨ-ਟ੍ਰਾਂਜ਼ਿਟ/ਐਟ-ਰੈਸਟ ਇੰਕ੍ਰਿਪਸ਼ਨ, ਕੀ ਪ੍ਰਬੰਧਨ ਵਿਕਲਪ, ਆਡਿਟਿੰਗ, ਐਕਸੈੱਸ ਕੰਟਰੋਲ, ਅਤੇ ਰੀਟੈਂਸ਼ਨ ਨੀਤੀਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਅਨੁਕੂਲਤਾ ਦੀਆਂ ਲੋੜਾਂ ਅਕਸਰ “ਕਾਮਯਾਬ” ਅਤੇ “ਕਬੂਲਯੋਗ” ਵਿਚਕਾਰ ਫ਼ਰਕ ਕਰਦੀਆਂ ਹਨ, ਭਾਵੇਂ ਰੁਝਾਨ ਕਿੰਨਾ ਵੀ ਚਮਕਦਾਰ ਹੋਵੇ।
ਜਦੋਂ ਤੁਸੀਂ ਆਪਣੇ ਪਹੁੰਚ ਪੈਟਰਨ ਦਾ ਵੇਰਵਾ ਕਰ ਲੈਂਦੇ ਹੋ (ਤੁਸੀਂ ਕੀ ਪੜ੍ਹਦੇ ਹੋ, ਕੀ ਲਿਖਦੇ ਹੋ, ਕਿੰਨੀ ਵਾਰੀ, ਅਤੇ ਕਿਸ ਸਪੀਕਸ 'ਤੇ), ਤਾਂ “ਸਹੀ” ਡੇਟਾਬੇਸ ਪਰਿਵਾਰ ਆਮ ਤੌਰ 'ਤੇ ਵੱਧ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦੀ ਹੈ। ਮਕਸਦ ਸਭ ਤੋਂ ਲੋਕਪ੍ਰਿਯ ਟੂਲ ਨਹੀਂ ਜਿੱਤਣਾ—ਇਹ ਐਸਾ ਸਧਾਰਨ ਸਿਸਟਮ ਚੁਣਨਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਵਰਕਲੋਡ ਹੇਠ ਸਹੀ ਰਹੇ।
ਜਦੋਂ ਤੁਹਾਨੂੰ ਮਜ਼ਬੂਤ ਸਹੀਪਣ, ਸਪਸ਼ਟ ਰਿਸ਼ਤੇ, ਅਤੇ ਭਰੋਸੇਯੋਗ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਾਂ ਦੀ ਲੋੜ ਹੋਵੇ—ਆਰਡਰ, ਭੁਗਤਾਨ, ਇਨਵੈਂਟਰੀ, ਪਰਮੀਸ਼ਨ, ਸ਼ੈਡਿਊਲਿੰਗ—ਤਾਂ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਚੁਣੋ। ਜੇ ਤੁਸੀਂ ਅਕਸਰ ਇਕ-ਇਕਾਈਆਂ 'ਤੇ ਕੁਝ ਜੋਇਨ (“ਖੋਜੋ ਸਾਰੇ ਗ੍ਰਾਹਕ ਜਿਨ੍ਹਾਂ ਨੇ X ਖਰੀਦਿਆ ਅਤੇ Y ਵਾਪਸ ਕੀਤਾ”) ਕਰ ਰਹੇ ਹੋ, SQL ਅਤੇ ਜੋਇਨ ਸਮੇਂ ਨਾਲ ਸਧਾਰਨ ਰਹਿੰਦੇ ਹਨ।
ਇੱਕ ਆਮ ਸੂਤਰ: ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਫੇਰ ਆਪਣੇ ਕੋਡ ਵਿੱਚ ਜੋਇਨ, ਪਾਬੰਦੀਆਂ, ਅਤੇ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਾਂ ਨੂੰ ਮੁੜ-ਨਿਰਮਿਤ ਕਰਨ ਲਈ ਤਿਆਰ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਸੰਭਵਤ: ਇੱਕ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਚਾਹੀਦਾ ਹੈ।
ਦਸਤਾਵੇਜ਼ ਡੇਟਾਬੇਸ ਉਹਦੇ ਸਮੇਂ ਚੰਗਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਅਕਸਰ ਪੂਰੇ ਆਬਜੈਕਟ ਨੂੰ ਪੜ੍ਹਦੇ-ਲਿਖਦੇ ਹੋ ਜੋ ਸਹਰਣੀ ਢਾਂਚਾ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦਾ ਹੈ, ਜਿਵੇਂ ਯੂਜ਼ਰ ਪ੍ਰੋਫਾਈਲ, ਸਮੱਗਰੀ ਪੰਨੇ, ਉਤਪਾਦ ਕੈਟਾਲੌਗ ਜਿਸਦੇ ਵਿਵਰਕ ਫੀਲਡ ਹੋ ਸਕਦੇ ਹਨ, ਜਾਂ ਸੈਟਿੰਗਜ਼। ਜੇ ਤੁਹਾਡੀ ਆਮ ਕਵੈਰੀ “user_id ਦੁਆਰਾ ਪ੍ਰੋਫਾਈਲ ਲਵੋ” ਹੈ ਅਤੇ ਇਸਦੇ ਹਿੱਸਿਆਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ ਹੈ, ਤਾਂ ਦਸਤਾਵੇਜ਼ ਡੇਟਾਬੇਸ ਡਾਟਾ ਨੂੰ ਇਕੱਠੇ ਰੱਖ ਸਕਦਾ ਹੈ।
ਜਦੋਂ ਤੁਹਾਡੀਆਂ ਕਵੈਰੀਆਂ ਬਹੁਤ ਰਿਲੇਸ਼ਨਲ (ਕਈ ਡਾਕਯੂਮੈਂਟ-ਪਾਰ ਕਵੈਰੀ) ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਜਾਂ ਤੁਹਾਨੂੰ ਬਹੁ-ਇਕਾਈ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਗਰੰਟੀਜ਼ ਦੀ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਸਾਵਧਾਨ ਰਹੋ।
ਕੀ-ਵੈਲਯੂ ਸਿਸਟਮ ਕੈਸ਼ਿੰਗ, ਸੈਸ਼ਨ, ਰੇਟ ਲਿਮਿਟਸ, ਫੀਚਰ ਫਲੈਗਸ, ਅਤੇ ਛੋਟੇ ਸਮੇਂ ਵਾਲੇ ਸਟੇਟ ਲਈ ਸੁਆਹ ਹੁੰਦੇ ਹਨ ਜਿੱਥੇ ਪਹੁੰਚ ਪੈਟਰਨ “ਕੀ ਦੁਆਰਾ get/set” ਹੈ ਅਤੇ ਲੈਟੈਂਸੀ ਮਹੱਤਵਪੂਰਣ ਹੈ। ਉਹ ਅਕਸਰ ਰਿਕਾਰਡ ਦਾ ਪ੍ਰਮੁੱਖ ਸਿਸਟਮ ਨਹੀਂ ਹੁੰਦੇ।
ਜੇ ਤੁਸੀਂ ਟਿਕਾਊ ਵਪਾਰ ਡੇਟਾ ਸਟੋਰ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਸੋਚੋ ਕਿ ਐਵਿਕਸ਼ਨ, ਰੀਸਟਾਰਟ ਜਾਂ ਰੀਪਲੀਕੇਸ਼ਨ ਦੇ ਦੇਰੀ ਵਕਤ ਕੀ ਹੁੰਦੇ ਹਨ।
ਐਨਾਲਿਟਿਕਸ—ਡੈਸ਼ਬੋਰਡ, ਕੋਹੋਰਟ ਰਿਟੈਂਸ਼ਨ, ਰੈਵੇਨਿਊ ਰੋਲਅਪ, “ਗਰੁੱਪ-ਬਾਈ” ਕਵੈਰੀਜ਼ ਬੜੇ ਇਤਿਹਾਸ ਉੱਪਰ—ਕਾਲਮਾਰ/ਵੇਅਰਹਾਊਸ ਸਿਸਟਮ ਜਿੱਤਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਬਹੁਤ ਸਾਰੀਆਂ ਪੰਗਤੀਆਂ ਨੂੰ ਸਕੈਨ ਅਤੇ ਐਗਰੀਗੇਟ ਕਰਨ ਲਈ ਅਪਟਿਮਾਈਜ਼ਡ ਹੁੰਦੇ ਹਨ।
ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਵੰਡ: OLTP ਲਿਖਤਾਂ ਆਪਣੇ ਪ੍ਰਾਇਮਰੀ ਡੇਟਾਬੇਸ ਵਿੱਚ ਰੱਖੋ, ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਲਈ ਇੱਕ ਵੇਅਰਹਾਊਸ 'ਚ ਫੀਡ ਕਰੋ। ਇਸ ਨਾਲ ਚੈਕਆਉਟ ਜਿਹੜੇ ਯੂਜ਼ਰ-ਸੰਬੰਧਤ ਕਵੈਰੀਜ਼ ਨੂੰ BI ਵਰਕਲੋਡ ਨਾਲ ਠੱਲੇ ਹੋਣ ਤੋਂ ਬਚਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
ਬਹੁਤ ਸਾਰੀਆਂ ਸਫ਼ਲ ਉਤਪਾਦ "ਇੱਕ ਡੇਟਾਬੇਸ ਨਹੀਂ ਚੁਣਦੇ"। ਉਹ ਹਰ ਮੁੱਖ ਪਹੁੰਚ ਪੈਟਰਨ ਨੂੰ ਸਧਾਰਨ ਸਟੋਰੇਜ ਨਾਲ ਮੇਲ ਕਰਦੇ ਹਨ—ਭਾਵੇਂ ਇਸਦਾ ਅਰਥ ਇਹ ਹੋਵੇ ਕਿ ਦੋ ਜਾਂ ਤਿੰਨ ਡੇਟਾਬੇਸ ਇਕੱਠੇ ਵਰਤੇ ਜਾਂ।
ਇੱਕ ਆਨਲਾਈਨ ਸਟੋਰ ਅਕਸਰ ਤਿੰਨ ਬਹੁਤ ਵੱਖ-ਵੱਖ ਵਰਕਲੋਡਾਂ ਰੱਖਦਾ ਹੈ:
ਉਤਪਾਦ ਇੱਕਜੈਸੀ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਪਰ ਸਟੋਰੇਜ ਹਰ ਪਹੁੰਚ ਪੈਟਰਨ ਲਈ ਵਿਸ਼ੇਸ਼ ਹੁੰਦੀ ਹੈ।
ਇੱਕ B2B SaaS ਟੂਲ ਮੁੱਖ ਇਕਾਈਆਂ (ਪ੍ਰੋਜੈਕਟ, ਇਨਵੌਇਸ, ਟਿਕਟ) ਲੈਣ-ਦੇਣੀ ਡੇਟਾਬੇਸ ਵਿੱਚ ਰੱਖ ਸਕਦਾ ਹੈ, ਪਰ ਫਿਰ ਵੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ:
IoT ਪਲੇਟਫਾਰਮ ਬਰਸੱਟਸ ਨਾਲ ਟੈਲੀਮੇਟਰੀ ਇੰਜੈਸਟ ਕਰਦੇ ਹਨ, ਫਿਰ ਡੇਸ਼ਬੋਰਡ ਵਜੋਂ ਵਾਪਸ ਪੜ੍ਹਦੇ ਹਨ।
ਸਾਧਾਰਣ ਵੰਡ: ਹਾਲੀਆ ਡੇਟਾ ਲਈ ਤੇਜ਼ ਇੰਜੈਸਟ ਸਟੋਰ, ਰੀਟੈਂਸ਼ਨ ਲਈ ਸਸਤਾ ਲੰਬੀ ਅਵਧੀ ਸਟੋਰੇਜ, ਅਤੇ ਐਗਰੀਗੇਟ ਲਈ ਇੱਕ ਐਨਾਲਿਟਿਕਸ ਇੰਜਣ।
ਮੁੱਖ ਨਤੀਜਾ: ਜਦੋਂ ਪਹੁੰਚ ਪੈਟਰਨ ਵੱਖਰੇ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਵੱਖ-ਵੱਖ ਘਟਕ ਅਕਸਰ ਅਤੇ ਚਾਹੀਦੇ ਹਨ—ਅਤੇ ਉਹ ਅਕਸਰ ਵੱਖ-ਵੱਖ ਡੇਟਾਬੇਸ ਵਰਤਦੇ ਹਨ।
ਡੇਟਾਬੇਸ ਦੀ ਗਲਤ ਮਿਲਾਪ ਆਮ ਤੌਰ 'ਤੇ "ਛੋਟੇ" ਠੀਕ-ਕੰਮਾਂ ਦੀ ਢੇਰ ਵਜੋਂ ਸਾਹਮਣਾ ਆਉਂਦੀ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਡੇਟਾਬੇਸ ਨਾਲ ਲੜਨ ਵਿੱਚ ਜ਼ਿਆਦਾ ਸਮਾਂ ਬਿਤਾਉਂਦੀ ਹੈ ਬਜ਼ਾਏ ਨਵੇਂ ਉਤਪਾਦ ਫੀਚਰ ਬਣਾਉਣ ਦੇ, ਤਾਂ ਧਿਆਨ ਦਿਓ—ਅਕਸਰ ਇਹ ਪਹੁੰਚ-ਪੈਟਰਨ ਦੀ ਸਮੱਸਿਆ ਹੁੰਦੀ ਹੈ, ਟਿਊਨਿੰਗ ਦੀ ਨਹੀਂ।
ਕੁਝ ਚੇਤਾਵਨੀ ਨਿਸ਼ਾਨ ਮੁੜ-ਮੁੜ ਦਿਖਦੇ ਹਨ:
ਜੇ ਡੇਟਾਬੇਸ ਨੂੰ ਆਮ ਕਾਰੋਬਾਰੀ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਸਹਿਯੋਗ ਦੇਣ ਲਈ ਹੀਰੋਇਕ ਕੋਸ਼ਿਸ਼ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਵਰਕਲੋਡ ਅਤੇ ਡੇਟਾਬੇਸ ਪਰਿਵਾਰ ਸੰਭਵਤ: ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ।
ਇਕ ਡੇਟਾਬੇਸ ਚੁਣਨ ਕਿਉਂਕਿ ਉਹ ਪਾਪੁਲਰ ਹੈ, ਤੁਹਾਨੂੰ ਲੰਬੇ ਸਮੇਂ ਦੀ ਲਾਗਤਾਂ ਵਿੱਚ ਫਸਾ ਸਕਦਾ ਹੈ:
ਬਿੱਲ ਉਸ ਵੇਲੇ ਆਉਂਦਾ ਹੈ ਜਦੋਂ ਸਕੇਲ ਵਧਦਾ ਹੈ ਜਾਂ ਲੋੜਾਂ ਬਦਲਦੀਆਂ ਹਨ, ਅਤੇ ਇਕੱਲਾ ਹੱਲ ਇੱਕ ਦਰਦਨਾਕ ਰੀ-ਪ्लੈਟਫਾਰਮ ਹੁੰਦਾ ਹੈ।
ਤੁਹਾਨੂੰ ਪੂਰੀ ਆਬਜ਼ਰਵੇਬਿਲਿਟੀ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਪਰ ਕੁਝ ਸੰਕੇਤਾਂ ਦੀ ਲੋੜ ਹੈ:
ਉਪਰਲੇ ਪਹੁੰਚ ਪੈਟਰਨ ਲਿਖੋ (ਰੀਡ/ਰਾਈਟ, ਮੁੱਖ ਕਵੈਰੀਜ਼, ਪੀਕ ਦਰ), ਡੇਟਾ ਵਾਲੀਅਮ ਅਨੁਮਾਨ, ਅਤੇ “ਨਾਨ-ਨੇਗੋਸ਼ੀਏਬਲ” (ਸਹੀਪਣ, ਉਪਲੱਬਧਤਾ, ਰੀਜਨ ਸੀਮਾਵਾਂ)। ਡੈਸ਼ਬੋਰਡਾਂ ਅਤੇ ਸਭ ਤੋਂ ਭਿਆਨਕ ਕਵੈਰੀਜ਼ ਦੇ ਨਮੂਨੇ ਜੋੜੋ। ਉਹ ਛੋਟਾ ਰਿਕਾਰਡ ਭਵਿੱਖ ਦੇ ਫੈਸਲਿਆਂ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ—ਅਤੇ ਇਹ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ ਕਿ ਕਦੋਂ ਡੇਟਾਬੇਸ ਹਾਲਤ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।
ਫਿਊਚਰ-ਪ੍ਰੂਫ਼ ਕਰਨਾ ਦਿਨ ਇੱਕ "ਸਭ ਤੋਂ ਸਕੇਲਯੋਗ" ਡੇਟਾਬੇਸ ਚੁਣਨ ਦਾ ਮਤਲਬ ਨਹੀਂ। ਇਹ ਉਹ ਸੋਚ-ਸਮਝ ਕੇ ਚੋਣਾਂ ਕਰਨ ਬਾਰੇ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਬਦਲਦੀਆਂ ਪਹੁੰਚ ਪੈਟਰਨਾਂ ਦੇ ਸਮੇਂ ਚੁਸਤ ਰੱਖਣ।
ਜੇ ਤੁਹਾਡਾ ਵਰਕਲੋਡ ਮੁੱਖ ਤੌਰ 'ਤੇ ਲੈਣ-ਦੇਣ ਅਤੇ ਸਧਾਰਣ ਕਵੈਰੀਜ਼ ਹੈ, ਤਾਂ ਇੱਕ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਅਕਸਰ ਭਰੋਸੇਯੋਗ ਉਤਪਾਦ ਤੱਕ ਪਹੁੰਚਣ ਦਾ ਤੇਜ਼ ਰਸਤਾ ਹੁੰਦਾ ਹੈ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਹੈ ਸ਼ਿਪ ਕਰਨ ਦਾ ਵਿਸ਼ਵਾਸ: ਪ੍ਰਡਿਕਟੇਬਲ ਪ੍ਰਦਰਸ਼ਨ, ਸਪਸ਼ਟ ਸਹੀਪਣ ਗਾਰੰਟੀਆਂ, ਅਤੇ ਟੀਮ ਲਈ ਜਾਣੂ ਟੂਲਿੰਗ।
“ਭਵਿੱਖ-ਪ੍ਰੂਫ” ਦਾ ਅਰਥ ਇੱਥੇ ਇਹ ਹੈ ਕਿ ਸ਼ੁਰੂ ਵਿੱਚ ਵਾਪਸੀਯੋਗ ਵਚਨਬੱਧਤਾਵਾਂ ਤੋਂ ਬਚੋ—ਜਿਵੇਂ ਇੱਕ ਮਾਹਿਰ ਸਟੋਰ ਅਪਣਾਉਣਾ ਪਹਿਲਾਂ, ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਇਸ ਦੀ ਲੋੜ ਸਿੱਧ ਨਾ ਕਰੋ।
ਇੱਕ ਖ਼ਾਸ ਡੇਟਾ ਐਕਸੈੱਸ ਲੇਅਰ (ਜਾਂ ਸਰਵਿਸ ਬਾਊਂਡਰੀ) ਬਣਾਓ ਤਾਂ ਕਿ ਐਪ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਡੇਟਾਬੇਸ-ਖਾਸ ਕਵਿਰਕਸ 'ਤੇ ਨਿਰਭਰ ਨਾ ਰਹੇ। ਕਵੈਰੀ ਲੋਜਿਕ ਕੇਂਦਰਿਤ ਰੱਖੋ, ਅੱਖਰ ਜੀ-ਇਨਪੁੱਟ/ਆਉਟਪੁੱਟ ਕਾਂਟ੍ਰੈਕਟ ਤਯਾਰ ਕਰੋ, ਅਤੇ ਸਕੀਮਾ ਬਦਲਾਅ ਨੂੰ ਸਧਾਰਨ ਵਿਕਾਸ ਦਾ ਹਿੱਸਾ ਮਾਨੋ।
ਕੁਝ ਪ੍ਰਾਇਕਟਿਕ ਆਦਤਾਂ ਜੋ ਬਾਅਦ ਦੀਆਂ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ:
ਕਈ ਉਤਪਾਦ ਆਖਿਰਕਾਰ ਦੋ ਰਾਹਾਂ ਦੀ ਲੋੜ ਹੋਂਦੇ ਹਨ: ਦੈਨੀਕ ਲੈਨ-ਦੇਨ ਲਈ OLTP ਅਤੇ ਰਿਪੋਰਟਿੰਗ/ਐਕਸਪੇਰੀਮੇਟੇਸ਼ਨ ਲਈ ਐਨਾਲਿਟਿਕਸ। ਜਦੋਂ ਐਨਾਲਿਟਿਕਲ ਕਵੈਰੀਆਂ ਪ੍ਰੋਡਕਸ਼ਨ ਲੈਟੈਂਸੀ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਣ ਲੱਗਦੀਆਂ ਹਨ, ਜਾਂ ਜਦੋਂ ਤੁਹਾਨੂੰ ਵੱਖਰੇ ਰੀਟੈਂਸ਼ਨ/ਪਾਰਟੀਸ਼ਨਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਦ ਆਪਕਾਰ ਕਰੋ।
ਇਨ੍ਹਾ ਨੂੰ ਸੰਰੇਖਿਤ ਰੱਖਣ ਲਈ, ਇਵੈਂਟ/ਡੇਟਾ ਪਰਿਭਾਸ਼ਾਵਾਂ ਨੂੰ ਮਿਆਰੀ ਬਣਾਓ, ਪਾਈਪਲਾਈਨਾਂ ਆਟੋਮੇਟ ਕਰੋ, ਅਤੇ ਸਿਸਟਮਾਂ ਵਿਚਕਾਰ ਵਿਕਰੀ ਦੀ ਜਿਨ੍ਹਾਂ ਕੋਠੀ (ਉਦਾਹਰਣ: ਰੋਜ਼ਾਨਾ ਵਿਕਰੀs) ਨੂੰ ਮਿਲਾਉ। ਇਸ ਤਾਂ “ਸੱਚ” ਖੰਡ-ਭਾਗ ਨਾ ਹੋਵੇ।
ਜੇ ਤੁਸੀਂ ਇਕ ਠੋਸ ਅਗਲਾ ਕਦਮ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਹਲਕੀ-ਫੁਲਕੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਯੋਜਨਾ ਟੈਂਪਲੇਟ ਬਣਾਓ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਦੁਆਰਾ ਦੁਬਾਰਾ ਵਰਤੀ ਜਾ ਸਕੇ: /blog/database-migration-checklist.
ਇੱਕ access pattern ਉਹ ਦੁਹਰਾਉਣ ਯੋਗ ਢੰਗ ਹੈ ਜਿਸ ਨਾਲ ਤੁਹਾਡੀ ਐਪ ਉਤਪਾਦਨ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਛੂਹਦੀ ਹੈ: ਕੀ ਪੜ੍ਹਦੀ/ਲਿਖਦੀ ਹੈ, ਕਿੰਨੀ ਵਾਰੀ, ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ, ਅਤੇ ਕਿਸ ਨੁਮੂਨੇ ਦੇ ਕਵੈਰੀਜ਼ (ਪੌਇੰਟ ਲੁੱਕਅੱਪ, ਰੇਂਜ ਸਕੈਨ, ਜੋਇਨ, ਐਗਰੀਗੇਸ਼ਨ, ਟਾਈਮ ਵਿੰਡੋ ਆਦਿ)। ਇਹ “ਸਾਡੇ ਕੋਲ ਯੂਜ਼ਰ ਅਤੇ ਆਰਡਰ ਹਨ” ਵਾਲੀ ਜਾਣਕਾਰੀ ਨਾਲੋਂ ਕਾਮਯਾਬ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਸਿੱਧਾ ਇੰਡੈਕਸ, ਸਕੀਮਾ ਚੋਣਾਂ ਅਤੇ ਡੇਟਾਬੇਸ ਦੀ ਫਿਟ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ।
ਕਿਉਂਕਿ “ਲੋਕਪ੍ਰਿਯ” ਹੋਣਾ ਹੋਰ ਟੀਮਾਂ ਦੀਆਂ ਪਾਬੰਦੀਆਂ, ਬਜਟ ਅਤੇ ਰਿਸਕ ਸਹਨਸ਼ੀਲਤਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ—ਤੁਹਾਨੂੰ ਨਹੀਂ। ਇੱਕੋ ਡੇਟਾਬੇਸ ਇੱਕ ਵਰਕਲੋਡ ਲਈ ਸ਼ਾਨਦਾਰ ਹੋ ਸਕਦਾ ਹੈ (ਜਿਵੇਂ OLTP) ਅਤੇ ਦੂਜੇ ਲਈ ਦੁਖਦਾਈ (ਭਾਰੀ ਐਨਾਲਿਟਿਕਸ ਸਕੈਨ)। ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀਆਂ ਸ਼ਾਨਦਾਰ 5–10 ਰੀਡਸ ਅਤੇ ਰਾਈਟਸ ਲਿਖੋ, ਫਿਰ ਉਹਨਾਂ ਆਧਾਰ 'ਤੇ ਟੇਕنالੋਜੀ ਦਾ ਮੁਕਾਬਲਾ ਕਰੋ—ਬ੍ਰਾਂਡ ਦੀ ਗਰਮੀ ਨਹੀਂ।
ਲਿਖੋ:
ਇਹ ਤੁਹਾਡੇ ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਲਈ ਇੱਕ ਚੰਗਾ ਰਿਕੁਆਇਰਮੈਂਟ ਡੌਕ ਬਣ ਜਾਂਦਾ ਹੈ।
OLTP ਉਹ ਦਿਨ-ਚਰਿਆ ਹੈ ਜਿਸ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ, ਇੱਕ-ਦੂਜੇ ਨਾਲ ਸਮਾਂਤਰੀ ਪੜ੍ਹਨ/ਲਿਖਣ ਹੁੰਦੇ ਹਨ ਅਤੇ ਕਾਰਜਾਂ ਦੀ ਸਹੀਤਾ ਅਹਮ ਹੁੰਦੀ ਹੈ (ਚੈਕਆਉਟ, ਇਨਵੈਂਟਰੀ ਅੱਪਡੇਟ)।
OLAP/ਐਨਾਲਿਟਿਕਸ ਓਥੇ ਘੱਟ ਕਵੈਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਪਰ ਹਰ ਇੱਕ ਬਹੁਤ ਸਾਰਾ ਡੇਟਾ ਛੂਹਦੀ ਹੈ (ਸਕੈਨ, ਗਰੂਪ-ਬਾਈ, ਡੈਸ਼ਬੋਰਡ) ਅਤੇ ਸਕਿੰਡ-ਪੱਧਰੀ ਲੈਟੈਂਸੀ ਮਨਜ਼ੂਰ ਹੋ ਸਕਦੀ ਹੈ।
ਇਨ੍ਹਾ ਨੂੰ ਇੱਕੋ ਸਿਸਟਮ 'ਤੇ ਮਿਲਾ ਦੇਣ ਨਾਲ ਅਕਸਰ ਐਨਾਲਿਟਿਕਸ ਸਕੈਨ ਯੂਜ਼ਰ-ਫੇਸਿੰਗ ਲੈਟੈਂਸੀ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੇ ਹਨ।
p95/p99 ਲੈਟੈਂਸੀ ਦੇਖੋ—ਸਰਵਸਾਮਾਨ ਨਹੀਂ। ਜੇ 99 ਰਿਕਵੈਸਟ 50 ms ਵਿੱਚ ਖਤਮ ਹੋ ਰਹੇ ਹਨ ਪਰ 1 ਰਿਕਵੈਸਟ 2 ਸਕਿੰਟ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਔਸਤ ਠੀਕ ਲੱਗੇਗਾ ਪਰ ਯੂਜ਼ਰ ਅਜੇ ਵੀ ਐਪ ਨੂੰ ਧੀਰਾ ਮਹਿਸੂਸ ਕਰਨਗੇ।
ਪ੍ਰਾਈਕਟਿਕਲ ਸੁਝਾਅ: ਲਾਂਚ, ਚੈਕਆਉਟ ਅਤੇ ਖੂਬਦੀਰ ਐਂਡਪਾਇੰਟਾਂ ਲਈ ਪ95/ਪ99 ਟ੍ਰੈਕ ਕਰੋ ਅਤੇ ਸਪੀਕਾਂ ਨੂੰ ਡੇਟਾਬੇਸ ਮੈਟ੍ਰਿਕਸ (ਲਾਕਸ, ਰੀਪਲੀਕੇਸ਼ਨ ਲੈਗ, I/O) ਨਾਲ ਜੋੜੋ।
ਅਕਸਰ ਉਹਨਾਂ ਦੇ ਵੱਖਰੇ ਲੋੜਾਂ ਹੁੰਦੀਆਂ ਹਨ:
ਮਾਹਿਰ ਸਟੋਰ ਵਰਤਣਾ ਅਕਸਰ ਜ਼ਿਆਦਾ ਸੌਖਾ ਹੁੰਦਾ ਹੈ ਬਜਾਏ ਕਿ ਇੱਕ ਡੇਟਾਬੇਸ ਨੂੰ ਸਭ ਕੁਝ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਨ ਦੇ।
ਕੈਸ਼ਿੰਗ ਪਾਠ-ਭਾਰ ਵਾਲੀਆਂ ਵਰਕਲੋਡਜ਼ ਨੂੰ ਛੁਪਾ ਸਕਦੀ ਹੈ—ਪਰ ਜਦੋਂ ਕੈਸ਼ ਮਿਸ ਜਾਂ ਪੁਰਜ ਹੁੰਦਾ ਹੈ ਤਾਂ ਸੱਚੀ ਸਮੱਸਿਆ ਸਾਹਮਣੇ ਆਉਂਦੀ ਹੈ।
ਸੋਚੋ:
ਕੈਸ਼ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਛੁਪਾ ਸਕਦਾ ਹੈ ਪਰ ਮਿਸਜ਼ ਨੇ ਡੇਟਾਬੇਸ ਤੇ ਹੜਤਾਲ ਲਾ ਸਕਦੇ ਹਨ।
ਸਖ਼ਤ ਸਹੀਪਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਲਿਖਤਾਂ ਲਈ ਗੈਰ-ਅਧੂਰੀ ਅਵਸਥਾਵਾਂ ਨਹੀਂ ਦੇਖਣਾ ਚਾਹੁੰਦੇ—ਖਾਸ ਕਰਕੇ ਭੁਗਤਾਨ, ਬੈਲੈਂਸ ਅਤੇ ਰਿਜ਼ਰਵੇਸ਼ਨ ਲਈ।
ਇਸ ਦੇ ਵਪਸੇਦਿਆਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋ ਸਕਦਾ ਹੈ:
ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਤੁਹਾਡੀ ਸਵੈਗਤ ਡੇਟਾ ਕਿਸ ਨੂੰ “ਕਦੇ ਵੀ ਗਲਤ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ” ਅਤੇ ਕਿਸ ਨੂੰ ਥੋੜ੍ਹੀ ਸਟੇਲਨੈੱਸ ਸਹਿਣਯੋਗ ਹੈ, ਇਹ ਨਿਰਧਾਰਿਤ ਕਰੋ।
ਇੰਡੈਕਸਿੰਗ ਤੁਹਾਡੇ ਵਰਕਲੋਡ ਅਤੇ ਡੇਟਾਬੇਸ ਦਰਮਿਆਨ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਸਮਝੌਤਾ ਹੈ। ਅਕਸਰ:
ਲਕੜੀ: ਤੁਸੀਂ ਜੋ ਵਾਸਤਵ ਵਿੱਚ ਅਕਸਰ ਕਰਦੇ ਹੋ, ਉਨ੍ਹਾਂ ਨੂੰ ਇੰਡੈਕਸ ਕਰੋ, ਨਾ ਕਿ ਹਰ ਚੀਜ਼ ਨੂੰ।
ਇੱਕ PoC ਨੂੰ ਇੱਕ ਛੋਟੀ ਪ੍ਰੋਡਕਸ਼ਨ ਰਿਹਰਸਲ ਵਾਂਗ ਲ treatੋ:
ਜੇ ਕਿਸੇ ਉਮੀਦਵਾਰ ਨੇ PoC ਵਿੱਚ ਕਿਸੇ ਬਹੁਤ ਜ਼ਰੂਰੀ ਗੱਲ ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕੀਤਾ, ਤਾਂ ਇਸਨੂੰ ਜਲਦੀ ਹੀ ਹਟਾ ਦਿਓ।