ਅਸਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਕਲਿਕਹਾਊਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਸਿਧਾਂਤ ਅਤੇ ਅਭਿਆਸ। ਅਲੈਗਜ਼ੈਂਡਰ ਜ਼ੈਤਸੇਵ (2018)

ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਹੁਣ ਲਗਭਗ ਹਰ ਜਗ੍ਹਾ ਬਹੁਤ ਸਾਰਾ ਡੇਟਾ ਹੈ, ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਡੇਟਾਬੇਸ ਅਜੇ ਵੀ ਕਾਫ਼ੀ ਵਿਦੇਸ਼ੀ ਹਨ. ਉਹ ਬਹੁਤ ਘੱਟ ਜਾਣੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਵਰਤਣ ਲਈ ਵੀ ਘੱਟ ਸਮਰੱਥ ਹਨ। ਬਹੁਤ ਸਾਰੇ MySQL ਜਾਂ PostgreSQL ਨਾਲ "ਕੈਕਟਸ ਖਾਣਾ" ਜਾਰੀ ਰੱਖਦੇ ਹਨ, ਜੋ ਕਿ ਹੋਰ ਸਥਿਤੀਆਂ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਹਨ, NoSQL ਨਾਲ ਸੰਘਰਸ਼ ਕਰਦੇ ਹਨ, ਜਾਂ ਵਪਾਰਕ ਹੱਲਾਂ ਲਈ ਵੱਧ ਭੁਗਤਾਨ ਕਰਦੇ ਹਨ। ਕਲਿਕਹਾਊਸ ਇੱਕ ਗੇਮ ਚੇਂਜਰ ਹੈ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ DBMS ਦੀ ਦੁਨੀਆ ਵਿੱਚ ਦਾਖਲੇ ਲਈ ਰੁਕਾਵਟ ਨੂੰ ਮਹੱਤਵਪੂਰਣ ਰੂਪ ਵਿੱਚ ਘਟਾਉਂਦਾ ਹੈ।

ਰਿਪੋਰਟ ਬੈਕਐਂਡ ਕੌਂਫ 2018 ਦੀ ਹੈ ਅਤੇ ਇਹ ਸਪੀਕਰ ਦੀ ਆਗਿਆ ਨਾਲ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤੀ ਗਈ ਹੈ।

ਮੈਂ ਕੌਣ ਹਾਂ ਅਤੇ ਮੈਂ ਕਲਿਕਹਾਊਸ ਬਾਰੇ ਕਿਉਂ ਗੱਲ ਕਰ ਰਿਹਾ ਹਾਂ? ਮੈਂ ਲਾਈਫਸਟ੍ਰੀਟ 'ਤੇ ਵਿਕਾਸ ਦਾ ਡਾਇਰੈਕਟਰ ਹਾਂ, ਜੋ ਕਲਿਕਹਾਊਸ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਮੈਂ Altinity ਦਾ ਸੰਸਥਾਪਕ ਵੀ ਹਾਂ। ਇਹ ਇੱਕ Yandex ਪਾਰਟਨਰ ਹੈ ਜੋ ClickHouse ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ ਅਤੇ Yandex ਨੂੰ ClickHouse ਨੂੰ ਹੋਰ ਸਫਲ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਮੈਂ ਕਲਿਕਹਾਊਸ ਬਾਰੇ ਗਿਆਨ ਸਾਂਝਾ ਕਰਨ ਲਈ ਵੀ ਤਿਆਰ ਹਾਂ।

ਅਤੇ ਮੈਂ ਪੇਟੀਆ ਜ਼ੈਤਸੇਵ ਦਾ ਭਰਾ ਵੀ ਨਹੀਂ ਹਾਂ। ਮੈਨੂੰ ਅਕਸਰ ਇਸ ਬਾਰੇ ਪੁੱਛਿਆ ਜਾਂਦਾ ਹੈ। ਨਹੀਂ, ਅਸੀਂ ਭਰਾ ਨਹੀਂ ਹਾਂ।

"ਹਰ ਕੋਈ ਜਾਣਦਾ ਹੈ" ਕਿ ਕਲਿਕਹਾਊਸ:

• ਬਹੁਤ ਤੇਜ,
• ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ,
• Yandex ਵਿੱਚ ਵਰਤਿਆ ਗਿਆ ਹੈ.

ਇਹ ਥੋੜਾ ਘੱਟ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਕੰਪਨੀਆਂ ਵਿੱਚ ਅਤੇ ਇਸਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ.

ਮੈਂ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗਾ ਕਿ ਯਾਂਡੇਕਸ ਤੋਂ ਇਲਾਵਾ ਕਲਿਕਹਾਊਸ ਕਿਉਂ, ਕਿੱਥੇ ਅਤੇ ਕਿਵੇਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

ਮੈਂ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗਾ ਕਿ ਵੱਖ-ਵੱਖ ਕੰਪਨੀਆਂ ਵਿੱਚ ਕਲਿਕਹਾਊਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਖਾਸ ਸਮੱਸਿਆਵਾਂ ਕਿਵੇਂ ਹੱਲ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਤੁਸੀਂ ਆਪਣੇ ਕੰਮਾਂ ਲਈ ਕਿਹੜੇ ਕਲਿਕਹਾਊਸ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਕੰਪਨੀਆਂ ਵਿੱਚ ਕਿਵੇਂ ਵਰਤਿਆ ਗਿਆ ਸੀ।

ਮੈਂ ਤਿੰਨ ਉਦਾਹਰਣਾਂ ਦੀ ਚੋਣ ਕੀਤੀ ਹੈ ਜੋ ਵੱਖ-ਵੱਖ ਪਾਸਿਆਂ ਤੋਂ ਕਲਿਕਹਾਊਸ ਦਿਖਾਉਂਦੀਆਂ ਹਨ। ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਦਿਲਚਸਪ ਹੋਵੇਗਾ।

ਪਹਿਲਾ ਸਵਾਲ ਹੈ: "ਸਾਨੂੰ ਕਲਿਕਹਾਊਸ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ?" ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਸਵਾਲ ਕਾਫ਼ੀ ਸਪੱਸ਼ਟ ਹੈ, ਪਰ ਇਸਦੇ ਇੱਕ ਤੋਂ ਵੱਧ ਜਵਾਬ ਹਨ.

• ਪਹਿਲਾ ਜਵਾਬ ਪ੍ਰਦਰਸ਼ਨ ਕਾਰਨਾਂ ਲਈ ਹੈ. ਕਲਿਕਹਾਊਸ ਬਹੁਤ ਤੇਜ਼ ਹੈ। ਕਲਿਕਹਾਊਸ 'ਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਵੀ ਬਹੁਤ ਤੇਜ਼ ਹੈ। ਇਹ ਅਕਸਰ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜਿੱਥੇ ਕੋਈ ਹੋਰ ਚੀਜ਼ ਬਹੁਤ ਹੌਲੀ ਜਾਂ ਬਹੁਤ ਮਾੜੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰ ਰਹੀ ਹੈ।
• ਦੂਜਾ ਜਵਾਬ ਲਾਗਤ ਹੈ. ਅਤੇ ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਸਕੇਲਿੰਗ ਦੀ ਲਾਗਤ. ਉਦਾਹਰਨ ਲਈ, Vertica ਇੱਕ ਬਿਲਕੁਲ ਸ਼ਾਨਦਾਰ ਡਾਟਾਬੇਸ ਹੈ। ਇਹ ਬਹੁਤ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰਾ ਟੈਰਾਬਾਈਟ ਡੇਟਾ ਨਹੀਂ ਹੈ। ਪਰ ਜਦੋਂ ਅਸੀਂ ਸੈਂਕੜੇ ਟੈਰਾਬਾਈਟ ਜਾਂ ਪੇਟਾਬਾਈਟਸ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਤਾਂ ਲਾਇਸੈਂਸ ਅਤੇ ਸਹਾਇਤਾ ਦੀ ਕੀਮਤ ਕਾਫ਼ੀ ਮਹੱਤਵਪੂਰਨ ਰਕਮ ਦੇ ਬਰਾਬਰ ਹੈ। ਅਤੇ ਇਹ ਮਹਿੰਗਾ ਹੈ। ਅਤੇ ਕਲਿਕਹਾਊਸ ਮੁਫ਼ਤ ਹੈ।
• ਤੀਜਾ ਜਵਾਬ ਓਪਰੇਟਿੰਗ ਲਾਗਤ ਹੈ. ਇਹ ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਤਰੀਕਾ ਹੈ। RedShift ਇੱਕ ਵਧੀਆ ਐਨਾਲਾਗ ਹੈ. RedShift ਨਾਲ ਤੁਸੀਂ ਬਹੁਤ ਜਲਦੀ ਫੈਸਲਾ ਲੈ ਸਕਦੇ ਹੋ। ਇਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰੇਗਾ, ਪਰ ਉਸੇ ਸਮੇਂ, ਹਰ ਘੰਟੇ, ਹਰ ਦਿਨ ਅਤੇ ਹਰ ਮਹੀਨੇ ਤੁਸੀਂ ਐਮਾਜ਼ਾਨ ਨੂੰ ਬਹੁਤ ਸਾਰਾ ਭੁਗਤਾਨ ਕਰੋਗੇ, ਕਿਉਂਕਿ ਇਹ ਬਹੁਤ ਮਹਿੰਗੀ ਸੇਵਾ ਹੈ. Google BigQuery ਵੀ। ਜੇ ਕਿਸੇ ਨੇ ਇਸਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ, ਤਾਂ ਉਹ ਜਾਣਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਉੱਥੇ ਕਈ ਸਵਾਲ ਚਲਾ ਸਕਦੇ ਹੋ ਅਤੇ ਅਚਾਨਕ ਸੈਂਕੜੇ ਡਾਲਰਾਂ ਲਈ ਇੱਕ ਇਨਵੌਇਸ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ.

ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਇਹ ਸਮੱਸਿਆਵਾਂ ਨਹੀਂ ਹਨ।

ਕਲਿਕਹਾਊਸ ਹੁਣ ਕਿੱਥੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ? Yandex ਤੋਂ ਇਲਾਵਾ, ਕਲਿਕਹਾਊਸ ਦੀ ਵਰਤੋਂ ਵੱਖ-ਵੱਖ ਕਾਰੋਬਾਰਾਂ ਅਤੇ ਕੰਪਨੀਆਂ ਦੇ ਸਮੂਹ ਵਿੱਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਆਕਾਰ ਮਾਇਨੇ ਨਹੀਂ ਰੱਖਦਾ. ਬਹੁਤ ਸਾਰੀਆਂ ਕੰਪਨੀਆਂ ਹਨ ਜੋ ਇੱਕ ਛੋਟੇ ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ. ਅਤੇ ਉਹ ਉਨ੍ਹਾਂ ਨੂੰ ਆਪਣੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰਨ ਦਿੰਦਾ ਹੈ। ਅਤੇ ਹੋਰ ਵੀ ਕੰਪਨੀਆਂ ਬਹੁਤ ਸਾਰੇ ਸਰਵਰਾਂ ਜਾਂ ਦਰਜਨਾਂ ਸਰਵਰਾਂ ਦੇ ਵੱਡੇ ਕਲੱਸਟਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ।

ਅਤੇ ਜੇ ਤੁਸੀਂ ਰਿਕਾਰਡਾਂ ਨੂੰ ਦੇਖਦੇ ਹੋ, ਤਾਂ:

• ਯਾਂਡੇਕਸ: 500+ ਸਰਵਰ, ਉਹ ਉੱਥੇ ਇੱਕ ਦਿਨ ਵਿੱਚ 25 ਬਿਲੀਅਨ ਰਿਕਾਰਡ ਸਟੋਰ ਕਰਦੇ ਹਨ।
• ਲਾਈਫਸਟ੍ਰੀਟ: 60 ਸਰਵਰ, ਪ੍ਰਤੀ ਦਿਨ ਲਗਭਗ 75 ਬਿਲੀਅਨ ਰਿਕਾਰਡ। ਯਾਂਡੇਕਸ ਦੇ ਮੁਕਾਬਲੇ ਘੱਟ ਸਰਵਰ ਅਤੇ ਜ਼ਿਆਦਾ ਰਿਕਾਰਡ ਹਨ।
• CloudFlare: 36 ਸਰਵਰ, ਉਹ ਪ੍ਰਤੀ ਦਿਨ 200 ਬਿਲੀਅਨ ਰਿਕਾਰਡ ਸਟੋਰ ਕਰਦੇ ਹਨ। ਉਹਨਾਂ ਕੋਲ ਹੋਰ ਵੀ ਘੱਟ ਸਰਵਰ ਹਨ ਅਤੇ ਹੋਰ ਵੀ ਡਾਟਾ ਸਟੋਰ ਕਰਦੇ ਹਨ।
• ਬਲੂਮਬਰਗ: 102 ਸਰਵਰ, ਪ੍ਰਤੀ ਦਿਨ ਲਗਭਗ ਇੱਕ ਟ੍ਰਿਲੀਅਨ ਰਿਕਾਰਡ। ਰਿਕਾਰਡ ਧਾਰਕ.

ਭੂਗੋਲਿਕ ਤੌਰ 'ਤੇ, ਇਹ ਵੀ ਬਹੁਤ ਹੈ. ਇਹ ਨਕਸ਼ਾ ਦੁਨੀਆ ਵਿੱਚ ਕਲਿਕਹਾਊਸ ਦੀ ਵਰਤੋਂ ਦਾ ਹੀਟਮੈਪ ਦਿਖਾਉਂਦਾ ਹੈ। ਇੱਥੇ ਰੂਸ, ਚੀਨ ਅਤੇ ਅਮਰੀਕਾ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਖੜ੍ਹੇ ਹਨ। ਕੁਝ ਯੂਰਪੀ ਦੇਸ਼ ਹਨ. ਅਤੇ 4 ਕਲੱਸਟਰਾਂ ਨੂੰ ਵੱਖ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

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

ਮੈਂ ਇਹ ਸਭ ਕਿਉਂ ਦੱਸ ਰਿਹਾ ਹਾਂ? ਇਹ ਦਿਖਾਉਣ ਲਈ ਕਿ ਕਲਿਕਹਾਊਸ ਵੱਡੇ ਡੇਟਾ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਇੱਕ ਮਿਆਰੀ ਹੱਲ ਬਣ ਰਿਹਾ ਹੈ ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਕਈ ਥਾਵਾਂ 'ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ. ਜੇਕਰ ਤੁਸੀਂ ਇਸਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸਹੀ ਰੁਝਾਨ 'ਤੇ ਹੋ। ਜੇਕਰ ਤੁਸੀਂ ਅਜੇ ਤੱਕ ਇਸਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ ਤੁਹਾਨੂੰ ਡਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਇਕੱਲੇ ਛੱਡ ਦਿੱਤਾ ਜਾਵੇਗਾ ਅਤੇ ਕੋਈ ਵੀ ਤੁਹਾਡੀ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ, ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੇ ਪਹਿਲਾਂ ਹੀ ਅਜਿਹਾ ਕਰ ਰਹੇ ਹਨ।

ਇਹ ਕਈ ਕੰਪਨੀਆਂ ਵਿੱਚ ਕਲਿਕਹਾਊਸ ਦੀ ਅਸਲ ਵਰਤੋਂ ਦੀਆਂ ਉਦਾਹਰਣਾਂ ਹਨ।

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

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

ਕੰਪਨੀ ਨੇ ਇੱਕ ਲੰਮਾ ਅਤੇ ਕੰਡਿਆਲੇ ਰਾਹ ਆਇਆ ਹੈ. ਅਤੇ ਮੈਂ ਇਸ ਬਾਰੇ ਹਾਈਲੋਡ 'ਤੇ ਗੱਲ ਕੀਤੀ. ਪਹਿਲਾਂ, ਲਾਈਫਸਟ੍ਰੀਟ MySQL (Oracle 'ਤੇ ਇੱਕ ਸੰਖੇਪ ਸਟਾਪ ਦੇ ਨਾਲ) ਤੋਂ Vertica ਵਿੱਚ ਮਾਈਗਰੇਟ ਹੋ ਗਈ। ਅਤੇ ਤੁਸੀਂ ਇਸ ਬਾਰੇ ਇੱਕ ਕਹਾਣੀ ਲੱਭ ਸਕਦੇ ਹੋ.

ਅਤੇ ਸਭ ਕੁਝ ਬਹੁਤ ਵਧੀਆ ਸੀ, ਪਰ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਡੇਟਾ ਵਧ ਰਿਹਾ ਸੀ ਅਤੇ ਵਰਟਿਕਾ ਮਹਿੰਗਾ ਸੀ. ਇਸ ਲਈ ਵੱਖ-ਵੱਖ ਵਿਕਲਪਾਂ ਦੀ ਮੰਗ ਕੀਤੀ ਗਈ। ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਇੱਥੇ ਸੂਚੀਬੱਧ ਹਨ। ਅਤੇ ਵਾਸਤਵ ਵਿੱਚ, ਅਸੀਂ 13 ਤੋਂ 16 ਤੱਕ ਮਾਰਕੀਟ ਵਿੱਚ ਉਪਲਬਧ ਲਗਭਗ ਸਾਰੇ ਡੇਟਾਬੇਸ ਦੀ ਧਾਰਨਾ ਜਾਂ ਕਈ ਵਾਰ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਜਾਂਚ ਕੀਤੀ ਸੀ ਅਤੇ ਕਾਰਜਸ਼ੀਲਤਾ ਵਿੱਚ ਲਗਭਗ ਢੁਕਵੇਂ ਸਨ। ਅਤੇ ਮੈਂ ਹਾਈਲੋਡ 'ਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਬਾਰੇ ਵੀ ਗੱਲ ਕੀਤੀ.

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

ਕਿੱਥੇ ਜਾਣਾ ਹੈ? ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਸਪਸ਼ਟ ਸੀ ਕਿ ਕਿੱਥੇ ਜਾਣਾ ਹੈ, ਕਿਉਂਕਿ ਇੱਕ ਪਾਸੇ ਵਪਾਰਕ ਡੇਟਾਬੇਸ ਹਨ, ਉਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੇ ਜਾਪਦੇ ਹਨ. ਕੁਝ ਲਗਭਗ ਵਰਟੀਕਾ ਦੇ ਨਾਲ-ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ, ਕੁਝ ਬਦਤਰ। ਪਰ ਉਹ ਸਾਰੇ ਮਹਿੰਗੇ ਹਨ, ਕੁਝ ਵੀ ਸਸਤਾ ਜਾਂ ਬਿਹਤਰ ਨਹੀਂ ਲੱਭਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਦੂਜੇ ਪਾਸੇ, ਓਪਨ ਸੋਰਸ ਹੱਲ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਨਹੀਂ ਹਨ, ਅਰਥਾਤ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਪਾਸੇ ਗਿਣਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਅਤੇ ਉਹ ਮੁਫਤ ਜਾਂ ਸਸਤੇ ਹਨ, ਪਰ ਉਹ ਹੌਲੀ ਹੌਲੀ ਕੰਮ ਕਰਦੇ ਹਨ. ਅਤੇ ਉਹਨਾਂ ਵਿੱਚ ਅਕਸਰ ਲੋੜੀਂਦੀ ਅਤੇ ਉਪਯੋਗੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਘਾਟ ਹੁੰਦੀ ਹੈ.

ਅਤੇ ਵਪਾਰਕ ਡੇਟਾਬੇਸ ਵਿੱਚ ਹਨ ਅਤੇ ਓਪਨ ਸੋਰਸ ਵਿੱਚ ਹੋਣ ਵਾਲੀਆਂ ਸਾਰੀਆਂ ਮੁਫਤ ਚੀਜ਼ਾਂ ਨੂੰ ਜੋੜਨ ਲਈ ਕੁਝ ਵੀ ਨਹੀਂ ਸੀ.

ਕੁਝ ਨਹੀਂ ਹੋਇਆ ਜਦੋਂ ਤੱਕ ਯਾਂਡੇਕਸ ਨੇ ਅਚਾਨਕ ਕਲਿਕਹਾਊਸ ਨੂੰ ਜਾਦੂਗਰ ਦੇ ਖਰਗੋਸ਼ ਵਾਂਗ ਟੋਪੀ ਤੋਂ ਬਾਹਰ ਨਹੀਂ ਕੱਢ ਲਿਆ। ਅਤੇ ਇਹ ਇੱਕ ਅਚਾਨਕ ਫੈਸਲਾ ਸੀ; ਲੋਕ ਅਜੇ ਵੀ ਸਵਾਲ ਪੁੱਛਦੇ ਹਨ: "ਕਿਉਂ?", ਪਰ ਫਿਰ ਵੀ.

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

ਮੈਂ ਬਹੁਤ ਆਲਸੀ ਨਹੀਂ ਸੀ ਅਤੇ ਦੂਜੇ ਦਿਨ ਹੋਰ ਯਾਂਡੇਕਸ ਟੈਸਟਾਂ ਨੂੰ ਦੇਖਿਆ। ਇਹ ਉੱਥੇ ਹੀ ਹੈ: ਕਲਿਕਹਾਊਸ ਵਰਟਿਕਾ ਨਾਲੋਂ ਦੁੱਗਣਾ ਤੇਜ਼ ਹੈ, ਇਸ ਲਈ ਉਹ ਅਕਸਰ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਨ।

ਪਰ ਜੇ ਸਵਾਲਾਂ ਵਿੱਚ ਜੋੜ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਸਭ ਕੁਝ ਬਹੁਤ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੁੰਦਾ. ਅਤੇ ਕਲਿਕਹਾਊਸ ਵਰਟੀਕਾ ਨਾਲੋਂ ਦੁੱਗਣਾ ਹੌਲੀ ਹੋ ਸਕਦਾ ਹੈ। ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਬੇਨਤੀ ਨੂੰ ਥੋੜਾ ਜਿਹਾ ਠੀਕ ਅਤੇ ਦੁਬਾਰਾ ਲਿਖਦੇ ਹੋ, ਤਾਂ ਉਹ ਲਗਭਗ ਬਰਾਬਰ ਹੋਣਗੇ। ਭੈੜਾ ਨਹੀਂ. ਅਤੇ ਇਹ ਮੁਫ਼ਤ ਹੈ।

ਅਤੇ ਟੈਸਟ ਦੇ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਤੇ ਇਸ ਨੂੰ ਵੱਖ-ਵੱਖ ਕੋਣਾਂ ਤੋਂ ਦੇਖਦੇ ਹੋਏ, ਲਾਈਫਸਟ੍ਰੀਟ ਕਲਿਕਹਾਊਸ 'ਤੇ ਗਈ।

ਇਹ 16ਵਾਂ ਸਾਲ ਹੈ, ਮੈਂ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਂਦਾ ਹਾਂ। ਇਹ ਚੂਹੇ ਬਾਰੇ ਮਜ਼ਾਕ ਵਾਂਗ ਸੀ ਜੋ ਰੋਂਦਾ ਸੀ ਅਤੇ ਆਪਣੇ ਆਪ ਨੂੰ ਟੀਕਾ ਲਗਾਉਂਦਾ ਸੀ, ਪਰ ਕੈਕਟਸ ਨੂੰ ਖਾਣਾ ਜਾਰੀ ਰੱਖਦਾ ਸੀ। ਅਤੇ ਇਸ ਬਾਰੇ ਵਿਸਥਾਰ ਵਿੱਚ ਚਰਚਾ ਕੀਤੀ ਗਈ ਸੀ, ਇਸ ਬਾਰੇ ਇੱਕ ਵੀਡੀਓ ਹੈ, ਆਦਿ.

ਇਸ ਲਈ, ਮੈਂ ਇਸ ਬਾਰੇ ਵਿਸਥਾਰ ਵਿੱਚ ਗੱਲ ਨਹੀਂ ਕਰਾਂਗਾ, ਮੈਂ ਸਿਰਫ ਨਤੀਜਿਆਂ ਅਤੇ ਕੁਝ ਦਿਲਚਸਪ ਗੱਲਾਂ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਮੈਂ ਉਦੋਂ ਗੱਲ ਨਹੀਂ ਕੀਤੀ ਸੀ.

ਨਤੀਜੇ ਹਨ:

• ਸਫਲ ਮਾਈਗ੍ਰੇਸ਼ਨ ਅਤੇ ਸਿਸਟਮ ਇੱਕ ਸਾਲ ਤੋਂ ਵੱਧ ਸਮੇਂ ਤੋਂ ਉਤਪਾਦਨ ਵਿੱਚ ਹੈ।
• ਉਤਪਾਦਕਤਾ ਅਤੇ ਲਚਕਤਾ ਵਧੀ ਹੈ। 10 ਬਿਲੀਅਨ ਰਿਕਾਰਡਾਂ ਵਿੱਚੋਂ ਜੋ ਅਸੀਂ ਸਿਰਫ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਪ੍ਰਤੀ ਦਿਨ ਸਟੋਰ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਰੱਖਦੇ ਹਾਂ, ਲਾਈਫਸਟ੍ਰੀਟ ਹੁਣ ਪ੍ਰਤੀ ਦਿਨ 75 ਬਿਲੀਅਨ ਰਿਕਾਰਡ ਸਟੋਰ ਕਰਦੀ ਹੈ ਅਤੇ ਅਜਿਹਾ 3 ਮਹੀਨਿਆਂ ਜਾਂ ਇਸ ਤੋਂ ਵੱਧ ਸਮੇਂ ਲਈ ਕਰ ਸਕਦੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਸਿਖਰ 'ਤੇ ਗਿਣਦੇ ਹੋ, ਤਾਂ ਇਹ ਪ੍ਰਤੀ ਸਕਿੰਟ ਇੱਕ ਮਿਲੀਅਨ ਇਵੈਂਟਸ ਤੱਕ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਦਿਨ ਵਿੱਚ ਇੱਕ ਮਿਲੀਅਨ ਤੋਂ ਵੱਧ SQL ਸਵਾਲ ਇਸ ਸਿਸਟਮ ਨੂੰ ਭੇਜੇ ਜਾਂਦੇ ਹਨ, ਜ਼ਿਆਦਾਤਰ ਵੱਖ-ਵੱਖ ਰੋਬੋਟਾਂ ਤੋਂ।
• ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਕਲਿਕਹਾਊਸ ਨੇ ਵਰਟਿਕਾ ਨਾਲੋਂ ਵਧੇਰੇ ਸਰਵਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਸ਼ੁਰੂ ਕੀਤੀ, ਹਾਰਡਵੇਅਰ 'ਤੇ ਵੀ ਬਚਤ ਕੀਤੀ ਗਈ, ਕਿਉਂਕਿ ਵਰਟੀਕਾ ਨੇ ਕਾਫ਼ੀ ਮਹਿੰਗੀਆਂ SAS ਡਿਸਕਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਕਲਿਕਹਾਊਸ ਨੇ SATA ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਅਤੇ ਕਿਉਂ? ਕਿਉਂਕਿ ਵਰਟੀਕਾ ਇਨਸਰਟ ਸਮਕਾਲੀ ਹੈ। ਅਤੇ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਡਿਸਕਾਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੌਲੀ ਨਾ ਹੋਣ, ਅਤੇ ਇਹ ਵੀ ਕਿ ਨੈੱਟਵਰਕ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੌਲੀ ਨਾ ਹੋਵੇ, ਭਾਵ, ਇੱਕ ਬਹੁਤ ਮਹਿੰਗਾ ਓਪਰੇਸ਼ਨ। ਅਤੇ ClickHouse ਵਿੱਚ ਸੰਮਿਲਿਤ ਅਸਿੰਕ੍ਰੋਨਸ ਹੈ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਤੁਸੀਂ ਹਮੇਸ਼ਾ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸਭ ਕੁਝ ਲਿਖ ਸਕਦੇ ਹੋ, ਇਸਦੇ ਲਈ ਕੋਈ ਵਾਧੂ ਖਰਚੇ ਨਹੀਂ ਹਨ, ਇਸਲਈ ਡੇਟਾ ਨੂੰ ਵਰਟਿਕਾ ਨਾਲੋਂ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਪਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਭਾਵੇਂ ਸਭ ਤੋਂ ਤੇਜ਼ ਡਿਸਕਾਂ 'ਤੇ ਵੀ ਨਹੀਂ। ਅਤੇ ਪੜ੍ਹਨਾ ਵੀ ਇਹੀ ਹੈ. SATA 'ਤੇ ਪੜ੍ਹਨਾ, ਜੇ ਉਹ RAID ਵਿੱਚ ਹਨ, ਤਾਂ ਇਹ ਸਭ ਕਾਫ਼ੀ ਤੇਜ਼ ਹੈ.
• ਲਾਇਸੈਂਸ ਦੁਆਰਾ ਅਸੀਮਤ, 3 ਸਰਵਰਾਂ ਵਿੱਚ 60 ਪੇਟਾਬਾਈਟ ਡੇਟਾ (20 ਸਰਵਰ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਹਨ) ਅਤੇ ਤੱਥਾਂ ਅਤੇ ਸਮੁੱਚਿਆਂ ਵਿੱਚ 6 ਟ੍ਰਿਲੀਅਨ ਰਿਕਾਰਡ। ਵਰਟੀਕਾ ਅਜਿਹਾ ਕੁਝ ਵੀ ਬਰਦਾਸ਼ਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਸੀ।

ਹੁਣ ਮੈਂ ਇਸ ਉਦਾਹਰਣ ਵਿੱਚ ਵਿਹਾਰਕ ਚੀਜ਼ਾਂ ਵੱਲ ਜਾ ਰਿਹਾ ਹਾਂ।

• ਪਹਿਲੀ ਇੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸਕੀਮ ਹੈ. ਬਹੁਤ ਕੁਝ ਸਕੀਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ.
• ਦੂਜਾ ਕੁਸ਼ਲ SQL ਤਿਆਰ ਕਰ ਰਿਹਾ ਹੈ.

ਇੱਕ ਆਮ OLAP ਪੁੱਛਗਿੱਛ ਚੁਣੀ ਗਈ ਹੈ। ਕੁਝ ਕਾਲਮ ਗਰੁੱਪ ਅਨੁਸਾਰ ਜਾਂਦੇ ਹਨ, ਕੁਝ ਕਾਲਮ ਐਗਰੀਗੇਟ ਫੰਕਸ਼ਨਾਂ 'ਤੇ ਜਾਂਦੇ ਹਨ। ਉੱਥੇ ਹੈ, ਜਿਸਨੂੰ ਇੱਕ ਘਣ ਦੇ ਟੁਕੜੇ ਦੇ ਰੂਪ ਵਿੱਚ ਸੋਚਿਆ ਜਾ ਸਕਦਾ ਹੈ. ਦੁਆਰਾ ਪੂਰੇ ਸਮੂਹ ਨੂੰ ਇੱਕ ਪ੍ਰੋਜੈਕਸ਼ਨ ਵਜੋਂ ਸੋਚਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਅਤੇ ਇਸੇ ਕਰਕੇ ਇਸ ਨੂੰ ਮਲਟੀਵੇਰੀਏਟ ਡੇਟਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਿਹਾ ਜਾਂਦਾ ਹੈ।

ਅਤੇ ਅਕਸਰ ਇਹ ਇੱਕ ਤਾਰੇ ਦੇ ਚਿੱਤਰ ਦੇ ਰੂਪ ਵਿੱਚ ਤਿਆਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਦੋਂ ਕਿਰਨਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਪਾਸੇ 'ਤੇ ਇੱਕ ਕੇਂਦਰੀ ਤੱਥ ਅਤੇ ਇਸ ਤੱਥ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ.

ਅਤੇ ਭੌਤਿਕ ਡਿਜ਼ਾਈਨ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਇਹ ਟੇਬਲ 'ਤੇ ਕਿਵੇਂ ਫਿੱਟ ਹੁੰਦਾ ਹੈ, ਉਹ ਆਮ ਤੌਰ' ਤੇ ਇੱਕ ਸਧਾਰਣ ਪ੍ਰਤੀਨਿਧਤਾ ਕਰਦੇ ਹਨ. ਤੁਸੀਂ ਅਸਧਾਰਨ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਇਹ ਡਿਸਕ 'ਤੇ ਮਹਿੰਗਾ ਹੈ ਅਤੇ ਪੁੱਛਗਿੱਛਾਂ 'ਤੇ ਬਹੁਤ ਕੁਸ਼ਲ ਨਹੀਂ ਹੈ। ਇਸ ਲਈ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਧਾਰਣ ਦ੍ਰਿਸ਼ ਬਣਾਉਂਦੇ ਹਨ, ਅਰਥਾਤ ਇੱਕ ਤੱਥ ਸਾਰਣੀ ਅਤੇ ਬਹੁਤ ਸਾਰੇ, ਬਹੁਤ ਸਾਰੇ ਆਯਾਮ ਟੇਬਲ।

ਪਰ ਇਹ ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਦੋ ਕਾਰਨ ਹਨ:

• ਪਹਿਲਾ ਇਹ ਹੈ ਕਿ ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਬਹੁਤ ਵਧੀਆ ਜੁਆਇਨ ਨਹੀਂ ਹੁੰਦੇ ਹਨ, ਯਾਨਿ ਕਿ ਜੁਆਇਨ ਹਨ, ਪਰ ਉਹ ਮਾੜੇ ਹਨ। ਹੁਣ ਤੱਕ ਉਹ ਮਾੜੇ ਹਨ।
• ਦੂਜਾ ਇਹ ਹੈ ਕਿ ਟੇਬਲ ਅੱਪਡੇਟ ਨਹੀਂ ਕੀਤੇ ਗਏ ਹਨ. ਆਮ ਤੌਰ 'ਤੇ ਇਹਨਾਂ ਚਿੰਨ੍ਹਾਂ ਵਿੱਚ ਜੋ ਤਾਰੇ ਦੇ ਚਿੱਤਰ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਹੁੰਦੇ ਹਨ, ਕੁਝ ਬਦਲਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਗਾਹਕ ਦਾ ਨਾਮ, ਕੰਪਨੀ ਦਾ ਨਾਮ, ਆਦਿ। ਅਤੇ ਇਹ ਕੰਮ ਨਹੀਂ ਕਰਦਾ।

ਅਤੇ ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਇਸ ਤੋਂ ਬਾਹਰ ਨਿਕਲਣ ਦਾ ਇੱਕ ਤਰੀਕਾ ਹੈ. ਦੋ ਵੀ:

• ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਸ਼ਬਦਕੋਸ਼ਾਂ ਦੀ ਵਰਤੋਂ ਹੈ। ਐਕਸਟਰਨਲ ਡਿਕਸ਼ਨਰੀਆਂ ਉਹ ਹੈ ਜੋ 99% ਨੂੰ ਅਪਡੇਟਸ ਆਦਿ ਨਾਲ ਸਟਾਰ ਸਕੀਮ ਨਾਲ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
• ਦੂਜਾ ਐਰੇ ਦੀ ਵਰਤੋਂ ਹੈ. ਐਰੇ ਜੋੜਾਂ ਅਤੇ ਸਧਾਰਣਕਰਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣ ਵਿੱਚ ਵੀ ਮਦਦ ਕਰਦੇ ਹਨ।

• ਜੁੜਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ।
• ਅੱਪਡੇਟ ਕਰਨ ਯੋਗ। ਮਾਰਚ 2018 ਤੋਂ, ਸ਼ਬਦਕੋਸ਼ਾਂ ਨੂੰ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਅੱਪਡੇਟ ਕਰਨ ਲਈ ਇੱਕ ਗੈਰ-ਦਸਤਾਵੇਜ਼ੀ ਮੌਕਾ ਪ੍ਰਗਟ ਹੋਇਆ ਹੈ (ਤੁਹਾਨੂੰ ਇਹ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਨਹੀਂ ਮਿਲੇਗਾ), ਅਰਥਾਤ ਉਹ ਐਂਟਰੀਆਂ ਜੋ ਬਦਲ ਗਈਆਂ ਹਨ। ਅਭਿਆਸ ਵਿੱਚ, ਇਹ ਇੱਕ ਮੇਜ਼ ਵਰਗਾ ਹੈ.
• ਹਮੇਸ਼ਾਂ ਮੈਮੋਰੀ ਵਿੱਚ, ਇਸਲਈ ਡਿਕਸ਼ਨਰੀ ਦੇ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ ਜੇਕਰ ਇਹ ਇੱਕ ਸਾਰਣੀ ਹੁੰਦੀ ਜੋ ਡਿਸਕ 'ਤੇ ਪਈ ਹੁੰਦੀ ਹੈ ਅਤੇ ਇਹ ਇੱਕ ਤੱਥ ਨਹੀਂ ਹੈ ਕਿ ਇਹ ਕੈਸ਼ ਵਿੱਚ ਹੈ, ਜ਼ਿਆਦਾਤਰ ਨਹੀਂ।

• ਤੁਹਾਨੂੰ ਸ਼ਾਮਲ ਹੋਣ ਦੀ ਵੀ ਲੋੜ ਨਹੀਂ ਹੈ।
• ਇਹ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰਤੀਨਿਧਤਾ ਲਈ ਇੱਕ ਸੰਖੇਪ 1 ਹੈ.
• ਅਤੇ ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਐਰੇ ਗੀਕਸ ਲਈ ਬਣਾਏ ਗਏ ਹਨ. ਇਹ ਲਾਂਬਡਾ ਫੰਕਸ਼ਨ ਅਤੇ ਚੀਜ਼ਾਂ ਹਨ।

ਇਹ ਸ਼ਬਦਾਂ ਦੀ ਖ਼ਾਤਰ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਬਹੁਤ ਸ਼ਕਤੀਸ਼ਾਲੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਬਹੁਤ ਹੀ ਅਸਾਨ ਅਤੇ ਸ਼ਾਨਦਾਰ ਢੰਗ ਨਾਲ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ।

ਖਾਸ ਉਦਾਹਰਣਾਂ ਜੋ ਐਰੇ ਨੂੰ ਹੱਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ। ਇਹ ਉਦਾਹਰਣਾਂ ਸਧਾਰਨ ਅਤੇ ਬਿਲਕੁਲ ਸਪੱਸ਼ਟ ਹਨ:

• ਟੈਗਾਂ ਦੁਆਰਾ ਖੋਜ ਕਰੋ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਹੈਸ਼ਟੈਗ ਹਨ ਅਤੇ ਹੈਸ਼ਟੈਗ ਦੁਆਰਾ ਕੁਝ ਪੋਸਟਾਂ ਨੂੰ ਲੱਭਣਾ ਚਾਹੁੰਦੇ ਹੋ.
• ਕੁੰਜੀ-ਮੁੱਲ ਜੋੜਿਆਂ ਦੁਆਰਾ ਖੋਜੋ। ਅਰਥ ਦੇ ਨਾਲ ਕੁਝ ਗੁਣ ਵੀ ਹਨ।
• ਉਹਨਾਂ ਕੁੰਜੀਆਂ ਦੀਆਂ ਸੂਚੀਆਂ ਨੂੰ ਸਟੋਰ ਕਰਨਾ ਜੋ ਤੁਹਾਨੂੰ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਇਹ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਐਰੇ ਤੋਂ ਬਿਨਾਂ ਹੱਲ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਟੈਗਸ ਨੂੰ ਕੁਝ ਲਾਈਨਾਂ ਵਿੱਚ ਰੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਇੱਕ ਨਿਯਮਤ ਸਮੀਕਰਨ, ਜਾਂ ਇੱਕ ਵੱਖਰੀ ਸਾਰਣੀ ਵਿੱਚ ਚੁਣਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਫਿਰ ਤੁਹਾਨੂੰ ਜੋੜਨਾ ਪਵੇਗਾ।

ਪਰ ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਤੁਹਾਨੂੰ ਕੁਝ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਸਿਰਫ਼ ਹੈਸ਼ਟੈਗਾਂ ਲਈ ਇੱਕ ਸਟ੍ਰਿੰਗ ਐਰੇ ਦਾ ਵਰਣਨ ਕਰੋ ਜਾਂ ਕੀ-ਵੈਲਯੂ ਸਿਸਟਮਾਂ ਲਈ ਇੱਕ ਨੇਸਟਡ ਢਾਂਚਾ ਬਣਾਓ।

ਇੱਕ ਨੇਸਟਡ ਢਾਂਚਾ ਸਭ ਤੋਂ ਵਧੀਆ ਨਾਮ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਇਹ ਦੋ ਐਰੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਨਾਮ ਅਤੇ ਕੁਝ ਸੰਬੰਧਿਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਇੱਕ ਸਾਂਝਾ ਹਿੱਸਾ ਹੈ।

ਅਤੇ ਟੈਗ ਦੁਆਰਾ ਖੋਜ ਕਰਨਾ ਬਹੁਤ ਆਸਾਨ ਹੈ। ਇੱਕ ਫੰਕਸ਼ਨ ਹੈ has, ਜੋ ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਐਰੇ ਵਿੱਚ ਇੱਕ ਤੱਤ ਹੈ। ਹਰ ਕੋਈ, ਸਾਨੂੰ ਸਾਡੀ ਕਾਨਫਰੰਸ ਨਾਲ ਸਬੰਧਤ ਸਾਰੀਆਂ ਐਂਟਰੀਆਂ ਮਿਲੀਆਂ।

ਸਬਡ ਦੁਆਰਾ ਖੋਜ ਕਰਨਾ ਥੋੜਾ ਹੋਰ ਗੁੰਝਲਦਾਰ ਹੈ. ਸਾਨੂੰ ਪਹਿਲਾਂ ਕੁੰਜੀ ਦਾ ਸੂਚਕਾਂਕ ਲੱਭਣ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਫਿਰ ਇਸ ਸੂਚਕਾਂਕ ਦੇ ਨਾਲ ਤੱਤ ਲਓ ਅਤੇ ਜਾਂਚ ਕਰੋ ਕਿ ਇਹ ਮੁੱਲ ਉਹੀ ਹੈ ਜੋ ਸਾਨੂੰ ਚਾਹੀਦਾ ਹੈ। ਪਰ ਫਿਰ ਵੀ ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਅਤੇ ਸੰਖੇਪ.

ਨਿਯਮਤ ਸਮੀਕਰਨ ਜੋ ਤੁਸੀਂ ਲਿਖਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਜੇਕਰ ਤੁਸੀਂ ਇਹ ਸਭ ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਸਟੋਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਬੇਢੰਗੀ ਹੋਵੇਗੀ। ਅਤੇ, ਦੂਜਾ, ਇਸਨੇ ਦੋ ਐਰੇ ਨਾਲੋਂ ਬਹੁਤ ਲੰਬਾ ਕੰਮ ਕੀਤਾ।

ਇੱਕ ਹੋਰ ਉਦਾਹਰਨ. ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਐਰੇ ਹੈ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਆਈਡੀ ਸਟੋਰ ਕਰਦੇ ਹੋ। ਅਤੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਨਾਮਾਂ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰ ਸਕਦੇ ਹੋ। ਫੰਕਸ਼ਨ arrayMap. ਇਹ ਇੱਕ ਆਮ ਲਾਂਬਡਾ ਫੰਕਸ਼ਨ ਹੈ। ਤੁਸੀਂ ਉੱਥੇ ਲਾਂਬਡਾ ਸਮੀਕਰਨ ਪਾਸ ਕਰਦੇ ਹੋ। ਅਤੇ ਉਹ ਸ਼ਬਦਕੋਸ਼ ਵਿੱਚੋਂ ਹਰੇਕ ID ਲਈ ਨਾਮ ਮੁੱਲ ਕੱਢਦੀ ਹੈ।

ਤੁਸੀਂ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਖੋਜ ਕਰ ਸਕਦੇ ਹੋ. ਇੱਕ ਪੂਰਵ-ਅਨੁਮਾਨ ਫੰਕਸ਼ਨ ਪਾਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਤੱਤ ਕੀ ਮੇਲ ਖਾਂਦੇ ਹਨ।

ਇਹ ਚੀਜ਼ਾਂ ਸਰਕਟ ਨੂੰ ਬਹੁਤ ਸਰਲ ਬਣਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਸਮੱਸਿਆਵਾਂ ਦੇ ਝੁੰਡ ਨੂੰ ਹੱਲ ਕਰਦੀਆਂ ਹਨ।

ਪਰ ਅਗਲੀ ਸਮੱਸਿਆ ਜਿਸ ਦਾ ਅਸੀਂ ਸਾਹਮਣਾ ਕੀਤਾ ਅਤੇ ਜਿਸਦਾ ਮੈਂ ਜ਼ਿਕਰ ਕਰਨਾ ਚਾਹਾਂਗਾ ਉਹ ਹੈ ਕੁਸ਼ਲ ਸਵਾਲ।

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

ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਸਧਾਰਨ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਕਈ ਵਾਰ ਤੁਹਾਨੂੰ ਸ਼ਡਿਊਲਰ ਦਾ ਕੰਮ ਵੀ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਅਤੇ ਸਵਾਲਾਂ ਨੂੰ ਥੋੜਾ ਜਿਹਾ ਦੁਬਾਰਾ ਲਿਖਣਾ ਪੈਂਦਾ ਹੈ।

ਇੱਥੇ ਇੱਕ ਉਦਾਹਰਨ ਹੈ. ਖੱਬੇ ਪਾਸੇ ਇੱਕ ਸਵਾਲ ਹੈ ਜੋ ਚੋਟੀ ਦੇ 5 ਦੇਸ਼ਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਅਤੇ ਇਹ 2,5 ਸਕਿੰਟਾਂ ਵਿੱਚ ਚੱਲਦਾ ਹੈ, ਮੈਨੂੰ ਲਗਦਾ ਹੈ. ਅਤੇ ਸੱਜੇ ਪਾਸੇ ਉਹੀ ਬੇਨਤੀ ਹੈ, ਪਰ ਥੋੜ੍ਹਾ ਜਿਹਾ ਦੁਬਾਰਾ ਲਿਖਿਆ ਗਿਆ ਹੈ. ਸਟ੍ਰਿੰਗ ਦੁਆਰਾ ਗਰੁੱਪਿੰਗ ਕਰਨ ਦੀ ਬਜਾਏ, ਅਸੀਂ ਕੁੰਜੀ (ਇੰਟ) ਦੁਆਰਾ ਗਰੁੱਪਿੰਗ ਸ਼ੁਰੂ ਕੀਤੀ. ਅਤੇ ਇਹ ਤੇਜ਼ ਹੈ। ਅਤੇ ਫਿਰ ਅਸੀਂ ਨਤੀਜੇ ਨਾਲ ਇੱਕ ਸ਼ਬਦਕੋਸ਼ ਜੋੜਿਆ. 2,5 ਸਕਿੰਟਾਂ ਦੀ ਬਜਾਏ, ਬੇਨਤੀ ਵਿੱਚ 1,5 ਸਕਿੰਟ ਲੱਗਦੇ ਹਨ। ਇਹ ਚਗਾ ਹੈ.

ਰੀਰਾਈਟਿੰਗ ਫਿਲਟਰਾਂ ਦੇ ਨਾਲ ਇੱਕ ਸਮਾਨ ਉਦਾਹਰਨ. ਇੱਥੇ ਰੂਸ ਲਈ ਇੱਕ ਬੇਨਤੀ ਹੈ. ਇਹ 5 ਸਕਿੰਟ ਲਈ ਚੱਲਦਾ ਹੈ. ਜੇ ਅਸੀਂ ਇਸਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਦੁਬਾਰਾ ਲਿਖਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਦੁਬਾਰਾ ਕਿਸੇ ਸਤਰ ਦੀ ਨਹੀਂ, ਪਰ ਉਹਨਾਂ ਕੁੰਜੀਆਂ ਦੇ ਕੁਝ ਸਮੂਹਾਂ ਨਾਲ ਸੰਖਿਆਵਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹਾਂ ਜੋ ਰੂਸ ਨਾਲ ਸਬੰਧਤ ਹਨ, ਤਾਂ ਇਹ ਬਹੁਤ ਤੇਜ਼ ਹੋਵੇਗਾ.

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

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

ਹੋਰ ਤਕਨੀਕਾਂ ਹਨ, ਨਾ ਕਿ ਸਿਰਫ਼ ਉਹ ਜੋ ਮੈਂ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤੀਆਂ ਹਨ। ਅਤੇ ਉਹ ਸਾਰੇ ਕਈ ਵਾਰ ਤੁਹਾਨੂੰ ਸਵਾਲਾਂ ਦੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ.

ਚਲੋ ਅਗਲੀ ਉਦਾਹਰਣ ਵੱਲ ਵਧੀਏ। ਅਮਰੀਕਾ ਤੋਂ ਕੰਪਨੀ ਐਕਸ. ਉਹ ਕੀ ਕਰ ਰਹੀ ਹੈ?

ਇੱਕ ਕੰਮ ਸੀ:

• ਵਿਗਿਆਪਨ ਲੈਣ-ਦੇਣ ਦੀ ਔਫਲਾਈਨ ਲਿੰਕਿੰਗ।
• ਵੱਖ-ਵੱਖ ਬਾਈਡਿੰਗ ਮਾਡਲਾਂ ਦਾ ਸਿਮੂਲੇਸ਼ਨ।

ਦ੍ਰਿਸ਼ ਕੀ ਹੈ?

ਇੱਕ ਆਮ ਵਿਜ਼ਟਰ ਸਾਈਟ 'ਤੇ ਜਾਂਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਵੱਖ-ਵੱਖ ਇਸ਼ਤਿਹਾਰਾਂ ਤੋਂ ਮਹੀਨੇ ਵਿੱਚ 20 ਵਾਰ, ਜਾਂ ਕਈ ਵਾਰ ਉਹ ਬਿਨਾਂ ਕਿਸੇ ਇਸ਼ਤਿਹਾਰ ਦੇ ਆਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਉਸਨੂੰ ਇਹ ਸਾਈਟ ਯਾਦ ਹੈ। ਕੁਝ ਉਤਪਾਦਾਂ ਨੂੰ ਵੇਖਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਟੋਕਰੀ ਵਿੱਚ ਰੱਖਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਟੋਕਰੀ ਵਿੱਚੋਂ ਬਾਹਰ ਕੱਢਦਾ ਹੈ. ਅਤੇ, ਅੰਤ ਵਿੱਚ, ਉਹ ਕੁਝ ਖਰੀਦਦਾ ਹੈ.

ਵਾਜਬ ਸਵਾਲ: "ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਇਸ਼ਤਿਹਾਰਬਾਜ਼ੀ ਲਈ ਕਿਸ ਨੂੰ ਭੁਗਤਾਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?" ਅਤੇ "ਕਿਹੜੀ ਇਸ਼ਤਿਹਾਰਬਾਜ਼ੀ, ਜੇ ਕੋਈ ਹੈ, ਨੇ ਉਸਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ?" ਭਾਵ, ਉਸਨੇ ਕਿਉਂ ਖਰੀਦਿਆ ਅਤੇ ਇਹ ਕਿਵੇਂ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾਵੇ ਕਿ ਇਸ ਵਿਅਕਤੀ ਦੇ ਸਮਾਨ ਲੋਕ ਵੀ ਖਰੀਦਦੇ ਹਨ?

ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਵੈਬਸਾਈਟ 'ਤੇ ਹੋਣ ਵਾਲੀਆਂ ਘਟਨਾਵਾਂ ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਜੋੜਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਯਾਨੀ ਕਿ ਕਿਸੇ ਤਰ੍ਹਾਂ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ ਇੱਕ ਕਨੈਕਸ਼ਨ ਬਣਾਓ। ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ DWH ਵਿੱਚ ਤਬਦੀਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਇਸ ਵਿਸ਼ਲੇਸ਼ਣ ਦੇ ਆਧਾਰ 'ਤੇ, ਇਸ ਗੱਲ ਦੇ ਮਾਡਲ ਬਣਾਓ ਕਿ ਕਿਸ ਨੂੰ ਵਿਗਿਆਪਨ ਦਿਖਾਉਣਾ ਹੈ।

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

ਬਹੁਤ ਸਾਰੇ ਬਾਈਡਿੰਗ ਮਾਡਲ ਹਨ.

ਸਭ ਤੋਂ ਵੱਧ ਪ੍ਰਸਿੱਧ ਹਨ:

• ਆਖਰੀ ਪਰਸਪਰ ਪ੍ਰਭਾਵ, ਜਿੱਥੇ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਜਾਂ ਤਾਂ ਇੱਕ ਕਲਿੱਕ ਜਾਂ ਪ੍ਰਭਾਵ ਹੁੰਦਾ ਹੈ।
• ਪਹਿਲੀ ਇੰਟਰਐਕਸ਼ਨ, ਭਾਵ ਪਹਿਲੀ ਚੀਜ਼ ਜੋ ਕਿਸੇ ਵਿਅਕਤੀ ਨੂੰ ਸਾਈਟ 'ਤੇ ਲਿਆਉਂਦੀ ਹੈ।
• ਰੇਖਿਕ ਸੁਮੇਲ - ਹਰੇਕ ਲਈ ਬਰਾਬਰ ਸ਼ੇਅਰ।
• ਧਿਆਨ.
• ਇਤਆਦਿ.

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

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

ਅਤੇ ਇਹ ਸਭ ਬਹੁਤ ਵਧੀਆ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦਾ ਸੀ ਜਦੋਂ ਤੱਕ ਲਿੰਕਿੰਗ ਆਖਰੀ ਕਲਿਕ ਤੱਕ ਨਹੀਂ ਸੀ. ਕਿਉਂਕਿ ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਮਹੀਨੇ ਲਈ ਇੱਕ ਵਿੰਡੋ ਸੈਟ ਕਰਦੇ ਹੋ, ਤਾਂ 10 ਮਿਲੀਅਨ ਕਲਿੱਕ ਪ੍ਰਤੀ ਦਿਨ, 300 ਮਿਲੀਅਨ ਪ੍ਰਤੀ ਮਹੀਨਾ ਹੁੰਦੇ ਹਨ। ਅਤੇ ਕਿਉਂਕਿ ਕੈਸੈਂਡਰਾ ਵਿੱਚ ਇਹ ਸਭ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਮੈਮੋਰੀ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਰਨਟਾਈਮ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇਣ ਲਈ ਲੋੜੀਂਦਾ ਹੈ, ਲਗਭਗ 10-15 ਸਰਵਰਾਂ ਦੀ ਲੋੜ ਸੀ।

ਅਤੇ ਜਦੋਂ ਉਹ ਕਿਸੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਨੂੰ ਡਿਸਪਲੇ ਨਾਲ ਜੋੜਨਾ ਚਾਹੁੰਦੇ ਸਨ, ਤਾਂ ਇਹ ਤੁਰੰਤ ਇੰਨਾ ਮਜ਼ੇਦਾਰ ਨਹੀਂ ਨਿਕਲਿਆ. ਅਤੇ ਕਿਉਂ? ਇਹ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ 30 ਗੁਣਾ ਹੋਰ ਘਟਨਾਵਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ. ਅਤੇ, ਇਸਦੇ ਅਨੁਸਾਰ, ਤੁਹਾਨੂੰ 30 ਗੁਣਾ ਹੋਰ ਸਰਵਰਾਂ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਅਤੇ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਇਹ ਕਿਸੇ ਕਿਸਮ ਦਾ ਖਗੋਲ-ਵਿਗਿਆਨਕ ਚਿੱਤਰ ਹੈ. ਰਨਟਾਈਮ ਵਿੱਚ ਕਾਫ਼ੀ ਘੱਟ ਸਰਵਰ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਲਿੰਕਿੰਗ ਕਰਨ ਲਈ 500 ਸਰਵਰਾਂ ਤੱਕ ਰੱਖਣਾ, ਇੱਕ ਕਿਸਮ ਦਾ ਗਲਤ ਅੰਕੜਾ ਹੈ। ਅਤੇ ਉਹ ਸੋਚਣ ਲੱਗੇ ਕਿ ਕੀ ਕੀਤਾ ਜਾਵੇ।

ਅਤੇ ਅਸੀਂ ਕਲਿਕ ਹਾਊਸ ਗਏ। ਕਲਿਕਹਾਊਸ 'ਤੇ ਇਹ ਕਿਵੇਂ ਕਰਨਾ ਹੈ? ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ, ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਇਹ ਐਂਟੀਪੈਟਰਨਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ.

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

ਭਾਵ, ਐਂਟੀਪੈਟਰਨਾਂ ਦਾ ਇੱਕ ਸਮੂਹ.

ਪਰ ਫਿਰ ਵੀ, ਅਸੀਂ ਇੱਕ ਅਜਿਹਾ ਸਿਸਟਮ ਬਣਾਉਣ ਵਿੱਚ ਕਾਮਯਾਬ ਰਹੇ ਜੋ ਬਹੁਤ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ।

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

ਇਹ ਇਸ ਰੂਪ ਵਿੱਚ ਬਹੁਤ ਵਧੀਆ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਸੀ। ਅਤੇ ਕਲਿਕਹਾਊਸ ਲਈ ਇਸਨੂੰ ਆਸਾਨ ਬਣਾਉਣ ਲਈ, ਜਦੋਂ ਇੱਕ ਵਿਜ਼ਿਟ ਆਈਡੀ ਲਈ ਬੇਨਤੀ ਕੀਤੀ ਗਈ ਸੀ, ਤਾਂ ਉਹਨਾਂ ਨੇ ਇਹਨਾਂ ਬੇਨਤੀਆਂ ਨੂੰ 1-000 ਵਿਜ਼ਿਟ ਆਈਡੀ ਦੇ ਬਲਾਕਾਂ ਵਿੱਚ ਗਰੁੱਪ ਕੀਤਾ ਅਤੇ 2-000 ਲੋਕਾਂ ਲਈ ਸਾਰੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਬਾਹਰ ਕੱਢਿਆ। ਅਤੇ ਫਿਰ ਇਹ ਸਭ ਕੰਮ ਕੀਤਾ.

ਜੇਕਰ ਤੁਸੀਂ ਕਲਿਕਹਾਊਸ ਦੇ ਅੰਦਰ ਵੇਖਦੇ ਹੋ, ਤਾਂ ਇੱਥੇ ਸਿਰਫ 3 ਮੁੱਖ ਟੇਬਲ ਹਨ ਜੋ ਇਹ ਸਭ ਵਰਤਦੇ ਹਨ।

ਪਹਿਲੀ ਸਾਰਣੀ ਜਿਸ ਵਿੱਚ ਲੌਗ ਅੱਪਲੋਡ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਲੌਗ ਅਸਲ ਵਿੱਚ ਬਿਨਾਂ ਕਿਸੇ ਪ੍ਰਕਿਰਿਆ ਦੇ ਅੱਪਲੋਡ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

ਦੂਜੀ ਸਾਰਣੀ. ਭੌਤਿਕ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਦੁਆਰਾ, ਘਟਨਾਵਾਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਜੇ ਤੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ ਦਿੱਤੀ ਗਈ ਹੈ, ਅਰਥਾਤ, ਗੈਰ-ਸੰਬੰਧਿਤ, ਇਹਨਾਂ ਲੌਗਸ ਤੋਂ ਕੱਢੇ ਗਏ ਸਨ। ਅਤੇ ਭੌਤਿਕ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਦੁਆਰਾ, ਇੱਕ ਸਨੈਪਸ਼ਾਟ ਬਣਾਉਣ ਲਈ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਇਹਨਾਂ ਲੌਗਸ ਵਿੱਚੋਂ ਬਾਹਰ ਕੱਢਿਆ ਗਿਆ ਸੀ. ਭਾਵ, ਇੱਕ ਸਨੈਪਸ਼ਾਟ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਪਦਾਰਥਕ ਦ੍ਰਿਸ਼ ਨਾਲ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਅਰਥਾਤ ਲੈਣ-ਦੇਣ ਦੀ ਆਖਰੀ ਸੰਚਿਤ ਸਥਿਤੀ।

ਇੱਥੇ ਟੈਕਸਟ SQL ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ. ਮੈਂ ਇਸ ਵਿੱਚ ਕਈ ਮਹੱਤਵਪੂਰਨ ਗੱਲਾਂ ਉੱਤੇ ਟਿੱਪਣੀ ਕਰਨਾ ਚਾਹਾਂਗਾ।

ਪਹਿਲੀ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਕਲਿਕਹਾਊਸ ਵਿੱਚ json ਤੋਂ ਕਾਲਮ ਅਤੇ ਖੇਤਰਾਂ ਨੂੰ ਐਕਸਟਰੈਕਟ ਕਰਨ ਦੀ ਯੋਗਤਾ ਹੈ। ਭਾਵ, ਕਲਿਕਹਾਊਸ ਕੋਲ json ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਕੁਝ ਤਰੀਕੇ ਹਨ। ਉਹ ਬਹੁਤ, ਬਹੁਤ ਹੀ ਮੁੱਢਲੇ ਹਨ.

visitParamExtractInt ਤੁਹਾਨੂੰ json ਤੋਂ ਗੁਣਾਂ ਨੂੰ ਐਕਸਟਰੈਕਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਭਾਵ ਪਹਿਲੀ ਹਿੱਟ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਆਈਡੀ ਜਾਂ ਵਿਜ਼ਿਟ ਆਈਡੀ ਨੂੰ ਬਾਹਰ ਕੱਢ ਸਕਦੇ ਹੋ। ਇਸ ਸਮੇਂ.

ਦੂਜਾ, ਇੱਥੇ ਇੱਕ ਛਲ ਪਦਾਰਥਕ ਖੇਤਰ ਵਰਤਿਆ ਗਿਆ ਹੈ। ਇਸਦਾ ਮਤਲੱਬ ਕੀ ਹੈ? ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਸਾਰਣੀ ਵਿੱਚ ਨਹੀਂ ਪਾ ਸਕਦੇ ਹੋ, ਭਾਵ ਇਹ ਸੰਮਿਲਿਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ, ਇਸਨੂੰ ਸੰਮਿਲਿਤ ਕਰਨ 'ਤੇ ਗਣਨਾ ਅਤੇ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਸੰਮਿਲਿਤ ਕਰਦੇ ਹੋ, ਕਲਿਕਹਾਊਸ ਤੁਹਾਡੇ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ। ਅਤੇ ਜੋ ਤੁਹਾਨੂੰ ਬਾਅਦ ਵਿੱਚ ਲੋੜ ਪਵੇਗੀ ਉਹ json ਤੋਂ ਬਾਹਰ ਕੱਢਿਆ ਗਿਆ ਹੈ.

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

ਦੂਜੀ ਮਹੱਤਵਪੂਰਨ ਚੀਜ਼ ਹੈ index_granularity. ਜੇਕਰ ਤੁਸੀਂ MergeTree ਦੇਖਿਆ ਹੈ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਡਿਫਾਲਟ ਮੁੱਲ 8 index_granularity ਹੁੰਦਾ ਹੈ। ਇਹ ਕੀ ਹੈ? ਇਹ ਸੂਚਕਾਂਕ ਸਪਾਰਸਿਟੀ ਪੈਰਾਮੀਟਰ ਹੈ। ਕਲਿਕਹਾਊਸ ਵਿੱਚ, ਸੂਚਕਾਂਕ ਸਪਾਰਸ ਹੈ; ਇਹ ਕਦੇ ਵੀ ਹਰ ਰਿਕਾਰਡ ਨੂੰ ਸੂਚੀਬੱਧ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਇਹ ਹਰ 192 ਵਿੱਚ ਅਜਿਹਾ ਕਰਦਾ ਹੈ। ਅਤੇ ਇਹ ਉਦੋਂ ਚੰਗਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਬਹੁਤ ਸਾਰੇ ਡੇਟਾ ਦੀ ਗਣਨਾ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਪਰ ਜਦੋਂ ਤੁਹਾਨੂੰ ਥੋੜਾ ਜਿਹਾ ਹਿਸਾਬ ਲਗਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਤਾਂ ਇਹ ਬੁਰਾ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰਾ ਓਵਰਹੈੱਡ ਹੁੰਦਾ ਹੈ। ਅਤੇ ਜੇਕਰ ਅਸੀਂ ਇੰਡੈਕਸ ਗ੍ਰੈਨਿਊਲਿਟੀ ਨੂੰ ਘਟਾਉਂਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਓਵਰਹੈੱਡ ਨੂੰ ਘਟਾਉਂਦੇ ਹਾਂ. ਤੁਸੀਂ ਇਸਨੂੰ ਘਟਾ ਕੇ ਇੱਕ ਤੱਕ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਕਿਉਂਕਿ ਇੱਥੇ ਲੋੜੀਂਦੀ ਮੈਮੋਰੀ ਨਹੀਂ ਹੋ ਸਕਦੀ ਹੈ। ਸੂਚਕਾਂਕ ਨੂੰ ਹਮੇਸ਼ਾ ਮੈਮੋਰੀ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਅਤੇ ਸਨੈਪਸ਼ਾਟ ਕੁਝ ਹੋਰ ਦਿਲਚਸਪ ਕਲਿਕਹਾਊਸ ਫੰਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

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

• ਬਾਈਡਿੰਗ ਰਨਟਾਈਮ ਤੋਂ "ਅਨਟੀਥਰਡ" ਹੈ।
• ਪ੍ਰਤੀ ਮਹੀਨਾ 3 ਬਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਸਟੋਰ ਅਤੇ ਪ੍ਰੋਸੈਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਕੈਸੈਂਡਰਾ ਨਾਲੋਂ ਵੱਧ ਤੀਬਰਤਾ ਦਾ ਇੱਕ ਕ੍ਰਮ ਹੈ, ਭਾਵ, ਇੱਕ ਆਮ ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਸਿਸਟਮ ਵਿੱਚ।
• 2x5 ਕਲਿਕਹਾਊਸ ਸਰਵਰਾਂ ਦਾ ਕਲੱਸਟਰ। 5 ਸਰਵਰ ਅਤੇ ਹਰੇਕ ਸਰਵਰ ਦੀ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਹੈ। ਕਲਿਕ ਅਧਾਰਤ ਵਿਸ਼ੇਸ਼ਤਾ ਕਰਨ ਲਈ ਇਹ ਕੈਸੈਂਡਰਾ ਨਾਲੋਂ ਵੀ ਘੱਟ ਹੈ, ਪਰ ਇੱਥੇ ਸਾਡੇ ਕੋਲ ਪ੍ਰਭਾਵ ਅਧਾਰਤ ਹੈ। ਯਾਨੀ ਸਰਵਰਾਂ ਦੀ ਗਿਣਤੀ 30 ਗੁਣਾ ਵਧਾਉਣ ਦੀ ਬਜਾਏ ਘਟਾ ਦਿੱਤੀ ਗਈ।

ਅਤੇ ਆਖਰੀ ਉਦਾਹਰਣ ਵਿੱਤੀ ਕੰਪਨੀ Y ਹੈ, ਜਿਸ ਨੇ ਸਟਾਕ ਦੀਆਂ ਕੀਮਤਾਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦੇ ਸਬੰਧਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ।

ਅਤੇ ਕੰਮ ਇਹ ਸੀ:

• ਲਗਭਗ 5 ਸ਼ੇਅਰ ਹਨ।
• ਹਰ 100 ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ ਹਵਾਲੇ ਜਾਣੇ ਜਾਂਦੇ ਹਨ।
• ਡੇਟਾ 10 ਸਾਲਾਂ ਤੋਂ ਵੱਧ ਇਕੱਠਾ ਹੋਇਆ ਹੈ। ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਕੁਝ ਕੰਪਨੀਆਂ ਲਈ ਇਹ ਜ਼ਿਆਦਾ ਹੈ, ਕੁਝ ਲਈ ਇਹ ਘੱਟ ਹੈ.
• ਕੁੱਲ ਮਿਲਾ ਕੇ ਲਗਭਗ 100 ਬਿਲੀਅਨ ਕਤਾਰਾਂ ਹਨ।

ਅਤੇ ਤਬਦੀਲੀਆਂ ਦੇ ਸਬੰਧਾਂ ਦੀ ਗਣਨਾ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ.

ਇੱਥੇ ਦੋ ਸਟਾਕ ਅਤੇ ਉਹਨਾਂ ਦੇ ਹਵਾਲੇ ਹਨ. ਜੇਕਰ ਇੱਕ ਉੱਪਰ ਜਾਂਦਾ ਹੈ ਅਤੇ ਦੂਜਾ ਉੱਪਰ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਸਕਾਰਾਤਮਕ ਸਬੰਧ ਹੈ, ਅਰਥਾਤ ਇੱਕ ਉੱਪਰ ਜਾਂਦਾ ਹੈ ਅਤੇ ਦੂਜਾ ਉੱਪਰ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ ਇੱਕ ਉੱਪਰ ਜਾਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਗ੍ਰਾਫ਼ ਦੇ ਅੰਤ ਵਿੱਚ, ਅਤੇ ਦੂਜਾ ਹੇਠਾਂ ਚਲਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਨਕਾਰਾਤਮਕ ਸਬੰਧ ਹੈ, ਭਾਵ ਜਦੋਂ ਇੱਕ ਉੱਪਰ ਜਾਂਦਾ ਹੈ, ਦੂਜਾ ਹੇਠਾਂ ਜਾਂਦਾ ਹੈ।

ਇਹਨਾਂ ਆਪਸੀ ਤਬਦੀਲੀਆਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਕੇ, ਕੋਈ ਵੀ ਵਿੱਤੀ ਬਜ਼ਾਰ ਵਿੱਚ ਭਵਿੱਖਬਾਣੀ ਕਰ ਸਕਦਾ ਹੈ।

ਪਰ ਕੰਮ ਔਖਾ ਹੈ। ਇਸ ਲਈ ਕੀ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ? ਸਾਡੇ ਕੋਲ 100 ਬਿਲੀਅਨ ਰਿਕਾਰਡ ਹਨ ਜਿਸ ਵਿੱਚ ਇਹ ਸ਼ਾਮਲ ਹਨ: ਸਮਾਂ, ਸਟਾਕ ਅਤੇ ਕੀਮਤ। ਸਾਨੂੰ ਪਹਿਲਾਂ ਕੀਮਤ ਐਲਗੋਰਿਦਮ ਤੋਂ 100 ਬਿਲੀਅਨ ਗੁਣਾ ਚੱਲ ਰਹੇ ਅੰਤਰ ਦੀ ਗਣਨਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। RunningDifference ClickHouse ਵਿੱਚ ਇੱਕ ਫੰਕਸ਼ਨ ਹੈ ਜੋ ਕ੍ਰਮਵਾਰ ਦੋ ਲਾਈਨਾਂ ਵਿੱਚ ਅੰਤਰ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ।

ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਸਾਨੂੰ ਸਬੰਧਾਂ ਦੀ ਗਣਨਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਹਰੇਕ ਜੋੜੇ ਲਈ ਸਬੰਧ ਦੀ ਗਣਨਾ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। 5 ਸ਼ੇਅਰਾਂ ਲਈ, ਜੋੜੇ 000 ਮਿਲੀਅਨ ਹਨ। ਅਤੇ ਇਹ ਬਹੁਤ ਹੈ, ਅਰਥਾਤ 12,5 ਵਾਰ ਤੁਹਾਨੂੰ ਇਸ ਸਬੰਧ ਫੰਕਸ਼ਨ ਦੀ ਗਣਨਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਅਤੇ ਜੇਕਰ ਕੋਈ ਭੁੱਲ ਗਿਆ ਹੈ, ͞x ਅਤੇ ͞y ਚੈੱਕਮੇਟ ਹਨ। ਨਮੂਨਾ ਉਮੀਦ. ਭਾਵ, ਤੁਹਾਨੂੰ ਨਾ ਸਿਰਫ਼ ਮੂਲ ਅਤੇ ਜੋੜਾਂ ਦੀ ਗਣਨਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਸਗੋਂ ਇਹਨਾਂ ਰਕਮਾਂ ਦੇ ਅੰਦਰ ਹੋਰ ਜੋੜਾਂ ਦੀ ਵੀ ਲੋੜ ਹੈ। ਬਹੁਤ ਸਾਰੀਆਂ ਗਣਨਾਵਾਂ ਨੂੰ 12,5 ਮਿਲੀਅਨ ਵਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਘੰਟੇ ਦੁਆਰਾ ਸਮੂਹਿਤ ਕਰਨ ਦੀ ਵੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਅਤੇ ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਘੰਟੇ ਹਨ. ਅਤੇ ਤੁਹਾਨੂੰ ਇਸਨੂੰ 60 ਸਕਿੰਟਾਂ ਵਿੱਚ ਕਰਨਾ ਪਵੇਗਾ। ਇਹ ਇੱਕ ਮਜ਼ਾਕ ਹੈ।

ਸਾਨੂੰ ਇਸਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਬਣਾਉਣਾ ਪਿਆ, ਕਿਉਂਕਿ ਕਲਿਕਹਾਊਸ ਦੇ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਸਭ ਬਹੁਤ ਹੌਲੀ ਹੌਲੀ ਕੰਮ ਕਰਦਾ ਸੀ।

ਉਨ੍ਹਾਂ ਨੇ ਹਡੂਪ 'ਤੇ, ਸਪਾਰਕ 'ਤੇ, ਗ੍ਰੀਨਪਲਮ 'ਤੇ ਇਸ ਦੀ ਗਣਨਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ। ਅਤੇ ਇਹ ਸਭ ਬਹੁਤ ਹੌਲੀ ਜਾਂ ਮਹਿੰਗਾ ਸੀ. ਭਾਵ, ਕਿਸੇ ਤਰ੍ਹਾਂ ਇਸਦੀ ਗਣਨਾ ਕਰਨਾ ਸੰਭਵ ਸੀ, ਪਰ ਫਿਰ ਇਹ ਮਹਿੰਗਾ ਸੀ.

ਅਤੇ ਫਿਰ ਕਲਿਕਹਾਊਸ ਆਇਆ ਅਤੇ ਸਭ ਕੁਝ ਬਿਹਤਰ ਹੋ ਗਿਆ।

ਮੈਂ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਣਾ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਸਾਡੇ ਕੋਲ ਡਾਟਾ ਸਥਾਨਿਕਤਾ ਨਾਲ ਇੱਕ ਸਮੱਸਿਆ ਹੈ, ਇਸਲਈ ਸਬੰਧਾਂ ਨੂੰ ਸਥਾਨਕ ਨਹੀਂ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਅਸੀਂ ਇੱਕ ਸਰਵਰ ਵਿੱਚ ਕੁਝ ਡੇਟਾ ਸ਼ਾਮਲ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਕੁਝ ਦੂਜੇ ਵਿੱਚ ਅਤੇ ਗਣਨਾ ਕਰ ਸਕਦੇ ਹਾਂ; ਸਾਡੇ ਕੋਲ ਹਰ ਥਾਂ ਸਾਰਾ ਡੇਟਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਉਨ੍ਹਾਂ ਨੇ ਕੀ ਕੀਤਾ? ਸ਼ੁਰੂਆਤੀ ਤੌਰ 'ਤੇ, ਡੇਟਾ ਦਾ ਸਥਾਨੀਕਰਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ. ਹਰੇਕ ਸਰਵਰ ਸ਼ੇਅਰਾਂ ਦੇ ਇੱਕ ਖਾਸ ਸੈੱਟ ਲਈ ਕੀਮਤ ਡਾਟਾ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਅਤੇ ਉਹ ਇਕ ਦੂਜੇ ਨੂੰ ਕੱਟਦੇ ਨਹੀਂ ਹਨ। ਇਸ ਲਈ, ਸਮਾਨਾਂਤਰ ਅਤੇ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ logReturn ਦੀ ਗਣਨਾ ਕਰਨਾ ਸੰਭਵ ਹੈ; ਇਹ ਸਭ ਸਮਾਨਾਂਤਰ ਅਤੇ ਵੰਡਿਆ ਹੋਇਆ ਹੁੰਦਾ ਹੈ।

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

ਇਹ ਫਿਰ ਦੁਹਰਾਇਆ ਜਾ ਸਕਦਾ ਹੈ. ਅੱਖਰ “r” ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਇਸ ਡੇਟਾ ਨੂੰ ਦੁਹਰਾਇਆ ਹੈ। ਭਾਵ, ਸਾਡੇ ਕੋਲ ਤਿੰਨੋਂ ਸਰਵਰਾਂ 'ਤੇ ਇੱਕੋ ਜਿਹਾ ਡੇਟਾ ਹੈ - ਇਹ ਐਰੇ ਹਨ।

ਅਤੇ ਫਿਰ, ਇੱਕ ਵਿਸ਼ੇਸ਼ ਸਕ੍ਰਿਪਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਤੁਸੀਂ 12,5 ਮਿਲੀਅਨ ਸਬੰਧਾਂ ਦੇ ਇਸ ਸੈੱਟ ਤੋਂ ਪੈਕੇਜ ਬਣਾ ਸਕਦੇ ਹੋ ਜਿਨ੍ਹਾਂ ਦੀ ਗਣਨਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਭਾਵ, 2 ਜੋੜਿਆਂ ਦੇ ਸਬੰਧਾਂ ਦੇ ਨਾਲ 500 ਕਾਰਜ। ਅਤੇ ਇਸ ਕੰਮ ਦੀ ਇੱਕ ਖਾਸ ਕਲਿਕਹਾਊਸ ਸਰਵਰ 'ਤੇ ਗਣਨਾ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਉਸ ਕੋਲ ਸਾਰਾ ਡੇਟਾ ਹੈ ਕਿਉਂਕਿ ਡੇਟਾ ਇਕੋ ਜਿਹਾ ਹੈ ਅਤੇ ਉਹ ਇਸ ਦੀ ਕ੍ਰਮਵਾਰ ਗਣਨਾ ਕਰ ਸਕਦਾ ਹੈ.

ਇੱਥੇ ਇਹ ਹੈ ਕਿ ਇਹ ਦੁਬਾਰਾ ਕਿਵੇਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਪਹਿਲਾਂ, ਸਾਡੇ ਕੋਲ ਹੇਠਾਂ ਦਿੱਤੇ ਢਾਂਚੇ ਵਿੱਚ ਸਾਰਾ ਡਾਟਾ ਹੈ: ਸਮਾਂ, ਸ਼ੇਅਰ, ਕੀਮਤ। ਫਿਰ ਅਸੀਂ logReturn ਦੀ ਗਣਨਾ ਕੀਤੀ, ਅਰਥਾਤ ਉਸੇ ਢਾਂਚੇ ਦੇ ਡੇਟਾ, ਸਿਰਫ ਕੀਮਤ ਦੀ ਬਜਾਏ ਸਾਡੇ ਕੋਲ logReturn ਹੈ। ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਕੀਤਾ ਗਿਆ, ਅਰਥਾਤ ਸਾਨੂੰ ਤਰੱਕੀਆਂ ਅਤੇ ਕੀਮਤ ਸੂਚੀਆਂ ਦੁਆਰਾ ਸਮਾਂ ਅਤੇ ਸਮੂਹ ਐਰੇ ਮਿਲਿਆ। ਦੁਹਰਾਇਆ। ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ, ਉਹਨਾਂ ਨੇ ਬਹੁਤ ਸਾਰੇ ਕਾਰਜ ਤਿਆਰ ਕੀਤੇ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਲਿਕਹਾਊਸ ਨੂੰ ਖੁਆਇਆ ਤਾਂ ਜੋ ਇਹ ਉਹਨਾਂ ਦੀ ਗਿਣਤੀ ਕਰ ਸਕੇ। ਅਤੇ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ.

ਸੰਕਲਪ ਦੇ ਸਬੂਤ 'ਤੇ, ਕੰਮ ਇੱਕ ਉਪ-ਟਾਸਕ ਸੀ, ਭਾਵ ਉਨ੍ਹਾਂ ਨੇ ਘੱਟ ਡਾਟਾ ਲਿਆ। ਅਤੇ ਸਿਰਫ ਤਿੰਨ ਸਰਵਰਾਂ 'ਤੇ.

ਇਹ ਪਹਿਲੇ ਦੋ ਪੜਾਅ: Log_return ਦੀ ਗਣਨਾ ਕਰਨ ਅਤੇ ਇਸਨੂੰ ਐਰੇ ਵਿੱਚ ਲਪੇਟਣ ਵਿੱਚ ਹਰ ਇੱਕ ਘੰਟਾ ਲੱਗ ਗਿਆ।

ਅਤੇ ਸਬੰਧਾਂ ਦੀ ਗਣਨਾ ਕਰਨ ਵਿੱਚ ਲਗਭਗ 50 ਘੰਟੇ ਲੱਗਦੇ ਹਨ। ਪਰ 50 ਘੰਟੇ ਕਾਫ਼ੀ ਨਹੀਂ ਹਨ, ਕਿਉਂਕਿ ਪਹਿਲਾਂ ਇਹ ਉਹਨਾਂ ਲਈ ਹਫ਼ਤਿਆਂ ਲਈ ਕੰਮ ਕਰਦਾ ਸੀ. ਇਹ ਇੱਕ ਵੱਡੀ ਸਫਲਤਾ ਸੀ. ਅਤੇ ਜੇ ਤੁਸੀਂ ਗਿਣਦੇ ਹੋ, ਤਾਂ ਇਸ ਕਲੱਸਟਰ 'ਤੇ ਹਰ ਚੀਜ਼ ਨੂੰ 70 ਵਾਰ ਪ੍ਰਤੀ ਸਕਿੰਟ ਗਿਣਿਆ ਗਿਆ ਸੀ.

ਪਰ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਣ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਸ ਪ੍ਰਣਾਲੀ ਵਿਚ ਕੋਈ ਰੁਕਾਵਟ ਨਹੀਂ ਹੈ, ਯਾਨੀ ਇਹ ਲਗਭਗ ਰੇਖਿਕ ਤੌਰ 'ਤੇ ਸਕੇਲ ਕਰਦਾ ਹੈ। ਅਤੇ ਉਨ੍ਹਾਂ ਨੇ ਇਸ ਦੀ ਜਾਂਚ ਕੀਤੀ. ਇਹ ਸਫਲਤਾਪੂਰਵਕ ਸਕੇਲ ਕੀਤਾ ਗਿਆ ਸੀ।

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

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

-ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ! ਬਹੁਤ ਹੀ ਦਿਲਚਸਪ! ਕੀ ਅਪਾਚੇ ਫੀਨਿਕਸ ਨਾਲ ਕੋਈ ਤੁਲਨਾ ਕੀਤੀ ਗਈ ਹੈ?

-ਨਹੀਂ, ਮੈਂ ਕਿਸੇ ਨੂੰ ਤੁਲਨਾ ਕਰਦੇ ਨਹੀਂ ਸੁਣਿਆ ਹੈ। ਅਸੀਂ ਅਤੇ ਯਾਂਡੇਕਸ ਵੱਖ-ਵੱਖ ਡੇਟਾਬੇਸ ਦੇ ਨਾਲ ਕਲਿਕਹਾਊਸ ਦੀਆਂ ਸਾਰੀਆਂ ਤੁਲਨਾਵਾਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ। ਕਿਉਂਕਿ ਜੇਕਰ ਅਚਾਨਕ ਕੋਈ ਚੀਜ਼ ਕਲਿਕਹਾਊਸ ਨਾਲੋਂ ਤੇਜ਼ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਲੇਸ਼ਾ ਮਿਲੋਵਿਡੋਵ ਰਾਤ ਨੂੰ ਸੌਂ ਨਹੀਂ ਸਕਦਾ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਇਸ ਨੂੰ ਤੇਜ਼ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ. ਮੈਂ ਅਜਿਹੀ ਤੁਲਨਾ ਬਾਰੇ ਨਹੀਂ ਸੁਣਿਆ ਹੈ।

• (Alexey Milovidov) Apache Phoenix Hbase 'ਤੇ ਆਧਾਰਿਤ ਇੱਕ SQL ਇੰਜਣ ਹੈ। Hbase ਮੁੱਖ ਤੌਰ 'ਤੇ ਕੁੰਜੀ-ਮੁੱਲ ਕਿਸਮ ਦੇ ਕੰਮ ਦੇ ਦ੍ਰਿਸ਼ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਉੱਥੇ, ਹਰ ਲਾਈਨ ਵਿੱਚ ਆਰਬਿਟਰੇਰੀ ਨਾਮਾਂ ਵਾਲੇ ਕਾਲਮਾਂ ਦੀ ਇੱਕ ਆਰਬਿਟਰੇਰੀ ਸੰਖਿਆ ਹੋ ਸਕਦੀ ਹੈ। ਇਹ Hbase ਅਤੇ Cassandra ਵਰਗੇ ਸਿਸਟਮਾਂ ਬਾਰੇ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ। ਅਤੇ ਇਹ ਬਿਲਕੁਲ ਭਾਰੀ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਸਵਾਲ ਹਨ ਜੋ ਉਹਨਾਂ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਕੰਮ ਨਹੀਂ ਕਰਨਗੇ। ਜਾਂ ਤੁਸੀਂ ਸੋਚ ਸਕਦੇ ਹੋ ਕਿ ਉਹ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਕਲਿਕਹਾਊਸ ਨਾਲ ਕੋਈ ਅਨੁਭਵ ਨਹੀਂ ਹੈ।

• Спасибо

  • ਨਮਸਕਾਰ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਇਸ ਵਿਸ਼ੇ ਵਿੱਚ ਕਾਫ਼ੀ ਦਿਲਚਸਪੀ ਰੱਖਦਾ ਹਾਂ, ਕਿਉਂਕਿ ਮੇਰੇ ਕੋਲ ਇੱਕ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਉਪ-ਸਿਸਟਮ ਹੈ. ਪਰ ਜਦੋਂ ਮੈਂ ਕਲਿਕਹਾਊਸ ਨੂੰ ਦੇਖਦਾ ਹਾਂ, ਤਾਂ ਮੈਨੂੰ ਇਹ ਅਹਿਸਾਸ ਹੁੰਦਾ ਹੈ ਕਿ ਕਲਿਕਹਾਊਸ ਇਵੈਂਟ ਵਿਸ਼ਲੇਸ਼ਣ, ਪਰਿਵਰਤਨਸ਼ੀਲ ਲਈ ਬਹੁਤ ਵਧੀਆ ਹੈ. ਅਤੇ ਜੇ ਮੈਨੂੰ ਵੱਡੇ ਟੇਬਲ ਦੇ ਝੁੰਡ ਦੇ ਨਾਲ ਬਹੁਤ ਸਾਰੇ ਕਾਰੋਬਾਰੀ ਡੇਟਾ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਤਾਂ ਕਲਿਕਹਾਊਸ, ਜਿੱਥੋਂ ਤੱਕ ਮੈਂ ਸਮਝਦਾ ਹਾਂ, ਮੇਰੇ ਲਈ ਬਹੁਤ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ? ਖਾਸ ਕਰਕੇ ਜੇ ਉਹ ਬਦਲਦੇ ਹਨ। ਕੀ ਇਹ ਸਹੀ ਹੈ ਜਾਂ ਕੀ ਅਜਿਹੀਆਂ ਉਦਾਹਰਣਾਂ ਹਨ ਜੋ ਇਸ ਨੂੰ ਗਲਤ ਸਾਬਤ ਕਰ ਸਕਦੀਆਂ ਹਨ?

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

ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ! ਮੇਰੇ ਕੋਲ ਤਾਜ਼ਾ ਵਿੱਤੀ ਕੇਸ ਬਾਰੇ ਇੱਕ ਸਵਾਲ ਹੈ। ਉਨ੍ਹਾਂ ਕੋਲ ਵਿਸ਼ਲੇਸ਼ਣ ਸੀ. ਇਹ ਤੁਲਨਾ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ ਕਿ ਉਹ ਕਿਵੇਂ ਉੱਪਰ ਅਤੇ ਹੇਠਾਂ ਜਾਂਦੇ ਹਨ. ਅਤੇ ਮੈਂ ਸਮਝਦਾ ਹਾਂ ਕਿ ਤੁਸੀਂ ਖਾਸ ਤੌਰ 'ਤੇ ਇਸ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਸਿਸਟਮ ਬਣਾਇਆ ਹੈ? ਜੇਕਰ ਕੱਲ੍ਹ, ਮੰਨ ਲਓ, ਉਹਨਾਂ ਨੂੰ ਇਸ ਡੇਟਾ 'ਤੇ ਕਿਸੇ ਹੋਰ ਰਿਪੋਰਟ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਕੀ ਉਹਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਡਾਇਗ੍ਰਾਮ ਬਣਾਉਣ ਅਤੇ ਡੇਟਾ ਨੂੰ ਲੋਡ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ? ਭਾਵ, ਬੇਨਤੀ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕਿਸੇ ਕਿਸਮ ਦੀ ਪ੍ਰੀਪ੍ਰੋਸੈਸਿੰਗ ਕਰੋ?

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

ਇਹ ਸਪੱਸ਼ਟ ਹੈ. ਤੁਸੀਂ ਕਿਹਾ ਕਿ ਇਸ ਨੂੰ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਵਿੱਚ 50 ਘੰਟੇ ਲੱਗੇ। ਕੀ ਇਹ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਸ਼ੁਰੂ ਹੋ ਰਿਹਾ ਹੈ, ਜਦੋਂ ਤੁਸੀਂ ਡੇਟਾ ਲੋਡ ਕੀਤਾ ਜਾਂ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕੀਤੇ?

ਹਾ ਹਾ.

ਠੀਕ ਹੈ ਤੁਹਾਡਾ ਬਹੁਤ ਬਹੁਤ ਧੰਨਵਾਦ।

ਇਹ 3 ਸਰਵਰ ਕਲੱਸਟਰ 'ਤੇ ਹੈ।

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

ਬੇਸ਼ੱਕ, ਕੋਈ ਆਦਰਸ਼ ਪ੍ਰਣਾਲੀਆਂ ਨਹੀਂ ਹਨ. ਅਤੇ ਕਲਿਕਹਾਊਸ ਦੀਆਂ ਵੀ ਸਮੱਸਿਆਵਾਂ ਹਨ। ਪਰ ਕੀ ਤੁਸੀਂ Yandex.Metrica ਬਾਰੇ ਸੁਣਿਆ ਹੈ ਜੋ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ ਹੈ? ਸ਼ਾਇਦ ਨਹੀਂ। ਇਹ ClickHouse 'ਤੇ ਲਗਭਗ 2012-2013 ਤੋਂ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਮੈਂ ਆਪਣੇ ਅਨੁਭਵ ਬਾਰੇ ਵੀ ਇਹੀ ਕਹਿ ਸਕਦਾ ਹਾਂ। ਅਸੀਂ ਕਦੇ ਵੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਸਫਲ ਨਹੀਂ ਹੋਏ. ਕੁਝ ਅੰਸ਼ਕ ਚੀਜ਼ਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਉਹ ਕਾਰੋਬਾਰ ਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਲਈ ਕਦੇ ਵੀ ਨਾਜ਼ੁਕ ਨਹੀਂ ਸਨ। ਅਜਿਹਾ ਪਹਿਲਾਂ ਕਦੇ ਨਹੀਂ ਹੋਇਆ। ਕਲਿਕਹਾਊਸ ਕਾਫ਼ੀ ਭਰੋਸੇਮੰਦ ਹੈ ਅਤੇ ਬੇਤਰਤੀਬੇ ਤੌਰ 'ਤੇ ਕ੍ਰੈਸ਼ ਨਹੀਂ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਚਿੰਤਾ ਕਰਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਹ ਕੋਈ ਕੱਚੀ ਗੱਲ ਨਹੀਂ ਹੈ। ਇਹ ਬਹੁਤ ਸਾਰੀਆਂ ਕੰਪਨੀਆਂ ਦੁਆਰਾ ਸਾਬਤ ਕੀਤਾ ਗਿਆ ਹੈ.

ਸਤ ਸ੍ਰੀ ਅਕਾਲ! ਤੁਸੀਂ ਕਿਹਾ ਕਿ ਤੁਹਾਨੂੰ ਤੁਰੰਤ ਡਾਟਾ ਸਕੀਮਾ ਬਾਰੇ ਧਿਆਨ ਨਾਲ ਸੋਚਣ ਦੀ ਲੋੜ ਹੈ। ਕੀ ਹੋਇਆ ਜੇ ਇਹ ਹੋਇਆ? ਮੇਰਾ ਡੇਟਾ ਅੰਦਰ ਅਤੇ ਬਾਹਰ ਆ ਰਿਹਾ ਹੈ. ਛੇ ਮਹੀਨੇ ਬੀਤ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਮੈਂ ਸਮਝਦਾ ਹਾਂ ਕਿ ਮੈਂ ਇਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਰਹਿ ਸਕਦਾ, ਮੈਨੂੰ ਡੇਟਾ ਨੂੰ ਮੁੜ-ਅੱਪਲੋਡ ਕਰਨ ਅਤੇ ਇਸ ਨਾਲ ਕੁਝ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

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

Спасибо

ਸਰੋਤ: www.habr.com