ਇਸ ਲੇਖ ਵਿੱਚ Michael Stonebraker ਦੇ ਮੁੱਖ ਵਿਚਾਰ—Ingres, Postgres, Vertica—ਤੇ ਚਰਚਾ ਕੀਤੀ ਗਈ ਹੈ ਅਤੇ ਦਿਖਾਇਆ ਗਿਆ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਨੇ SQL ਡੇਟਾਬੇਸ, ਐਨਾਲਿਟਿਕਸ ਇੰਜਨਾਂ ਅਤੇ ਆਧੁਨਿਕ ਡੇਟਾ ਸਟੈਕ ਨੂੰ ਕਿਵੇਂ ਰੂਪ ਦਿੱਤਾ।
Michael Stonebraker ਇੱਕ ਕਮਪਿਊਟਰ ਸਾਇੰਟਿਸਟ ਹਨ ਜਿਨ੍ਹਾਂ ਦੇ ਪ੍ਰੋਜੈਕਟਸ ਸਿਰਫ਼ ਡੇਟਾਬੇਸ ਰਿਸਰਚ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦੇ—ਉਹਨੇ ਉਨ੍ਹਾਂ ਉਤਪਾਦਾਂ ਅਤੇ ਡਿਜ਼ਾਈਨ ਪੈਟਰਨਾਂ ਨੂੰ ਸਿੱਧਾ ਆਕਾਰ ਦਿੱਤਾ ਜੋ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਹਰ ਰੋਜ਼ ਵਰਤਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਕਦੇ ਕੋਈ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ, ਐਨਾਲਿਟਿਕਸ ਵੇਅਰਹਾਊਸ ਜਾਂ ਸਟ੍ਰੀਮਿੰਗ ਸਿਸਟਮ ਵਰਤਿਆ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉਹਨਾਂ ਵਿਚਾਰਾਂ ਤੋਂ ਲਾਭ ਉਠਾ ਚੁੱਕੇ ਹੋ ਜੋ ਉਨ੍ਹਾਂ ਨੇ ਸਾਬਤ, ਬਣਾਏ ਜਾਂ ਲੋਕਪ੍ਰਿਯ ਬਣਾਏ।
ਇਹ ਕੋਈ ਜੀਵਨੀ ਜਾਂ ਅਕਾਦਮਿਕ ਡੇਟਾਬੇਸ ਸਿਧਾਂਤ ਦੀ ਸੈਰ ਨਹੀਂ ਹੈ। ਇਸ ਦੀ ਥੀਮ ਇਹ ਹੈ ਕਿ Stonebraker ਦੀਆਂ ਮੁੱਖ ਪ੍ਰਣਾਲੀਆਂ (ਜਿਵੇਂ Ingres, Postgres, ਅਤੇ Vertica) ਕਿਵੇਂ ਆਧੁਨਿਕ ਡੇਟਾ ਸਟੈਕ ਵਿੱਚ ਦਿੱਖ ਰਹੀਆਂ ਚੋਣਾਂ ਨਾਲ ਜੁੜਦੀਆਂ ਹਨ:
ਇੱਕ ਆਧੁਨਿਕ ਡੇਟਾਬੇਸ ਉਹ ਕੋਈ ਵੀ ਪ੍ਰਣਾਲੀ ਹੈ ਜੋ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਕਰ ਸਕਦੀ ਹੈ:
ਵੱਖ-ਵੱਖ ਡੇਟਾਬੇਸ ਇਹਨਾਂ ਲਕਸ਼ਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਅਪਟਾਈਮ ਕਰਦੇ ਹਨ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਲ ਐਪਸ, BI ਡੈਸ਼ਬੋਰਡਾਂ ਅਤੇ ਰੀਅਲ-ਟਾਈਮ ਪਾਈਪਲਾਈਨਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹੋ।
ਅਸੀਂ ਕਾਰਗੁਜ਼ਾਰੀ ਤੇ ਧਿਆਨ ਦੇਵਾਂਗੇ: ਉਹ ਵਿਚਾਰ ਜੋ ਅੱਜ ਦੇ “ਵੇਅਰਹਾਊਸ + ਲੇਕ + ਸਟਰੀਮ + ਮਾਇਕਰੋਸਰਵਿਸز” ਦੁਨੀਆ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਜੋ ਤੁਸੀਂ ਖਰੀਦਦੇ, ਬਣਾਉਂਦੇ ਅਤੇ ਚਲਾਂਦੇ ਹੋ, ਉਹਨਾਂ 'ਤੇ ਉਹਨਾਂ ਦਾ ਪ੍ਰਭਾਵ। ਸਪੱਸ਼ਟ ਸਪਸ਼ਟੀਕਰਨ, ਟਰੇਡ-ਆਫ਼ ਅਤੇ ਰੀਅਲ-ਵਰਲਡ ਨਤੀਜੇ ਉਮੀਦ ਕਰੋ—ਪਰ ਗਹਿਰਾਈ ਵਾਲੇ ਸਬੂਤ ਜਾਂ ਇੰਪਲੀਮੇਂਟੇਸ਼ਨ ਦੇ ਵੇਰਵੇ ਨਹੀਂ।
Stonebraker ਦਾ ਕੈਰੀਅਰ ਸਮਝਣਾ ਸਭ ਤੋਂ ਅਸਾਨ ਹੈ ਜਿਵੇਂ ਕਿ ਖਾਸ ਨੌਕਰੀਆਂ ਲਈ ਬਣਾਈਆਂ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਇੱਕ ਲੜੀ—ਅਤੇ ਫਿਰ ਵੇਖਣਾ ਕਿ ਸਭ ਤੋਂ ਵਧੀਆ ਵਿਚਾਰ ਕਿਵੇਂ ਮੁੱਖ ਧਾਰਾ ਉਤਪਾਦਾਂ ਵਿੱਚ ਦਾਖਿਲ ਹੋਏ।
Ingres ਇੱਕ ਅਕਾਦਮਿਕ ਪ੍ਰੋਜੈਕਟ ਵਜੋਂ ਸ਼ੁਰੂ ਹੋਇਆ ਜਿਸ ਨੇ ਸਾਬਤ ਕੀਤਾ ਕਿ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਤੀਵੇਂ ਅਤੇ ਕਾਰਗਰ ਹੋ ਸਕਦੇ ਹਨ, ਸਿਰਫ਼ ਸਿਧਾਂਤ ਨਹੀਂ। ਇਸ ਨੇ SQL-ਸਟਾਈਲ ਕੁਐਰੀਅੰਗ ਅਤੇ ਕਾਟ-ਆਧਾਰਿਤ ਅਪਟੀਮਾਈਜੇਸ਼ਨ ਵਿਚਾਰਧਾਰਾ ਨੂੰ ਲੋਕਪ੍ਰਿਯ ਬਣਾਇਆ ਜੋ ਬਾਅਦ ਵਿੱਚ ਕਾਮਰਸ਼ਲ ਇੰਜਨਾਂ ਵਿੱਚ ਸਧਾਰਨ ਬਣ ਗਈ।
Postgres (ਜੋ ਅਨੁਸੰਧਾਨੀ ਪ੍ਰਣਾਲੀ ਸੀ ਅਤੇ ਜਿਹੜੀ PostgreSQL ਨਾਲ ਅੱਗੇ ਗਈ) ਇੱਕ ਵੱਖਰਾ ਦਾਅ ਪੇਸ਼ ਕਰਦੀ ਸੀ: ਡੇਟਾਬੇਸ ਨੂੰ ਫਿਕਸਡ-ਫੰਕਸ਼ਨ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਤੁਹਾਨੂੰ ਨਵੇਂ ਡੇਟਾ ਟਾਈਪ, ਨਵੇਂ ਇੰਡੈਕਸ ਮੈਥਡ, ਅਤੇ ਹੋਰ ਵਿਵਹਾਰ ਬਿਨਾਂ ਪੂਰੇ ਇੰਜਨ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖੇ ਜੋੜਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ।
ਅਕਸਰ “ਆਧੁਨਿਕ” ਫੀਚਰ ਇਸ ਯੁੱਗ ਤੱਕ ਵਾਪਸ ਜਾਂਦੇ ਹਨ—ਵਿਸਥਾਰਯੋਗ ਟਾਈਪ, ਉਪਭੋਗਤਾ-ਪਰਿਭਾਸ਼ਿਤ ਫੰਕਸ਼ਨ, ਅਤੇ ਐਕਸਟਰੈਂਸਨ ਜੋ ਭਾਰ ਨੂੰ ਬਦਲਣ ਦੇ ਅਨੁਕੂਲ ਹੋਣ।
ਜਿਵੇਂ-ਜਿਵੇਂ ਐਨਾਲਿਟਿਕਸ ਵਧੇ, ਰੋਅ-ਅਧਾਰਿਤ ਸਿਸਟਮ ਵੱਡੀਆਂ ਸਕੈਨਾਂ ਅਤੇ ਐਗਰੀਗੇਸ਼ਨਾਂ ਨਾਲ ਮੁਸ਼ਕਲ ਮਹਿਸੂਸ ਕਰਨ ਲੱਗੇ। Stonebraker ਨੇ ਕਾਲਮਰ ਸਟੋਰੇਜ ਅਤੇ ਇਸ ਨਾਲ ਸਬੰਧਤ ਤਕਨੀਕਾਂ ਨੂੰ ਅੱਗੇ ਵਧਾਇਆ—ਜੋ ਕੇਵਲ ਲੋੜੀਂਦੇ ਕਾਲਮਾਂ ਨੂੰ ਪੜ੍ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਪ੍ਰੈੱਸ ਕਰਨ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹਨ—ਇਹ ਵਿਚਾਰ ਹੁਣ ਐਨਾਲਿਟਿਕਸ ਡੇਟਾਬੇਸ ਅਤੇ ਕਲਾਉਡ ਵੇਅਰਹਾਊਸ ਵਿੱਚ ਮਿਆਰੀ ਹਨ।
Vertica ਨੇ ਕਾਲਮ-ਸਟੋਰ ਰਿਸਰਚ ਵਿਚਾਰਾਂ ਨੂੰ ਇੱਕ ਵਣਜਯੋਗ massively parallel processing (MPP) SQL ਇੰਜਨ ਵਿੱਚ ਲਿਆ ਦਿੱਤਾ ਜੋ ਵੱਡੀਆਂ ਐਨਾਲਿਟਿਕ ਕੁਐਰੀਆਂ ਲਈ ਬਣਾਇਆ ਗਿਆ। ਇਹ ਪੈਟਰਨ ਉਦਯੋਗ 'ਚ ਦੁਹਰਾਇਆ ਗਿਆ: ਇੱਕ ਰਿਸਰਚ ਪ੍ਰੋਟੋਟਾਈਪ ਇੱਕ ਅਹੰਕਾਰ ਸਾਬਤ ਕਰਦਾ ਹੈ; ਇੱਕ ਉਤਪਾਦ ਇਸ ਨੂੰ ਭਰੋਸੇਯੋਗਤਾ, ਟੂਲਿੰਗ, ਅਤੇ ਗਾਹਕ-ਮੁਕਾਬਲੇ ਨਾਲ ਮਜ਼ਬੂਤ ਕਰਦਾ ਹੈ।
ਬਾਅਦ ਦੀ ਕੰਮ ਸਟ੍ਰੀਮ ਪ੍ਰੋਸੈਸਿੰਗ ਅਤੇ ਵਰਕਲੋਡ-ਖਾਸ ਇੰਜਨਾਂ ਵੱਲ ਫੈਲੀ—ਕਹਿਣਾ ਕਿ ਇਕ ਸਰਬ-ਉਦੇਸ਼ਯ ਡੇਟਾਬੇਸ ਕਈ ਥਾਵਾਂ ਤੇ ਜਿੱਤ ਨਹੀਂ ਸਕਦਾ।
ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਜਲਦੀ ਕਿਰਿਆ-ਪ੍ਰਤਿਆਸ਼ਾ ਜਾਂਚਣ ਲਈ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ; ਇੱਕ ਉਤਪਾਦ ਨੂੰ ਓਪਰੇਬਿਲਟੀ ਨੂੰ ਤਰਜੀਹ ਦੇਣੀ ਪੈਂਦੀ ਹੈ: ਅਪਡੇਟ, ਮੋਨਿਟਰਿੰਗ, ਸੁਰੱਖਿਆ, ਪੇਸ਼ਗੀ ਪ੍ਰਦਰਸ਼ਨ, ਅਤੇ ਸਪੋਰਟ। Stonebraker ਦਾ ਪ੍ਰਭਾਵ ਇਸ ਲਈ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਕਈ ਪ੍ਰੋਟੋਟਾਈਪ ਵਿਚਾਰ ਵਪਾਰਕ ਡੇਟਾਬੇਸਾਂ ਵਿੱਚ ਡਿਫ਼ੋਲਟ ਸਮਰੱਥਾਵਾਂ ਵਜੋਂ ਸ਼ਾਮਲ ਹੋ ਗਏ।
Ingres (ਛੋਟਾ ਨਾਮ INteractive Graphics REtrieval System) Stonebraker ਦੀ ਪਹਿਲੀ ਸਾਬਤ ਕਰਨ ਵਾਲੀ ਪ੍ਰਣਾਲੀ ਸੀ ਕਿ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਸੁੰਦਰ ਸਿਧਾਂਤ ਹੀ ਨਹੀਂ—ਇੱਕ ਕਾਰਗਰ ਹੱਲ ਵੀ ਹੋ ਸਕਦਾ ਹੈ। ਉਸ ਸਮੇਂ ਬਹੁਤ ਸਾਰੀਆਂ ਪ੍ਰਣਾਲੀਆਂ ਕਸਟਮ ਐਕਸੈੱਸ ਮੈਥਡ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ-ਨਿਰਧਾਰਤ ਡੇਟਾ ਰਾਹਾਂ 'ਤੇ ਬਣੀਆਂ ਸਨ।
Ingres ਨੇ ਇਹ ਸਿੰਪਲ ਕਾਰੋਬਾਰੀ-ਫ੍ਰੈਂਡਲੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ:
ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ ਕਿ ਲੋਕ ਡੇਟਾ ਦੇ ਫਲੈਕਸਿਬਲ ਸਵਾਲ ਪੁੱਛ ਸਕਣ ਬਿਨਾਂ ਹਰ ਵਾਰੀ ਸਾਫਟਵੇਅਰ ਦੁਬਾਰਾ ਲਿਖਣ ਦੇ।
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਇਹ ਦਾਅਵਾ ਕਰਦੇ ਸਨ ਕਿ ਤੁਸੀਂ ਕੀ ਚਾਹੁੰਦੇ ਹੋ ਵੇਖਾ ਸਕਦੇ ਹੋ (ਜਿਵੇਂ “California ਵਿੱਚ ਓਵਰਡਿਊ ਇਨਵਾਇਸ ਵਾਲੇ ਗ੍ਰਾਹਕ”), ਬਜਾਏ ਇਸਦੇ ਕਿ ਤੁਸੀਂ ਕਦਮ-ਦਰ-ਕਦਮ ਕਿਵੇਂ ਫੈਚ ਕਰਨਾ ਹੈ ਦੱਸੋ। ਪਰ ਇਹ ਵਾਅਦਾ ਅਮਲ ਵਿੱਚ ਲਿਆਉਣ ਲਈ ਇੱਕ ਐਸੀ ਪ੍ਰਣਾਲੀ ਦੀ ਲੋੜ ਸੀ ਜੋ:
Ingres ਉਸ “ਪ੍ਰਯੋਗਿਕ” ਰਿਲੇਸ਼ਨਲ ਕਮਪਿਊਟਿੰਗ ਵੱਲ ਇੱਕ ਵੱਡਾ ਕਦਮ ਸੀ—ਅਜਿਹੇ ਹਾਰਡਵੇਅਰ 'ਤੇ ਚੱਲ ਸਕਣ ਵਾਲਾ ਅਤੇ ਫਿਰ ਵੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਮਹਿਸੂਸ ਕਰਨ ਵਾਲਾ।
Ingres ਨੇ ਇਹ ਵਿਚਾਰ ਲੋਕਪ੍ਰਿਯ ਬਣਾਇਆ ਕਿ ਡੇਟਾਬੇਸ ਨੂੰ ਕੁਐਰੀਆਂ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣ ਦਾ ਭਾਰ ਆਪਣੇ ਉੱਤੇ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ। ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਹਰ ਡੇਟਾ ਐਕਸੈੱਸ ਪਾਥ ਨੂੰ ਹੱਥੋਂ-ਹੱਥ ਟਿਊਨ ਕਰਨ ਦੀ ਬਜਾਏ, ਸਿਸਟਮ ਇਸ ਗੱਲ ਨੂੰ ਚੁਣ ਸਕਦਾ ਸੀ ਕਿ ਕਿਹੜੀ ਟੇਬਲ ਪਹਿਲਾਂ ਪੜ੍ਹੀ ਜਾਵੇ, ਕਿਹੜੇ ਇੰਡੈਕਸ ਵਰਤੇ ਜਾਣ, ਅਤੇ ਕਿਵੇਂ ਜੋਇਨ ਕੀਤੇ ਜਾਣ।
ਇਸ ਨਾਲ SQL-ਸਟਾਈਲ ਸੋਚ ਫੈਲੀ: ਜਦੋਂ ਤੁਸੀਂ ਡਿਕਲੇਰੇਟਿਵ ਕੁਐਰੀ ਲਿਖ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਇਤਰਾਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਲੋਕ—ਅਨਾਲਿਸਟ, ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ, ਫਾਇਨੈਂਸ—ਬਿਨਾਂ ਬੇਸਪੋਕ ਰਿਪੋਰਟਾਂ ਦੀ ਉਡੀਕ ਕੀਤੇ ਹੀ ਸਵਾਲ ਪੁੱਛ ਸਕਦੇ ਹਨ।
ਵੱਡਾ ਕਾਰਗਰ ਸਿੱਧਾਂਤ ਹੈ cost-based optimization: ਡੇਟਾ ਬਾਰੇ ਆਂਕੜਿਆਂ ਦੇ ਅਧਾਰ 'ਤੇ ਸਭ ਤੋਂ ਘੱਟ ਉਮੀਦਿਤ “ਲਾਗਤ” (ਆਮ ਤੌਰ 'ਤੇ I/O, CPU, ਅਤੇ ਮੈਮੋਰੀ ਦਾ ਮੁਕਾਬਲਾ) ਵਾਲੀ ਯੋਜਨਾ ਚੁਣੋ।
ਇਹ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਅਕਸਰ ਇਸਦਾ ਨਤੀਜਾ ਹੁੰਦਾ ਹੈ:
Ingres ਨੇ ਹਰ ਹਿੱਸੇ ਨੂੰ ਅਵਿਸਕਾਰ ਨਹੀਂ ਕੀਤਾ, ਪਰ ਇਹ ਪੈਟਰਨ ਸੈਟ ਕੀਤਾ ਕਿ SQL + ਇੱਕ ਅਪਟੀਮਾਈਜ਼ਰ ਉਹੀ ਚੀਜ਼ ਹੈ ਜੋ ਰਿਲੇਸ਼ਨਲ ਸਿਸਟਮਾਂ ਨੂੰ “ਚੰਗੇ ਵਿਚਾਰ” ਤੋਂ ਰੋਜ਼ਾਨਾ ਦੇ ਯੰਤਰ ਤੱਕ ਵਧਾਉਂਦੀ ਹੈ।
ਸ਼ੁਰੂਆਤੀ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਅਕਸਰ ਇਕ ਨਿਰਧਾਰਤ ਡੇਟਾ ਟਾਈਪਾਂ (ਨੰਬਰ, ਟੈਕਸਟ, ਤਾਰੀਖ) ਅਤੇ ਨਿਰਧਾਰਤ ਓਪਰੇਸ਼ਨਾਂ (ਫਿਲਟਰ, ਜੋਇਨ, ਐਗਰੀਗੇਟ) ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਸਨ। ਪਰ ਜਦੋਂ ਟੀਮਾਂ ਨਵੇਂ ਕਿਸਮ ਦੇ ਡੇਟਾ (ਜਿਵੇਂ geospatial, ਲੌਗ, ਟਾਈਮ-ਸਿਰੀਜ਼) ਸਟੋਰ ਕਰਨ ਲੱਗੀਆਂ ਜਾਂ ਵਿਸ਼ੇਸ਼ਤੀ ਕਾਰਗਰਤਾ ਦੀ ਲੋੜ ਪਈ, ਤਾਂ ਸਖਤ ਡਿਜ਼ਾਈਨ ਇੱਕ ਮਸਊਰੇ ਚੋਣ ਬਣ ਗਿਆ: ਡੇਟਾ ਨੂੰ ਟੈਕਸਟ ਬਲਾਬ ਵਿੱਚ ਫਿੱਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼, ਇੱਕ ਵੱਖਰੀ ਪ੍ਰਣਾਲੀ ਜੋੜਨਾ, ਜਾਂ ਵੇਂਡਰ ਤੋਂ ਸਮਰਥਨ ਦੀ ਉਡੀਕ ਕਰਨਾ।
Postgres ਨੇ ਇੱਕ ਵੱਖਰਾ ਵਿਚਾਰ ਅੱਗੇ ਰੱਖਿਆ: ਡੇਟਾਬੇਸ ਵਿਸਥਾਰਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ—ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਨਵੇਂ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਇੱਕ ਸੰਯਮਿਤ ਤਰੀਕੇ ਨਾਲ ਜੋੜ ਸਕਦੇ ਹੋ, ਬਿਨਾਂ SQL ਤੋਂ ਉਮੀਦ ਕੀਤੀ ਸੁਰੱਖਿਆ ਅਤੇ ਸਹੀਅਤ ਨੂੰ ਟੁੱਟਣ ਦੇ।
ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ, ਵਿਸਥਾਰਯੋਗਤਾ ਉਸੇ ਤਰ੍ਹਾਂ ਹੈ ਜਿਵੇਂ ਪਾਵਰ ਟੂਲ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਐਟੈਚਮੈਂਟਾਂ ਨਾਲ ਸੁਧਾਰਨਾ—ਇੰਜਨ ਨੂੰ ਖੁਦ ਰੀ-ਵਾਇਰ ਕੀਤੇ ਬਗੈਰ ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਨੂੰ “ਨਵੀਆਂ ਚੀਜ਼ਾਂ ਸਿਖਾ” ਸਕਦੇ ਹੋ।
ਇਹ ਮਨੋਭਾਵ ਅੱਜ ਦੇ PostgreSQL ਇਕੋਸਿਸਟਮ (ਅਤੇ ਕਈ Postgres-ਪ੍ਰੇਰਿਤ ਸਿਸਟਮ) ਵਿੱਚ ਸਾਫ਼ ਨਜ਼ਰ ਆਉਂਦੀ ਹੈ। ਕੋਰ ਫੀਚਰ ਦੀ ਉਡੀਕ ਕਰਨ ਦੀ ਬਜਾਏ, ਟੀਮਾਂ ਪੱਕੇ-ਜਾਂਚੇ ਗਏ ਐਕਸਟੈਂਸ਼ਨ ਅਪਣਾਉਂਦੀਆਂ ਹਨ ਜੋ SQL ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਟੂਲਿੰਗ ਨਾਲ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਇੰਟੀਗਰੇਟ ਹੁੰਦੇ ਹਨ।
ਸਧਾਰਣ ਉਦਾਹਰਨਾਂ:
ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ Postgres ਨੇ “ਡੇਟਾਬੇਸ ਕੀ ਕਰ ਸਕਦਾ ਹੈ” ਨੂੰ ਡਿਜ਼ਾਈਨ ਉਦਦੇਸ਼ ਵਜੋਂ ਦਰਸਾਇਆ—ਇੱਕ ਬਾਅਦ-ਨੋਟ ਨਹੀਂ—ਅਤੇ ਇਹ ਵਿਚਾਰ ਅਜੇ ਵੀ ਆਧੁਨਿਕ ਡੇਟਾ ਪਲੈਟਫਾਰਮਾਂ ਦੇ ਵਿਕਾਸ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।
ਡੇਟਾਬੇਸ ਸਿਰਫ਼ ਜਾਣਕਾਰੀ ਸਟੋਰ ਕਰਨ ਲਈ ਨਹੀਂ ਹੁੰਦੇ—ਉਹ ਇਹ ਯਕੀਨ ਬਣਾਉਂਦੇ ਹਨ ਕਿ ਜਾਣਕਾਰੀ ਸਹੀ ਰਹੇ, ਭਲੇ ਹੀ ਉਨ੍ਹਾਂ ਵੇਲੇ ਬਹੁਤ ਸਾਰੀਆਂ ਗਤੀਵਿਧੀਆਂ ਇੱਕਸਾਥ ਹੋ ਰਹੀਆਂ ਹੋਣ। ਇਹੀ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਅਤੇ ਕਨਕਰਨਸੀ ਕੰਟਰੋਲ ਦਾ ਕੰਮ ਹੈ, ਅਤੇ ਇਹ SQL ਸਿਸਟਮਾਂ ਨੂੰ ਵ੍ਹਰਵਹਿ ਕਾਰੋਬਾਰੀ ਕੰਮਾਂ ਲਈ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਇੱਕ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਬਦਲਾਅਾਂ ਦਾ ਉਹ ਗਰੁੱਪ ਹੈ ਜੋ ਇਕੱਠੇ ਨਾ ਤਾਂ ਸਫਲ ਹੋਣਗੇ ਨਾ ਫੇਲ—ਇੱਕ ਯੂਨਿਟ ਵਜੋਂ ਸਫਲਤਾ ਜਾਂ ਅਸਫਲਤਾ।
ਜੇ ਤੁਸੀਂ ਖਾਤਿਆਂ ਵਿਚੋਂ ਪੈਸੇ ਟ੍ਰਾਂਸਫਰ ਕਰ ਰਹੇ ਹੋ, ਇੱਕ ਆਰਡਰ ਰੱਖ ਰਹੇ ਹੋ, ਜਾਂ ਇਨਵੈਂਟਰੀ ਅਪਡੇਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ “ਅਧੂਰੇ” ਨਤੀਜੇ ਕਬੂਲਯੋਗ ਨਹੀਂ। ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਇਹ ਯਕੀਨ ਦਿਲਾਉਂਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਅਧੂਰਾ ਨਤੀਜਾ ਨਹੀਂ ਮਿਲਿਆ।
ਅਮਲੀ ਤੌਰ 'ਤੇ, ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਤੁਹਾਨੂੰ ਦਿੰਦੇ ਹਨ:
ਕਨਕਰਨਸੀ ਦਾ ਮਤਲਬ ਹੈ ਬਹੁਤ ਸਾਰੇ ਲੋਕ (ਅਤੇ ਐਪ) ਇਕੱਠੇ ਡੇਟਾ ਪੜ੍ਹਨਾ ਅਤੇ ਬਦਲ ਰਹੇ ਹੋਣ: ਕਸਟਮਰ ਚੈਕਆਊਟ, ਸਹਾਇਤਾ ਏਜੰਟਾਂ ਦੇਖ-ਭਾਲ, ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬਸ, ਅਤੇ ਅਨਾਲਿਸਟਿਕ ਰਿਪੋਰਟ।
ਬਿਨਾਂ ਧਿਆਨ ਦੇ, ਕਨਕਰਨਸੀ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ ਜਿਵੇਂ:
ਇੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕਾ ਹੈ MVCC (Multi-Version Concurrency Control)। ਧਾਰਣਾ ਅਨੁਸਾਰ, MVCC ਕੁਝ ਸਮੇਂ ਲਈ ਇੱਕ ਰੋਅ ਦੀਆਂ ਕਈ ਵਰਜਨਾਂ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਜੋ ਪੜ੍ਹਨ ਵਾਲੇ ਲੋਕ ਇੱਕ ਸਥਿਰ ਸਨੇਪਸ਼ਾਟ ਵੇਖ ਸਕਣ ਜਦੋਂ ਲਿਖਤ ਹੋ ਰਹੀ ਹੁੰਦੀ ਹੈ।
ਵੱਡਾ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਰੀਡਜ਼ ਲਿਖਤਾਂ ਨੂੰ ਅਕਸਰ ਬਲੌਕ ਨਹੀਂ ਕਰਦੀਆਂ, ਅਤੇ ਲਿਖਤ ਲੰਬੇ ਸੰਮੇਲਨ ਵਾਲੇ ਕੁਐਰੀਆਂ ਪਿੱਛੇ ਘੁਟ ਨਹੀਂ ਪੈਂਦੇ। ਤੁਸੀਂ ਅਜੇ ਵੀ ਸਹੀਅਤ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ, ਪਰ ਘੱਟ ਇੰਤਜ਼ਾਰ ਨਾਲ।
ਅੱਜ ਦੇ ਡੇਟਾਬੇਸ ਅਕਸਰ ਮਿਕਸਡ ਵਰਕਲੋਡ ਘਰੇਲੂ ਹੁੰਦੇ ਹਨ: ਉੱਚ-ਮਾਤਰਾ ਵਾਲੀਆਂ ਐਪ ਲਿਖਤਾਂ ਨਾਲ ਨਾਲ ਡੈਸ਼ਬੋਰਡ ਲਈ ਬਾਰ-ਬਾਰ ਪੜ੍ਹਨ। ਆਧੁਨਿਕ SQL ਸਿਸਟਮ MVCC, ਸਮਾਰਟ ਲਾਕਿੰਗ ਅਤੇ ਆਈਸੋਲੇਸ਼ਨ ਲੈਵਲ ਵਰਗੀਆਂ ਤਕਨੀਕਾਂ ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਤਾਂ ਕਿ ਰਫ਼ਤਾਰ ਅਤੇ ਸਹੀਅਤ ਵਿਚ ਸੰਤੁਲਨ ਬਣਿਆ ਰਹੇ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਰਗਰਮੀ ਵਧਾ ਸਕੋ ਬਿਨਾਂ ਡੇਟਾ 'ਤੇ ਭਰੋਸਾ ਘੱਟ ਕੀਤੇ।
ਰੋਅ-ਅਧਾਰਿਤ ਡੇਟਾਬੇਸ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ ਬਣੇ ਸਨ: ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ ਪੜ੍ਹਨ ਤੇ ਲਿਖਤ, ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਗ੍ਰਾਹਕ, ਇੱਕ ਆਰਡਰ ਜਾਂ ਇੱਕ ਅਕਾਊਂਟ ਨੂੰ ਛੂਹਦੇ ਹੋਏ। ਇਹ ਡਿਜ਼ਾਈਨ ਉਨ੍ਹਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਬਹੁਤ ਚੰਗਾ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਇੱਕ ਰਿਕਾਰਡ ਪੂਰਾ ਲੈਣਾ ਹੋਵੇ।
ਇੱਕ spreadsheet ਨੂੰ ਸੋਚੋ। ਇੱਕ row store ਹਰ ਕਤਾਰ ਨੂੰ ਆਪਣੀ ਫੋਲਡਰ ਵਾਂਗ ਰੱਖਣ ਵਰਗਾ ਹੈ: ਜਦੋਂ ਤੁਹਾਨੂੰ "Order #123 ਬਾਰੇ ਸਭ ਕੁਝ" ਚਾਹੀਦਾ, ਤੁਸੀਂ ਇੱਕ ਫੋਲਡਰ ਖਿੱਚ ਲੈਂਦੇ ਹੋ। ਇੱਕ column store ਕਾਲਮ ਅਨੁਸਾਰ ਫਾਇਲ ਕਰਦਾ ਹੈ: ਇੱਕ ਦਰਾਜ਼ "order_total" ਲਈ, ਦੂਜਾ "order_date" ਲਈ, ਹੋਰ "customer_region" ਲਈ।
ਐਨਾਲਿਟਿਕਸ ਲਈ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਪੂਰਾ ਫੋਲਡਰ ਨਹੀਂ ਚਾਹੁੰਦੇ—ਤੁਹਾਡਾ ਸਵਾਲ ਅਕਸਰ ਇਹ ਹੁੰਦਾ ਹੈ "ਪਿਛਲੇ ਕਵੈਰਟਰ ਵਿੱਚ ਖੇਤਰ ਅਨੁਸਾਰ ਕੁੱਲ ਆਮਦਨ ਕੀ ਸੀ?"। ਇਹ ਕੁਐਰੀ ਲੱਗਭਗ ਹਮੇਸ਼ਾ ਮਿਲੀਅਨਾਂ ਰਿਕਾਰਡਾਂ 'ਚੋਂ ਸਿਰਫ਼ ਕੁਝ ਖੇਤਰ ਬੋਲਦੀ ਹੈ।
ਐਨਾਲਿਟਿਕਸ ਕੁਐਰੀਆਂ ਅਕਸਰ:
ਕਾਲਮਰ ਸਟੋਰੇਜ ਨਾਲ, ਇੰਜਨ ਸਿਰਫ਼ ਉਹੀ ਕਾਲਮ ਪੜ੍ਹ ਸਕਦਾ ਹੈ ਜੋ ਕੁਐਰੀ ਵਿੱਚ ਜ਼ਿਕਰ ਕੀਤੇ ਗਏ ਹਨ, ਬਾਕੀ ਨੂੰ ਸਕਿੱਪ ਕਰਕੇ। ਡਿਸਕ ਤੋਂ ਘੱਟ ਡੇਟਾ ਪੜ੍ਹਨਾ (ਅਤੇ ਮੈਮੋਰੀ ਰਾਹੀਂ ਘੱਟ ਡੇਟਾ ਮੂਵ) ਅਕਸਰ ਸਭ ਤੋਂ ਵੱਡਾ ਪ੍ਰਦਰਸ਼ਨ ਫਾਇਦਾ ਹੁੰਦਾ ਹੈ।
ਕਾਲਮਾਂ ਵਿੱਚ ਮੁੱਲ ਆਮ ਤੌਰ 'ਤੇ ਦੁਹਰਾਏ ਜਾਂਦੇ ਹਨ (ਖੇਤਰ, ਸਥਿਤੀਆਂ, ਵਰਗ). ਇਸ ਨਾਲ ਉਹਨਾਂ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਪ੍ਰੈੱਸ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ—ਅਤੇ ਕੰਪ੍ਰੈਸ਼ਨ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਸਿਸਟਮ ਘੱਟ ਬਾਈਟ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਕਈ ਵਾਰੀ ਕੰਪ੍ਰੈੱਸਡ ਡੇਟਾ 'ਤੇ ਹੀ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ।
ਕਾਲਮ ਸਟੋਰ ਨੇ OLTP-ਪਹਿਲੇ ਡੇਟਾਬੇਸਾਂ ਤੋਂ ਐਨਾਲਿਟਿਕਸ-ਪਹਿਲੇ ਇੰਜਨਾਂ ਵੱਲ ਮੂੰਹ ਘੁਮਾਇਆ, ਜਿੱਥੇ ਸਕੈਨਿੰਗ, ਕੰਪ੍ਰੈਸ਼ਨ, ਅਤੇ ਤੇਜ਼ ਐਗਰੀਗੇਸ਼ਨ ਮੁੱਖ ਡਿਜ਼ਾਈਨ ਲਕਸ਼ ਬਣ ਗਏ।
Vertica ਇੱਕ ਚਮਕਦਾਰ ਉਦਾਹਰਣ ਹੈ ਕਿ Stonebraker ਦੇ ਐਨਾਲਿਟਿਕਸ-ਕੇਂਦਰਤ ਵਿਚਾਰ ਕਿਵੇਂ ਇਕ ਪ੍ਰੋਡਕਟ ਬਣ ਕੇ ਟੀਮਾਂ ਦੁਆਰਾ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਚਲਾਏ ਜਾ ਸਕਦੇ ਹਨ। ਇਸ ਨੇ ਕਾਲਮਰ ਸਟੋਰੇਜ ਦੇ ਪਾਠਾਂ ਨੂੰ ਡਿਸਟ੍ਰਿਬਿਊਟ ਕੀਤੇ ਡਿਜ਼ਾਈਨ ਨਾਲ ਜੋੜਿਆ ਜੋ ਇੱਕ ਖਾਸ ਸਮੱਸਿਆ—ਵੱਡੀਆਂ ਐਨਾਲਿਟਿਕ SQL ਕੁਐਰੀਆਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇਣ— ਲਈ ਬਣਾਇਆ ਗਿਆ।
MPP ਦਾ ਮਤਲਬ ਹੈ massively parallel processing. ਸਭ ਤੋਂ ਸਧਾਰਨ ਢੰਗ ਨਾਲ ਸੋਚੋ: ਬਹੁਤੀਆਂ ਮਸ਼ੀਨਾਂ ਇੱਕ SQL ਕੁਐਰੀ 'ਤੇ ਇਕੱਠੇ ਕੰਮ ਕਰ ਰਹੀਆਂ ਹਨ।
ਇਕ ਇਕੱਲੇ ਡੇਟਾਬੇਸ ਸਰਵਰ ਦੀ ਥਾਂ, ਡੇਟਾ ਨੋਡਾਂ 'ਤੇ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ। ਹਰ ਨੋਡ ਆਪਣੀ ਸਲਾਈਸ 'ਤੇ ਸਮਾਨ-ਸਮਾਂਨ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਸਿਸਟਮ ਹਿੱਸਵਾਰ ਨਤੀਜੇ ਇਕੱਠੇ ਕਰਕੇ ਅੰਤਿਮ ਜਵਾਬ ਬਣਾਂਦਾ ਹੈ।
ਇਸ ਤਰ੍ਹਾਂ ਉਹ ਕੁਐਰੀ ਜੋ ਇਕ ਬਕਸੇ 'ਤੇ ਮਿੰਟ ਲੈਂਦੀ ਸੀ, ਕਲਸਟਰ 'ਤੇ ਸਕਿੰਟਾਂ ਵਿੱਚ ਆ ਸਕਦੀ ਹੈ—ਜੇ ਡੇਟਾ ਚੰਗੀ ਤਰ੍ਹਾਂ ਵੰਡਿਆ ਗਿਆ ਹੋਵੇ ਅਤੇ ਕੁਐਰੀ ਪੈਰਲਲাইজ ਕੀਤਾ ਜਾ ਸਕੇ।
Vertica-ਸ਼ੈਲੀ MPP ਐਨਾਲਿਟਿਕਸ ਸਿਸਟਮ ਉਹਨਾਂ ਹਾਲਤਾਂ 'ਚ ਚਮਕਦੇ ਹਨ ਜਿੱਥੇ ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ سارੀਆਂ ਰੋਅ ਹਨ ਅਤੇ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਸਕੈਨ, ਫਿਲਟਰ ਅਤੇ ਐਗਰੀਗੇਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਆਮ ਇਸਤੇਮਾਲ ਦੇ ਕੇਸ:
MPP ਐਨਾਲਿਟਿਕਸ ਇੰਜਨਾਂ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਲ (OLTP) ਸਿਸਟਮਾਂ ਲਈ ਸਿੱਧਾ ਬਦਲ ਨਹੀਂ ਹਨ। ਇਹ ਕਈ ਰੋਅ ਪੜ੍ਹਨ ਅਤੇ ਸੰਖੇਪ ਗਣਨਾ ਲਈ ਅਨੁਕੂਲ ਹਨ, ਨਾ ਕਿ ਛੋਟੇ-ਛੋਟੇ ਅਪਡੇਟਸ ਲਈ।
ਮੁਢਲੇ ਟਰੇਡ-ਆਫ਼:
ਕੁੰਜੀ ਵਿਚਾਰ ਇਹ ਹੈ: ਫੋਕਸ—Vertica ਅਤੇ ਉਸ ਦੀਆਂ ਸਮਾਨ ਪ੍ਰਣਾਲੀਆਂ ਸਟੋਰੇਜ, ਕੰਪ੍ਰੈਸ਼ਨ, ਅਤੇ ਪੈਰਲਲ ਐਗਜ਼ੈਕਿਊਸ਼ਨ ਨੂੰ ਐਨਾਲਿਟਿਕਸ ਲਈ ਟਿਊਨ ਕਰਕੇ ਆਪਣੀ ਗਤੀ ਹਾਸਲ ਕਰਦੀਆਂ ਹਨ—ਫਿਰ ਉਹ ਸੀਮਾਵਾਂ ਮਨਜ਼ੂਰ ਕਰ ਲੈਂਦੀਆਂ ਹਨ ਜੋ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਲ ਸਿਸਟਮ ਟਾਲਦੇ ਹਨ।
ਇੱਕ ਡੇਟਾਬੇਸ "ਸਟੋਰ ਅਤੇ ਕੁਐਰੀ" ਕਰ ਸਕਦਾ ਹੈ ਪਰ ਫਿਰ ਵੀ ਐਨਾਲਿਟਿਕਸ ਲਈ ਧੀਮਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ। ਫਰਕ ਅਕਸਰ ਤੁਹਾਡੇ ਦੁਆਰਾ ਲਿਖੀ SQL ਨਹੀਂ, ਬਲਕਿ ਇਹ ਹੈ ਕਿ ਇੰਜਨ ਇਸਨੂੰ ਕਿਵੇਂ ਚਲਾਉਂਦਾ ਹੈ: ਕਿਵੇਂ ਉਹ ਪੇਜਜ਼ ਪੜ੍ਹਦਾ ਹੈ, ਡੇਟਾ CPU ਰਾਹੀਂ ਕਿਵੇਂ ਘੁਮਦਾ ਹੈ, ਮੈਮੋਰੀ ਕਿਵੇਂ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਬੇਕਾਰ ਕੰਮ ਕਿਵੇਂ ਘਟਾਇਆ ਜਾਂਦਾ ਹੈ।
Stonebraker ਦੇ ਐਨਾਲਿਟਿਕਸ-ਕੇਂਦਰਤ ਪ੍ਰੋਜੈਕਟਾਂ ਨੇ ਇਹ ਵਿਚਾਰ ਅੱਗੇ ਧੱਕਿਆ ਕਿ ਕੁਐਰੀ ਪ੍ਰਦਰਸ਼ਨ ਇਕ ਸਟੋਰੇਜ ਮਸਲੇ ਦੇ ਨਾਲ ਨਾਲ ਇੱਕ ਐਗਜ਼ੈਕਿਊਸ਼ਨ ਸਮੱਸਿਆ ਵੀ ਹੈ। ਇਹ ਸੋਚ ਟੀਮਾਂ ਨੂੰ ਇੱਕ-ਰੋਅ ਲੁਕਅਪ ਨੂੰ ਅਪਟਾਈਮ ਕਰਨ ਤੋਂ ਲੰਬੇ ਸਕੈਨ, ਜੋਇਨ ਅਤੇ ਐਗਰੀਗੇਸ਼ਨ 'ਤੇ ਧਿਆਨ ਮੋੜਨ ਦੀ ਪ੍ਰੇਰਨਾ ਦਿੱਤੀ।
ਕਈ ਪੁਰਾਣੇ ਇੰਜਨਾਂ "tuple-at-a-time" (ਰੋਅ-ਬਾਈ-ਰੋਅ) ਪ੍ਰੋਸੈਸ ਕਰਦੇ ਸਨ, ਜੋ ਬਹੁਤ ਸਾਰੀ ਫੰਕਸ਼ਨ ਕਾਲ ਅਤੇ ਓਵਰਹੈਡ ਪੈਦਾ ਕਰਦਾ ਸੀ। ਵੇਕਟੋਰਾਈਜ਼ਡ ਐਗਜ਼ੈਕਿਊਸ਼ਨ ਉਸ ਮਾਡਲ ਨੂੰ ਉਲਟ ਦਿੰਦਾ ਹੈ: ਇੰਜਨ ਇੱਕ ਬੈਚ (vector) ਦੀਆਂ ਵੈਲਿਊਜ਼ ਨੂੰ ਇੱਕ ਕਸਰਤ ਚੱਕਰ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ।
ਸਧਾਰਨ ਤੌਰ 'ਤੇ, ਇਹ ਕਾਰਟ ਨਾਲ ਕਿਰਾਨਕ ਸਮਾਨ ਸਮਾਨ ਚੀਜ਼ਾਂ ਲਿਜਾਣ ਵਰਗਾ ਹੈ—ਇਕ-ਇਕ ਆਈਟਮ ਲਿਜਾਣ ਦੀ ਥਾਂ ਬੈਚ-ਮੋਡ ਘੱਟ ਓਵਰਹੈਡ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਆਧੁਨਿਕ CPUs ਨੂੰ ਉਹ ਕੰਮ ਕਰਨ ਦਿੰਦਾ ਹੈ ਜੋ ਉਹ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਕਰਦੇ ਹਨ: ਪੇਸ਼ਗੋਈਯੋਗ ਲੂਪ, ਘੱਟ ਬ੍ਰਾਂਚ, ਅਤੇ ਬੇਹਤਰ ਕੈਸ਼ ਵਰਤੋਂ।
ਤੇਜ਼ ਇੰਜਨ CPU ਅਤੇ cache-ਦਰਸਤ ਹੇਠਾਂ ਰਹਿਣ 'ਤੇ ਜ਼ੋਰ ਦਿੰਦੇ ਹਨ। ਐਗਜ਼ੈਕਿਊਸ਼ਨ ਨਵੀਨਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਸ 'ਤੇ ਧਿਆਨ ਦਿੰਦੀਆਂ ਹਨ:
ਇਹ ਵਿਚਾਰ ਮਹੱਤਵਪੂਰਨ ਹਨ ਕਿਉਂਕਿ ਐਨਾਲਿਟਿਕਲ ਕੁਐਰੀਆਂ ਅਕਸਰ ਮੈਮੋਰੀ ਬੈਂਡਵਿਡਥ ਅਤੇ ਕੈਸ਼-ਮਿਸਜ਼ ਦੁਆਰਾ ਸੀਮਤ ਹੁੰਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਕੇਵਲ ਡਿਸਕ ਸਪੀਡ ਦੁਆਰਾ।
ਆਧੁਨਿਕ ਡੇਟਾ ਵੇਅਰਹਾਊਸ ਅਤੇ SQL ਇੰਜਨਾਂ—ਕਲਾਉਡ ਵੇਅਰਹਾਊਸ, MPP ਸਿਸਟਮ, ਅਤੇ ਤੇਜ਼ ਇਨ-ਪ੍ਰੋਸੈਸ ਐਨਾਲਿਟਿਕਸ ਟੂਲ—ਅਕਸਰ ਵੇਕਟोरਾਈਜ਼ਡ ਐਗਜ਼ੈਕਿਊਸ਼ਨ, ਕੰਪ੍ਰੈਸ਼ਨ-ਸਹਿਤ ਆਪਰੇਟਰਾਂ, ਅਤੇ ਕੈਸ਼-ਫ੍ਰੈਂਡਲੀ ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਮਿਆਰੀ ਅਮਲ ਮੰਨਦੇ ਹਨ।
ਜਦੋਂ ਵੈਂਡਰ “autoscaling” ਜਾਂ “storage ਅਤੇ compute ਦੀ ਵੱਖਰੀਕਰਨ” ਵਰਗੀਆਂ ਫੀਚਰਾਂ ਦਾ ਪ੍ਰਚਾਰ ਕਰਦੇ ਹਨ, ਦਿਨ-ਪਰ-ਦਿਨ ਦੀ ਗਤੀ ਅਜੇ ਵੀ ਭਾਰੀ ਹੱਦ ਤੱਕ ਇਨ੍ਹਾਂ ਐਗਜ਼ੈਕਿਊਸ਼ਨ ਚੋਣਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਪਲੇਟਫਾਰਮਾਂ ਦੀ ਮੁਲਾਂਕਣ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਸਿਰਫ਼ ਇਹ ਨਾ ਪੁੱਛੋ ਕਿ ਉਹ ਕੀ ਸਟੋਰ ਕਰਦੇ ਹਨ—ਪਰ ਇਹ ਵੀ ਪੁੱਛੋ ਕਿ ਉਹ ਜੋਇਨ ਅਤੇ ਐਗਰੀਗੇਸ਼ਨ ਨੂੰ ਅੰਦਰੋਂ ਕਿਵੇਂ ਚਲਾਉਂਦੇ ਹਨ ਅਤੇ ਕੀ ਉਨ੍ਹਾਂ ਦਾ ਐਗਜ਼ੈਕਿਊਸ਼ਨ ਮਾਡਲ ਐਨਾਲਿਟਿਕਸ ਲਈ ਬਣਿਆ ਹੈ।
ਸਟ੍ਰੀਮਿੰਗ ਡੇਟਾ ਸਾਦਾ ਸ਼ਬਦਾਂ ਵਿੱਚ ਉਹ ਡੇਟਾ ਹੈ ਜੋ ਲਗਾਤਾਰ ਘਟਨਾਵਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਆਉਂਦਾ ਹੈ—ਸੋਚੋ “ਨਵੀਂ ਘਟਨਾ ਹੁਣੀ ਹੋਈ” ਸੁਨੇਹੇ। ਇੱਕ ਕਰੈਡਿਟ-ਕਾਰਡ ਸਵਾਈਪ, ਇੱਕ ਸੈਂਸਰ ਪੜ੍ਹਾਈ, ਇੱਕ ਪ੍ਰੋਡਕਟ ਪੇਜ 'ਤੇ ਕਲਿੱਕ, ਇੱਕ ਪੈਕੇਜ ਸਕੈਨ, ਇੱਕ ਲੌਗ ਲਾਈਨ: ਇਹ ਸਭ ਤੁਰੰਤ ਆਉਂਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ।
ਪਾਰੰਪਰਿਕ ਡੇਟਾਬੇਸ ਅਤੇ ਬੈਚ ਪਾਈਪਲਾਈਨਾਂ ਓਸ ਵੇਲੇ ਵਧੀਆ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਰੁਕ ਸਕਦੇ ਹੋ: ਕੱਲ੍ਹ ਦਾ ਡੇਟਾ ਲੋਡ ਕਰੋ, ਰਿਪੋਰਟ ਚਲਾਓ, ਡੈਸ਼ਬੋਰਡ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ। ਪਰ ਰੀਅਲ-ਟਾਈਮ ਲੋੜਾਂ ਲਈ ਹੋਰ ਇੰਤਜ਼ਾਰ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।
ਜੇ ਤੁਸੀਂ ਕੇਵਲ ਬੈਚ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਕਰਦੇ ਹੋ, ਤਾਂ ਅਕਸਰ ਨਤੀਜੇ ਹੁੰਦੇ ਹਨ:
ਸਟ੍ਰੀਮਿੰਗ ਸਿਸਟਮ ਇਸ ਵਿਚਾਰ ਦੇ ਆਧਾਰ 'ਤੇ ਬਣੇ ਹੁੰਦੇ ਹਨ ਕਿ ਗਣਨਾਤਮਕ ਕਾਰਜ ਘਟਨਾਵਾਂ ਦੇ ਆਉਣ ਨਾਲ ਲਗਾਤਾਰ ਚੱਲ ਸਕਦੇ ਹਨ।
ਇੱਕ ਲਗਾਤਾਰ ਕੁਐਰੀ ਇੱਕ ਐਸੀ SQL ਕੁਐਰੀ ਵਰਗੀ ਹੈ ਜੋ ਕਦੇ "ਮੁੱਕਦੀ" ਨਹੀਂ। ਇਹ ਇਕ ਨਤੀਜਾ ਇਕ ਵਾਰੀ ਵਾਪਸ ਨਹੀਂ ਕਰਦੀ; ਬਲਕਿ ਜਿਵੇਂ-ਜਿਵੇਂ ਨਵੇਂ ਘਟਨਾ ਆਉਂਦੇ ਹਨ, ਨਤੀਜੇ ਅਪਡੇਟ ਹੁੰਦੇ ਰਹਿੰਦੇ ਹਨ।
ਕਿਉਂਕਿ ਸਟ੍ਰੀਮਾਂ ਅਨੰਤ ਹਨ (ਉਹ ਖਤਮ ਨਹੀਂ ਹੁੰਦੀਆਂ), ਸਟ੍ਰੀਮਿੰਗ ਸਿਸਟਮ ਵਿੰਡੋਜ਼ ਵਰਤਦੇ ਹਨ ताकि ਗਣਨਾ ਸੰਭਾਲਯੋਗ ਰਹੇ। ਇਕ ਵਿੰਡੋ ਸਮਾਂ ਜਾਂ ਘਟਨਾਵਾਂ ਦੀ ਗਿਣਤੀ ਹੋ ਸਕਦੀ ਹੈ, ਉਦਾਹਰਣ ਲਈ "ਉ posled 5 ਮਿੰਟ" ਜਾਂ "ਹਰੇਕ ਮਿੰਟ" ਜਾਂ "ਆਖਰੀ 1,000 ਘਟਨਾਵਾਂ"। ਇਸ ਨਾਲ ਤੁਸੀਂ rolling counts, averages ਜਾਂ top-N ਸੂਚੀਆਂ ਗਿਣ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਸਾਰਾ ਡੇਟਾ ਮੁੜ-ਪ੍ਰੋਸੈਸ ਕੀਤੇ।
ਰੀਅਲ-ਟਾਈਮ ਸਟ੍ਰੀਮਿੰਗ ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਕੀਮਤੀ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਸਮਾਂ ਮਾਮਲਾ ਹੈ:
Stonebraker ਨੇ ਸਦੀਆਂ ਤੱਕ ਦਲੀਲ ਕੀਤੀ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਸਭ ਨੂੰ ਇੱਕ ਜੇਹਾ ਬਣਾਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਨੇ ਚਾਹੀਦੇ। ਕਾਰਣ ਸਧਾਰਨ ਹੈ: ਵੱਖ-ਵੱਖ ਵਰਕਲੋਡ ਵੱਖ-ਵੱਖ ਡਿਜ਼ਾਈਨ ਚੋਣਾਂ ਨੂੰ ਇਨਾਮ ਦਿੰਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਕੰਮ ਲਈ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਅਪਟਾਈਮ ਹੋ, ਤਾਂ ਅਕਸਰ ਤੁਸੀਂ ਕਿਸੇ ਹੋਰ ਕੰਮ ਨੂੰ ਹੌਂਟੇਗਾ।
ਅਧਿਕਤਰ ਆਧੁਨਿਕ ਸਟੈਕ ਇੱਕ ਤੋਂ ਵੱਧ ਡੇਟਾ ਸਿਸਟਮ ਵਰਤਦੇ ਹਨ ਕਿਉਂਕਿ ਕਾਰੋਬਾਰ ਵੱਖ-ਵੱਖ ਕਿਸਮ ਦੇ ਸਵਾਲ ਮੰਗਦਾ ਹੈ:
ਇਹ ਅਮਲ ਵਿੱਚ "ਇੱਕ ਸਾਈਜ਼ ਸਾਰੀਆਂ ਲਈ ਨਹੀਂ" ਦਾ ਉਦਾਹਰਨ ਹੈ: ਤੁਸੀਂ ਉਹਨਾਂ ਇੰਜਨਾਂ ਨੂੰ ਚੁਣਦੇ ਹੋ ਜੋ ਕੰਮ ਦੀ ਸ਼ਕਲ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ।
ਚੁਣਨ ਵੇਲੇ (ਜਾਂ ਇਕ ਹੋਰ ਸਿਸਟਮ ਨੂੰ ਜਸਟਿਫਾਈ ਕਰਦੇ ਸਮੇਂ) ਇਸ ਤੇਜ਼ ਛਾਣ-ਬੀਨ ਵਰਤੋਂ:
ਕਈ ਇੰਜਨ ਸਿਹਤਮੰਦ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਸਿਰਫ ਉਹਨਾਂ ਵਰਗੇ ਜਦੋਂ ਹਰ ਇਕ ਦਾ ਇੱਕ ਸਾਫ਼ ਵਰਕਲੋਡ ਹੋਵੇ। ਨਵਾਂ ਟੂਲ ਆਪਣੀ ਜਗ੍ਹਾ ਕਮਾਉਣ ਲਈ ਲਾਗਤ, ਲੇਟੈਂਸੀ ਜਾਂ ਜੋਖਮ ਘਟਾ ਕੇ ਇਸ ਦੀ ਵਜ੍ਹਾ ਦਿਖਾਏ— ਨਾ ਕਿ ਸਿਰਫ ਨਵਾਂपन ਦਿਖਾ ਕੇ।
ਘੱਟ ਟੂਲਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਜਿਨ੍ਹਾਂ ਦੀ ਮਜ਼ਬੂਤ ਓਪਰੇਸ਼ਨਲ ਮਾਲਕੀਅਤ ਹੋਵੇ, ਅਤੇ ਉਹ ਕੰਪੋਨੈਂਟਸ ਜਿਨ੍ਹਾਂ ਦਾ ਸਪਸ਼ਟ, ਮਾਪਯੋਗ ਉਦੇਸ਼ ਨਹੀਂ, ਉਹਨਾਂ ਨੂੰ ਰਿਟਾਇਰ ਕਰੋ।
Stonebraker ਦੀਆਂ ਖੋਜ ਥਰੇਡ—ਰਿਲੇਸ਼ਨਲ ਬੁਨਿਆਦ, ਵਿਸਥਾਰਯੋਗਤਾ, ਕਾਲਮ ਸਟੋਰ, MPP ਐਗਜ਼ੈਕਿਊਸ਼ਨ, ਅਤੇ "ਕਾਮ ਲਈ ਸਹੀ ਟੂਲ"—ਆਧੁਨਿਕ ਡੇਟਾ ਪਲੇਟਫਾਰਮਾਂ ਦੀਆਂ ਡਿਫ਼ਾਲਟ ਰੂਪ-ਰੇਖਾਵਾਂ ਵਿੱਚ ਦਿਸਦੀਆਂ ਹਨ।
ਵੇਅਰਹਾਊਸ SQL ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ, ਕਾਲਮਰ ਸਟੋਰੇਜ, ਅਤੇ ਪੈਰਲਲ ਐਗਜ਼ੈਕਿਊਸ਼ਨ 'ਤੇ ਸਦੀਆਂ ਦੇ ਕੰਮ ਦੀ ਪਰਛਾਂਵ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਵੱਡੀਆਂ ਟੇਬਲਾਂ 'ਤੇ ਤੇਜ਼ ਡੈਸ਼ਬੋਰਡ ਵੇਖਦੇ ਹੋ, ਅਕਸਰ ਤੁਸੀਂ ਕਾਲਮ-ਅਧਾਰਿਤ ਫਾਰਮੈਟਸ, ਵੇਕਟੋਰਾਈਜ਼ਡ ਪ੍ਰੋਸੈਸਿੰਗ ਅਤੇ MPP-ਸ਼ੈਲੀ ਸਕੇਲਿੰਗ ਵੇਖ ਰਹੇ ਹੁੰਦੇ ਹੋ।
ਲੇਕਹਾਊਸ ਵੇਅਰਹਾਊਸ ਵਿਚਾਰ (ਸਕੀਮਾਂ, ਅੰਕੜੇ, ਕੈਸ਼ਿੰਗ, cost-based optimization) ਨੂੰ ਖੁਲੇ ਫਾਈਲ ਫਾਰਮੈਟ ਅਤੇ objekਟ ਸਟੋਰੇਜ 'ਤੇ ਰੱਖਦਾ ਹੈ। "ਸਟੋਰੇਜ ਸਸਤਾ, ਕੰਪਿਊਟ ਇਲਾਸਟਿਕ" ਦਾ ਤਬਦੀਲੀ ਨਵਾਂ ਹੈ; ਪਰ ਅਧਾਰ 'ਤੇ ਕੁਐਰੀ ਅਤੇ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਸੋਚ ਨਵੀਂ ਨਹੀਂ।
MPP ਐਨਾਲਿਟਿਕਸ ਸਿਸਟਮ (shared-nothing ਕਲਸਟਰ) ਉਹੀ ਸੀਧੇ ਵੰਸ਼ਜ ਹਨ ਜਿਹੜਿਆਂ ਨੇ ਦਿਖਾਇਆ ਕਿ ਤੁਸੀਂ ਡਾਟਾ ਪਾਰਟਿਸ਼ਨ ਕਰਕੇ, ਕੰਪਿਊਟ ਨੂੰ ਡੇਟਾ ਕੋਲ ਲੈ ਕੇ, ਅਤੇ ਜੋਇਨ/ਐਗਰੀਗੇਸ਼ਨ ਦੌਰਾਨ ਡੇਟਾ ਮੂਵਮੈਂਟ ਨੂੰ ਸਾਵਧਾਨੀ ਨਾਲ ਮੈਨੇਜ ਕਰਕੇ SQL ਨੂੰ ਸਕੇਲ ਕਰ ਸਕਦੇ ਹੋ।
SQL ਨੇ ਵੇਅਰਹਾਊਸ, MPP ਇੰਜਨਾਂ ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ "ਲੇਕ" ਕੁਐਰੀ ਲੇਅਰ ਦੇ ਪਾਰਮੁੱਖ ਇੰਟਰਫੇਸ ਦੇ ਰੂਪ ਵਿੱਚ ਆਪਣੀ ਥਾਂ ਬਣਾਈ ਹੈ। ਟੀਮਾਂ ਇਸਨੂੰ ਵਰਤਦੀਆਂ ਹਨ:
ਭਾਵੇਂ ਐਗਜ਼ੈਕਿਊਸ਼ਨ ਵੱਖਰੇ ਇੰਜਨਾਂ ਵਿੱਚ ਹੋਵੇ (ਬੈਚ, ਇੰਟਰਐਕਟਿਵ, ਸਟ੍ਰੀਮਿੰਗ), SQL ਅਕਸਰ ਉਪਭੋਗਤਾ-ਮੁਹੱਈਆ ਭਾਸ਼ਾ ਰਹਿੰਦੀ ਹੈ।
ਲਚਕੀਲੇ ਸਟੋਰੇਜ ਨਾਲ ਸਟ੍ਰਕਚਰ ਦੀ ਲੋੜ ਦੂਰ ਨਹੀਂ ਹੋ ਜਾਂਦੀ। ਸਾਫ਼ ਸਕੀਮਾਂ, ਦਸਤਾਵੇਜ਼ੀ ਅਰਥ, ਅਤੇ ਨਿਯੰਤ੍ਰਿਤ ਵਿਕਾਸ ਨਾਲ਼ downstream ਉਲਟ-ਪਲਟ ਘਟਦੇ ਹਨ।
ਚੰਗੀ ਗਵਰਨੈਂਸ ਕਿਸੇ ਬਿਊਰੋਕਰੇਸੀ ਬਾਰੇ ਨਹੀਂ, ਬਲਕਿ ਡੇਟਾ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਣ ਬਾਰੇ ਹੈ: ਸੰਪਰਿਚਿਤ ਪਰਿਭਾਸ਼ਾਵਾਂ, ਮਾਲਕੀਅਤ, ਗੁਣਵੱਤਾ ਚੈੱਕ, ਅਤੇ ਐਕਸੈਸ ਨਿਯੰਤਰਣ।
ਜਦੋਂ ਤੁਸੀਂ ਪਲੇਟਫਾਰਮਾਂ ਦੀ ਮੁਲਾਂਕਣ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਪੁੱਛੋ:
ਜੇ ਕੋਈ ਵੇਂਡਰ ਆਪਣਾ ਉਤਪਾਦ ਇਨ੍ਹਾਂ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਨਾ ਬਤਾ ਸਕੇ, ਤਾਂ "ਨਵੀਨੀਕਰਨ" ਬਹੁਤ ਹੱਦ ਤੱਕ ਪੈਕੇਜਿੰਗ ਹੋ ਸਕਦੀ ਹੈ।
Stonebraker ਦੀ ਲੜੀ ਸਧਾਰਨ ਹੈ: ਡੇਟਾਬੇਸ ਉਹਨਾਂ ਕੰਮਾਂ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਲਈ ਉਹ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਗਏ ਹਨ—ਅਤੇ ਜਦੋਂ ਉਹ ਉਸ ਕੰਮ ਦੇ ਬਦਲਣ ਦੀ ਬਨਾਵਟ ਰੱਖ ਸਕਦੇ ਹਨ।
ਫੀਚਰਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਨਾ ਹੈ:
ਇੱਕ ਉਪਯੋਗੀ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਆਪਣੀ ਵਰਕਲੋਡ ਇੱਕ-ਦੋ ਵਾਕਾਂ ਵਿੱਚ ਵੇਰਵਾ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਬਜ਼ਵਰਡਸ ਦੇ ਆਧਾਰ 'ਤੇ ਖਰੀਦਦਾਰੀ ਕਰ ਲਵੋਗੇ।
ਟੀਮਾਂ ਅਕਸਰ ਇਹ ਅੰਦਾਜ਼ਾ ਘੱਟ ਲਾਉਂਦੀਆਂ ਹਨ ਕਿ ਲੋੜ ਕਿੰਨੀ ਵਾਰ ਬਦਲੇਗੀ: ਨਵੇਂ ਡੇਟਾ ਟਾਈਪ, ਨਵੇਂ ਮੈਟ੍ਰਿਕਸ, ਨਵੇਂ ਕੰਪਲਾਇੰਸ ਨਿਯਮ, ਨਵੇਂ ਉਪਭੋਗੀ।
ਉਹ ਪਲੇਟਫਾਰਮ ਅਤੇ ਡੇਟਾ ਮਾਡਲ ਚੁਣੋ ਜੋ ਬਦਲਾਅ ਨੂੰ ਰੋਜ਼ਾਨਾ ਰੂਟੀਨ ਬਣਾਉਂਦੇ ਹਨ, ਨਾ ਕਿ ਖਤਰਨਾਕ ਕੰਮ:
ਤੇਜ਼ ਜਵਾਬ ਤਦ ਹੀ ਕੀਮਤੀ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਸਹੀ ਹੋ। ਵਿਕਲਪਾਂ ਮੁਲਾਂਕਣ ਕਰਦੇ ਸਮੇਂ ਪੁੱਛੋ ਕਿ ਸਿਸਟਮ ਹੇਠ ਲਿਖੇ ਢੰਗ ਨਾਲ ਕਿਵੇਂ ਨਿਭਾਂਦਾ ਹੈ:
ਇੱਕ ਛੋਟਾ "ਤੁਹਾਡੇ ਡੇਟਾ ਨਾਲ ਪ੍ਰੂਫ" ਚਲਾਓ, ਸਿਰਫ਼ ਡੈਮੋ ਨਹੀਂ:
ਬਹੁਤ ਸਾਰੀਆਂ ਡੇਟਾਬੇਸ ਸਲਾਹਾਂ "ਸਹੀ ਇੰਜਨ ਚੁਣੋ" ਤੱਕ ਹੀ ਰੁਕ ਜਾਂਦੀਆਂ ਹਨ, ਪਰ ਟੀਮਾਂ ਨੂੰ ਉਸ ਇੰਜਨ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਐਪ ਅਤੇ ਅੰਦਰੂਨੀ ਟੂਲ ਵੀ ਸ਼ਿਪ ਕਰਨੇ ਪੈਂਦੇ ਹਨ: ਐਡਮਿਨ ਪੈਨਲ, ਮੈਟ੍ਰਿਕਸ ਡੈਸ਼ਬੋਰਡ, ਇੰਜੈਸ਼ਨ ਸਰਵਿਸਿਜ਼, ਅਤੇ ਬੈਕ-ਆਫ਼ਿਸ ਵਰਕਫਲੋਜ਼।
ਜੇ ਤੁਸੀਂ ਇਨ੍ਹਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਬਿਨਾਂ ਪੂਰੇ ਪਾਈਪਲਾਈਨ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਏ, ਤਾਂ ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ: React ਲਈ ਵੈੱਬ ਐਪ, backend ਸਰਵਿਸਿਜ਼ (Go + PostgreSQL), ਅਤੇ ਮੋਬਾਈਲ ਕਲਾਇੰਟ (Flutter) ਨੂੰ chat-ਚਾਲਿਤ ਵਰਕਫਲੋ ਵਿੱਚ ਤਿਆਰ ਕਰਨਾ। ਇਹ ਅਕਸਰ ਵਰਤੋਂਯੋਗ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਸਕੀਮਾ ਡਿਜ਼ਾਈਨ 'ਤੇ ਤੁਰੰਤ ਪ੍ਰਯੋਗ ਕਰ ਰਹੇ ਹੋ, ਇੱਕ ਛੋਟਾ ਅੰਦਰੂਨੀ "ਡੇਟਾ ਉਤਪਾਦ" ਬਣਾਉਂਦੇ ਹੋ, ਜਾਂ ਲੰਬੇ ਸਮੇਂ ਦੀ ਢੇਰ ਸਟ੍ਰਕਚਰ 'ਤੇ ਰੋਕਥਾਮ ਤੋਂ ਪਹਿਲਾਂ ਵਰਕਲੋਡ ਦੀ ਅਸਲ ਵਿਵਹਾਰਤਾ ਸਾਬਤ ਕਰਨੀ ਹੁੰਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਹੋਰ ਗਹਿਰਾਈ ਵਿੱਚ ਜਾਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ "ਕਾਲਮਰ ਸਟੋਰੇਜ", "MVCC", "MPP execution", ਅਤੇ "stream processing" ਬਾਰੇ ਪੜ੍ਹੋ। ਹੋਰ ਸਮਝਾਉਣ ਵਾਲੇ ਲੇਖ /blog ਵਿੱਚ ਮੌਜੂਦ ਹਨ।
ਉਨ੍ਹਾਂ ਦੀਆਂ ਖੋਜ-ਅਧਾਰਿਤ ਪ੍ਰਣਾਲੀਆਂ ਵਾਕਈ ਉਤਪਾਦਿਕ ਡੀਐਨਏ ਬਣ ਗਈਆਂ। Ingres (SQL + ਕੁਐਰੀ ਅਪਟੀਮਾਈਜੇਸ਼ਨ), Postgres (extensibility + MVCC ਵਿਚਾਰ) ਅਤੇ Vertica (ਕਾਲਮਰ + MPP ਐਨਾਲਿਟਿਕਸ) ਵਿੱਚ ਸਾਬਤ ਕੀਤੀਆਂ ਗਈਆਂ ਵਿਚਾਰਧਾਰਾਵਾਂ ਅੱਜ ਵੀ ਵੇਅਰਹਾਊਸ, OLTP ਡੇਟਾਬੇਸ ਅਤੇ ਸਟ੍ਰੀਮਿੰਗ ਪਲੇਟਫਾਰਮਾਂ ਦੇ ਬਣਤਰ ਅਤੇ ਮਾਰਕੀਟਿੰਗ 'ਚ ਨਜ਼ਰ ਆਉਂਦੀਆਂ ਨੇ।
SQL ਨੇ ਇਸ ਲਈ ਜਿੱਤਿਆ ਕਿ ਇਸ ਨਾਲ ਤੁਸੀਂ ਇਹ ਵੇਖਾ ਸਕਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਕੀ ਚਾਹੁੰਦੇ ਹੋ, ਜਦੋਂ ਕਿ ਡੇਟਾਬੇਸ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਨਤੀਜਿਆਂ ਨੂੰ ਲਭਣ ਲਈ ਕਿਵੇਂ। ਇਹ ਵੱਖ-ਵੱਖ ਫਾਇਦੇ ਦਿੰਦਾ ਹੈ:
ਇਕ cost-based optimizer ਟੇਬਲ ਦੇ ਅੰਕੜਿਆਂ ਤੋਂ ਸੰਭਾਵਿਤ ਕੁਐਰੀ ਯੋਜਨਾਵਾਂ ਦੀ ਤੁਲਨਾ ਕਰਕੇ ਸਭ ਤੋਂ ਘੱਟ ਉਮੀਦਿਤ "ਲਾਗਤ" (I/O, CPU, ਮੈਮੋਰੀ) ਵਾਲੀ ਯੋਜਨਾ ਚੁਣਦਾ ਹੈ।ਅਮਲ ਵਿਚ ਇਹ ਤੁਹਾਨੂੰ:
MVCC (Multi-Version Concurrency Control) ਕਿਛੇ ਸਮੇਂ ਲਈ ਇੱਕ ਰੋਅ ਦੀਆਂ ਕਈ ਵਰਜਨਾਂ ਨੂੰ ਰੱਖਦਾ ਹੈ ਤਾਂ ਜੋ ਪੜ੍ਹਨ ਵਾਲੇ ਇੱਕ ਸਥਿਰ ਸਨੇਪਸ਼ਾਟ ਵੇਖ ਸਕਣ ਜਦੋਂ ਲਿਖਣ ਵਾਲੇ ਅੱਪਡੇਟ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ।ਰੋਜ਼ਾਨਾ ਜੀਵਨ ਵਿੱਚ ਇਸਦਾ ਫਾਇਦਾ ਇਹ ਹੈ:
Extensibility ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਨਵੀਆਂ ਸਮਰੱਥਾਵਾਂ — ਟਾਈਪ, ਫੰਕਸ਼ਨ, ਇੰਡੈਕਸ — ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਜੋੜ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਇੰਜਨ ਨੂੰ ਫੋਰਕ ਕੀਤੇ।ਇਸਦੇ ਫਾਇਦੇ:
ਆਪਰੇਸ਼ਨਲ ਨਿਯਮ: ਐਕਸਟੈਂਸ਼ਨਜ਼ ਨੂੰ ਡਿਪੈਂਡੇੰਸੀ ਵਾਂਗ ਵਰਤੋ—ਵਰਜ਼ਨਿੰਗ, ਟੈਸਟਿੰਗ ਅਤੇ ਕਿਸ ਨੂੰ ਇੰਸਟਾਲ ਕਰਨ ਦੀ ਆਗਿਆ ਹੈ, ਇਹ ਨਿਯੰਤਰਿਤ ਰੱਖੋ।
ਰੋਅ ਸਟੋਰ ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਲਈ ਵਧੀਆ ਹੁੰਦੇ ਹਨ ਜਿੱਥੇ ਤੁਸੀਂ ਅਕਸਰ ਪੂਰੇ ਰਿਕਾਰਡ ਨੂੰ ਪੜ੍ਹਦੇ ਜਾਂ ਲਿਖਦੇ ਹੋ (OLTP). ਕਾਲਮ ਸਟੋਰ ਉਨ੍ਹਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਚਮਕਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੇ ਰੋਅ ਨੂੰ ਸਕੈਨ ਕਰਦੇ ਹੋ ਪਰ ਸਿਰਫ਼ ਕੁਝ ਖੇਤਰਾਂ ਨੂੰ ਛੂਹਦੇ ਹੋ (ਐਨਾਲਿਟਿਕਸ)।
ਸਧਾਰਨ ਨਿਯਮ:
MPP (massively parallel processing) ਡਾਟਾ ਨੂੰ ਨੋਡਾਂ ਵਿਚ ਵੰਡ ਕੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਇਕੋ ਵੇਲੇ ਬਹੁਤ ਸਾਰੇ ਮਸ਼ੀਨ ਇੱਕ SQL ਕੁਐਰੀ 'ਤੇ ਕੰਮ ਕਰਨ।ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਦੋਂ:
ਟਰੇਡ-ਆਫ਼ ਅੰਦਰ: ਡੈਟਾ ਵਿਤਰਨ ਚੋਣਾਂ, ਜੋਇਨ ਦੌਰਾਨ ਸ਼ੁਫਲਿੰਗ ਲਾਗਤਾਂ, ਅਤੇ ਇਕੱਲੇ-ਰੋਅ ਅਪਡੇਟਸ ਲਈ ਘੱਟ ਸੁਵਿਧਾ।
Vectorized execution ਡੇਟਾ ਨੂੰ ਬੈਚਾਂ (vectors) ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ ਨਾਕਿ ਇਕ-ਇਕ ਰੋਅ ਅਨੁਸਾਰ, ਇਸ ਨਾਲ ਓਵਰਹੈਡ ਘਟਦਾ ਹੈ ਅਤੇ CPU cache ਬਿਹਤਰ ਤਰੀਕੇ ਨਾਲ ਵਰਤੀ ਜਾਂਦੀ ਹੈ।ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਇਹ ਤਰੀਕਾਂ ਅਨੁਭਵ ਕਰੋਗੇ:
ਬੈਚ ਸਿਸਟਮ ਪੀਰੀਆਡਿਕ ਜੌਬਾਂ ਚਲਾਉਂਦੇ ਹਨ, ਇਸ ਲਈ ਡੇਟਾ "ਤਾਜ਼ਾ" ਹੋਣ ਵਿੱਚ ਦੇਰੀ ਹੋ ਸਕਦੀ ਹੈ।ਸਟ੍ਰੀਮਿੰਗ ਸਿਸਟਮ ਘਟਨਾਵਾਂ ਨੂੰ ਲਗਾਤਾਰ ਇਨਪੁੱਟ ਵਜੋਂ ਲੈਂਦੇ ਹਨ ਅਤੇ ਨਤੀਜੇ ਨੂੰ ਇੰਕ੍ਰੀਮੈਂਟਲ ਤਰੀਕੇ ਨਾਲ ਨਵੀਨਤ ਕਰਦੇ ਹਨ।
ਜਿੱਥੇ ਸਟ੍ਰੀਮਿੰਗ ਤੁਰੰਤ ਲਾਭਦਾਇਕ ਹੁੰਦੀ ਹੈ:
ਸਟ੍ਰੀਮਿੰਗ ਵਿੱਚ ਨਤੀਜਿਆਂ ਨੂੰ ਸਿਮਤ ਰੱਖਣ ਲਈ ਵਿੰਡੋਜ਼ ਵਰਤੀ ਜਾਂਦੀਆਂ ਹਨ (ਉਦਾਹਰਣ: ਆਖਰੀ 5 ਮਿੰਟ)।
ਜਦੋਂ ਹਰ ਇਕ ਟੂਲ ਦਾ ਇੱਕ ਕਲੀਅਰ ਵਰਕਲੋਡ ਬਾਉਂਡਰੀ ਅਤੇ ਮਾਪਯੋਗ ਲਾਭ ਹੋਵੇ, ਤਾਂ ਕਈ ਸਿਸਟਮ ਵਰਤਣਾ ਠੀਕ ਹੈ (ਲਾਗਤ, ਲੇਟੈਂਸੀ, ਭਰੋਸਾ)।ਸਪ੍ਰੌਲ ਤੋਂ ਬਚਣ ਲਈ:
ਪੋਸਟ ਵਿੱਚ ਦਿੱਤੇ ਚੈੱਕਲਿਸਟ ਵਿਚਾਰ ਨੂੰ ਦੁਹਰਾਓ ਜੇ ਤੁਹਾਨੂੰ ਚੋਣ ਫਰੇਮਵਰਕ ਚਾਹੀਦਾ ਹੈ।
