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

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

ਗ੍ਰੇਫਾਈਟ + ਵਿਸਪਰ ਸਮੱਸਿਆਵਾਂ

1. ਡਿਸਕ ਸਬ-ਸਿਸਟਮ 'ਤੇ ਉੱਚ ਲੋਡ

ਪਰਿਵਰਤਨ ਦੇ ਸਮੇਂ, ਲਗਭਗ 1.5 ਮਿਲੀਅਨ ਮੀਟ੍ਰਿਕਸ ਪ੍ਰਤੀ ਮਿੰਟ ਸਾਡੇ ਕੋਲ ਆ ਰਹੇ ਸਨ। ਅਜਿਹੇ ਪ੍ਰਵਾਹ ਦੇ ਨਾਲ, ਸਰਵਰਾਂ 'ਤੇ ਡਿਸਕ ਦੀ ਵਰਤੋਂ ~30% ਸੀ। ਆਮ ਤੌਰ 'ਤੇ, ਇਹ ਕਾਫ਼ੀ ਸਵੀਕਾਰਯੋਗ ਸੀ - ਸਭ ਕੁਝ ਸਥਿਰਤਾ ਨਾਲ ਕੰਮ ਕਰਦਾ ਸੀ, ਤੇਜ਼ੀ ਨਾਲ ਲਿਖਿਆ ਜਾਂਦਾ ਸੀ, ਜਲਦੀ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਸੀ... ਜਦੋਂ ਤੱਕ ਵਿਕਾਸ ਟੀਮਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੇ ਇੱਕ ਨਵੀਂ ਵਿਸ਼ੇਸ਼ਤਾ ਤਿਆਰ ਨਹੀਂ ਕੀਤੀ ਅਤੇ ਸਾਨੂੰ ਪ੍ਰਤੀ ਮਿੰਟ 10 ਮਿਲੀਅਨ ਮੀਟ੍ਰਿਕਸ ਭੇਜਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਇਹ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਡਿਸਕ ਸਬ-ਸਿਸਟਮ ਸਖ਼ਤ ਹੋ ਗਿਆ ਸੀ, ਅਤੇ ਅਸੀਂ 100% ਉਪਯੋਗਤਾ ਦੇਖੀ। ਸਮੱਸਿਆ ਜਲਦੀ ਹੱਲ ਹੋ ਗਈ ਸੀ, ਪਰ ਇੱਕ ਰਹਿੰਦ-ਖੂੰਹਦ ਬਾਕੀ ਸੀ।

2. ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਅਤੇ ਇਕਸਾਰਤਾ ਦੀ ਘਾਟ

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

3. ਵੱਡੇ ਪੈਰਾਂ ਦੇ ਨਿਸ਼ਾਨ

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

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

ਉਪਰੋਕਤ ਸਾਰੇ ਹੋਣ (ਪਿਛਲੇ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਲੇਖ) ਦੇ ਨਾਲ ਨਾਲ ਪ੍ਰਾਪਤ ਕੀਤੇ ਮੈਟ੍ਰਿਕਸ ਦੀ ਗਿਣਤੀ ਵਿੱਚ ਲਗਾਤਾਰ ਵਾਧਾ, ਸਾਰੇ ਮੈਟ੍ਰਿਕਸ ਨੂੰ 30 ਸਕਿੰਟਾਂ ਦੇ ਸਟੋਰੇਜ ਅੰਤਰਾਲ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਦੀ ਇੱਛਾ. (ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ 10 ਸਕਿੰਟਾਂ ਤੱਕ), ਅਸੀਂ ਵਿਸਪਰ ਦੇ ਇੱਕ ਸ਼ਾਨਦਾਰ ਵਿਕਲਪ ਵਜੋਂ Graphite+ClickHouse ਨੂੰ ਅਜ਼ਮਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ।

ਗ੍ਰੇਫਾਈਟ+ਕਲਿੱਕਹਾਊਸ। ਉਮੀਦਾਂ

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

ਮੈਂ ਹੇਠ ਲਿਖਿਆਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹਾਂਗਾ:

• ਡਿਸਕ ਸਬ-ਸਿਸਟਮ ਉਪਯੋਗਤਾ ਨੂੰ 30% ਤੋਂ 5% ਤੱਕ ਘਟਾਓ;
• 1TB ਤੋਂ 100GB ਤੱਕ ਜਗ੍ਹਾ ਦੀ ਮਾਤਰਾ ਨੂੰ ਘਟਾਓ;
• ਸਰਵਰ ਵਿੱਚ ਪ੍ਰਤੀ ਮਿੰਟ 100 ਮਿਲੀਅਨ ਮੀਟ੍ਰਿਕਸ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ;
• ਬਾਕਸ ਦੇ ਬਾਹਰ ਡਾਟਾ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਅਤੇ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ;
• ਇੱਕ ਸਾਲ ਲਈ ਇਸ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਨਾ ਬੈਠੋ ਅਤੇ ਇੱਕ ਵਾਜਬ ਸਮਾਂ ਸੀਮਾ ਦੇ ਅੰਦਰ ਤਬਦੀਲੀ ਕਰੋ;
• ਡਾਊਨਟਾਈਮ ਤੋਂ ਬਿਨਾਂ ਸਵਿਚ ਕਰੋ।

ਕਾਫ਼ੀ ਅਭਿਲਾਸ਼ੀ, ਸੱਜਾ?

ਗ੍ਰੇਫਾਈਟ+ਕਲਿੱਕਹਾਊਸ। ਕੰਪੋਨੈਂਟਸ

ਗ੍ਰੇਫਾਈਟ ਪ੍ਰੋਟੋਕੋਲ ਦੁਆਰਾ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਇਸਨੂੰ ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਰਿਕਾਰਡ ਕਰਨ ਲਈ, ਮੈਂ ਚੁਣਿਆ ਕਾਰਬਨ-ਕਲਿੱਕਹਾਊਸ (ਗੋਲਾਂਗ)।

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

ਕਲਿਕਹਾਊਸ ਤੋਂ ਡਾਟਾ ਪੜ੍ਹਨ ਲਈ ਚੁਣਿਆ ਗਿਆ ਗ੍ਰੈਫਾਈਟ-ਸਲਿੱਕਹਾਊਸ (ਗੋਲਾਂਗ)। ਗ੍ਰੇਫਾਈਟ ਲਈ ਇੱਕ API ਦੇ ਰੂਪ ਵਿੱਚ - ਕਾਰਬੋਨਾਪੀ (ਗੋਲਾਂਗ)। ਕਲਿਕਹਾਊਸ ਦੀ ਵਰਤੋਂ ਟੇਬਲਾਂ ਵਿਚਕਾਰ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਲਈ ਕੀਤੀ ਗਈ ਸੀ ਚਿੜੀਆਘਰ. ਰੂਟਿੰਗ ਮੈਟ੍ਰਿਕਸ ਲਈ, ਅਸੀਂ ਆਪਣੇ ਪਿਆਰੇ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਕਾਰਬਨ-ਸੀ-ਰਿਲੇਅ (ਨਾਲ) (ਪਿਛਲਾ ਲੇਖ ਦੇਖੋ).

ਗ੍ਰੇਫਾਈਟ+ਕਲਿੱਕਹਾਊਸ। ਟੇਬਲ ਬਣਤਰ

"ਗ੍ਰੇਫਾਈਟ" ਇੱਕ ਡੇਟਾਬੇਸ ਹੈ ਜੋ ਅਸੀਂ ਨਿਗਰਾਨੀ ਟੇਬਲ ਲਈ ਬਣਾਇਆ ਹੈ।

“graphite.metrics” - ReplicatedReplacingMergeTree ਇੰਜਣ ਵਾਲੀ ਸਾਰਣੀ (ਦੁਹਰਾਈ ਗਈ MergeTree ਨੂੰ ਬਦਲਣਾ). ਇਹ ਸਾਰਣੀ ਮੈਟ੍ਰਿਕਸ ਦੇ ਨਾਮ ਅਤੇ ਉਹਨਾਂ ਦੇ ਮਾਰਗਾਂ ਨੂੰ ਸਟੋਰ ਕਰਦੀ ਹੈ।

CREATE TABLE graphite.metrics ( Date Date, Level UInt32, Path String, Deleted UInt8, Version UInt32 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.metrics', ‘r1’, Date, (Level, Path), 8192, Version);

“graphite.data” - ReplicatedGraphiteMergeTree ਇੰਜਣ ਵਾਲੀ ਸਾਰਣੀ (ਦੁਹਰਾਈ ਗਈ GraphiteMergeTree). ਇਹ ਸਾਰਣੀ ਮੀਟ੍ਰਿਕ ਮੁੱਲਾਂ ਨੂੰ ਸਟੋਰ ਕਰਦੀ ਹੈ।

CREATE TABLE graphite.data ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = ReplicatedGraphiteMergeTree('/clickhouse/tables/replicator/graphite.data', 'r1', Date, (Path, Time), 8192, 'graphite_rollup')

“graphite.date_metrics” ReplicatedReplacingMergeTree ਇੰਜਣ ਨਾਲ ਇੱਕ ਸ਼ਰਤ ਨਾਲ ਭਰੀ ਸਾਰਣੀ ਹੈ। ਇਹ ਸਾਰਣੀ ਦਿਨ ਦੇ ਦੌਰਾਨ ਆਈਆਂ ਸਾਰੀਆਂ ਮੈਟ੍ਰਿਕਸ ਦੇ ਨਾਮ ਦਰਜ ਕਰਦੀ ਹੈ। ਇਸ ਦੀ ਰਚਨਾ ਦੇ ਕਾਰਨ ਭਾਗ ਵਿੱਚ ਦੱਸੇ ਗਏ ਹਨ "ਸਮੱਸਿਆਵਾਂ" ਇਸ ਲੇਖ ਦੇ ਅੰਤ 'ਤੇ.

CREATE MATERIALIZED VIEW graphite.date_metrics ( Path String,  Level UInt32,  Date Date) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.date_metrics', 'r1', Date, (Level, Path, Date), 8192) AS SELECT toUInt32(length(splitByChar('.', Path))) AS Level, Date, Path FROM graphite.data

“graphite.data_stat” - ReplicatedAggregatingMergeTree ਇੰਜਣ (ਦੁਹਰਾਇਆ ਗਿਆ AggregatingMergeTree). ਇਹ ਸਾਰਣੀ ਆਉਣ ਵਾਲੇ ਮੈਟ੍ਰਿਕਸ ਦੀ ਸੰਖਿਆ ਨੂੰ ਰਿਕਾਰਡ ਕਰਦੀ ਹੈ, 4 ਆਲ੍ਹਣੇ ਦੇ ਪੱਧਰਾਂ ਵਿੱਚ ਵੰਡੀ ਜਾਂਦੀ ਹੈ।

CREATE MATERIALIZED VIEW graphite.data_stat ( Date Date,  Prefix String,  Timestamp UInt32,  Count AggregateFunction(count)) ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/replicator/graphite.data_stat', 'r1', Date, (Timestamp, Prefix), 8192) AS SELECT toStartOfMonth(now()) AS Date, replaceRegexpOne(Path, '^([^.]+.[^.]+.[^.]+).*$', '1') AS Prefix, toUInt32(toStartOfMinute(toDateTime(Timestamp))) AS Timestamp, countState() AS Count FROM graphite.data  GROUP BY Timestamp, Prefix

ਗ੍ਰੇਫਾਈਟ+ਕਲਿੱਕਹਾਊਸ। ਕੰਪੋਨੈਂਟ ਇੰਟਰੈਕਸ਼ਨ ਡਾਇਗਰਾਮ

ਗ੍ਰੇਫਾਈਟ+ਕਲਿੱਕਹਾਊਸ। ਡਾਟਾ ਮਾਈਗ੍ਰੇਸ਼ਨ

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

• ਕਲਿਕਹਾਊਸ ਟੇਬਲ ਦੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਵਿੱਚ ਹਿੱਸਾ ਲੈਣ ਵਾਲੇ ਸਰਵਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੇ ਕਾਰਬਨ-ਕਲਿੱਕਹਾਊਸ ਨੂੰ ਮੀਟ੍ਰਿਕਸ ਦੀ ਇੱਕ ਵਾਧੂ ਸਟ੍ਰੀਮ ਭੇਜਣ ਲਈ ਕਾਰਬਨ-ਸੀ-ਰੀਲੇ ਵਿੱਚ ਇੱਕ ਨਿਯਮ ਜੋੜਿਆ ਗਿਆ ਹੈ।

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

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

• ਬੈਲੇਂਸਰ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਰੀਡਿੰਗ ਲੋਡ ਨੂੰ ਬਦਲਣ ਲਈ, ਅਸੀਂ ਗ੍ਰੇਫਾਈਟ-ਏਪੀਆਈ (ਗ੍ਰੇਫਾਈਟ+ਵਿਸਪਰ ਲਈ API ਇੰਟਰਫੇਸ) ਤੋਂ ਕਾਰਬੋਨਾਪੀ ਵਿੱਚ ਅੰਤਮ ਬਿੰਦੂਆਂ ਨੂੰ ਬਦਲ ਦਿੱਤਾ ਹੈ।

ਗ੍ਰੇਫਾਈਟ+ਕਲਿੱਕਹਾਊਸ। ਨਤੀਜੇ

• ਡਿਸਕ ਸਬ-ਸਿਸਟਮ ਉਪਯੋਗਤਾ ਨੂੰ 30% ਤੋਂ ਘਟਾ ਕੇ 1%;

  

• 1 ਟੀਬੀ ਤੋਂ 300 ਜੀਬੀ ਤੱਕ ਘਟਾਈ ਗਈ ਜਗ੍ਹਾ ਦੀ ਮਾਤਰਾ ਨੂੰ ਘਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ;
• ਸਾਡੇ ਕੋਲ ਸਰਵਰ ਵਿੱਚ ਪ੍ਰਤੀ ਮਿੰਟ 125 ਮਿਲੀਅਨ ਮੀਟ੍ਰਿਕਸ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੈ (ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੇ ਸਮੇਂ ਸਿਖਰ);
• ਸਾਰੇ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਤੀਹ-ਸਕਿੰਟ ਸਟੋਰੇਜ ਅੰਤਰਾਲ ਵਿੱਚ ਤਬਦੀਲ ਕੀਤਾ;
• ਪ੍ਰਾਪਤ ਡੇਟਾ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਅਤੇ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ;
• ਡਾਊਨਟਾਈਮ ਤੋਂ ਬਿਨਾਂ ਬਦਲਿਆ;
• ਹਰ ਚੀਜ਼ ਨੂੰ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਲਗਭਗ 7 ਹਫ਼ਤੇ ਲੱਗ ਗਏ।

ਗ੍ਰੇਫਾਈਟ+ਕਲਿੱਕਹਾਊਸ। ਸਮੱਸਿਆਵਾਂ

ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਕੁਝ ਕਮੀਆਂ ਸਨ. ਇਹ ਉਹ ਹੈ ਜੋ ਅਸੀਂ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਸਾਹਮਣਾ ਕੀਤਾ।

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

   url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"

3. ਕਲਿਕਹਾਊਸ ਅਕਸਰ ਸਥਿਰ ਰੀਲੀਜ਼ਾਂ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣਾਂ ਨੂੰ ਜਾਰੀ ਕਰਦਾ ਹੈ; ਉਹਨਾਂ ਵਿੱਚ ਹੈਰਾਨੀ ਹੋ ਸਕਦੀ ਹੈ: ਸਾਵਧਾਨ ਰਹੋ।
4. ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਬਣਾਏ ਗਏ ਕੰਟੇਨਰ ਇੱਕ ਛੋਟੇ ਅਤੇ ਬੇਤਰਤੀਬ ਜੀਵਨ ਕਾਲ ਦੇ ਨਾਲ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਮੈਟ੍ਰਿਕਸ ਭੇਜਦੇ ਹਨ। ਅਜਿਹੇ ਮੈਟ੍ਰਿਕਸ ਲਈ ਬਹੁਤ ਸਾਰੇ ਪੁਆਇੰਟ ਨਹੀਂ ਹਨ, ਅਤੇ ਸਪੇਸ ਨਾਲ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ. ਪਰ ਜਦੋਂ ਸਵਾਲਾਂ ਦਾ ਨਿਰਮਾਣ ਕਰਦੇ ਹੋ, ਤਾਂ ਕਲਿਕਹਾਊਸ 'ਮੈਟ੍ਰਿਕਸ' ਟੇਬਲ ਤੋਂ ਇਹਨਾਂ ਸਮਾਨ ਮੈਟ੍ਰਿਕਸ ਦੀ ਇੱਕ ਵੱਡੀ ਗਿਣਤੀ ਨੂੰ ਚੁਣਦਾ ਹੈ। 90% ਮਾਮਲਿਆਂ ਵਿੱਚ, ਵਿੰਡੋ (24 ਘੰਟੇ) ਤੋਂ ਬਾਹਰ ਉਹਨਾਂ 'ਤੇ ਕੋਈ ਡਾਟਾ ਨਹੀਂ ਹੈ। ਪਰ 'ਡੇਟਾ' ਸਾਰਣੀ ਵਿੱਚ ਇਸ ਡੇਟਾ ਨੂੰ ਖੋਜਣ ਵਿੱਚ ਸਮਾਂ ਬਿਤਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਇੱਕ ਸਮਾਂ ਸਮਾਪਤ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਅਸੀਂ ਦਿਨ ਦੇ ਦੌਰਾਨ ਆਈਆਂ ਮੈਟ੍ਰਿਕਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਦੇ ਨਾਲ ਇੱਕ ਵੱਖਰਾ ਨਜ਼ਰੀਆ ਰੱਖਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਇਸ ਤਰ੍ਹਾਂ, ਜਦੋਂ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਬਣਾਏ ਗਏ ਕੰਟੇਨਰਾਂ ਲਈ ਰਿਪੋਰਟਾਂ (ਗ੍ਰਾਫ਼) ਬਣਾਉਂਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਸਿਰਫ਼ ਉਹਨਾਂ ਮੈਟ੍ਰਿਕਸ ਦੀ ਪੁੱਛਗਿੱਛ ਕਰਦੇ ਹਾਂ ਜੋ ਕਿਸੇ ਦਿੱਤੇ ਵਿੰਡੋ ਦੇ ਅੰਦਰ ਆਈਆਂ ਸਨ, ਨਾ ਕਿ ਪੂਰੇ ਸਮੇਂ ਲਈ, ਜਿਸ ਨੇ ਉਹਨਾਂ 'ਤੇ ਰਿਪੋਰਟਾਂ ਦੇ ਨਿਰਮਾਣ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਕੀਤਾ ਹੈ। ਉੱਪਰ ਦੱਸੇ ਗਏ ਹੱਲ ਲਈ, ਮੈਂ ਇਕੱਠਾ ਕੀਤਾ ਗ੍ਰੈਫਾਈਟ-ਕਲਿਕਹਾਊਸ (ਕਾਂਟਾ), ਜਿਸ ਵਿੱਚ date_metrics ਟੇਬਲ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨਾ ਸ਼ਾਮਲ ਹੈ।

ਗ੍ਰੇਫਾਈਟ+ਕਲਿੱਕਹਾਊਸ। ਟੈਗਸ

ਸੰਸਕਰਣ 1.1.0 ਦੇ ਨਾਲ ਗ੍ਰੇਫਾਈਟ ਅਧਿਕਾਰਤ ਬਣ ਗਿਆ ਸਮਰਥਨ ਟੈਗ. ਅਤੇ ਅਸੀਂ ਸਰਗਰਮੀ ਨਾਲ ਇਸ ਬਾਰੇ ਸੋਚ ਰਹੇ ਹਾਂ ਕਿ ਗ੍ਰੇਫਾਈਟ+ਕਲਿਕਹਾਊਸ ਸਟੈਕ ਵਿੱਚ ਇਸ ਪਹਿਲਕਦਮੀ ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ ਕੀ ਅਤੇ ਕਿਵੇਂ ਕਰਨਾ ਹੈ।

ਗ੍ਰੇਫਾਈਟ+ਕਲਿੱਕਹਾਊਸ। ਅਨੌਮਲੀ ਡਿਟੈਕਟਰ

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

ਗਾਹਕ ਬਣੋ, ਉੱਪਰ ਤੀਰ ਨੂੰ ਦਬਾਓ ਅਤੇ ਖੁਸ਼ ਰਹੋ!

ਸਰੋਤ: www.habr.com