ਸਿੱਖੋ ਕਿ ਕਿਵੇਂ ਕਾਲਮ-ਉਦਮਿਤ ਡੇਟਾਬੇਸ ਡੇਟਾ ਨੂੰ ਕਾਲਮ ਅਨੁਸਾਰ ਸਟੋਰ ਕਰਦੇ ਹਨ, ਕੰਪ੍ਰੈੱਸ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਨ ਕਰਦੇ ਹਨ, ਅਤੇ BI ਕੁਇਰੀਆਂ ਨੂੰ ਤੇਜ਼ ਕਰਦੇ ਹਨ। ਰੋ-ਸਟੋਰ ਨਾਲ ਤੁਲਨਾ ਕਰੋ ਅਤੇ ਚੁਣੋ।
ਐਨਾਲਿਟਿਕਸ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਕੁਇਰੀਆਂ BI ਡੈਸ਼ਬੋਰਡ, ਹਫਤਾਵਾਰੀ KPI ਈਮੇਲ, “ਅਸੀਂ ਪਿਛਲੇ ਤਿਮਾਹੀ ਵਿੱਚ ਕਿਵੇਂ ਕੀਆ?” ਵਾਂਗ ਦੇ ਰਿਵਿਊਂ ਅਤੇ ad‑hoc ਸਵਾਲਾਂ (ਜਿਵੇਂ “ਜਰਮਨੀ ਵਿੱਚ ਕਿਸ ਮਾਰਕੀਟਿੰਗ ਚੈਨਲ ਨੇ ਸਭ ਤੋਂ ਵੱਧ lifetime value ਦਿੱਤੀ?”) ਨੂੰ ਚਲਾਉਂਦੀਆਂ ਹਨ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਪੜ੍ਹਨ-ਭਾਰ ਵਾਲੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਬੜੇ ਇਤਿਹਾਸਕ ਡੇਟਾ ਦਾ ਸਰਲੰਸ਼ ਕਰਨ 'ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਹੁੰਦੀਆਂ ਹਨ।
ਇੱਕ ਸਧਾਰਣ ਰਿਕਾਰਡ ਲੱਭਣ ਦੀ ਥਾਂ, ਐਨਾਲਿਟਿਕਸ ਕੁਇਰੀਆਂ ਅਕਸਰ:
ਦੋ ਚੀਜ਼ਾਂ ਇੱਕ ਪਰੰਪਰਾਗਤ ਡੇਟਾਬੇਸ ਇੰਜਣ 'ਤੇ ਐਨਾਲਿਟਿਕਸ ਨੂੰ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦੀਆਂ ਹਨ:
ਵੱਡੇ ਸਕੈਨ ਮਹਿੰਗੇ ਹੁੰਦੇ ਹਨ। ਬਹੁਤ ਸਾਰੀਆਂ ਰੋਅਜ਼ ਪੜ੍ਹਨਾ ਮਤਲਬ ਬਹੁਤ ਸਾਰਾ ਡਿਸਕ ਅਤੇ ਮੈਮੋਰੀ ਐਕਟਿਵਿਟੀ, ਭਾਵੇਂ ਆਖਰੀ ਆਉਟਪੁੱਟ ਛੋਟਾ ਹੋਵੇ।
Concurrency ਇੱਕ ਹਕੀਕਤ ਹੈ। ਇੱਕ ਡੈਸ਼ਬੋਰਡ "ਇੱਕ ਕੁਇਰੀ" ਨਹੀਂ ਹੁੰਦਾ—ਇਹ ਕਈ ਚਾਰਟ ਹਨ ਜੋ ਇਕੱਠੇ ਲੋਡ ਹੁੰਦੇ ਹਨ, ਕਈ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਨਾਲ ਗੁਣਾ ਕਰਕੇ, ਨਾਲ ਹੀ ਨਿਯਤ ਰਿਪੋਰਟਾਂ ਅਤੇ تلاشਕਾਰੀ ਪੁੱਛਗਿੱਛ parallel ਚਲ ਰਹੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।
ਕਾਲਮ-ਉਦਮਿਤ ਸਿਸਟਮ ਸਕੈਨ ਅਤੇ aggregates ਨੂੰ ਤੇਜ਼ ਅਤੇ ਪੇਸ਼ਗੋਈਯੋਗ ਬਣਾਉਣ ਦਾ ਉਦੇਸ਼ ਰੱਖਦੇ ਹਨ—ਅਕਸਰ ਪ੍ਰਤੀ ਕੁਇਰੀ ਘੱਟ ਲਾਗਤ 'ਤੇ—ਜਦ ਕਿ ਡੈਸ਼ਬੋਰਡ ਲਈ ਉੱਚ concurrency ਨੂੰ ਸਮਰਥਨ ਵੀ ਦਿੰਦੇ ਹਨ।
ਤਾਜਗੀ ਇੱਕ ਵੱਖਰਾ ਪਹਿਲੂ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਐਨਾਲਿਟਿਕਸ ਸੈਟਅਪਜ਼ ਤੇਜ਼ ਰਿਪੋਰਟਿੰਗ ਲਈ ਡੇਟਾ ਨੂੰ ਬੈਚਾਂ ਵਿੱਚ ਲੋਡ ਕਰਕੇ (ਕੁਝ ਮਿੰਟਾਂ ਜਾਂ ਘੰਟਿਆਂ 'ਚ) sub-second ਅੱਪਡੇਟਾਂ ਦਾ ਤਿਆਗ ਕਰ ਦਿੰਦੇ ਹਨ। ਕੁਝ ਪਲੇਟਫਾਰਮ ਨੀਅਰ-ਰੀਅਲ-ਟਾਈਮ ingestion ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਪਰ updates ਅਤੇ deletes ਵਪਾਰਕ (transactional) ਸਿਸਟਮਾਂ ਦੇ ਮੁਕਾਬਲੇ ਵਧੇਰੇ ਜਟਿਲ ਹੋ ਸਕਦੇ ਹਨ।
ਕਾਲਮ-ਉਦਮਿਤ ਡੇਟਾਬੇਸ ਮੁੱਖ ਤੌਰ 'ਤੇ OLAP-ਸਟਾਈਲ ਕਾਰਜਾਂ ਲਈ ਬਣਾਏ ਜਾਂਦੇ ਹਨ।
ਕਾਲਮ-ਉਦਮਿਤ ਡੇਟਾਬੇਸ ਨੂੰ ਸਮਝਣ ਦਾ ਸਭ ਤੋਂ ਸਿੱਧਾ ਤਰੀਕਾ ਇਹ ਦਿਖਾਉਣਾ ਹੈ ਕਿ ਇੱਕ ਟੇਬਲ ਡਿਸਕ 'ਤੇ ਕਿਵੇਂ ਰੱਖੀ ਜਾਂਦੀ ਹੈ।
ਇੱਕ ਟੇਬਲ orders ਦੀ ਕਲਪਨਾ ਕਰੋ:
| order_id | customer_id | order_date | status | total |
|---|---|---|---|---|
| 1001 | 77 | 2025-01-03 | shipped | 120.50 |
| 1002 | 12 | 2025-01-03 | pending | 35.00 |
| 1003 | 77 | 2025-01-04 | shipped | 89.99 |
ਇੱਕ row store ਵਿੱਚ ਡੇਟਾਬੇਸ ਇਕੋ row ਤੋਂ ਆਉਣ ਵਾਲੀਆਂ ਵੈਲਿਊਜ਼ ਨੂੰ ਨਜ਼ਦੀਕ ਰੱਖਦਾ ਹੈ। ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਹੈ:
ਜੇ ਤੁਹਾਡੀ ਐਪ ਅਕਸਰ ਪੂਰੇ ਰਿਕਾਰਡ ਨੂੰ ਲੱਭਦੀ ਜਾਂ update ਕਰਦੀ ਹੈ (ਉਦਾਹਰਨ ਵਜੋਂ “order 1002 ਲੱਭੋ ਅਤੇ ਉਸਦਾ status update ਕਰੋ”), ਤਾਂ ਇਹ ਬਿਹਤਰ ਹੁੰਦਾ ਹੈ।
ਇੱਕ column store ਵਿੱਚ ਇੱਕੇ ਕਾਲਮ ਦੀਆਂ ਵੈਲ੍ਯੂਜ਼ ਇਕੱਠੀਆਂ ਰੱਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ:
order_id: 1001, 1002, 1003, …status: shipped, pending, shipped, …total: 120.50, 35.00, 89.99, …ਐਨਾਲਿਟਿਕਸ ਕੁਇਰੀਆਂ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਹੀ ਕਾਲਮ ਛੇੜਦੀਆਂ ਹਨ ਪਰ ਕਈ ਰੋਅਜ਼ ਸਕੈਨ ਕਰਦੀਆਂ ਹਨ। ਉਦਾਹਰਨ:
SUM(total) ਦਿਵਸ ਦੇ ਮੁਤਾਬਕAVG(total) ਗਾਹਕ ਮੁਤਾਬਕGROUP BY status ਕਰਕੇ orders ਦੀ ਗਿਣਤੀਕਾਲਮਰ ਸਟੋਰੇਜ ਨਾਲ, “total revenue per day” ਵਰਗੀ ਕੁਇਰੀ ਸਿਰਫ order_date ਅਤੇ total ਨੂੰ ਪੜ੍ਹ ਸਕਦੀ ਹੈ, ਬਿਨਾਂ ਹਰ ਰੋਅ ਲਈ customer_id ਅਤੇ status ਨੂੰ ਮੈਮੋਰੀ ਵਿੱਚ ਲਿਆਉਣ ਦੇ। ਘੱਟ ਡਾਟਾ ਪੜ੍ਹਿਆ ਜਾਣਾ ਤੇਜ਼ ਸਕੈਨ ਦਾ ਮੁੱਖ ਫਾਇਦਾ ਹੈ।
ਕਾਲਮਰ ਸਟੋਰੇਜ ਤੇਜ਼ ਹੈ ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਰਿਪੋਰਟਾਂ ਨੂੰ ਤੁਹਾਡੇ ਬਹੁਤ ਸਾਰੇ ਡੇਟਾ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਜੇ ਇਕ ਕੁਇਰੀ ਕੇਵਲ ਕੁਝ ਫੀਲਡਾਂ ਵਰਤੇ, ਤਾਂ ਕਾਲਮ-ਉਦਮਿਤ ਡੇਟਾਬੇਸ ਉਹੀ ਕਾਲਮ ਡਿਸਕ ਤੋਂ ਪੜ੍ਹ ਸਕਦਾ ਹੈ—ਪੂਰੀਆਂ ਰੋਅਜ਼ ਨਹੀਂ।
ਡੇਟਾ ਸਕੈਨ ਕਰਨ ਦੀ ਰਫਤਾਰ ਅਕਸਰ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਸਟੋਰੇਜ ਤੋਂ ਮੈਮੋਰੀ ਵਿੱਚ ਬਾਈਟ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਘੁੰਮਾਉਂਦੇ ਹੋ। ਇੱਕ ਰੋ-ਸਟੋਰ ਆਮ ਤੌਰ 'ਤੇ ਪੂਰੀਆਂ ਰੋਅਜ਼ ਪੜ੍ਹਦਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੀਆਂ “ਵਾਧੂ” ਵੈਲ੍ਯੂਜ਼ ਲਿਆਉਂਦੇ ਹੋ।
ਕਾਲਮਰ ਸਟੋਰੇਜ ਵਿੱਚ ਹਰ ਕਾਲਮ ਆਪਣੀ ਲਗਾਤਾਰ ਥਾਂ 'ਚ ਹੁੰਦਾ ਹੈ। ਇਸ ਲਈ “total revenue by day” ਵਰਗੀ ਕੁਇਰੀ ਸਿਰਫ:
ਪੜ੍ਹਦੀ ਹੈ। ਬਾਕੀ ਸਬ (ਨਾਂਵ, ਪਤੇ, ਨੋਟਸ, ਸੈਂਕੜੇ ਘੱਟ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਅੈਟਰਿਬਿਫ਼) ਡਿਸਕ 'ਤੇ ਰਹਿੰਦੇ ਹਨ।
ਐਨਾਲਿਟਿਕਸ ਟੇਬਲ ਵਕਤ ਦੇ ਨਾਲ ਚੌੜੀਆਂ ਹੋਨ ਲੱਗਦੀਆਂ ਹਨ: ਨਵੇਂ ਪ੍ਰੋਡਕਟ ਗੁਣ, ਮਾਰਕੀਟਿੰਗ ਟੈਗ, ਆਪਰੇਸ਼ਨ ਫਲੈਗ ਆਦਿ। ਪਰ ਰਿਪੋਰਟਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਛੋਟਾ subset ਛੇੜਦੀਆਂ ਹਨ—ਅਕਸਰ 5–20 ਕਾਲਮ 100+ ਵਿੱਚੋਂ।
ਕਾਲਮਰ ਸਟੋਰੇਜ ਇਸ ਹਕੀਕਤ ਨਾਲ ਮਿਲਦੀ ਹੈ। ਇਹ ਵਾਰਦਾਤੀ ਕਾਲਮਾਂ ਨੂੰ ਸਕੈਨ ਕਰਕੇ ਮਹਿੰਗਾ ਬਣਨ ਤੋਂ ਰੋਕਦੀ ਹੈ।
“Column pruning” ਦਾ ਅਰਥ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਉਹਨਾਂ ਕਾਲਮਾਂ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਜੋ ਕੁਇਰੀ ਨੇ ਹਵਾਲਾ ਨਹੀਂ ਦਿੱਤੇ। ਇਸ ਨਾਲ ਘਟਦਾ ਹੈ:
ਨਤੀਜਾ ਤੇਜ਼ ਸਕੈਨ ਅਤੇ ਵੱਡੇ ਡੇਟਾਸੈਟਾਂ 'ਤੇ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਬੇਹਤਰ ਪ੍ਰਦਰਸ਼ਨ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਅਨਵਾਂਢਾ ਡਾਟਾ ਲੋੜ ਤੋਂ ਵੱਧ ਹੋ।
ਕੰਪ੍ਰੈਸ਼ਨ ਕਾਲਮ-ਉਦਮਿਤ ਡੇਟਾਬੇਸ ਦਾ ਇੱਕ ਸ਼ਾਂਤ ਪਰ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹਥਿਆਰ ਹੈ। ਜਦੋਂ ਡੇਟਾ ਕਾਲਮ-ਅਨੁਸਾਰ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ, ਹਰ ਕਾਲਮ ਅਕਸਰ ਇੱਕੋ ਕਿਸਮ ਦੀਆਂ ਮੁੱਲਾਂ ਰੱਖਦਾ ਹੈ (ਤਾਰੀਖਾਂ, ਦੇਸ਼, status ਕੋਡ), ਅਤੇ ਇਹ ਇੱਕ-ਜਿਹੇ ਪੈਟਰਨ ਬਹੁਤ ਢੰਗ ਨਾਲ ਕੰਪ੍ਰੈੱਸ ਹੁੰਦੇ ਹਨ—ਇਹੋ same data row-by-row ਰੱਖਣ ਨਾਲੋਂ ਬਿਹਤਰ ਹੁੰਦਾ ਹੈ।
ਸੋਚੋ ਇੱਕ order_status ਕਾਲਮ ਜੋ ਜ਼ਿਆਦਾਤਰ shipped, processing, ਜਾਂ returned ਵਾਪਸ ਦਿੰਦਾ ਹੈ। ਜਾਂ ਇੱਕ timestamp ਕਾਲਮ ਜਿੱਥੇ ਮੁੱਲ ਲਗਾਤਾਰ ਵੱਧ ਰਹੀ ਹੋਵੇ। ਕਾਲਮ ਸਟੋਰ ਵਿੱਚ ਇਹ ਰੀਪਟੀਟਿਵ ਜਾਂ predictable ਪੈਟਰਨ ਇਕੱਠੇ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਡੇਟਾਬੇਸ ਉਹਨਾਂ ਨੂੰ ਘੱਟ ਬਿੱਟਾਂ 'ਚ ਦਰਸਾ ਸਕਦਾ ਹੈ।
ਅਨੇਕ ਤਕਨੀਕਾਂ ਮਿਲ ਕੇ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਉਦਾਹਰਨ:
ਘੱਟ ਡੇਟਾ ਮਤਲਬ ਡਿਸਕ ਜਾਂ object storage ਤੋਂ ਘੱਟ ਬਾਈਟ ਖਿੱਚਣੇ, ਅਤੇ ਮੈਮੋਰੀ/CPU caches ਵਿੱਚ ਘੱਟ ਡਾਟਾ ਭੇਜਣਾ। ਰਿਪੋਰਟਿੰਗ ਕੁਇਰੀਆਂ ਜੋ ਬਹੁਤ ਸਾਰੀਆਂ ਰੋਅਜ਼ ਸਕੈਨ ਕਰਦੀਆਂ ਹਨ ਪਰ ਕੇਵਲ ਕੁਝ ਕਾਲਮ ਲੈਂਦੀਆਂ ਹਨ, ਕੰਪ੍ਰੈਸ਼ਨ I/O ਨੂੰ ਨਿਰਣਾਦੇ ਤੌਰ 'ਤੇ ਘਟਾ ਦਿੰਦੀ ਹੈ।
ਇੱਕ ਵਧੀਆ ਬੋਨਸ: ਕਈ ਸਿਸਟਮ ਕੰਪ੍ਰੈਸ਼ਡ ਡੇਟਾ 'ਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ (ਜਾਂ ਵੱਡੇ ਬੈਚਾਂ ਵਿੱਚ decompress ਕਰਕੇ), ਜਿਸ ਨਾਲ aggregates ਜਿਵੇਂ sums, counts ਅਤੇ group-bys ਤੇਜ਼ ਰਹਿੰਦੇ ਹਨ।
ਕੰਪ੍ਰੈਸ਼ਨ ਮੁਫ਼ਤ ਨਹੀਂ ਹੁੰਦੀ। ਡੇਟਾਬੇਸ ingestion ਦੌਰਾਨ ਡੇਟਾ compress ਕਰਨ ਅਤੇ query ਦੌਰਾਨ decompress ਕਰਨ ਲਈ CPU ਵਰਤਦਾ ਹੈ। ਹਕੀਕਤ ਵਿੱਚ, ਐਨਾਲਿਟਿਕਸ ਵਰਕਲੋਡ ਅਕਸਰ ਅਜੇ ਵੀ ਜਿੱਤਦੇ ਹਨ ਕਿਉਂਕਿ I/O बचਤ CPU overhead ਨਾਲੋਂ ਵੱਧ ਹੁੰਦੀ ਹੈ—ਪਰ ਬਹੁਤ CPU-bound ਕੁਇਰੀਆਂ ਜਾਂ ਬਹੁਤ ਹੀ ਤਾਜ਼ਾ ਡੇਟਾ ਲਈ ਸੰਤੁਲਨ ਬਦਲ ਸਕਦਾ ਹੈ।
ਕਾਲਮਰ ਸਟੋਰੇਜ ਤੁਹਾਨੂੰ ਘੱਟ ਬਾਈਟ ਪੜ੍ਹਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ। ਵੇਕਟਰਾਈਜ਼ਡ ਪ੍ਰੋਸੈਸਿੰਗ ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰਦੀ ਹੈ ਕਿ ਜਦੋਂ ਉਹ ਬਾਈਟ ਮੈਮੋਰੀ ਵਿੱਚ ਆ ਜਾਂਦੇ ਹਨ ਤਾਂ ਤੁਸੀਂ ਤੇਜ਼ ਗਣਨਾ ਕਰੋ।
ਪਰੰਪਰਾਗਤ ਇੰਜਣ ਅਕਸਰ ਇਕ ਕੁਇਰੀ ਨੂੰ ਇੱਕ ਰੋ ਅਨੁਸਾਰ ਮੂਲਾਂਕਣ ਕਰਦੇ ਹਨ: ਇੱਕ ਰੋ ਲੋਡ ਕਰੋ, ਇੱਕ ਸ਼ਰਤ ਚੈੱਕ ਕਰੋ, ਇੱਕ aggregate update ਕਰੋ, ਅਗਲੀ ਰੋ 'ਤੇ ਜਾਓ। ਇਹ ਹਰ ਰੋਅ ਲਈ ਛੋਟੇ ਓਪਰੇਸ਼ਨ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ constant branching ਰਚਦਾ ਹੈ, ਜਿਸ ਨਾਲ CPU overhead ਵੱਧਦੀ ਹੈ।
ਵੇਕਟਰਾਈਜ਼ਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਮਾਡਲ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ: ਡੇਟਾਬੇਸ ਵੈਲ੍ਯੂਜ਼ ਨੂੰ ਬੈਚਾਂ (ਅਕਸਰ ਲੱਖਾਂ ਨਾਂਹੀਂ, ਪਰ ਹਜ਼ਾਰਾਂ) 'ਚ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹੈ। ਬਜਾਏ ਹਰ ਰੋਅ ਲਈ ਵਾਰ-ਵਾਰ ਲਾਜਿਕ ਚਲਾਏ ਜਾਣ ਦੇ, ਇੰਜਣ tight loops 'ਚ arrays ਉੱਤੇ ਕੰਮ ਕਰਦਾ ਹੈ।
ਬੈਚ ਪ੍ਰੋਸੈਸਿੰਗ ਇਹਨਾਂ ਕਾਰਨਾਂ ਕਰਕੇ CPU ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਬਿਹਤਰ ਬਣਾਉਂਦੀ ਹੈ:
ਕਲਪਨਾ ਕਰੋ: “2025 ਵਿੱਚ category = 'Books' ਲਈ ਕੁੱਲ ਰੇਵਨਿਊ।”
ਇੱਕ ਵੇਕਟਰਾਈਜ਼ਡ ਇੰਜਣ:
category ਦੀਆਂ ਬੈਚ ਵੈਲ੍ਹਯੂਜ਼ ਲੋਡ ਕਰਦਾ ਹੈ ਅਤੇ boolean mask ਬਣਾਉਂਦਾ ਹੈ ਜਿੱਥੇ category "Books" ਹੈ।order_date ਦੀਆਂ ਬੈਚ ਵੈਲ੍ਹਯੂਜ਼ ਲੋਡ ਕਰਕੇ mask ਨੂੰ 2025 ਲਈ ਅੱਗੇ ਸੰਕੁਚਿਤ ਕਰਦਾ ਹੈ।revenue ਵੈਲ੍ਯੂਜ਼ ਲੋਡ ਕਰਕੇ mask ਦੀ ਵਰਤੋਂ ਨਾਲ ਜੋੜ ਕਰਦਾ ਹੈ—ਅਕਸਰ SIMD ਨਾਲ ਇੱਕੋ ਚੱਕਰ ਵਿੱਚ ਕਈ ਨੰਬਰ ਜੋੜੇ ਜਾਂਦੇ ਹਨ।ਕਿਉਂਕਿ ਇਹ ਕਾਲਮ ਅਤੇ ਬੈਚਾਂ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਇੰਜਣ ਅਣ-ਸੰਬੰਧਿਤ ਫੀਲਡਾਂ ਨੂੰ ਛੇੜਨ ਤੋਂ ਬਚਦਾ ਹੈ ਅਤੇ per-row overhead ਘੱਟ ਰਹਿੰਦਾ ਹੈ—ਇਸੇ ਲਈ ਕਾਲਮ-ਉਦਮਿਤ ਸਿਸਟਮ ਐਨਾਲਿਟਿਕਸ ਵਿੱਚ ਬਹੁਤ ਵਧੀਆ ਹਨ।
ਐਨਾਲਿਟਿਕਸ ਕੁਇਰੀਆਂ ਅਕਸਰ ਬਹੁਤ ਸਾਰੀ ਰੋਅਜ਼ ਨੂੰ ਛੇੜਦੀਆਂ ਹਨ: “ਮਹੀਨਾ ਮੁਤਾਬਕ ਰੇਵਨਿਊ ਦਿਖਾਓ”, “ਦੇਸ਼ ਮੁਤਾਬਕ ਇਵੈਂਟਾਂ ਦੀ ਗਿਣਤੀ”, “ਟਾਪ 100 ਪ੍ਰੋਡਕਟ ਲੱਭੋ” ਆਦਿ। OLTP ਸਿਸਟਮਾਂ ਵਿੱਚ indexes ਆਮ ਹਥਿਆਰ ਹਨ ਕਿਉਂਕਿ queries ਆਮ ਤੌਰ 'ਤੇ ਥੋੜੇ ਰੋਅਜ਼ ਫੈਚ ਕਰਦੀਆਂ ਹਨ। ਐਨਾਲਿਟਿਕਸ ਲਈ ਬਹੁਤ ਸਾਰੇ indexes ਬਣਾਉਣਾ ਅਤੇ ਬਰਕਰਾਰ ਰੱਖਣਾ ਮਹਿੰਗਾ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਵੀ ਕਈ queries ਵੱਡੇ ਹਿੱਸੇ ਸਕੈਨ ਕਰਦੀਆਂ ਹਨ—ਇਸ ਲਈ column stores ਸਕੈਨਾਂ ਨੂੰ ਸਿਆਣਾ ਅਤੇ ਤੇਜ਼ ਬਣਾਉਣ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹਨ।
ਕਈ column-ਉਦਮਿਤ ਡੇਟਾਬੇਸ ਹਰ data block (ਕਦੇ 'stripe', 'row group', ਜਾਂ 'segment' ਕਿਹਾ ਜਾਂਦਾ ਹੈ) ਲਈ ਸਧਾਰਨ metadata ਰੱਖਦੇ ਹਨ—ਜਿਵੇਂ ਉਸ ਬਲਾਕ ਵਿੱਚ ਘੱਟ ਤੋਂ ਘੱਟ ਅਤੇ ਵੱਧ ਤੋਂ ਵੱਧ ਮੁੱਲ।
ਜੇ ਤੁਹਾਡੀ ਕੁਇਰੀ amount > 100 ਫਿਲਟਰ ਕਰਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਬਲਾਕ ਦਾ metadata ਦੱਸਦਾ ਹੈ ਕਿ max(amount) = 80, ਤਾਂ ਇੰਜਣ ਉਸ ਪੂਰੇ ਬਲਾਕ ਨੂੰ amount ਕਾਲਮ ਲਈ ਪੜ੍ਹਨ ਤੋਂ ਛੱਡ ਦੇਵੇਗਾ—ਪਾਰੰਪਰਿਕ index ਦੀ ਲੋੜ ਨਹੀਂ। ਇਹ zone maps ਸਟੋਰ ਕਰਨ ਲਈ ਸਸਤੇ ਅਤੇ ਜਾਂਚਣ ਲਈ ਤੇਜ਼ ਹਨ, ਅਤੇ ਉਹ ਕਾਫੀ ਅਚਛੇ ਨਤੀਜੇ ਦਿੰਦੇ ਹਨ ਜਦੋਂ columns ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਆਰਡਰਡ ਹੁੰਦੇ ਹਨ।
Partitioning ਟੇਬਲ ਨੂੰ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡ ਦਿੰਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ date ਮੁਤਾਬਕ। ਮੰਨੋ events date ਦੁਆਰਾ partition ਕੀਤੇ ਗਏ ਹਨ ਅਤੇ ਤੁਹਾਡੀ ਰਿਪੋਰਟ WHERE event_date BETWEEN '2025-10-01' AND '2025-10-31' ਮੰਗਦੀ ਹੈ। ਡੇਟਾਬੇਸ ਅਕਸਰ ਅਕਸਰ October ਤੋਂ ਬਾਹਰ ਵਾਲੇ ਸਾਰੇ partitions ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਸੰਬੰਧਤ partitions ਸਕੈਨ ਕਰੇਗਾ।
ਇਸ ਨਾਲ I/O ਵਿੱਚ ਵੱਡਾ ਕਟੋਤੀ ਆ ਸਕਦੀ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਨਾ صرف blocks ਬਲਕਿ ਫਾਇਲਾਂ ਜਾਂ ਟੇਬਲ ਦੇ ਵੱਡੇ ਭਾਗ ਛੱਡ ਰਹੇ ਹੋ।
ਜੇ ਡੇਟਾ ਆਮ filter keys (ਜਿਵੇਂ event_date, customer_id, ਜਾਂ country) ਨਾਲ sort ਜਾਂ cluster ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਮਿਲਦੇ ਮੁੱਲ ਇਕੱਠੇ ਰਹਿਣਗੇ। ਇਸ ਨਾਲ partition pruning ਅਤੇ zone-map ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦੇ ਹਨ, ਕਿਉਂਕਿ ਗੈਰ-ਮੈਚਿੰਗ ਬਲਾਕ ਤੁਰੰਤ min/max ਚੈੱਕ 'ਚ fail ਕਰ ਜਾਂਦੇ ਹਨ ਅਤੇ skip ਹੋ ਜਾਂਦੇ ਹਨ।
ਕਾਲਮ-ਉਦਮਿਤ ਡੇਟਾਬੇਸ ਤੇਜ਼ ਹਨ ਨਾਂ صرف ਇਸ ਲਈ ਕਿ ਉਹ ਪ੍ਰਤੀ ਕੁਇਰੀ ਘੱਟ ਡੇਟਾ ਪੜ੍ਹਦੇ ਹਨ, ਬਲਕਿ ਇਸ ਲਈ ਵੀ ਕਿ ਉਹ ਇਸਨੂੰ parallel ਢੰਗ ਨਾਲ ਪੜ੍ਹ ਸਕਦੇ ਹਨ।
ਇੱਕ single query (ਉਦਾਹਰਨ: "ਮਹੀਨਾ ਮੁਤਾਬਕ ਰੇਵਨਿਊ ਜੋੜੋ") ਅਕਸਰ ਮਿਲੀਅਨ ਜਾਂ ਬਿਲੀਅਨ ਵੈਲ੍ਯੂਜ਼ ਸਕੈਨ ਕਰਨ ਦੀ ਲੋੜ ਰੱਖਦੀ ਹੈ। Column stores ਆਮ ਤੌਰ 'ਤੇ ਕੰਮ ਨੂੰ CPU cores ਵਿੱਚ ਵੰਡਦੇ ਹਨ: ਹਰ ਕੋਰ column ਦੇ ਇੱਕ ਵੱਖੇ ਚੰਕ (ਜਾਂ partitions) ਨੂੰ ਸਕੈਨ ਕਰਦਾ ਹੈ।
ਕਾਲਮਰ ਡੇਟਾ ਵੱਡੇ, contiguous blocks ਵਿੱਚ ਸਟੋਰ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਹਰ ਕੋਰ ਆਪਣੇ block ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ stream ਕਰ ਸਕਦਾ ਹੈ—ਇਸ ਨਾਲ CPU caches ਅਤੇ disk bandwidth ਦੀ ਵਧੀਆ ਵਰਤੋਂ ਹੁੰਦੀ ਹੈ।
ਜਦੋਂ ਡੇਟਾ ਇੱਕ ਮਸ਼ੀਨ ਲਈ ਬਹੁਤ ਵੱਧ ਹੋ ਜਾਵੇ, ਡੇਟਾਬੇਸ ਇਸਨੂੰ ਕਈ ਸਰਵਰਾਂ 'ਤੇ ਵੰਡ ਸਕਦਾ ਹੈ। ਹਰ ਨੋਡ ਨੂੰ ਉਹ ਕੁਇਰੀ ਭੇਜੀ ਜਾਂਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਉਸ ਦੇ ਕੋਲ ਸੰਬੰਧਤ ਚੰਕ ਹਨ, ਅਤੇ ਹਰ ਨੋਡ ਆਪਣਾ local scan ਅਤੇ partial computation ਕਰਦਾ ਹੈ।
ਇੱਥੇ data locality ਮਹੱਤਵਪੂਰਣ ਹੁੰਦੀ ਹੈ: ਅਕਸਰ compute to the data ਕਰਨਾ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ, ਬਜਾਏ raw rows ਨੈਟਵਰਕ ਤੇ ਭੇਜਣ ਦੇ। ਨੈਟਵਰਕ ਸਾਂਝਾ ਅਤੇ ਮੈਮੋਰੀ ਤੋਂ ਹੌਲੀ ਹੁੰਦੀ ਹੈ ਅਤੇ ਜੇ intermediate results ਵੱਧ ਜਾਂ ਪਠਾਏ ਜਾਣ ਤਾਂ ਇਹ ਬੋਟਲਨੇਕ ਬਣ ਸਕਦੀ ਹੈ।
ਕਈ aggregates ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ parallel ਹੁੰਦੇ ਹਨ:
ਡੈਸ਼ਬੋਰਡ ਉੱਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਇੱਕੋ ਜਿਹੀਆਂ ਕੁਇਰੀਆਂ ਇੱਕੱਠੇ ਚਲ ਸਕਦੀਆਂ ਹਨ—ਖਾਸ ਕਰਕੇ ਘੰਟੇ ਦੀ ਸ਼ੁਰੂਆਤ 'ਤੇ ਜਾਂ ਮੀਟਿੰਗਾਂ ਦੌਰਾਨ। Column stores ਆਮ ਤੌਰ 'ਤੇ parallelism ਨੂੰ ਸਮਾਰਟ scheduling (ਉਤਪਾਦਕ caching ਦੇ ਨਾਲ) ਨਾਲ ਮਿਲਾ ਕੇ latency predictable ਰੱਖਦੇ ਹਨ ਜਦੋਂ ਦਰਜਨ ਤੋਂ ਸੈਂਕੜੇ ਉਪਭੋਗਤਾ ਚਾਰਟ ਰੀਫ੍ਰੈਸ਼ ਕਰਦੇ ਹਨ।
ਕਾਲਮ-ਉਦਮਿਤ ਡੇਟਾਬੇਸ ਉਹਨਾਂ ਸਥਿਤੀਆਂ 'ਚ ਮਹਾਰਤ ਰੱਖਦੇ ਹਨ ਜਿੱਥੇ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੀਆਂ ਰੋਅਜ਼ ਪੜ੍ਹਦੇ ਹੋ ਪਰ صرف ਕੁਝ ਕਾਲਮਾਂ ਨੂੰ। ਇਸ ਦਾ ਟਰੇਡ-ਆਫ਼ ਇਹ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਉਹ ਕਾਰਜ ਸਹਲ ਨਹੀਂ ਹੁੰਦੇ ਜਿੱਥੇ ਵਾਰ-ਵਾਰ ਇਕਲ-ਰੋਅ ਅਪਡੇਟ ਹੋ ਰਹੇ ਹੋਣ।
ਇੱਕ row store ਵਿੱਚ, ਇੱਕ ਗਾਹਕ ਦਾ ਰਿਕਾਰਡ update ਕਰਨਾ ਅਕਸਰ ਇੱਕ ਛੋਟੇ contiguous ਟੁਕੜੇ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖ ਕੇ ਹੋ ਜਾਂਦਾ ਹੈ। ਕਾਲਮ store ਵਿੱਚ, ਉਹ "ਇੱਕ ਰੋਅ" ਕਈ ਅਲੱਗ-ਅਲੱਗ ਕਾਲਮ ਫਾਇਲਾਂ/ਸੈਗਮੈਂਟਾਂ ਵਿੱਚ ਫੈਲਿਆ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਵੈਲ੍ਯੂ ਬਦਲਣ ਲਈ ਕਈ ਥਾਵਾਂ 'ਤੇ ਛੇੜਛਾੜ ਕਰਨੀ ਪੈਂਦੀ ਹੈ ਅਤੇ—ਕਾਂਪ੍ਰੈਸ਼ਨ ਅਤੇ ਠੋਸ ਬਲਾਕਾਂ ਕਰਕੇ—ਇਨ-ਪਲੇਸ ਚੇਂਜ ਵੱਡੇ ਚੰਕਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਐਨਾਲਿਟਿਕਲ column stores ਇੱਕ ਦੂ-ਹਿੱਸੇ ਵਾਲੀ ਪਹੁੰਚ ਵਰਤਦੇ ਹਨ:
ਇਸ ਲਈ ਅਕਸਰ ਤੁਸੀਂ ਸ਼ਬਦਾਂ ਵੇਖਦੇ ਹੋ: “delta + main”, “ingestion buffer”, “compaction”, ਜਾਂ “merge”。
ਜੇ ਤੁਹਾਨੂੰ ਡੈਸ਼ਬੋਰਡਾਂ 'ਤੇ ਤਬਦੀਲੀਆਂ ਤੁਰੰਤ ਵੇਖਣੀਆਂ ਹਨ ਤਾਂ ਇੱਕ ਪਿਊਰ column store ਕੁਝ ਹਦ ਤੱਕ ਧੀਰਜੀ ਜਾਂ ਮਹਿੰਗੀ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ। ਬਹੁਤ ਟੀਮਾਂ nearly real-time (ਜਿਵੇਂ 1–5 ਮਿੰਟ) ਕਬੂਲ ਕਰ ਲੈਂਦੀਆਂ ਹਨ ਤਾਂ ਕਿ merges ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਹੋ ਸਕਣ ਅਤੇ ਕੁਇਰੀਆਂ ਤੇਜ਼ ਰਹਿਣ।
ਬਾਰ-ਬਾਰ ਅਪਡੇਟਾਂ ਅਤੇ ਡਿਲੀਟਾਂ "tombstones" (ਹਟਾਏ/ਪੁਰਾਣੇ ਮੁੱਲਾਂ ਲਈ ਨਿਸ਼ਾਨ) ਅਤੇ fragmented segments ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ। ਇਸ ਨਾਲ ਸਟੋਰੇਜ ਵਧਦੀ ਹੈ ਅਤੇ ਜਦ ਤੱਕ maintenance jobs (vacuuming/compaction) ਉਨ੍ਹਾਂ ਨੂੰ ਸਾਫ਼ ਨਹੀਂ ਕਰਦੀਆਂ, queries ਹੌਲੀ ਹੋ ਸਕਦੀਆਂ ਹਨ। maintenance ਦੀ ਯੋਜਨਾ—ਟਾਈਮਿੰਗ, ਸਰੋਤ ਸੀਮਾਵਾਂ, ਅਤੇ retention ਨੀਤੀਆਂ—ਰਿਪੋਰਟਿੰਗ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਪੇਸ਼ਗੋਈਯੋਗ ਰੱਖਣ ਦਾ ਅہم ਹਿੱਸਾ ਹੈ।
ਚੰਗੀ ਮਾਡਲਿੰਗ ਇੰਜਣ ਦੇ ਬਰਾਬਰ ਹੀ ਮਹੱਤਵਪੂਰਣ ਹੈ। ਕਾਲਮਰ ਸਟੋਰੇਜ ਤੇਜ਼ ਸਕੈਨ ਅਤੇ aggregate ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਤੁਸੀਂ ਟੇਬਲਾਂ ਨੂੰ ਕਿਵੇਂ ਸੰਰਚਿਤ ਕਰਦੇ ਹੋ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਕਿੰਨੀ ਵਾਰ ਅਣ-ਲੋੜੀਂਦੀਆਂ ਕਾਲਮਾਂ ਤੋਂ ਬਚ ਸਕਦਾ ਹੈ, ਡੇਟਾ ਚੰਕਾਂ ਨੂੰ ਕਿਵੇਂ skip ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ GROUP BYs ਕਿਵੇਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋ ਸਕਦੇ ਹਨ।
ਇੱਕ star schema ਇੱਕ ਕੇਂਦਰੀ fact table ਨੂੰ ਚੁਣਦੀ ਹੈ ਜੋ ਛੋਟੀਆਂ dimension tables ਨਾਲ ਘਿਰੀ ਹੁੰਦੀ ਹੈ। ਇਹ ਐਨਾਲਿਟਿਕਸ ਲਈ ਸੁਟਦਾ ਹੈ ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਰਿਪੋਰਟਾਂ:
ਕਾਲਮਰ ਸਿਸਟਮਾਂ ਨੂੰ ਲਾਭ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ queries ਆਮ ਤੌਰ 'ਤੇ ਚੌੜੇ fact table ਦੇ ਛੋਟੇ subset ਕਾਲਮਾਂ ਨੂੰ ਛੇੜਦੀਆਂ ਹਨ।
ਉਦਾਹਰਨ:
fact_orders: order_id, order_date_id, customer_id, product_id, quantity, net_revenuedim_customer: customer_id, region, segmentdim_product: product_id, category, branddim_date: date_id, month, quarter, yearਜੇਕਰ ਰਿਪੋਰਟ "ਮਹੀਨਾ ਅਤੇ ਖੇਤਰ ਮੁਤਾਬਕ net_revenue" ਹੈ, ਤਾਂ ਇਹ fact_orders ਤੋਂ net_revenue aggregate ਕਰਦੀ ਹੈ ਅਤੇ dim_date ਅਤੇ dim_customer ਦੇ attributes ਨਾਲ ਗ੍ਰੁੱਪ ਕਰਦੀ ਹੈ।
Star schemas joins 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਬਹੁਤ ਸਾਰੇ column-ਉਦਮਿਤ ਡੇਟਾਬੇਸ joins ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੰਭਾਲਦੇ ਹਨ, ਪਰ join ਲਾਗਤ ਡੇਟਾ ਮਾਪ ਅਤੇ concurrency ਦੇ ਨਾਲ ਵਧਦੀ ਹੈ।
Denormalization ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕੋਈ dimension attribute ਬਾਰ-ਬਾਰ ਵਰਤੀ ਜਾਂਦੀ ਹੋ (ਉਦਾਹਰਨ ਲਈ region ਨੂੰ fact_orders ਵਿੱਚ ਨਕਲ ਕਰਨਾ)। ਇਸਦਾ trade-off ਵੱਡੇ fact rows, duplicated values, ਅਤੇ attribute ਬਦਲਣ 'ਤੇ ਵੱਧ ਕੰਮ ਹੈ। ਇੱਕ ਆਮ ਸਮਝੌਤਾ ਇਹ ਹੈ ਕਿ dimension normalized ਰੱਖੋ ਪਰ ਜੇ ਕੋਈ attribute ਵੱਡੀ dashboards ਲਈ ਲਗਾਤਾਰ ਹਿਸਾ ਹੈ ਤਾਂ ਉਸਨੂੰ fact ਵਿੱਚ cache ਕਰ ਲੋ—ਬੱਸ ਜਦੋਂ ਇਹ ਵਾਸਤਵ ਵਿੱਚlepší ਪ੍ਰਦਰਸ਼ਨ ਦਿਉਂਦਾ ਹੋਵੇ।
region, category) ਅਤੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਉਹਨਾਂ ਨੂੰ low-to-medium cardinality ਰੱਖੋ।date_id, ਫਿਰ customer_id) ਤਾਂ ਕਿ filters ਅਤੇ GROUP BYs ਸਸਤੇ ਪੈਂ।ਕਾਲਮ-ਉਦਮਿਤ ਡੇਟਾਬੇਸ ਉਹਨਾਂ ਹਾਲਾਤਾਂ 'ਚ ਜ਼ਿਆਦਾ ਫਾਇਦਾ ਦਿੰਦੇ ਹਨ ਜਿੱਥੇ ਤੁਹਾਡੇ ਸਵਾਲ ਬਹੁਤ ਸਾਰੀਆਂ ਰੋਅਜ਼ ਨੂੰ ਛੇੜਦੇ ਹਨ ਪਰ ਕੇਵਲ ਕੁਝ ਕਾਲਮਾਂ; ਖ਼ਾਸ ਕਰਕੇ ਜਦ ਜਵਾਬ ਇੱਕ aggregate (sum, average, percentiles) ਜਾਂ grouped report (day/by region/by customer segment) ਹੋਵੇ।
ਜੇ ਤੁਹਾਡਾ ਵਰਕਲੋਡ high-rate point lookups (ਇੱਕ user record ID ਦੁਆਰਾ ਲੱਭਣਾ) ਜਾਂ ਛੋਟੇ transactional updates (ਪੂਰਾ-ਵੇਲੇ order status update) ਨਾਲ ਭਰਪੂਰ ਹੈ, ਤਾਂ ਇੱਕ row-oriented OLTP ਡੇਟਾਬੇਸ ਆਮ ਤੌਰ 'ਤੇ ਵਧੀਆ ਫਿੱਟ ਹੋਵੇਗਾ।
ਕਾਲਮ stores inserts ਅਤੇ ਕੁਝ updates ਸਮਰਥਨ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਬਾਰ-ਬਾਰ row-level changes ਦਾ ਕਾਰੋਬਾਰ ਜ਼ਿਆਦਾ ਢੀਲਾ ਜਾਂ ਓਪਰੇਸ਼ਨਲ ਤੌਰ 'ਤੇ ਜ਼ਿਆਦਾ ਜਟਿਲ ਹੋ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ: write amplification, merge ਪ੍ਰਕਿਰਿਆਵਾਂ, ਜਾਂ visibility ਵਿੱਚ ਦੇਰ)।
ਕਮਿਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ benchmark ਕਰੋ:
ਇੱਕ ਛੋਟਾ PoC ਜੋ production-ਸ਼ੇਪਡ ਡੇਟਾ ਵਰਤੇ ਉਹ synthetic tests ਜਾਂ vendor comparisons ਤੋਂ ਜ਼ਿਆਦਾ ਸੱਚੇ ਨਤੀਜੇ ਦਿਖਾਏਗਾ।
ਡੇਟਾਬੇਸ ਚੁਣਨਾ benchmaks ਦੇ ਪਿਛੇ ਭੱਜਣ ਤੋਂ ਵੱਧ, ਤੁਹਾਡੇ ਰਿਪੋਰਟਿੰਗ ਹਕੀਕਤ ਨਾਲ ਸਿਸਟਮ ਨੂੰ ਮੈਚ ਕਰਨ ਬਾਰੇ ਹੈ: ਕੌਣ ਇਸਨੂੰ ਕੁਇਰੀ ਕਰਦਾ ਹੈ, ਕਿੰਨੀ ਵਾਰੀ, ਅਤੇ ਸਵਾਲ ਕਿੰਨੇ predictable ਹਨ।
ਕੁਝ ਛੋਟੇ ਪਰ ਮੱਤਵਪੂਰਨ ਪ੍ਰਸ਼ਨ:
ਬਹੁਤ ਟੀਮ ਸਿੱਧੇ ਡੇਟਾਬੇਸ ਨੂੰ query ਨਹੀਂ ਕਰਦੀਆਂ। ਯਕੀਨੀ ਬਣਾਓ:
ਛੋਟਾ ਪਰ ਹਕੀਕਤੀ ਰੱਖੋ:
ਜੇ ਕੋਈ ਉਮੀਦਵਾਰ ਉਹਨਾਂ ਮੈਟਰਿਕਸ 'ਤੇ ਜਿੱਤਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਓਪਰੇਸ਼ਨਲ ਆਰਾਮ ਦੀ ਪੱਧਰੀ 'ਚ ਫਿੱਟ ਬੈਠਦਾ ਹੈ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਠੀਕ ਚੋਣ ਹੁੰਦੀ ਹੈ।
ਕਾਲਮ-ਉਦਮਿਤ ਸਿਸਟਮ ਐਨਾਲਿਟਿਕਸ ਲਈ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਉਹ ਕੰਮ ਨਹੀਂ ਕਰਦੇ ਜੋ ਤੁਹਾਨੂੰ ਨਹੀਂ ਚਾਹੀਦਾ। ਉਹ ਘੱਟ ਬਾਇਟ ਪੜ੍ਹਦੇ ਹਨ (ਕੇਵਲ ਜਿਹੜੇ ਕਾਲਮ refer ਕੀਤੇ ਗਏ), ਉਹਨਾਂ ਬਾਈਟਾਂ ਨੂੰ ਬਹੁਤ ਅਚਛੀ ਤਰ੍ਹਾਂ ਕੰਪ੍ਰੈੱਸ ਕਰਦੇ ਹਨ (ਇਸ ਲਈ ਡਿਸਕ ਅਤੇ ਮੈਮੋਰੀ ਟ੍ਰੈਫਿਕ ਘੱਟ ਹੁੰਦਾ ਹੈ), ਅਤੇ ਉਹ ਬੈਚਾਂ ਵਿੱਚ ਐਗਜ਼ੀਕਿਊਟ ਕਰਦੇ ਹਨ ਜੋ CPU caches ਲਈ ਅਨੁਕੂਲ ਹੁੰਦੀਆਂ ਹਨ। ਇਸਨੂੰ ਕੋਰਾਂ ਅਤੇ ਨੋਡਾਂ 'ਤੇ parallelism ਮਿਲਾ ਦਿਓ, ਅਤੇ ਜੋ ਰਿਪੋਰਟਿੰਗ ਕੁਇਰੀਆਂ pehle slowly ਚੱਲਦੀਆਂ ਸਨ, ਉਹ ਸੈਕੰਡਾਂ 'ਚ ਮੁਕੰਮਲ ਹੋ ਸਕਦੀਆਂ ਹਨ।
ਅਕਸਰ ਇਨ੍ਹਾਂ ਸੰਕੇਤਾਂ ਨੂੰ ਨਿਰੰਤਰ ਦੇਖਣਾ ਲਾਭਕਾਰੀ ਹੈ:
ਜੇ scans ਵੱਡੇ ਹਨ, ਤਾਂ column selection, partitions, ਅਤੇ sort order ਨੂੰ ਦੁਬਾਰਾ ਵੇਖੋ—ਹਾਰਡਵੇਅਰ ਵਧਾਉਣ ਤੋਂ ਪਹਿਲਾਂ।
Read-mostly workloads (ਰਾਤ ਦੀਆਂ ਰਿਪੋਰਟਾਂ, BI ਡੈਸ਼ਬੋਰਡ, ad-hoc exploration) ਨੂੰ ਪਹਿਲਾਂ offload ਕਰੋ। transactional ਸਿਸਟਮ ਤੋਂ column store ਵਿੱਚ ਡੇਟਾ replicate ਕਰੋ, ਨਤੀਜੇ side-by-side validate ਕਰੋ, ਫਿਰ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਮੋੜੋ।.rollback path ਰੱਖੋ (ਛੋਟੇ ਸਮੇਂ ਲਈ dual-run), ਅਤੇ ਕੇਵਲ ਉਸ ਵੇਲੇ ਦਾਇਰਾ ਵਧਾਓ ਜਦੋਂ ਮਾਨੀਟਰਨਗ stable scan volumes ਅਤੇ predictable performance ਦਿਖਾਵੇ।
ਇੱਕ column store ਕੁਇਰੀ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ, ਪਰ ਟੀਮਾਂ ਅਕਸਰ ਉਹ ਸਮਾਂ ਗਵਾ ਦਿੰਦੀਆਂ ਹਨ ਜੋ surrounding reporting experience ਬਣਾਉਣ ਵਿੱਚ ਲੱਗਦਾ ਹੈ: ਇੱਕ ਅੰਦਰੂਨੀ metrics ਪੋਰਟਲ, role-based access, scheduled report delivery, ਅਤੇ "one-off" ਵਿਸਲੇਸ਼ਣ ਟੂਲ ਜੋ ਬਾਅਦ ਵਿੱਚ ਪੱਕੇ ਫੀਚਰ ਬਣ ਜਾਂਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਉਸ ਐਪਲੀਕੇਸ਼ਨ ਲੇਅਰ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai ਤੁਹਾਡੇ ਲਈ React ਵੈੱਬ ਐਪ, Go backend ਸਰਵਿਸਜ਼, ਅਤੇ PostgreSQL ਇੰਟਰਗ੍ਰੇਸ਼ਨ ਇੱਕ ਚੈਟ-ਅਧਾਰਿਤ ਯੋਜਨਾ ਤੋਂ ਜਨਰੇਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਪ੍ਰਯੋਗਿਕ ਢੰਗ ਨਾਲ ਲਾਭਦਾਇਕ ਹੈ ਜਿਵੇਂ ਕਿ:
Koder.ai ਕੋਡ ਨਿਰਯਾਤ, ਡਿਪਲੋਇਮੈਂਟ/ਹੋਸਟਿੰਗ, ਅਤੇ rollback snapshots ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਰਿਪੋਰਟਿੰਗ ਫੀਚਰਾਂ 'ਤੇ iterate ਕਰ ਸਕਦੇ ਹੋ ਤੇ ਬਦਲਾਅ ਨਿਯੰਤਰਿਤ ਰੱਖ ਸਕਦੇ ਹੋ—ਜਦੋਂ ਕਈ stakeholder ਇੱਕੋ ਜਿਹੇ ਡੈਸ਼ਬੋਰਡਾਂ ਤੇ ਨਿਰਭਰ ਹੋਣ।
ਐਨਾਲਿਟਿਕਸ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਕੁਇਰੀਆਂ ਵੱਡੀ ਮਾਤਰਾ ਦੇ ਇਤਿਹਾਸਕ ਡੇਟਾ ਨੂੰ ਸੰਖੇਪ ਵਿੱਚ ਪੇਸ਼ ਕਰਨ ਵਾਲੀਆਂ ਪੜ੍ਹਨ-ਭਾਰਿਤ ਪੁੱਛਗਿੱਛਾਂ ਹਨ—ਜਿਵੇਂ ਮਹੀਨੇ ਮੁਤਾਬਕ ਰੈਵਨੂੰ, ਮੁਹਿੰਮ ਮੁਤਾਬਕ ਕੰਵਰਜ਼ਨ, ਜਾਂ ਕੋਹੋਰਟ ਰੀਟੇਨਸ਼ਨ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਕਈ ਪੰਗਤੀਆਂ ਨੂੰ ਸਕੈਨ ਕਰਦੀਆਂ ਹਨ, ਕੁਝ ਕਾਲਮਾਂ ਨੂੰ ਛੂਹਦੀਆਂ ਹਨ, ਸਾਰਾਂਸ਼ (aggregates) ਗਣਨਾ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਚਾਰਟਾਂ ਜਾਂ ਟੇਬਲਾਂ ਲਈ ਛੋਟਾ ਨਤੀਜਾ ਵਾਪਿਸ ਕਰਦੀਆਂ ਹਨ।
ਉਹਨਾਂ ਨੇ ਡੇਟਾਬੇਸਾਂ 'ਤੇ ਮੁੱਖ ਤੌਰ 'ਤੇ ਦੋ ਤਰੀਕਿਆਂ ਨਾਲ ਦਬਾਅ ਪਾਇਆ:
Row-oriented OLTP ਇੰਜਣ ਇਹ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਲਾਗਤ ਅਤੇ ਲੇਟੈਂਸੀ ਅਣਪੇਖਿਆ ਹੋ ਸਕਦੇ ਹਨ।
ਸਰਲ لفظਾਂ ਵਿੱਚ:
ਜੇਕਰ ਤੁਹਾਡੀ ਰਿਪੋਰਟ ਨੂੰ ਕੇਵਲ ਅਤੇ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਤਾਂ column store ਬੇਸਰੋ-ਪੈਰ ਜਾਂ ਵਰਗੀਆਂ ਗੈਰ-ਲੋੜੀਂਦੀਆਂ ਕਾਲਮਾਂ ਨੂੰ ਪੜ੍ਹਨ ਤੋਂ ਬਚ ਸਕਦਾ ਹੈ।
ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਐਨਾਲਿਟਿਕਸ ਕੁਇਰੀਆਂ ਕੇਵਲ ਇਕ ਛੋਟੇ subset ਕਾਲਮਾਂ ਨੂੰ ਪੜ੍ਹਦੀਆਂ ਹਨ। Column stores column pruning ਲਾਗੂ ਕਰ ਸਕਦੇ ਹਨ (ਜਿਹੜੀਆਂ ਕਾਲਮਾਂ ਦੀ ਲੋੜ ਨਹੀਂ, ਉਹ ਛੱਡ ਦਿਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ), ਇਸ ਲਈ ਉਹ ਘੱਟ ਬਾਇਟ ਪੜ੍ਹਦੇ ਹਨ।
ਘੱਟ I/O ਆਮ ਤੌਰ 'ਤੇ ਨਤੀਜੇ ਹਨ:
ਕਾਲਮਰ ਲੇਆ웃 ਇੱਕੋ ਕਿਸਮ ਦੀਆਂ ਵੈਲ੍ਯੂਜ਼ ਨੂੰ ਇਕੱਠੇ ਰੱਖਦਾ ਹੈ (ਤਾਰੀਖਾਂ ਨਾਲ ਤਾਰੀਖਾਂ, ਦੇਸ਼ਾਂ ਨਾਲ ਦੇਸ਼), ਜਿਸ ਨਾਲ ਕੰਪ੍ਰੈਸ਼ਨ ਬਹੁਤ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦੀ ਹੈ।
ਆਮ ਤਰੀਕੇ:
value + count ਦੇ ਰੂਪ ਵਿੱਚ ਸਟੋਰ ਕਰਨਾ।ਕੰਪ੍ਰੈਸ਼ਨ ਸਟੋਰੇਜ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਸਕੈਨ ਤੇਜ਼ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਘੱਟ ਡੇਟਾ ਇ/O ਹੋਂਦਾ ਹੈ। ਹਾਲਾਂਕਿ ingesion ਅਤੇ query ਸਮੇਂ ਕੁਝ CPU ਵੇਖਿਆ ਜਾਂਦਾ ਹੈ (compress/decompress), ਪਰ ਆਮ ਤੌਰ 'ਤੇ I/O ਬਚਤ ਇਸ overhead ਤੋਂ ਵੱਧ ਮੁੱਲ ਦਿੰਦੀ ਹੈ।
Vectorized execution ਡੇਟਾ ਨੂੰ ਬੈਚਾਂ (ਹਜ਼ਾਰਾਂ ਵੈਲ੍ਯੂਜ਼ ਇੱਕ ਵਾਰੀ) 'ਚ ਸੰਭਾਲਦਾ ਹੈ ਨਾ ਕਿ ਇਕ-ਇਕ ਰੋ 'ਤੇ।
ਇਸ ਦੇ ਫਾਇਦੇ:
ਇਹ ਵਿਧੀ column stores ਨੂੰ ਉਸ ਸਮੇਂ ਵੀ ਤੇਜ਼ ਬਣਾਉਂਦੀ ਹੈ ਜਦੋਂ ਉਹ ਵੱਡੀ ਰੇਂਜਾਂ ਨੂੰ ਸਕੈਨ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ।
ਅਕਸਰ ਇੰਜਨਾਂ ਹਰੇਕ ਡੇਟਾ ਬਲਾਕ (stripe/row group/segment) ਲਈ ਸਿੱਧਾ metadata ਰੱਖਦੇ ਹਨ—ਉਦਾਹਰਨ ਲਈ ਉਸ ਬਲਾਕ ਵਿੱਚ min ਅਤੇ max value।
ਜੇਕਰ ਤੁਹਾਡੀ ਕੁਇਰੀ amount > 100 ਫਿਲਟਰ ਕਰਦੀ ਹੈ ਅਤੇ ਕਿਸੇ ਬਲਾਕ ਦਾ max(amount) = 80 ਹੈ, ਤਾਂ ਇੰਜਣ ਉਸ ਬਲਾਕ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਕਿਪ ਕਰ ਸਕਦਾ ਹੈ।
ਇਹ ਵਿਧੀ ਬਹੁਤ ਸਾਰੀਆਂ ਹੋਰ ਤਕਨੀਕਾਂ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਬਾਈਨ ਹੁੰਦੀ ਹੈ:
ਕਾਲਮਰ ਡੇਟਾਬੇਸਜ਼ ਘੱਟ ਡੇਟਾ ਪੜ੍ਹਦੇ ਹਨ ਅਤੇ ਇਸ ਨੂੰ highly parallel ਢੰਗ ਨਾਲ ਕਰਦੇ ਹਨ:
ਆਮ ਪੈਟਰਨ split-and-merge ਹੁੰਦੀ ਹੈ: ਹਰੇਕ ਸਾਈਟ ਤੇ ਅੰਸ਼ਕਿ ਨਤੀਜੇ ਕੱਢੇ ਜਾਂਦੇ ਹਨ, ਫਿਰ ਉਨ੍ਹਾਂ ਨੂੰ ਇਕੱਠਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਜਿਵੇਂ sums ਨੂੰ ਜੋੜ ਕੇ ਅੰਤਿਮ sum ਮਿਲਦਾ ਹੈ)।
ਇੱਕ ਰੋ-ਸਟੋਰ ਵਿੱਚ ਇੱਕ ਰੋਅ ਅਪਡੇਟ ਅਕਸਰ ਇੱਕ ਛੋਟੇ contiguous ਖੇਤਰ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਨਾਲ ਹੋ ਜਾਂਦੀ ਹੈ। ਕਾਲਮ-ਸਟੋਰ ਵਿੱਚ ਇੱਕ 'ਰੋਅ' ਕਈ ਕਾਲਮ ਫਾਇਲ/ਸੈਗਮੈਂਟਾਂ 'ਚ ਫੈਲੀ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਵੈਲ੍ਯੂ ਬਦਲਣ ਲਈ ਕਈ ਥਾਵਾਂ ਨੂੰ ਛੇੜਨਾ ਪੈਂਦਾ ਹੈ ਅਤੇ compress/packed blocks ਦੇ ਕਾਰਨ ਇੱਕ in-place ਚੇੰਜ ਵੱਡੇ ਚੰਕਾਂ ਨੂੰ ਰੀਰਾਈਟ ਕਰਨ ਦੀ ਲੋੜ ਪਾ ਸਕਦੀ ਹੈ।
ਆਮ ਰਣਨੀਤੀਆਂ:
ਇਸ ਲਈ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮ ਨੇਅਰ-ਰੀਅਲ-ਟਾਈਮ (ਉਦਾਹਰਨ: 1–5 ਮਿੰਟ ਦੇ ਡੀਲੇ) ਨੂੰ ਕਬੂਲ ਕਰ ਲੈਂਦੀਆਂ ਹਨ ਬਜਾਏ ਕਿ ਸਾਰੇ ਇਨਸਟੈਂਟ ਅੱਪਡੇਟ ਦੇ।
Star schema columnar analytics ਲਈ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਮੈਚ ਕਰਦੀ ਹੈ: ਇੱਕ ਵੱਡੀ fact table ਤੇ ਕਈ ਛੋਟੀਆਂ dimension tables।
ਫਾਇਦੇ:
ਮਾਡਲਿੰਗ ਸੁਝਾਵ:
ਜਿੱਥੇ ਤੁਸੀਂ ਕਈ ਰੋਅਜ਼ ਨੂੰ ਛੇੜ ਕੇ ਕੁਝ ਕਾਲਮਾਂ 'ਤੇ aggregates ਜਾਂ GROUP BY ਚਲਾਉਂਦੇ ਹੋ, column stores ਜ਼ਿਆਦਾਤਰ ਮੁਕਾਬਲੇ 'ਚ ਜਿੱਤਦੇ ਹਨ।
ਚੰਗੇ ਉਦੇਸ਼:
ਕਦੋਂ row store ਚੰਗਾ ਹੈ:
ਪੈਮਾਨੇ ਦੇ ਖਿਆਲ ਨਾਲ ਵਰਕਲੋਡ ਦੇ ਨਾਲ ਮਿਲਦੇ-ਜੁਲਦੇ ਮਾਪਦੰਡ ਤੇ ਧਿਆਨ ਦਿਓ:
ਪ੍ਰਯੋਗਕਲਾ (PoC) ਦੌਰਾਨ ਆਪਣੀਆਂ ਅਸਲ ਕੁਇਰੀਆਂ ਅਤੇ ਡੇਟਾ ਨਾਲ ਨਾਪੋ—ਇਹ vendor benchmarks ਤੋਂ ਜ਼ਿਆਦਾ ਕੀਮਤੀ ਆਮ ਤੌਰ 'ਤੇ ਸਾਬਤ ਹੁੰਦਾ ਹੈ।
order_datetotalstatuscustomer_iddate_id ਫਿਰ customer_id) ਤਾਂ ਕਿ skip ਅਤੇ compression ਚੰਗੀ ਹੋਵੇ।