ਮੈਸੇਂਜਰ ਡੇਟਾਬੇਸ (ਭਾਗ 2): “ਲਾਭ ਲਈ” ਵੰਡਣਾ

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

• ਭਾਗ 1: ਬੇਸ ਫਰੇਮ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨਾ
• ਭਾਗ 2: "ਲਾਭ ਲਈ" ਭਾਗ ਕਰਨਾ

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

ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਇਹ ਬਚਾਅ ਲਈ ਆਉਂਦਾ ਹੈ ਸੈਕਸ਼ਨਿੰਗ.

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

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

ਸੰਕਲਪ

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

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

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

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

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

ਕਦਮ-ਦਰ-ਕਦਮ

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

ਸੁਨੇਹਾ, ਇਸ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਅਨੁਮਾਨ

ਕਿਉਂਕਿ ਅਸੀਂ ਸੁਨੇਹਿਆਂ ਨੂੰ ਤਾਰੀਖਾਂ ਅਨੁਸਾਰ ਕੱਟਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ, ਇਸ ਲਈ ਉਹਨਾਂ 'ਤੇ ਨਿਰਭਰ ਇਕਾਈਆਂ-ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਵੰਡਣਾ ਵੀ ਸਮਝਦਾਰ ਹੈ (ਨੱਥੀ ਫਾਈਲਾਂ, ਪ੍ਰਾਪਤਕਰਤਾਵਾਂ ਦੀ ਸੂਚੀ), ਅਤੇ ਸੁਨੇਹੇ ਦੀ ਮਿਤੀ ਦੁਆਰਾ ਵੀ.

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

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

ਥਰਿੱਡ

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

ਸਾਰੀਆਂ ਸਾਰਣੀਆਂ ਵਿੱਚ ਵਿਭਾਗੀਕਰਨ ਕੁੰਜੀ (ਵਿਸ਼ਾ ਮਿਤੀ) ਸ਼ਾਮਲ ਕਰੋ: ਵਿਸ਼ਾ, ਭਾਗੀਦਾਰ।

ਪਰ ਹੁਣ ਸਾਡੇ ਕੋਲ ਇੱਕੋ ਸਮੇਂ ਦੋ ਸਮੱਸਿਆਵਾਂ ਹਨ:

• ਮੈਨੂੰ ਵਿਸ਼ੇ 'ਤੇ ਸੁਨੇਹੇ ਕਿਸ ਭਾਗ ਵਿੱਚ ਦੇਖਣੇ ਚਾਹੀਦੇ ਹਨ?
• ਮੈਨੂੰ ਸੁਨੇਹੇ ਤੋਂ ਵਿਸ਼ੇ ਦੀ ਖੋਜ ਕਿਸ ਭਾਗ ਵਿੱਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ?

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

• ਅਸੀਂ ਸੰਦੇਸ਼ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਾਂਗੇ ਵਿਸ਼ਾ ਮਿਤੀ ਖੇਤਰ
• ਆਓ ਵਿਸ਼ੇ ਵਿੱਚ ਜੋੜੀਏ ਸੁਨੇਹਾ ਮਿਤੀ ਸੈੱਟ ਇਹ ਪੱਤਰ ਵਿਹਾਰ (ਇੱਕ ਵੱਖਰੀ ਸਾਰਣੀ, ਜਾਂ ਤਾਰੀਖਾਂ ਦੀ ਇੱਕ ਲੜੀ ਹੋ ਸਕਦੀ ਹੈ)

ਕਿਉਂਕਿ ਹਰੇਕ ਵਿਅਕਤੀਗਤ ਪੱਤਰ-ਵਿਹਾਰ ਲਈ ਸੁਨੇਹੇ ਦੀਆਂ ਤਾਰੀਖਾਂ ਦੀ ਸੂਚੀ ਵਿੱਚ ਕੁਝ ਸੋਧਾਂ ਹੋਣਗੀਆਂ (ਆਖ਼ਰਕਾਰ, ਲਗਭਗ ਸਾਰੇ ਸੁਨੇਹੇ 1-2 ਨੇੜਲੇ ਦਿਨਾਂ ਵਿੱਚ ਆਉਂਦੇ ਹਨ), ਮੈਂ ਇਸ ਵਿਕਲਪ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਕਰਾਂਗਾ।

ਕੁੱਲ ਮਿਲਾ ਕੇ, ਸਾਡੇ ਡੇਟਾਬੇਸ ਦੀ ਬਣਤਰ ਨੇ ਵਿਭਾਗੀਕਰਨ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਹੇਠ ਲਿਖਿਆਂ ਰੂਪ ਲਿਆ:

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

-- секции по дате сообщения
CREATE TABLE "Сообщение_YYYYMMDD"(
  "Сообщение"
    uuid
      PRIMARY KEY
, "Тема"
    uuid
, "ДатаТемы"
    date
, "Автор"
    uuid
, "ДатаВремя" -- используем как дату
    timestamp
, "Текст"
    text
);

CREATE TABLE "Адресат_YYYYMMDD"(
  "ДатаСообщения"
    date
, "Сообщение"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Сообщение", "Персона")
);

CREATE TABLE "Файл_YYYYMMDD"(
  "ДатаСообщения"
    date
, "Файл"
    uuid
      PRIMARY KEY
, "Сообщение"
    uuid
, "BLOB"
    uuid
, "Имя"
    text
);

CREATE TABLE "РеестрСообщений_YYYYMMDD"(
  "ДатаСообщения"
    date
, "Владелец"
    uuid
, "ТипРеестра"
    smallint
, "ДатаВремя"
    timestamp
, "Сообщение"
    uuid
, PRIMARY KEY("Владелец", "ТипРеестра", "Сообщение")
);
CREATE INDEX ON "РеестрСообщений_YYYYMMDD"("Владелец", "ТипРеестра", "ДатаВремя" DESC);

-- секции по дате темы
CREATE TABLE "Тема_YYYYMMDD"(
  "ДатаТемы"
    date
, "Тема"
    uuid
      PRIMARY KEY
, "Документ"
    uuid
, "Название"
    text
);

CREATE TABLE "УчастникТемы_YYYYMMDD"(
  "ДатаТемы"
    date
, "Тема"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Тема", "Персона")
);

CREATE TABLE "ДатыСообщенийТемы_YYYYMMDD"(
  "ДатаТемы"
    date
, "Тема"
    uuid
      PRIMARY KEY
, "Дата"
    date
);

ਇੱਕ ਸੁੰਦਰ ਪੈਸਾ ਬਚਾਓ

ਠੀਕ ਹੈ, ਜੇ ਅਸੀਂ ਨਹੀਂ ਵਰਤਦੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ ਕਲਾਸਿਕ ਸੈਕਸ਼ਨਿੰਗ ਵਿਕਲਪ ਫੀਲਡ ਮੁੱਲਾਂ ਦੀ ਵੰਡ ਦੇ ਅਧਾਰ ਤੇ (ਟਰਿੱਗਰਸ ਅਤੇ ਵਿਰਾਸਤ ਜਾਂ PARTITION BY ਦੁਆਰਾ), ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ 'ਤੇ "ਹੱਥੀਂ", ਤੁਸੀਂ ਵੇਖੋਗੇ ਕਿ ਵਿਭਾਗੀਕਰਨ ਕੁੰਜੀ ਦਾ ਮੁੱਲ ਪਹਿਲਾਂ ਹੀ ਸਾਰਣੀ ਦੇ ਨਾਮ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਗਿਆ ਹੈ।

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

ਸਰੋਤ: www.habr.com