ਕੈਸੈਂਡਰਾ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ ਓਰੇਕਲ ਨੂੰ ਜਾਣਦੇ ਹੋ ਤਾਂ ਕਿਵੇਂ ਮਰਨਾ ਨਹੀਂ ਹੈ

ਹੇ ਹਬਰ.

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

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

ਉਹ ਹੋਰ ਕੀ ਚੰਗੀ ਹੈ? ਇਹ ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਸੰਭਾਲਣ ਬਾਰੇ ਹੈ। ਪਰ ਬਹੁਤ ਸਾਰਾ ਕਿੰਨਾ ਹੈ? ਪ੍ਰਤੀ ਸਕਿੰਟ 10, 20, 30, 40 ਹਜ਼ਾਰ ਬੇਨਤੀਆਂ ਜ਼ਿਆਦਾ ਨਹੀਂ ਹਨ। ਰਿਕਾਰਡਿੰਗ ਲਈ ਪ੍ਰਤੀ ਸਕਿੰਟ 100 ਹਜ਼ਾਰ ਬੇਨਤੀਆਂ - ਵੀ. ਅਜਿਹੀਆਂ ਕੰਪਨੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੇ ਕਿਹਾ ਕਿ ਉਹ ਪ੍ਰਤੀ ਸਕਿੰਟ 2 ਮਿਲੀਅਨ ਬੇਨਤੀਆਂ ਰੱਖਦੀਆਂ ਹਨ. ਉਨ੍ਹਾਂ ਨੂੰ ਸ਼ਾਇਦ ਇਸ 'ਤੇ ਵਿਸ਼ਵਾਸ ਕਰਨਾ ਪਏਗਾ।

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

ਹਰ ਚੀਜ਼ ਜੋ ਇੱਕੋ ਜਿਹੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ ਉਹੀ ਕੰਮ ਨਹੀਂ ਕਰਦੀ

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

ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਗਾਹਕ ਸਾਡੇ ਕੋਲ ਆਉਂਦਾ ਹੈ ਅਤੇ ਕਹਿੰਦਾ ਹੈ: "ਆਓ ਟੀਵੀ ਸੀਰੀਜ਼ ਲਈ ਇੱਕ ਡੇਟਾਬੇਸ, ਜਾਂ ਇੱਕ ਪਕਵਾਨ ਡਾਇਰੈਕਟਰੀ ਲਈ ਇੱਕ ਡੇਟਾਬੇਸ ਬਣਾਈਏ। ਸਾਡੇ ਕੋਲ ਉੱਥੇ ਖਾਣੇ ਦੇ ਪਕਵਾਨ ਹੋਣਗੇ ਜਾਂ ਇਸ ਵਿੱਚ ਟੀਵੀ ਲੜੀਵਾਰਾਂ ਅਤੇ ਅਦਾਕਾਰਾਂ ਦੀ ਸੂਚੀ ਹੋਵੇਗੀ।” ਅਸੀਂ ਖੁਸ਼ੀ ਨਾਲ ਕਹਿੰਦੇ ਹਾਂ: "ਚਲੋ ਚੱਲੀਏ!" ਬਸ ਦੋ ਬਾਈਟਸ, ਕੁਝ ਸੰਕੇਤ ਭੇਜੋ ਅਤੇ ਤੁਸੀਂ ਪੂਰਾ ਕਰ ਲਿਆ, ਸਭ ਕੁਝ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਨਾਲ ਕੰਮ ਕਰੇਗਾ। ਅਤੇ ਸਭ ਕੁਝ ਉਦੋਂ ਤੱਕ ਠੀਕ ਹੈ ਜਦੋਂ ਤੱਕ ਗਾਹਕ ਨਹੀਂ ਆਉਂਦੇ ਅਤੇ ਕਹਿੰਦੇ ਹਨ ਕਿ ਘਰੇਲੂ ਔਰਤਾਂ ਵੀ ਉਲਟ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰ ਰਹੀਆਂ ਹਨ: ਉਹਨਾਂ ਕੋਲ ਉਤਪਾਦਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਹੈ, ਅਤੇ ਉਹ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਉਹ ਕਿਹੜਾ ਪਕਵਾਨ ਪਕਾਉਣਾ ਚਾਹੁੰਦੇ ਹਨ. ਤੁਸੀਂ ਮਰ ਗਏ ਹੋ।

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

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

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

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

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

CREATE TABLE users (
	user_id uu id,
	name text,
	year int,
	salary float,
	PRIMARY KEY(user_id)

)

ਇਸ ਕੇਸ ਵਿੱਚ ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ ਵਿੱਚ ਇੱਕ ਕਾਲਮ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਵਿਭਾਗੀਕਰਨ ਕੁੰਜੀ ਵੀ ਹੈ।

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

ਚੁਣੋ: ਜਦੋਂ ਫਿਲਟਰਿੰਗ ਪੂਰੇ ਸਕੈਨ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ, ਜਾਂ ਕੀ ਨਹੀਂ ਕਰਨਾ ਹੈ

ਆਓ ਕੁਝ ਚੋਣਵੇਂ ਬਿਆਨ ਲਿਖੀਏ: select * from users where, userid = . ਇਹ ਓਰੇਕਲ ਵਾਂਗ ਨਿਕਲਦਾ ਹੈ: ਅਸੀਂ ਸਿਲੈਕਟ ਲਿਖਦੇ ਹਾਂ, ਸ਼ਰਤਾਂ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ ਅਤੇ ਸਭ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ, ਉਪਭੋਗਤਾ ਇਸਨੂੰ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ. ਪਰ ਜੇ ਤੁਸੀਂ, ਉਦਾਹਰਨ ਲਈ, ਜਨਮ ਦੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸਾਲ ਵਾਲਾ ਉਪਭੋਗਤਾ ਚੁਣਦੇ ਹੋ, ਤਾਂ ਕੈਸੈਂਡਰਾ ਸ਼ਿਕਾਇਤ ਕਰਦੀ ਹੈ ਕਿ ਇਹ ਬੇਨਤੀ ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਕਿਉਂਕਿ ਉਹ ਇਸ ਬਾਰੇ ਕੁਝ ਵੀ ਨਹੀਂ ਜਾਣਦੀ ਕਿ ਅਸੀਂ ਜਨਮ ਦੇ ਸਾਲ ਬਾਰੇ ਡੇਟਾ ਕਿਵੇਂ ਵੰਡਦੇ ਹਾਂ - ਉਸ ਕੋਲ ਸਿਰਫ ਇੱਕ ਕਾਲਮ ਹੈ ਜੋ ਇੱਕ ਕੁੰਜੀ ਵਜੋਂ ਦਰਸਾਈ ਗਈ ਹੈ। ਫਿਰ ਉਹ ਕਹਿੰਦੀ ਹੈ, “ਠੀਕ ਹੈ, ਮੈਂ ਅਜੇ ਵੀ ਇਹ ਬੇਨਤੀ ਪੂਰੀ ਕਰ ਸਕਦੀ ਹਾਂ। ਫਿਲਟਰਿੰਗ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ।" ਅਸੀਂ ਨਿਰਦੇਸ਼ ਜੋੜਦੇ ਹਾਂ, ਸਭ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ. ਅਤੇ ਇਸ ਪਲ 'ਤੇ ਕੁਝ ਭਿਆਨਕ ਵਾਪਰਦਾ ਹੈ.

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

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

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

ਇਹ ਅਸਲ ਵਿੱਚ ਇੱਕ ਰੁੱਖ ਹੈ, ਇੱਕ ਤੁਲਨਾਕਾਰ ਨੂੰ ਸਿਰਫ਼ ਉੱਥੇ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨੂੰ ਅਸੀਂ ਇੱਕ ਵਸਤੂ ਦੇ ਰੂਪ ਵਿੱਚ ਕਾਲਮਾਂ ਦੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸਮੂਹ ਨੂੰ ਪਾਸ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਇਸਨੂੰ ਕਾਲਮਾਂ ਦੀ ਸੂਚੀ ਦੇ ਰੂਪ ਵਿੱਚ ਵੀ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

CREATE TABLE users_by_year_salary_id (
	user_id uuid,
	name text,
	year int,
	salary float,
	PRIMARY KEY((year), salary, user_id)

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

ਅਸੀਂ ਛਾਂਟੀ ਸੈੱਟ ਕਰਦੇ ਹਾਂ ਅਤੇ ਪਾਬੰਦੀਆਂ ਲਗਾਉਂਦੇ ਹਾਂ

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

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

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

ਕਿਸੇ ਵੀ ਅਸਪਸ਼ਟ ਸਥਿਤੀ ਵਿੱਚ, ਇੱਕ ਨਵੀਂ ਸਾਰਣੀ ਬਣਾਓ

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

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

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

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

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

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

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

ਸਰੋਤ: www.habr.com