ELK, Big Query ਅਤੇ TimescaleDB ਦੇ ਬਦਲ ਵਜੋਂ ਕਲਿਕਹਾਊਸ ਦੀ ਵਰਤੋਂ ਕਰਨਾ

ਕਲਿੱਕਹਾਊਸ Yandex ਦੁਆਰਾ ਬਣਾਈ ਗਈ ਔਨਲਾਈਨ ਐਨਾਲਿਟੀਕਲ ਪੁੱਛਗਿੱਛ ਪ੍ਰੋਸੈਸਿੰਗ (OLAP) ਲਈ ਇੱਕ ਓਪਨ-ਸੋਰਸ ਕਾਲਮਨਰ ਡਾਟਾਬੇਸ ਪ੍ਰਬੰਧਨ ਸਿਸਟਮ ਹੈ। ਇਹ Yandex, CloudFlare, VK.com, Badoo ਅਤੇ ਦੁਨੀਆ ਭਰ ਦੀਆਂ ਹੋਰ ਸੇਵਾਵਾਂ ਦੁਆਰਾ ਅਸਲ ਵਿੱਚ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ (ਪ੍ਰਤੀ ਸਕਿੰਟ ਹਜ਼ਾਰਾਂ ਕਤਾਰਾਂ ਦੀ ਸੰਮਿਲਨ ਜਾਂ ਡਿਸਕ ਉੱਤੇ ਸਟੋਰ ਕੀਤੇ ਡੇਟਾ ਦੇ ਪੈਟਾਬਾਈਟ)।

ਇੱਕ ਆਮ, "ਸਟ੍ਰਿੰਗ" DBMS ਵਿੱਚ, ਜਿਸ ਦੀਆਂ ਉਦਾਹਰਣਾਂ MySQL, Postgres, MS SQL ਸਰਵਰ ਹਨ, ਡੇਟਾ ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਇੱਕ ਕਤਾਰ ਨਾਲ ਸਬੰਧਤ ਮੁੱਲ ਭੌਤਿਕ ਤੌਰ 'ਤੇ ਨਾਲ-ਨਾਲ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਕਾਲਮ DBMS ਵਿੱਚ, ਵੱਖ-ਵੱਖ ਕਾਲਮਾਂ ਦੇ ਮੁੱਲ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਕਾਲਮ ਦਾ ਡੇਟਾ ਇਕੱਠੇ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:

ਕਾਲਮਨਰ DBMSs ਦੀਆਂ ਉਦਾਹਰਨਾਂ ਹਨ Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, kb+ Druid।

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

ਸੌਖਾ

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

MySQL ਦੇ ਮੁਕਾਬਲੇ, ਇਸ DBMS ਵਿੱਚ ਟੇਬਲ ਸਕੀਮਾ ਪਰਿਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਡੇਟਾ ਕਿਸਮ ਦੇ ਅੰਤਰ ਹਨ, ਇਸਲਈ ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਟੇਬਲ ਸਕੀਮਾ ਪਰਿਭਾਸ਼ਾਵਾਂ ਨੂੰ ਬਦਲਣ ਅਤੇ ਆਰਾਮਦਾਇਕ ਹੋਣ ਲਈ ਟੇਬਲ ਇੰਜਣਾਂ ਨੂੰ ਸਿੱਖਣ ਲਈ ਕੁਝ ਸਮਾਂ ਚਾਹੀਦਾ ਹੈ।

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

ਉਤਪਾਦਕਤਾ

• ਬੇਂਚਮਾਰਕ ਸੰਰਚਨਾ ਸਰਵਰ 'ਤੇ ਕਲਿਕਹਾਊਸ ਬਨਾਮ ਵਰਟਿਕਾ ਅਤੇ MySQL ਦੀ ਤੁਲਨਾ: ਦੋ ਸਾਕਟ Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 8 6TB SATA HDD, ext4 'ਤੇ।
• ਬੇਂਚਮਾਰਕ ਐਮਾਜ਼ਾਨ ਰੈੱਡਸ਼ਿਫਟ ਕਲਾਉਡ ਸਟੋਰੇਜ ਨਾਲ ਕਲਿਕਹਾਊਸ ਦੀ ਤੁਲਨਾ।
• ਬਲੌਗ ਦੇ ਅੰਸ਼ ਕਲਿਕਹਾਊਸ ਪ੍ਰਦਰਸ਼ਨ ਬਾਰੇ ਕਲਾਉਡਫਲੇਅਰ:

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

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

ਮੁੱਖ ਇੰਜਣ, ਜਾਂ ਇਸ ਦੀ ਬਜਾਏ, ਡੇਟਾ ਸਟੋਰ ਕਰਨ ਲਈ ਕਲਿਕਹਾਊਸ ਦੁਆਰਾ ਵਰਤੇ ਜਾਂਦੇ ਟੇਬਲ ਇੰਜਣਾਂ ਦਾ ਇੱਕ ਪਰਿਵਾਰ, MergeTree ਹੈ। ਇਹ ਇੰਜਣ Google BigTable ਜਾਂ Apache Cassandra ਵਿੱਚ ਵਰਤੇ ਜਾਣ ਵਾਲੇ LSM ਐਲਗੋਰਿਦਮ ਦੇ ਸਮਾਨ ਹੈ, ਪਰ ਇੱਕ ਇੰਟਰਮੀਡੀਏਟ ਮੈਮੋਰੀ ਟੇਬਲ ਬਣਾਉਣ ਤੋਂ ਬਚਦਾ ਹੈ ਅਤੇ ਡੇਟਾ ਨੂੰ ਸਿੱਧਾ ਡਿਸਕ 'ਤੇ ਲਿਖਦਾ ਹੈ। ਇਹ ਇਸਨੂੰ ਸ਼ਾਨਦਾਰ ਲਿਖਣ ਦਾ ਥ੍ਰਰੂਪੁਟ ਦਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਹਰੇਕ ਸੰਮਿਲਿਤ ਪੈਕੇਟ ਨੂੰ ਸਿਰਫ "ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ" ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ ਦੁਆਰਾ ਕ੍ਰਮਬੱਧ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਸੰਕੁਚਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਭਾਗ ਬਣਾਉਣ ਲਈ ਡਿਸਕ 'ਤੇ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ।

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

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

ਇਹ ਵੇਖਦੇ ਹੋਏ ਕਿ ਸਾਰੇ ਕਾਲਮਾਂ ਨੂੰ "ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ" ਦੁਆਰਾ ਕ੍ਰਮਬੱਧ ਕੀਤਾ ਗਿਆ ਹੈ, ਇੰਡੈਕਸ ਫਾਈਲ ਵਿੱਚ ਸਿਰਫ ਹਰ Nਵੀਂ ਕਤਾਰ ਦੇ ਲੇਬਲ (ਕੈਪਚਰ ਕੀਤੀਆਂ ਕਤਾਰਾਂ) ਸ਼ਾਮਲ ਹਨ, ਤਾਂ ਜੋ ਉਹਨਾਂ ਨੂੰ ਬਹੁਤ ਵੱਡੀਆਂ ਟੇਬਲਾਂ ਲਈ ਵੀ ਮੈਮੋਰੀ ਵਿੱਚ ਰੱਖਣ ਦੇ ਯੋਗ ਬਣਾਇਆ ਜਾ ਸਕੇ। ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਪੂਰਵ-ਨਿਰਧਾਰਤ ਸੈਟਿੰਗਾਂ ਨੂੰ "ਹਰ 8192ਵੀਂ ਕਤਾਰ 'ਤੇ ਨਿਸ਼ਾਨ ਲਗਾਉਣ ਲਈ ਸੈੱਟ ਕਰ ਸਕਦੇ ਹੋ, ਫਿਰ 1 ਟ੍ਰਿਲੀਅਨ ਦੇ ਨਾਲ ਇੱਕ ਸਾਰਣੀ ਦੀ "ਘੱਟ" ਇੰਡੈਕਸਿੰਗ। ਮੈਮੋਰੀ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਫਿੱਟ ਹੋਣ ਵਾਲੀਆਂ ਲਾਈਨਾਂ ਵਿੱਚ ਸਿਰਫ਼ 122 ਅੱਖਰ ਹੀ ਹੋਣਗੇ।

ਸਿਸਟਮ ਵਿਕਾਸ

ਕਲਿਕਹਾਊਸ ਦੇ ਵਿਕਾਸ ਅਤੇ ਸੁਧਾਰ ਦਾ ਪਤਾ ਲਗਾਇਆ ਜਾ ਸਕਦਾ ਹੈ Github ਰੈਪੋ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ "ਵੱਡੇ ਹੋਣ" ਦੀ ਪ੍ਰਕਿਰਿਆ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਰਫ਼ਤਾਰ ਨਾਲ ਹੋ ਰਹੀ ਹੈ।

ਪ੍ਰਸਿੱਧੀ

ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਕਲਿਕਹਾਊਸ ਦੀ ਪ੍ਰਸਿੱਧੀ ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਰਹੀ ਹੈ, ਖਾਸ ਕਰਕੇ ਰੂਸੀ ਬੋਲਣ ਵਾਲੇ ਭਾਈਚਾਰੇ ਵਿੱਚ. ਪਿਛਲੇ ਸਾਲ ਦੀ ਹਾਈ ਲੋਡ 2018 ਕਾਨਫਰੰਸ (ਮਾਸਕੋ, 8-9 ਨਵੰਬਰ, 2018) ਨੇ ਦਿਖਾਇਆ ਕਿ vk.com ਅਤੇ Badoo ਵਰਗੇ ਰਾਖਸ਼ ਕਲਿਕਹਾਊਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਜੋ ਇੱਕੋ ਸਮੇਂ ਹਜ਼ਾਰਾਂ ਸਰਵਰਾਂ ਤੋਂ ਡੇਟਾ (ਉਦਾਹਰਨ ਲਈ, ਲੌਗ) ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ। 40 ਮਿੰਟ ਦੀ ਵੀਡੀਓ ਵਿੱਚ VKontakte ਟੀਮ ਤੋਂ ਯੂਰੀ ਨਸਰੇਟਡੀਨੋਵ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਕਿਵੇਂ ਕੀਤਾ ਗਿਆ ਹੈ. ਜਲਦੀ ਹੀ ਅਸੀਂ ਸਮੱਗਰੀ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਸਹੂਲਤ ਲਈ ਹੈਬਰ 'ਤੇ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ ਪੋਸਟ ਕਰਾਂਗੇ।

ਐਪਲੀਕੇਸ਼ਨ

ਖੋਜ ਕਰਨ ਵਿੱਚ ਕੁਝ ਸਮਾਂ ਬਿਤਾਉਣ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਸੋਚਦਾ ਹਾਂ ਕਿ ਅਜਿਹੇ ਖੇਤਰ ਹਨ ਜਿੱਥੇ ਕਲਿਕਹਾਊਸ ਉਪਯੋਗੀ ਹੋ ਸਕਦਾ ਹੈ ਜਾਂ ਹੋਰ ਰਵਾਇਤੀ ਅਤੇ ਪ੍ਰਸਿੱਧ ਹੱਲ ਜਿਵੇਂ ਕਿ MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਦਲਣ ਦੇ ਯੋਗ ਹੋ ਸਕਦਾ ਹੈ. ਡਰੂਇਡ. ਉਪਰੋਕਤ DBMS ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕਰਨ ਜਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਦਲਣ ਲਈ ਕਲਿਕਹਾਊਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਵੇਰਵੇ ਹੇਠਾਂ ਦਿੱਤੇ ਗਏ ਹਨ।

MySQL ਅਤੇ PostgreSQL ਦਾ ਵਿਸਤਾਰ ਕਰਨਾ

ਹਾਲ ਹੀ ਵਿੱਚ, ਅਸੀਂ ਨਿਊਜ਼ਲੈਟਰ ਪਲੇਟਫਾਰਮ ਲਈ MySQL ਨੂੰ ਕਲਿਕਹਾਊਸ ਨਾਲ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਬਦਲ ਦਿੱਤਾ ਹੈ Mautic ਨਿਊਜ਼ਲੈਟਰ. ਸਮੱਸਿਆ ਇਹ ਸੀ ਕਿ MySQL ਨੇ ਬੇਸ 64 ਹੈਸ਼ ਨਾਲ ਭੇਜੀ ਗਈ ਹਰ ਈਮੇਲ ਅਤੇ ਉਸ ਈਮੇਲ ਦੇ ਹਰ ਲਿੰਕ ਨੂੰ ਲੌਗ ਕੀਤਾ, ਜਿਸ ਨਾਲ ਇੱਕ ਵਿਸ਼ਾਲ MySQL ਟੇਬਲ (email_stats) ਬਣ ਗਿਆ। ਸੇਵਾ ਦੇ ਗਾਹਕਾਂ ਨੂੰ ਸਿਰਫ਼ 10 ਮਿਲੀਅਨ ਈਮੇਲਾਂ ਭੇਜਣ ਤੋਂ ਬਾਅਦ, ਇਸ ਸਾਰਣੀ ਨੇ 150 GB ਫਾਈਲ ਸਪੇਸ 'ਤੇ ਕਬਜ਼ਾ ਕਰ ਲਿਆ, ਅਤੇ MySQL ਨੇ ਸਧਾਰਨ ਸਵਾਲਾਂ 'ਤੇ "ਮੂਰਖ" ਹੋਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਫਾਈਲ ਸਪੇਸ ਦੇ ਮੁੱਦੇ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਅਸੀਂ ਸਫਲਤਾਪੂਰਵਕ InnoDB ਟੇਬਲ ਕੰਪਰੈਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਜਿਸ ਨੇ ਇਸਨੂੰ 4 ਦੇ ਫੈਕਟਰ ਦੁਆਰਾ ਘਟਾ ਦਿੱਤਾ। ਹਾਲਾਂਕਿ, ਇਤਿਹਾਸ ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਖ਼ਾਤਰ MySQL ਵਿੱਚ 20-30 ਮਿਲੀਅਨ ਤੋਂ ਵੱਧ ਈਮੇਲਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਦਾ ਅਜੇ ਵੀ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ, ਜਿਵੇਂ ਕਿ ਕੋਈ ਵੀ ਸਧਾਰਨ ਪੁੱਛਗਿੱਛ ਜਿਸ ਲਈ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਸਵੈਪ ਅਤੇ ਭਾਰੀ I/O ਵਿੱਚ ਨਤੀਜੇ ਪੂਰੇ ਸਕੈਨ ਕਰਨੇ ਪੈਂਦੇ ਹਨ। ਓਵਰਹੈੱਡ, ਜਿਸ ਬਾਰੇ ਸਾਨੂੰ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਜ਼ੈਬਿਕਸ ਚੇਤਾਵਨੀਆਂ ਮਿਲਦੀਆਂ ਹਨ।

ਕਲਿਕਹਾਊਸ ਦੋ ਕੰਪਰੈਸ਼ਨ ਐਲਗੋਰਿਦਮ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜੋ ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਨੂੰ ਲਗਭਗ ਘਟਾਉਂਦੇ ਹਨ 3-4 ਵਾਰ, ਪਰ ਇਸ ਖਾਸ ਕੇਸ ਵਿੱਚ, ਡੇਟਾ ਖਾਸ ਤੌਰ 'ਤੇ "ਸੰਕੁਚਿਤ" ਸੀ।

ELK ਬਦਲਣਾ

ਮੇਰੇ ਆਪਣੇ ਤਜ਼ਰਬੇ ਦੇ ਆਧਾਰ 'ਤੇ, ELK ਸਟੈਕ (ElasticSearch, Logstash ਅਤੇ Kibana, ਇਸ ਖਾਸ ਮਾਮਲੇ ਵਿੱਚ ElasticSearch) ਨੂੰ ਲੌਗਸ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਲੋੜ ਤੋਂ ਵੱਧ ਚਲਾਉਣ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਰੋਤਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ElasticSearch ਇੱਕ ਵਧੀਆ ਇੰਜਣ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਚੰਗੀ ਫੁੱਲ-ਟੈਕਸਟ ਲੌਗ ਖੋਜ ਚਾਹੁੰਦੇ ਹੋ (ਅਤੇ ਮੈਨੂੰ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ ਇਸਦੀ ਲੋੜ ਹੈ), ਪਰ ਮੈਂ ਹੈਰਾਨ ਹਾਂ ਕਿ ਇਹ ਡੀ ਫੈਕਟੋ ਸਟੈਂਡਰਡ ਲੌਗਿੰਗ ਇੰਜਣ ਕਿਉਂ ਬਣ ਗਿਆ ਹੈ। ਇਸਦੀ ਇੰਜੈਸ਼ਨ ਕਾਰਗੁਜ਼ਾਰੀ, ਲੌਗਸਟੈਸ਼ ਦੇ ਨਾਲ ਮਿਲ ਕੇ, ਸਾਨੂੰ ਕਾਫ਼ੀ ਹਲਕੇ ਵਰਕਲੋਡਾਂ 'ਤੇ ਵੀ ਸਮੱਸਿਆਵਾਂ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਵੱਧ ਤੋਂ ਵੱਧ RAM ਅਤੇ ਡਿਸਕ ਸਪੇਸ ਨੂੰ ਜੋੜਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਡੇਟਾਬੇਸ ਦੇ ਰੂਪ ਵਿੱਚ, Clickhouse ਹੇਠ ਲਿਖੇ ਕਾਰਨਾਂ ਕਰਕੇ ElasticSearch ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ:

• SQL ਉਪਭਾਸ਼ਾ ਸਹਿਯੋਗ;
• ਸਟੋਰ ਕੀਤੇ ਡੇਟਾ ਦੇ ਸੰਕੁਚਨ ਦੀ ਸਭ ਤੋਂ ਵਧੀਆ ਡਿਗਰੀ;
• ਪੂਰੀ ਟੈਕਸਟ ਖੋਜ ਦੀ ਬਜਾਏ Regex ਖੋਜ ਲਈ ਸਮਰਥਨ;
• ਸੁਧਰੀ ਪੁੱਛਗਿੱਛ ਸਮਾਂ-ਸਾਰਣੀ ਅਤੇ ਬਿਹਤਰ ਸਮੁੱਚੀ ਕਾਰਗੁਜ਼ਾਰੀ।

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

ਘੱਟੋ-ਘੱਟ ਹੱਲਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹੋਏ, ਮੈਂ ਕਾਫਕਾ ਦੀ ਵਰਤੋਂ ਤੋਂ ਬਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋਏ, ਕਲਿਕਹਾਊਸ ਦੇ ਨਾਲ, ਫਲੂਐਂਟਬਿਟ, ਇੱਕ ਬਹੁਤ ਘੱਟ ਮੈਮੋਰੀ ਲੌਗ ਅੱਪਲੋਡ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ। ਹਾਲਾਂਕਿ, ਛੋਟੀਆਂ ਅਸੰਗਤਤਾਵਾਂ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਜਿਵੇਂ ਕਿ ਮਿਤੀ ਫਾਰਮੈਟ ਮੁੱਦੇਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਇਹ ਪ੍ਰੌਕਸੀ ਲੇਅਰ ਤੋਂ ਬਿਨਾਂ ਕੀਤਾ ਜਾ ਸਕੇ ਜੋ FluentBit ਤੋਂ ClickHouse ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਬਦਲਦਾ ਹੈ।

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

Google Big Query ਅਤੇ Amazon RedShift (ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਲਈ ਹੱਲ) ਦਾ ਬਦਲਣਾ

BigQuery ਲਈ ਆਦਰਸ਼ ਵਰਤੋਂ ਦਾ ਕੇਸ JSON ਡੇਟਾ ਦਾ 1TB ਲੋਡ ਕਰਨਾ ਅਤੇ ਇਸ 'ਤੇ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਸਵਾਲਾਂ ਨੂੰ ਚਲਾਉਣਾ ਹੈ। Big Query ਇੱਕ ਵਧੀਆ ਉਤਪਾਦ ਹੈ ਜਿਸਦੀ ਸਕੇਲੇਬਿਲਟੀ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਔਖਾ ਹੈ। ਇਹ ਇੱਕ ਅੰਦਰੂਨੀ ਕਲੱਸਟਰ 'ਤੇ ਚੱਲ ਰਹੇ ਕਲਿਕਹਾਊਸ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਗੁੰਝਲਦਾਰ ਸੌਫਟਵੇਅਰ ਹੈ, ਪਰ ਕਲਾਇੰਟ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਇਸ ਵਿੱਚ ਕਲਿਕਹਾਊਸ ਨਾਲ ਬਹੁਤ ਕੁਝ ਸਾਂਝਾ ਹੈ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਹਰੇਕ SELECT ਲਈ ਭੁਗਤਾਨ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ ਤਾਂ BigQuery ਤੇਜ਼ੀ ਨਾਲ "ਕੀਮਤ ਵਧਾ" ਸਕਦਾ ਹੈ, ਇਸਲਈ ਇਹ ਇਸਦੇ ਸਾਰੇ ਫਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨਾਂ ਦੇ ਨਾਲ ਇੱਕ ਅਸਲ SaaS ਹੱਲ ਹੈ।

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

ਅਲਟੀਨਿਟੀ ਦੇ ਸਹਿ-ਸੰਸਥਾਪਕ ਅਲੈਗਜ਼ੈਂਡਰ ਜ਼ੈਤਸੇਵ ਦੁਆਰਾ ਇੱਕ ਲੇਖ ਵਿੱਚ "ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਜਾਣਾ" ਅਜਿਹੇ DBMS ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੇ ਲਾਭਾਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ।

ਟਾਈਮਸਕੇਲਡੀਬੀ ਤਬਦੀਲੀ

TimescaleDB ਇੱਕ PostgreSQL ਐਕਸਟੈਂਸ਼ਨ ਹੈ ਜੋ ਇੱਕ ਨਿਯਮਤ ਡੇਟਾਬੇਸ ਵਿੱਚ ਟਾਈਮਸੀਰੀਜ਼ ਨਾਲ ਕੰਮ ਕਰਨ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਂਦਾ ਹੈ (https://docs.timescale.com/v1.0/introduction, https://habr.com/ru/company/zabbix/blog/458530/).

ਹਾਲਾਂਕਿ ਕਲਿਕਹਾਊਸ ਟਾਈਮ ਸੀਰੀਜ਼ ਦੇ ਸਥਾਨ ਵਿੱਚ ਇੱਕ ਗੰਭੀਰ ਪ੍ਰਤੀਯੋਗੀ ਨਹੀਂ ਹੈ, ਪਰ ਕਾਲਮ ਸਟ੍ਰਕਚਰ ਅਤੇ ਵੈਕਟਰ ਪੁੱਛਗਿੱਛ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੇ ਰੂਪ ਵਿੱਚ, ਇਹ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਸਵਾਲਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ TimescaleDB ਨਾਲੋਂ ਬਹੁਤ ਤੇਜ਼ ਹੈ। ਉਸੇ ਸਮੇਂ, ਕਲਿਕਹਾਊਸ ਪੈਕੇਟ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਲਗਭਗ 3 ਗੁਣਾ ਵੱਧ ਹੈ, ਇਸਦੇ ਇਲਾਵਾ, ਇਹ 20 ਗੁਣਾ ਘੱਟ ਡਿਸਕ ਸਪੇਸ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਇਤਿਹਾਸਕ ਡੇਟਾ ਦੀ ਵੱਡੀ ਮਾਤਰਾ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨ ਲਈ ਅਸਲ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹੈ: 
https://www.altinity.com/blog/ClickHouse-for-time-series.

ClickHouse ਦੇ ਉਲਟ, TimescaleDB ਵਿੱਚ ਕੁਝ ਡਿਸਕ ਸਪੇਸ ਬਚਾਉਣ ਦਾ ਇੱਕੋ ਇੱਕ ਤਰੀਕਾ ਹੈ ZFS ਜਾਂ ਸਮਾਨ ਫਾਈਲ ਸਿਸਟਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ।

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

• ਬਹੁਤ ਘੱਟ RAM (<3 GB) ਵਾਲੀਆਂ ਛੋਟੀਆਂ ਸਥਾਪਨਾਵਾਂ;
• ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਛੋਟੀਆਂ INSERTs ਜਿਹਨਾਂ ਨੂੰ ਤੁਸੀਂ ਵੱਡੇ ਟੁਕੜਿਆਂ ਵਿੱਚ ਬਫਰ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ;
• ਬਿਹਤਰ ਇਕਸਾਰਤਾ, ਇਕਸਾਰਤਾ ਅਤੇ ACID ਲੋੜਾਂ;
• ਪੋਸਟਜੀਆਈਐਸ ਸਹਾਇਤਾ;
• ਮੌਜੂਦਾ PostgreSQL ਟੇਬਲ ਨਾਲ ਮਿਲਾਓ, ਕਿਉਂਕਿ Timescale DB ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ PostgreSQL ਹੈ।

Hadoop ਅਤੇ MapReduce ਸਿਸਟਮ ਨਾਲ ਮੁਕਾਬਲਾ

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

ਪਿਨੋਟ ਅਤੇ ਡਰੂਡ ਨਾਲ ਮੁਕਾਬਲਾ

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

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

ਸਾਡੇ ਕੋਲ ਇਹਨਾਂ DBMSs ਨਾਲ ਬਹੁਤਾ ਤਜਰਬਾ ਨਹੀਂ ਹੈ, ਪਰ ਮੈਨੂੰ ਅੰਡਰਲਾਈੰਗ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਗੁੰਝਲਤਾ ਪਸੰਦ ਨਹੀਂ ਹੈ ਜੋ ਡਰੂਇਡ ਅਤੇ ਪਿਨੋਟ ਨੂੰ ਚਲਾਉਣ ਲਈ ਲੋੜੀਂਦਾ ਹੈ - ਇਹ ਸਾਰੇ ਪਾਸਿਆਂ ਤੋਂ ਜਾਵਾ ਦੁਆਰਾ ਘਿਰਿਆ ਹੋਇਆ "ਮੂਵਿੰਗ ਪਾਰਟਸ" ਦਾ ਪੂਰਾ ਸਮੂਹ ਹੈ।

ਡਰੂਇਡ ਅਤੇ ਪਿਨੋਟ ਅਪਾਚੇ ਇਨਕਿਊਬੇਟਰ ਪ੍ਰੋਜੈਕਟ ਹਨ, ਜੋ ਅਪਾਚੇ ਦੁਆਰਾ ਉਹਨਾਂ ਦੇ ਗਿਟਹਬ ਪ੍ਰੋਜੈਕਟ ਪੰਨਿਆਂ 'ਤੇ ਵਿਸਥਾਰ ਵਿੱਚ ਕਵਰ ਕੀਤੇ ਗਏ ਹਨ। ਪਿਨੋਟ ਅਕਤੂਬਰ 2018 ਵਿੱਚ ਇਨਕਿਊਬੇਟਰ ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਇਆ ਸੀ, ਅਤੇ ਡਰੂਡ ਦਾ ਜਨਮ 8 ਮਹੀਨੇ ਪਹਿਲਾਂ - ਫਰਵਰੀ ਵਿੱਚ ਹੋਇਆ ਸੀ।

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

ਕਲਿਕਹਾਊਸ ਦੇ ਨੁਕਸਾਨ

ਅਸਪੱਸ਼ਟਤਾ: ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਇਹ ਅਜੇ ਵੀ ਇੱਕ ਬੋਰਿੰਗ ਤਕਨਾਲੋਜੀ ਹੈ, ਪਰ ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ, ਹੋਰ ਕਾਲਮ DBMS ਵਿੱਚ ਅਜਿਹਾ ਕੁਝ ਨਹੀਂ ਦੇਖਿਆ ਗਿਆ ਹੈ.

ਛੋਟੀਆਂ ਸੰਮਿਲਨਾਂ ਤੇਜ਼ ਰਫ਼ਤਾਰ ਨਾਲ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਨਹੀਂ ਕਰਦੀਆਂ ਹਨ: ਸੰਮਿਲਨਾਂ ਨੂੰ ਵੱਡੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਛੋਟੀਆਂ ਸੰਮਿਲਨਾਂ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਹਰ ਕਤਾਰ ਵਿੱਚ ਕਾਲਮਾਂ ਦੀ ਸੰਖਿਆ ਦੇ ਅਨੁਪਾਤ ਵਿੱਚ ਘਟ ਜਾਂਦੀ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਕਲਿਕਹਾਊਸ ਡਿਸਕ 'ਤੇ ਡਾਟਾ ਸਟੋਰ ਕਰਦਾ ਹੈ - ਹਰੇਕ ਕਾਲਮ ਦਾ ਮਤਲਬ ਹੈ 1 ਜਾਂ ਇਸ ਤੋਂ ਵੱਧ, ਇਸ ਲਈ 1 ਕਾਲਮਾਂ ਵਾਲੀ 100 ਕਤਾਰ ਪਾਉਣ ਲਈ, ਤੁਹਾਨੂੰ ਘੱਟੋ-ਘੱਟ 100 ਫਾਈਲਾਂ ਖੋਲ੍ਹਣ ਅਤੇ ਲਿਖਣ ਦੀ ਲੋੜ ਹੈ। ਇਸ ਲਈ ਇਨਸਰਟ ਬਫਰਿੰਗ ਲਈ ਇੱਕ ਵਿਚੋਲੇ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਜਦੋਂ ਤੱਕ ਕਿ ਕਲਾਇੰਟ ਖੁਦ ਬਫਰਿੰਗ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ) - ਆਮ ਤੌਰ 'ਤੇ ਕਾਫਕਾ ਜਾਂ ਕਿਸੇ ਕਿਸਮ ਦੀ ਕਤਾਰ ਪ੍ਰਣਾਲੀ। ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ MergeTree ਟੇਬਲ ਵਿੱਚ ਡੇਟਾ ਦੇ ਵੱਡੇ ਭਾਗਾਂ ਨੂੰ ਕਾਪੀ ਕਰਨ ਲਈ ਬਫਰ ਟੇਬਲ ਇੰਜਣ ਦੀ ਵਰਤੋਂ ਵੀ ਕਰ ਸਕਦੇ ਹੋ।

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

ਸਿੱਟਾ

ਆਉਣ ਵਾਲੇ ਸਾਲਾਂ ਵਿੱਚ, ਅਸੀਂ Qwintry ਵਿੱਚ ClickHouse ਦੀ ਵਿਆਪਕ ਵਰਤੋਂ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ, ਕਿਉਂਕਿ ਇਹ DBMS ਪ੍ਰਦਰਸ਼ਨ, ਘੱਟ ਓਵਰਹੈੱਡ, ਸਕੇਲੇਬਿਲਟੀ, ਅਤੇ ਸਰਲਤਾ ਦਾ ਇੱਕ ਸ਼ਾਨਦਾਰ ਸੰਤੁਲਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਮੈਨੂੰ ਪੂਰਾ ਯਕੀਨ ਹੈ ਕਿ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਫੈਲ ਜਾਵੇਗਾ ਜਦੋਂ ਕਲਿਕਹਾਊਸ ਕਮਿਊਨਿਟੀ ਇਸ ਨੂੰ ਛੋਟੀਆਂ ਅਤੇ ਮੱਧਮ ਸਥਾਪਨਾਵਾਂ ਵਿੱਚ ਵਰਤਣ ਦੇ ਹੋਰ ਤਰੀਕੇ ਲੈ ਕੇ ਆਵੇਗੀ।

ਕੁਝ ਵਿਗਿਆਪਨ 🙂

ਸਾਡੇ ਨਾਲ ਰਹਿਣ ਲਈ ਤੁਹਾਡਾ ਧੰਨਵਾਦ। ਕੀ ਤੁਹਾਨੂੰ ਸਾਡੇ ਲੇਖ ਪਸੰਦ ਹਨ? ਹੋਰ ਦਿਲਚਸਪ ਸਮੱਗਰੀ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ? ਆਰਡਰ ਦੇ ਕੇ ਜਾਂ ਦੋਸਤਾਂ ਨੂੰ ਸਿਫਾਰਸ਼ ਕਰਕੇ ਸਾਡਾ ਸਮਰਥਨ ਕਰੋ, $4.99 ਤੋਂ ਡਿਵੈਲਪਰਾਂ ਲਈ ਕਲਾਉਡ VPS, ਪ੍ਰਵੇਸ਼-ਪੱਧਰ ਦੇ ਸਰਵਰਾਂ ਦਾ ਇੱਕ ਵਿਲੱਖਣ ਐਨਾਲਾਗ, ਜਿਸਦੀ ਖੋਜ ਸਾਡੇ ਦੁਆਰਾ ਤੁਹਾਡੇ ਲਈ ਕੀਤੀ ਗਈ ਸੀ: VPS (KVM) E5-2697 v3 (6 ਕੋਰ) 10GB DDR4 480GB SSD 1Gbps ਤੋਂ $19 ਜਾਂ ਸਰਵਰ ਨੂੰ ਕਿਵੇਂ ਸਾਂਝਾ ਕਰਨਾ ਹੈ ਬਾਰੇ ਪੂਰੀ ਸੱਚਾਈ? (RAID1 ਅਤੇ RAID10 ਦੇ ਨਾਲ ਉਪਲਬਧ, 24 ਕੋਰ ਤੱਕ ਅਤੇ 40GB DDR4 ਤੱਕ)।

ਡੈਲ R730xd ਐਮਸਟਰਡਮ ਵਿੱਚ ਈਕੁਇਨਿਕਸ ਟੀਅਰ IV ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ 2 ਗੁਣਾ ਸਸਤਾ? ਇੱਥੇ ਹੀ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ਟੀਵੀ $199 ਤੋਂ ਨੀਦਰਲੈਂਡ ਵਿੱਚ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 ਤੋਂ! ਬਾਰੇ ਪੜ੍ਹੋ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਕਾਰਪੋਰੇਸ਼ਨ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਵੇ ਡੇਲ R730xd E5-2650 v4 ਸਰਵਰਾਂ ਦੀ ਵਰਤੋਂ ਨਾਲ ਕਲਾਸ 9000 ਯੂਰੋ ਦੀ ਕੀਮਤ ਦੇ ਇੱਕ ਪੈਸੇ ਲਈ?

ਸਰੋਤ: www.habr.com