InfluxDB ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਗੁੱਸਾ, ਸੌਦੇਬਾਜ਼ੀ ਅਤੇ ਉਦਾਸੀ

ਜੇਕਰ ਤੁਸੀਂ ਟਾਈਮ ਸੀਰੀਜ਼ ਡੇਟਾਬੇਸ (timeseries db, ਵਿਕਿ) ਅੰਕੜਿਆਂ ਵਾਲੀ ਸਾਈਟ ਲਈ ਮੁੱਖ ਸਟੋਰੇਜ ਵਜੋਂ, ਫਿਰ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਬਜਾਏ ਤੁਹਾਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਿਰ ਦਰਦ ਹੋ ਸਕਦਾ ਹੈ. ਮੈਂ ਇੱਕ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਹਾਂ ਜੋ ਅਜਿਹੇ ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਈ ਵਾਰ InfluxDB, ਜਿਸ ਬਾਰੇ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ, ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਚਾਨਕ ਹੈਰਾਨੀ ਪੇਸ਼ ਕੀਤੀ ਗਈ ਹੈ.

ਬੇਦਾਅਵਾ: ਸੂਚੀਬੱਧ ਮੁੱਦੇ InfluxDB ਸੰਸਕਰਣ 1.7.4 'ਤੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ।

ਸਮਾਂ ਲੜੀ ਕਿਉਂ?

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

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

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

ਇਹ ਥੋੜਾ ਉਲਝਣ ਵਾਲਾ ਸੀ ਕਿ ਅਜਿਹੇ ਡੇਟਾਬੇਸ ਆਮ ਤੌਰ 'ਤੇ ਮੈਟ੍ਰਿਕਸ ਇਕੱਠੇ ਕਰਨ ਦੇ ਉਦੇਸ਼ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ. ਸਰਵਰਾਂ ਦੀ ਨਿਗਰਾਨੀ, ਆਈਓਟੀ ਡਿਵਾਈਸਾਂ, ਹਰ ਚੀਜ਼ ਜਿਸ ਤੋਂ "ਪ੍ਰਵਾਹ" ਰੂਪ ਦੇ ਲੱਖਾਂ ਪੁਆਇੰਟ: [<time> - <ਮੀਟ੍ਰਿਕ ਮੁੱਲ>]। ਪਰ ਜੇਕਰ ਡੇਟਾਬੇਸ ਇੱਕ ਵੱਡੇ ਡੇਟਾ ਪ੍ਰਵਾਹ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਮਾਤਰਾ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਕਿਉਂ ਪੈਦਾ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ? ਇਸ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਅਸੀਂ InfluxDB ਨੂੰ ਕੰਮ ਕਰਨ ਲਈ ਲਿਆ।

InfluxDB ਵਿੱਚ ਹੋਰ ਕੀ ਸੁਵਿਧਾਜਨਕ ਹੈ

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

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

1. ਕਿਸੇ ਹੋਰ ਸਾਰਣੀ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਲਈ ਇੱਕ ਨਿਰੰਤਰ ਪੁੱਛਗਿੱਛ ਬਣਾਓ;
2. ਪਹਿਲੀ ਸਾਰਣੀ ਲਈ, ਉਸੇ ਹਫ਼ਤੇ ਤੋਂ ਪੁਰਾਣੇ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਮਿਟਾਉਣ ਲਈ ਇੱਕ ਨੀਤੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ।

ਅਤੇ ਇਨਫਲਕਸ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਡੇਟਾ ਦੇ ਆਕਾਰ ਨੂੰ ਘਟਾ ਦੇਵੇਗਾ ਅਤੇ ਬੇਲੋੜੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਮਿਟਾ ਦੇਵੇਗਾ.

ਸਟੋਰ ਕੀਤੇ ਡੇਟਾ ਬਾਰੇ

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

ਸਮੱਸਿਆਵਾਂ

ਸੇਵਾ ਦੇ ਵਿਕਾਸ ਅਤੇ ਬਾਅਦ ਦੀ ਜਾਂਚ ਦੇ ਦੌਰਾਨ, InfluxDB ਦੇ ਸੰਚਾਲਨ ਵਿੱਚ ਵੱਧ ਤੋਂ ਵੱਧ ਗੰਭੀਰ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੋਈਆਂ।

1. ਡਾਟਾ ਮਿਟਾਉਣਾ

ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਦੇ ਨਾਲ ਡੇਟਾ ਦੀ ਇੱਕ ਲੜੀ ਹੈ:

SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'

ਨਤੀਜਾ:

ਮੈਂ ਡੇਟਾ ਨੂੰ ਮਿਟਾਉਣ ਲਈ ਇੱਕ ਕਮਾਂਡ ਭੇਜ ਰਿਹਾ ਹਾਂ:

DELETE FROM transactions WHERE symbol=’USDT’

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

ਮੈਂ ਪੂਰੀ ਸਾਰਣੀ ਨੂੰ ਮਿਟਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹਾਂ:

DROP MEASUREMENT transactions

ਮੈਂ ਟੇਬਲ ਨੂੰ ਹਟਾਉਣ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹਾਂ:

SHOW MEASUREMENTS

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

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

ਨਤੀਜੇ ਵਜੋਂ, ਪੂਰੇ ਡੇਟਾਬੇਸ ਨੂੰ ਮਿਟਾਉਣ ਅਤੇ ਫਿਰ ਰੀਸਟੋਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਮਿਲੀ।

2. ਫਲੋਟਿੰਗ ਪੁਆਇੰਟ ਨੰਬਰ

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

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

3. ਲਗਾਤਾਰ ਸਵਾਲਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਸਮਾਂ ਜ਼ੋਨਾਂ ਲਈ ਅਨੁਕੂਲਿਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ

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

InfluxDB ਵਿੱਚ, ਸਮੇਂ ਅਨੁਸਾਰ ਗਰੁੱਪਿੰਗ ਕਰਦੇ ਸਮੇਂ, ਤੁਸੀਂ ਇੱਕ ਸ਼ਿਫਟ ਵੀ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ ਮਾਸਕੋ ਸਮਾਂ (UTC+3):

SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)

ਪਰ ਪੁੱਛਗਿੱਛ ਦਾ ਨਤੀਜਾ ਗਲਤ ਹੋਵੇਗਾ। ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ, ਦਿਨ ਦੇ ਹਿਸਾਬ ਨਾਲ ਗਰੁੱਪ ਕੀਤਾ ਗਿਆ ਡਾਟਾ 1677 ਤੱਕ ਵਾਪਸ ਸ਼ੁਰੂ ਹੋ ਜਾਵੇਗਾ (InfluxDB ਅਧਿਕਾਰਤ ਤੌਰ 'ਤੇ ਇਸ ਸਾਲ ਤੋਂ ਇੱਕ ਸਮਾਂ ਮਿਆਦ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ):

ਇਸ ਸਮੱਸਿਆ ਦੇ ਹੱਲ ਲਈ, ਅਸੀਂ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਸੇਵਾ ਨੂੰ UTC+0 'ਤੇ ਬਦਲ ਦਿੱਤਾ ਹੈ।

4. ਪ੍ਰਦਰਸ਼ਨ

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

ਮੈਂ ਤੁਹਾਨੂੰ ਆਪਣਾ ਕੇਸ ਦੱਸਾਂਗਾ।

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

SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1

SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1

SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESC

ਵਿਆਖਿਆ:

1. ਪਹਿਲੀ ਬੇਨਤੀ ਵਿੱਚ, ਅਸੀਂ ਮਾਰਕੀਟ ਡੇਟਾ ਦੇ ਨਾਲ ਹਰੇਕ ਸਿੱਕੇ ਲਈ ਆਖਰੀ ਅੰਕ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ। ਮੇਰੇ ਕੇਸ ਵਿੱਚ ਅੱਠ ਸਿੱਕਿਆਂ ਲਈ ਅੱਠ ਅੰਕ.
2. ਦੂਜੀ ਬੇਨਤੀ ਸਭ ਤੋਂ ਨਵੇਂ ਅੰਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ।
3. ਤੀਜਾ ਪਿਛਲੇ XNUMX ਘੰਟਿਆਂ ਲਈ ਲੈਣ-ਦੇਣ ਦੀ ਸੂਚੀ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ; ਉਹਨਾਂ ਵਿੱਚੋਂ ਕਈ ਸੌ ਹੋ ਸਕਦੇ ਹਨ।

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

ਮੈਂ ਇਸ API ਵਿਧੀ 'ਤੇ ਤਣਾਅ ਦਾ ਟੈਸਟ ਚਲਾਇਆ ਹੈ। 25 RPS ਲਈ, ਸਰਵਰ ਨੇ ਛੇ CPUs ਦਾ ਪੂਰਾ ਲੋਡ ਦਿਖਾਇਆ:

ਉਸੇ ਸਮੇਂ, NodeJs ਪ੍ਰਕਿਰਿਆ ਨੇ ਕੋਈ ਵੀ ਲੋਡ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕੀਤਾ।

ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਪੀਡ ਪਹਿਲਾਂ ਹੀ 7-10 RPS ਦੁਆਰਾ ਘਟਾਈ ਗਈ ਹੈ: ਜੇਕਰ ਇੱਕ ਕਲਾਇੰਟ 200 ms ਵਿੱਚ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ 10 ਗਾਹਕਾਂ ਨੂੰ ਇੱਕ ਸਕਿੰਟ ਉਡੀਕ ਕਰਨੀ ਪਵੇਗੀ। 25 RPS ਉਹ ਸੀਮਾ ਹੈ ਜਿਸ 'ਤੇ ਸਥਿਰਤਾ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ; 500 ਗਲਤੀਆਂ ਗਾਹਕਾਂ ਨੂੰ ਵਾਪਸ ਕਰ ਦਿੱਤੀਆਂ ਗਈਆਂ ਸਨ।

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

ਸਿੱਟਾ

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

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

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

ਸਰੋਤ: www.habr.com