ਅਸੀਂ ਮਲਟੀਪਲ ਟਾਈਮ ਸੀਰੀਜ਼ ਡੇਟਾਬੇਸ ਦੀ ਜਾਂਚ ਕਿਵੇਂ ਕੀਤੀ

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

ਇਹ ਜਾਪਦਾ ਹੈ ਕਿ 2019 ਵਿੱਚ ਇੱਕ ਲੇਖ ਜਿਸ ਬਾਰੇ TSDB ਵਰਤਣ ਯੋਗ ਹੈ ਸਿਰਫ਼ ਇੱਕ ਵਾਕ ਹੋਵੇਗਾ: "ਸਿਰਫ਼ ਕਲਿਕਹਾਊਸ ਦੀ ਵਰਤੋਂ ਕਰੋ।" ਪਰ... ਇੱਥੇ ਬਾਰੀਕੀਆਂ ਹਨ।

ਦਰਅਸਲ, ਕਲਿਕਹਾਊਸ ਸਰਗਰਮੀ ਨਾਲ ਵਿਕਾਸ ਕਰ ਰਿਹਾ ਹੈ, ਉਪਭੋਗਤਾ ਅਧਾਰ ਵਧ ਰਿਹਾ ਹੈ, ਅਤੇ ਸਮਰਥਨ ਬਹੁਤ ਸਰਗਰਮ ਹੈ, ਪਰ ਕੀ ਅਸੀਂ ਕਲਿਕਹਾਊਸ ਦੀ ਜਨਤਕ ਸਫਲਤਾ ਲਈ ਬੰਧਕ ਬਣ ਗਏ ਹਾਂ, ਜਿਸ ਨੇ ਹੋਰ, ਸ਼ਾਇਦ ਵਧੇਰੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ/ਭਰੋਸੇਯੋਗ ਹੱਲਾਂ ਨੂੰ ਛਾਇਆ ਹੋਇਆ ਹੈ?

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

ਸਮੱਸਿਆ ਦਾ ਗਠਨ

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਜ਼ਰੂਰੀ ਪ੍ਰਸਤਾਵਨਾ. ਸਾਨੂੰ ਆਪਣੀ ਖੁਦ ਦੀ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਦੀ ਕਿਉਂ ਲੋੜ ਹੈ ਅਤੇ ਇਹ ਕਿਵੇਂ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ?

ਅਸੀਂ 2008 ਵਿੱਚ ਸਹਾਇਤਾ ਸੇਵਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਅਤੇ 2010 ਤੱਕ ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਉਸ ਸਮੇਂ ਮੌਜੂਦ ਹੱਲਾਂ ਦੇ ਨਾਲ ਕਲਾਇੰਟ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਹੋਣ ਵਾਲੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਬਾਰੇ ਡੇਟਾ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋ ਗਿਆ ਹੈ (ਅਸੀਂ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਰੱਬ ਮੈਨੂੰ ਮਾਫ਼ ਕਰੋ, ਕੈਟੀ, ਜ਼ੈਬਿਕਸ ਅਤੇ ਉੱਭਰ ਰਹੀ ਗ੍ਰੈਫਾਈਟ)।

ਸਾਡੀਆਂ ਮੁੱਖ ਲੋੜਾਂ ਸਨ:

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

ਇਸ ਲੇਖ ਵਿਚ ਅਸੀਂ ਆਖਰੀ ਬਿੰਦੂ ਵਿਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਾਂ.

ਸਟੋਰੇਜ ਦੀ ਗੱਲ ਕਰਦੇ ਹੋਏ, ਲੋੜਾਂ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਸਨ:

• ਸਿਸਟਮ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ;
• ਇਹ ਫਾਇਦੇਮੰਦ ਹੈ ਕਿ ਸਿਸਟਮ ਦਾ ਇੱਕ SQL ਇੰਟਰਫੇਸ ਹੈ;
• ਸਿਸਟਮ ਸਥਿਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇੱਕ ਕਿਰਿਆਸ਼ੀਲ ਉਪਭੋਗਤਾ ਅਧਾਰ ਅਤੇ ਸਮਰਥਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਇੱਕ ਵਾਰ ਜਦੋਂ ਸਾਨੂੰ MemcacheDB, ਜੋ ਕਿ ਹੁਣ ਵਿਕਸਤ ਨਹੀਂ ਸੀ, ਜਾਂ MooseFS ਵੰਡਿਆ ਸਟੋਰੇਜ, ਜਿਸ ਦਾ ਬੱਗ ਟਰੈਕਰ ਚੀਨੀ ਵਿੱਚ ਰੱਖਿਆ ਗਿਆ ਸੀ, ਨੂੰ ਸਮਰਥਨ ਦੇਣ ਦੀ ਲੋੜ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ: ਅਸੀਂ ਇਸ ਕਹਾਣੀ ਨੂੰ ਦੁਹਰਾਉਂਦੇ ਹਾਂ ਕਿਉਂਕਿ ਸਾਡੇ ਪ੍ਰੋਜੈਕਟ ਨਹੀਂ ਚਾਹੁੰਦੇ ਸਨ);
• CAP ਸਿਧਾਂਤ ਦੀ ਪਾਲਣਾ: ਇਕਸਾਰਤਾ (ਲੋੜੀਂਦੀ) - ਡੇਟਾ ਅਪ-ਟੂ-ਡੇਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਸੀਂ ਨਹੀਂ ਚਾਹੁੰਦੇ ਕਿ ਚੇਤਾਵਨੀ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀ ਨਵਾਂ ਡੇਟਾ ਪ੍ਰਾਪਤ ਨਾ ਕਰੇ ਅਤੇ ਸਾਰੇ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਡੇਟਾ ਦੇ ਨਾ ਆਉਣ ਬਾਰੇ ਚੇਤਾਵਨੀਆਂ ਨੂੰ ਥੁੱਕੇ; ਭਾਗ ਸਹਿਣਸ਼ੀਲਤਾ (ਲੋੜੀਂਦੀ) - ਅਸੀਂ ਸਪਲਿਟ ਬ੍ਰੇਨ ਸਿਸਟਮ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ; ਉਪਲਬਧਤਾ (ਨਾਜ਼ੁਕ ਨਹੀਂ, ਜੇਕਰ ਕੋਈ ਕਿਰਿਆਸ਼ੀਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਹੈ) - ਅਸੀਂ ਕੋਡ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਦੁਰਘਟਨਾ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਆਪਣੇ ਆਪ ਬੈਕਅੱਪ ਸਿਸਟਮ ਤੇ ਸਵਿਚ ਕਰ ਸਕਦੇ ਹਾਂ।

ਅਜੀਬ ਤੌਰ 'ਤੇ, ਉਸ ਸਮੇਂ MySQL ਸਾਡੇ ਲਈ ਆਦਰਸ਼ ਹੱਲ ਨਿਕਲਿਆ. ਸਾਡਾ ਡੇਟਾ ਢਾਂਚਾ ਬਹੁਤ ਸਰਲ ਸੀ: ਸਰਵਰ ਆਈਡੀ, ਕਾਊਂਟਰ ਆਈਡੀ, ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਮੁੱਲ; ਗਰਮ ਡੇਟਾ ਦੇ ਤੇਜ਼ ਨਮੂਨੇ ਨੂੰ ਇੱਕ ਵੱਡੇ ਬਫਰ ਪੂਲ ਦੁਆਰਾ ਯਕੀਨੀ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਅਤੇ ਇਤਿਹਾਸਕ ਡੇਟਾ ਦੇ ਨਮੂਨੇ ਨੂੰ SSD ਦੁਆਰਾ ਯਕੀਨੀ ਬਣਾਇਆ ਗਿਆ ਸੀ।

ਇਸ ਤਰ੍ਹਾਂ, ਅਸੀਂ ਡੇਟਾ ਦੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੈਂਡਰ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਕਿੰਟ 200 ms ਤੱਕ ਵੇਰਵੇ ਦੇ ਨਾਲ, ਤਾਜ਼ਾ ਦੋ-ਹਫ਼ਤਿਆਂ ਦੇ ਡੇਟਾ ਦਾ ਇੱਕ ਨਮੂਨਾ ਪ੍ਰਾਪਤ ਕੀਤਾ, ਅਤੇ ਕਾਫ਼ੀ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਇਸ ਸਿਸਟਮ ਵਿੱਚ ਰਹੇ।

ਇਸ ਦੌਰਾਨ, ਸਮਾਂ ਬੀਤਦਾ ਗਿਆ ਅਤੇ ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਵਧਦੀ ਗਈ। 2016 ਤੱਕ, ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਟੇਰਾਬਾਈਟ ਦੇ ਦਸਾਂ ਤੱਕ ਪਹੁੰਚ ਗਈ, ਜੋ ਕਿ ਕਿਰਾਏ ਦੇ SSD ਸਟੋਰੇਜ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਖਰਚ ਸੀ।

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

ਹਾਲਾਂਕਿ, ਕੰਪਨੀ ਦੀ ਮੁੱਖ ਪ੍ਰਣਾਲੀ ਸਥਿਰਤਾ ਨਾਲ ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਮੈਂ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ 'ਤੇ ਜਾਣ ਦਾ ਪ੍ਰਯੋਗ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ।

2017 ਵਿੱਚ, ਸੈਨ ਜੋਸ ਵਿੱਚ ਪਰਕੋਨਾ ਲਾਈਵ ਕਾਨਫਰੰਸ ਵਿੱਚ, ਕਲਿਕਹਾਊਸ ਡਿਵੈਲਪਰਾਂ ਨੇ ਸ਼ਾਇਦ ਪਹਿਲੀ ਵਾਰ ਆਪਣੇ ਆਪ ਦਾ ਐਲਾਨ ਕੀਤਾ। ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ, ਸਿਸਟਮ ਉਤਪਾਦਨ ਲਈ ਤਿਆਰ ਸੀ (ਠੀਕ ਹੈ, Yandex.Metrica ਇੱਕ ਕਠੋਰ ਉਤਪਾਦਨ ਪ੍ਰਣਾਲੀ ਹੈ), ਸਮਰਥਨ ਤੇਜ਼ ਅਤੇ ਸਧਾਰਨ ਸੀ, ਅਤੇ, ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਓਪਰੇਸ਼ਨ ਸਧਾਰਨ ਸੀ. 2018 ਤੋਂ, ਅਸੀਂ ਪਰਿਵਰਤਨ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕੀਤੀ ਹੈ। ਪਰ ਉਸ ਸਮੇਂ ਤੱਕ, ਬਹੁਤ ਸਾਰੇ "ਬਾਲਗ" ਅਤੇ ਸਮਾਂ-ਪਰੀਖਣ ਵਾਲੇ TSDB ਪ੍ਰਣਾਲੀਆਂ ਸਨ, ਅਤੇ ਅਸੀਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਾਫ਼ੀ ਸਮਾਂ ਲਗਾਉਣ ਅਤੇ ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ ਕਿ ਸਾਡੀਆਂ ਜ਼ਰੂਰਤਾਂ ਦੇ ਅਨੁਸਾਰ, ਕਲਿਕਹਾਊਸ ਲਈ ਕੋਈ ਵਿਕਲਪਿਕ ਹੱਲ ਨਹੀਂ ਹਨ।

ਪਹਿਲਾਂ ਹੀ ਨਿਰਧਾਰਤ ਸਟੋਰੇਜ ਲੋੜਾਂ ਤੋਂ ਇਲਾਵਾ, ਨਵੀਆਂ ਆਈਆਂ ਹਨ:

• ਨਵੇਂ ਸਿਸਟਮ ਨੂੰ ਹਾਰਡਵੇਅਰ ਦੀ ਉਸੇ ਮਾਤਰਾ 'ਤੇ ਘੱਟੋ-ਘੱਟ MySQL ਵਾਂਗ ਹੀ ਕਾਰਗੁਜ਼ਾਰੀ ਪ੍ਰਦਾਨ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ;
• ਨਵੇਂ ਸਿਸਟਮ ਦੀ ਸਟੋਰੇਜ ਨੂੰ ਕਾਫ਼ੀ ਘੱਟ ਜਗ੍ਹਾ ਲੈਣੀ ਚਾਹੀਦੀ ਹੈ;
• DBMS ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ ਅਜੇ ਵੀ ਆਸਾਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ;
• DBMS ਬਦਲਦੇ ਸਮੇਂ ਮੈਂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਬਦਲਣਾ ਚਾਹੁੰਦਾ ਸੀ।

ਅਸੀਂ ਕਿਹੜੀਆਂ ਪ੍ਰਣਾਲੀਆਂ 'ਤੇ ਵਿਚਾਰ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ?

ਅਪਾਚੇ ਹਾਈਵ/ਅਪਾਚੇ ਇਮਪਲਾ
ਇੱਕ ਪੁਰਾਣਾ, ਲੜਾਈ-ਜਾਂਚਿਆ ਹੋਇਆ ਹੈਡੂਪ ਸਟੈਕ। ਅਸਲ ਵਿੱਚ, ਇਹ ਇੱਕ SQL ਇੰਟਰਫੇਸ ਹੈ ਜੋ HDFS 'ਤੇ ਮੂਲ ਫਾਰਮੈਟਾਂ ਵਿੱਚ ਡਾਟਾ ਸਟੋਰ ਕਰਨ ਦੇ ਸਿਖਰ 'ਤੇ ਬਣਾਇਆ ਗਿਆ ਹੈ।

ਪ੍ਰੋ.

• ਸਥਿਰ ਕਾਰਵਾਈ ਦੇ ਨਾਲ, ਡੇਟਾ ਨੂੰ ਸਕੇਲ ਕਰਨਾ ਬਹੁਤ ਆਸਾਨ ਹੈ।
• ਡਾਟਾ ਸਟੋਰੇਜ (ਘੱਟ ਥਾਂ) ਲਈ ਕਾਲਮ ਹੱਲ ਹਨ।
• ਜਦੋਂ ਸਰੋਤ ਉਪਲਬਧ ਹੁੰਦੇ ਹਨ ਤਾਂ ਸਮਾਨਾਂਤਰ ਕਾਰਜਾਂ ਦਾ ਬਹੁਤ ਤੇਜ਼ ਐਗਜ਼ੀਕਿਊਸ਼ਨ।

ਘਟਾਓ.

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

ਹਾਲਾਂਕਿ:

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

ਡਰੂਇਡ/ਪਿਨੋਟ

ਖਾਸ ਤੌਰ 'ਤੇ TSDB ਬਾਰੇ ਹੋਰ ਬਹੁਤ ਕੁਝ ਹੈ, ਪਰ ਦੁਬਾਰਾ, Hadoop ਸਟੈਕ.

ਹਨ ਡਰੂਇਡ ਅਤੇ ਪਿਨੋਟ ਬਨਾਮ ਕਲਿਕਹਾਊਸ ਦੇ ਚੰਗੇ ਅਤੇ ਨੁਕਸਾਨ ਦੀ ਤੁਲਨਾ ਕਰਨ ਵਾਲਾ ਵਧੀਆ ਲੇਖ .

ਕੁਝ ਸ਼ਬਦਾਂ ਵਿੱਚ: ਡਰੂਇਡ/ਪਿਨੋਟ ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ ਕਲਿਕਹਾਊਸ ਨਾਲੋਂ ਬਿਹਤਰ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ ਜਿੱਥੇ:

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

ਉਲਟ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਕਲਿਕਹਾਊਸ ਬਿਹਤਰ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਸਾਡਾ ਮਾਮਲਾ ਹੈ।

ਕਲਿਕਹਾouseਸ

• SQL-ਵਰਗੇ
• ਪ੍ਰਬੰਧਨ ਲਈ ਆਸਾਨ.
• ਲੋਕ ਕਹਿੰਦੇ ਹਨ ਕਿ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ.

ਟੈਸਟਿੰਗ ਲਈ ਸ਼ਾਰਟਲਿਸਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

InfluxDB

ਕਲਿਕਹਾਊਸ ਦਾ ਇੱਕ ਵਿਦੇਸ਼ੀ ਵਿਕਲਪ। ਨੁਕਸਾਨਾਂ ਵਿੱਚੋਂ: ਉੱਚ ਉਪਲਬਧਤਾ ਸਿਰਫ ਵਪਾਰਕ ਸੰਸਕਰਣ ਵਿੱਚ ਮੌਜੂਦ ਹੈ, ਪਰ ਇਸਦੀ ਤੁਲਨਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ.

ਟੈਸਟਿੰਗ ਲਈ ਸ਼ਾਰਟਲਿਸਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

Cassandra

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

ਕੈਸੈਂਡਰਾ ਰਵਾਇਤੀ ਅਰਥਾਂ ਵਿੱਚ ਇੱਕ ਕਾਲਮ ਡੇਟਾਬੇਸ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਕਤਾਰ ਦ੍ਰਿਸ਼ ਦੀ ਤਰ੍ਹਾਂ ਦਿਸਦਾ ਹੈ, ਪਰ ਹਰੇਕ ਲਾਈਨ ਵਿੱਚ ਕਾਲਮ ਦੀ ਇੱਕ ਵੱਖਰੀ ਸੰਖਿਆ ਹੋ ਸਕਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਇੱਕ ਕਾਲਮ ਦ੍ਰਿਸ਼ ਨੂੰ ਵਿਵਸਥਿਤ ਕਰਨਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਸ ਅਰਥ ਵਿਚ, ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ 2 ਬਿਲੀਅਨ ਕਾਲਮਾਂ ਦੀ ਸੀਮਾ ਦੇ ਨਾਲ, ਕਾਲਮਾਂ (ਅਤੇ ਉਸੇ ਸਮੇਂ ਦੀ ਲੜੀ) ਵਿੱਚ ਕੁਝ ਡੇਟਾ ਸਟੋਰ ਕਰਨਾ ਸੰਭਵ ਹੈ. ਉਦਾਹਰਨ ਲਈ, MySQL ਵਿੱਚ 4096 ਕਾਲਮਾਂ ਦੀ ਇੱਕ ਸੀਮਾ ਹੈ ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਅਜਿਹਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ ਤਾਂ ਕੋਡ 1117 ਦੇ ਨਾਲ ਇੱਕ ਗਲਤੀ 'ਤੇ ਠੋਕਰ ਮਾਰਨਾ ਆਸਾਨ ਹੈ।

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

Prometheus

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

ਟੈਸਟਿੰਗ ਵਿਧੀ ਅਤੇ ਨਤੀਜੇ

ਇਸ ਲਈ, ਅਸੀਂ ਹੇਠ ਲਿਖੀਆਂ 5 ਸੰਰਚਨਾਵਾਂ ਵਿੱਚ 6 ਡੇਟਾਬੇਸ ਦੀ ਜਾਂਚ ਕੀਤੀ: ਕਲਿਕਹਾਊਸ (1 ਨੋਡ), ਕਲਿਕਹਾਊਸ (3 ਨੋਡਾਂ ਲਈ ਵੰਡਿਆ ਸਾਰਣੀ), ਇਨਫਲੁਕਸਡੀਬੀ, ਮਾਈਐਸਕਯੂਐਲ 8, ਕੈਸੈਂਡਰਾ (3 ਨੋਡ) ਅਤੇ ਪ੍ਰੋਮੀਥੀਅਸ। ਟੈਸਟ ਯੋਜਨਾ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਹੈ:

1. ਇੱਕ ਹਫ਼ਤੇ ਲਈ ਇਤਿਹਾਸਕ ਡੇਟਾ ਅੱਪਲੋਡ ਕਰੋ (840 ਮਿਲੀਅਨ ਮੁੱਲ ਪ੍ਰਤੀ ਦਿਨ; 208 ਹਜ਼ਾਰ ਮੀਟ੍ਰਿਕਸ);
2. ਅਸੀਂ ਇੱਕ ਰਿਕਾਰਡਿੰਗ ਲੋਡ ਤਿਆਰ ਕਰਦੇ ਹਾਂ (6 ਲੋਡ ਮੋਡਾਂ 'ਤੇ ਵਿਚਾਰ ਕੀਤਾ ਗਿਆ ਸੀ, ਹੇਠਾਂ ਦੇਖੋ);
3. ਰਿਕਾਰਡਿੰਗ ਦੇ ਸਮਾਨਾਂਤਰ, ਅਸੀਂ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਚੋਣ ਕਰਦੇ ਹਾਂ, ਚਾਰਟ ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲੇ ਉਪਭੋਗਤਾ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਨਕਲ ਕਰਦੇ ਹੋਏ। ਚੀਜ਼ਾਂ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਗੁੰਝਲਦਾਰ ਨਾ ਬਣਾਉਣ ਲਈ, ਅਸੀਂ ਇੱਕ ਹਫ਼ਤੇ ਲਈ 10 ਮੈਟ੍ਰਿਕਸ (ਜੋ ਕਿ CPU ਗ੍ਰਾਫ 'ਤੇ ਕਿੰਨੇ ਹਨ) ਲਈ ਡੇਟਾ ਚੁਣਿਆ ਹੈ।

ਅਸੀਂ ਆਪਣੇ ਨਿਗਰਾਨੀ ਏਜੰਟ ਦੇ ਵਿਵਹਾਰ ਦੀ ਨਕਲ ਕਰਕੇ ਲੋਡ ਕਰਦੇ ਹਾਂ, ਜੋ ਹਰ 15 ਸਕਿੰਟਾਂ ਵਿੱਚ ਇੱਕ ਵਾਰ ਹਰੇਕ ਮੀਟ੍ਰਿਕ ਨੂੰ ਮੁੱਲ ਭੇਜਦਾ ਹੈ। ਉਸੇ ਸਮੇਂ, ਅਸੀਂ ਵੱਖ-ਵੱਖ ਹੋਣ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਾਂ:

• ਮੈਟ੍ਰਿਕਸ ਦੀ ਕੁੱਲ ਸੰਖਿਆ ਜਿਸ ਵਿੱਚ ਡੇਟਾ ਲਿਖਿਆ ਗਿਆ ਹੈ;
• ਇੱਕ ਮੈਟ੍ਰਿਕ ਨੂੰ ਮੁੱਲ ਭੇਜਣ ਲਈ ਅੰਤਰਾਲ;
• ਬੈਚ ਦਾ ਆਕਾਰ.

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

ਨਾਲ ਹੀ, ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਫਿਰ ਪ੍ਰਾਪਤ ਕੀਤੇ ਡੇਟਾ ਦੀ ਵਿਆਖਿਆ ਕਿਵੇਂ ਕਰਨੀ ਹੈ, ਆਓ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਅਸੀਂ ਸਿਰਫ ਮੈਟ੍ਰਿਕਸ ਦਾ ਇੱਕ ਸਮੂਹ ਨਹੀਂ ਭੇਜ ਰਹੇ ਹਾਂ, ਪਰ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਸਰਵਰਾਂ ਵਿੱਚ ਸੰਗਠਿਤ ਕੀਤਾ ਗਿਆ ਹੈ - ਪ੍ਰਤੀ ਸਰਵਰ 125 ਮੀਟ੍ਰਿਕਸ. ਇੱਥੇ ਸਰਵਰ ਸਿਰਫ਼ ਇੱਕ ਵਰਚੁਅਲ ਇਕਾਈ ਹੈ - ਸਿਰਫ਼ ਇਹ ਸਮਝਣ ਲਈ, ਉਦਾਹਰਨ ਲਈ, 10000 ਮੈਟ੍ਰਿਕਸ ਲਗਭਗ 80 ਸਰਵਰਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ.

ਅਤੇ ਇੱਥੇ, ਇਸ ਸਭ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਸਾਡੇ 6 ਡੇਟਾਬੇਸ ਰਾਈਟ ਲੋਡ ਮੋਡ ਹਨ:

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

ਟੈਸਟ ਦੇ ਨਤੀਜੇ ਇਸ ਪ੍ਰਕਾਰ ਹਨ:

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

ਅੰਤ ਵਿੱਚ: ClickHouse ਅਤੇ InfluxDB ਨੇ ਆਪਣੇ ਆਪ ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਦਿਖਾਇਆ, ਪਰ Influx ਤੋਂ ਇੱਕ ਕਲੱਸਟਰ ਸਿਰਫ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸੰਸਕਰਣ ਦੇ ਅਧਾਰ 'ਤੇ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਪੈਸਾ ਖਰਚ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ClickHouse ਦੀ ਕੋਈ ਕੀਮਤ ਨਹੀਂ ਹੈ ਅਤੇ ਇਹ ਰੂਸ ਵਿੱਚ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਇਹ ਤਰਕਪੂਰਨ ਹੈ ਕਿ ਸੰਯੁਕਤ ਰਾਜ ਅਮਰੀਕਾ ਵਿੱਚ ਚੋਣ ਸ਼ਾਇਦ inInfluxDB ਦੇ ਹੱਕ ਵਿੱਚ ਹੈ, ਅਤੇ ਸਾਡੇ ਦੇਸ਼ ਵਿੱਚ ਇਹ ClickHouse ਦੇ ਹੱਕ ਵਿੱਚ ਹੈ।

ਸਰੋਤ: www.habr.com