PostgreSQL ਸਵਾਲਾਂ ਦਾ ਬਲਕ ਓਪਟੀਮਾਈਜੇਸ਼ਨ। ਕਿਰਿਲ ਬੋਰੋਵਿਕੋਵ (ਟੈਂਸਰ)

ਰਿਪੋਰਟ ਕੁਝ ਪਹੁੰਚ ਪੇਸ਼ ਕਰਦੀ ਹੈ ਜੋ ਆਗਿਆ ਦਿੰਦੀ ਹੈ SQL ਸਵਾਲਾਂ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ ਜਦੋਂ ਉਹ ਪ੍ਰਤੀ ਦਿਨ ਲੱਖਾਂ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇੱਥੇ ਸੈਂਕੜੇ ਨਿਗਰਾਨੀ ਕੀਤੇ PostgreSQL ਸਰਵਰ ਹਨ।

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

ਕੌਣ ਦਿਲਚਸਪੀ ਰੱਖਦਾ ਹੈ? ਖਾਸ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਵੱਖ-ਵੱਖ ਅਨੁਕੂਲਨ ਤਕਨੀਕਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ SQL ਸਵਾਲ ਅਤੇ PostgreSQL ਵਿੱਚ ਖਾਸ DBA ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨਾ - ਤੁਸੀਂ ਇਹ ਵੀ ਕਰ ਸਕਦੇ ਹੋ ਲੇਖਾਂ ਦੀ ਇੱਕ ਲੜੀ ਪੜ੍ਹੋ ਇਸ ਵਿਸ਼ੇ 'ਤੇ.


ਮੇਰਾ ਨਾਮ ਕਿਰਿਲ ਬੋਰੋਵਿਕੋਵ ਹੈ, ਮੈਂ ਪ੍ਰਤੀਨਿਧਤਾ ਕਰਦਾ ਹਾਂ ਟੈਂਸਰ ਕੰਪਨੀ. ਖਾਸ ਤੌਰ 'ਤੇ, ਮੈਂ ਸਾਡੀ ਕੰਪਨੀ ਵਿੱਚ ਡੇਟਾਬੇਸ ਨਾਲ ਕੰਮ ਕਰਨ ਵਿੱਚ ਮਾਹਰ ਹਾਂ।

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

ਆਮ ਤੌਰ 'ਤੇ, ਸਾਡੇ ਇੱਕ ਮਿਲੀਅਨ ਗਾਹਕਾਂ ਲਈ ਟੈਂਸਰ ਹੈ VLSI ਸਾਡੀ ਅਰਜ਼ੀ ਹੈ: ਕਾਰਪੋਰੇਟ ਸੋਸ਼ਲ ਨੈਟਵਰਕ, ਵੀਡੀਓ ਸੰਚਾਰ ਲਈ ਹੱਲ, ਅੰਦਰੂਨੀ ਅਤੇ ਬਾਹਰੀ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਪ੍ਰਵਾਹ ਲਈ, ਲੇਖਾਕਾਰੀ ਅਤੇ ਵੇਅਰਹਾਊਸਾਂ ਲਈ ਲੇਖਾ ਪ੍ਰਣਾਲੀਆਂ,... ਅਰਥਾਤ, ਏਕੀਕ੍ਰਿਤ ਵਪਾਰ ਪ੍ਰਬੰਧਨ ਲਈ ਅਜਿਹਾ "ਮੈਗਾ-ਕੰਬਾਈਨ", ਜਿਸ ਵਿੱਚ 100 ਤੋਂ ਵੱਧ ਵੱਖ-ਵੱਖ ਹਨ। ਅੰਦਰੂਨੀ ਪ੍ਰਾਜੈਕਟ.

ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਉਹ ਸਾਰੇ ਕੰਮ ਕਰਦੇ ਹਨ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਵਿਕਾਸ ਕਰਦੇ ਹਨ, ਸਾਡੇ ਕੋਲ ਦੇਸ਼ ਭਰ ਵਿੱਚ 10 ਵਿਕਾਸ ਕੇਂਦਰ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਹੋਰ ਵੀ ਹਨ 1000 ਡਿਵੈਲਪਰ.

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

SQL ਇੱਕ ਘੋਸ਼ਣਾਤਮਕ ਭਾਸ਼ਾ ਹੈ। ਤੁਸੀਂ ਵਰਣਨ ਨਹੀਂ ਕਰਦੇ ਹੋ ਕਿ "ਕਿਵੇਂ" ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ "ਕੀ" ਤੁਸੀਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। DBMS ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਸ਼ਾਮਲ ਹੋਣਾ ਹੈ - ਤੁਹਾਡੀਆਂ ਟੇਬਲਾਂ ਨੂੰ ਕਿਵੇਂ ਜੋੜਨਾ ਹੈ, ਕਿਹੜੀਆਂ ਸ਼ਰਤਾਂ ਲਾਗੂ ਕਰਨੀਆਂ ਹਨ, ਸੂਚਕਾਂਕ ਵਿੱਚੋਂ ਕੀ ਲੰਘੇਗਾ, ਕੀ ਨਹੀਂ...

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

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

ਆਮ ਤੌਰ 'ਤੇ, ਇੱਕ ਡਿਵੈਲਪਰ [ਡੀਬੀਏ ਲਈ] ਆਮ ਤੌਰ 'ਤੇ ਕਿਹੜੀਆਂ ਕਲਾਸਿਕ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਆਉਂਦਾ ਹੈ? "ਇੱਥੇ ਅਸੀਂ ਬੇਨਤੀ ਨੂੰ ਪੂਰਾ ਕੀਤਾ, ਅਤੇ ਸਾਡੇ ਨਾਲ ਸਭ ਕੁਝ ਹੌਲੀ ਹੈ, ਸਭ ਕੁਝ ਲਟਕ ਰਿਹਾ ਹੈ, ਕੁਝ ਹੋ ਰਿਹਾ ਹੈ... ਕਿਸੇ ਕਿਸਮ ਦੀ ਮੁਸੀਬਤ!"

ਕਾਰਨ ਲਗਭਗ ਹਮੇਸ਼ਾ ਇੱਕੋ ਜਿਹੇ ਹੁੰਦੇ ਹਨ:

• ਅਕੁਸ਼ਲ ਪੁੱਛਗਿੱਛ ਐਲਗੋਰਿਦਮ
  ਡਿਵੈਲਪਰ: “ਹੁਣ ਮੈਂ ਉਸਨੂੰ ਜੁਆਇਨ ਰਾਹੀਂ SQL ਵਿੱਚ 10 ਟੇਬਲ ਦੇ ਰਿਹਾ ਹਾਂ...” - ਅਤੇ ਉਮੀਦ ਕਰਦਾ ਹੈ ਕਿ ਉਸਦੀ ਸਥਿਤੀ ਚਮਤਕਾਰੀ ਢੰਗ ਨਾਲ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ "ਖੁੱਲੀ" ਹੋ ਜਾਵੇਗੀ ਅਤੇ ਉਸਨੂੰ ਸਭ ਕੁਝ ਜਲਦੀ ਮਿਲ ਜਾਵੇਗਾ। ਪਰ ਚਮਤਕਾਰ ਨਹੀਂ ਵਾਪਰਦੇ, ਅਤੇ ਅਜਿਹੀ ਪਰਿਵਰਤਨਸ਼ੀਲਤਾ ਵਾਲਾ ਕੋਈ ਵੀ ਸਿਸਟਮ (ਇੱਕ ਤੋਂ 10 ਟੇਬਲ) ਹਮੇਸ਼ਾ ਕਿਸੇ ਕਿਸਮ ਦੀ ਗਲਤੀ ਦਿੰਦਾ ਹੈ। [ਲੇਖ]
• ਅਪ੍ਰਸੰਗਿਕ ਅੰਕੜੇ
  ਇਹ ਬਿੰਦੂ ਖਾਸ ਤੌਰ 'ਤੇ PostgreSQL ਲਈ ਬਹੁਤ ਢੁਕਵਾਂ ਹੈ, ਜਦੋਂ ਤੁਸੀਂ ਸਰਵਰ 'ਤੇ ਇੱਕ ਵੱਡਾ ਡੇਟਾਸੈਟ "ਡੋਲ੍ਹਿਆ" ਹੈ, ਇੱਕ ਬੇਨਤੀ ਕਰੋ, ਅਤੇ ਇਹ ਤੁਹਾਡੀ ਟੈਬਲੇਟ ਨੂੰ "ਸੈਕਸਕੈਨਿਟ" ਕਰਦਾ ਹੈ। ਕਿਉਂਕਿ ਕੱਲ੍ਹ ਇਸ ਵਿੱਚ 10 ਰਿਕਾਰਡ ਸਨ, ਅਤੇ ਅੱਜ 10 ਮਿਲੀਅਨ ਹਨ, ਪਰ PostgreSQL ਅਜੇ ਤੱਕ ਇਸ ਬਾਰੇ ਜਾਣੂ ਨਹੀਂ ਹੈ, ਅਤੇ ਸਾਨੂੰ ਇਸ ਬਾਰੇ ਦੱਸਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. [ਲੇਖ]
• ਸਰੋਤਾਂ 'ਤੇ "ਪਲੱਗ"
  ਤੁਸੀਂ ਇੱਕ ਕਮਜ਼ੋਰ ਸਰਵਰ ਉੱਤੇ ਇੱਕ ਵੱਡਾ ਅਤੇ ਭਾਰੀ ਲੋਡ ਕੀਤਾ ਡਾਟਾਬੇਸ ਸਥਾਪਿਤ ਕੀਤਾ ਹੈ ਜਿਸ ਵਿੱਚ ਲੋੜੀਂਦੀ ਡਿਸਕ, ਮੈਮੋਰੀ, ਜਾਂ ਪ੍ਰੋਸੈਸਰ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨਹੀਂ ਹੈ। ਅਤੇ ਇਹ ਸਭ ਕੁਝ ਹੈ... ਕਿਤੇ ਨਾ ਕਿਤੇ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਛੱਤ ਹੈ ਜਿਸ ਤੋਂ ਤੁਸੀਂ ਹੁਣ ਛਾਲ ਨਹੀਂ ਮਾਰ ਸਕਦੇ।
• ਬਲਾਕਿੰਗ
  ਇਹ ਇੱਕ ਮੁਸ਼ਕਲ ਬਿੰਦੂ ਹੈ, ਪਰ ਇਹ ਵੱਖ-ਵੱਖ ਸੋਧਣ ਵਾਲੀਆਂ ਪੁੱਛਗਿੱਛਾਂ (ਇਨਸਰਟ, ਅੱਪਡੇਟ, ਮਿਟਾਓ) ਲਈ ਸਭ ਤੋਂ ਢੁਕਵੇਂ ਹਨ - ਇਹ ਇੱਕ ਵੱਖਰਾ ਵੱਡਾ ਵਿਸ਼ਾ ਹੈ।

ਇੱਕ ਯੋਜਨਾ ਪ੍ਰਾਪਤ ਕਰ ਰਿਹਾ ਹੈ

...ਅਤੇ ਹਰ ਚੀਜ਼ ਲਈ ਅਸੀਂ ਇੱਕ ਯੋਜਨਾ ਦੀ ਲੋੜ ਹੈ! ਸਾਨੂੰ ਇਹ ਦੇਖਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਸਰਵਰ ਦੇ ਅੰਦਰ ਕੀ ਹੋ ਰਿਹਾ ਹੈ।

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

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

ਪੁੱਛਗਿੱਛ ਯੋਜਨਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਬਿਆਨ ਨੂੰ ਚਲਾਉਣਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਹੈ EXPLAIN. ਸਾਰੀਆਂ ਅਸਲ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਨਾਲ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਭਾਵ, ਅਸਲ ਵਿੱਚ ਅਧਾਰ 'ਤੇ ਇੱਕ ਪੁੱਛਗਿੱਛ ਨੂੰ ਚਲਾਉਣ ਲਈ - EXPLAIN (ANALYZE, BUFFERS) SELECT ....

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

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

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

ਹੁਣ ਸਭ ਕੁਝ ਠੀਕ ਜਾਪਦਾ ਹੈ, ਅਸੀਂ ਲੌਗ 'ਤੇ ਜਾਂਦੇ ਹਾਂ ਅਤੇ ਉੱਥੇ ਦੇਖਦੇ ਹਾਂ... [ਟੈਕਸਟ ਫੁੱਟਕਲੌਥ]। ਪਰ ਅਸੀਂ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿ ਸਕਦੇ, ਇਸ ਤੱਥ ਤੋਂ ਇਲਾਵਾ ਕਿ ਇਹ ਇੱਕ ਸ਼ਾਨਦਾਰ ਯੋਜਨਾ ਹੈ ਕਿਉਂਕਿ ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ 11ms ਦਾ ਸਮਾਂ ਲੱਗਾ।

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

ਪਰ ਭਾਵੇਂ ਇਹ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ, ਭਾਵੇਂ ਇਹ ਅਸੁਵਿਧਾਜਨਕ ਹੈ, ਹੋਰ ਬੁਨਿਆਦੀ ਸਮੱਸਿਆਵਾਂ ਹਨ:

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

ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ, ਸਮਝੋ "ਸਭ ਤੋਂ ਕਮਜ਼ੋਰ ਕੜੀ ਕੌਣ ਹੈ?" ਲਗਭਗ ਅਸੰਭਵ. ਇਸ ਲਈ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਡਿਵੈਲਪਰ ਆਪਣੇ ਆਪ ਨੂੰ "ਮੈਨੁਅਲ" ਵਿੱਚ ਲਿਖਦੇ ਹਨ "ਯੋਜਨਾ ਨੂੰ ਸਮਝਣਾ ਇੱਕ ਕਲਾ ਹੈ ਜੋ ਸਿੱਖੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਨੁਭਵ...".

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

ਯੋਜਨਾ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ

ਇਸ ਲਈ, ਅਸੀਂ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਇਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਨਜਿੱਠਣ ਲਈ, ਸਾਨੂੰ ਲੋੜ ਹੈ ਯੋਜਨਾ ਦੀ ਚੰਗੀ ਕਲਪਨਾ. [ਲੇਖ]

ਅਸੀਂ ਪਹਿਲਾਂ "ਮਾਰਕੀਟ ਦੁਆਰਾ" ਗਏ - ਆਓ ਇਹ ਵੇਖਣ ਲਈ ਇੰਟਰਨੈਟ 'ਤੇ ਵੇਖੀਏ ਕਿ ਕੀ ਮੌਜੂਦ ਹੈ।

ਪਰ ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਇੱਥੇ ਬਹੁਤ ਘੱਟ ਮੁਕਾਬਲਤਨ "ਲਾਈਵ" ਹੱਲ ਹਨ ਜੋ ਘੱਟ ਜਾਂ ਘੱਟ ਵਿਕਾਸਸ਼ੀਲ ਹਨ - ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ, ਸਿਰਫ ਇੱਕ: explain.depesz.com Hubert Lubaczewski ਦੁਆਰਾ. ਜਦੋਂ ਤੁਸੀਂ "ਫੀਡ" ਖੇਤਰ ਵਿੱਚ ਪਲਾਨ ਦੀ ਇੱਕ ਟੈਕਸਟ ਪ੍ਰਤੀਨਿਧਤਾ ਦਰਜ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਤੁਹਾਨੂੰ ਪਾਰਸ ਕੀਤੇ ਡੇਟਾ ਦੇ ਨਾਲ ਇੱਕ ਸਾਰਣੀ ਦਿਖਾਉਂਦਾ ਹੈ:

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

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

ਪਰ ਛੋਟੀਆਂ-ਛੋਟੀਆਂ ਸਮੱਸਿਆਵਾਂ ਵੀ ਹਨ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, "ਕਾਪੀ-ਪੇਸਟ" ਦੀ ਇੱਕ ਵੱਡੀ ਮਾਤਰਾ. ਤੁਸੀਂ ਲੌਗ ਦਾ ਇੱਕ ਟੁਕੜਾ ਲੈਂਦੇ ਹੋ, ਇਸਨੂੰ ਉੱਥੇ ਚਿਪਕਾਉਂਦੇ ਹੋ, ਅਤੇ ਦੁਬਾਰਾ, ਅਤੇ ਦੁਬਾਰਾ.

ਦੂਜਾ, ਪੜ੍ਹੇ ਗਏ ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਦਾ ਕੋਈ ਵਿਸ਼ਲੇਸ਼ਣ ਨਹੀਂ — ਉਹੀ ਬਫਰ ਜੋ ਆਉਟਪੁੱਟ ਕਰਦੇ ਹਨ EXPLAIN (ANALYZE, BUFFERS), ਅਸੀਂ ਇਸਨੂੰ ਇੱਥੇ ਨਹੀਂ ਦੇਖਦੇ। ਉਹ ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਵੱਖ ਕਰਨਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਸਮਝਣਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨਾਲ ਕੰਮ ਕਰਨਾ ਹੈ. ਜਦੋਂ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰਾ ਡਾਟਾ ਪੜ੍ਹ ਰਹੇ ਹੋ ਅਤੇ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਡਿਸਕ ਅਤੇ ਮੈਮੋਰੀ ਕੈਸ਼ ਨੂੰ ਗਲਤ ਵੰਡ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਜਾਣਕਾਰੀ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ।

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

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

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

ਫਿਰ ਸਾਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਇਹ ਸਾਡੇ ਆਪਣੇ ਲਿਖਣ ਦਾ ਸਮਾਂ ਸੀ - ਹੁਰੇ! ਹਰ ਡਿਵੈਲਪਰ ਕਹਿੰਦਾ ਹੈ: "ਹੁਣ ਅਸੀਂ ਆਪਣੇ ਆਪ ਲਿਖਾਂਗੇ, ਇਹ ਬਹੁਤ ਆਸਾਨ ਹੋਵੇਗਾ!"

ਅਸੀਂ ਵੈੱਬ ਸੇਵਾਵਾਂ ਲਈ ਖਾਸ ਸਟੈਕ ਲਿਆ: Node.js + Express 'ਤੇ ਆਧਾਰਿਤ ਇੱਕ ਕੋਰ, ਸੁੰਦਰ ਚਿੱਤਰਾਂ ਲਈ Bootstrap ਅਤੇ D3.js ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ। ਅਤੇ ਸਾਡੀਆਂ ਉਮੀਦਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਜਾਇਜ਼ ਸਨ - ਸਾਨੂੰ 2 ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਪਹਿਲਾ ਪ੍ਰੋਟੋਟਾਈਪ ਪ੍ਰਾਪਤ ਹੋਇਆ:

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

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

ਇਹ ਸੰਖੇਪ ਪ੍ਰਤੀਨਿਧਤਾ ਹੈ ਜਿਸਨੂੰ ਅਸੀਂ ਕਹਿੰਦੇ ਹਾਂ ਯੋਜਨਾ ਟੈਪਲੇਟ.

ਹੋਰ ਕੀ ਸੁਵਿਧਾਜਨਕ ਹੋਵੇਗਾ? ਇਹ ਦੇਖਣਾ ਸੁਵਿਧਾਜਨਕ ਹੋਵੇਗਾ ਕਿ ਸਾਡੇ ਕੁੱਲ ਸਮੇਂ ਦਾ ਕਿਹੜਾ ਹਿੱਸਾ ਕਿਸ ਨੋਡ ਲਈ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੈ - ਅਤੇ ਸਿਰਫ ਇਸ ਨੂੰ ਪਾਸੇ 'ਤੇ ਚਿਪਕਾਓ ਪਾਈ ਚਾਰਟ.

ਅਸੀਂ ਨੋਡ 'ਤੇ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਾਂ ਅਤੇ ਦੇਖਦੇ ਹਾਂ - ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਸੀਕ ਸਕੈਨ ਨੇ ਕੁੱਲ ਸਮੇਂ ਦੇ ਇੱਕ ਚੌਥਾਈ ਤੋਂ ਵੀ ਘੱਟ ਸਮਾਂ ਲਿਆ, ਅਤੇ ਬਾਕੀ 3/4 CTE ਸਕੈਨ ਦੁਆਰਾ ਲਿਆ ਗਿਆ ਸੀ। ਡਰ! ਇਹ CTE ਸਕੈਨ ਦੀ "ਅੱਗ ਦੀ ਦਰ" ਬਾਰੇ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਨੋਟ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਆਪਣੇ ਸਵਾਲਾਂ ਵਿੱਚ ਸਰਗਰਮੀ ਨਾਲ ਵਰਤਦੇ ਹੋ। ਉਹ ਬਹੁਤ ਤੇਜ਼ ਨਹੀਂ ਹਨ - ਉਹ ਨਿਯਮਤ ਟੇਬਲ ਸਕੈਨਿੰਗ ਤੋਂ ਵੀ ਘਟੀਆ ਹਨ। [ਲੇਖ] [ਲੇਖ]

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

ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਕੁਝ "ਰੇਕ" ਸ਼ਾਮਲ ਸਨ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਅਸੀਂ ਆਏ, ਉਹ ਸੀ ਗੋਲਿੰਗ ਸਮੱਸਿਆ। ਯੋਜਨਾ ਵਿੱਚ ਹਰੇਕ ਵਿਅਕਤੀਗਤ ਨੋਡ ਦਾ ਸਮਾਂ 1 μs ਦੀ ਸ਼ੁੱਧਤਾ ਨਾਲ ਦਰਸਾਇਆ ਗਿਆ ਹੈ। ਅਤੇ ਜਦੋਂ ਨੋਡ ਚੱਕਰਾਂ ਦੀ ਸੰਖਿਆ ਵੱਧ ਜਾਂਦੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ, 1000 - ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਤੋਂ ਬਾਅਦ PostgreSQL ਨੂੰ "ਸ਼ੁੱਧਤਾ ਦੇ ਅੰਦਰ" ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਜਦੋਂ ਵਾਪਸ ਗਣਨਾ ਕਰਦੇ ਹਾਂ ਤਾਂ ਅਸੀਂ "ਕਿਤੇ 0.95ms ਅਤੇ 1.05ms ਵਿਚਕਾਰ" ਕੁੱਲ ਸਮਾਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ। ਜਦੋਂ ਗਿਣਤੀ ਮਾਈਕ੍ਰੋਸਕਿੰਡ ਵਿੱਚ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਠੀਕ ਹੈ, ਪਰ ਜਦੋਂ ਇਹ ਪਹਿਲਾਂ ਹੀ [ਮਿਲੀ] ਸਕਿੰਟ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ "ਕਿਸਨੇ ਕਿੰਨਾ ਖਪਤ ਕੀਤਾ" ਯੋਜਨਾ ਦੇ ਨੋਡਾਂ ਵਿੱਚ ਸਰੋਤਾਂ ਨੂੰ "ਖੁੱਲ" ਕਰਨ ਵੇਲੇ ਇਸ ਜਾਣਕਾਰੀ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਹੋਵੇਗਾ।

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

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

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

ਵਾਸਤਵ ਵਿੱਚ, ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਇੱਥੇ ਉਹ ਸਾਰੇ 3 ​​ਪੰਨਿਆਂ ਦੇ ਡੇਟਾ ਹਨ ਜੋ ਸੇਕ ਸਕੈਨ ਤੋਂ ਮੰਗੇ ਗਏ ਸਨ, ਪਹਿਲਾਂ 1 ਨੇ 1st CTE ਸਕੈਨ ਲਈ ਕਿਹਾ, ਅਤੇ ਫਿਰ 2, ਅਤੇ 2 ਹੋਰ ਉਸਨੂੰ ਪੜ੍ਹੇ ਗਏ ਸਨ। 3 ਪੰਨਿਆਂ ਦਾ ਡਾਟਾ ਪੜ੍ਹਿਆ ਗਿਆ ਸੀ, 6 ਨਹੀਂ।

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

ਅਸੀਂ ਕੁਝ ਦੇਰ ਲਈ ਸਾਹ ਛੱਡਿਆ. ਉਨ੍ਹਾਂ ਨੇ ਕਿਹਾ: “ਹੁਣ, ਨੀਓ, ਤੁਸੀਂ ਕੁੰਗ ਫੂ ਨੂੰ ਜਾਣਦੇ ਹੋ! ਹੁਣ ਸਾਡਾ ਅਨੁਭਵ ਤੁਹਾਡੀ ਸਕਰੀਨ 'ਤੇ ਸਹੀ ਹੈ। ਹੁਣ ਤੁਸੀਂ ਇਸਨੂੰ ਵਰਤ ਸਕਦੇ ਹੋ।" [ਲੇਖ]

ਲੌਗ ਏਕੀਕਰਨ

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

ਆਮ ਤੌਰ 'ਤੇ, ਇੱਥੇ ਇੱਕ ਮਿਆਰੀ ਮੋਡੀਊਲ ਹੁੰਦਾ ਹੈ ਜੋ ਅੰਕੜੇ ਇਕੱਠੇ ਕਰ ਸਕਦਾ ਹੈ, ਹਾਲਾਂਕਿ, ਇਸਨੂੰ ਸੰਰਚਨਾ ਵਿੱਚ ਕਿਰਿਆਸ਼ੀਲ ਕਰਨ ਦੀ ਵੀ ਲੋੜ ਹੁੰਦੀ ਹੈ - ਇਹ pg_stat_statements ਮੋਡੀਊਲ. ਪਰ ਉਹ ਸਾਡੇ ਅਨੁਕੂਲ ਨਹੀਂ ਸੀ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਇੱਕੋ ਡੇਟਾਬੇਸ ਦੇ ਅੰਦਰ ਵੱਖ-ਵੱਖ ਸਕੀਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕੋ ਸਵਾਲਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਵੱਖ-ਵੱਖ ਪੁੱਛਗਿੱਛ ਆਈਡਜ਼. ਇਹ ਹੈ, ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਕਰਦੇ ਹੋ SET search_path = '01'; SELECT * FROM user LIMIT 1;ਅਤੇ ਫਿਰ SET search_path = '02'; ਅਤੇ ਉਹੀ ਬੇਨਤੀ, ਤਾਂ ਇਸ ਮੋਡੀਊਲ ਦੇ ਅੰਕੜਿਆਂ ਦੇ ਵੱਖ-ਵੱਖ ਰਿਕਾਰਡ ਹੋਣਗੇ, ਅਤੇ ਮੈਂ ਸਕੀਮਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖੇ ਬਿਨਾਂ, ਖਾਸ ਤੌਰ 'ਤੇ ਇਸ ਬੇਨਤੀ ਪ੍ਰੋਫਾਈਲ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਆਮ ਅੰਕੜੇ ਇਕੱਠੇ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵਾਂਗਾ।

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

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

ਇਸ ਲਈ, ਅਸੀਂ ਕਾਪੀ-ਪੇਸਟ ਲੜਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਅਤੇ ਲਿਖਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਕੁਲੈਕਟਰ.

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

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

ਇਸ ਅਨੁਸਾਰ, ਅਸੀਂ ਦੋ ਕੁਨੈਕਸ਼ਨਾਂ ਨੂੰ "ਖਿੱਚਦੇ" ਹਾਂ: ਪਹਿਲਾ ਲੌਗ ਨੂੰ "ਸੁਣਨਾ" ਅਤੇ ਇਸਨੂੰ ਆਪਣੇ ਕੋਲ ਲੈ ਜਾਣਾ, ਅਤੇ ਦੂਜਾ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਅਧਾਰ ਨੂੰ ਪੁੱਛਣਾ। "ਪਰ ਲੌਗ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ oid 123 ਵਾਲਾ ਚਿੰਨ੍ਹ ਬਲੌਕ ਕੀਤਾ ਗਿਆ ਹੈ," ਪਰ ਇਸਦਾ ਡਿਵੈਲਪਰ ਲਈ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ, ਅਤੇ ਡੇਟਾਬੇਸ ਨੂੰ ਪੁੱਛਣਾ ਚੰਗਾ ਹੋਵੇਗਾ, "OID = 123 ਫਿਰ ਵੀ ਕੀ ਹੈ?" ਅਤੇ ਇਸ ਲਈ ਅਸੀਂ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਅਧਾਰ ਨੂੰ ਪੁੱਛਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਅਜੇ ਆਪਣੇ ਬਾਰੇ ਕੀ ਨਹੀਂ ਜਾਣਦੇ ਹਾਂ।

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

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

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

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

ਦੂਜਾ, ਅਸੀਂ ਸਿੱਖਿਆ (ਮਜ਼ਬੂਰ ਹੋਏ) ਬਹੁਤ, ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਲਿਖਣ ਲਈ COPY. ਹੈ, ਨਾ ਸਿਰਫ਼ COPYਕਿਉਂਕਿ ਉਹ ਵੱਧ ਤੇਜ਼ ਹੈ INSERT, ਅਤੇ ਹੋਰ ਵੀ ਤੇਜ਼।

ਤੀਜਾ ਨੁਕਤਾ - ਮੈਨੂੰ ਕਰਨਾ ਪਿਆ ਕ੍ਰਮਵਾਰ ਟਰਿਗਰ ਅਤੇ ਵਿਦੇਸ਼ੀ ਕੁੰਜੀਆਂ ਨੂੰ ਛੱਡ ਦਿਓ. ਭਾਵ, ਸਾਡੇ ਕੋਲ ਕੋਈ ਵੀ ਸੰਦਰਭ ਅਖੰਡਤਾ ਨਹੀਂ ਹੈ। ਕਿਉਂਕਿ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਟੇਬਲ ਹੈ ਜਿਸ ਵਿੱਚ FKs ਦਾ ਇੱਕ ਜੋੜਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਢਾਂਚੇ ਵਿੱਚ ਕਹਿੰਦੇ ਹੋ ਕਿ "ਇੱਥੇ ਇੱਕ ਲੌਗ ਰਿਕਾਰਡ ਹੈ ਜਿਸਦਾ FK ਦੁਆਰਾ ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਰਿਕਾਰਡਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਲਈ," ਫਿਰ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਸੰਮਿਲਿਤ ਕਰਦੇ ਹੋ, ਤਾਂ PostgreSQL ਕੁਝ ਨਹੀਂ ਬਚਿਆ ਪਰ ਇਸ ਨੂੰ ਕਿਵੇਂ ਲੈਣਾ ਹੈ ਅਤੇ ਇਮਾਨਦਾਰੀ ਨਾਲ ਕਰਨਾ ਹੈ SELECT 1 FROM master_fk1_table WHERE ... ਪਛਾਣਕਰਤਾ ਦੇ ਨਾਲ ਜੋ ਤੁਸੀਂ ਸੰਮਿਲਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ - ਸਿਰਫ਼ ਇਹ ਦੇਖਣ ਲਈ ਕਿ ਇਹ ਰਿਕਾਰਡ ਉੱਥੇ ਮੌਜੂਦ ਹੈ, ਕਿ ਤੁਸੀਂ ਆਪਣੇ ਸੰਮਿਲਨ ਨਾਲ ਇਸ ਵਿਦੇਸ਼ੀ ਕੁੰਜੀ ਨੂੰ "ਬੰਦ" ਨਹੀਂ ਕਰਦੇ।

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

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

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

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

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

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

ਪਰ ਇਹ ਸਭ ਤੇਜ਼ੀ ਨਾਲ ਰਿਕਾਰਡ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਰਿਕਾਰਡਿੰਗ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਆਪਣੇ ਆਪ ਵਿੱਚ ਸੋਧਣ ਦੀ ਲੋੜ ਸੀ।

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

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

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

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

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

ਡੇਟਾ ਰਿਕਾਰਡਿੰਗ ਲਈ ਇਸ ਪਹੁੰਚ ਨੂੰ ਪੇਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਸਾਡੇ ਕੋਲ ਲਗਭਗ 4K ਰਾਈਟ ਓਪ ਸਨ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਅਸੀਂ ਲੋਡ ਨੂੰ 4 ਗੁਣਾ ਘਟਾ ਦਿੱਤਾ। ਹੁਣ ਉਹ ਨਵੇਂ ਨਿਰੀਖਣ ਕੀਤੇ ਡੇਟਾਬੇਸ ਦੇ ਕਾਰਨ 6 ਗੁਣਾ ਹੋਰ ਵਧ ਗਏ ਹਨ - 100MB/s ਤੱਕ। ਅਤੇ ਹੁਣ ਅਸੀਂ ਪਿਛਲੇ 3 ਮਹੀਨਿਆਂ ਦੇ ਲੌਗਸ ਨੂੰ ਲਗਭਗ 10-15TB ਦੀ ਮਾਤਰਾ ਵਿੱਚ ਸਟੋਰ ਕਰਦੇ ਹਾਂ, ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ ਸਿਰਫ਼ ਤਿੰਨ ਮਹੀਨਿਆਂ ਵਿੱਚ ਕੋਈ ਵੀ ਵਿਕਾਸਕਾਰ ਕਿਸੇ ਵੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੇ ਯੋਗ ਹੋਵੇਗਾ।

ਅਸੀਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਸਮਝਦੇ ਹਾਂ

ਪਰ ਸਿਰਫ਼ ਇਹ ਸਾਰਾ ਡਾਟਾ ਇਕੱਠਾ ਕਰਨਾ ਚੰਗਾ, ਉਪਯੋਗੀ, ਢੁਕਵਾਂ ਹੈ, ਪਰ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ - ਇਸਨੂੰ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ. ਕਿਉਂਕਿ ਇਹ ਪ੍ਰਤੀ ਦਿਨ ਲੱਖਾਂ ਵੱਖ-ਵੱਖ ਯੋਜਨਾਵਾਂ ਹਨ।

ਪਰ ਲੱਖਾਂ ਬੇਕਾਬੂ ਹਨ, ਸਾਨੂੰ ਪਹਿਲਾਂ "ਛੋਟਾ" ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਅਤੇ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਇਹ ਫੈਸਲਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸ "ਛੋਟੀ" ਚੀਜ਼ ਨੂੰ ਕਿਵੇਂ ਸੰਗਠਿਤ ਕਰੋਗੇ.

ਅਸੀਂ ਤਿੰਨ ਮੁੱਖ ਨੁਕਤਿਆਂ ਦੀ ਪਛਾਣ ਕੀਤੀ ਹੈ:

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

ਇਹ ਸਮਝਣ ਲਈ ਕਿ "ਕਿਸਨੇ" ਨੇ ਸਾਨੂੰ ਇੱਕ ਬੇਨਤੀ ਭੇਜੀ ਹੈ, ਅਸੀਂ ਇੱਕ ਸਟੈਂਡਰਡ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ - ਇੱਕ ਸੈਸ਼ਨ ਵੇਰੀਏਬਲ ਸੈੱਟ ਕਰਨਾ: SET application_name = '{bl-host}:{bl-method}'; - ਅਸੀਂ ਵਪਾਰਕ ਤਰਕ ਹੋਸਟ ਦਾ ਨਾਮ ਭੇਜਦੇ ਹਾਂ ਜਿੱਥੋਂ ਬੇਨਤੀ ਆਉਂਦੀ ਹੈ, ਅਤੇ ਵਿਧੀ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਨਾਮ ਜਿਸਨੇ ਇਸਨੂੰ ਸ਼ੁਰੂ ਕੀਤਾ ਹੈ।

ਸਾਡੇ ਦੁਆਰਾ ਬੇਨਤੀ ਦੇ "ਮਾਲਕ" ਨੂੰ ਪਾਸ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਇਹ ਲੌਗ ਵਿੱਚ ਆਉਟਪੁੱਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ - ਇਸਦੇ ਲਈ ਅਸੀਂ ਵੇਰੀਏਬਲ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਦੇ ਹਾਂ log_line_prefix = ' %m [%p:%v] [%d] %r %a'. ਦਿਲਚਸਪੀ ਰੱਖਣ ਵਾਲਿਆਂ ਲਈ, ਹੋ ਸਕਦਾ ਹੈ ਮੈਨੂਅਲ ਵਿੱਚ ਵੇਖੋਇਸ ਸਭ ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਅਸੀਂ ਲੌਗ ਵਿੱਚ ਦੇਖਦੇ ਹਾਂ:

• время
• ਪ੍ਰਕਿਰਿਆ ਅਤੇ ਲੈਣ-ਦੇਣ ਪਛਾਣਕਰਤਾ
• ਡਾਟਾਬੇਸ ਦਾ ਨਾਮ
• ਇਸ ਬੇਨਤੀ ਨੂੰ ਭੇਜਣ ਵਾਲੇ ਵਿਅਕਤੀ ਦਾ ਆਈ.ਪੀ
• ਅਤੇ ਢੰਗ ਦਾ ਨਾਮ

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

ਇਸ ਲਈ ਇੱਥੇ ਕੱਟ ਹੈ "ਇੱਕ ਸਰਵਰ - ਇੱਕ ਦਿਨ" ਇਹ ਕਿਸੇ ਵੀ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਸਾਡੇ ਲਈ ਕਾਫੀ ਸਾਬਤ ਹੋਇਆ।

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

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

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

ਬਾਕੀ ਦੇ ਤਰੀਕੇ ਉਹਨਾਂ ਸੂਚਕਾਂ 'ਤੇ ਅਧਾਰਤ ਹਨ ਜੋ ਅਸੀਂ ਯੋਜਨਾ ਤੋਂ ਕੱਢਦੇ ਹਾਂ: ਕਿੰਨੀ ਵਾਰ ਅਜਿਹਾ ਪੈਟਰਨ ਆਇਆ, ਕੁੱਲ ਅਤੇ ਔਸਤ ਸਮਾਂ, ਡਿਸਕ ਤੋਂ ਕਿੰਨਾ ਡਾਟਾ ਪੜ੍ਹਿਆ ਗਿਆ, ਅਤੇ ਮੈਮੋਰੀ ਤੋਂ ਕਿੰਨਾ...

ਕਿਉਂਕਿ, ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਹੋਸਟ ਲਈ ਵਿਸ਼ਲੇਸ਼ਣ ਪੰਨੇ 'ਤੇ ਆਉਂਦੇ ਹੋ, ਦੇਖੋ - ਕੁਝ ਡਿਸਕ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪੜ੍ਹਨਾ ਸ਼ੁਰੂ ਕਰ ਰਿਹਾ ਹੈ. ਸਰਵਰ 'ਤੇ ਡਿਸਕ ਇਸ ਨੂੰ ਸੰਭਾਲ ਨਹੀਂ ਸਕਦੀ - ਇਸ ਤੋਂ ਕੌਣ ਪੜ੍ਹਦਾ ਹੈ?

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

ਅਤੇ ਤੁਰੰਤ ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ ਜੋ ਕਿ ਇੱਕ ਬੇਨਤੀ ਤੋਂ ਇੱਕੋ ਟੈਂਪਲੇਟ ਨਾਲ ਆਉਂਦੇ ਹਨ SELECT * FROM users WHERE login = 'Vasya'. ਫਰੰਟਐਂਡ, ਬੈਕਐਂਡ, ਪ੍ਰੋਸੈਸਿੰਗ... ਅਤੇ ਤੁਸੀਂ ਹੈਰਾਨ ਹੋਵੋਗੇ ਕਿ ਪ੍ਰੋਸੈਸਿੰਗ ਉਪਭੋਗਤਾ ਨੂੰ ਕਿਉਂ ਪੜ੍ਹੇਗੀ ਜੇਕਰ ਉਹ ਉਸ ਨਾਲ ਇੰਟਰੈਕਟ ਨਹੀਂ ਕਰਦਾ ਹੈ।

ਉਲਟ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਤੁਰੰਤ ਇਹ ਵੇਖਣਾ ਕਿ ਇਹ ਕੀ ਕਰਦਾ ਹੈ. ਉਦਾਹਰਨ ਲਈ, ਫਰੰਟਐਂਡ ਇਹ ਹੈ, ਇਹ, ਇਹ, ਅਤੇ ਇਹ ਇੱਕ ਘੰਟੇ ਵਿੱਚ ਇੱਕ ਵਾਰ (ਟਾਈਮਲਾਈਨ ਮਦਦ ਕਰਦੀ ਹੈ)। ਅਤੇ ਸਵਾਲ ਤੁਰੰਤ ਉੱਠਦਾ ਹੈ: ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਇੱਕ ਘੰਟੇ ਵਿੱਚ ਇੱਕ ਵਾਰ ਕੁਝ ਕਰਨਾ ਫਰੰਟਐਂਡ ਦਾ ਕੰਮ ਨਹੀਂ ਹੈ ...

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

ਤੁਹਾਡੇ ਕੋਲ ਪਲੇਟ 'ਤੇ ਕੋਈ ਢੁਕਵਾਂ ਸੂਚਕਾਂਕ ਨਹੀਂ ਹੈ, ਤੁਸੀਂ ਇਸ ਨੂੰ ਬੇਨਤੀ ਕਰਦੇ ਹੋ, ਇਹ ਸੂਚਕਾਂਕ ਤੋਂ ਲੰਘਦਾ ਹੈ, ਸੇਕ ਸਕੈਨ ਵਿੱਚ ਆਉਂਦਾ ਹੈ... ਤੁਸੀਂ ਇੱਕ ਨੂੰ ਛੱਡ ਕੇ ਸਾਰੇ ਰਿਕਾਰਡਾਂ ਨੂੰ ਫਿਲਟਰ ਕਰ ਦਿੱਤਾ ਹੈ। ਤੁਹਾਨੂੰ ਪ੍ਰਤੀ ਦਿਨ 100M ਫਿਲਟਰ ਕੀਤੇ ਰਿਕਾਰਡਾਂ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ? ਕੀ ਇੰਡੈਕਸ ਨੂੰ ਰੋਲ ਅਪ ਕਰਨਾ ਬਿਹਤਰ ਨਹੀਂ ਹੈ?

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

ਹਰ ਕੋਈ ਜਿਸ ਨੇ ਸਵਾਲ ਲਿਖੇ ਹਨ, ਸ਼ਾਇਦ ਇਸ ਪੈਟਰਨ ਦਾ ਸਾਹਮਣਾ ਕੀਤਾ ਹੈ: "ਮੈਨੂੰ ਵਾਸਿਆ ਲਈ ਆਖਰੀ ਆਰਡਰ ਦਿਓ, ਇਸਦੀ ਤਾਰੀਖ। ਬਿਲਕੁਲ ਉਸੇ "ਰੇਕ" 'ਤੇ ਕਦਮ ਰੱਖੋ।

ਪਰ ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਇਹ ਇੱਕ "ਰੇਕ" ਹੈ - ਤਾਂ ਕਿਉਂ ਨਾ ਡਿਵੈਲਪਰ ਨੂੰ ਤੁਰੰਤ ਦੱਸੋ ਕਿ ਉਸਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਅਨੁਸਾਰ, ਜਦੋਂ ਹੁਣ ਕੋਈ ਯੋਜਨਾ ਖੋਲ੍ਹਦੇ ਹੋ, ਤਾਂ ਸਾਡੇ ਡਿਵੈਲਪਰ ਤੁਰੰਤ ਸੁਝਾਅ ਦੇ ਨਾਲ ਇੱਕ ਸੁੰਦਰ ਤਸਵੀਰ ਵੇਖਦੇ ਹਨ, ਜਿੱਥੇ ਉਹ ਤੁਰੰਤ ਉਸਨੂੰ ਕਹਿੰਦੇ ਹਨ: "ਤੁਹਾਨੂੰ ਇੱਥੇ ਅਤੇ ਉੱਥੇ ਸਮੱਸਿਆਵਾਂ ਹਨ, ਪਰ ਉਹ ਇਸ ਤਰੀਕੇ ਨਾਲ ਹੱਲ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।"

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

ਸਰੋਤ: www.habr.com