ਅਸੀਂ ਸਬਲਾਈਟ 'ਤੇ PostgreSQL ਵਿੱਚ ਲਿਖਦੇ ਹਾਂ: 1 ਹੋਸਟ, 1 ਦਿਨ, 1TB

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

#1। ਸੈਕਸ਼ਨਿੰਗ

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

"ਬੀਤੇ ਦਿਨਾਂ ਦੀਆਂ ਗੱਲਾਂ..."

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

ਸਮਾਂ ਲਗਭਗ ਮਹਾਂਕਾਵਿ ਸਮਿਆਂ ਵਾਂਗ ਸੀ, PostgreSQL 9.x ਦੇ ਵੱਖੋ-ਵੱਖਰੇ ਸੰਸਕਰਣ ਢੁਕਵੇਂ ਸਨ, ਇਸਲਈ ਸਾਰੀਆਂ ਵੰਡਾਂ ਨੂੰ "ਹੱਥੀਂ" ਕਰਨਾ ਪੈਂਦਾ ਸੀ - ਦੁਆਰਾ ਸਾਰਣੀ ਵਿਰਾਸਤ ਅਤੇ ਟਰਿਗਰਸ ਗਤੀਸ਼ੀਲ ਨਾਲ ਰੂਟਿੰਗ EXECUTE.

ਨਤੀਜਾ ਹੱਲ ਇੰਨਾ ਸਰਵ ਵਿਆਪਕ ਨਿਕਲਿਆ ਕਿ ਇਸਨੂੰ ਸਾਰੀਆਂ ਟੇਬਲਾਂ ਵਿੱਚ ਅਨੁਵਾਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

• ਇੱਕ ਖਾਲੀ "ਸਿਰਲੇਖ" ਪੇਰੈਂਟ ਟੇਬਲ ਘੋਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਸੀ, ਜਿਸ ਵਿੱਚ ਸਭ ਦਾ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਸੀ ਜ਼ਰੂਰੀ ਸੂਚਕਾਂਕ ਅਤੇ ਟਰਿਗਰਸ.
• ਕਲਾਇੰਟ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਰਿਕਾਰਡ "ਰੂਟ" ਸਾਰਣੀ ਵਿੱਚ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਅਤੇ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਵਰਤ ਕੇ ਰੂਟਿੰਗ ਟਰਿੱਗਰ BEFORE INSERT ਰਿਕਾਰਡ ਨੂੰ "ਸਰੀਰਕ ਤੌਰ 'ਤੇ" ਲੋੜੀਂਦੇ ਭਾਗ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਸੀ। ਜੇ ਅਜੇ ਤੱਕ ਅਜਿਹੀ ਕੋਈ ਚੀਜ਼ ਨਹੀਂ ਸੀ, ਤਾਂ ਅਸੀਂ ਇੱਕ ਅਪਵਾਦ ਫੜਿਆ ਅਤੇ...
• … ਵਰਤ ਕੇ CREATE TABLE ... (LIKE ... INCLUDING ...) ਪੇਰੈਂਟ ਟੇਬਲ ਦੇ ਟੈਮਪਲੇਟ ਦੇ ਅਧਾਰ ਤੇ ਬਣਾਇਆ ਗਿਆ ਸੀ ਲੋੜੀਦੀ ਮਿਤੀ 'ਤੇ ਪਾਬੰਦੀ ਦੇ ਨਾਲ ਭਾਗਇਸ ਲਈ ਜਦੋਂ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਰੀਡਿੰਗ ਸਿਰਫ ਇਸ ਵਿੱਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ.

PG10: ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼

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

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

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

• ਸੂਚਕਾਂਕ ਵਰਣਨ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ
• ਇਸ 'ਤੇ ਟਰਿਗਰ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ ਹੈ
• ਕਿਸੇ ਦਾ "ਔਲਾਦ" ਨਹੀਂ ਹੋ ਸਕਦਾ
• ਸਮਰਥਨ ਨਾ ਕਰੋ INSERT ... ON CONFLICT
• ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਇੱਕ ਸੈਕਸ਼ਨ ਤਿਆਰ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ

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

PG10: ਦੂਜਾ ਮੌਕਾ

ਇਸ ਲਈ, ਅਸੀਂ ਇਕ-ਇਕ ਕਰਕੇ ਪੈਦਾ ਹੋਈਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ:

1. ਕਿਉਂਕਿ ਟਰਿੱਗਰ ਅਤੇ ON CONFLICT ਅਸੀਂ ਪਾਇਆ ਕਿ ਸਾਨੂੰ ਅਜੇ ਵੀ ਉਹਨਾਂ ਦੀ ਇੱਥੇ ਅਤੇ ਉੱਥੇ ਲੋੜ ਹੈ, ਇਸਲਈ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਬਾਹਰ ਕੱਢਣ ਲਈ ਇੱਕ ਵਿਚਕਾਰਲਾ ਪੜਾਅ ਬਣਾਇਆ ਹੈ ਪ੍ਰੌਕਸੀ ਟੇਬਲ.
2. "ਰੂਟਿੰਗ" ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਇਆ ਟਰਿਗਰਜ਼ ਵਿੱਚ - ਭਾਵ, ਤੋਂ EXECUTE.
3. ਉਹ ਇਸ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਲੈ ਗਏ ਸਾਰੇ ਸੂਚਕਾਂਕ ਦੇ ਨਾਲ ਟੈਂਪਲੇਟ ਟੇਬਲਤਾਂ ਜੋ ਉਹ ਪ੍ਰੌਕਸੀ ਟੇਬਲ ਵਿੱਚ ਵੀ ਮੌਜੂਦ ਨਾ ਹੋਣ।

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

"ਸਾਵਿੰਗ" ਸ਼ਬਦਕੋਸ਼

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

"ਤੱਥ" ਪਹਿਲਾਂ ਹੀ ਲੰਬੇ ਸਮੇਂ ਲਈ ਦਿਨ ਦੁਆਰਾ ਭਾਗ ਕੀਤੇ ਗਏ ਸਨ, ਇਸਲਈ ਅਸੀਂ ਸ਼ਾਂਤ ਢੰਗ ਨਾਲ ਪੁਰਾਣੇ ਭਾਗਾਂ ਨੂੰ ਮਿਟਾ ਦਿੱਤਾ, ਅਤੇ ਉਹਨਾਂ ਨੇ ਸਾਨੂੰ ਪਰੇਸ਼ਾਨ ਨਹੀਂ ਕੀਤਾ (ਲੌਗ!) ਪਰ ਸ਼ਬਦਕੋਸ਼ਾਂ ਵਿੱਚ ਇੱਕ ਸਮੱਸਿਆ ਸੀ...

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

ਇੱਕ ਡਿਕਸ਼ਨਰੀ ਵਾਂਗ... ਇਸ ਵਿੱਚ, ਹਰੇਕ ਐਂਟਰੀ ਨੂੰ ਇੱਕ ਵਾਰ ਹੀ ਪੇਸ਼ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ... ਅਤੇ ਇਹ ਸਹੀ ਹੈ, ਪਰ!... ਕੋਈ ਵੀ ਸਾਨੂੰ ਰੱਖਣ ਤੋਂ ਨਹੀਂ ਰੋਕ ਰਿਹਾ. ਹਰ ਦਿਨ ਲਈ ਇੱਕ ਵੱਖਰਾ ਸ਼ਬਦਕੋਸ਼! ਹਾਂ, ਇਹ ਇੱਕ ਖਾਸ ਰਿਡੰਡੈਂਸੀ ਲਿਆਉਂਦਾ ਹੈ, ਪਰ ਇਹ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ:

• ਤੇਜ਼ੀ ਨਾਲ ਲਿਖੋ/ਪੜ੍ਹੋ ਛੋਟੇ ਭਾਗ ਦੇ ਆਕਾਰ ਦੇ ਕਾਰਨ
• ਘੱਟ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਵਧੇਰੇ ਸੰਖੇਪ ਸੂਚਕਾਂਕ ਨਾਲ ਕੰਮ ਕਰਕੇ
• ਘੱਟ ਡਾਟਾ ਸਟੋਰ ਕਰੋ ਪੁਰਾਣੀ ਨੂੰ ਜਲਦੀ ਹਟਾਉਣ ਦੀ ਯੋਗਤਾ ਦੇ ਕਾਰਨ

ਉਪਾਅ ਦੇ ਪੂਰੇ ਕੰਪਲੈਕਸ ਦੇ ਨਤੀਜੇ ਵਜੋਂ CPU ਲੋਡ ~ 30% ਘਟਿਆ, ਡਿਸਕ ਲੋਡ ~ 50%:

ਉਸੇ ਸਮੇਂ, ਅਸੀਂ ਡੇਟਾਬੇਸ ਵਿੱਚ ਬਿਲਕੁਲ ਉਹੀ ਚੀਜ਼ ਲਿਖਣਾ ਜਾਰੀ ਰੱਖਿਆ, ਸਿਰਫ ਘੱਟ ਲੋਡ ਦੇ ਨਾਲ.

#2. ਡਾਟਾਬੇਸ ਵਿਕਾਸ ਅਤੇ ਰੀਫੈਕਟਰਿੰਗ

ਇਸ ਲਈ ਅਸੀਂ ਉਸ 'ਤੇ ਸੈਟਲ ਹੋ ਗਏ ਜੋ ਸਾਡੇ ਕੋਲ ਹੈ ਹਰ ਦਿਨ ਦਾ ਆਪਣਾ ਸੈਕਸ਼ਨ ਹੁੰਦਾ ਹੈ ਡਾਟਾ ਦੇ ਨਾਲ. ਅਸਲ ਵਿੱਚ, CHECK (dt = '2018-10-12'::date) — ਅਤੇ ਇੱਕ ਵਿਭਾਗੀਕਰਨ ਕੁੰਜੀ ਹੈ ਅਤੇ ਇੱਕ ਖਾਸ ਭਾਗ ਵਿੱਚ ਰਿਕਾਰਡ ਕਰਨ ਦੀ ਸ਼ਰਤ ਹੈ।

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

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

ਅਨੁਕੂਲਨ ਦੀ ਦਿਸ਼ਾ ਸਪੱਸ਼ਟ ਹੈ - ਸਧਾਰਨ ਸਾਰੇ ਸੂਚਕਾਂਕ ਤੋਂ ਮਿਤੀ ਖੇਤਰ ਨੂੰ ਹਟਾਓ ਵਿਭਾਜਿਤ ਟੇਬਲ 'ਤੇ. ਸਾਡੀਆਂ ਮਾਤਰਾਵਾਂ ਦੇ ਮੱਦੇਨਜ਼ਰ, ਲਾਭ ਬਾਰੇ ਹੈ 1TB/ਹਫ਼ਤਾ!

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

#3. ਪੀਕ ਲੋਡ ਨੂੰ "ਫੈਲਾਉਣਾ"

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

ਚਲੋ ਪਿਛਲੀ ਤਸਵੀਰ 'ਤੇ ਜ਼ੂਮ ਇਨ ਕਰੀਏ ਅਤੇ ਦੇਖਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਕੋਲ ਇੱਕ ਡਿਸਕ ਹੈ ਡਬਲ ਐਪਲੀਟਿਊਡ ਦੇ ਨਾਲ ਲੋਡ ਦੇ ਹੇਠਾਂ "ਪੰਪ" ਆਸ ਪਾਸ ਦੇ ਨਮੂਨਿਆਂ ਦੇ ਵਿਚਕਾਰ, ਜੋ ਕਿ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ "ਅੰਕੜਿਆਂ ਅਨੁਸਾਰ" ਅਜਿਹੇ ਕਈ ਓਪਰੇਸ਼ਨਾਂ ਨਾਲ ਨਹੀਂ ਵਾਪਰਨਾ ਚਾਹੀਦਾ ਹੈ:

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

setInterval(sendToDB, interval)

ਇੱਥੇ ਸਮੱਸਿਆ ਬਿਲਕੁਲ ਇਸ ਤੱਥ ਵਿੱਚ ਹੈ ਕਿ ਸਾਰੇ ਥ੍ਰੈੱਡ ਲਗਭਗ ਇੱਕੋ ਸਮੇਂ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ, ਇਸਲਈ ਉਹਨਾਂ ਦੇ ਭੇਜਣ ਦਾ ਸਮਾਂ ਲਗਭਗ ਹਮੇਸ਼ਾ "ਬਿੰਦੂ ਤੱਕ" ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਓਹੋ #2...

ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਇਸ ਨੂੰ ਠੀਕ ਕਰਨਾ ਕਾਫ਼ੀ ਆਸਾਨ ਹੈ, ਇੱਕ "ਬੇਤਰਤੀਬ" ਰਨ-ਅੱਪ ਜੋੜਨਾ ਸਮੇਂ ਅਨੁਸਾਰ:

setInterval(sendToDB, interval * (1 + 0.1 * (Math.random() - 0.5)))

#4. ਅਸੀਂ ਉਸ ਚੀਜ਼ ਨੂੰ ਕੈਸ਼ ਕਰਦੇ ਹਾਂ ਜੋ ਸਾਨੂੰ ਚਾਹੀਦਾ ਹੈ

ਤੀਜੀ ਪਰੰਪਰਾਗਤ ਹਾਈਲੋਡ ਸਮੱਸਿਆ ਹੈ ਕੋਈ ਕੈਸ਼ ਨਹੀਂ ਜਿੱਥੇ ਉਹ ਹੈ ਸਕਦਾ ਹੈ ਹੋਣਾ

ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਯੋਜਨਾ ਨੋਡਸ (ਇਹ ਸਾਰੇ) ਦੇ ਰੂਪ ਵਿੱਚ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨਾ ਸੰਭਵ ਬਣਾਇਆ ਹੈ Seq Scan on users), ਪਰ ਤੁਰੰਤ ਸੋਚੋ ਕਿ ਉਹ ਹਨ, ਜ਼ਿਆਦਾਤਰ ਹਿੱਸੇ ਲਈ, ਉਹੀ - ਉਹ ਭੁੱਲ ਗਏ ਹਨ.

ਨਹੀਂ, ਬੇਸ਼ਕ, ਡੇਟਾਬੇਸ ਨੂੰ ਦੁਬਾਰਾ ਕੁਝ ਨਹੀਂ ਲਿਖਿਆ ਗਿਆ ਹੈ, ਇਸ ਨਾਲ ਟਰਿੱਗਰ ਨੂੰ ਕੱਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ INSERT ... ON CONFLICT DO NOTHING. ਪਰ ਇਹ ਡੇਟਾ ਅਜੇ ਵੀ ਡੇਟਾਬੇਸ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਅਤੇ ਇਹ ਬੇਲੋੜਾ ਹੈ ਵਿਵਾਦ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਪੜ੍ਹਨਾ ਕਰਨਾ ਹੈ। ਓਹੋ #3...

ਕੈਸ਼ਿੰਗ ਨੂੰ ਸਮਰੱਥ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ/ਬਾਅਦ ਡਾਟਾਬੇਸ ਨੂੰ ਭੇਜੇ ਗਏ ਰਿਕਾਰਡਾਂ ਦੀ ਗਿਣਤੀ ਵਿੱਚ ਅੰਤਰ ਸਪੱਸ਼ਟ ਹੈ:

ਅਤੇ ਇਹ ਸਟੋਰੇਜ ਲੋਡ ਵਿੱਚ ਆਉਣ ਵਾਲੀ ਗਿਰਾਵਟ ਹੈ:

ਕੁੱਲ

"ਟੈਰਾਬਾਈਟ-ਪ੍ਰਤੀ-ਦਿਨ" ਸਿਰਫ਼ ਡਰਾਉਣਾ ਲੱਗਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਸਭ ਕੁਝ ਸਹੀ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਸਹੀ ਹੈ 2^40 ਬਾਈਟ / 86400 ਸਕਿੰਟ = ~12.5MB/sਜੋ ਕਿ ਡੈਸਕਟਾਪ IDE ਪੇਚ ਵੀ ਰੱਖੇ ਗਏ ਹਨ। 🙂

ਪਰ ਗੰਭੀਰਤਾ ਨਾਲ, ਦਿਨ ਦੇ ਦੌਰਾਨ ਲੋਡ ਦੇ ਦਸ ਗੁਣਾ "ਸਕੂ" ਦੇ ਨਾਲ, ਤੁਸੀਂ ਆਧੁਨਿਕ SSDs ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹੋ.

ਸਰੋਤ: www.habr.com