ಕಸ್ಸಂದ್ರ. ನಿಮಗೆ ಒರಾಕಲ್ ಮಾತ್ರ ತಿಳಿದಿದ್ದರೆ ಹೇಗೆ ಸಾಯಬಾರದು

ಹೇ ಹಬ್ರ್.

ನನ್ನ ಹೆಸರು ಮಿಶಾ ಬುಟ್ರಿಮೊವ್, ನಾನು ನಿಮಗೆ ಕಸ್ಸಂದ್ರದ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ಹೇಳಲು ಬಯಸುತ್ತೇನೆ. NoSQL ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಎಂದಿಗೂ ಎದುರಿಸದವರಿಗೆ ನನ್ನ ಕಥೆಯು ಉಪಯುಕ್ತವಾಗಿರುತ್ತದೆ - ಇದು ಬಹಳಷ್ಟು ಅನುಷ್ಠಾನ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಮತ್ತು ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕಾದ ಮೋಸಗಳನ್ನು ಹೊಂದಿದೆ. ಮತ್ತು ನೀವು Oracle ಅಥವಾ ಯಾವುದೇ ಇತರ ಸಂಬಂಧಿತ ಡೇಟಾಬೇಸ್ ಹೊರತುಪಡಿಸಿ ಬೇರೆ ಯಾವುದನ್ನೂ ನೋಡಿಲ್ಲದಿದ್ದರೆ, ಈ ವಿಷಯಗಳು ನಿಮ್ಮ ಜೀವವನ್ನು ಉಳಿಸುತ್ತದೆ.

ಕಸ್ಸಂದ್ರದಲ್ಲಿ ಏನು ಒಳ್ಳೆಯದು? ಇದು NoSQL ಡೇಟಾಬೇಸ್ ಆಗಿದ್ದು, ಒಂದೇ ಒಂದು ವೈಫಲ್ಯದ ಬಿಂದುವಿಲ್ಲದೆ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ ಅದು ಚೆನ್ನಾಗಿ ಮಾಪಕವಾಗುತ್ತದೆ. ಕೆಲವು ಡೇಟಾಬೇಸ್‌ಗಾಗಿ ನೀವು ಒಂದೆರಡು ಟೆರಾಬೈಟ್‌ಗಳನ್ನು ಸೇರಿಸಬೇಕಾದರೆ, ನೀವು ಕೇವಲ ರಿಂಗ್‌ಗೆ ನೋಡ್‌ಗಳನ್ನು ಸೇರಿಸಿ. ಅದನ್ನು ಮತ್ತೊಂದು ಡೇಟಾ ಕೇಂದ್ರಕ್ಕೆ ವಿಸ್ತರಿಸುವುದೇ? ಕ್ಲಸ್ಟರ್‌ಗೆ ನೋಡ್‌ಗಳನ್ನು ಸೇರಿಸಿ. ಸಂಸ್ಕರಿಸಿದ RPS ಅನ್ನು ಹೆಚ್ಚಿಸುವುದೇ? ಕ್ಲಸ್ಟರ್‌ಗೆ ನೋಡ್‌ಗಳನ್ನು ಸೇರಿಸಿ. ಇದು ವಿರುದ್ಧ ದಿಕ್ಕಿನಲ್ಲಿಯೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಅವಳು ಇನ್ನೇನು ಒಳ್ಳೆಯವಳು? ಇದು ಬಹಳಷ್ಟು ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಬಗ್ಗೆ. ಆದರೆ ಬಹಳಷ್ಟು ಎಷ್ಟು? ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 10, 20, 30, 40 ಸಾವಿರ ವಿನಂತಿಗಳು ಹೆಚ್ಚು ಅಲ್ಲ. ರೆಕಾರ್ಡಿಂಗ್‌ಗಾಗಿ ಸೆಕೆಂಡಿಗೆ 100 ಸಾವಿರ ವಿನಂತಿಗಳು - ತುಂಬಾ. ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 2 ಮಿಲಿಯನ್ ರಿಕ್ವೆಸ್ಟ್‌ಗಳನ್ನು ಇಡುತ್ತೇವೆ ಎಂದು ಕಂಪನಿಗಳಿವೆ. ಅವರು ಬಹುಶಃ ಅದನ್ನು ನಂಬಬೇಕು.

ಮತ್ತು ತಾತ್ವಿಕವಾಗಿ, ಕಸ್ಸಂದ್ರವು ಸಂಬಂಧಿತ ಡೇಟಾದಿಂದ ಒಂದು ದೊಡ್ಡ ವ್ಯತ್ಯಾಸವನ್ನು ಹೊಂದಿದೆ - ಅದು ಅವರಿಗೆ ಹೋಲುವಂತಿಲ್ಲ. ಮತ್ತು ಇದನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ.

ಒಂದೇ ರೀತಿ ಕಾಣುವ ಎಲ್ಲವೂ ಒಂದೇ ರೀತಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ

ಒಮ್ಮೆ ಸಹೋದ್ಯೋಗಿಯೊಬ್ಬರು ನನ್ನ ಬಳಿಗೆ ಬಂದು ಕೇಳಿದರು: “ಇಲ್ಲಿ ಒಂದು CQL Cassandra ಪ್ರಶ್ನೆ ಭಾಷೆ ಇದೆ, ಮತ್ತು ಇದು ಆಯ್ದ ಹೇಳಿಕೆಯನ್ನು ಹೊಂದಿದೆ, ಅದು ಎಲ್ಲಿದೆ, ಅದು ಹೊಂದಿದೆ ಮತ್ತು. ನಾನು ಪತ್ರಗಳನ್ನು ಬರೆಯುತ್ತೇನೆ ಮತ್ತು ಅದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ಏಕೆ?". ಕಸ್ಸಂದ್ರವನ್ನು ಸಂಬಂಧಿತ ಡೇಟಾಬೇಸ್‌ನಂತೆ ಪರಿಗಣಿಸುವುದು ಹಿಂಸಾತ್ಮಕ ಆತ್ಮಹತ್ಯೆಗೆ ಪರಿಪೂರ್ಣ ಮಾರ್ಗವಾಗಿದೆ. ಮತ್ತು ನಾನು ಅದನ್ನು ಪ್ರಚಾರ ಮಾಡುತ್ತಿಲ್ಲ, ರಷ್ಯಾದಲ್ಲಿ ಇದನ್ನು ನಿಷೇಧಿಸಲಾಗಿದೆ. ನೀವು ಏನನ್ನಾದರೂ ತಪ್ಪಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸುತ್ತೀರಿ.

ಉದಾಹರಣೆಗೆ, ಒಬ್ಬ ಗ್ರಾಹಕರು ನಮ್ಮ ಬಳಿಗೆ ಬಂದು ಹೀಗೆ ಹೇಳುತ್ತಾರೆ: “ನಾವು ಟಿವಿ ಸರಣಿಗಾಗಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ನಿರ್ಮಿಸೋಣ ಅಥವಾ ಪಾಕವಿಧಾನ ಡೈರೆಕ್ಟರಿಗಾಗಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ನಿರ್ಮಿಸೋಣ. ನಾವು ಅಲ್ಲಿ ಆಹಾರ ಭಕ್ಷ್ಯಗಳನ್ನು ಹೊಂದಿರುತ್ತೇವೆ ಅಥವಾ ಟಿವಿ ಸರಣಿಗಳು ಮತ್ತು ನಟರ ಪಟ್ಟಿಯನ್ನು ಹೊಂದಿರುತ್ತೇವೆ. ನಾವು ಸಂತೋಷದಿಂದ ಹೇಳುತ್ತೇವೆ: "ನಾವು ಹೋಗೋಣ!" ಕೇವಲ ಎರಡು ಬೈಟ್‌ಗಳು, ಒಂದೆರಡು ಚಿಹ್ನೆಗಳನ್ನು ಕಳುಹಿಸಿ ಮತ್ತು ನೀವು ಮುಗಿಸಿದ್ದೀರಿ, ಎಲ್ಲವೂ ತ್ವರಿತವಾಗಿ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಮತ್ತು ಗ್ರಾಹಕರು ಬಂದು ಗೃಹಿಣಿಯರು ಸಹ ವಿರುದ್ಧವಾದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತಿದ್ದಾರೆ ಎಂದು ಹೇಳುವವರೆಗೂ ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿರುತ್ತದೆ: ಅವರು ಉತ್ಪನ್ನಗಳ ಪಟ್ಟಿಯನ್ನು ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಅವರು ಯಾವ ಖಾದ್ಯವನ್ನು ಬೇಯಿಸಬೇಕೆಂದು ಅವರು ಬಯಸುತ್ತಾರೆ. ನೀನು ಸತ್ತೆ.

ಏಕೆಂದರೆ ಕಸ್ಸಂದ್ರವು ಹೈಬ್ರಿಡ್ ಡೇಟಾಬೇಸ್ ಆಗಿದೆ: ಇದು ಏಕಕಾಲದಲ್ಲಿ ಪ್ರಮುಖ ಮೌಲ್ಯವನ್ನು ಒದಗಿಸುತ್ತದೆ ಮತ್ತು ಡೇಟಾವನ್ನು ವಿಶಾಲ ಕಾಲಮ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಜಾವಾ ಅಥವಾ ಕೋಟ್ಲಿನ್‌ನಲ್ಲಿ, ಇದನ್ನು ಈ ರೀತಿ ವಿವರಿಸಬಹುದು:

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

ಅಂದರೆ, ವಿಂಗಡಿಸಲಾದ ನಕ್ಷೆಯನ್ನು ಒಳಗೊಂಡಿರುವ ನಕ್ಷೆ. ಈ ನಕ್ಷೆಯ ಮೊದಲ ಕೀ ರೋ ಕೀ ಅಥವಾ ವಿಭಜನಾ ಕೀ - ವಿಭಜನಾ ಕೀ. ಈಗಾಗಲೇ ವಿಂಗಡಿಸಲಾದ ನಕ್ಷೆಯ ಕೀಲಿಯಾಗಿರುವ ಎರಡನೇ ಕೀ ಕ್ಲಸ್ಟರಿಂಗ್ ಕೀ ಆಗಿದೆ.

ಡೇಟಾಬೇಸ್ನ ವಿತರಣೆಯನ್ನು ವಿವರಿಸಲು, ನಾವು ಮೂರು ನೋಡ್ಗಳನ್ನು ಸೆಳೆಯೋಣ. ಡೇಟಾವನ್ನು ನೋಡ್‌ಗಳಾಗಿ ವಿಭಜಿಸುವುದು ಹೇಗೆ ಎಂಬುದನ್ನು ಈಗ ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಏಕೆಂದರೆ ನಾವು ಎಲ್ಲವನ್ನೂ ಒಂದಾಗಿ ಸೇರಿಸಿದರೆ (ಮೂಲಕ, ಒಂದು ಸಾವಿರ, ಎರಡು ಸಾವಿರ, ಐದು ಇರಬಹುದು - ನೀವು ಇಷ್ಟಪಡುವಷ್ಟು), ಇದು ನಿಜವಾಗಿಯೂ ವಿತರಣೆಯ ಬಗ್ಗೆ ಅಲ್ಲ. ಆದ್ದರಿಂದ, ನಮಗೆ ಗಣಿತದ ಕಾರ್ಯದ ಅಗತ್ಯವಿದೆ ಅದು ಸಂಖ್ಯೆಯನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಕೇವಲ ಒಂದು ಸಂಖ್ಯೆ, ಕೆಲವು ವ್ಯಾಪ್ತಿಯೊಳಗೆ ಬೀಳುವ ದೀರ್ಘವಾದ ಇಂಟ್. ಮತ್ತು ನಾವು ಒಂದು ಶ್ರೇಣಿಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಒಂದು ನೋಡ್ ಅನ್ನು ಹೊಂದಿರುತ್ತೇವೆ, ಎರಡನೆಯದು ಎರಡನೆಯದು, nth ಗೆ nನೇ ಒಂದು.

ಈ ಸಂಖ್ಯೆಯನ್ನು ಹ್ಯಾಶ್ ಫಂಕ್ಷನ್ ಬಳಸಿ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ, ಇದನ್ನು ನಾವು ವಿಭಜನಾ ಕೀ ಎಂದು ಕರೆಯುವುದಕ್ಕೆ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ. ಇದು ಪ್ರಾಥಮಿಕ ಕೀ ನಿರ್ದೇಶನದಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಕಾಲಮ್ ಆಗಿದೆ ಮತ್ತು ಇದು ನಕ್ಷೆಯ ಮೊದಲ ಮತ್ತು ಅತ್ಯಂತ ಮೂಲಭೂತ ಕೀ ಆಗಿರುವ ಕಾಲಮ್ ಆಗಿದೆ. ಯಾವ ನೋಡ್ ಯಾವ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಇದು ನಿರ್ಧರಿಸುತ್ತದೆ. 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