ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਵਿੱਚ ਅਨੁਕੂਲਤਾ 'ਤੇ ਜਾਓ। ਅਲੈਗਜ਼ੈਂਡਰ ਵਲਯਾਲਕਿਨ

ਮੈਂ ਸੁਝਾਅ ਦਿੰਦਾ ਹਾਂ ਕਿ ਤੁਸੀਂ ਅਲੈਗਜ਼ੈਂਡਰ ਵਲਯਾਲਕਿਨ ਦੁਆਰਾ "ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਵਿੱਚ ਅਨੁਕੂਲਤਾ ਵੱਲ ਜਾਓ" ਦੀ 2019 ਦੀ ਰਿਪੋਰਟ ਦੀ ਪ੍ਰਤੀਲਿਪੀ ਨੂੰ ਪੜ੍ਹੋ।

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

ਪੇਸ਼ ਹੈ ਇਸ ਰਿਪੋਰਟ ਦੀ ਵੀਡੀਓ ਦਾ ਲਿੰਕ- https://youtu.be/MZ5P21j_HLE

ਸਲਾਈਡਾਂ

ਸਾਨੂੰ ਆਪਣੇ ਬਾਰੇ ਦੱਸੋ. ਮੈਂ ਅਲੈਗਜ਼ੈਂਡਰ ਵਲਯਾਲਕਿਨ ਹਾਂ। ਇਥੇ ਮੇਰਾ GitHub ਖਾਤਾ. ਮੈਂ ਗੋ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਅਨੁਕੂਲਨ ਬਾਰੇ ਭਾਵੁਕ ਹਾਂ। ਮੈਂ ਬਹੁਤ ਸਾਰੀਆਂ ਉਪਯੋਗੀ ਅਤੇ ਇੰਨੀਆਂ ਉਪਯੋਗੀ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨਹੀਂ ਲਿਖੀਆਂ। ਉਹ ਕਿਸੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ fast, ਜਾਂ ਨਾਲ quick ਅਗੇਤਰ.

ਮੈਂ ਇਸ ਸਮੇਂ ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ 'ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ/ਰਹੀ ਹਾਂ। ਇਹ ਕੀ ਹੈ ਅਤੇ ਮੈਂ ਉੱਥੇ ਕੀ ਕਰ ਰਿਹਾ ਹਾਂ? ਮੈਂ ਇਸ ਪੇਸ਼ਕਾਰੀ ਵਿੱਚ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ।

ਰਿਪੋਰਟ ਦੀ ਰੂਪਰੇਖਾ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਹੈ:

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

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

ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਹੋਰ ਟਾਈਮ ਸੀਰੀਜ਼ ਡੇਟਾਬੇਸ ਨਾਲੋਂ ਬਿਹਤਰ ਡਾਟਾ ਕੰਪਰੈਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

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

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

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

ਕੌਣ ਜਾਣਦਾ ਹੈ ਕਿ ਸਮਾਂ ਲੜੀ ਕੀ ਹੈ? ਉਹ ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਨੂੰ ਜਾਣਦਾ ਵੀ ਹੈ। ਇੱਕ ਸਮਾਂ ਲੜੀ ਜੋੜਿਆਂ ਦੀ ਇੱਕ ਲੜੀ ਹੁੰਦੀ ਹੈ (timestamp, значение), ਜਿੱਥੇ ਇਹ ਜੋੜਿਆਂ ਨੂੰ ਸਮੇਂ ਅਨੁਸਾਰ ਕ੍ਰਮਬੱਧ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਮੁੱਲ ਇੱਕ ਫਲੋਟਿੰਗ ਪੁਆਇੰਟ ਨੰਬਰ ਹੈ - float64।

ਹਰ ਵਾਰ ਲੜੀ ਨੂੰ ਇੱਕ ਕੁੰਜੀ ਦੁਆਰਾ ਵਿਲੱਖਣ ਰੂਪ ਵਿੱਚ ਪਛਾਣਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਕੁੰਜੀ ਵਿੱਚ ਕੀ ਸ਼ਾਮਲ ਹੈ? ਇਸ ਵਿੱਚ ਕੁੰਜੀ-ਮੁੱਲ ਜੋੜਿਆਂ ਦਾ ਇੱਕ ਗੈਰ-ਖਾਲੀ ਸੈੱਟ ਹੁੰਦਾ ਹੈ।

ਇੱਥੇ ਇੱਕ ਸਮਾਂ ਲੜੀ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਹੈ। ਇਸ ਲੜੀ ਦੀ ਕੁੰਜੀ ਜੋੜਿਆਂ ਦੀ ਸੂਚੀ ਹੈ: __name__="cpu_usage" ਮੈਟ੍ਰਿਕ ਦਾ ਨਾਮ ਹੈ, instance="my-server" - ਇਹ ਉਹ ਕੰਪਿਊਟਰ ਹੈ ਜਿਸ 'ਤੇ ਇਹ ਮੈਟ੍ਰਿਕ ਇਕੱਠੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, datacenter="us-east" - ਇਹ ਉਹ ਡਾਟਾ ਸੈਂਟਰ ਹੈ ਜਿੱਥੇ ਇਹ ਕੰਪਿਊਟਰ ਸਥਿਤ ਹੈ।

ਅਸੀਂ ਤਿੰਨ ਮੁੱਖ-ਮੁੱਲ ਜੋੜਿਆਂ ਵਾਲੀ ਇੱਕ ਸਮਾਂ ਲੜੀ ਦੇ ਨਾਮ ਨਾਲ ਸਮਾਪਤ ਹੋਏ। ਇਹ ਕੁੰਜੀ ਜੋੜਿਆਂ ਦੀ ਸੂਚੀ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ (timestamp, value). t1, t3, t3, ..., tN - ਇਹ ਟਾਈਮਸਟੈਂਪ ਹਨ, 10, 20, 12, ..., 15 - ਅਨੁਸਾਰੀ ਮੁੱਲ। ਇਹ ਇੱਕ ਦਿੱਤੀ ਕਤਾਰ ਲਈ ਇੱਕ ਦਿੱਤੇ ਸਮੇਂ 'ਤੇ cpu-ਵਰਤੋਂ ਹੈ।

ਸਮਾਂ ਲੜੀ ਕਿੱਥੇ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ? ਕੀ ਕਿਸੇ ਕੋਲ ਕੋਈ ਵਿਚਾਰ ਹੈ?

• DevOps ਵਿੱਚ, ਤੁਸੀਂ CPU, RAM, ਨੈੱਟਵਰਕ, rps, ਗਲਤੀਆਂ ਦੀ ਗਿਣਤੀ, ਆਦਿ ਨੂੰ ਮਾਪ ਸਕਦੇ ਹੋ।
• IoT - ਅਸੀਂ ਤਾਪਮਾਨ, ਦਬਾਅ, ਜੀਓ ਕੋਆਰਡੀਨੇਟਸ ਅਤੇ ਕੁਝ ਹੋਰ ਮਾਪ ਸਕਦੇ ਹਾਂ।
• ਵਿੱਤ ਵੀ - ਅਸੀਂ ਹਰ ਕਿਸਮ ਦੇ ਸਟਾਕਾਂ ਅਤੇ ਮੁਦਰਾਵਾਂ ਲਈ ਕੀਮਤਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰ ਸਕਦੇ ਹਾਂ।
• ਇਸ ਤੋਂ ਇਲਾਵਾ, ਫੈਕਟਰੀਆਂ ਵਿੱਚ ਉਤਪਾਦਨ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ ਸਮਾਂ ਲੜੀ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਸਾਡੇ ਕੋਲ ਅਜਿਹੇ ਉਪਭੋਗਤਾ ਹਨ ਜੋ ਰੋਬੋਟਾਂ ਲਈ ਵਿੰਡ ਟਰਬਾਈਨਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।
• ਸਮਾਂ ਲੜੀ ਵੱਖ-ਵੱਖ ਡਿਵਾਈਸਾਂ ਦੇ ਸੈਂਸਰਾਂ ਤੋਂ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰਨ ਲਈ ਵੀ ਉਪਯੋਗੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਇੰਜਣ ਲਈ; ਟਾਇਰ ਪ੍ਰੈਸ਼ਰ ਨੂੰ ਮਾਪਣ ਲਈ; ਗਤੀ, ਦੂਰੀ ਨੂੰ ਮਾਪਣ ਲਈ; ਗੈਸੋਲੀਨ ਦੀ ਖਪਤ ਨੂੰ ਮਾਪਣ ਲਈ, ਆਦਿ.
• ਟਾਈਮ ਸੀਰੀਜ਼ ਨੂੰ ਏਅਰਕ੍ਰਾਫਟ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ ਵੀ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਹਰੇਕ ਜਹਾਜ਼ ਵਿੱਚ ਇੱਕ ਬਲੈਕ ਬਾਕਸ ਹੁੰਦਾ ਹੈ ਜੋ ਜਹਾਜ਼ ਦੀ ਸਿਹਤ ਦੇ ਵੱਖ-ਵੱਖ ਮਾਪਦੰਡਾਂ ਲਈ ਸਮਾਂ ਲੜੀ ਇਕੱਤਰ ਕਰਦਾ ਹੈ। ਸਮਾਂ ਲੜੀ ਵੀ ਏਰੋਸਪੇਸ ਉਦਯੋਗ ਵਿੱਚ ਵਰਤੀ ਜਾਂਦੀ ਹੈ।
• ਸਿਹਤ ਸੰਭਾਲ ਬਲੱਡ ਪ੍ਰੈਸ਼ਰ, ਨਬਜ਼ ਆਦਿ ਹੈ।

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

ਤੁਹਾਨੂੰ ਟਾਈਮ ਸੀਰੀਜ਼ ਡੇਟਾਬੇਸ ਦੀ ਕਿਉਂ ਲੋੜ ਹੈ? ਤੁਸੀਂ ਸਮਾਂ ਲੜੀ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਨਿਯਮਤ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕਿਉਂ ਨਹੀਂ ਕਰ ਸਕਦੇ?

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

ਆਮ ਤੌਰ 'ਤੇ ਟਾਈਮ ਸੀਰੀਜ਼ ਡੇਟਾਬੇਸ ਵਿਸ਼ੇਸ਼ ਪੁੱਛਗਿੱਛ ਭਾਸ਼ਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਸਮਾਂ ਲੜੀ SQL ਬਹੁਤ ਅਨੁਕੂਲ ਨਹੀਂ ਹੈ। ਹਾਲਾਂਕਿ ਅਜਿਹੇ ਡੇਟਾਬੇਸ ਹਨ ਜੋ SQL ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਇਹ ਬਹੁਤ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ. ਪ੍ਰਸ਼ਨ ਭਾਸ਼ਾਵਾਂ ਜਿਵੇਂ ਕਿ PromQL, InfluxQL, ਵਹਿਣਾ, Q. ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਕਿਸੇ ਨੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਭਾਸ਼ਾ ਸੁਣੀ ਹੋਵੇਗੀ। ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਨੇ ਸ਼ਾਇਦ PromQL ਬਾਰੇ ਸੁਣਿਆ ਹੋਵੇਗਾ। ਇਹ ਪ੍ਰੋਮੀਥੀਅਸ ਪੁੱਛਗਿੱਛ ਭਾਸ਼ਾ ਹੈ।

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

ਇਸ ਦੇ ਦੋ ਭਾਗ ਹਨ। ਇਹ ਉਲਟ ਸੂਚਕਾਂਕ ਲਈ ਸਟੋਰੇਜ ਅਤੇ ਸਮਾਂ ਲੜੀ ਦੇ ਮੁੱਲਾਂ ਲਈ ਸਟੋਰੇਜ ਹੈ। ਇਹ ਰਿਪੋਜ਼ਟਰੀਆਂ ਵੱਖ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ।

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

ਜਦੋਂ TSDB ਤੋਂ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕੋਈ ਬੇਨਤੀ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਅਸੀਂ ਪਹਿਲਾਂ ਉਲਟ ਸੂਚਕਾਂਕ 'ਤੇ ਜਾਂਦੇ ਹਾਂ। ਆਓ ਸਭ ਕੁਝ ਪ੍ਰਾਪਤ ਕਰੀਏ timeseries_ids ਰਿਕਾਰਡ ਜੋ ਇਸ ਸੈੱਟ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ label=value. ਅਤੇ ਫਿਰ ਅਸੀਂ ਡੇਟਾ ਵੇਅਰਹਾਊਸ ਤੋਂ ਸਾਰੇ ਲੋੜੀਂਦੇ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ, ਦੁਆਰਾ ਸੂਚੀਬੱਧ timeseries_ids.

ਆਉ ਇੱਕ ਉਦਾਹਰਨ ਵੇਖੀਏ ਕਿ ਕਿਵੇਂ ਇੱਕ ਸਮਾਂ ਲੜੀ ਡੇਟਾਬੇਸ ਇੱਕ ਆਉਣ ਵਾਲੀ ਚੋਣਵੀਂ ਪੁੱਛਗਿੱਛ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ।

• ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਨੂੰ ਸਭ ਕੁਝ ਮਿਲਦਾ ਹੈ timeseries_ids ਇੱਕ ਉਲਟ ਸੂਚਕਾਂਕ ਤੋਂ ਜਿਸ ਵਿੱਚ ਦਿੱਤੇ ਜੋੜੇ ਹੁੰਦੇ ਹਨ label=value, ਜਾਂ ਦਿੱਤੇ ਨਿਯਮਤ ਸਮੀਕਰਨ ਨੂੰ ਸੰਤੁਸ਼ਟ ਕਰੋ।
• ਫਿਰ ਇਹ ਲੱਭੇ ਗਏ ਲੋਕਾਂ ਲਈ ਇੱਕ ਦਿੱਤੇ ਸਮੇਂ ਦੇ ਅੰਤਰਾਲ 'ਤੇ ਡੇਟਾ ਸਟੋਰੇਜ ਤੋਂ ਸਾਰੇ ਡੇਟਾ ਪੁਆਇੰਟਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ timeseries_ids.
• ਇਸ ਤੋਂ ਬਾਅਦ, ਡੇਟਾਬੇਸ ਉਪਭੋਗਤਾ ਦੀ ਬੇਨਤੀ ਦੇ ਅਨੁਸਾਰ ਇਹਨਾਂ ਡੇਟਾ ਪੁਆਇੰਟਾਂ 'ਤੇ ਕੁਝ ਗਣਨਾ ਕਰਦਾ ਹੈ। ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਇਹ ਜਵਾਬ ਵਾਪਸ ਕਰਦਾ ਹੈ.

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

ਚਲੋ ਉਲਟੇ ਸੂਚਕਾਂਕ ਵੱਲ ਵਧਦੇ ਹਾਂ। ਕਈ ਸੋਚ ਸਕਦੇ ਹਨ ਕਿ ਇਹ ਸਧਾਰਨ ਹੈ. ਕੌਣ ਜਾਣਦਾ ਹੈ ਕਿ ਇੱਕ ਉਲਟ ਸੂਚਕਾਂਕ ਕੀ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ? ਓਹ, ਹੁਣ ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਨਹੀਂ ਹਨ. ਆਓ ਇਹ ਸਮਝਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ ਕਿ ਇਹ ਕੀ ਹੈ.

ਇਹ ਅਸਲ ਵਿੱਚ ਸਧਾਰਨ ਹੈ. ਇਹ ਸਿਰਫ਼ ਇੱਕ ਸ਼ਬਦਕੋਸ਼ ਹੈ ਜੋ ਇੱਕ ਮੁੱਲ ਦੀ ਕੁੰਜੀ ਨੂੰ ਮੈਪ ਕਰਦਾ ਹੈ। ਇੱਕ ਕੁੰਜੀ ਕੀ ਹੈ? ਇਹ ਜੋੜਾ label=valueਕਿੱਥੇ label и value - ਇਹ ਲਾਈਨਾਂ ਹਨ। ਅਤੇ ਮੁੱਲ ਇੱਕ ਸੈੱਟ ਹਨ timeseries_ids, ਜਿਸ ਵਿੱਚ ਦਿੱਤਾ ਗਿਆ ਜੋੜਾ ਸ਼ਾਮਲ ਹੈ label=value.

ਉਲਟਾ ਸੂਚਕਾਂਕ ਤੁਹਾਨੂੰ ਸਭ ਕੁਝ ਤੇਜ਼ੀ ਨਾਲ ਲੱਭਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ timeseries_ids, ਜੋ ਦਿੱਤੇ ਹਨ label=value.

ਇਹ ਤੁਹਾਨੂੰ ਜਲਦੀ ਲੱਭਣ ਦੀ ਵੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ timeseries_ids ਕਈ ਜੋੜਿਆਂ ਲਈ ਸਮਾਂ ਲੜੀ label=value, ਜਾਂ ਜੋੜਿਆਂ ਲਈ label=regexp. ਇਹ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ? ਸੈੱਟ ਦਾ ਲਾਂਘਾ ਲੱਭ ਕੇ timeseries_ids ਹਰੇਕ ਜੋੜੇ ਲਈ label=value.

ਆਉ ਉਲਟੇ ਸੂਚਕਾਂਕ ਦੇ ਵੱਖ-ਵੱਖ ਅਮਲਾਂ ਨੂੰ ਵੇਖੀਏ। ਆਉ ਸਭ ਤੋਂ ਸਰਲ ਸਧਾਰਨ ਅਮਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ। ਉਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ।

ਫੰਕਸ਼ਨ getMetricIDs ਸਤਰ ਦੀ ਇੱਕ ਸੂਚੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ. ਹਰ ਲਾਈਨ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ label=value. ਇਹ ਫੰਕਸ਼ਨ ਇੱਕ ਸੂਚੀ ਵਾਪਸ ਕਰਦਾ ਹੈ metricIDs.

ਕਿਦਾ ਚਲਦਾ? ਇੱਥੇ ਸਾਨੂੰ ਇੱਕ ਗਲੋਬਲ ਵੇਰੀਏਬਲ ਕਹਿੰਦੇ ਹਨ invertedIndex. ਇਹ ਇੱਕ ਨਿਯਮਤ ਸ਼ਬਦਕੋਸ਼ ਹੈ (map), ਜੋ ਕਿ ਸਤਰ ਨੂੰ ਇੰਟਸ ਨੂੰ ਮੈਪ ਕਰੇਗਾ। ਲਾਈਨ ਸ਼ਾਮਿਲ ਹੈ label=value.

ਫੰਕਸ਼ਨ ਲਾਗੂ ਕਰਨਾ: ਪ੍ਰਾਪਤ ਕਰੋ metricIDs ਪਹਿਲੇ ਲਈ label=value, ਫਿਰ ਅਸੀਂ ਹਰ ਚੀਜ਼ ਵਿੱਚੋਂ ਲੰਘਦੇ ਹਾਂ label=value, ਅਸੀਂ ਇਸਨੂੰ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ metricIDs ਓਹਨਾਂ ਲਈ. ਅਤੇ ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰੋ intersectInts, ਜਿਸ ਬਾਰੇ ਹੇਠਾਂ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ। ਅਤੇ ਇਹ ਫੰਕਸ਼ਨ ਇਹਨਾਂ ਸੂਚੀਆਂ ਦਾ ਇੰਟਰਸੈਕਸ਼ਨ ਵਾਪਸ ਕਰਦਾ ਹੈ।

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

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

ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਰੈਡੀਮੇਡ ਹੱਲ ਵਰਤ ਕੇ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਲੈਵਲਡੀਬੀ, ਜਾਂ ਰੌਕਸਡੀਬੀ.

ਸੰਖੇਪ ਵਿੱਚ, ਸਾਨੂੰ ਇੱਕ ਡੇਟਾਬੇਸ ਦੀ ਲੋੜ ਹੈ ਜੋ ਸਾਨੂੰ ਤਿੰਨ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

• ਪਹਿਲੀ ਕਾਰਵਾਈ ਰਿਕਾਰਡਿੰਗ ਹੈ ключ-значение ਇਸ ਡਾਟਾਬੇਸ ਨੂੰ. ਉਹ ਇਹ ਬਹੁਤ ਜਲਦੀ ਕਰਦੀ ਹੈ, ਜਿੱਥੇ ключ-значение ਆਪਹੁਦਰੇ ਸਤਰ ਹਨ।
• ਦੂਜੀ ਕਾਰਵਾਈ ਇੱਕ ਦਿੱਤੀ ਕੁੰਜੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਮੁੱਲ ਲਈ ਇੱਕ ਤੇਜ਼ ਖੋਜ ਹੈ।
• ਅਤੇ ਤੀਜੀ ਕਾਰਵਾਈ ਇੱਕ ਦਿੱਤੇ ਅਗੇਤਰ ਦੁਆਰਾ ਸਾਰੇ ਮੁੱਲਾਂ ਲਈ ਇੱਕ ਤੇਜ਼ ਖੋਜ ਹੈ।

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

ਇੱਕ ਉਲਟ ਸੂਚਕਾਂਕ ਨੂੰ LevelDB ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਕਿਵੇਂ ਕਰਨਾ ਹੈ? ਅਸੀਂ ਇੱਕ ਕੁੰਜੀ ਵਜੋਂ ਸੁਰੱਖਿਅਤ ਕਰਦੇ ਹਾਂ label=value. ਅਤੇ ਮੁੱਲ ਉਸ ਸਮੇਂ ਦੀ ਲੜੀ ਦਾ ਪਛਾਣਕਰਤਾ ਹੈ ਜਿੱਥੇ ਜੋੜਾ ਮੌਜੂਦ ਹੈ label=value.

ਜੇਕਰ ਸਾਡੇ ਕੋਲ ਇੱਕ ਦਿੱਤੇ ਜੋੜੇ ਦੇ ਨਾਲ ਕਈ ਵਾਰ ਲੜੀ ਹੈ label=value, ਫਿਰ ਇਸ ਡੇਟਾਬੇਸ ਵਿੱਚ ਇੱਕੋ ਕੁੰਜੀ ਅਤੇ ਵੱਖ-ਵੱਖ ਨਾਲ ਬਹੁਤ ਸਾਰੀਆਂ ਕਤਾਰਾਂ ਹੋਣਗੀਆਂ timeseries_ids. ਸਭ ਦੀ ਸੂਚੀ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ timeseries_ids, ਜੋ ਇਸ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ label=prefix, ਅਸੀਂ ਇੱਕ ਰੇਂਜ ਸਕੈਨ ਕਰਦੇ ਹਾਂ ਜਿਸ ਲਈ ਇਹ ਡੇਟਾਬੇਸ ਅਨੁਕੂਲ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਭਾਵ, ਅਸੀਂ ਸਾਰੀਆਂ ਲਾਈਨਾਂ ਚੁਣਦੇ ਹਾਂ ਜੋ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ label=prefix ਅਤੇ ਲੋੜੀਂਦਾ ਪ੍ਰਾਪਤ ਕਰੋ timeseries_ids.

ਗੋ ਵਿੱਚ ਇਹ ਕਿਹੋ ਜਿਹਾ ਦਿਖਾਈ ਦੇਵੇਗਾ ਇਸਦਾ ਇੱਕ ਨਮੂਨਾ ਲਾਗੂਕਰਨ ਇੱਥੇ ਹੈ। ਸਾਡੇ ਕੋਲ ਇੱਕ ਉਲਟ ਸੂਚਕਾਂਕ ਹੈ। ਇਹ LevelDB ਹੈ।

ਫੰਕਸ਼ਨ ਨਿਰਪੱਖ ਲਾਗੂ ਕਰਨ ਦੇ ਸਮਾਨ ਹੈ। ਇਹ ਭੋਲੇਪਣ ਨੂੰ ਲਗਭਗ ਲਾਈਨ ਦਰ ਲਾਈਨ ਦੁਹਰਾਉਂਦਾ ਹੈ। ਸਿਰਫ ਗੱਲ ਇਹ ਹੈ ਕਿ ਵੱਲ ਮੁੜਨ ਦੀ ਬਜਾਏ map ਅਸੀਂ ਉਲਟ ਸੂਚਕਾਂਕ ਤੱਕ ਪਹੁੰਚ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਪਹਿਲੇ ਲਈ ਸਾਰੇ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ label=value. ਫਿਰ ਅਸੀਂ ਬਾਕੀ ਸਾਰੇ ਜੋੜਿਆਂ ਵਿੱਚੋਂ ਲੰਘਦੇ ਹਾਂ label=value ਅਤੇ ਉਹਨਾਂ ਲਈ metricIDs ਦੇ ਅਨੁਸਾਰੀ ਸੈੱਟ ਪ੍ਰਾਪਤ ਕਰੋ। ਫਿਰ ਅਸੀਂ ਇੰਟਰਸੈਕਸ਼ਨ ਲੱਭਦੇ ਹਾਂ.

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

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

LevelDB ਵਿੱਚ, ਹਰ ਵਾਰ ਇੱਕ ਫੰਕਸ਼ਨ ਨੂੰ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ GetValues ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਸਾਰੀਆਂ ਲਾਈਨਾਂ ਵਿੱਚੋਂ ਲੰਘਣ ਦੀ ਲੋੜ ਹੈ ਜੋ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ label=value. ਅਤੇ ਹਰੇਕ ਲਾਈਨ ਲਈ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰੋ timeseries_ids. ਅਜਿਹੇ timeseries_ids ਇਹਨਾਂ ਦਾ ਇੱਕ ਟੁਕੜਾ ਇਕੱਠਾ ਕਰੋ timeseries_ids. ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਇਹ ਕੁੰਜੀ ਦੁਆਰਾ ਨਿਯਮਤ ਨਕਸ਼ੇ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਨਾਲੋਂ ਬਹੁਤ ਹੌਲੀ ਹੈ।

ਦੂਜੀ ਕਮੀ ਇਹ ਹੈ ਕਿ LevelDB C ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ। Go ਤੋਂ C ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਕਾਲ ਕਰਨਾ ਬਹੁਤ ਤੇਜ਼ ਨਹੀਂ ਹੈ। ਇਸ ਵਿੱਚ ਸੈਂਕੜੇ ਨੈਨੋ ਸਕਿੰਟ ਲੱਗਦੇ ਹਨ। ਇਹ ਬਹੁਤ ਤੇਜ਼ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਗੋ ਵਿੱਚ ਲਿਖੀ ਇੱਕ ਨਿਯਮਤ ਫੰਕਸ਼ਨ ਕਾਲ ਦੀ ਤੁਲਨਾ ਵਿੱਚ, ਜਿਸ ਵਿੱਚ 1-5 ਨੈਨੋ ਸਕਿੰਟ ਲੱਗਦੇ ਹਨ, ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਅੰਤਰ ਕਈ ਗੁਣਾ ਹੁੰਦਾ ਹੈ। ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਲਈ ਇਹ ਇੱਕ ਘਾਤਕ ਨੁਕਸ ਸੀ :)

ਇਸ ਲਈ ਮੈਂ ਉਲਟਾ ਸੂਚਕਾਂਕ ਦਾ ਆਪਣਾ ਖੁਦ ਦਾ ਅਮਲ ਲਿਖਿਆ। ਅਤੇ ਉਸਨੇ ਉਸਨੂੰ ਬੁਲਾਇਆ ਅਭੇਦ.

Mergeset MergeTree ਡਾਟਾ ਢਾਂਚੇ 'ਤੇ ਆਧਾਰਿਤ ਹੈ। ਇਹ ਡਾਟਾ ਢਾਂਚਾ ਕਲਿਕਹਾਊਸ ਤੋਂ ਉਧਾਰ ਲਿਆ ਗਿਆ ਹੈ। ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਮਰਜਸੈੱਟ ਨੂੰ ਤੇਜ਼ ਖੋਜ ਲਈ ਅਨੁਕੂਲ ਬਣਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ timeseries_ids ਦਿੱਤੀ ਕੁੰਜੀ ਦੇ ਅਨੁਸਾਰ. Mergeset ਪੂਰੀ ਤਰ੍ਹਾਂ ਗੋ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ। ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ GitHub 'ਤੇ ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਸਰੋਤ. mergeset ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਫੋਲਡਰ ਵਿੱਚ ਹੈ /lib/mergeset. ਤੁਸੀਂ ਇਹ ਪਤਾ ਲਗਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਉੱਥੇ ਕੀ ਹੋ ਰਿਹਾ ਹੈ।

mergeset API LevelDB ਅਤੇ RocksDB ਦੇ ਸਮਾਨ ਹੈ। ਭਾਵ, ਇਹ ਤੁਹਾਨੂੰ ਉੱਥੇ ਨਵੇਂ ਰਿਕਾਰਡਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸੁਰੱਖਿਅਤ ਕਰਨ ਅਤੇ ਦਿੱਤੇ ਅਗੇਤਰ ਦੁਆਰਾ ਰਿਕਾਰਡਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਚੁਣਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

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

ਉਹ ਕਿਉਂ ਪੈਦਾ ਹੋਏ?

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

ਦੂਜਾ ਕਾਰਨ ਸਮਾਂ ਲੜੀ ਦੀ ਵੱਡੀ ਗਿਣਤੀ ਹੈ। ਸ਼ੁਰੂ ਵਿੱਚ, ਜਦੋਂ ਨਿਗਰਾਨੀ ਪ੍ਰਸਿੱਧੀ ਪ੍ਰਾਪਤ ਕਰ ਰਹੀ ਸੀ, ਸਮੇਂ ਦੀ ਲੜੀ ਦੀ ਗਿਣਤੀ ਘੱਟ ਸੀ. ਉਦਾਹਰਨ ਲਈ, ਹਰੇਕ ਕੰਪਿਊਟਰ ਲਈ ਤੁਹਾਨੂੰ CPU, ਮੈਮੋਰੀ, ਨੈੱਟਵਰਕ ਅਤੇ ਡਿਸਕ ਲੋਡ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਪ੍ਰਤੀ ਕੰਪਿਊਟਰ 4 ਵਾਰ ਲੜੀ। ਮੰਨ ਲਓ ਕਿ ਤੁਹਾਡੇ ਕੋਲ 100 ਕੰਪਿਊਟਰ ਅਤੇ 400 ਟਾਈਮ ਸੀਰੀਜ਼ ਹਨ। ਇਹ ਬਹੁਤ ਘੱਟ ਹੈ।

ਸਮੇਂ ਦੇ ਨਾਲ, ਲੋਕਾਂ ਨੇ ਇਹ ਸਮਝ ਲਿਆ ਕਿ ਉਹ ਵਧੇਰੇ ਦਾਣੇਦਾਰ ਜਾਣਕਾਰੀ ਨੂੰ ਮਾਪ ਸਕਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਪੂਰੇ ਪ੍ਰੋਸੈਸਰ ਦੇ ਲੋਡ ਨੂੰ ਨਹੀਂ, ਪਰ ਹਰੇਕ ਪ੍ਰੋਸੈਸਰ ਕੋਰ ਦੇ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਮਾਪੋ। ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ 40 ਪ੍ਰੋਸੈਸਰ ਕੋਰ ਹਨ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਪ੍ਰੋਸੈਸਰ ਲੋਡ ਨੂੰ ਮਾਪਣ ਲਈ 40 ਗੁਣਾ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੜੀ ਹੈ।

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

ਇੱਕ ਮੈਟ੍ਰਿਕ ਤੋਂ ਸਾਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਕੰਪਿਊਟਰ ਲਈ 40 x 8 = 320 ਮੈਟ੍ਰਿਕਸ ਮਿਲੇ ਹਨ। 100 ਨਾਲ ਗੁਣਾ ਕਰਨ 'ਤੇ ਸਾਨੂੰ 32 ਦੀ ਬਜਾਏ 000 ਮਿਲਦਾ ਹੈ।

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

ਆਉ ਉੱਚ ਮੰਥਨ ਦਰ 'ਤੇ ਇੱਕ ਡੂੰਘੀ ਵਿਚਾਰ ਕਰੀਏ. ਉਤਪਾਦਨ ਵਿੱਚ ਉੱਚ ਮੰਥਨ ਦਰ ਦਾ ਕੀ ਕਾਰਨ ਹੈ? ਕਿਉਂਕਿ ਲੇਬਲ ਅਤੇ ਟੈਗਸ ਦੇ ਕੁਝ ਅਰਥ ਲਗਾਤਾਰ ਬਦਲ ਰਹੇ ਹਨ।

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

ਇਸ ਨਾਲ ਕੀ ਹੋਇਆ? ਇਸ ਤੋਂ ਇਲਾਵਾ, ਹਰੇਕ ਨਵੀਂ ਤੈਨਾਤੀ ਦੇ ਨਾਲ, ਸਾਰੀਆਂ ਪੁਰਾਣੀਆਂ ਸਮਾਂ ਲੜੀਵਾਂ ਵਿੱਚ ਵਿਘਨ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਦੀ ਬਜਾਏ, ਨਵੀਂ ਸਮਾਂ ਲੜੀ ਇੱਕ ਨਵੇਂ ਲੇਬਲ ਮੁੱਲ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। deployment_id. ਅਜਿਹੀਆਂ ਸੈਂਕੜੇ ਹਜ਼ਾਰਾਂ ਅਤੇ ਲੱਖਾਂ ਵੀ ਕਤਾਰਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ।

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

ਉੱਚ ਮੰਥਨ ਦਰ ਦੀ ਮੁੱਖ ਸਮੱਸਿਆ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸਮੇਂ ਦੇ ਅੰਤਰਾਲ 'ਤੇ ਲੇਬਲਾਂ ਦੇ ਦਿੱਤੇ ਸਮੂਹ ਲਈ ਹਰ ਸਮੇਂ ਦੀ ਲੜੀ ਲਈ ਨਿਰੰਤਰ ਖੋਜ ਗਤੀ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਆਖਰੀ ਘੰਟੇ ਜਾਂ ਆਖਰੀ ਦਿਨ ਲਈ ਸਮਾਂ ਅੰਤਰਾਲ ਹੁੰਦਾ ਹੈ।

ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕਰਨਾ ਹੈ? ਇੱਥੇ ਪਹਿਲਾ ਵਿਕਲਪ ਹੈ। ਇਹ ਸਮੇਂ ਦੇ ਨਾਲ ਉਲਟੇ ਸੂਚਕਾਂਕ ਨੂੰ ਸੁਤੰਤਰ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਣਾ ਹੈ। ਭਾਵ, ਕੁਝ ਸਮਾਂ ਅੰਤਰਾਲ ਲੰਘਦਾ ਹੈ, ਅਸੀਂ ਮੌਜੂਦਾ ਉਲਟ ਸੂਚਕਾਂਕ ਨਾਲ ਕੰਮ ਕਰਨਾ ਖਤਮ ਕਰਦੇ ਹਾਂ। ਅਤੇ ਇੱਕ ਨਵਾਂ ਉਲਟਾ ਸੂਚਕਾਂਕ ਬਣਾਓ। ਇੱਕ ਹੋਰ ਸਮਾਂ ਅੰਤਰਾਲ ਲੰਘਦਾ ਹੈ, ਅਸੀਂ ਇੱਕ ਹੋਰ ਅਤੇ ਦੂਜਾ ਬਣਾਉਂਦੇ ਹਾਂ.

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

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

ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਇੱਕ ਹੋਰ ਵਿਕਲਪ ਹੈ. ਇਹ ਹਰ ਦਿਨ ਲਈ ਉਸ ਦਿਨ ਆਈ ਟਾਈਮ ਸੀਰੀਜ਼ ਦੇ ਆਈਡੀ ਦੀ ਇੱਕ ਵੱਖਰੀ ਸੂਚੀ ਨੂੰ ਸਟੋਰ ਕਰਨਾ ਹੈ।

ਪਿਛਲੇ ਹੱਲ ਨਾਲੋਂ ਇਸ ਹੱਲ ਦਾ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਸਮਾਂ ਲੜੀ ਦੀ ਜਾਣਕਾਰੀ ਦੀ ਡੁਪਲੀਕੇਟ ਨਹੀਂ ਕਰਦੇ ਜੋ ਸਮੇਂ ਦੇ ਨਾਲ ਅਲੋਪ ਨਹੀਂ ਹੁੰਦੀ ਹੈ। ਉਹ ਲਗਾਤਾਰ ਮੌਜੂਦ ਹਨ ਅਤੇ ਬਦਲਦੇ ਨਹੀਂ ਹਨ।

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

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

ਅਸੀਂ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕੀਤਾ? ਅਸੀਂ ਇਸਨੂੰ ਇੱਕ ਅਸਲੀ ਤਰੀਕੇ ਨਾਲ ਹੱਲ ਕੀਤਾ - ਇੱਕ ਪਛਾਣਕਰਤਾ ਦੀ ਬਜਾਏ ਹਰੇਕ ਉਲਟ ਸੂਚਕਾਂਕ ਐਂਟਰੀ ਵਿੱਚ ਕਈ ਵਾਰ ਲੜੀ ਪਛਾਣਕਰਤਾਵਾਂ ਨੂੰ ਸਟੋਰ ਕਰਕੇ। ਯਾਨੀ ਸਾਡੇ ਕੋਲ ਇੱਕ ਕੁੰਜੀ ਹੈ label=value, ਜੋ ਹਰ ਵਾਰ ਲੜੀ ਵਿੱਚ ਵਾਪਰਦਾ ਹੈ। ਅਤੇ ਹੁਣ ਅਸੀਂ ਕਈਆਂ ਨੂੰ ਬਚਾਉਂਦੇ ਹਾਂ timeseries_ids ਇੱਕ ਇੰਦਰਾਜ਼ ਵਿੱਚ.

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

ਇਸ ਨਾਲ ਅਜਿਹੇ ਉਲਟ ਸੂਚਕਾਂਕ ਦੀ ਸਕੈਨਿੰਗ ਸਪੀਡ ਨੂੰ 10 ਗੁਣਾ ਤੱਕ ਵਧਾਉਣਾ ਸੰਭਵ ਹੋ ਗਿਆ। ਅਤੇ ਇਸਨੇ ਸਾਨੂੰ ਕੈਸ਼ ਲਈ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਨੂੰ ਘਟਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ, ਕਿਉਂਕਿ ਹੁਣ ਅਸੀਂ ਸਤਰ ਨੂੰ ਸਟੋਰ ਕਰਦੇ ਹਾਂ label=value N ਵਾਰ ਇਕੱਠੇ ਕੈਸ਼ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ। ਅਤੇ ਇਹ ਲਾਈਨ ਵੱਡੀ ਹੋ ਸਕਦੀ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਆਪਣੇ ਟੈਗਸ ਅਤੇ ਲੇਬਲਾਂ ਵਿੱਚ ਲੰਬੀਆਂ ਲਾਈਨਾਂ ਨੂੰ ਸਟੋਰ ਕਰਦੇ ਹੋ, ਜੋ ਕਿ ਕੁਬਰਨੇਟਸ ਉੱਥੇ ਹਿਲਾਉਣਾ ਪਸੰਦ ਕਰਦੇ ਹਨ।

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

ਹੁਣ ਅਸੀਂ ਆਪਣੀਆਂ ਭੇਡਾਂ - ਇੰਟਰਸੈਕਸ਼ਨ ਫੰਕਸ਼ਨ 'ਤੇ ਵਾਪਸ ਆਉਂਦੇ ਹਾਂ timeseries_ids. ਆਓ ਵਿਚਾਰ ਕਰੀਏ ਕਿ ਇੱਥੇ ਕੀ ਲਾਗੂ ਹੋ ਸਕਦੇ ਹਨ। ਇਹ ਫੰਕਸ਼ਨ ਤੁਹਾਨੂੰ ਲੱਭਣ ਲਈ ਸਹਾਇਕ ਹੈ timeseries_ids ਇੱਕ ਦਿੱਤੇ ਸੈੱਟ ਲਈ label=value.

ਪਹਿਲਾ ਵਿਕਲਪ ਇੱਕ ਭੋਲਾ ਅਮਲ ਹੈ. ਦੋ ਨੇਸਟਡ ਲੂਪ। ਇੱਥੇ ਸਾਨੂੰ ਫੰਕਸ਼ਨ ਇਨਪੁਟ ਮਿਲਦਾ ਹੈ intersectInts ਦੋ ਟੁਕੜੇ - a и b. ਆਉਟਪੁੱਟ 'ਤੇ, ਇਹ ਸਾਨੂੰ ਇਹਨਾਂ ਟੁਕੜਿਆਂ ਦੇ ਇੰਟਰਸੈਕਸ਼ਨ 'ਤੇ ਵਾਪਸ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇੱਕ ਭੋਲਾ ਅਮਲ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸਦਾ ਹੈ। ਅਸੀਂ ਟੁਕੜੇ ਤੋਂ ਸਾਰੇ ਮੁੱਲਾਂ ਨੂੰ ਦੁਹਰਾਉਂਦੇ ਹਾਂ a, ਇਸ ਲੂਪ ਦੇ ਅੰਦਰ ਅਸੀਂ ਸਲਾਈਸ ਦੇ ਸਾਰੇ ਮੁੱਲਾਂ ਵਿੱਚੋਂ ਲੰਘਦੇ ਹਾਂ b. ਅਤੇ ਅਸੀਂ ਉਹਨਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹਾਂ. ਜੇਕਰ ਉਹ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਤਾਂ ਅਸੀਂ ਇੱਕ ਇੰਟਰਸੈਕਸ਼ਨ ਲੱਭ ਲਿਆ ਹੈ। ਅਤੇ ਇਸ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕਰੋ result.

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

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

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

ਨਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਇਸ ਨਕਸ਼ੇ ਨੂੰ ਬਣਾਉਣ ਲਈ ਇਸ ਫੰਕਸ਼ਨ ਨੂੰ ਵਧੇਰੇ ਮੈਮੋਰੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

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

ਇਹਨਾਂ ਥਾਵਾਂ 'ਤੇ CPU ਦਾ ਸਮਾਂ ਕਿਉਂ ਬਰਬਾਦ ਹੁੰਦਾ ਹੈ? ਕਿਉਂਕਿ ਗੋ ਇਹਨਾਂ ਲਾਈਨਾਂ 'ਤੇ ਹੈਸ਼ਿੰਗ ਆਪਰੇਸ਼ਨ ਕਰਦਾ ਹੈ। ਭਾਵ, ਇਹ ਹੈਸ਼ਮੈਪ ਵਿੱਚ ਦਿੱਤੇ ਸੂਚਕਾਂਕ 'ਤੇ ਇਸ ਨੂੰ ਐਕਸੈਸ ਕਰਨ ਲਈ ਕੁੰਜੀ ਦੇ ਹੈਸ਼ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ। ਹੈਸ਼ ਕੈਲਕੂਲੇਸ਼ਨ ਓਪਰੇਸ਼ਨ ਦਸ ਨੈਨੋ ਸਕਿੰਟਾਂ ਵਿੱਚ ਪੂਰਾ ਹੁੰਦਾ ਹੈ। ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਲਈ ਇਹ ਹੌਲੀ ਹੈ।

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

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਮੈਪ ਲਾਗੂ ਕਰਨ ਦੇ ਮੁਕਾਬਲੇ ਬਹੁਤ ਘੱਟ ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਕਿਉਂਕਿ ਅਸੀਂ ਇੱਥੇ ਅੱਠ-ਬਾਈਟ ਮੁੱਲਾਂ ਦੀ ਬਜਾਏ ਬਿੱਟ ਸਟੋਰ ਕਰ ਰਹੇ ਹਾਂ।

ਇਸ ਲਾਗੂ ਕਰਨ ਦਾ ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਇਹ ਇੰਨਾ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ, ਮਾਮੂਲੀ ਨਹੀਂ ਹੈ.

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

ਆਉ ਇਸ ਢਾਂਚੇ ਨੂੰ ਲਾਗੂ ਕਰਨ ਬਾਰੇ ਵਿਚਾਰ ਕਰੀਏ. ਜੇਕਰ ਤੁਸੀਂ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਹ ਫੋਲਡਰ ਵਿੱਚ ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਸਰੋਤਾਂ ਵਿੱਚ ਸਥਿਤ ਹੈ lib/uint64set. ਇਹ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਕੇਸ ਲਈ ਅਨੁਕੂਲਿਤ ਹੈ, ਜਿੱਥੇ timeseries_id ਇੱਕ 64-ਬਿੱਟ ਮੁੱਲ ਹੈ, ਜਿੱਥੇ ਪਹਿਲੇ 32 ਬਿੱਟ ਅਸਲ ਵਿੱਚ ਸਥਿਰ ਹੁੰਦੇ ਹਨ ਅਤੇ ਸਿਰਫ਼ ਆਖਰੀ 32 ਬਿੱਟ ਬਦਲਦੇ ਹਨ।

ਇਹ ਡਾਟਾ ਢਾਂਚਾ ਡਿਸਕ 'ਤੇ ਸਟੋਰ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਇਹ ਸਿਰਫ ਮੈਮੋਰੀ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ।

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

ਫੰਕਸ਼ਨ ਹਨ add, ਜੋ ਨਵੇਂ ਮੁੱਲ ਜੋੜਦਾ ਹੈ। ਇੱਕ ਫੰਕਸ਼ਨ ਹੈ has, ਜੋ ਨਵੇਂ ਮੁੱਲਾਂ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਅਤੇ ਇੱਕ ਫੰਕਸ਼ਨ ਹੈ del, ਜੋ ਮੁੱਲਾਂ ਨੂੰ ਹਟਾਉਂਦਾ ਹੈ। ਇੱਕ ਸਹਾਇਕ ਫੰਕਸ਼ਨ ਹੈ len, ਜੋ ਸੈੱਟ ਦਾ ਆਕਾਰ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਫੰਕਸ਼ਨ clone ਬਹੁਤ ਸਾਰੇ ਕਲੋਨ. ਅਤੇ ਫੰਕਸ਼ਨ appendto ਇਸ ਸੈੱਟ ਨੂੰ ਟੁਕੜੇ ਵਿੱਚ ਬਦਲਦਾ ਹੈ timeseries_ids.

ਇਸ ਡੇਟਾ ਢਾਂਚੇ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਸੈੱਟ ਦੇ ਦੋ ਤੱਤ ਹਨ:

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

• ਦੂਜਾ ਖੇਤਰ ਹੈ buckets. ਇਹ ਬਣਤਰ ਤੋਂ ਟੁਕੜਾ ਹੈ bucket32. ਹਰ ਢਾਂਚਾ ਸਟੋਰ ਕਰਦਾ ਹੈ hi ਖੇਤਰ. ਇਹ ਉਪਰਲੇ 32 ਬਿੱਟ ਹਨ। ਅਤੇ ਦੋ ਟੁਕੜੇ - b16his и buckets ਤੱਕ bucket16 ਬਣਤਰ.

16-ਬਿੱਟ ਢਾਂਚੇ ਦੇ ਦੂਜੇ ਭਾਗ ਦੇ ਸਿਖਰਲੇ 64 ਬਿੱਟ ਇੱਥੇ ਸਟੋਰ ਕੀਤੇ ਗਏ ਹਨ। ਅਤੇ ਇੱਥੇ ਹਰ ਬਾਈਟ ਦੇ ਹੇਠਲੇ 16 ਬਿੱਟਾਂ ਲਈ ਬਿੱਟਸੈੱਟ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

Bucket64 ਇੱਕ ਐਰੇ ਦੇ ਸ਼ਾਮਲ ਹਨ uint64. ਇਹਨਾਂ ਸਥਿਰਾਂਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲੰਬਾਈ ਦੀ ਗਣਨਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਵਿੱਚ bucket16 ਵੱਧ ਤੋਂ ਵੱਧ ਸਟੋਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ 2^16=65536 ਬਿੱਟ ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਨੂੰ 8 ਨਾਲ ਵੰਡਦੇ ਹੋ, ਤਾਂ ਇਹ 8 ਕਿਲੋਬਾਈਟ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਦੁਬਾਰਾ 8 ਨਾਲ ਭਾਗ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ 1000 ਹੈ uint64 ਮਤਲਬ ਜੋ ਕਿ ਹੈ Bucket16 - ਇਹ ਸਾਡਾ 8-ਕਿਲੋਬਾਈਟ ਢਾਂਚਾ ਹੈ।

ਆਉ ਦੇਖੀਏ ਕਿ ਇੱਕ ਨਵਾਂ ਮੁੱਲ ਜੋੜਨ ਲਈ ਇਸ ਢਾਂਚੇ ਦੇ ਇੱਕ ਢੰਗ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਇਹ ਸਭ ਦੇ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ uint64 ਅਰਥ. ਅਸੀਂ ਉਪਰਲੇ 32 ਬਿੱਟਾਂ ਦੀ ਗਣਨਾ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਹੇਠਲੇ 32 ਬਿੱਟਾਂ ਦੀ ਗਣਨਾ ਕਰਦੇ ਹਾਂ। ਆਓ ਹਰ ਚੀਜ਼ ਵਿੱਚੋਂ ਲੰਘੀਏ buckets. ਅਸੀਂ ਜੋੜੇ ਜਾ ਰਹੇ ਮੁੱਲ ਦੇ ਨਾਲ ਹਰੇਕ ਬਾਲਟੀ ਵਿੱਚ ਚੋਟੀ ਦੇ 32 ਬਿੱਟਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹਾਂ। ਅਤੇ ਜੇਕਰ ਉਹ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਤਾਂ ਅਸੀਂ ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਾਂ add ਬਣਤਰ ਵਿੱਚ b32 buckets. ਅਤੇ ਉੱਥੇ ਹੇਠਲੇ 32 ਬਿੱਟ ਜੋੜੋ। ਅਤੇ ਜੇ ਇਹ ਵਾਪਸ ਆ ਗਿਆ true, ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਉੱਥੇ ਅਜਿਹਾ ਮੁੱਲ ਜੋੜਿਆ ਹੈ ਅਤੇ ਸਾਡੇ ਕੋਲ ਅਜਿਹਾ ਮੁੱਲ ਨਹੀਂ ਹੈ। ਜੇ ਇਹ ਵਾਪਸ ਆਉਂਦਾ ਹੈ false, ਫਿਰ ਅਜਿਹਾ ਅਰਥ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਸੀ। ਫਿਰ ਅਸੀਂ ਢਾਂਚੇ ਵਿੱਚ ਤੱਤਾਂ ਦੀ ਗਿਣਤੀ ਵਧਾਉਂਦੇ ਹਾਂ।

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

ਇਹ ਫੰਕਸ਼ਨ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਹੈ b32.add. ਇਹ ਪਿਛਲੇ ਲਾਗੂ ਕਰਨ ਦੇ ਸਮਾਨ ਹੈ. ਅਸੀਂ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ 16 ਬਿੱਟਾਂ ਦੀ ਗਣਨਾ ਕਰਦੇ ਹਾਂ, ਸਭ ਤੋਂ ਘੱਟ ਮਹੱਤਵਪੂਰਨ 16 ਬਿੱਟ।

ਫਿਰ ਅਸੀਂ ਸਾਰੇ ਉਪਰਲੇ 16 ਬਿੱਟਾਂ ਵਿੱਚੋਂ ਲੰਘਦੇ ਹਾਂ। ਅਸੀਂ ਮੈਚ ਲੱਭਦੇ ਹਾਂ। ਅਤੇ ਜੇਕਰ ਕੋਈ ਮੇਲ ਹੈ, ਤਾਂ ਅਸੀਂ ਐਡ ਵਿਧੀ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਾਂ, ਜਿਸ ਬਾਰੇ ਅਸੀਂ ਅਗਲੇ ਪੰਨੇ 'ਤੇ ਵਿਚਾਰ ਕਰਾਂਗੇ bucket16.

ਅਤੇ ਇੱਥੇ ਸਭ ਤੋਂ ਨੀਵਾਂ ਪੱਧਰ ਹੈ, ਜਿਸ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਅਨੁਕੂਲ ਬਣਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ. ਅਸੀਂ ਲਈ ਗਣਨਾ ਕਰਦੇ ਹਾਂ uint64 ਸਲਾਈਸ ਬਿੱਟ ਵਿੱਚ id ਮੁੱਲ ਅਤੇ ਇਹ ਵੀ bitmask. ਇਹ ਦਿੱਤੇ ਗਏ 64-ਬਿੱਟ ਮੁੱਲ ਲਈ ਇੱਕ ਮਾਸਕ ਹੈ, ਜਿਸਦੀ ਵਰਤੋਂ ਇਸ ਬਿੱਟ ਦੀ ਮੌਜੂਦਗੀ ਦੀ ਜਾਂਚ ਕਰਨ, ਜਾਂ ਇਸਨੂੰ ਸੈੱਟ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਅਸੀਂ ਇਹ ਦੇਖਣ ਲਈ ਜਾਂਚ ਕਰਦੇ ਹਾਂ ਕਿ ਕੀ ਇਹ ਬਿੱਟ ਸੈੱਟ ਹੈ ਅਤੇ ਇਸਨੂੰ ਸੈੱਟ ਕਰੋ, ਅਤੇ ਮੌਜੂਦਗੀ ਵਾਪਸ ਕਰੋ। ਇਹ ਸਾਡਾ ਲਾਗੂਕਰਨ ਹੈ, ਜਿਸ ਨੇ ਸਾਨੂੰ ਰਵਾਇਤੀ ਨਕਸ਼ਿਆਂ ਦੇ ਮੁਕਾਬਲੇ 10 ਗੁਣਾ ਸਮਾਂ ਲੜੀ ਦੇ ਇੰਟਰਸੈਕਟਿੰਗ ਆਈਡੀ ਦੇ ਸੰਚਾਲਨ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਹੈ।

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

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

ਮੇਰੇ ਕੋਲ ਬਿੱਟਸੈੱਟ ਬਾਰੇ ਇੱਕ ਸਵਾਲ ਹੈ। C++ ਵੈਕਟਰ ਬੂਲ ਲਾਗੂ ਕਰਨ ਦੇ ਸਮਾਨ, ਅਨੁਕੂਲਿਤ ਬਿੱਟਸੈੱਟ। ਕੀ ਤੁਸੀਂ ਉਥੋਂ ਲਾਗੂ ਕੀਤਾ ਸੀ?

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

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

ਮੇਰਾ ਦੂਜਾ ਸਵਾਲ ਹੈ। InfluxDB ਤੋਂ ਬੁਨਿਆਦੀ ਅੰਤਰ ਕੀ ਹੈ?

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

ਦੂਜਾ ਬੁਨਿਆਦੀ ਅੰਤਰ ਇਹ ਹੈ ਕਿ InfluxDB ਕੋਲ ਅਜੀਬ ਪੁੱਛਗਿੱਛ ਭਾਸ਼ਾਵਾਂ ਹਨ - ਫਲੈਕਸ ਅਤੇ ਇਨਫਲੂਕਸਕਿਯੂਐਲ. ਦੇ ਮੁਕਾਬਲੇ ਸਮਾਂ ਲੜੀ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਉਹ ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ ਨਹੀਂ ਹਨ PromQL, ਜੋ ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਦੁਆਰਾ ਸਮਰਥਿਤ ਹੈ। PromQL ਪ੍ਰੋਮੀਥੀਅਸ ਦੀ ਇੱਕ ਪੁੱਛਗਿੱਛ ਭਾਸ਼ਾ ਹੈ।

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

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

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

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

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

ਮੈਂ ਤੁਰੰਤ ਦੂਜੇ ਦਾ ਜਵਾਬ ਦਿਆਂਗਾ। ਅਸੀਂ ਅਜੇ ਉਸ ਬਿੰਦੂ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚੇ ਹਾਂ। ਪਰ ਜੇ ਲੋੜ ਪਈ ਤਾਂ ਅਸੀਂ ਉੱਥੇ ਪਹੁੰਚਾਂਗੇ। ਅਤੇ ਪਹਿਲਾ, ਸਵਾਲ ਕੀ ਸੀ?

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

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

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

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

ਅਸੀਂ ਡੇਟਾ ਨੂੰ ਪਾਰ ਕਰਨ ਲਈ ਕਰਸਰਾਂ ਦੀ ਵਰਤੋਂ ਕਿਉਂ ਨਹੀਂ ਕਰਦੇ?

ਹਾਂ

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

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

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

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

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

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

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

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

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

ਇਕ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾ ਇਹ ਹੈ ਕਿ ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ ਇਸ ਡੇਟਾ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਸੰਕੁਚਿਤ ਕਰਦਾ ਹੈ। ਉਤਪਾਦਨ ਵਿੱਚ ਔਸਤਨ ਕੰਪਰੈਸ਼ਨ 0,4 ਤੋਂ 0,8 ਬਾਈਟ ਪ੍ਰਤੀ ਬਿੰਦੂ ਤੱਕ ਹੈ। ਹਰੇਕ ਬਿੰਦੂ ਇੱਕ ਟਾਈਮਸਟੈਂਪ + ਮੁੱਲ ਹੈ। ਅਤੇ ਇਸਨੂੰ ਔਸਤਨ ਇੱਕ ਬਾਈਟ ਤੋਂ ਘੱਟ ਵਿੱਚ ਸੰਕੁਚਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਸਰਗੇਈ. ਮੇਰੇ ਕੋਲ ਇੱਕ ਸਵਾਲ ਹੈ. ਘੱਟੋ-ਘੱਟ ਰਿਕਾਰਡਿੰਗ ਸਮਾਂ ਕੁਆਂਟਮ ਕੀ ਹੈ?

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

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

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

ਤੁਹਾਡਾ ਧੰਨਵਾਦ! ਅਤੇ ਇੱਕ ਹੋਰ ਸਵਾਲ. PromQL ਵਿੱਚ ਅਨੁਕੂਲਤਾ ਕੀ ਹੈ?

ਪੂਰੀ ਬੈਕਵਰਡ ਅਨੁਕੂਲਤਾ। VictoriaMetrics ਪੂਰੀ ਤਰ੍ਹਾਂ PromQL ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ PromQL ਵਿੱਚ ਅਤਿਰਿਕਤ ਉੱਨਤ ਕਾਰਜਸ਼ੀਲਤਾ ਜੋੜਦਾ ਹੈ, ਜਿਸਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ MetricsQL. ਇਸ ਵਿਸਤ੍ਰਿਤ ਕਾਰਜਸ਼ੀਲਤਾ ਬਾਰੇ ਯੂਟਿਊਬ 'ਤੇ ਚਰਚਾ ਹੈ। ਮੈਂ ਸੇਂਟ ਪੀਟਰਸਬਰਗ ਵਿੱਚ ਬਸੰਤ ਵਿੱਚ ਨਿਗਰਾਨੀ ਮੀਟਿੰਗ ਵਿੱਚ ਗੱਲ ਕੀਤੀ ਸੀ।

ਟੈਲੀਗ੍ਰਾਮ ਚੈਨਲ ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ.

ਸਿਰਫ਼ ਰਜਿਸਟਰਡ ਉਪਭੋਗਤਾ ਹੀ ਸਰਵੇਖਣ ਵਿੱਚ ਹਿੱਸਾ ਲੈ ਸਕਦੇ ਹਨ। ਸਾਈਨ - ਇਨ, ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ.

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

• 71,4%ਮੈਂ Prometheus5 ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦਾ

• 28,6%VictoriaMetrics2 ਬਾਰੇ ਪਤਾ ਨਹੀਂ ਸੀ

7 ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਵੋਟ ਕੀਤਾ। 12 ਉਪਭੋਗਤਾ ਬਚੇ ਹੋਏ ਹਨ।

ਸਰੋਤ: www.habr.com