ਉੱਚ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਨੇਟਿਵ ਵਿਭਾਗੀਕਰਨ: TimescaleDB ਸਹਿਯੋਗ ਨਾਲ ਜ਼ੈਬਿਕਸ

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

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

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

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

ਉਤਪਾਦਕਤਾ ਚੁਣੌਤੀਆਂ

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

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

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

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

ਪੁਰਾਣੇ ਡੇਟਾ ਨੂੰ ਸਾਫ਼ ਕਰਨਾ ਇੱਕ ਨਾਜ਼ੁਕ ਮੁੱਦਾ ਹੈ ਜੋ ਡੇਟਾਬੇਸ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਬਹੁਤ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।

ਜ਼ੈਬਿਕਸ ਵਿੱਚ ਕੈਚਿੰਗ

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

ਜ਼ੈਬਿਕਸ ਸਰਵਰ ਦੇ ਸਾਈਡ 'ਤੇ ਕੈਚਿੰਗ ਆਪਣੇ ਆਪ ਹੈ:

• ਸੰਰਚਨਾ ਕੈਚ;
• ValueCache;
• ਇਤਿਹਾਸ ਕੈਸ਼;
• TrendsCache.

ਆਓ ਉਨ੍ਹਾਂ ਨੂੰ ਵਧੇਰੇ ਵਿਸਥਾਰ ਨਾਲ ਵਿਚਾਰੀਏ.

ਕੌਂਫਿਗਰੇਸ਼ਨ ਕੈਚ

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

ਇਹ ਸਭ ConfigurationCache ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਜੋ ਡੇਟਾਬੇਸ ਵਿੱਚ ਬੇਲੋੜੀ ਪੁੱਛਗਿੱਛ ਨਾ ਕੀਤੀ ਜਾ ਸਕੇ। ਸਰਵਰ ਚਾਲੂ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਇਸ ਕੈਸ਼ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦੇ ਹਾਂ, ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਸੰਰਚਨਾਵਾਂ ਬਣਾਉਂਦੇ ਅਤੇ ਅੱਪਡੇਟ ਕਰਦੇ ਹਾਂ।

ਡਾਟਾ ਇਕੱਠਾ ਕਰਨ

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

ਕੁਲੈਕਟਰਾਂ ਨੂੰ ਸੰਤਰੀ ਵਿੱਚ ਦਰਸਾਇਆ ਗਿਆ ਹੈ।

ਜ਼ੈਬਿਕਸ ਨੇ ਐਗਰੀਗੇਸ਼ਨ ਆਈਟਮਾਂ ਦੀ ਗਣਨਾ ਕੀਤੀ ਹੈ ਜੋ ਕਿ ਐਗਰੀਗੇਟ ਚੈਕਾਂ ਲਈ ਲੋੜੀਂਦੀਆਂ ਹਨ। ਜੇਕਰ ਸਾਡੇ ਕੋਲ ਉਹ ਹਨ, ਤਾਂ ਅਸੀਂ ਉਹਨਾਂ ਲਈ ਸਿੱਧਾ ValueCache ਤੋਂ ਡੇਟਾ ਲਿਆਉਂਦੇ ਹਾਂ।

ਪ੍ਰੀ-ਪ੍ਰੋਸੈਸਿੰਗ ਹਿਸਟਰੀ ਕੈਚ

ਸਾਰੇ ਕੁਲੈਕਟਰ ਨੌਕਰੀਆਂ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ConfigurationCache ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਫਿਰ ਉਹ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰੀਪ੍ਰੋਸੈਸਿੰਗ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕਰਦੇ ਹਨ।

ਪ੍ਰੀਪ੍ਰੋਸੈਸਿੰਗ ਪ੍ਰੀਪ੍ਰੋਸੈਸਿੰਗ ਕਦਮਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕੌਂਫਿਗਰੇਸ਼ਨ ਕੈਚ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਇਹ ਇਸ ਡੇਟਾ ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹੈ।

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

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

ValueCache, ਇਤਿਹਾਸ ਅਤੇ ਰੁਝਾਨ ਕੈਸ਼

ਹਿਸਟਰੀ ਸਿੰਸਰ ਇੱਕ ਮੁੱਖ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜੋ ਹਰ ਇੱਕ ਡੇਟਾ ਤੱਤ, ਯਾਨੀ ਹਰੇਕ ਮੁੱਲ ਨੂੰ ਪ੍ਰਮਾਣੂ ਰੂਪ ਵਿੱਚ ਪ੍ਰੋਸੈਸ ਕਰਦੀ ਹੈ।

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

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

ਹਿਸਟਰੀ ਸਿੰਸਰ ਸਾਰੇ ਡੇਟਾ ਨੂੰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਲਿਖਦਾ ਹੈ, ਅਤੇ ਇਹ ਡਿਸਕ ਤੇ ਲਿਖਦਾ ਹੈ। ਪ੍ਰੋਸੈਸਿੰਗ ਪ੍ਰਕਿਰਿਆ ਇੱਥੇ ਖਤਮ ਹੁੰਦੀ ਹੈ।

ਡਾਟਾਬੇਸ ਵਿੱਚ ਕੈਸ਼ਿੰਗ

ਡੇਟਾਬੇਸ ਵਾਲੇ ਪਾਸੇ ਕਈ ਕੈਚ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਇਵੈਂਟਾਂ 'ਤੇ ਗ੍ਰਾਫ ਜਾਂ ਰਿਪੋਰਟਾਂ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ:

• Innodb_buffer_pool MySQL ਪਾਸੇ;
• shared_buffers PostgreSQL ਪਾਸੇ;
• effective_cache_size ਓਰੇਕਲ ਵਾਲੇ ਪਾਸੇ;
• shared_pool DB2 ਪਾਸੇ.

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

ਡਾਟਾਬੇਸ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨਾਜ਼ੁਕ ਹੈ

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

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

ਸਫ਼ਾਈ

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

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

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

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

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

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

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

ਵਿਭਾਜਨ - ਭਾਗ ਜਾਂ ਵਿਭਾਗੀਕਰਨ

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

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

ਮੁੱਲ ਬਦਲ ਸਕਦੇ ਹਨ ਜੇਕਰ "ਸੈਟਅੱਪ" ਬਹੁਤ ਵੱਡਾ ਹੈ। ਜੇ ਇੱਕ ਛੋਟਾ "ਸੈਟਅੱਪ" 5 nvps (ਨਵੇਂ ਮੁੱਲ ਪ੍ਰਤੀ ਸਕਿੰਟ) ਤੱਕ ਹੈ, ਇੱਕ ਮੱਧਮ ਇੱਕ 000 ਤੋਂ 5 ਤੱਕ ਹੈ, ਫਿਰ ਇੱਕ ਵੱਡਾ 000 nvps ਤੋਂ ਉੱਪਰ ਹੈ। ਇਹ ਵੱਡੀਆਂ ਅਤੇ ਬਹੁਤ ਵੱਡੀਆਂ ਸਥਾਪਨਾਵਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਲਈ ਡੇਟਾਬੇਸ ਦੀ ਧਿਆਨ ਨਾਲ ਸੰਰਚਨਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਬਹੁਤ ਵੱਡੀਆਂ ਸਥਾਪਨਾਵਾਂ 'ਤੇ, ਇੱਕ ਦਿਨ ਦੀ ਮਿਆਦ ਅਨੁਕੂਲ ਨਹੀਂ ਹੋ ਸਕਦੀ ਹੈ। ਮੈਂ ਪ੍ਰਤੀ ਦਿਨ 40 GB ਜਾਂ ਵੱਧ ਦੇ MySQL ਭਾਗ ਦੇਖੇ ਹਨ। ਇਹ ਡਾਟਾ ਦੀ ਇੱਕ ਬਹੁਤ ਵੱਡੀ ਮਾਤਰਾ ਹੈ ਜੋ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਇਸਨੂੰ ਘਟਾਉਣ ਦੀ ਲੋੜ ਹੈ।

ਵਿਭਾਗੀਕਰਨ ਕੀ ਦਿੰਦਾ ਹੈ?

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

ਤੁਰੰਤ ਹਟਾਉਣਾ - DELETE. ਮਿਟਾਉਣ ਲਈ ਕਤਾਰਾਂ ਦੀ ਚੋਣ ਦੀ ਬਜਾਏ ਇੱਕ ਫਾਈਲ/ਉਪ-ਸਾਰਣੀ ਚੁਣੀ ਗਈ ਹੈ।

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

ਅਕਸਰ ਕਈ ਡਾਟਾਬੇਸ ਵੀ ਤੇਜ਼ ਹੁੰਦੇ ਹਨ INSERT - ਚਾਈਲਡ ਟੇਬਲ ਵਿੱਚ ਸੰਮਿਲਨ।

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

v 4.2 ਲਈ, ਅਸੀਂ TimescaleDB ਵੱਲ ਧਿਆਨ ਦਿੱਤਾ। ਇਹ ਨੇਟਿਵ ਇੰਟਰਫੇਸ ਦੇ ਨਾਲ PostgreSQL ਲਈ ਇੱਕ ਐਕਸਟੈਂਸ਼ਨ ਹੈ। ਐਕਸਟੈਂਸ਼ਨ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਦੇ ਲਾਭਾਂ ਨੂੰ ਗੁਆਏ ਬਿਨਾਂ, ਟਾਈਮ ਸੀਰੀਜ਼ ਡੇਟਾ ਦੇ ਨਾਲ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ। TimescaleDB ਵੀ ਆਪਣੇ ਆਪ ਭਾਗ ਕਰਦਾ ਹੈ।

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

TimescaleDB ਬਨਾਮ PostgreSQL

TimescaleDB ਅਸਲ ਵਿੱਚ ਕੁਸ਼ਲਤਾ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ. ਐਕਸਟੈਂਸ਼ਨ ਦੇ ਨਿਰਮਾਤਾ ਦਾਅਵਾ ਕਰਦੇ ਹਨ ਕਿ ਉਹ ਖਾਸ inserts ਵਿੱਚ, ਇੱਕ ਵਧੇਰੇ ਸਹੀ ਪੁੱਛਗਿੱਛ ਪ੍ਰੋਸੈਸਿੰਗ ਐਲਗੋਰਿਦਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਜਿਵੇਂ ਕਿ ਡੇਟਾਸੇਟ ਸੰਮਿਲਿਤ ਕਰਨ ਦਾ ਆਕਾਰ ਵਧਦਾ ਹੈ, ਐਲਗੋਰਿਦਮ ਨਿਰੰਤਰ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਕਾਇਮ ਰੱਖਦਾ ਹੈ।

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

ਸੈਟਿੰਗ

ਟਾਈਮਸਕੇਲਡੀਬੀ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨਾ ਕਿਸੇ ਵੀ ਪੈਕੇਜ ਲਈ ਕਾਫ਼ੀ ਆਸਾਨ ਹੈ. IN ਦਸਤਾਵੇਜ਼ ਸਭ ਕੁਝ ਵਿਸਥਾਰ ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ - ਇਹ ਅਧਿਕਾਰਤ PostgreSQL ਪੈਕੇਜਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। TimescaleDB ਨੂੰ ਹੱਥੀਂ ਵੀ ਬਣਾਇਆ ਅਤੇ ਕੰਪਾਇਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਜ਼ੈਬਿਕਸ ਡੇਟਾਬੇਸ ਲਈ ਅਸੀਂ ਸਿਰਫ਼ ਐਕਸਟੈਂਸ਼ਨ ਨੂੰ ਸਰਗਰਮ ਕਰਦੇ ਹਾਂ:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

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

ਇਤਿਹਾਸ ਟੇਬਲ ਨੂੰ TimescaleDB ਵਿੱਚ ਮਾਈਗਰੇਟ ਕਰਨਾ

ਇਸਦੇ ਲਈ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਫੰਕਸ਼ਨ ਹੈ create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

ਫੰਕਸ਼ਨ ਦੇ ਤਿੰਨ ਪੈਰਾਮੀਟਰ ਹਨ। ਪਹਿਲਾਂ - ਡਾਟਾਬੇਸ ਵਿੱਚ ਸਾਰਣੀ, ਜਿਸ ਲਈ ਤੁਹਾਨੂੰ ਇੱਕ ਹਾਈਪਰਟੇਬਲ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਦੂਜਾ - ਫੀਲਡ, ਜਿਸ ਅਨੁਸਾਰ ਤੁਹਾਨੂੰ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ chunk_time_interval — ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਭਾਗ ਭਾਗਾਂ ਦਾ ਅੰਤਰਾਲ। ਮੇਰੇ ਕੇਸ ਵਿੱਚ, ਅੰਤਰਾਲ ਇੱਕ ਦਿਨ ਹੈ - 86.

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

ਆਖਰੀ ਕਦਮ - UPDATE: ਤੇ db_extension ਪਾਓ timescaledbਤਾਂ ਜੋ ਡੇਟਾਬੇਸ ਸਮਝ ਸਕੇ ਕਿ ਇਹ ਐਕਸਟੈਂਸ਼ਨ ਮੌਜੂਦ ਹੈ। ਜ਼ੈਬਿਕਸ ਇਸਨੂੰ ਸਰਗਰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਡਾਟਾਬੇਸ ਲਈ ਸੰਟੈਕਸ ਅਤੇ ਸਵਾਲਾਂ ਦੀ ਸਹੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ - ਉਹ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜੋ TimescaleDB ਲਈ ਜ਼ਰੂਰੀ ਹਨ।

ਹਾਰਡਵੇਅਰ ਸੰਰਚਨਾ

ਮੈਂ ਦੋ ਸਰਵਰ ਵਰਤੇ। ਪਹਿਲਾਂ - VMware ਮਸ਼ੀਨ. ਇਹ ਕਾਫ਼ੀ ਛੋਟਾ ਹੈ: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz ਪ੍ਰੋਸੈਸਰ, 16 GB RAM ਅਤੇ ਇੱਕ 200 GB SSD।

ਮੈਂ ਇਸ 'ਤੇ ਡੇਬੀਅਨ 10.8-10.8.pgdg1+90 OS ਅਤੇ xfs ਫਾਈਲ ਸਿਸਟਮ ਨਾਲ PostgreSQL 1 ਸਥਾਪਤ ਕੀਤਾ ਹੈ। ਮੈਂ ਇਸ ਖਾਸ ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਹਰ ਚੀਜ਼ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਕੌਂਫਿਗਰ ਕੀਤਾ ਹੈ, ਜੋ ਜ਼ੈਬਿਕਸ ਖੁਦ ਵਰਤੇਗਾ।

ਉਸੇ ਮਸ਼ੀਨ 'ਤੇ ਜ਼ੈਬਿਕਸ ਸਰਵਰ, PostgreSQL ਅਤੇ ਸੀ ਲੋਡ ਏਜੰਟ. ਮੇਰੇ ਕੋਲ 50 ਸਰਗਰਮ ਏਜੰਟ ਸਨ ਜੋ ਵਰਤ ਰਹੇ ਸਨ LoadableModuleਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਵੱਖ-ਵੱਖ ਨਤੀਜੇ ਪੈਦਾ ਕਰਨ ਲਈ: ਨੰਬਰ, ਸਤਰ। ਮੈਂ ਡੇਟਾਬੇਸ ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਡੇਟਾ ਨਾਲ ਭਰਿਆ.

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

ਡਾਟਾ ਆਈਟਮ ਅੱਪਡੇਟ ਅੰਤਰਾਲ - 4-7 ਸਕਿੰਟ. ਮੈਂ ਨਾ ਸਿਰਫ਼ 50 ਏਜੰਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਸਗੋਂ ਹੋਰ ਜੋੜ ਕੇ ਲੋਡ ਨੂੰ ਖੁਦ ਨਿਯੰਤ੍ਰਿਤ ਕੀਤਾ। ਨਾਲ ਹੀ, ਡੇਟਾ ਐਲੀਮੈਂਟਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਮੈਂ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਲੋਡ ਨੂੰ ਐਡਜਸਟ ਕੀਤਾ ਅਤੇ ਅਪਡੇਟ ਅੰਤਰਾਲ ਨੂੰ 4 ਸਕਿੰਟ ਤੱਕ ਘਟਾ ਦਿੱਤਾ।

PostgreSQL। 35 ਐੱਨ.ਵੀ.ਪੀ.ਐੱਸ

ਇਸ ਹਾਰਡਵੇਅਰ 'ਤੇ ਮੇਰੀ ਪਹਿਲੀ ਦੌੜ ਸ਼ੁੱਧ PostgreSQL 'ਤੇ ਸੀ - 35 ਹਜ਼ਾਰ ਮੁੱਲ ਪ੍ਰਤੀ ਸਕਿੰਟ. ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ, ਡੇਟਾ ਨੂੰ ਸੰਮਿਲਿਤ ਕਰਨ ਵਿੱਚ ਇੱਕ ਸਕਿੰਟ ਦੇ ਅੰਸ਼ ਲੱਗਦੇ ਹਨ - ਸਭ ਕੁਝ ਵਧੀਆ ਅਤੇ ਤੇਜ਼ ਹੈ। ਸਿਰਫ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇੱਕ 200 GB SSD ਡਿਸਕ ਤੇਜ਼ੀ ਨਾਲ ਭਰ ਜਾਂਦੀ ਹੈ.

ਇਹ ਇੱਕ ਮਿਆਰੀ ਜ਼ੈਬਿਕਸ ਸਰਵਰ ਪ੍ਰਦਰਸ਼ਨ ਡੈਸ਼ਬੋਰਡ ਹੈ।

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

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

PostgreSQL। 50 ਐੱਨ.ਵੀ.ਪੀ.ਐੱਸ

ਫਿਰ ਮੈਂ ਉਸੇ ਹਾਰਡਵੇਅਰ 'ਤੇ ਲੋਡ ਨੂੰ 50 ਹਜ਼ਾਰ ਮੁੱਲ ਪ੍ਰਤੀ ਸਕਿੰਟ ਤੱਕ ਵਧਾ ਦਿੱਤਾ।

ਹਾਊਸਕੀਪਰ ਤੋਂ ਲੋਡ ਕਰਨ ਵੇਲੇ, 10 ਹਜ਼ਾਰ ਮੁੱਲ ਪਾਉਣ ਵਿੱਚ 2-3 ਸਕਿੰਟ ਲੱਗ ਗਏ।

ਹਾਊਸਕੀਪਰ ਪਹਿਲਾਂ ਹੀ ਕੰਮ ਵਿੱਚ ਦਖਲ ਦੇਣ ਲੱਗ ਪਿਆ ਹੈ।

ਤੀਜਾ ਗ੍ਰਾਫ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ, ਆਮ ਤੌਰ 'ਤੇ, ਟ੍ਰੈਪਰ ਅਤੇ ਹਿਸਟਰੀ ਸਿੰਕਰਾਂ 'ਤੇ ਲੋਡ ਅਜੇ ਵੀ 60% ਹੈ। ਚੌਥੇ ਗ੍ਰਾਫ਼ ਵਿੱਚ, HistoryCache ਪਹਿਲਾਂ ਹੀ ਹਾਊਸਕੀਪਰ ਓਪਰੇਸ਼ਨ ਦੌਰਾਨ ਕਾਫ਼ੀ ਸਰਗਰਮੀ ਨਾਲ ਭਰਨਾ ਸ਼ੁਰੂ ਕਰ ਰਿਹਾ ਹੈ। ਇਹ 20% ਭਰਿਆ ਹੋਇਆ ਹੈ, ਜੋ ਕਿ ਲਗਭਗ 0,5 GB ਹੈ।

PostgreSQL। 80 ਐੱਨ.ਵੀ.ਪੀ.ਐੱਸ

ਫਿਰ ਮੈਂ ਲੋਡ ਨੂੰ 80 ਹਜ਼ਾਰ ਮੁੱਲ ਪ੍ਰਤੀ ਸਕਿੰਟ ਤੱਕ ਵਧਾ ਦਿੱਤਾ. ਇਹ ਲਗਭਗ 400 ਹਜ਼ਾਰ ਡੇਟਾ ਐਲੀਮੈਂਟਸ ਅਤੇ 280 ਹਜ਼ਾਰ ਟਰਿਗਰ ਹਨ।

ਤੀਹ ਹਿਸਟਰੀ ਸਿੰਕਰਾਂ ਦੀ ਲੋਡਿੰਗ ਲਾਗਤ ਪਹਿਲਾਂ ਹੀ ਕਾਫੀ ਜ਼ਿਆਦਾ ਹੈ।

ਮੈਂ ਵੱਖ-ਵੱਖ ਮਾਪਦੰਡ ਵੀ ਵਧਾਏ ਹਨ: ਇਤਿਹਾਸ ਸਿੰਕਰ, ਕੈਚ.

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

ਇਸ ਸਾਰੇ ਸਮੇਂ ਵਿੱਚ ਮੈਂ ਦੇਖਿਆ ਕਿ ਪ੍ਰੋਸੈਸਰ, ਰੈਮ ਅਤੇ ਹੋਰ ਸਿਸਟਮ ਪੈਰਾਮੀਟਰ ਕਿਵੇਂ ਵਰਤੇ ਗਏ ਸਨ, ਅਤੇ ਪਾਇਆ ਕਿ ਡਿਸਕ ਦੀ ਵਰਤੋਂ ਇਸਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਸੀ।

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

ਦੂਜਾ ਸਰਵਰ

ਮੈਂ ਇੱਕ ਹੋਰ ਸਰਵਰ ਲਿਆ, ਜਿਸ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ 48 ਪ੍ਰੋਸੈਸਰ ਅਤੇ 128 GB RAM ਸੀ। ਮੈਂ ਇਸਨੂੰ ਟਿਊਨ ਕੀਤਾ - ਇਸਨੂੰ 60 ਹਿਸਟਰੀ ਸਿੰਸਰ 'ਤੇ ਸੈੱਟ ਕੀਤਾ, ਅਤੇ ਸਵੀਕਾਰਯੋਗ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਾਪਤ ਕੀਤਾ।

ਵਾਸਤਵ ਵਿੱਚ, ਇਹ ਪਹਿਲਾਂ ਹੀ ਉਤਪਾਦਕਤਾ ਦੀ ਸੀਮਾ ਹੈ ਜਿੱਥੇ ਕੁਝ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ.

ਟਾਈਮਸਕੇਲDB। 80 ਐੱਨ.ਵੀ.ਪੀ.ਐੱਸ

ਮੇਰਾ ਮੁੱਖ ਕੰਮ ਜ਼ੈਬਿਕਸ ਲੋਡ ਦੇ ਵਿਰੁੱਧ TimescaleDB ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਦੀ ਜਾਂਚ ਕਰਨਾ ਹੈ. 80 ਹਜ਼ਾਰ ਮੁੱਲ ਪ੍ਰਤੀ ਸਕਿੰਟ ਬਹੁਤ ਹੈ, ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਦੀ ਬਾਰੰਬਾਰਤਾ (ਯੈਂਡੇਕਸ ਨੂੰ ਛੱਡ ਕੇ, ਬੇਸ਼ਕ) ਅਤੇ ਇੱਕ ਕਾਫ਼ੀ ਵੱਡਾ "ਸੈਟਅੱਪ" ਹੈ.

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

TimescaleDB ਤੁਹਾਨੂੰ ਲਗਭਗ 3 ਗੁਣਾ ਤੇਜ਼ੀ ਨਾਲ ਡਾਟਾ ਸੰਮਿਲਿਤ ਕਰਨ ਅਤੇ ਘੱਟ HistoryCache ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਇਸ ਅਨੁਸਾਰ, ਤੁਹਾਨੂੰ ਸਮੇਂ ਸਿਰ ਡਾਟਾ ਪ੍ਰਾਪਤ ਹੋਵੇਗਾ।

ਟਾਈਮਸਕੇਲDB। 120 ਐੱਨ.ਵੀ.ਪੀ.ਐੱਸ

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

ਇਹ ਇੱਕ ਕਾਰਜਸ਼ੀਲ "ਸੈਟਅੱਪ" ਹੈ ਜੋ ਲੰਬੇ ਸਮੇਂ ਲਈ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ। ਪਰ ਕਿਉਂਕਿ ਮੇਰੀ ਡਿਸਕ ਸਿਰਫ 1,5 ਟੀਬੀ ਸੀ, ਮੈਂ ਇਸਨੂੰ ਕੁਝ ਦਿਨਾਂ ਵਿੱਚ ਭਰ ਲਿਆ।

ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਉਸੇ ਸਮੇਂ ਨਵੇਂ TimescaleDB ਭਾਗ ਬਣਾਏ ਗਏ ਸਨ।

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

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

ਸਿੱਟਾ

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

TimescaleDB ਕੌਂਫਿਗਰ ਕਰਨਾ ਆਸਾਨ ਹੈ, ਪ੍ਰਦਰਸ਼ਨ ਲਾਭ ਦਿੰਦਾ ਹੈ, ਜ਼ੈਬਿਕਸ ਅਤੇ ਨਾਲ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ PostgreSQL ਉੱਤੇ ਫਾਇਦੇ ਹਨ.

ਜੇ ਤੁਸੀਂ PostgreSQL ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ ਅਤੇ ਇਸਨੂੰ ਬਦਲਣ ਦੀ ਯੋਜਨਾ ਨਹੀਂ ਬਣਾਉਂਦੇ, ਤਾਂ ਮੈਂ ਸਿਫ਼ਾਰਿਸ਼ ਕਰਦਾ ਹਾਂ Zabbix ਦੇ ਨਾਲ TimescaleDB ਐਕਸਟੈਂਸ਼ਨ ਦੇ ਨਾਲ PostgreSQL ਦੀ ਵਰਤੋਂ ਕਰੋ. ਇਹ ਹੱਲ ਇੱਕ ਮੱਧਮ "ਸੈਟਅੱਪ" ਤੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ।

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

ਸਾਡੇ ਲਈ ਗਾਹਕ ਬਣੋ ылку и ਤਾਰ, ਜਿਸ ਵਿੱਚ ਅਸੀਂ ਆਗਾਮੀ ਕਾਨਫਰੰਸ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਖੁਲਾਸਾ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਇਹ ਪਤਾ ਲਗਾਉਂਦੇ ਹਾਂ ਕਿ ਇਸਦਾ ਵੱਧ ਤੋਂ ਵੱਧ ਲਾਭ ਕਿਵੇਂ ਲੈਣਾ ਹੈ।

ਸਰੋਤ: www.habr.com