ਹਾਈਲੋਡ++, ਐਂਡਰੀ ਗੁਸ਼ਚਿਨ (ਜ਼ੈਬਿਕਸ): ਉੱਚ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਮੂਲ ਵਿਭਾਗੀਕਰਨ

ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ Zabbix ਬੈਕਐਂਡ ਵਜੋਂ TimescaleDB ਡੇਟਾਬੇਸ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਤੁਹਾਨੂੰ ਦਿਖਾਵਾਂਗੇ ਕਿ ਕਿਵੇਂ ਸ਼ੁਰੂ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ ਅਤੇ PostgreSQL ਤੋਂ ਕਿਵੇਂ ਮਾਈਗਰੇਟ ਕਰਨਾ ਹੈ। ਅਸੀਂ ਦੋ ਸੰਰਚਨਾਵਾਂ ਦੇ ਤੁਲਨਾਤਮਕ ਪ੍ਰਦਰਸ਼ਨ ਟੈਸਟ ਵੀ ਪ੍ਰਦਾਨ ਕਰਾਂਗੇ।

ਹਾਈਲੋਡ++ ਸਾਇਬੇਰੀਆ 2019. ਟਾਮਸਕ ਹਾਲ। ਜੂਨ 24, 16:00. ਥੀਸਸ ਅਤੇ ਪੇਸ਼ਕਾਰੀ. ਅਗਲੀ ਹਾਈਲੋਡ++ ਕਾਨਫਰੰਸ 6 ਅਤੇ 7 ਅਪ੍ਰੈਲ, 2020 ਨੂੰ ਸੇਂਟ ਪੀਟਰਸਬਰਗ ਵਿੱਚ ਹੋਵੇਗੀ। ਵੇਰਵੇ ਅਤੇ ਟਿਕਟਾਂ ਲਿੰਕ.

ਐਂਡਰੀ ਗੁਸ਼ਚਿਨ (ਇਸ ਤੋਂ ਬਾਅਦ - ਏਜੀ): - ਮੈਂ ਇੱਕ ZABBIX ਤਕਨੀਕੀ ਸਹਾਇਤਾ ਇੰਜੀਨੀਅਰ (ਇਸ ਤੋਂ ਬਾਅਦ "Zabbix" ਵਜੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ), ਇੱਕ ਟ੍ਰੇਨਰ ਹਾਂ। ਮੈਂ 6 ਸਾਲਾਂ ਤੋਂ ਵੱਧ ਸਮੇਂ ਤੋਂ ਤਕਨੀਕੀ ਸਹਾਇਤਾ ਵਿੱਚ ਕੰਮ ਕਰ ਰਿਹਾ ਹਾਂ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਦਾ ਸਿੱਧਾ ਤਜਰਬਾ ਹੈ। ਅੱਜ ਮੈਂ ਉਸ ਪ੍ਰਦਰਸ਼ਨ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ ਜੋ TimescaleDB ਨਿਯਮਤ PostgreSQL 10 ਦੇ ਮੁਕਾਬਲੇ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦਾ ਹੈ। ਨਾਲ ਹੀ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਇਸ ਬਾਰੇ ਕੁਝ ਸ਼ੁਰੂਆਤੀ ਹਿੱਸਾ।

ਪ੍ਰਮੁੱਖ ਉਤਪਾਦਕਤਾ ਚੁਣੌਤੀਆਂ: ਡੇਟਾ ਸੰਗ੍ਰਹਿ ਤੋਂ ਡੇਟਾ ਕਲੀਨਿੰਗ ਤੱਕ

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

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

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

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

ਕੈਸ਼ਿੰਗ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕਰਨਾ ਹੈ?

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

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

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

ਜ਼ੈਬਿਕਸ ਸਰਵਰ ਦੇ ਸਾਈਡ 'ਤੇ ਕੈਚਿੰਗ: ਸਾਡੇ ਕੋਲ ਕੌਂਫਿਗਰੇਸ਼ਨ ਕੈਚ, ਵੈਲਯੂ ਕੈਚ, ਹਿਸਟਰੀ ਕੈਚ, ਟ੍ਰੈਂਡਸ ਕੈਚ ਹੈ। ਇਹ ਕੀ ਹੈ?

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

ਜ਼ੈਬਿਕਸ ਵਿੱਚ ਕੈਚਿੰਗ। ਡਾਟਾ ਇਕੱਠਾ ਕਰਨ

ਇੱਥੇ ਚਿੱਤਰ ਕਾਫ਼ੀ ਵੱਡਾ ਹੈ:

ਸਕੀਮ ਵਿੱਚ ਮੁੱਖ ਇਹ ਕੁਲੈਕਟਰ ਹਨ:

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

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

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

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

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

ਇਤਿਹਾਸ ਸਿੰਕਰ ਦਾ ਕੰਮ

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

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

ਡਾਟਾਬੇਸ। ਕੈਸ਼ਿੰਗ

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

MySQL ਲਈ Innodb_buffer_pool ਹੈ, ਅਤੇ ਵੱਖ-ਵੱਖ ਕੈਚਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ ਜਿਸਨੂੰ ਸੰਰਚਿਤ ਵੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਪਰ ਇਹ ਮੁੱਖ ਹਨ:

• ਸਾਂਝੇ_ਬਫਰ;
• ਪ੍ਰਭਾਵਸ਼ਾਲੀ_ਕੈਸ਼_ਆਕਾਰ;
• ਸਾਂਝਾ_ਪੂਲ।

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

ਡਾਟਾਬੇਸ ਪ੍ਰਦਰਸ਼ਨ ਬਾਰੇ

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

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

ਇਤਿਹਾਸ ਨੂੰ ਸਾਫ਼ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ। ਜ਼ੈਬਿਕਸ ਕੋਲ ਹਾਊਸਕੀਪਰ ਹੈ

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

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

ਇਹ ਕਿਵੇਂ ਸਮਝਣਾ ਹੈ ਕਿ ਇਹ ਬੇਅਸਰ ਹੈ? ਤੁਸੀਂ ਅੰਦਰੂਨੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਗ੍ਰਾਫ 'ਤੇ ਹੇਠਾਂ ਦਿੱਤੀ ਤਸਵੀਰ ਦੇਖ ਸਕਦੇ ਹੋ:

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

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

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

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

ਵਿਭਾਗੀਕਰਨ (ਵਿਭਾਗੀਕਰਨ)

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

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

ਚਲੋ ਸੈੱਟਅੱਪ ਦੇ ਆਕਾਰ ਬਾਰੇ ਤੁਰੰਤ ਦੱਸੀਏ: ਪ੍ਰਤੀ ਸਕਿੰਟ 5 ਹਜ਼ਾਰ ਨਵੇਂ ਮੁੱਲ (ਅਖੌਤੀ ਐਨਵੀਪੀਐਸ) - ਇਸ ਨੂੰ ਇੱਕ ਛੋਟਾ "ਸੈਟਅੱਪ" ਮੰਨਿਆ ਜਾਵੇਗਾ। ਔਸਤ - 5 ਤੋਂ 25 ਹਜ਼ਾਰ ਮੁੱਲ ਪ੍ਰਤੀ ਸਕਿੰਟ ਤੱਕ। ਉਪਰੋਕਤ ਸਭ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਵੱਡੀਆਂ ਅਤੇ ਬਹੁਤ ਵੱਡੀਆਂ ਸਥਾਪਨਾਵਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਲਈ ਡੇਟਾਬੇਸ ਦੀ ਬਹੁਤ ਧਿਆਨ ਨਾਲ ਸੰਰਚਨਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

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

ਤੁਹਾਨੂੰ ਵੰਡ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ?

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

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

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

NoSQL ਲਈ ਲਚਕਦਾਰ ਖੋਜ

ਹਾਲ ਹੀ ਵਿੱਚ, 3.4 ਵਿੱਚ, ਅਸੀਂ ਇੱਕ NoSQL ਹੱਲ ਲਾਗੂ ਕੀਤਾ ਹੈ। Elasticsearch ਵਿੱਚ ਲਿਖਣ ਦੀ ਯੋਗਤਾ ਸ਼ਾਮਲ ਕੀਤੀ ਗਈ। ਤੁਸੀਂ ਕੁਝ ਖਾਸ ਕਿਸਮਾਂ ਲਿਖ ਸਕਦੇ ਹੋ: ਤੁਸੀਂ ਚੁਣਦੇ ਹੋ - ਜਾਂ ਤਾਂ ਨੰਬਰ ਲਿਖੋ ਜਾਂ ਕੁਝ ਚਿੰਨ੍ਹ; ਸਾਡੇ ਕੋਲ ਸਟ੍ਰਿੰਗ ਟੈਕਸਟ ਹੈ, ਤੁਸੀਂ Elasticsearch 'ਤੇ ਲੌਗ ਲਿਖ ਸਕਦੇ ਹੋ... ਇਸ ਅਨੁਸਾਰ, ਵੈੱਬ ਇੰਟਰਫੇਸ ਵੀ Elasticsearch ਤੱਕ ਪਹੁੰਚ ਕਰੇਗਾ। ਇਹ ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਇਸ ਸਮੇਂ ਇਸਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

ਟਾਈਮਸਕੇਲDB। ਹਾਈਪਰਟੇਬਲ

4.4.2 ਲਈ ਅਸੀਂ TimescaleDB ਵਰਗੀ ਇੱਕ ਚੀਜ਼ ਵੱਲ ਧਿਆਨ ਦਿੱਤਾ। ਇਹ ਕੀ ਹੈ? ਇਹ PostgreSQL ਲਈ ਇੱਕ ਐਕਸਟੈਂਸ਼ਨ ਹੈ, ਯਾਨੀ ਕਿ ਇਸਦਾ ਇੱਕ ਮੂਲ PostgreSQL ਇੰਟਰਫੇਸ ਹੈ। ਨਾਲ ਹੀ, ਇਹ ਐਕਸਟੈਂਸ਼ਨ ਤੁਹਾਨੂੰ ਟਾਈਮਸੀਰੀਜ਼ ਡੇਟਾ ਦੇ ਨਾਲ ਵਧੇਰੇ ਕੁਸ਼ਲਤਾ ਨਾਲ ਕੰਮ ਕਰਨ ਅਤੇ ਆਟੋਮੈਟਿਕ ਵਿਭਾਗੀਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਇਹ ਕਿਹੋ ਜਿਹਾ ਦਿਸਦਾ ਹੈ:

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

TimescaleDB ਅਤੇ PostgreSQL

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

TimescaleDB ਨੂੰ ਕਿਵੇਂ ਇੰਸਟਾਲ ਕਰਨਾ ਹੈ? ਇਹ ਸਧਾਰਨ ਹੈ!

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

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

ਅਤੇ ਆਖਰੀ ਕਦਮ ...

ਟਾਈਮਸਕੇਲDB। ਇਤਿਹਾਸ ਟੇਬਲ ਦਾ ਮਾਈਗਰੇਸ਼ਨ

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

ਫੀਲਡ ਜਿਸ ਦੁਆਰਾ ਬਣਾਉਣਾ ਹੈ, ਅਤੇ chunk_time_interval (ਇਹ ਭਾਗਾਂ ਦਾ ਅੰਤਰਾਲ ਹੈ (ਭਾਗ ਜੋ ਵਰਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ)। 86 ਇੱਕ ਦਿਨ ਹੈ।

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

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

ਅਤੇ ਅਸੀਂ ਆਪਣੇ db_extention ਵਿੱਚ ਆਖਰੀ ਅੱਪਡੇਟ ਕਰਦੇ ਹਾਂ: ਅਸੀਂ timescaledb ਨੂੰ ਇੰਸਟਾਲ ਕਰਦੇ ਹਾਂ ਤਾਂ ਕਿ ਡੇਟਾਬੇਸ ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ, ਸਾਡਾ ਜ਼ੈਬਿਕਸ ਸਮਝ ਸਕੇ ਕਿ ਇੱਥੇ db_extention ਹੈ। ਉਹ ਇਸਨੂੰ ਐਕਟੀਵੇਟ ਕਰਦਾ ਹੈ ਅਤੇ ਡੇਟਾਬੇਸ ਲਈ ਸਹੀ ਸੰਟੈਕਸ ਅਤੇ ਸਵਾਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਉਹਨਾਂ "ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ" ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਜੋ TimescaleDB ਲਈ ਜ਼ਰੂਰੀ ਹਨ।

ਸਰਵਰ ਸੰਰਚਨਾ

ਮੈਂ ਦੋ ਸਰਵਰ ਵਰਤੇ। ਪਹਿਲਾ ਸਰਵਰ ਇੱਕ ਕਾਫ਼ੀ ਛੋਟੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨ, 20 ਪ੍ਰੋਸੈਸਰ, 16 ਗੀਗਾਬਾਈਟ ਰੈਮ ਹੈ। ਮੈਂ ਇਸ 'ਤੇ ਪੋਸਟਗ੍ਰੇਸ 10.8 ਨੂੰ ਕੌਂਫਿਗਰ ਕੀਤਾ ਹੈ:

ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਸੀ Debian, ਫਾਈਲ ਸਿਸਟਮ - xfs। ਮੈਂ ਇਸ ਡੇਟਾਬੇਸ ਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਵਰਤਣ ਲਈ ਘੱਟੋ-ਘੱਟ ਸੈਟਿੰਗਾਂ ਬਣਾਈਆਂ ਹਨ, ਇਸ ਤੋਂ ਇਲਾਵਾ Zabbix ਖੁਦ ਕੀ ਵਰਤੇਗਾ। Zabbix ਸਰਵਰ, PostgreSQL, ਅਤੇ ਲੋਡ ਏਜੰਟ ਵੀ ਇਸ ਮਸ਼ੀਨ 'ਤੇ ਸਥਾਪਿਤ ਕੀਤੇ ਗਏ ਸਨ।

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

ਮੈਂ ਨਾ ਸਿਰਫ਼ 50 ਏਜੰਟਾਂ (ਹੋਰ ਜੋੜ ਕੇ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਸਗੋਂ ਗਤੀਸ਼ੀਲ ਡਾਟਾ ਤੱਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਤੇ ਅੱਪਡੇਟ ਅੰਤਰਾਲ ਨੂੰ 4 ਸਕਿੰਟਾਂ ਤੱਕ ਘਟਾ ਕੇ ਆਪਣੇ ਆਪ ਅੱਪਡੇਟ ਅੰਤਰਾਲ ਅਤੇ ਲੋਡ ਨੂੰ ਨਿਯੰਤ੍ਰਿਤ ਕੀਤਾ।

ਪ੍ਰਦਰਸ਼ਨ ਟੈਸਟ. PostgreSQL: 36 ਹਜ਼ਾਰ NVPs

ਪਹਿਲੀ ਲਾਂਚ, ਮੇਰੇ ਕੋਲ ਪਹਿਲਾ ਸੈੱਟਅੱਪ ਇਸ ਹਾਰਡਵੇਅਰ (10 ਹਜ਼ਾਰ ਮੁੱਲ ਪ੍ਰਤੀ ਸਕਿੰਟ) 'ਤੇ ਸ਼ੁੱਧ PostreSQL 35 'ਤੇ ਸੀ। ਆਮ ਤੌਰ 'ਤੇ, ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਸਕ੍ਰੀਨ 'ਤੇ ਦੇਖ ਸਕਦੇ ਹੋ, ਡਾਟਾ ਪਾਉਣ ਲਈ ਇੱਕ ਸਕਿੰਟ ਦੇ ਅੰਸ਼ ਲੱਗਦੇ ਹਨ - ਸਭ ਕੁਝ ਵਧੀਆ ਅਤੇ ਤੇਜ਼ ਹੈ, SSD ਡਰਾਈਵਾਂ (200 ਗੀਗਾਬਾਈਟ)। ਸਿਰਫ ਗੱਲ ਇਹ ਹੈ ਕਿ 20 GB ਕਾਫ਼ੀ ਤੇਜ਼ੀ ਨਾਲ ਭਰਦਾ ਹੈ.

ਭਵਿੱਖ ਵਿੱਚ ਅਜਿਹੇ ਬਹੁਤ ਸਾਰੇ ਗ੍ਰਾਫ ਹੋਣਗੇ. ਇਹ ਇੱਕ ਮਿਆਰੀ ਜ਼ੈਬਿਕਸ ਸਰਵਰ ਪ੍ਰਦਰਸ਼ਨ ਡੈਸ਼ਬੋਰਡ ਹੈ।

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

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

ਪ੍ਰਦਰਸ਼ਨ ਟੈਸਟ. PostgreSQL: 50 ਹਜ਼ਾਰ NVPs

ਅੱਗੇ, ਮੈਂ ਉਸੇ ਹਾਰਡਵੇਅਰ 'ਤੇ ਲੋਡ ਨੂੰ 50 ਹਜ਼ਾਰ ਮੁੱਲ ਪ੍ਰਤੀ ਸਕਿੰਟ ਤੱਕ ਵਧਾ ਦਿੱਤਾ। ਜਦੋਂ ਹਾਊਸਕੀਪਰ ਦੁਆਰਾ ਲੋਡ ਕੀਤਾ ਗਿਆ, ਤਾਂ ਗਣਨਾ ਨਾਲ 10-2 ਸਕਿੰਟਾਂ ਵਿੱਚ 3 ਹਜ਼ਾਰ ਮੁੱਲ ਦਰਜ ਕੀਤੇ ਗਏ ਸਨ। ਕੀ, ਅਸਲ ਵਿੱਚ, ਹੇਠਾਂ ਦਿੱਤੇ ਸਕ੍ਰੀਨਸ਼ਾਟ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਹੈ:

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

ਪ੍ਰਦਰਸ਼ਨ ਟੈਸਟ. PostgreSQL: 80 ਹਜ਼ਾਰ NVPs

ਫਿਰ ਮੈਂ ਇਸਨੂੰ 80 ਹਜ਼ਾਰ ਮੁੱਲ ਪ੍ਰਤੀ ਸਕਿੰਟ ਤੱਕ ਵਧਾ ਦਿੱਤਾ:

ਇਹ ਲਗਭਗ 400 ਹਜ਼ਾਰ ਡਾਟਾ ਤੱਤ, 280 ਹਜ਼ਾਰ ਟਰਿਗਰ ਸੀ. ਸੰਮਿਲਨ, ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਇਤਿਹਾਸ ਦੇ ਡੁੱਬਣ ਵਾਲੇ ਲੋਡ ਦੇ ਰੂਪ ਵਿੱਚ (ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ 30 ਸਨ) ਪਹਿਲਾਂ ਹੀ ਕਾਫ਼ੀ ਉੱਚੇ ਸਨ. ਫਿਰ ਮੈਂ ਵੱਖ-ਵੱਖ ਮਾਪਦੰਡਾਂ ਨੂੰ ਵਧਾ ਦਿੱਤਾ: ਇਤਿਹਾਸ ਸਿੰਕਰ, ਕੈਸ਼... ਇਸ ਹਾਰਡਵੇਅਰ 'ਤੇ, ਹਿਸਟਰੀ ਸਿੰਕਰਾਂ ਦਾ ਲੋਡ ਵੱਧ ਤੋਂ ਵੱਧ ਵਧਣਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ, ਲਗਭਗ "ਸ਼ੈਲਫ 'ਤੇ" - ਇਸ ਅਨੁਸਾਰ, ਹਿਸਟਰੀ ਕੈਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੋਡ ਵਿੱਚ ਚਲਾ ਗਿਆ:

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

ਮੈਂ ਇੱਕ ਹੋਰ ਸਰਵਰ ਲਿਆ ਜਿਸ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ 48 ਪ੍ਰੋਸੈਸਰ ਅਤੇ 128 ਗੀਗਾਬਾਈਟ RAM ਸੀ:

ਮੈਂ ਇਸਨੂੰ "ਟਿਊਨ" ਵੀ ਕੀਤਾ - ਇਤਿਹਾਸ ਸਿੰਸਰ (60 ਟੁਕੜੇ) ਸਥਾਪਿਤ ਕੀਤਾ ਅਤੇ ਸਵੀਕਾਰਯੋਗ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਾਪਤ ਕੀਤਾ। ਵਾਸਤਵ ਵਿੱਚ, ਅਸੀਂ "ਸ਼ੈਲਫ ਉੱਤੇ" ਨਹੀਂ ਹਾਂ, ਪਰ ਇਹ ਸ਼ਾਇਦ ਉਤਪਾਦਕਤਾ ਦੀ ਸੀਮਾ ਹੈ, ਜਿੱਥੇ ਇਸ ਬਾਰੇ ਕੁਝ ਕਰਨਾ ਪਹਿਲਾਂ ਹੀ ਜ਼ਰੂਰੀ ਹੈ।

ਪ੍ਰਦਰਸ਼ਨ ਟੈਸਟ. ਟਾਈਮਸਕੇਲDB: 80 ਹਜ਼ਾਰ NVPs

ਮੇਰਾ ਮੁੱਖ ਕੰਮ ਟਾਈਮਸਕੇਲਡੀਬੀ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸੀ. ਹਰੇਕ ਗ੍ਰਾਫ ਇੱਕ ਡਿੱਪ ਦਿਖਾਉਂਦਾ ਹੈ:

ਇਹ ਅਸਫਲਤਾਵਾਂ ਬਿਲਕੁਲ ਡਾਟਾ ਮਾਈਗਰੇਸ਼ਨ ਹਨ। ਉਸ ਤੋਂ ਬਾਅਦ, ਜ਼ੈਬਿਕਸ ਸਰਵਰ ਵਿੱਚ, ਇਤਿਹਾਸ ਦੇ ਡੁੱਬਣ ਵਾਲਿਆਂ ਦੀ ਲੋਡਿੰਗ ਪ੍ਰੋਫਾਈਲ, ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਬਹੁਤ ਬਦਲ ਗਿਆ ਹੈ. ਇਹ ਤੁਹਾਨੂੰ ਲਗਭਗ 3 ਗੁਣਾ ਤੇਜ਼ੀ ਨਾਲ ਡਾਟਾ ਸੰਮਿਲਿਤ ਕਰਨ ਅਤੇ ਘੱਟ HistoryCache ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ - ਇਸ ਅਨੁਸਾਰ, ਤੁਹਾਡੇ ਕੋਲ ਸਮੇਂ 'ਤੇ ਡਾਟਾ ਡਿਲੀਵਰ ਹੋਵੇਗਾ। ਦੁਬਾਰਾ ਫਿਰ, ਪ੍ਰਤੀ ਸਕਿੰਟ 80 ਹਜ਼ਾਰ ਮੁੱਲ ਇੱਕ ਕਾਫ਼ੀ ਉੱਚ ਦਰ ਹੈ (ਬੇਸ਼ਕ, ਯਾਂਡੇਕਸ ਲਈ ਨਹੀਂ). ਕੁੱਲ ਮਿਲਾ ਕੇ ਇਹ ਇੱਕ ਸਰਵਰ ਦੇ ਨਾਲ ਇੱਕ ਕਾਫ਼ੀ ਵੱਡਾ ਸੈੱਟਅੱਪ ਹੈ।

PostgreSQL ਪ੍ਰਦਰਸ਼ਨ ਟੈਸਟ: 120 ਹਜ਼ਾਰ NVPs

ਅੱਗੇ, ਮੈਂ ਡੇਟਾ ਐਲੀਮੈਂਟਸ ਦੀ ਸੰਖਿਆ ਦੇ ਮੁੱਲ ਨੂੰ ਅੱਧਾ ਮਿਲੀਅਨ ਤੱਕ ਵਧਾ ਦਿੱਤਾ ਅਤੇ 125 ਹਜ਼ਾਰ ਪ੍ਰਤੀ ਸਕਿੰਟ ਦਾ ਗਣਿਤ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕੀਤਾ:

ਅਤੇ ਮੈਨੂੰ ਇਹ ਗ੍ਰਾਫ ਮਿਲੇ:

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

ਆਮ ਤੌਰ 'ਤੇ, ਪਾਰਟੀਸ਼ਨ ਰਾਤ ਨੂੰ ਬਣਾਏ ਜਾਂਦੇ ਹਨ, ਕਿਉਂਕਿ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਸੰਮਿਲਨ ਨੂੰ ਰੋਕਦਾ ਹੈ ਅਤੇ ਟੇਬਲਾਂ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਸੇਵਾ ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ। ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਇਹ ਕੇਸ ਨਹੀਂ ਹੈ! ਮੁੱਖ ਕੰਮ TimescaleDB ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਦੀ ਜਾਂਚ ਕਰਨਾ ਸੀ। ਨਤੀਜਾ ਹੇਠ ਲਿਖਿਆ ਅੰਕੜਾ ਸੀ: ਪ੍ਰਤੀ ਸਕਿੰਟ 120 ਹਜ਼ਾਰ ਮੁੱਲ.

ਕਮਿਊਨਿਟੀ ਵਿੱਚ ਵੀ ਉਦਾਹਰਣਾਂ ਹਨ:

ਵਿਅਕਤੀ ਨੇ TimescaleDB ਨੂੰ ਵੀ ਚਾਲੂ ਕੀਤਾ ਅਤੇ ਪ੍ਰੋਸੈਸਰ 'ਤੇ io.weight ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਲੋਡ ਘਟ ਗਿਆ; ਅਤੇ ਟਾਈਮਸਕੇਲਡੀਬੀ ਦੇ ਸ਼ਾਮਲ ਹੋਣ ਕਾਰਨ ਅੰਦਰੂਨੀ ਪ੍ਰਕਿਰਿਆ ਤੱਤਾਂ ਦੀ ਵਰਤੋਂ ਵੀ ਘਟ ਗਈ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਸਾਧਾਰਨ ਪੈਨਕੇਕ ਡਿਸਕਾਂ ਹਨ, ਯਾਨੀ, ਸਾਧਾਰਨ ਡਿਸਕਾਂ 'ਤੇ ਇੱਕ ਆਮ ਵਰਚੁਅਲ ਮਸ਼ੀਨ (SSD ਨਹੀਂ)!

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

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

ਸਰੋਤਿਆਂ ਦੇ ਸਵਾਲ

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

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

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

ਏ: - ਕਮਿਊਨਿਟੀ ਦੇ ਆਖਰੀ ਗ੍ਰਾਫਾਂ 'ਤੇ, "ਹਾਊਸਕੀਪਰ" ਵਾਲਾ ਗ੍ਰਾਫ ਸੀ:

ਉਸਨੇ ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਰੱਖਿਆ। ਹਾਊਸਕੀਪਰ ਟਾਈਮਸਕੇਲਡੀਬੀ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ?

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

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

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

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

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

ਏ: - ਆਮ ਤੌਰ 'ਤੇ, ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਪੋਸਟਗ੍ਰੇਸ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੁਟਕਾਰਾ ਪਾ ਸਕਦੇ ਹੋ?

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

ਏ: - ਕੀ ਤੁਸੀਂ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਸਭ ਕੁਝ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰੇਗਾ ਜੇਕਰ ਤੁਸੀਂ ਕਲਿਕਹਾਊਸ 'ਤੇ ਸਵਿੱਚ ਕਰਦੇ ਹੋ, ਉਦਾਹਰਣ ਲਈ?

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

ਏ: - ਇਸ ਲਈ ਅਸੀਂ ਬਰਾਬਰ ਦੀ ਲੜਾਈ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਨਾ ਕਿ ਇਹਨਾਂ ਤੇਜ਼ ਡੇਟਾਬੇਸ ਦੇ ਮਹਾਨ ਫਾਇਦੇ ਬਾਰੇ?

AG: - ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਜਦੋਂ ਅਸੀਂ ਏਕੀਕ੍ਰਿਤ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਹੋਰ ਸਹੀ ਟੈਸਟ ਹੋਣਗੇ।

ਏ: - ਚੰਗੇ ਪੁਰਾਣੇ ਆਰਆਰਡੀ ਕਿੱਥੇ ਗਏ? ਤੁਹਾਨੂੰ SQL ਡਾਟਾਬੇਸ 'ਤੇ ਜਾਣ ਲਈ ਕੀ ਕੀਤਾ? ਸ਼ੁਰੂ ਵਿੱਚ, ਸਾਰੇ ਮੈਟ੍ਰਿਕਸ RRD 'ਤੇ ਇਕੱਠੇ ਕੀਤੇ ਗਏ ਸਨ।

AG: - ਜ਼ੈਬਿਕਸ ਕੋਲ ਆਰਆਰਡੀ ਸੀ, ਸ਼ਾਇਦ ਇੱਕ ਬਹੁਤ ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਵਿੱਚ। ਹਮੇਸ਼ਾ SQL ਡਾਟਾਬੇਸ ਰਹੇ ਹਨ - ਇੱਕ ਕਲਾਸਿਕ ਪਹੁੰਚ. ਕਲਾਸਿਕ ਪਹੁੰਚ MySQL, PostgreSQL ਹੈ (ਉਹ ਬਹੁਤ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਮੌਜੂਦ ਹਨ)। ਅਸੀਂ ਲਗਭਗ ਕਦੇ ਵੀ SQL ਅਤੇ RRD ਡੇਟਾਬੇਸ ਲਈ ਇੱਕ ਸਾਂਝਾ ਇੰਟਰਫੇਸ ਨਹੀਂ ਵਰਤਿਆ।

ਕੁਝ ਵਿਗਿਆਪਨ 🙂

ਸਾਡੇ ਨਾਲ ਰਹਿਣ ਲਈ ਤੁਹਾਡਾ ਧੰਨਵਾਦ। ਕੀ ਤੁਹਾਨੂੰ ਸਾਡੇ ਲੇਖ ਪਸੰਦ ਹਨ? ਹੋਰ ਦਿਲਚਸਪ ਸਮੱਗਰੀ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ? ਆਰਡਰ ਦੇ ਕੇ ਜਾਂ ਦੋਸਤਾਂ ਨੂੰ ਸਿਫਾਰਸ਼ ਕਰਕੇ ਸਾਡਾ ਸਮਰਥਨ ਕਰੋ, $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