ಕ್ಲಿಕ್‌ಹೌಸ್ ವಿಶೇಷ ವ್ಯವಸ್ಥೆಯಾಗಿರುವುದರಿಂದ, ಅದನ್ನು ಬಳಸುವಾಗ ಅದರ ವಾಸ್ತುಶಿಲ್ಪದ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದು ಮುಖ್ಯ. ಈ ವರದಿಯಲ್ಲಿ, ಕ್ಲಿಕ್‌ಹೌಸ್ ಬಳಸುವಾಗ ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳ ಉದಾಹರಣೆಗಳ ಬಗ್ಗೆ ಅಲೆಕ್ಸಿ ಮಾತನಾಡುತ್ತಾರೆ, ಇದು ನಿಷ್ಪರಿಣಾಮಕಾರಿ ಕೆಲಸಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು. ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆಗಳು ಒಂದು ಅಥವಾ ಇನ್ನೊಂದು ಡೇಟಾ ಸಂಸ್ಕರಣಾ ಯೋಜನೆಯನ್ನು ಆಯ್ಕೆಮಾಡುವುದರಿಂದ ಮ್ಯಾಗ್ನಿಟ್ಯೂಡ್ ಆದೇಶಗಳ ಮೂಲಕ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೇಗೆ ಬದಲಾಯಿಸಬಹುದು ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.
ಎಲ್ಲರಿಗು ನಮಸ್ಖರ! ನನ್ನ ಹೆಸರು ಅಲೆಕ್ಸಿ, ನಾನು ಕ್ಲಿಕ್‌ಹೌಸ್ ಮಾಡುತ್ತೇನೆ.
ಮೊದಲನೆಯದಾಗಿ, ನಾನು ಈಗಿನಿಂದಲೇ ನಿಮ್ಮನ್ನು ಮೆಚ್ಚಿಸಲು ಆತುರಪಡುತ್ತೇನೆ, ಇಂದು ಕ್ಲಿಕ್‌ಹೌಸ್ ಎಂದರೇನು ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುವುದಿಲ್ಲ. ನಿಜ ಹೇಳಬೇಕೆಂದರೆ, ನಾನು ಅದರಿಂದ ಬೇಸತ್ತಿದ್ದೇನೆ. ಪ್ರತಿ ಬಾರಿ ಅದು ಏನು ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ. ಮತ್ತು ಬಹುಶಃ ಎಲ್ಲರಿಗೂ ಈಗಾಗಲೇ ತಿಳಿದಿದೆ.
ಬದಲಾಗಿ, ಸಂಭವನೀಯ ತಪ್ಪುಗಳು ಏನೆಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ, ಅಂದರೆ, ನೀವು ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಹೇಗೆ ತಪ್ಪಾಗಿ ಬಳಸಬಹುದು. ವಾಸ್ತವವಾಗಿ, ಭಯಪಡುವ ಅಗತ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ನಾವು ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಸರಳ, ಅನುಕೂಲಕರ ಮತ್ತು ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ವ್ಯವಸ್ಥೆಯಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದ್ದೇವೆ. ನಾನು ಅದನ್ನು ಸ್ಥಾಪಿಸಿದ್ದೇನೆ, ಯಾವುದೇ ತೊಂದರೆಗಳಿಲ್ಲ.
ಆದರೆ ಈ ವ್ಯವಸ್ಥೆಯು ವಿಶೇಷವಾಗಿದೆ ಎಂದು ನೀವು ಇನ್ನೂ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗಿದೆ ಮತ್ತು ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ಅದರ ಸೌಕರ್ಯ ವಲಯದಿಂದ ಹೊರಗೆ ತೆಗೆದುಕೊಳ್ಳುವ ಅಸಾಮಾನ್ಯ ಬಳಕೆಯ ಪ್ರಕರಣವನ್ನು ನೀವು ಸುಲಭವಾಗಿ ನೋಡಬಹುದು.
ಹಾಗಾದರೆ, ಯಾವ ರೀತಿಯ ಕುಂಟೆ ಇದೆ? ಹೆಚ್ಚಾಗಿ ನಾನು ಸ್ಪಷ್ಟವಾದ ವಿಷಯಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇನೆ. ಎಲ್ಲರಿಗೂ ಎಲ್ಲವೂ ಸ್ಪಷ್ಟವಾಗಿದೆ, ಪ್ರತಿಯೊಬ್ಬರೂ ಎಲ್ಲವನ್ನೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಅವರು ತುಂಬಾ ಸ್ಮಾರ್ಟ್ ಎಂದು ಸಂತೋಷಪಡಬಹುದು ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳದವರು ಹೊಸದನ್ನು ಕಲಿಯುತ್ತಾರೆ.
ಮೊದಲ ಮತ್ತು ಸರಳವಾದ ಉದಾಹರಣೆಯೆಂದರೆ, ದುರದೃಷ್ಟವಶಾತ್, ಆಗಾಗ್ಗೆ ಸಂಭವಿಸುತ್ತದೆ, ಸಣ್ಣ ಬ್ಯಾಚ್‌ಗಳೊಂದಿಗೆ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಒಳಸೇರಿಸುವಿಕೆಗಳು, ಅಂದರೆ ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಸಣ್ಣ ಒಳಸೇರಿಸುವಿಕೆಗಳು.
ಕ್ಲಿಕ್‌ಹೌಸ್ ಇನ್ಸರ್ಟ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಪರಿಗಣಿಸಿದರೆ, ನೀವು ಒಂದು ವಿನಂತಿಯಲ್ಲಿ ಕನಿಷ್ಠ ಟೆರಾಬೈಟ್ ಡೇಟಾವನ್ನು ಕಳುಹಿಸಬಹುದು. ಅದು ಸಮಸ್ಯೆಯಲ್ಲ.
ಮತ್ತು ವಿಶಿಷ್ಟವಾದ ಕಾರ್ಯಕ್ಷಮತೆ ಏನೆಂದು ನೋಡೋಣ. ಉದಾಹರಣೆಗೆ, ನಾವು Yandex.Metrica ಡೇಟಾದಿಂದ ಟೇಬಲ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಹಿಟ್ಸ್. 105 ಕೆಲವು ಕಾಲಮ್ಗಳು. ಸಂಕ್ಷೇಪಿಸದ 700 ಬೈಟ್‌ಗಳು. ಮತ್ತು ನಾವು ಒಂದು ಮಿಲಿಯನ್ ಸಾಲುಗಳ ಬ್ಯಾಚ್‌ಗಳಲ್ಲಿ ಉತ್ತಮ ರೀತಿಯಲ್ಲಿ ಸೇರಿಸುತ್ತೇವೆ.
ನಾವು ವಿಲೀನ ಟ್ರೀ ಅನ್ನು ಟೇಬಲ್‌ಗೆ ಸೇರಿಸುತ್ತೇವೆ, ಅದು ಸೆಕೆಂಡಿಗೆ ಅರ್ಧ ಮಿಲಿಯನ್ ಸಾಲುಗಳನ್ನು ತಿರುಗಿಸುತ್ತದೆ. ಕುವೆಂಪು. ಪುನರಾವರ್ತಿತ ಕೋಷ್ಟಕದಲ್ಲಿ ಅದು ಸ್ವಲ್ಪ ಚಿಕ್ಕದಾಗಿರುತ್ತದೆ, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸುಮಾರು 400 ಸಾಲುಗಳು.
ಮತ್ತು ನೀವು ಕೋರಮ್ ಅಳವಡಿಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದರೆ, ನೀವು ಸ್ವಲ್ಪ ಕಡಿಮೆ ಪಡೆಯುತ್ತೀರಿ, ಆದರೆ ಇನ್ನೂ ಯೋಗ್ಯವಾದ ಕಾರ್ಯಕ್ಷಮತೆ, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 250 ಪದಗಳು. ಕ್ಲಿಕ್‌ಹೌಸ್*ನಲ್ಲಿ ಕೋರಮ್ ಅಳವಡಿಕೆಯು ದಾಖಲೆರಹಿತ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ.
* 2020 ರಂತೆ, .
ನೀವು ಏನಾದರೂ ಕೆಟ್ಟದ್ದನ್ನು ಮಾಡಿದರೆ ಏನಾಗುತ್ತದೆ? ನಾವು ಒಂದು ಸಾಲನ್ನು MergeTree ಟೇಬಲ್‌ಗೆ ಸೇರಿಸುತ್ತೇವೆ ಮತ್ತು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 59 ಸಾಲುಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಅದು 10 ಪಟ್ಟು ನಿಧಾನವಾಗಿದೆ. ReplicatedMergeTree ನಲ್ಲಿ - ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 000 ಸಾಲುಗಳು. ಮತ್ತು ಕೋರಮ್ ಆನ್ ಆಗಿದ್ದರೆ, ಅದು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 6 ಸಾಲುಗಳನ್ನು ತಿರುಗಿಸುತ್ತದೆ. ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಇದು ಒಂದು ರೀತಿಯ ಸಂಪೂರ್ಣ ಅಮೇಧ್ಯ. ನೀವು ಹಾಗೆ ನಿಧಾನಗೊಳಿಸುವುದು ಹೇಗೆ? ನನ್ನ ಟಿ-ಶರ್ಟ್‌ನಲ್ಲಿ ಕ್ಲಿಕ್‌ಹೌಸ್ ನಿಧಾನವಾಗಬಾರದು ಎಂದು ನಾನು ಬರೆದಿದ್ದೇನೆ. ಆದಾಗ್ಯೂ, ಇದು ಕೆಲವೊಮ್ಮೆ ಸಂಭವಿಸುತ್ತದೆ.
ವಾಸ್ತವವಾಗಿ, ಇದು ನಮ್ಮ ನ್ಯೂನತೆಯಾಗಿದೆ. ನಾವು ಎಲ್ಲವನ್ನೂ ಸುಲಭವಾಗಿ ಕೆಲಸ ಮಾಡಬಹುದಿತ್ತು, ಆದರೆ ನಾವು ಮಾಡಲಿಲ್ಲ. ಮತ್ತು ನಮ್ಮ ಸ್ಕ್ರಿಪ್ಟ್‌ಗೆ ಅಗತ್ಯವಿಲ್ಲದ ಕಾರಣ ನಾವು ಅದನ್ನು ಮಾಡಲಿಲ್ಲ. ನಾವು ಈಗಾಗಲೇ ಕಟುಕರನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನಮ್ಮ ಪ್ರವೇಶದ್ವಾರದಲ್ಲಿ ನಾವು ಬ್ಯಾಚ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ ಮತ್ತು ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲ. ನಾವು ಅದನ್ನು ಸೇರಿಸುತ್ತೇವೆ ಮತ್ತು ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆದರೆ, ಸಹಜವಾಗಿ, ಎಲ್ಲಾ ರೀತಿಯ ಸನ್ನಿವೇಶಗಳು ಸಾಧ್ಯ. ಉದಾಹರಣೆಗೆ, ನೀವು ಡೇಟಾವನ್ನು ರಚಿಸುವ ಸರ್ವರ್‌ಗಳ ಗುಂಪನ್ನು ಹೊಂದಿರುವಾಗ. ಮತ್ತು ಅವರು ಆಗಾಗ್ಗೆ ಡೇಟಾವನ್ನು ಸೇರಿಸುವುದಿಲ್ಲ, ಆದರೆ ಅವುಗಳು ಇನ್ನೂ ಆಗಾಗ್ಗೆ ಒಳಸೇರಿಸುವಿಕೆಯೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ. ಮತ್ತು ನಾವು ಇದನ್ನು ಹೇಗಾದರೂ ತಪ್ಪಿಸಬೇಕು.
ತಾಂತ್ರಿಕ ದೃಷ್ಟಿಕೋನದಿಂದ, ನೀವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಇನ್ಸರ್ಟ್ ಮಾಡಿದಾಗ, ಡೇಟಾವು ಯಾವುದೇ ಮೆಮೆಟಬಲ್‌ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುವುದಿಲ್ಲ. ನಾವು ನಿಜವಾದ ಲಾಗ್ ರಚನೆಯನ್ನು MergeTree ಹೊಂದಿಲ್ಲ, ಆದರೆ ಕೇವಲ MergeTree, ಏಕೆಂದರೆ ಲಾಗ್ ಅಥವಾ ಮೆಮ್‌ಟೇಬಲ್ ಇಲ್ಲ. ನಾವು ಫೈಲ್ ಸಿಸ್ಟಮ್ಗೆ ಡೇಟಾವನ್ನು ತಕ್ಷಣವೇ ಬರೆಯುತ್ತೇವೆ, ಈಗಾಗಲೇ ಕಾಲಮ್ಗಳಲ್ಲಿ ಜೋಡಿಸಲಾಗಿದೆ. ಮತ್ತು ನೀವು 100 ಕಾಲಮ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ 200 ಕ್ಕೂ ಹೆಚ್ಚು ಫೈಲ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಡೈರೆಕ್ಟರಿಗೆ ಬರೆಯಬೇಕಾಗುತ್ತದೆ. ಇದೆಲ್ಲವೂ ತುಂಬಾ ತೊಡಕಾಗಿದೆ.
ಮತ್ತು ಪ್ರಶ್ನೆಯು ಉದ್ಭವಿಸುತ್ತದೆ: "ಅದನ್ನು ಸರಿಯಾಗಿ ಮಾಡುವುದು ಹೇಗೆ?" ನೀವು ಇನ್ನೂ ಹೇಗಾದರೂ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಡೇಟಾವನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಬೇಕಾದ ಪರಿಸ್ಥಿತಿ ಇದ್ದರೆ.
ವಿಧಾನ 1. ಇದು ಸುಲಭವಾದ ಮಾರ್ಗವಾಗಿದೆ. ಕೆಲವು ರೀತಿಯ ವಿತರಿಸಿದ ಕ್ಯೂ ಬಳಸಿ. ಉದಾಹರಣೆಗೆ, ಕಾಫ್ಕಾ. ನೀವು ಕಾಫ್ಕಾದಿಂದ ಡೇಟಾವನ್ನು ಹೊರತೆಗೆಯಿರಿ ಮತ್ತು ಅದನ್ನು ಸೆಕೆಂಡಿಗೆ ಒಮ್ಮೆ ಬ್ಯಾಚ್ ಮಾಡಿ. ಮತ್ತು ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿರುತ್ತದೆ, ನೀವು ರೆಕಾರ್ಡ್ ಮಾಡಿ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಅನನುಕೂಲವೆಂದರೆ ಕಾಫ್ಕಾ ಮತ್ತೊಂದು ಬೃಹತ್ ವಿತರಣೆ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ. ನಿಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ ನೀವು ಈಗಾಗಲೇ ಕಾಫ್ಕಾ ಹೊಂದಿದ್ದರೆ ನಾನು ಸಹ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ. ಇದು ಒಳ್ಳೆಯದು, ಇದು ಅನುಕೂಲಕರವಾಗಿದೆ. ಆದರೆ ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದಿದ್ದರೆ, ನಿಮ್ಮ ಯೋಜನೆಗೆ ಮತ್ತೊಂದು ವಿತರಣೆ ವ್ಯವಸ್ಥೆಯನ್ನು ಎಳೆಯುವ ಮೊದಲು ನೀವು ಮೂರು ಬಾರಿ ಯೋಚಿಸಬೇಕು. ಮತ್ತು ಆದ್ದರಿಂದ ಪರ್ಯಾಯಗಳನ್ನು ಪರಿಗಣಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ.
ವಿಧಾನ 2. ಇದು ಹಳೆಯ ಶಾಲಾ ಪರ್ಯಾಯವಾಗಿದೆ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ತುಂಬಾ ಸರಳವಾಗಿದೆ. ನಿಮ್ಮ ಲಾಗ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸುವ ಕೆಲವು ರೀತಿಯ ಸರ್ವರ್ ಅನ್ನು ನೀವು ಹೊಂದಿದ್ದೀರಾ. ಮತ್ತು ಇದು ನಿಮ್ಮ ದಾಖಲೆಗಳನ್ನು ಫೈಲ್‌ಗೆ ಬರೆಯುತ್ತದೆ. ಮತ್ತು ಸೆಕೆಂಡಿಗೆ ಒಮ್ಮೆ, ಉದಾಹರಣೆಗೆ, ನಾವು ಈ ಫೈಲ್ ಅನ್ನು ಮರುಹೆಸರಿಸುತ್ತೇವೆ ಮತ್ತು ಹೊಸದನ್ನು ಹರಿದು ಹಾಕುತ್ತೇವೆ. ಮತ್ತು ಪ್ರತ್ಯೇಕ ಸ್ಕ್ರಿಪ್ಟ್, ಕ್ರಾನ್ ಅಥವಾ ಕೆಲವು ಡೀಮನ್ ಮೂಲಕ, ಹಳೆಯ ಫೈಲ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಬರೆಯುತ್ತದೆ. ನೀವು ಸೆಕೆಂಡಿಗೆ ಒಮ್ಮೆ ದಾಖಲೆಗಳನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಿದರೆ, ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿರುತ್ತದೆ.
ಆದರೆ ಈ ವಿಧಾನದ ಅನನುಕೂಲವೆಂದರೆ ಲಾಗ್‌ಗಳನ್ನು ರಚಿಸಲಾದ ನಿಮ್ಮ ಸರ್ವರ್ ಎಲ್ಲೋ ಕಣ್ಮರೆಯಾದರೆ, ಡೇಟಾ ಸಹ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ.
ವಿಧಾನ 3. ಮತ್ತೊಂದು ಆಸಕ್ತಿದಾಯಕ ವಿಧಾನವಿದೆ, ಇದು ತಾತ್ಕಾಲಿಕ ಫೈಲ್ಗಳ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ನೀವು ಕೆಲವು ರೀತಿಯ ಜಾಹೀರಾತು ಸ್ಪಿನ್ನರ್ ಅಥವಾ ಡೇಟಾವನ್ನು ಉತ್ಪಾದಿಸುವ ಕೆಲವು ಇತರ ಆಸಕ್ತಿದಾಯಕ ಡೀಮನ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ. ಮತ್ತು ನೀವು RAM ನಲ್ಲಿ, ಬಫರ್‌ನಲ್ಲಿ ನೇರವಾಗಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು. ಮತ್ತು ಸಾಕಷ್ಟು ಸಮಯ ಕಳೆದಾಗ, ನೀವು ಈ ಬಫರ್ ಅನ್ನು ಪಕ್ಕಕ್ಕೆ ಇರಿಸಿ, ಹೊಸದನ್ನು ರಚಿಸಿ ಮತ್ತು ಪ್ರತ್ಯೇಕ ಥ್ರೆಡ್‌ನಲ್ಲಿ, ಈಗಾಗಲೇ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿರುವದನ್ನು ಸೇರಿಸಿ.
ಮತ್ತೊಂದೆಡೆ, ಡೇಟಾ ಕಿಲ್ -9 ನೊಂದಿಗೆ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ. ನಿಮ್ಮ ಸರ್ವರ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ, ನೀವು ಈ ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ. ಮತ್ತು ಇನ್ನೊಂದು ಸಮಸ್ಯೆ ಎಂದರೆ ನೀವು ಡೇಟಾಬೇಸ್‌ಗೆ ಬರೆಯಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ನಿಮ್ಮ ಡೇಟಾವು RAM ನಲ್ಲಿ ಸಂಗ್ರಹಗೊಳ್ಳುತ್ತದೆ. ಮತ್ತು RAM ಖಾಲಿಯಾಗುತ್ತದೆ, ಅಥವಾ ನೀವು ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ.
ವಿಧಾನ 4. ಮತ್ತೊಂದು ಆಸಕ್ತಿದಾಯಕ ವಿಧಾನ. ನೀವು ಕೆಲವು ರೀತಿಯ ಸರ್ವರ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೊಂದಿದ್ದೀರಾ. ಮತ್ತು ಇದು ತಕ್ಷಣವೇ ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಡೇಟಾವನ್ನು ಕಳುಹಿಸಬಹುದು, ಆದರೆ ಅದನ್ನು ಒಂದು ಸಂಪರ್ಕದಲ್ಲಿ ಮಾಡಿ. ಉದಾಹರಣೆಗೆ, ನಾನು ವರ್ಗಾವಣೆ-ಎನ್‌ಕೋಡಿಂಗ್‌ನೊಂದಿಗೆ http ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿದ್ದೇನೆ: ಸೇರಿಸುವಿಕೆಯೊಂದಿಗೆ ಭಾಗಿಸಲಾಗಿದೆ. ಮತ್ತು ಇದು ತುಂಬಾ ವಿರಳವಾಗಿ ತುಣುಕುಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ನೀವು ಪ್ರತಿ ಸಾಲನ್ನು ಕಳುಹಿಸಬಹುದು, ಆದರೂ ಈ ಡೇಟಾವನ್ನು ರೂಪಿಸಲು ಓವರ್ಹೆಡ್ ಇರುತ್ತದೆ.
ಆದಾಗ್ಯೂ, ಈ ಸಂದರ್ಭದಲ್ಲಿ ಡೇಟಾವನ್ನು ತಕ್ಷಣವೇ ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್ ಅವುಗಳನ್ನು ಸ್ವತಃ ಬಫರ್ ಮಾಡುತ್ತದೆ.
ಆದರೆ ಸಮಸ್ಯೆಗಳೂ ಉದ್ಭವಿಸುತ್ತವೆ. ನಿಮ್ಮ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಯಾವಾಗ ಕೊಲ್ಲಲಾಗುತ್ತದೆ ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್ ಪ್ರಕ್ರಿಯೆಯು ಕೊಲ್ಲಲ್ಪಟ್ಟರೆ ಅದು ಅಪೂರ್ಣವಾದ ಇನ್ಸರ್ಟ್ ಆಗಿರುವುದರಿಂದ ಈಗ ನೀವು ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ. ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಒಳಸೇರಿಸುವಿಕೆಗಳು ಸಾಲುಗಳ ಗಾತ್ರದಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಮಿತಿಯವರೆಗೆ ಪರಮಾಣುಗಳಾಗಿವೆ. ತಾತ್ವಿಕವಾಗಿ, ಇದು ಆಸಕ್ತಿದಾಯಕ ಮಾರ್ಗವಾಗಿದೆ. ಸಹ ಬಳಸಬಹುದು.
ವಿಧಾನ 5. ಇಲ್ಲಿ ಮತ್ತೊಂದು ಆಸಕ್ತಿದಾಯಕ ವಿಧಾನವಾಗಿದೆ. ಡೇಟಾ ಬ್ಯಾಚಿಂಗ್‌ಗಾಗಿ ಇದು ಕೆಲವು ರೀತಿಯ ಸಮುದಾಯ-ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಸರ್ವರ್ ಆಗಿದೆ. ನಾನು ಅದನ್ನು ನಾನೇ ನೋಡಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾನು ಏನನ್ನೂ ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಯಾವುದೇ ಗ್ಯಾರಂಟಿಗಳನ್ನು ಒದಗಿಸಲಾಗಿಲ್ಲ. ಇದು ಮುಕ್ತ ಮೂಲವಾಗಿದೆ, ಆದರೆ ಮತ್ತೊಂದೆಡೆ, ನಾವು ಒದಗಿಸಲು ಪ್ರಯತ್ನಿಸುವ ಕೆಲವು ಗುಣಮಟ್ಟದ ಮಾನದಂಡಗಳಿಗೆ ನೀವು ಬಳಸಬಹುದು. ಆದರೆ ಈ ವಿಷಯಕ್ಕಾಗಿ - ನನಗೆ ಗೊತ್ತಿಲ್ಲ, GitHub ಗೆ ಹೋಗಿ, ಕೋಡ್ ಅನ್ನು ನೋಡಿ. ಬಹುಶಃ ಅವರು ಸಾಮಾನ್ಯ ಏನೋ ಬರೆದಿದ್ದಾರೆ.
* 2020 ರಂತೆ, ಪರಿಗಣನೆಗೆ ಸೇರಿಸಬೇಕು .
ವಿಧಾನ 6. ಬಫರ್ ಕೋಷ್ಟಕಗಳನ್ನು ಬಳಸುವುದು ಇನ್ನೊಂದು ವಿಧಾನವಾಗಿದೆ. ಈ ವಿಧಾನದ ಪ್ರಯೋಜನವೆಂದರೆ ಅದನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸುವುದು ತುಂಬಾ ಸುಲಭ. ಬಫರ್ ಟೇಬಲ್ ಅನ್ನು ರಚಿಸಿ ಮತ್ತು ಅದನ್ನು ಸೇರಿಸಿ.
ಅನನುಕೂಲವೆಂದರೆ ಸಮಸ್ಯೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪರಿಹರಿಸಲಾಗಿಲ್ಲ. MergeTree ನಂತಹ ದರದಲ್ಲಿ, ನೀವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಒಂದು ಬ್ಯಾಚ್‌ನಂತೆ ಡೇಟಾವನ್ನು ಗುಂಪು ಮಾಡಬೇಕಾದರೆ, ನಂತರ ಬಫರ್ ಕೋಷ್ಟಕದಲ್ಲಿನ ದರದಲ್ಲಿ, ನೀವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಕನಿಷ್ಠ ಹಲವಾರು ಸಾವಿರದವರೆಗೆ ಗುಂಪು ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಇದು ಸೆಕೆಂಡಿಗೆ 10 ಕ್ಕಿಂತ ಹೆಚ್ಚಿದ್ದರೆ, ಅದು ಇನ್ನೂ ಕೆಟ್ಟದಾಗಿರುತ್ತದೆ. ಮತ್ತು ನೀವು ಅದನ್ನು ಬ್ಯಾಚ್‌ಗಳಲ್ಲಿ ಸೇರಿಸಿದರೆ, ಅದು ಸೆಕೆಂಡಿಗೆ ನೂರು ಸಾವಿರ ಸಾಲುಗಳಾಗಿ ಹೊರಹೊಮ್ಮುತ್ತದೆ ಎಂದು ನೀವು ನೋಡಿದ್ದೀರಿ. ಮತ್ತು ಇದು ಈಗಾಗಲೇ ಸಾಕಷ್ಟು ಭಾರೀ ಡೇಟಾದಲ್ಲಿದೆ.
ಮತ್ತು ಬಫರ್ ಕೋಷ್ಟಕಗಳು ಲಾಗ್ ಅನ್ನು ಹೊಂದಿಲ್ಲ. ಮತ್ತು ನಿಮ್ಮ ಸರ್ವರ್‌ನಲ್ಲಿ ಏನಾದರೂ ದೋಷವಿದ್ದರೆ, ಡೇಟಾ ಕಳೆದುಹೋಗುತ್ತದೆ.
ಮತ್ತು ಬೋನಸ್ ಆಗಿ, ಕಾಫ್ಕಾದಿಂದ ಡೇಟಾವನ್ನು ಹಿಂಪಡೆಯಲು ನಾವು ಇತ್ತೀಚೆಗೆ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಅವಕಾಶವನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ. ಟೇಬಲ್ ಎಂಜಿನ್ ಇದೆ - ಕಾಫ್ಕಾ. ನೀವು ಸರಳವಾಗಿ ರಚಿಸಿ. ಮತ್ತು ನೀವು ಅದರ ಮೇಲೆ ವಸ್ತುರೂಪದ ಪ್ರಾತಿನಿಧ್ಯಗಳನ್ನು ಸ್ಥಗಿತಗೊಳಿಸಬಹುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಅದು ಸ್ವತಃ ಕಾಫ್ಕಾದಿಂದ ಡೇಟಾವನ್ನು ಹೊರತೆಗೆಯುತ್ತದೆ ಮತ್ತು ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಕೋಷ್ಟಕಗಳಲ್ಲಿ ಸೇರಿಸುತ್ತದೆ.
ಮತ್ತು ಈ ಅವಕಾಶದ ಬಗ್ಗೆ ವಿಶೇಷವಾಗಿ ಸಂತೋಷಪಡುವ ವಿಷಯವೆಂದರೆ ಅದನ್ನು ಮಾಡಿದ್ದು ನಾವಲ್ಲ. ಇದು ಸಮುದಾಯದ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ. ಮತ್ತು ನಾನು "ಸಮುದಾಯ ವೈಶಿಷ್ಟ್ಯ" ಎಂದು ಹೇಳಿದಾಗ ನಾನು ಅದನ್ನು ಯಾವುದೇ ತಿರಸ್ಕಾರವಿಲ್ಲದೆ ಅರ್ಥೈಸುತ್ತೇನೆ. ನಾವು ಕೋಡ್ ಅನ್ನು ಓದಿದ್ದೇವೆ, ವಿಮರ್ಶೆಯನ್ನು ಮಾಡಿದ್ದೇವೆ, ಅದು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು.
* 2020 ರ ಹೊತ್ತಿಗೆ, ಇದೇ ರೀತಿಯ ಬೆಂಬಲವು ಕಾಣಿಸಿಕೊಂಡಿದೆ .
ಡೇಟಾವನ್ನು ಸೇರಿಸುವಾಗ ಅನನುಕೂಲ ಅಥವಾ ಅನಿರೀಕ್ಷಿತ ಬೇರೆ ಏನು? ನೀವು ಮೌಲ್ಯಗಳನ್ನು ಸೇರಿಸಲು ವಿನಂತಿಸಿದರೆ ಮತ್ತು ಮೌಲ್ಯಗಳಲ್ಲಿ ಕೆಲವು ಲೆಕ್ಕಾಚಾರದ ಅಭಿವ್ಯಕ್ತಿಗಳನ್ನು ಬರೆಯಿರಿ. ಉದಾಹರಣೆಗೆ, now() ಕೂಡ ಲೆಕ್ಕಾಚಾರದ ಅಭಿವ್ಯಕ್ತಿಯಾಗಿದೆ. ಮತ್ತು ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಕ್ಲಿಕ್‌ಹೌಸ್ ಪ್ರತಿ ಸಾಲಿನಲ್ಲಿ ಈ ಅಭಿವ್ಯಕ್ತಿಗಳ ಇಂಟರ್ಪ್ರಿಟರ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಬಲವಂತವಾಗಿ, ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯು ಪರಿಮಾಣದ ಆದೇಶಗಳಿಂದ ಕುಸಿಯುತ್ತದೆ. ಇದನ್ನು ತಪ್ಪಿಸುವುದು ಉತ್ತಮ.
* ಈ ಸಮಯದಲ್ಲಿ, ಸಮಸ್ಯೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪರಿಹರಿಸಲಾಗಿದೆ, VALUES ನಲ್ಲಿ ಅಭಿವ್ಯಕ್ತಿಗಳನ್ನು ಬಳಸುವಾಗ ಇನ್ನು ಮುಂದೆ ಯಾವುದೇ ಕಾರ್ಯಕ್ಷಮತೆಯ ಹಿಂಜರಿಕೆ ಇರುವುದಿಲ್ಲ.
ಮತ್ತೊಂದು ಉದಾಹರಣೆಯೆಂದರೆ, ನೀವು ಒಂದು ಗುಂಪಿನಲ್ಲಿ ಡೇಟಾವನ್ನು ಹೊಂದಿರುವಾಗ ಕೆಲವು ಸಮಸ್ಯೆಗಳಾಗಬಹುದು ಅದು ವಿಭಾಗಗಳ ಗುಂಪಿಗೆ ಸೇರಿದೆ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಕ್ಲಿಕ್‌ಹೌಸ್ ವಿಭಾಗಗಳು ತಿಂಗಳಿಗೊಮ್ಮೆ. ಮತ್ತು ನೀವು ಮಿಲಿಯನ್ ಸಾಲುಗಳ ಬ್ಯಾಚ್ ಅನ್ನು ಸೇರಿಸಿದರೆ ಮತ್ತು ಹಲವಾರು ವರ್ಷಗಳವರೆಗೆ ಡೇಟಾ ಇದ್ದರೆ, ನೀವು ಅಲ್ಲಿ ಹಲವಾರು ಡಜನ್ ವಿಭಾಗಗಳನ್ನು ಹೊಂದಿರುತ್ತೀರಿ. ಮತ್ತು ಗಾತ್ರದಲ್ಲಿ ಹಲವಾರು ಹತ್ತಾರು ಪಟ್ಟು ಚಿಕ್ಕದಾದ ಬ್ಯಾಚ್‌ಗಳು ಇರುತ್ತವೆ ಎಂಬ ಅಂಶಕ್ಕೆ ಇದು ಸಮನಾಗಿರುತ್ತದೆ, ಏಕೆಂದರೆ ಒಳಗೆ ಅವುಗಳನ್ನು ಯಾವಾಗಲೂ ಮೊದಲು ವಿಭಾಗಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ.
* ಇತ್ತೀಚೆಗೆ, ಪ್ರಾಯೋಗಿಕ ಮೋಡ್‌ನಲ್ಲಿ, ಕ್ಲಿಕ್‌ಹೌಸ್ ರೈಟ್-ಎಹೆಡ್ ಲಾಗ್‌ನೊಂದಿಗೆ RAM ನಲ್ಲಿ ಚಂಕ್ಸ್ ಮತ್ತು ಚಂಕ್‌ಗಳ ಕಾಂಪ್ಯಾಕ್ಟ್ ಫಾರ್ಮ್ಯಾಟ್‌ಗೆ ಬೆಂಬಲವನ್ನು ಸೇರಿಸಿದೆ, ಇದು ಸಮಸ್ಯೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪರಿಹರಿಸುತ್ತದೆ.
ಈಗ ಎರಡನೇ ರೀತಿಯ ಸಮಸ್ಯೆಯನ್ನು ನೋಡೋಣ - ಡೇಟಾ ಟೈಪಿಂಗ್.
ಡೇಟಾ ಟೈಪಿಂಗ್ ಕಟ್ಟುನಿಟ್ಟಾಗಿರಬಹುದು ಅಥವಾ ಸ್ಟ್ರಿಂಗ್ ಆಗಿರಬಹುದು. ಸ್ಟ್ರಿಂಗ್ ಎಂದರೆ ನೀವು ಅದನ್ನು ತೆಗೆದುಕೊಂಡು ನಿಮ್ಮ ಎಲ್ಲಾ ಕ್ಷೇತ್ರಗಳು ಸ್ಟ್ರಿಂಗ್ ಪ್ರಕಾರ ಎಂದು ಘೋಷಿಸಿದಾಗ. ಇದು ಹೀರುತ್ತದೆ. ಇದನ್ನು ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ.
ನಮ್ಮಲ್ಲಿ ಕೆಲವು ಕ್ಷೇತ್ರ, ಸ್ಟ್ರಿಂಗ್ ಇದೆ ಎಂದು ನೀವು ಹೇಳಲು ಬಯಸಿದಾಗ ಆ ಸಂದರ್ಭಗಳಲ್ಲಿ ಅದನ್ನು ಸರಿಯಾಗಿ ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್ ಅದನ್ನು ತನ್ನದೇ ಆದ ಮೇಲೆ ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಅವಕಾಶ ಮಾಡಿಕೊಡಿ ಮತ್ತು ನಾನು ತಲೆಕೆಡಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಆದರೆ ಇನ್ನೂ ಸ್ವಲ್ಪ ಪ್ರಯತ್ನ ಮಾಡುವುದು ಯೋಗ್ಯವಾಗಿದೆ.
ಉದಾಹರಣೆಗೆ, ನಾವು IP ವಿಳಾಸವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಒಂದು ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಅದನ್ನು ಸ್ಟ್ರಿಂಗ್ ಆಗಿ ಉಳಿಸಿದ್ದೇವೆ. ಉದಾಹರಣೆಗೆ, 192.168.1.1. ಮತ್ತು ಇನ್ನೊಂದು ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಹಲವಾರು ರೀತಿಯ UInt32* ಆಗಿರುತ್ತದೆ. IPv32 ವಿಳಾಸಕ್ಕೆ 4 ಬಿಟ್‌ಗಳು ಸಾಕು.
ಮೊದಲನೆಯದಾಗಿ, ವಿಚಿತ್ರವಾಗಿ ಸಾಕಷ್ಟು, ಡೇಟಾವನ್ನು ಸರಿಸುಮಾರು ಸಮಾನವಾಗಿ ಸಂಕುಚಿತಗೊಳಿಸಲಾಗುತ್ತದೆ. ಸಹಜವಾಗಿ, ವ್ಯತ್ಯಾಸವಿರುತ್ತದೆ, ಆದರೆ ಅಷ್ಟು ದೊಡ್ಡದಲ್ಲ. ಆದ್ದರಿಂದ ಡಿಸ್ಕ್ I/O ನಲ್ಲಿ ಯಾವುದೇ ವಿಶೇಷ ಸಮಸ್ಯೆಗಳಿಲ್ಲ.
ಆದರೆ ಪ್ರೊಸೆಸರ್ ಸಮಯ ಮತ್ತು ಕ್ವೆರಿ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಸಮಯದಲ್ಲಿ ಗಂಭೀರ ವ್ಯತ್ಯಾಸವಿದೆ.
ಅನನ್ಯ IP ವಿಳಾಸಗಳನ್ನು ಸಂಖ್ಯೆಗಳಾಗಿ ಸಂಗ್ರಹಿಸಿದ್ದರೆ ಅವುಗಳ ಸಂಖ್ಯೆಯನ್ನು ಎಣಿಸೋಣ. ಅದು ಸೆಕೆಂಡಿಗೆ 137 ಮಿಲಿಯನ್ ಲೈನ್‌ಗಳಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಅದೇ ತಂತಿಗಳ ರೂಪದಲ್ಲಿದ್ದರೆ, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 37 ಮಿಲಿಯನ್ ಸಾಲುಗಳು. ಈ ಕಾಕತಾಳೀಯ ಏಕೆ ಸಂಭವಿಸಿತು ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ. ಈ ಮನವಿಗಳನ್ನು ನಾನೇ ನೆರವೇರಿಸಿದೆ. ಆದರೆ ಇನ್ನೂ ಸುಮಾರು 4 ಪಟ್ಟು ನಿಧಾನವಾಗಿದೆ.
ಮತ್ತು ನೀವು ಡಿಸ್ಕ್ ಜಾಗದಲ್ಲಿ ವ್ಯತ್ಯಾಸವನ್ನು ಲೆಕ್ಕ ಹಾಕಿದರೆ, ನಂತರ ವ್ಯತ್ಯಾಸವೂ ಇದೆ. ಮತ್ತು ವ್ಯತ್ಯಾಸವು ಸುಮಾರು ಕಾಲು ಭಾಗವಾಗಿದೆ, ಏಕೆಂದರೆ ಸಾಕಷ್ಟು ಅನನ್ಯ IP ವಿಳಾಸಗಳಿವೆ. ಮತ್ತು ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ವಿಭಿನ್ನ ಅರ್ಥಗಳನ್ನು ಹೊಂದಿರುವ ಸಾಲುಗಳಿದ್ದರೆ, ಅವುಗಳನ್ನು ನಿಘಂಟಿನ ಪ್ರಕಾರ ಸರಿಸುಮಾರು ಒಂದೇ ಪರಿಮಾಣಕ್ಕೆ ಸುಲಭವಾಗಿ ಸಂಕುಚಿತಗೊಳಿಸಲಾಗುತ್ತದೆ.
ಮತ್ತು ನಾಲ್ಕು ಪಟ್ಟು ಸಮಯದ ವ್ಯತ್ಯಾಸವು ರಸ್ತೆಯ ಮೇಲೆ ಇರುವುದಿಲ್ಲ. ಬಹುಶಃ ನೀವು ಡ್ಯಾಮ್ ನೀಡುವುದಿಲ್ಲ, ಖಂಡಿತ, ಆದರೆ ನಾನು ಅಂತಹ ವ್ಯತ್ಯಾಸವನ್ನು ನೋಡಿದಾಗ, ಅದು ನನಗೆ ಬೇಸರವನ್ನುಂಟುಮಾಡುತ್ತದೆ.
ವಿವಿಧ ಪ್ರಕರಣಗಳನ್ನು ನೋಡೋಣ.
1. ನೀವು ಕೆಲವು ವಿಭಿನ್ನ ಅನನ್ಯ ಮೌಲ್ಯಗಳನ್ನು ಹೊಂದಿರುವಾಗ ಒಂದು ಪ್ರಕರಣ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಬಹುಶಃ ತಿಳಿದಿರುವ ಮತ್ತು ಯಾವುದೇ DBMS ಗೆ ಬಳಸಬಹುದಾದ ಸರಳ ಅಭ್ಯಾಸವನ್ನು ನಾವು ಬಳಸುತ್ತೇವೆ. ಇದು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಮಾತ್ರವಲ್ಲದೆ ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ. ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಂಖ್ಯಾ ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ಬರೆಯಿರಿ. ಮತ್ತು ನೀವು ತಂತಿಗಳಿಗೆ ಪರಿವರ್ತಿಸಬಹುದು ಮತ್ತು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಬದಿಯಲ್ಲಿ ಹಿಂತಿರುಗಬಹುದು.
ಉದಾಹರಣೆಗೆ, ನೀವು ಪ್ರದೇಶವನ್ನು ಹೊಂದಿದ್ದೀರಿ. ಮತ್ತು ನೀವು ಅದನ್ನು ಸ್ಟ್ರಿಂಗ್ ಆಗಿ ಉಳಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೀರಿ. ಮತ್ತು ಅದನ್ನು ಅಲ್ಲಿ ಬರೆಯಲಾಗುವುದು: ಮಾಸ್ಕೋ ಮತ್ತು ಮಾಸ್ಕೋ ಪ್ರದೇಶ. ಮತ್ತು ಅದು "ಮಾಸ್ಕೋ" ಎಂದು ಹೇಳುವುದನ್ನು ನಾನು ನೋಡಿದಾಗ, ಅದು ಏನೂ ಅಲ್ಲ, ಆದರೆ ಅದು ಮಾಸ್ಕೋದಲ್ಲಿ, ಅದು ಹೇಗಾದರೂ ಸಂಪೂರ್ಣವಾಗಿ ದುಃಖವಾಗುತ್ತದೆ. ಇದು ಎಷ್ಟು ಬೈಟ್‌ಗಳು.
ಬದಲಿಗೆ, ನಾವು Ulnt32 ಮತ್ತು 250 ಸಂಖ್ಯೆಯನ್ನು ಸರಳವಾಗಿ ಬರೆಯುತ್ತೇವೆ. Yandex ನಲ್ಲಿ ನಾವು 250 ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಆದರೆ ನಿಮ್ಮದು ವಿಭಿನ್ನವಾಗಿರಬಹುದು. ಒಂದು ವೇಳೆ, ಜಿಯೋಬೇಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಕ್ಲಿಕ್‌ಹೌಸ್ ಅಂತರ್ನಿರ್ಮಿತ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದೆ ಎಂದು ನಾನು ಹೇಳುತ್ತೇನೆ. ನೀವು ಕ್ರಮಾನುಗತ ಸೇರಿದಂತೆ ಪ್ರದೇಶಗಳೊಂದಿಗೆ ಡೈರೆಕ್ಟರಿಯನ್ನು ಸರಳವಾಗಿ ಬರೆಯಿರಿ, ಅಂದರೆ ಮಾಸ್ಕೋ, ಮಾಸ್ಕೋ ಪ್ರದೇಶ ಮತ್ತು ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲವೂ ಇರುತ್ತದೆ. ಮತ್ತು ನೀವು ವಿನಂತಿಯ ಮಟ್ಟದಲ್ಲಿ ಪರಿವರ್ತಿಸಬಹುದು.
ಎರಡನೆಯ ಆಯ್ಕೆಯು ಸರಿಸುಮಾರು ಒಂದೇ ಆಗಿರುತ್ತದೆ, ಆದರೆ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಬೆಂಬಲದೊಂದಿಗೆ. ಇದು ಎನಮ್ ಡೇಟಾ ಪ್ರಕಾರವಾಗಿದೆ. ಎನಮ್ ಒಳಗೆ ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಮೌಲ್ಯಗಳನ್ನು ನೀವು ಸರಳವಾಗಿ ಬರೆಯುತ್ತೀರಿ. ಉದಾಹರಣೆಗೆ, ಸಾಧನದ ಪ್ರಕಾರ ಮತ್ತು ಅಲ್ಲಿ ಬರೆಯಿರಿ: ಡೆಸ್ಕ್ಟಾಪ್, ಮೊಬೈಲ್, ಟ್ಯಾಬ್ಲೆಟ್, ಟಿವಿ. ಒಟ್ಟು 4 ಆಯ್ಕೆಗಳಿವೆ.
ಅನನುಕೂಲವೆಂದರೆ ನೀವು ಅದನ್ನು ನಿಯತಕಾಲಿಕವಾಗಿ ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ. ಕೇವಲ ಒಂದು ಆಯ್ಕೆಯನ್ನು ಸೇರಿಸಲಾಗಿದೆ. ಟೇಬಲ್ ಅನ್ನು ಬದಲಾಯಿಸೋಣ. ವಾಸ್ತವವಾಗಿ, ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಟೇಬಲ್ ಅನ್ನು ಬದಲಾಯಿಸುವುದು ಉಚಿತವಾಗಿದೆ. ಡಿಸ್ಕ್ನಲ್ಲಿನ ಡೇಟಾ ಬದಲಾಗದ ಕಾರಣ Enum ಗೆ ವಿಶೇಷವಾಗಿ ಉಚಿತವಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಆಲ್ಟರ್ ಮೇಜಿನ ಮೇಲೆ ಲಾಕ್ ಅನ್ನು ಪಡೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಾ ಆಯ್ಕೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವವರೆಗೆ ಕಾಯಬೇಕು. ಮತ್ತು ಇದರ ನಂತರ ಮಾತ್ರ ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ, ಅಂದರೆ ಇನ್ನೂ ಕೆಲವು ಅನಾನುಕೂಲತೆಗಳಿವೆ.
* ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಗಳಲ್ಲಿ, ALTER ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಬಂಧಿಸದಂತೆ ಮಾಡಲಾಗಿದೆ.
ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಸಾಕಷ್ಟು ವಿಶಿಷ್ಟವಾದ ಮತ್ತೊಂದು ಆಯ್ಕೆಯು ಬಾಹ್ಯ ನಿಘಂಟುಗಳನ್ನು ಸಂಪರ್ಕಿಸುತ್ತದೆ. ನೀವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಸಂಖ್ಯೆಗಳನ್ನು ಬರೆಯಬಹುದು ಮತ್ತು ನಿಮ್ಮ ಡೈರೆಕ್ಟರಿಗಳನ್ನು ನಿಮಗೆ ಅನುಕೂಲಕರವಾದ ಯಾವುದೇ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಇರಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ನೀವು ಇದನ್ನು ಬಳಸಬಹುದು: MySQL, Mongo, Postgres. ಈ ಡೇಟಾವನ್ನು http ಮೂಲಕ ಕಳುಹಿಸುವ ನಿಮ್ಮ ಸ್ವಂತ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಅನ್ನು ಸಹ ನೀವು ರಚಿಸಬಹುದು. ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್ ಮಟ್ಟದಲ್ಲಿ, ಈ ಡೇಟಾವನ್ನು ಸಂಖ್ಯೆಗಳಿಂದ ತಂತಿಗಳಿಗೆ ಪರಿವರ್ತಿಸುವ ಕಾರ್ಯವನ್ನು ನೀವು ಬರೆಯುತ್ತೀರಿ.
ಬಾಹ್ಯ ಕೋಷ್ಟಕದಲ್ಲಿ ಸೇರ್ಪಡೆ ಮಾಡಲು ಇದು ವಿಶೇಷವಾದ ಆದರೆ ಅತ್ಯಂತ ಪರಿಣಾಮಕಾರಿ ಮಾರ್ಗವಾಗಿದೆ. ಮತ್ತು ಎರಡು ಆಯ್ಕೆಗಳಿವೆ. ಒಂದು ಸಾಕಾರದಲ್ಲಿ, ಈ ಡೇಟಾವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, RAM ನಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಇರುತ್ತದೆ ಮತ್ತು ಕೆಲವು ಆವರ್ತನದೊಂದಿಗೆ ನವೀಕರಿಸಲಾಗುತ್ತದೆ. ಮತ್ತು ಇನ್ನೊಂದು ಆಯ್ಕೆಯಲ್ಲಿ, ಈ ಡೇಟಾವು RAM ಗೆ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಭಾಗಶಃ ಸಂಗ್ರಹಿಸಬಹುದು.
ಒಂದು ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ. Yandex.Direct ಇದೆ. ಮತ್ತು ಜಾಹೀರಾತು ಕಂಪನಿ ಮತ್ತು ಬ್ಯಾನರ್‌ಗಳಿವೆ. ಸುಮಾರು ಹತ್ತಾರು ಮಿಲಿಯನ್‌ಗಳಷ್ಟು ಜಾಹೀರಾತು ಕಂಪನಿಗಳಿವೆ. ಮತ್ತು ಅವರು ಸರಿಸುಮಾರು RAM ಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತಾರೆ. ಮತ್ತು ಶತಕೋಟಿ ಬ್ಯಾನರ್‌ಗಳಿವೆ, ಅವು ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ಮತ್ತು ನಾವು MySQL ನಿಂದ ಸಂಗ್ರಹಿಸಲಾದ ನಿಘಂಟನ್ನು ಬಳಸುತ್ತೇವೆ.
ಹಿಟ್ ದರವು 100% ರ ಸಮೀಪದಲ್ಲಿದ್ದರೆ ಕ್ಯಾಶ್ ಮಾಡಿದ ನಿಘಂಟು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದು ಒಂದೇ ಸಮಸ್ಯೆ. ಅದು ಚಿಕ್ಕದಾಗಿದ್ದರೆ, ಪ್ರತಿ ಬ್ಯಾಚ್ ಡೇಟಾಕ್ಕಾಗಿ ಪ್ರಶ್ನೆಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವಾಗ, ನೀವು ನಿಜವಾಗಿಯೂ ಕಾಣೆಯಾದ ಕೀಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ ಮತ್ತು MySQL ನಿಂದ ಡೇಟಾವನ್ನು ಪಡೆದುಕೊಳ್ಳಬೇಕು. ಕ್ಲಿಕ್‌ಹೌಸ್ ಕುರಿತು, ನಾನು ಇನ್ನೂ ಖಾತರಿ ನೀಡಬಲ್ಲೆ - ಹೌದು, ಅದು ನಿಧಾನವಾಗುವುದಿಲ್ಲ, ನಾನು ಇತರ ಸಿಸ್ಟಮ್‌ಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುವುದಿಲ್ಲ.
ಮತ್ತು ಬೋನಸ್ ಆಗಿ, ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಪೂರ್ವಾನ್ವಯವಾಗಿ ನವೀಕರಿಸಲು ನಿಘಂಟುಗಳು ತುಂಬಾ ಸುಲಭವಾದ ಮಾರ್ಗವಾಗಿದೆ. ಅಂದರೆ, ನೀವು ಜಾಹೀರಾತು ಕಂಪನಿಗಳ ಕುರಿತು ವರದಿಯನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಬಳಕೆದಾರರು ಸರಳವಾಗಿ ಜಾಹೀರಾತು ಕಂಪನಿಯನ್ನು ಬದಲಾಯಿಸಿದ್ದಾರೆ ಮತ್ತು ಎಲ್ಲಾ ಹಳೆಯ ಡೇಟಾದಲ್ಲಿ, ಎಲ್ಲಾ ವರದಿಗಳಲ್ಲಿ, ಈ ಡೇಟಾ ಕೂಡ ಬದಲಾಗಿದೆ. ನೀವು ನೇರವಾಗಿ ಟೇಬಲ್‌ಗೆ ಸಾಲುಗಳನ್ನು ಬರೆದರೆ, ಅವುಗಳನ್ನು ನವೀಕರಿಸಲು ಅಸಾಧ್ಯವಾಗುತ್ತದೆ.
ನಿಮ್ಮ ಸ್ಟ್ರಿಂಗ್‌ಗಳಿಗಾಗಿ ಐಡೆಂಟಿಫೈಯರ್‌ಗಳನ್ನು ಎಲ್ಲಿ ಪಡೆಯಬೇಕೆಂದು ನಿಮಗೆ ತಿಳಿದಿಲ್ಲದಿದ್ದಾಗ ಇನ್ನೊಂದು ಮಾರ್ಗ. ನೀವು ಅದನ್ನು ಸರಳವಾಗಿ ಹ್ಯಾಶ್ ಮಾಡಬಹುದು. ಇದಲ್ಲದೆ, 64-ಬಿಟ್ ಹ್ಯಾಶ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು ಸರಳವಾದ ಆಯ್ಕೆಯಾಗಿದೆ.
ಒಂದೇ ಸಮಸ್ಯೆಯೆಂದರೆ ಹ್ಯಾಶ್ 64-ಬಿಟ್ ಆಗಿದ್ದರೆ, ನೀವು ಬಹುತೇಕ ಖಚಿತವಾಗಿ ಘರ್ಷಣೆಯನ್ನು ಹೊಂದಿರುತ್ತೀರಿ. ಏಕೆಂದರೆ ಅಲ್ಲಿ ಒಂದು ಶತಕೋಟಿ ಸಾಲುಗಳಿದ್ದರೆ, ಸಂಭವನೀಯತೆಯು ಈಗಾಗಲೇ ಗಮನಾರ್ಹವಾಗುತ್ತದೆ.
ಮತ್ತು ಜಾಹೀರಾತು ಕಂಪನಿಗಳ ಹೆಸರನ್ನು ಈ ರೀತಿಯಲ್ಲಿ ಹ್ಯಾಶ್ ಮಾಡುವುದು ತುಂಬಾ ಒಳ್ಳೆಯದಲ್ಲ. ವಿವಿಧ ಕಂಪನಿಗಳ ಜಾಹೀರಾತು ಪ್ರಚಾರಗಳನ್ನು ಬೆರೆಸಿದರೆ, ಅರ್ಥವಾಗದ ಏನಾದರೂ ಇರುತ್ತದೆ.
ಮತ್ತು ಒಂದು ಸರಳ ಟ್ರಿಕ್ ಇದೆ. ನಿಜ, ಇದು ಗಂಭೀರ ಡೇಟಾಗೆ ತುಂಬಾ ಸೂಕ್ತವಲ್ಲ, ಆದರೆ ಏನಾದರೂ ತುಂಬಾ ಗಂಭೀರವಾಗಿಲ್ಲದಿದ್ದರೆ, ಕ್ಲೈಂಟ್ ಐಡೆಂಟಿಫೈಯರ್ ಅನ್ನು ನಿಘಂಟು ಕೀಗೆ ಸೇರಿಸಿ. ಮತ್ತು ನಂತರ ನೀವು ಘರ್ಷಣೆಗಳು ಹೊಂದಿರುತ್ತದೆ, ಆದರೆ ಕೇವಲ ಒಂದು ಕ್ಲೈಂಟ್ ಒಳಗೆ. ಮತ್ತು Yandex.Metrica ನಲ್ಲಿ ಲಿಂಕ್ ನಕ್ಷೆಗಳಿಗಾಗಿ ನಾವು ಈ ವಿಧಾನವನ್ನು ಬಳಸುತ್ತೇವೆ. ನಾವು ಅಲ್ಲಿ URL ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ನಾವು ಹ್ಯಾಶ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ. ಮತ್ತು ಸಹಜವಾಗಿ, ಘರ್ಷಣೆಗಳು ಇವೆ ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ. ಆದರೆ ಪುಟವನ್ನು ಪ್ರದರ್ಶಿಸಿದಾಗ, ಒಬ್ಬ ಬಳಕೆದಾರರ ಒಂದು ಪುಟದಲ್ಲಿ ಕೆಲವು URL ಗಳು ಒಟ್ಟಿಗೆ ಅಂಟಿಕೊಂಡಿರುತ್ತವೆ ಮತ್ತು ಇದು ಗಮನಕ್ಕೆ ಬರುವ ಸಂಭವನೀಯತೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸಬಹುದು.
ಬೋನಸ್ ಆಗಿ, ಅನೇಕ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಹ್ಯಾಶ್‌ಗಳು ಮಾತ್ರ ಸಾಕಾಗುತ್ತದೆ ಮತ್ತು ತಂತಿಗಳನ್ನು ಎಲ್ಲಿಯೂ ಸಂಗ್ರಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.
ಇನ್ನೊಂದು ಉದಾಹರಣೆಯೆಂದರೆ ಸ್ಟ್ರಿಂಗ್‌ಗಳು ಚಿಕ್ಕದಾಗಿದ್ದರೆ, ಉದಾಹರಣೆಗೆ, ವೆಬ್‌ಸೈಟ್ ಡೊಮೇನ್‌ಗಳು. ಅವುಗಳನ್ನು ಹಾಗೆಯೇ ಸಂಗ್ರಹಿಸಬಹುದು. ಅಥವಾ, ಉದಾಹರಣೆಗೆ, ಬ್ರೌಸರ್ ಭಾಷೆ ru 2 ಬೈಟ್‌ಗಳು. ಸಹಜವಾಗಿ, ಬೈಟ್‌ಗಳಿಗಾಗಿ ನಾನು ನಿಜವಾಗಿಯೂ ವಿಷಾದಿಸುತ್ತೇನೆ, ಆದರೆ ಚಿಂತಿಸಬೇಡಿ, 2 ಬೈಟ್‌ಗಳು ಕರುಣೆಯಲ್ಲ. ದಯವಿಟ್ಟು ಅದನ್ನು ಹಾಗೆಯೇ ಇರಿಸಿ, ಚಿಂತಿಸಬೇಡಿ.
ಇನ್ನೊಂದು ಪ್ರಕರಣವೆಂದರೆ, ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಸಾಕಷ್ಟು ಸಾಲುಗಳು ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಸಾಕಷ್ಟು ಅನನ್ಯವಾದವುಗಳು ಇವೆ, ಮತ್ತು ಸೆಟ್ ಕೂಡ ಸಂಭಾವ್ಯವಾಗಿ ಅನಿಯಮಿತವಾಗಿರುತ್ತದೆ. ಒಂದು ವಿಶಿಷ್ಟ ಉದಾಹರಣೆಯೆಂದರೆ ಹುಡುಕಾಟ ನುಡಿಗಟ್ಟುಗಳು ಅಥವಾ URL ಗಳು. ಟೈಪೊಸ್ ಸೇರಿದಂತೆ ನುಡಿಗಟ್ಟುಗಳನ್ನು ಹುಡುಕಿ. ದಿನಕ್ಕೆ ಎಷ್ಟು ಅನನ್ಯ ಹುಡುಕಾಟ ನುಡಿಗಟ್ಟುಗಳಿವೆ ಎಂದು ನೋಡೋಣ. ಮತ್ತು ಅವರು ಎಲ್ಲಾ ಘಟನೆಗಳ ಅರ್ಧದಷ್ಟು ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಮತ್ತು ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಡೇಟಾವನ್ನು ಸಾಮಾನ್ಯಗೊಳಿಸಬೇಕು ಎಂದು ನೀವು ಭಾವಿಸಬಹುದು, ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ಎಣಿಕೆ ಮಾಡಿ ಮತ್ತು ಅದನ್ನು ಪ್ರತ್ಯೇಕ ಕೋಷ್ಟಕದಲ್ಲಿ ಇರಿಸಿ. ಆದರೆ ನೀವು ಅದನ್ನು ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ. ಈ ಸಾಲುಗಳನ್ನು ಹಾಗೆಯೇ ಇರಿಸಿ.
ಯಾವುದನ್ನೂ ಆವಿಷ್ಕರಿಸದಿರುವುದು ಉತ್ತಮ, ಏಕೆಂದರೆ ನೀವು ಅದನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂಗ್ರಹಿಸಿದರೆ, ನೀವು ಸೇರಿಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ. ಮತ್ತು ಈ ಸೇರ್ಪಡೆಯು ಅತ್ಯುತ್ತಮವಾಗಿ, ಮೆಮೊರಿಗೆ ಯಾದೃಚ್ಛಿಕ ಪ್ರವೇಶವಾಗಿದೆ, ಅದು ಇನ್ನೂ ಮೆಮೊರಿಗೆ ಸರಿಹೊಂದಿದರೆ. ಅದು ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ಸಮಸ್ಯೆಗಳು ಉಂಟಾಗುತ್ತವೆ.
ಮತ್ತು ಡೇಟಾವನ್ನು ಸ್ಥಳದಲ್ಲಿ ಸಂಗ್ರಹಿಸಿದರೆ, ನಂತರ ಅದನ್ನು ಫೈಲ್ ಸಿಸ್ಟಮ್ನಿಂದ ಅಗತ್ಯವಿರುವ ಕ್ರಮದಲ್ಲಿ ಸರಳವಾಗಿ ಓದಲಾಗುತ್ತದೆ ಮತ್ತು ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ.
ನೀವು URL ಗಳು ಅಥವಾ ಕೆಲವು ಇತರ ಸಂಕೀರ್ಣ ಉದ್ದನೆಯ ಸ್ಟ್ರಿಂಗ್ ಹೊಂದಿದ್ದರೆ, ನೀವು ಮುಂಚಿತವಾಗಿ ಕೆಲವು ರೀತಿಯ ಸಾರವನ್ನು ಲೆಕ್ಕಹಾಕಬಹುದು ಮತ್ತು ಅದನ್ನು ಪ್ರತ್ಯೇಕ ಕಾಲಮ್ನಲ್ಲಿ ಬರೆಯಬಹುದು ಎಂದು ಪರಿಗಣಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ.
URL ಗಳಿಗಾಗಿ, ಉದಾಹರಣೆಗೆ, ನೀವು ಡೊಮೇನ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂಗ್ರಹಿಸಬಹುದು. ಮತ್ತು ನಿಮಗೆ ನಿಜವಾಗಿಯೂ ಡೊಮೇನ್ ಅಗತ್ಯವಿದ್ದರೆ, ಈ ಕಾಲಮ್ ಅನ್ನು ಬಳಸಿ, ಮತ್ತು URL ಗಳು ಅಲ್ಲಿಯೇ ಇರುತ್ತವೆ ಮತ್ತು ನೀವು ಅವುಗಳನ್ನು ಸ್ಪರ್ಶಿಸುವುದಿಲ್ಲ.
ವ್ಯತ್ಯಾಸ ಏನು ಎಂದು ನೋಡೋಣ. ಕ್ಲಿಕ್‌ಹೌಸ್ ಡೊಮೇನ್ ಅನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವ ವಿಶೇಷ ಕಾರ್ಯವನ್ನು ಹೊಂದಿದೆ. ಇದು ತುಂಬಾ ವೇಗವಾಗಿದೆ, ನಾವು ಅದನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ್ದೇವೆ. ಮತ್ತು, ಪ್ರಾಮಾಣಿಕವಾಗಿ ಹೇಳಬೇಕೆಂದರೆ, ಇದು RFC ಯನ್ನು ಸಹ ಅನುಸರಿಸುವುದಿಲ್ಲ, ಆದರೆ ಅದೇನೇ ಇದ್ದರೂ ಅದು ನಮಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ ಪರಿಗಣಿಸುತ್ತದೆ.
ಮತ್ತು ಒಂದು ಸಂದರ್ಭದಲ್ಲಿ ನಾವು ಸರಳವಾಗಿ URL ಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ ಮತ್ತು ಡೊಮೇನ್ ಅನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತೇವೆ. ಅದು 166 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಮತ್ತು ನೀವು ರೆಡಿಮೇಡ್ ಡೊಮೇನ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡರೆ, ಅದು ಕೇವಲ 67 ಮಿಲಿಸೆಕೆಂಡುಗಳಾಗಿ ಹೊರಹೊಮ್ಮುತ್ತದೆ, ಅಂದರೆ ಸುಮಾರು ಮೂರು ಪಟ್ಟು ವೇಗವಾಗಿರುತ್ತದೆ. ಮತ್ತು ಇದು ವೇಗವಾಗಿದೆ ಏಕೆಂದರೆ ನಾವು ಕೆಲವು ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ಮಾಡಬೇಕಾಗಿರುವುದರಿಂದ ಅಲ್ಲ, ಆದರೆ ನಾವು ಕಡಿಮೆ ಡೇಟಾವನ್ನು ಓದುತ್ತೇವೆ.
ಅದಕ್ಕಾಗಿಯೇ ಒಂದು ವಿನಂತಿಯು ನಿಧಾನವಾಗಿರುತ್ತದೆ, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಗಿಗಾಬೈಟ್‌ಗಳ ಹೆಚ್ಚಿನ ವೇಗವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಏಕೆಂದರೆ ಅದು ಹೆಚ್ಚು ಗಿಗಾಬೈಟ್ಗಳನ್ನು ಓದುತ್ತದೆ. ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಅನಗತ್ಯ ಡೇಟಾ. ವಿನಂತಿಯು ವೇಗವಾಗಿ ರನ್ ಆಗುತ್ತಿರುವಂತೆ ತೋರುತ್ತಿದೆ, ಆದರೆ ಇದು ಪೂರ್ಣಗೊಳ್ಳಲು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಮತ್ತು ನೀವು ಡಿಸ್ಕ್ನಲ್ಲಿನ ಡೇಟಾದ ಪ್ರಮಾಣವನ್ನು ನೋಡಿದರೆ, URL 126 ಮೆಗಾಬೈಟ್ಗಳು ಮತ್ತು ಡೊಮೇನ್ ಕೇವಲ 5 ಮೆಗಾಬೈಟ್ಗಳು ಎಂದು ತಿರುಗುತ್ತದೆ. ಇದು 25 ಪಟ್ಟು ಕಡಿಮೆ ತಿರುಗುತ್ತದೆ. ಆದರೆ ಅದೇನೇ ಇದ್ದರೂ, ವಿನಂತಿಯನ್ನು ಕೇವಲ 4 ಪಟ್ಟು ವೇಗವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ. ಆದರೆ ಡೇಟಾ ಬಿಸಿಯಾಗಿರುವ ಕಾರಣ. ಮತ್ತು ಅದು ತಣ್ಣಗಾಗಿದ್ದರೆ, ಡಿಸ್ಕ್ I/O ನಿಂದಾಗಿ ಇದು ಬಹುಶಃ 25 ಪಟ್ಟು ವೇಗವಾಗಿರುತ್ತದೆ.
ಮೂಲಕ, ಡೊಮೇನ್ URL ಗಿಂತ ಎಷ್ಟು ಚಿಕ್ಕದಾಗಿದೆ ಎಂದು ನೀವು ಅಂದಾಜಿಸಿದರೆ, ಅದು ಸುಮಾರು 4 ಪಟ್ಟು ಚಿಕ್ಕದಾಗಿದೆ. ಆದರೆ ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ, ಡಿಸ್ಕ್ನಲ್ಲಿ ಡೇಟಾವು 25 ಪಟ್ಟು ಕಡಿಮೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಏಕೆ? ಸಂಕೋಚನದ ಕಾರಣದಿಂದಾಗಿ. ಮತ್ತು URL ಅನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಡೊಮೇನ್ ಅನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಲಾಗಿದೆ. ಆದರೆ ಆಗಾಗ್ಗೆ URL ಕಸದ ಗುಂಪನ್ನು ಹೊಂದಿರುತ್ತದೆ.
ಮತ್ತು, ಸಹಜವಾಗಿ, ಅಪೇಕ್ಷಿತ ಮೌಲ್ಯಗಳಿಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಅಥವಾ ಸೂಕ್ತವಾದ ಸರಿಯಾದ ಡೇಟಾ ಪ್ರಕಾರಗಳನ್ನು ಬಳಸಲು ಇದು ಪಾವತಿಸುತ್ತದೆ. ನೀವು IPv4 ನಲ್ಲಿದ್ದರೆ, UInt32* ಅನ್ನು ಸಂಗ್ರಹಿಸಿ. IPv6 ಆಗಿದ್ದರೆ, ನಂತರ FixedString(16), ಏಕೆಂದರೆ IPv6 ವಿಳಾಸವು 128 ಬಿಟ್‌ಗಳು, ಅಂದರೆ ನೇರವಾಗಿ ಬೈನರಿ ಫಾರ್ಮ್ಯಾಟ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ.
ಆದರೆ ನೀವು ಕೆಲವೊಮ್ಮೆ IPv4 ವಿಳಾಸಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಕೆಲವೊಮ್ಮೆ IPv6 ಅನ್ನು ಹೊಂದಿದ್ದರೆ ಏನು? ಹೌದು, ನೀವು ಎರಡನ್ನೂ ಸಂಗ್ರಹಿಸಬಹುದು. IPv4 ಗಾಗಿ ಒಂದು ಕಾಲಮ್, IPv6 ಗಾಗಿ ಇನ್ನೊಂದು. ಸಹಜವಾಗಿ, IPv4 ನಲ್ಲಿ IPv6 ಅನ್ನು ಪ್ರದರ್ಶಿಸಲು ಒಂದು ಆಯ್ಕೆ ಇದೆ. ಇದು ಸಹ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ನಿಮಗೆ ಆಗಾಗ್ಗೆ ವಿನಂತಿಗಳಲ್ಲಿ IPv4 ವಿಳಾಸ ಅಗತ್ಯವಿದ್ದರೆ, ಅದನ್ನು ಪ್ರತ್ಯೇಕ ಕಾಲಮ್ನಲ್ಲಿ ಹಾಕುವುದು ಒಳ್ಳೆಯದು.
* ClickHouse ಈಗ ಪ್ರತ್ಯೇಕ IPv4, IPv6 ಡೇಟಾ ಪ್ರಕಾರಗಳನ್ನು ಹೊಂದಿದೆ ಅದು ಡೇಟಾವನ್ನು ಸಂಖ್ಯೆಗಳಂತೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಆದರೆ ಅವುಗಳನ್ನು ತಂತಿಗಳಂತೆ ಅನುಕೂಲಕರವಾಗಿ ಪ್ರತಿನಿಧಿಸುತ್ತದೆ.
ಮುಂಚಿತವಾಗಿ ಡೇಟಾವನ್ನು ಪೂರ್ವಭಾವಿಯಾಗಿ ಸಂಸ್ಕರಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ ಎಂಬುದನ್ನು ಗಮನಿಸುವುದು ಸಹ ಮುಖ್ಯವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ನೀವು ಕೆಲವು ಕಚ್ಚಾ ದಾಖಲೆಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ. ಮತ್ತು ಬಹುಶಃ ನೀವು ಅವುಗಳನ್ನು ಈಗಿನಿಂದಲೇ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಇರಿಸಬಾರದು, ಆದರೂ ಏನನ್ನೂ ಮಾಡಲು ಇದು ತುಂಬಾ ಪ್ರಲೋಭನಕಾರಿಯಾಗಿದೆ ಮತ್ತು ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಆದರೆ ಇನ್ನೂ ಸಾಧ್ಯವಿರುವ ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ಕೈಗೊಳ್ಳುವುದು ಯೋಗ್ಯವಾಗಿದೆ.
ಉದಾಹರಣೆಗೆ, ಬ್ರೌಸರ್ ಆವೃತ್ತಿ. ಕೆಲವು ಹತ್ತಿರದ ಇಲಾಖೆಯಲ್ಲಿ, ನಾನು ಬೆರಳು ತೋರಿಸಲು ಬಯಸುವುದಿಲ್ಲ, ಬ್ರೌಸರ್ ಆವೃತ್ತಿಯನ್ನು ಈ ರೀತಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ, ಅಂದರೆ ಸ್ಟ್ರಿಂಗ್‌ನಂತೆ: 12.3. ತದನಂತರ, ವರದಿ ಮಾಡಲು, ಅವರು ಈ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಒಂದು ಶ್ರೇಣಿಯಾಗಿ ವಿಭಜಿಸುತ್ತಾರೆ ಮತ್ತು ನಂತರ ರಚನೆಯ ಮೊದಲ ಅಂಶಕ್ಕೆ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ಎಲ್ಲವೂ ನಿಧಾನವಾಗುತ್ತದೆ. ಅವರು ಇದನ್ನು ಏಕೆ ಮಾಡುತ್ತಾರೆ ಎಂದು ನಾನು ಕೇಳಿದೆ. ಅವರು ಅಕಾಲಿಕ ಆಪ್ಟಿಮೈಸೇಶನ್ ಅನ್ನು ಇಷ್ಟಪಡುವುದಿಲ್ಲ ಎಂದು ಅವರು ನನಗೆ ಹೇಳಿದರು. ಮತ್ತು ನಾನು ಅಕಾಲಿಕ ನಿರಾಶಾವಾದವನ್ನು ಇಷ್ಟಪಡುವುದಿಲ್ಲ.
ಆದ್ದರಿಂದ ಈ ಸಂದರ್ಭದಲ್ಲಿ 4 ಕಾಲಮ್ಗಳಾಗಿ ವಿಂಗಡಿಸಲು ಹೆಚ್ಚು ಸರಿಯಾಗಿರುತ್ತದೆ. ಇಲ್ಲಿ ಭಯಪಡಬೇಡಿ, ಏಕೆಂದರೆ ಇದು ಕ್ಲಿಕ್‌ಹೌಸ್ ಆಗಿದೆ. ClickHouse ಒಂದು ಸ್ತಂಭಾಕಾರದ ಡೇಟಾಬೇಸ್ ಆಗಿದೆ. ಮತ್ತು ಹೆಚ್ಚು ಅಚ್ಚುಕಟ್ಟಾಗಿ ಕಡಿಮೆ ಕಾಲಮ್ಗಳು, ಉತ್ತಮ. 5 ಬ್ರೌಸರ್ ಆವೃತ್ತಿಗಳು ಇರುತ್ತವೆ, 5 ಕಾಲಮ್‌ಗಳನ್ನು ಮಾಡಿ. ಇದು ಚೆನ್ನಾಗಿದೆ.
ಈಗ ನೀವು ತುಂಬಾ ಉದ್ದವಾದ ತಂತಿಗಳು, ಬಹಳ ಉದ್ದವಾದ ಸರಣಿಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಏನು ಮಾಡಬೇಕೆಂದು ನೋಡೋಣ. ಅವುಗಳನ್ನು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಬದಲಿಗೆ, ನೀವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಮಾತ್ರ ಸಂಗ್ರಹಿಸಬಹುದು. ಮತ್ತು ಈ ಉದ್ದವಾದ ಸಾಲುಗಳನ್ನು ಬೇರೆ ಯಾವುದಾದರೂ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಇರಿಸಿ.
ಉದಾಹರಣೆಗೆ, ನಮ್ಮ ಅನಾಲಿಟಿಕ್ಸ್ ಸೇವೆಗಳಲ್ಲಿ ಕೆಲವು ಈವೆಂಟ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಹೊಂದಿದೆ. ಮತ್ತು ಈವೆಂಟ್‌ಗಳಿಗೆ ಹಲವು ಪ್ಯಾರಾಮೀಟರ್‌ಗಳಿದ್ದರೆ, ನಾವು ಮೊದಲ 512 ಅನ್ನು ಉಳಿಸುತ್ತೇವೆ ಏಕೆಂದರೆ 512 ಕರುಣೆ ಅಲ್ಲ.
ಮತ್ತು ನಿಮ್ಮ ಡೇಟಾ ಪ್ರಕಾರಗಳನ್ನು ನೀವು ನಿರ್ಧರಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ನೀವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಡೇಟಾವನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಬಹುದು, ಆದರೆ ಲಾಗ್ ಪ್ರಕಾರದ ತಾತ್ಕಾಲಿಕ ಕೋಷ್ಟಕದಲ್ಲಿ, ತಾತ್ಕಾಲಿಕ ಡೇಟಾಕ್ಕಾಗಿ ವಿಶೇಷವಾಗಿದೆ. ಇದರ ನಂತರ, ನೀವು ಅಲ್ಲಿ ಯಾವ ಮೌಲ್ಯಗಳ ವಿತರಣೆಯನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಸಾಮಾನ್ಯವಾಗಿ ಏನಿದೆ ಎಂಬುದನ್ನು ನೀವು ವಿಶ್ಲೇಷಿಸಬಹುದು ಮತ್ತು ಸರಿಯಾದ ಪ್ರಕಾರಗಳನ್ನು ರಚಿಸಬಹುದು.
*ClickHouse ಈಗ ಡೇಟಾ ಪ್ರಕಾರವನ್ನು ಹೊಂದಿದೆ ಕಡಿಮೆ ಪ್ರಯತ್ನದಲ್ಲಿ ತಂತಿಗಳನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಸಂಗ್ರಹಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ.
ಈಗ ಮತ್ತೊಂದು ಆಸಕ್ತಿದಾಯಕ ಪ್ರಕರಣವನ್ನು ನೋಡೋಣ. ಕೆಲವೊಮ್ಮೆ ಜನರು ವಿಚಿತ್ರವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ. ನಾನು ಒಳಗೆ ಬಂದು ಇದನ್ನು ನೋಡುತ್ತೇನೆ. ಮತ್ತು MySQL ಆವೃತ್ತಿ 3.23 ಅನ್ನು ಹೊಂದಿಸುವಲ್ಲಿ ವ್ಯಾಪಕ ಅನುಭವವನ್ನು ಹೊಂದಿರುವ ಕೆಲವು ಅನುಭವಿ, ಸ್ಮಾರ್ಟ್ ನಿರ್ವಾಹಕರು ಇದನ್ನು ಮಾಡಿದ್ದಾರೆ ಎಂದು ತಕ್ಷಣವೇ ತೋರುತ್ತದೆ.
ಇಲ್ಲಿ ನಾವು ಸಾವಿರ ಕೋಷ್ಟಕಗಳನ್ನು ನೋಡುತ್ತೇವೆ, ಪ್ರತಿಯೊಂದೂ ಸಾವಿರದಿಂದ ಯಾರಿಗೆ ಏನು ಗೊತ್ತು ಎಂದು ಭಾಗಿಸುವ ಉಳಿದ ಭಾಗವನ್ನು ದಾಖಲಿಸುತ್ತದೆ.
ತಾತ್ವಿಕವಾಗಿ, ಈ ಅನುಭವದ ಮೂಲಕ ಪಡೆಯಬಹುದಾದ ಸಂಕಟದ ತಿಳುವಳಿಕೆ ಸೇರಿದಂತೆ ಇತರ ಜನರ ಅನುಭವವನ್ನು ನಾನು ಗೌರವಿಸುತ್ತೇನೆ.
ಮತ್ತು ಕಾರಣಗಳು ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಸ್ಪಷ್ಟವಾಗಿವೆ. ಇವುಗಳು ಹಳೆಯ ಸ್ಟೀರಿಯೊಟೈಪ್‌ಗಳಾಗಿವೆ, ಅದು ಇತರ ವ್ಯವಸ್ಥೆಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಸಂಗ್ರಹವಾಗಬಹುದು. ಉದಾಹರಣೆಗೆ, MyISAM ಕೋಷ್ಟಕಗಳು ಕ್ಲಸ್ಟರ್ಡ್ ಪ್ರಾಥಮಿಕ ಕೀಲಿಯನ್ನು ಹೊಂದಿಲ್ಲ. ಮತ್ತು ಡೇಟಾವನ್ನು ವಿಭಜಿಸುವ ಈ ವಿಧಾನವು ಅದೇ ಕಾರ್ಯವನ್ನು ಪಡೆಯಲು ಹತಾಶ ಪ್ರಯತ್ನವಾಗಿರಬಹುದು.
ಮತ್ತೊಂದು ಕಾರಣವೆಂದರೆ ದೊಡ್ಡ ಟೇಬಲ್‌ಗಳಲ್ಲಿ ಯಾವುದೇ ಬದಲಾವಣೆಯ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮಾಡುವುದು ಕಷ್ಟ. ಎಲ್ಲವನ್ನೂ ನಿರ್ಬಂಧಿಸಲಾಗುವುದು. MySQL ನ ಆಧುನಿಕ ಆವೃತ್ತಿಗಳಲ್ಲಿ ಈ ಸಮಸ್ಯೆಯು ಇನ್ನು ಮುಂದೆ ಅಷ್ಟು ಗಂಭೀರವಾಗಿಲ್ಲ.
ಅಥವಾ, ಉದಾಹರಣೆಗೆ, ಮೈಕ್ರೋಶಾರ್ಡ್, ಆದರೆ ನಂತರ ಹೆಚ್ಚು.
ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಇದನ್ನು ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ, ಮೊದಲನೆಯದಾಗಿ, ಪ್ರಾಥಮಿಕ ಕೀಲಿಯನ್ನು ಕ್ಲಸ್ಟರ್ ಮಾಡಲಾಗಿದೆ, ಡೇಟಾವನ್ನು ಪ್ರಾಥಮಿಕ ಕೀಲಿಯಿಂದ ಆದೇಶಿಸಲಾಗುತ್ತದೆ.
ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಜನರು ನನ್ನನ್ನು ಕೇಳುತ್ತಾರೆ: "ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿನ ಶ್ರೇಣಿಯ ಪ್ರಶ್ನೆಗಳ ಕಾರ್ಯಕ್ಷಮತೆ ಟೇಬಲ್ ಗಾತ್ರವನ್ನು ಅವಲಂಬಿಸಿ ಹೇಗೆ ಬದಲಾಗುತ್ತದೆ?" ಅದು ಬದಲಾಗುವುದಿಲ್ಲ ಎಂದು ನಾನು ಹೇಳುತ್ತೇನೆ. ಉದಾಹರಣೆಗೆ, ನೀವು ಒಂದು ಬಿಲಿಯನ್ ಸಾಲುಗಳನ್ನು ಹೊಂದಿರುವ ಟೇಬಲ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ನೀವು ಒಂದು ಮಿಲಿಯನ್ ಸಾಲುಗಳ ಶ್ರೇಣಿಯನ್ನು ಓದಿದ್ದೀರಿ. ಎಲ್ಲವು ಚೆನ್ನಾಗಿದೆ. ಒಂದು ಕೋಷ್ಟಕದಲ್ಲಿ ಟ್ರಿಲಿಯನ್ ಸಾಲುಗಳಿದ್ದರೆ ಮತ್ತು ನೀವು ಒಂದು ಮಿಲಿಯನ್ ಸಾಲುಗಳನ್ನು ಓದಿದರೆ, ಅದು ಬಹುತೇಕ ಒಂದೇ ಆಗಿರುತ್ತದೆ.
ಮತ್ತು, ಎರಡನೆಯದಾಗಿ, ಹಸ್ತಚಾಲಿತ ವಿಭಾಗಗಳಂತಹ ಎಲ್ಲಾ ರೀತಿಯ ವಿಷಯಗಳು ಅಗತ್ಯವಿಲ್ಲ. ನೀವು ಒಳಗೆ ಹೋಗಿ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಏನಿದೆ ಎಂದು ನೋಡಿದರೆ, ಟೇಬಲ್ ಸಾಕಷ್ಟು ದೊಡ್ಡ ವ್ಯವಹಾರವಾಗಿದೆ ಎಂದು ನೀವು ನೋಡುತ್ತೀರಿ. ಮತ್ತು ಒಳಗೆ ವಿಭಾಗಗಳಂತಹವುಗಳಿವೆ. ಅಂದರೆ, ಕ್ಲಿಕ್‌ಹೌಸ್ ನಿಮಗಾಗಿ ಎಲ್ಲವನ್ನೂ ಮಾಡುತ್ತದೆ ಮತ್ತು ನೀವು ಬಳಲುತ್ತಬೇಕಾಗಿಲ್ಲ.
ಆಡ್/ಡ್ರಾಪ್ ಕಾಲಮ್ ಅನ್ನು ಬದಲಾಯಿಸಿದರೆ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಆಲ್ಟರ್ ಉಚಿತವಾಗಿದೆ.
ಮತ್ತು ನೀವು ಸಣ್ಣ ಕೋಷ್ಟಕಗಳನ್ನು ಮಾಡಬಾರದು, ಏಕೆಂದರೆ ನೀವು ಕೋಷ್ಟಕದಲ್ಲಿ 10 ಸಾಲುಗಳು ಅಥವಾ 10 ಸಾಲುಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದು ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ. ಕ್ಲಿಕ್‌ಹೌಸ್ ಎನ್ನುವುದು ಥ್ರೋಪುಟ್ ಅನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡುವ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ, ಲೇಟೆನ್ಸಿ ಅಲ್ಲ, ಆದ್ದರಿಂದ 000 ಸಾಲುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ.
ಒಂದು ದೊಡ್ಡ ಟೇಬಲ್ ಅನ್ನು ಬಳಸುವುದು ಸರಿಯಾಗಿದೆ. ಹಳೆಯ ಸ್ಟೀರಿಯೊಟೈಪ್‌ಗಳನ್ನು ತೊಡೆದುಹಾಕಿ, ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿರುತ್ತದೆ.
ಮತ್ತು ಬೋನಸ್ ಆಗಿ, ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಯಲ್ಲಿ ನಾವು ಈಗ ಪ್ರತ್ಯೇಕ ವಿಭಾಗಗಳಲ್ಲಿ ಎಲ್ಲಾ ರೀತಿಯ ನಿರ್ವಹಣಾ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಅನಿಯಂತ್ರಿತ ವಿಭಜನಾ ಕೀಲಿಯನ್ನು ರಚಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ಉದಾಹರಣೆಗೆ, ನಿಮಗೆ ಅನೇಕ ಸಣ್ಣ ಕೋಷ್ಟಕಗಳು ಬೇಕಾಗುತ್ತವೆ, ಉದಾಹರಣೆಗೆ, ಕೆಲವು ಮಧ್ಯಂತರ ಡೇಟಾವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಅಗತ್ಯವಿರುವಾಗ, ನೀವು ಭಾಗಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ ಮತ್ತು ಅಂತಿಮ ಕೋಷ್ಟಕಕ್ಕೆ ಬರೆಯುವ ಮೊದಲು ನೀವು ಅವುಗಳ ಮೇಲೆ ರೂಪಾಂತರವನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಅದ್ಭುತವಾದ ಟೇಬಲ್ ಎಂಜಿನ್ ಇದೆ - ಸ್ಟ್ರೈಪ್ಲಾಗ್. ಇದು ಟೈನಿಲಾಗ್‌ನಂತೆಯೇ ಇದೆ, ಮಾತ್ರ ಉತ್ತಮವಾಗಿದೆ.
* ಈಗ ಕ್ಲಿಕ್‌ಹೌಸ್ ಕೂಡ ಹೊಂದಿದೆ .
ಮತ್ತೊಂದು ಆಂಟಿಪ್ಯಾಟರ್ನ್ ಮೈಕ್ರೋಶಾರ್ಡ್ ಆಗಿದೆ. ಉದಾಹರಣೆಗೆ, ನೀವು ಡೇಟಾವನ್ನು ಚೂರು ಮಾಡಬೇಕಾಗಿದೆ ಮತ್ತು ನೀವು 5 ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ನಾಳೆ 6 ಸರ್ವರ್‌ಗಳು ಇರುತ್ತವೆ. ಮತ್ತು ಈ ಡೇಟಾವನ್ನು ಮರುಸಮತೋಲನ ಮಾಡುವುದು ಹೇಗೆ ಎಂದು ನೀವು ಯೋಚಿಸುತ್ತೀರಿ. ಮತ್ತು ಬದಲಾಗಿ ನೀವು 5 ಚೂರುಗಳಾಗಿ ಅಲ್ಲ, ಆದರೆ 1 ಚೂರುಗಳಾಗಿ ಒಡೆಯುತ್ತೀರಿ. ತದನಂತರ ನೀವು ಈ ಪ್ರತಿಯೊಂದು ಮೈಕ್ರೋಶಾರ್ಡ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಸರ್ವರ್‌ಗೆ ಮ್ಯಾಪ್ ಮಾಡಿ. ಮತ್ತು ನೀವು ಪಡೆಯುತ್ತೀರಿ, ಉದಾಹರಣೆಗೆ, ಒಂದು ಸರ್ವರ್‌ನಲ್ಲಿ 000 ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗಳು, ಉದಾಹರಣೆಗೆ. ಪ್ರತ್ಯೇಕ ಪೋರ್ಟ್‌ಗಳು ಅಥವಾ ಪ್ರತ್ಯೇಕ ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ ಪ್ರತ್ಯೇಕ ನಿದರ್ಶನಗಳು.
ಆದರೆ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಇದು ತುಂಬಾ ಉತ್ತಮವಾಗಿಲ್ಲ. ಏಕೆಂದರೆ ಒಂದು ಕ್ಲಿಕ್‌ಹೌಸ್ ನಿದರ್ಶನವು ಒಂದು ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ ಸರ್ವರ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಅಂದರೆ, ನೀವು ಕೆಲವು ರೀತಿಯ ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ಇದು 56 ಪ್ರೊಸೆಸರ್ ಕೋರ್ಗಳನ್ನು ಹೊಂದಿದೆ. ನೀವು ಒಂದು ಸೆಕೆಂಡ್ ತೆಗೆದುಕೊಳ್ಳುವ ಪ್ರಶ್ನೆಯನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತಿದ್ದೀರಿ ಮತ್ತು ಅದು 56 ಕೋರ್ಗಳನ್ನು ಬಳಸುತ್ತದೆ. ಮತ್ತು ನೀವು ಒಂದು ಸರ್ವರ್‌ನಲ್ಲಿ 200 ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗಳನ್ನು ಇರಿಸಿದರೆ, 10 ಥ್ರೆಡ್‌ಗಳು ಪ್ರಾರಂಭವಾಗುತ್ತವೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಎಲ್ಲವೂ ತುಂಬಾ ಕೆಟ್ಟದಾಗಿರುತ್ತದೆ.
ಇನ್ನೊಂದು ಕಾರಣವೆಂದರೆ ಈ ನಿದರ್ಶನಗಳಲ್ಲಿ ಕೆಲಸದ ವಿತರಣೆಯು ಅಸಮವಾಗಿರುತ್ತದೆ. ಕೆಲವರು ಮೊದಲೇ ಮುಗಿಸುತ್ತಾರೆ, ಕೆಲವರು ನಂತರ ಮುಗಿಸುತ್ತಾರೆ. ಇದೆಲ್ಲವೂ ಒಂದು ನಿದರ್ಶನದಲ್ಲಿ ಸಂಭವಿಸಿದಲ್ಲಿ, ಥ್ರೆಡ್‌ಗಳ ನಡುವೆ ಡೇಟಾವನ್ನು ಸರಿಯಾಗಿ ವಿತರಿಸುವುದು ಹೇಗೆ ಎಂದು ಕ್ಲಿಕ್‌ಹೌಸ್ ಸ್ವತಃ ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ.
ಮತ್ತು ಇನ್ನೊಂದು ಕಾರಣವೆಂದರೆ ನೀವು TCP ಮೂಲಕ ಇಂಟರ್ಪ್ರೊಸೆಸರ್ ಸಂವಹನವನ್ನು ಹೊಂದಿರುತ್ತೀರಿ. ದತ್ತಾಂಶವನ್ನು ಧಾರಾವಾಹಿ ಮಾಡಬೇಕು, ಡೀರಿಯಲೈಸ್ ಮಾಡಬೇಕು ಮತ್ತು ಇದು ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಮೈಕ್ರೋಶಾರ್ಡ್‌ಗಳು. ಇದು ಸರಳವಾಗಿ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.
ಮತ್ತೊಂದು ಆಂಟಿಪ್ಯಾಟರ್ನ್, ಆದರೂ ಇದನ್ನು ಆಂಟಿಪ್ಯಾಟರ್ನ್ ಎಂದು ಕರೆಯಲಾಗುವುದಿಲ್ಲ. ಇದು ಒಂದು ದೊಡ್ಡ ಮೊತ್ತದ ಪೂರ್ವ-ಸಂಗ್ರಹವಾಗಿದೆ.
ಸಾಮಾನ್ಯವಾಗಿ, ಪೂರ್ವ-ಸಂಗ್ರಹವು ಒಳ್ಳೆಯದು. ನೀವು ಒಂದು ಬಿಲಿಯನ್ ಸಾಲುಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ, ನೀವು ಅದನ್ನು ಒಟ್ಟುಗೂಡಿಸಿದ್ದೀರಿ ಮತ್ತು ಅದು 1 ಸಾಲುಗಳಾಗಿ ಮಾರ್ಪಟ್ಟಿದೆ ಮತ್ತು ಈಗ ಪ್ರಶ್ನೆಯನ್ನು ತಕ್ಷಣವೇ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ. ಎಲ್ಲವೂ ಅದ್ಭುತವಾಗಿದೆ. ನೀವು ಇದನ್ನು ಮಾಡಬಹುದು. ಮತ್ತು ಇದಕ್ಕಾಗಿ, ಕ್ಲಿಕ್‌ಹೌಸ್ ಕೂಡ ವಿಶೇಷ ಟೇಬಲ್ ಪ್ರಕಾರವನ್ನು ಹೊಂದಿದೆ, ಅಗ್ರಿಗೇಟಿಂಗ್ ಮರ್ಜ್‌ಟ್ರೀ, ಇದು ಡೇಟಾವನ್ನು ಸೇರಿಸಿದಾಗ ಹೆಚ್ಚುತ್ತಿರುವ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.
ಆದರೆ ನಾವು ಈ ರೀತಿಯ ಡೇಟಾವನ್ನು ಒಟ್ಟುಗೂಡಿಸುತ್ತೇವೆ ಮತ್ತು ಈ ರೀತಿಯ ಡೇಟಾವನ್ನು ಒಟ್ಟುಗೂಡಿಸುತ್ತೇವೆ ಎಂದು ನೀವು ಯೋಚಿಸುವ ಸಂದರ್ಭಗಳಿವೆ. ಮತ್ತು ಕೆಲವು ನೆರೆಯ ಇಲಾಖೆಗಳಲ್ಲಿ, ಯಾವುದನ್ನು ಹೇಳಲು ನಾನು ಬಯಸುವುದಿಲ್ಲ, ಅವರು ಪ್ರಾಥಮಿಕ ಕೀಲಿಯಿಂದ ಸಾರಾಂಶ ಮಾಡಲು ಸಮ್ಮಿಂಗ್‌ಮರ್ಜ್‌ಟ್ರೀ ಕೋಷ್ಟಕಗಳನ್ನು ಬಳಸುತ್ತಾರೆ ಮತ್ತು ಸುಮಾರು 20 ಕಾಲಮ್‌ಗಳನ್ನು ಪ್ರಾಥಮಿಕ ಕೀಲಿಯಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಒಂದು ವೇಳೆ, ನಾನು ರಹಸ್ಯಕ್ಕಾಗಿ ಕೆಲವು ಕಾಲಮ್‌ಗಳ ಹೆಸರನ್ನು ಬದಲಾಯಿಸಿದ್ದೇನೆ, ಆದರೆ ಅದು ಬಹುಮಟ್ಟಿಗೆ.
ಮತ್ತು ಅಂತಹ ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸುತ್ತವೆ. ಮೊದಲನೆಯದಾಗಿ, ನಿಮ್ಮ ಡೇಟಾ ಪರಿಮಾಣವು ಹೆಚ್ಚು ಕಡಿಮೆಯಾಗುವುದಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಇದು ಮೂರು ಪಟ್ಟು ಕಡಿಮೆಯಾಗುತ್ತದೆ. ನಿಮ್ಮ ಡೇಟಾವನ್ನು ಒಟ್ಟುಗೂಡಿಸದಿದ್ದರೆ ಉಂಟಾಗುವ ಅನಿಯಮಿತ ವಿಶ್ಲೇಷಣಾ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಪಡೆಯಲು ಮೂರು ಬಾರಿ ಉತ್ತಮ ಬೆಲೆಯಾಗಿದೆ. ಡೇಟಾವನ್ನು ಒಟ್ಟುಗೂಡಿಸಿದರೆ, ವಿಶ್ಲೇಷಣೆಯ ಬದಲಿಗೆ ನೀವು ಕರುಣಾಜನಕ ಅಂಕಿಅಂಶಗಳನ್ನು ಮಾತ್ರ ಪಡೆಯುತ್ತೀರಿ.
ಮತ್ತು ಅದರ ವಿಶೇಷತೆ ಏನು? ವಾಸ್ತವವೆಂದರೆ ಪಕ್ಕದ ಇಲಾಖೆಯ ಈ ಜನರು ಕೆಲವೊಮ್ಮೆ ಹೋಗಿ ಪ್ರಾಥಮಿಕ ಕೀಗೆ ಮತ್ತೊಂದು ಕಾಲಮ್ ಸೇರಿಸಲು ಕೇಳುತ್ತಾರೆ. ಅಂದರೆ, ನಾವು ಈ ರೀತಿಯ ಡೇಟಾವನ್ನು ಒಟ್ಟುಗೂಡಿಸಿದ್ದೇವೆ, ಆದರೆ ಈಗ ನಾವು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಬಯಸುತ್ತೇವೆ. ಆದರೆ ಕ್ಲಿಕ್‌ಹೌಸ್ ಆಲ್ಟರ್ ಪ್ರಾಥಮಿಕ ಕೀಲಿಯನ್ನು ಹೊಂದಿಲ್ಲ. ಆದ್ದರಿಂದ, ನಾವು ಕೆಲವು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು C++ ನಲ್ಲಿ ಬರೆಯಬೇಕಾಗಿದೆ. ಮತ್ತು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು C++ ನಲ್ಲಿದ್ದರೂ ನನಗೆ ಇಷ್ಟವಿಲ್ಲ.
ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಯಾವುದಕ್ಕಾಗಿ ರಚಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡಿದರೆ, ಒಟ್ಟುಗೂಡಿಸದ ಡೇಟಾವು ನಿಖರವಾಗಿ ಅದು ಹುಟ್ಟಿದ ಸನ್ನಿವೇಶವಾಗಿದೆ. ನೀವು ಒಟ್ಟುಗೂಡಿಸದ ಡೇಟಾಕ್ಕಾಗಿ ClickHouse ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಸರಿಯಾಗಿ ಮಾಡುತ್ತಿದ್ದೀರಿ. ನೀವು ಒಟ್ಟುಗೂಡಿಸಿದರೆ, ಇದು ಕೆಲವೊಮ್ಮೆ ಕ್ಷಮೆಯಾಗುತ್ತದೆ.
ಮತ್ತೊಂದು ಆಸಕ್ತಿದಾಯಕ ಪ್ರಕರಣವೆಂದರೆ ಅನಂತ ಲೂಪ್‌ನಲ್ಲಿರುವ ಪ್ರಶ್ನೆಗಳು. ಕೆಲವೊಮ್ಮೆ ನಾನು ಕೆಲವು ಪ್ರೊಡಕ್ಷನ್ ಸರ್ವರ್‌ಗೆ ಹೋಗುತ್ತೇನೆ ಮತ್ತು ಅಲ್ಲಿ ಪ್ರದರ್ಶನ ಪ್ರಕ್ರಿಯೆ ಪಟ್ಟಿಯನ್ನು ನೋಡುತ್ತೇನೆ. ಮತ್ತು ಪ್ರತಿ ಬಾರಿಯೂ ಭಯಾನಕ ಏನಾದರೂ ನಡೆಯುತ್ತಿದೆ ಎಂದು ನಾನು ಕಂಡುಕೊಂಡೆ.
ಉದಾಹರಣೆಗೆ, ಈ ರೀತಿ. ಒಂದು ವಿನಂತಿಯಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ಮಾಡಬಹುದೆಂದು ತಕ್ಷಣವೇ ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ. ಕೇವಲ url ಮತ್ತು ಪಟ್ಟಿಯನ್ನು ಬರೆಯಿರಿ.
ಅಂತ್ಯವಿಲ್ಲದ ಲೂಪ್ನಲ್ಲಿ ಅಂತಹ ಅನೇಕ ಪ್ರಶ್ನೆಗಳು ಏಕೆ ಕೆಟ್ಟದಾಗಿವೆ? ಸೂಚ್ಯಂಕವನ್ನು ಬಳಸದಿದ್ದರೆ, ಅದೇ ಡೇಟಾದ ಮೇಲೆ ನೀವು ಅನೇಕ ಪಾಸ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತೀರಿ. ಆದರೆ ಸೂಚ್ಯಂಕವನ್ನು ಬಳಸಿದರೆ, ಉದಾಹರಣೆಗೆ, ನೀವು ru ಗಾಗಿ ಪ್ರಾಥಮಿಕ ಕೀಲಿಯನ್ನು ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ನೀವು url = ಅಲ್ಲಿ ಏನನ್ನಾದರೂ ಬರೆಯುತ್ತೀರಿ. ಮತ್ತು ಟೇಬಲ್‌ನಿಂದ ಕೇವಲ ಒಂದು URL ಅನ್ನು ಓದಿದರೆ, ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿರುತ್ತದೆ ಎಂದು ನೀವು ಭಾವಿಸುತ್ತೀರಿ. ಆದರೆ ವಾಸ್ತವವಾಗಿ ಇಲ್ಲ. ಏಕೆಂದರೆ ಕ್ಲಿಕ್‌ಹೌಸ್ ಬ್ಯಾಚ್‌ಗಳಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ಮಾಡುತ್ತದೆ.
ಅವರು ನಿರ್ದಿಷ್ಟ ಶ್ರೇಣಿಯ ಡೇಟಾವನ್ನು ಓದಬೇಕಾದಾಗ, ಅವರು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಓದುತ್ತಾರೆ, ಏಕೆಂದರೆ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿನ ಸೂಚ್ಯಂಕವು ವಿರಳವಾಗಿರುತ್ತದೆ. ಈ ಸೂಚ್ಯಂಕವು ಕೋಷ್ಟಕದಲ್ಲಿ ಒಂದು ಪ್ರತ್ಯೇಕ ಸಾಲನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಿಮಗೆ ಅನುಮತಿಸುವುದಿಲ್ಲ, ಕೆಲವು ರೀತಿಯ ಶ್ರೇಣಿಯನ್ನು ಮಾತ್ರ. ಮತ್ತು ಡೇಟಾವನ್ನು ಬ್ಲಾಕ್ಗಳಲ್ಲಿ ಸಂಕುಚಿತಗೊಳಿಸಲಾಗುತ್ತದೆ. ಒಂದು ಸಾಲನ್ನು ಓದಲು, ನೀವು ಸಂಪೂರ್ಣ ಬ್ಲಾಕ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಬಿಚ್ಚಬೇಕು. ಮತ್ತು ನೀವು ಪ್ರಶ್ನೆಗಳ ಗುಂಪನ್ನು ಮಾಡುತ್ತಿದ್ದರೆ, ನೀವು ಸಾಕಷ್ಟು ಅತಿಕ್ರಮಣವನ್ನು ಹೊಂದಿರುತ್ತೀರಿ ಮತ್ತು ನೀವು ಮತ್ತೆ ಮತ್ತೆ ಮಾಡಲು ಸಾಕಷ್ಟು ಕೆಲಸವನ್ನು ಹೊಂದಿರುತ್ತೀರಿ.
ಮತ್ತು ಬೋನಸ್ ಆಗಿ, ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ನೀವು ಮೆಗಾಬೈಟ್ಗಳು ಮತ್ತು ನೂರಾರು ಮೆಗಾಬೈಟ್‌ಗಳನ್ನು ಸಹ IN ವಿಭಾಗಕ್ಕೆ ವರ್ಗಾಯಿಸಲು ಭಯಪಡಬಾರದು ಎಂದು ನೀವು ಗಮನಿಸಬಹುದು. MySQL ನಲ್ಲಿ ನಾವು ಮೌಲ್ಯಗಳ ಗುಂಪನ್ನು IN ವಿಭಾಗಕ್ಕೆ ವರ್ಗಾಯಿಸಿದರೆ, ಉದಾಹರಣೆಗೆ, ನಾವು 100 ಮೆಗಾಬೈಟ್‌ಗಳ ಕೆಲವು ಸಂಖ್ಯೆಗಳನ್ನು ವರ್ಗಾಯಿಸುತ್ತೇವೆ ಎಂದು ನಮ್ಮ ಅಭ್ಯಾಸದಿಂದ ನಾನು ನೆನಪಿಸಿಕೊಳ್ಳುತ್ತೇನೆ, ನಂತರ MySQL 10 ಗಿಗಾಬೈಟ್ ಮೆಮೊರಿಯನ್ನು ತಿನ್ನುತ್ತದೆ ಮತ್ತು ಅದಕ್ಕೆ ಬೇರೆ ಏನೂ ಆಗುವುದಿಲ್ಲ, ಎಲ್ಲವೂ ಕಳಪೆಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ.
ಮತ್ತು ಎರಡನೆಯದು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ, ನಿಮ್ಮ ಪ್ರಶ್ನೆಗಳು ಸೂಚ್ಯಂಕವನ್ನು ಬಳಸಿದರೆ, ಅದು ಯಾವಾಗಲೂ ಪೂರ್ಣ ಸ್ಕ್ಯಾನ್‌ಗಿಂತ ನಿಧಾನವಾಗಿರುವುದಿಲ್ಲ, ಅಂದರೆ ನೀವು ಬಹುತೇಕ ಸಂಪೂರ್ಣ ಟೇಬಲ್ ಅನ್ನು ಓದಬೇಕಾದರೆ, ಅದು ಅನುಕ್ರಮವಾಗಿ ಹೋಗುತ್ತದೆ ಮತ್ತು ಸಂಪೂರ್ಣ ಟೇಬಲ್ ಅನ್ನು ಓದುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಅವನು ಅದನ್ನು ತನ್ನದೇ ಆದ ಮೇಲೆ ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತಾನೆ.
ಆದರೆ ಅದೇನೇ ಇದ್ದರೂ ಕೆಲವು ತೊಂದರೆಗಳಿವೆ. ಉದಾಹರಣೆಗೆ, ಉಪಪ್ರಶ್ನೆಯೊಂದಿಗೆ IN ಸೂಚ್ಯಂಕವನ್ನು ಬಳಸುವುದಿಲ್ಲ. ಆದರೆ ಇದು ನಮ್ಮ ಸಮಸ್ಯೆಯಾಗಿದೆ ಮತ್ತು ನಾವು ಅದನ್ನು ಸರಿಪಡಿಸಬೇಕಾಗಿದೆ. ಇಲ್ಲಿ ಮೂಲಭೂತವಾದ ಏನೂ ಇಲ್ಲ. ನಾವು ಅದನ್ನು ಸರಿಪಡಿಸುತ್ತೇವೆ*.
ಮತ್ತು ಇನ್ನೊಂದು ಕುತೂಹಲಕಾರಿ ವಿಷಯವೆಂದರೆ ನೀವು ಬಹಳ ದೀರ್ಘವಾದ ವಿನಂತಿಯನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ವಿತರಿಸಿದ ವಿನಂತಿಯ ಪ್ರಕ್ರಿಯೆಯು ಪ್ರಗತಿಯಲ್ಲಿದ್ದರೆ, ಈ ದೀರ್ಘವಾದ ವಿನಂತಿಯನ್ನು ಸಂಕುಚಿತಗೊಳಿಸದೆ ಪ್ರತಿ ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, 100 ಮೆಗಾಬೈಟ್ಗಳು ಮತ್ತು 500 ಸರ್ವರ್‌ಗಳು. ಮತ್ತು, ಅದರ ಪ್ರಕಾರ, ನೀವು ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ 50 ಗಿಗಾಬೈಟ್ಗಳನ್ನು ವರ್ಗಾಯಿಸುತ್ತೀರಿ. ಇದು ರವಾನೆಯಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಎಲ್ಲವೂ ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ.
* ಈಗಾಗಲೇ ಬಳಸಲಾಗುತ್ತಿದೆ; ಭರವಸೆಯಂತೆ ಎಲ್ಲವನ್ನೂ ಸರಿಪಡಿಸಲಾಯಿತು.
ಮತ್ತು API ನಿಂದ ವಿನಂತಿಗಳು ಬಂದಾಗ ಸಾಕಷ್ಟು ಸಾಮಾನ್ಯವಾದ ಪ್ರಕರಣವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ನೀವು ಕೆಲವು ರೀತಿಯ ನಿಮ್ಮ ಸ್ವಂತ ಸೇವೆಯನ್ನು ರಚಿಸಿದ್ದೀರಿ. ಮತ್ತು ಯಾರಿಗಾದರೂ ನಿಮ್ಮ ಸೇವೆ ಅಗತ್ಯವಿದ್ದರೆ, ನೀವು API ಅನ್ನು ತೆರೆಯುತ್ತೀರಿ ಮತ್ತು ಅಕ್ಷರಶಃ ಎರಡು ದಿನಗಳ ನಂತರ ಗ್ರಹಿಸಲಾಗದ ಏನಾದರೂ ನಡೆಯುತ್ತಿದೆ ಎಂದು ನೀವು ನೋಡುತ್ತೀರಿ. ಎಲ್ಲವೂ ಓವರ್‌ಲೋಡ್ ಆಗಿದೆ ಮತ್ತು ಕೆಲವು ಭಯಾನಕ ವಿನಂತಿಗಳು ಬರುತ್ತಿವೆ, ಅದು ಎಂದಿಗೂ ಸಂಭವಿಸಬಾರದು.
ಮತ್ತು ಒಂದೇ ಒಂದು ಪರಿಹಾರವಿದೆ. ನೀವು API ಅನ್ನು ತೆರೆದಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಕತ್ತರಿಸಬೇಕಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಕೆಲವು ರೀತಿಯ ಕೋಟಾಗಳನ್ನು ಪರಿಚಯಿಸಿ. ಬೇರೆ ಯಾವುದೇ ಸಾಮಾನ್ಯ ಆಯ್ಕೆಗಳಿಲ್ಲ. ಇಲ್ಲದಿದ್ದರೆ, ಅವರು ತಕ್ಷಣ ಸ್ಕ್ರಿಪ್ಟ್ ಬರೆಯುತ್ತಾರೆ ಮತ್ತು ಸಮಸ್ಯೆಗಳಿರುತ್ತವೆ.
ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್ ವಿಶೇಷ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊಂದಿದೆ - ಕೋಟಾ ಲೆಕ್ಕಾಚಾರ. ಇದಲ್ಲದೆ, ನಿಮ್ಮ ಕೋಟಾ ಕೀಯನ್ನು ನೀವು ವರ್ಗಾಯಿಸಬಹುದು. ಇದು, ಉದಾಹರಣೆಗೆ, ಆಂತರಿಕ ಬಳಕೆದಾರ ID. ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಕೋಟಾಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ.
ಈಗ ಮತ್ತೊಂದು ಕುತೂಹಲಕಾರಿ ಸಂಗತಿ. ಇದು ಹಸ್ತಚಾಲಿತ ಪ್ರತಿರೂಪವಾಗಿದೆ.
ಕ್ಲಿಕ್‌ಹೌಸ್ ಅಂತರ್ನಿರ್ಮಿತ ಪುನರಾವರ್ತನೆಯ ಬೆಂಬಲವನ್ನು ಹೊಂದಿದ್ದರೂ, ಜನರು ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಪುನರಾವರ್ತಿಸುವ ಹಲವು ಪ್ರಕರಣಗಳು ನನಗೆ ತಿಳಿದಿದೆ.
ತತ್ವ ಏನು? ನೀವು ಡೇಟಾ ಸಂಸ್ಕರಣಾ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಹೊಂದಿರುವಿರಿ. ಮತ್ತು ಇದು ಸ್ವತಂತ್ರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ವಿವಿಧ ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ. ನೀವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಅದೇ ಡೇಟಾವನ್ನು ಅದೇ ರೀತಿಯಲ್ಲಿ ಬರೆಯುತ್ತೀರಿ. ನಿಜ, ಅಭ್ಯಾಸವು ನಿಮ್ಮ ಕೋಡ್‌ನಲ್ಲಿರುವ ಕೆಲವು ವೈಶಿಷ್ಟ್ಯಗಳ ಕಾರಣದಿಂದಾಗಿ ಡೇಟಾ ಇನ್ನೂ ಭಿನ್ನವಾಗಿರುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಅದು ನಿಮ್ಮಲ್ಲಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.
ಮತ್ತು ಕಾಲಕಾಲಕ್ಕೆ ನೀವು ಇನ್ನೂ ಹಸ್ತಚಾಲಿತವಾಗಿ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ತಿಂಗಳಿಗೊಮ್ಮೆ ನಿರ್ವಾಹಕರು rsync ಮಾಡುತ್ತಾರೆ.
ವಾಸ್ತವವಾಗಿ, ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ಪ್ರತಿಕೃತಿಯನ್ನು ಬಳಸುವುದು ತುಂಬಾ ಸುಲಭ. ಆದರೆ ಕೆಲವು ವಿರೋಧಾಭಾಸಗಳು ಇರಬಹುದು, ಏಕೆಂದರೆ ಇದಕ್ಕಾಗಿ ನೀವು ZooKeeper ಅನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ. ZooKeeper ಬಗ್ಗೆ ನಾನು ಕೆಟ್ಟದ್ದನ್ನು ಹೇಳುವುದಿಲ್ಲ, ತಾತ್ವಿಕವಾಗಿ, ಸಿಸ್ಟಮ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಜಾವಾ-ಫೋಬಿಯಾದಿಂದಾಗಿ ಜನರು ಅದನ್ನು ಬಳಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಕ್ಲಿಕ್‌ಹೌಸ್ ಸಿ ++ ನಲ್ಲಿ ಬರೆಯಲಾದ ಉತ್ತಮ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ, ಅದನ್ನು ನೀವು ಬಳಸಬಹುದು ಮತ್ತು ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿರುತ್ತದೆ. ಮತ್ತು ZooKeeper ಜಾವಾದಲ್ಲಿದೆ. ಮತ್ತು ಹೇಗಾದರೂ ನೀವು ನೋಡಲು ಬಯಸುವುದಿಲ್ಲ, ಆದರೆ ನಂತರ ನೀವು ಹಸ್ತಚಾಲಿತ ಪ್ರತಿಕೃತಿಯನ್ನು ಬಳಸಬಹುದು.
ಕ್ಲಿಕ್‌ಹೌಸ್ ಒಂದು ಪ್ರಾಯೋಗಿಕ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ. ಅವಳು ನಿಮ್ಮ ಅಗತ್ಯಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತಾಳೆ. ನೀವು ಹಸ್ತಚಾಲಿತ ಪ್ರತಿಕೃತಿಯನ್ನು ಹೊಂದಿದ್ದರೆ, ನಿಮ್ಮ ಹಸ್ತಚಾಲಿತ ಪ್ರತಿಕೃತಿಗಳನ್ನು ನೋಡುವ ಮತ್ತು ಅವುಗಳ ನಡುವೆ ವಿಫಲತೆಯನ್ನು ಮಾಡುವ ವಿತರಣಾ ಕೋಷ್ಟಕವನ್ನು ನೀವು ರಚಿಸಬಹುದು. ಮತ್ತು ನಿಮ್ಮ ಸಾಲುಗಳು ವ್ಯವಸ್ಥಿತವಾಗಿ ಭಿನ್ನವಾಗಿದ್ದರೂ ಸಹ, ಫ್ಲಾಪ್‌ಗಳನ್ನು ತಪ್ಪಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ವಿಶೇಷ ಆಯ್ಕೆ ಕೂಡ ಇದೆ.
ನೀವು ಪ್ರಾಚೀನ ಟೇಬಲ್ ಎಂಜಿನ್ಗಳನ್ನು ಬಳಸಿದರೆ ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳು ಉಂಟಾಗಬಹುದು. ಕ್ಲಿಕ್‌ಹೌಸ್ ವಿವಿಧ ಟೇಬಲ್ ಎಂಜಿನ್‌ಗಳ ಗುಂಪನ್ನು ಹೊಂದಿರುವ ಕನ್‌ಸ್ಟ್ರಕ್ಟರ್ ಆಗಿದೆ. ಎಲ್ಲಾ ಗಂಭೀರ ಪ್ರಕರಣಗಳಿಗೆ, ದಾಖಲಾತಿಯಲ್ಲಿ ಬರೆದಂತೆ, MergeTree ಕುಟುಂಬದಿಂದ ಕೋಷ್ಟಕಗಳನ್ನು ಬಳಸಿ. ಮತ್ತು ಎಲ್ಲಾ ಉಳಿದ - ಇದು ಆದ್ದರಿಂದ, ವೈಯಕ್ತಿಕ ಸಂದರ್ಭಗಳಲ್ಲಿ ಅಥವಾ ಪರೀಕ್ಷೆಗಳಿಗೆ.
MergeTree ಕೋಷ್ಟಕದಲ್ಲಿ, ನೀವು ಯಾವುದೇ ದಿನಾಂಕ ಮತ್ತು ಸಮಯವನ್ನು ಹೊಂದುವ ಅಗತ್ಯವಿಲ್ಲ. ನೀವು ಅದನ್ನು ಇನ್ನೂ ಬಳಸಬಹುದು. ದಿನಾಂಕ ಮತ್ತು ಸಮಯವಿಲ್ಲದಿದ್ದರೆ, ಡೀಫಾಲ್ಟ್ 2000 ಎಂದು ಬರೆಯಿರಿ. ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ.
ಮತ್ತು ಸರ್ವರ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯಲ್ಲಿ, ವಿಭಜನಾ ಕೀ ಇಲ್ಲದೆಯೇ ನೀವು ಕಸ್ಟಮ್ ವಿಭಜನೆಯನ್ನು ಹೊಂದಿರುವಿರಿ ಎಂದು ಸಹ ನೀವು ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು. ಅದೇ ಆಗಿರುತ್ತದೆ.
ಮತ್ತೊಂದೆಡೆ, ನೀವು ಪ್ರಾಚೀನ ಟೇಬಲ್ ಎಂಜಿನ್ಗಳನ್ನು ಬಳಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ಒಮ್ಮೆ ಡೇಟಾವನ್ನು ಭರ್ತಿ ಮಾಡಿ ಮತ್ತು ನೋಡಿ, ಟ್ವಿಸ್ಟ್ ಮಾಡಿ ಮತ್ತು ಅಳಿಸಿ. ನೀವು ಲಾಗ್ ಅನ್ನು ಬಳಸಬಹುದು.
ಅಥವಾ ಮಧ್ಯಂತರ ಪ್ರಕ್ರಿಯೆಗಾಗಿ ಸಣ್ಣ ಸಂಪುಟಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಸ್ಟ್ರೈಪ್ಲಾಗ್ ಅಥವಾ ಟೈನಿಲಾಗ್ ಆಗಿದೆ.
ಡೇಟಾದ ಪ್ರಮಾಣವು ಚಿಕ್ಕದಾಗಿದ್ದರೆ ಮೆಮೊರಿಯನ್ನು ಬಳಸಬಹುದು ಮತ್ತು ನೀವು RAM ನಲ್ಲಿ ಏನನ್ನಾದರೂ ಸರಳವಾಗಿ ತಿರುಗಿಸಬಹುದು.
ClickHouse ನಿಜವಾಗಿಯೂ ಮರುರೂಪಿಸಿದ ಡೇಟಾವನ್ನು ಇಷ್ಟಪಡುವುದಿಲ್ಲ.
ಒಂದು ವಿಶಿಷ್ಟ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ. ಇದು ದೊಡ್ಡ ಸಂಖ್ಯೆಯ URL ಗಳು. ನೀವು ಅವುಗಳನ್ನು ಮುಂದಿನ ಕೋಷ್ಟಕದಲ್ಲಿ ಇರಿಸಿ. ತದನಂತರ ಅವರು ಅವರೊಂದಿಗೆ ಸೇರಲು ನಿರ್ಧರಿಸಿದರು, ಆದರೆ ಇದು ನಿಯಮದಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಕ್ಲಿಕ್‌ಹೌಸ್ ಹ್ಯಾಶ್ ಜಾಯಿನ್ ಅನ್ನು ಮಾತ್ರ ಬೆಂಬಲಿಸುತ್ತದೆ. ಸಂಪರ್ಕಿಸಬೇಕಾದ ಬಹಳಷ್ಟು ಡೇಟಾಗೆ ಸಾಕಷ್ಟು RAM ಇಲ್ಲದಿದ್ದರೆ, JOIN ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ*.
ಡೇಟಾವು ಹೆಚ್ಚಿನ ಕಾರ್ಡಿನಾಲಿಟಿಯಾಗಿದ್ದರೆ, ಚಿಂತಿಸಬೇಡಿ, ಅದನ್ನು ಸಾಮಾನ್ಯೀಕರಿಸಿದ ರೂಪದಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ, URL ಗಳು ಮುಖ್ಯ ಕೋಷ್ಟಕದಲ್ಲಿ ನೇರವಾಗಿ ಇರುತ್ತವೆ.
* ಮತ್ತು ಈಗ ಕ್ಲಿಕ್‌ಹೌಸ್ ವಿಲೀನ ಸೇರುವಿಕೆಯನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಇದು ಮಧ್ಯಂತರ ಡೇಟಾ RAM ಗೆ ಹೊಂದಿಕೆಯಾಗದ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆದರೆ ಇದು ನಿಷ್ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ ಮತ್ತು ಶಿಫಾರಸು ಜಾರಿಯಲ್ಲಿದೆ.
ಇನ್ನೂ ಒಂದೆರಡು ಉದಾಹರಣೆಗಳು, ಆದರೆ ಅವು ವಿರೋಧಿ ಮಾದರಿಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂದು ನಾನು ಈಗಾಗಲೇ ಅನುಮಾನಿಸುತ್ತೇನೆ.
ClickHouse ಒಂದು ತಿಳಿದಿರುವ ನ್ಯೂನತೆಯನ್ನು ಹೊಂದಿದೆ. ಇದನ್ನು ಹೇಗೆ ನವೀಕರಿಸಬೇಕು* ಎಂದು ತಿಳಿದಿಲ್ಲ. ಕೆಲವು ರೀತಿಯಲ್ಲಿ, ಇದು ಸಹ ಒಳ್ಳೆಯದು. ನೀವು ಕೆಲವು ಪ್ರಮುಖ ಡೇಟಾವನ್ನು ಹೊಂದಿದ್ದರೆ, ಉದಾಹರಣೆಗೆ, ಲೆಕ್ಕಪತ್ರ ನಿರ್ವಹಣೆ, ನಂತರ ಯಾರೂ ಅದನ್ನು ಕಳುಹಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಯಾವುದೇ ನವೀಕರಣಗಳಿಲ್ಲ.
* ಬ್ಯಾಚ್ ಮೋಡ್‌ನಲ್ಲಿ ನವೀಕರಣ ಮತ್ತು ಅಳಿಸುವಿಕೆಗೆ ಬೆಂಬಲವನ್ನು ಬಹಳ ಹಿಂದೆಯೇ ಸೇರಿಸಲಾಗಿದೆ.
ಆದರೆ ಹಿನ್ನೆಲೆಯಲ್ಲಿರುವಂತೆ ನವೀಕರಣಗಳನ್ನು ಅನುಮತಿಸುವ ಕೆಲವು ವಿಶೇಷ ವಿಧಾನಗಳಿವೆ. ಉದಾಹರಣೆಗೆ, ReplaceMergeTree ನಂತಹ ಕೋಷ್ಟಕಗಳು. ಹಿನ್ನೆಲೆ ವಿಲೀನದ ಸಮಯದಲ್ಲಿ ಅವರು ನವೀಕರಣಗಳನ್ನು ಮಾಡುತ್ತಾರೆ. ಆಪ್ಟಿಮೈಜ್ ಟೇಬಲ್ ಬಳಸಿ ನೀವು ಇದನ್ನು ಒತ್ತಾಯಿಸಬಹುದು. ಆದರೆ ಇದನ್ನು ಹೆಚ್ಚಾಗಿ ಮಾಡಬೇಡಿ, ಏಕೆಂದರೆ ಅದು ವಿಭಜನೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಿದ್ದಿ ಬರೆಯುತ್ತದೆ.
ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ವಿತರಿಸಲಾದ ಸೇರ್ಪಡೆಗಳನ್ನು ಸಹ ಪ್ರಶ್ನೆ ಯೋಜಕರಿಂದ ಸರಿಯಾಗಿ ನಿರ್ವಹಿಸಲಾಗಿಲ್ಲ.
ಕೆಟ್ಟದು, ಆದರೆ ಕೆಲವೊಮ್ಮೆ ಸರಿ.
ಆಯ್ಕೆಮಾಡಿ* ಬಳಸಿಕೊಂಡು ಡೇಟಾವನ್ನು ಮರಳಿ ಓದಲು ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಮಾತ್ರ ಬಳಸುವುದು.
ತೊಡಕಿನ ಲೆಕ್ಕಾಚಾರಗಳಿಗಾಗಿ ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಬಳಸಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುವುದಿಲ್ಲ. ಆದರೆ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ನಿಜವಲ್ಲ, ಏಕೆಂದರೆ ನಾವು ಈಗಾಗಲೇ ಈ ಶಿಫಾರಸಿನಿಂದ ದೂರ ಹೋಗುತ್ತಿದ್ದೇವೆ. ಮತ್ತು ನಾವು ಇತ್ತೀಚೆಗೆ ಕ್ಲಿಕ್‌ಹೌಸ್ - ಕ್ಯಾಟ್‌ಬೂಸ್ಟ್‌ನಲ್ಲಿ ಯಂತ್ರ ಕಲಿಕೆ ಮಾದರಿಗಳನ್ನು ಅನ್ವಯಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಸೇರಿಸಿದ್ದೇವೆ. ಮತ್ತು ಇದು ನನ್ನನ್ನು ಕಾಡುತ್ತದೆ ಏಕೆಂದರೆ ನಾನು ಯೋಚಿಸುತ್ತೇನೆ, “ಏನು ಭಯಾನಕ. ಇದು ಪ್ರತಿ ಬೈಟ್‌ಗೆ ಎಷ್ಟು ಚಕ್ರಗಳನ್ನು ತಿರುಗಿಸುತ್ತದೆ! ಬೈಟ್‌ಗಳಲ್ಲಿ ಗಡಿಯಾರಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡುವುದನ್ನು ನಾನು ನಿಜವಾಗಿಯೂ ದ್ವೇಷಿಸುತ್ತೇನೆ.
ಆದರೆ ಭಯಪಡಬೇಡಿ, ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿ, ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿರುತ್ತದೆ. ಏನಾದರೂ ಇದ್ದರೆ, ನಮಗೆ ಒಂದು ಸಮುದಾಯವಿದೆ. ಅಂದಹಾಗೆ, ಸಮುದಾಯವು ನೀವೇ. ಮತ್ತು ನಿಮಗೆ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿದ್ದರೆ, ನೀವು ಕನಿಷ್ಟ ನಮ್ಮ ಚಾಟ್‌ಗೆ ಹೋಗಬಹುದು ಮತ್ತು ಆಶಾದಾಯಕವಾಗಿ ಅವರು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತಾರೆ.
ಪ್ರಶ್ನೆಗಳು
ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ಕ್ಲಿಕ್‌ಹೌಸ್ ಕ್ರ್ಯಾಶಿಂಗ್ ಬಗ್ಗೆ ನಾನು ಎಲ್ಲಿ ದೂರು ನೀಡಬಹುದು?
ನೀವು ಇದೀಗ ನನಗೆ ವೈಯಕ್ತಿಕವಾಗಿ ದೂರು ನೀಡಬಹುದು.
ನಾನು ಇತ್ತೀಚೆಗೆ ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದೆ. ನಾನು ತಕ್ಷಣ ಕ್ಲೈ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಕೈಬಿಟ್ಟೆ.
ಏನು ಅಂಕ.
ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ನಾನು ಸಣ್ಣ ಆಯ್ಕೆಯೊಂದಿಗೆ ಸರ್ವರ್ ಅನ್ನು ಕ್ರ್ಯಾಶ್ ಮಾಡಿದೆ.
ನಿಮ್ಮಲ್ಲಿ ಪ್ರತಿಭೆ ಇದೆ.
ನಾನು GitHub ಬಗ್ ಅನ್ನು ತೆರೆದಿದ್ದೇನೆ, ಆದರೆ ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸಲಾಗಿದೆ.
ಸರಿ ನೊಡೋಣ.
ವರದಿಗೆ ಹಾಜರಾಗುವಂತೆ ಅಲೆಕ್ಸಿ ನನ್ನನ್ನು ಮೋಸಗೊಳಿಸಿದರು, ನೀವು ಒಳಗೆ ಡೇಟಾವನ್ನು ಹೇಗೆ ಪ್ರವೇಶಿಸುತ್ತೀರಿ ಎಂದು ನನಗೆ ಹೇಳುವುದಾಗಿ ಭರವಸೆ ನೀಡಿದರು.
ಇದು ತುಂಬಾ ಸರಳವಾಗಿದೆ.
ನಾನು ಇದನ್ನು ನಿನ್ನೆ ಅರಿತುಕೊಂಡೆ. ಹೆಚ್ಚು ನಿಶ್ಚಿತಗಳು.
ಅಲ್ಲಿ ಯಾವುದೇ ಭಯಾನಕ ತಂತ್ರಗಳಿಲ್ಲ. ಕೇವಲ ಬ್ಲಾಕ್-ಬೈ-ಬ್ಲಾಕ್ ಕಂಪ್ರೆಷನ್ ಇದೆ. ಡೀಫಾಲ್ಟ್ LZ4 ಆಗಿದೆ, ನೀವು ZSTD* ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು. 64 ಕಿಲೋಬೈಟ್‌ಗಳಿಂದ 1 ಮೆಗಾಬೈಟ್‌ವರೆಗೆ ನಿರ್ಬಂಧಿಸುತ್ತದೆ.
* ಇತರ ಅಲ್ಗಾರಿದಮ್‌ಗಳೊಂದಿಗೆ ಸರಪಳಿಯಲ್ಲಿ ಬಳಸಬಹುದಾದ ವಿಶೇಷ ಸಂಕೋಚನ ಕೊಡೆಕ್‌ಗಳಿಗೆ ಸಹ ಬೆಂಬಲವಿದೆ.
ಬ್ಲಾಕ್‌ಗಳು ಕೇವಲ ಕಚ್ಚಾ ಡೇಟಾವೇ?
ಸಂಪೂರ್ಣವಾಗಿ ಕಚ್ಚಾ ಅಲ್ಲ. ವ್ಯೂಹಗಳಿವೆ. ನೀವು ಸಂಖ್ಯಾತ್ಮಕ ಕಾಲಮ್ ಹೊಂದಿದ್ದರೆ, ನಂತರ ಸಾಲುಗಳಲ್ಲಿ ಸಂಖ್ಯೆಗಳನ್ನು ಒಂದು ಶ್ರೇಣಿಯಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ.
ಇದು ಸ್ಪಷ್ಟವಾಗಿದೆ.
ಅಲೆಕ್ಸಿ, IP ಗಳ ಮೇಲೆ uniqExact ನೊಂದಿಗೆ ಇದ್ದ ಒಂದು ಉದಾಹರಣೆ, ಅಂದರೆ uniqExact ಸಂಖ್ಯೆಗಳಿಂದ ರೇಖೆಗಳ ಮೂಲಕ ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಇತ್ಯಾದಿ. ಪ್ರೂಫ್ ರೀಡಿಂಗ್ ಸಮಯದಲ್ಲಿ ನಾವು ನಮ್ಮ ಕಿವಿಗಳಿಂದ ಫೀಂಟ್ ಅನ್ನು ಬಳಸಿದರೆ ಮತ್ತು ಎರಕಹೊಯ್ದರೆ ಏನು? ಅಂದರೆ, ನಮ್ಮ ಡಿಸ್ಕ್ನಲ್ಲಿ ಅದು ತುಂಬಾ ಭಿನ್ನವಾಗಿಲ್ಲ ಎಂದು ನೀವು ಹೇಳಿದ್ದೀರಿ ಎಂದು ತೋರುತ್ತದೆ. ನಾವು ಡಿಸ್ಕ್ ಮತ್ತು ಎರಕಹೊಯ್ದ ಸಾಲುಗಳನ್ನು ಓದಿದರೆ, ನಮ್ಮ ಒಟ್ಟು ಮೊತ್ತವು ವೇಗವಾಗಿರುತ್ತದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ? ಅಥವಾ ನಾವು ಇನ್ನೂ ಇಲ್ಲಿ ಸ್ವಲ್ಪ ಲಾಭ ಪಡೆಯುತ್ತೇವೆಯೇ? ನೀವು ಇದನ್ನು ಪರೀಕ್ಷಿಸಿದ್ದೀರಿ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ, ಆದರೆ ಕೆಲವು ಕಾರಣಗಳಿಂದ ಅದನ್ನು ಮಾನದಂಡದಲ್ಲಿ ಸೂಚಿಸಲಿಲ್ಲ.
ಬಿತ್ತರಿಸದೆ ಇರುವುದಕ್ಕಿಂತ ಇದು ನಿಧಾನವಾಗಿರುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಐಪಿ ವಿಳಾಸವನ್ನು ಸ್ಟ್ರಿಂಗ್‌ನಿಂದ ಪಾರ್ಸ್ ಮಾಡಬೇಕು. ಸಹಜವಾಗಿ, ClickHouse ನಲ್ಲಿ, ನಮ್ಮ IP ವಿಳಾಸ ಪಾರ್ಸಿಂಗ್ ಅನ್ನು ಸಹ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲಾಗಿದೆ. ನಾವು ತುಂಬಾ ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ, ಆದರೆ ಅಲ್ಲಿ ನೀವು ಹತ್ತು ಸಾವಿರದ ರೂಪದಲ್ಲಿ ಬರೆದ ಸಂಖ್ಯೆಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ. ತುಂಬಾ ಅಹಿತಕರ. ಮತ್ತೊಂದೆಡೆ, uniqExact ಕಾರ್ಯವು ಸ್ಟ್ರಿಂಗ್‌ಗಳಲ್ಲಿ ನಿಧಾನವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಇವುಗಳು ಸ್ಟ್ರಿಂಗ್‌ಗಳಾಗಿರುವುದರಿಂದ, ಆದರೆ ಅಲ್ಗಾರಿದಮ್‌ನ ವಿಭಿನ್ನ ವಿಶೇಷತೆಯನ್ನು ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ. ತಂತಿಗಳನ್ನು ಸರಳವಾಗಿ ವಿಭಿನ್ನವಾಗಿ ಸಂಸ್ಕರಿಸಲಾಗುತ್ತದೆ.
ನಾವು ಹೆಚ್ಚು ಪ್ರಾಚೀನ ಡೇಟಾ ಪ್ರಕಾರವನ್ನು ತೆಗೆದುಕೊಂಡರೆ ಏನು? ಉದಾಹರಣೆಗೆ, ನಾವು ಹೊಂದಿರುವ ಯೂಸರ್ ಐಡಿಯನ್ನು ನಾವು ಬರೆದು, ಅದನ್ನು ಸಾಲಾಗಿ ಬರೆದು, ನಂತರ ಅದನ್ನು ಸ್ಕ್ರ್ಯಾಂಬಲ್ ಮಾಡಿದ್ದೇವೆ, ಅದು ಹೆಚ್ಚು ಖುಷಿಯಾಗುತ್ತದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ?
ನನಗೆ ಅನುಮಾನ. ಇದು ಇನ್ನೂ ದುಃಖಕರವಾಗಿರುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಏಕೆಂದರೆ ಎಲ್ಲಾ ನಂತರ, ಸಂಖ್ಯೆಗಳನ್ನು ಪಾರ್ಸಿಂಗ್ ಮಾಡುವುದು ಗಂಭೀರ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಈ ಸಹೋದ್ಯೋಗಿ ಹತ್ತು ಸಾವಿರದ ರೂಪದಲ್ಲಿ ಸಂಖ್ಯೆಗಳನ್ನು ಪಾರ್ಸ್ ಮಾಡುವುದು ಎಷ್ಟು ಕಷ್ಟ ಎಂಬ ವರದಿಯನ್ನು ಸಹ ನೀಡಿದ್ದಾರೆ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ, ಆದರೆ ಬಹುಶಃ ಅಲ್ಲ.
ಅಲೆಕ್ಸಿ, ವರದಿಗಾಗಿ ತುಂಬಾ ಧನ್ಯವಾದಗಳು! ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗಾಗಿ ತುಂಬಾ ಧನ್ಯವಾದಗಳು! ಯೋಜನೆಗಳ ಬಗ್ಗೆ ನನಗೆ ಪ್ರಶ್ನೆ ಇದೆ. ಡಿಕ್ಷನರಿಗಳನ್ನು ಅಪೂರ್ಣವಾಗಿ ನವೀಕರಿಸಲು ವೈಶಿಷ್ಟ್ಯಕ್ಕಾಗಿ ಯಾವುದೇ ಯೋಜನೆಗಳಿವೆಯೇ?
ಅಂದರೆ, ಭಾಗಶಃ ರೀಬೂಟ್?
ಹೌದು ಹೌದು. ಅಲ್ಲಿ MySQL ಕ್ಷೇತ್ರವನ್ನು ಹೊಂದಿಸುವ ಸಾಮರ್ಥ್ಯದಂತೆ, ಅಂದರೆ ನಂತರ ನವೀಕರಿಸಿ ಇದರಿಂದ ನಿಘಂಟು ತುಂಬಾ ದೊಡ್ಡದಾಗಿದ್ದರೆ ಮಾತ್ರ ಈ ಡೇಟಾವನ್ನು ಲೋಡ್ ಮಾಡಲಾಗುತ್ತದೆ.
ಬಹಳ ಆಸಕ್ತಿದಾಯಕ ವೈಶಿಷ್ಟ್ಯ. ಮತ್ತು ನಮ್ಮ ಚಾಟ್‌ನಲ್ಲಿ ಯಾರೋ ಒಬ್ಬರು ಇದನ್ನು ಸೂಚಿಸಿದ್ದಾರೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಬಹುಶಃ ಅದು ನೀನೇ ಆಗಿರಬಹುದು.
ನಾನು ಹಾಗೆ ಯೋಚಿಸುವುದಿಲ್ಲ.
ಅದ್ಭುತವಾಗಿದೆ, ಈಗ ಎರಡು ವಿನಂತಿಗಳಿವೆ ಎಂದು ತಿರುಗುತ್ತದೆ. ಮತ್ತು ನೀವು ನಿಧಾನವಾಗಿ ಅದನ್ನು ಮಾಡಲು ಪ್ರಾರಂಭಿಸಬಹುದು. ಆದರೆ ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ತುಂಬಾ ಸರಳವಾಗಿದೆ ಎಂದು ನಾನು ನಿಮಗೆ ಈಗಿನಿಂದಲೇ ಎಚ್ಚರಿಸಲು ಬಯಸುತ್ತೇನೆ. ಅಂದರೆ, ಸಿದ್ಧಾಂತದಲ್ಲಿ, ನೀವು ಕೇವಲ ಕೋಷ್ಟಕದಲ್ಲಿ ಆವೃತ್ತಿ ಸಂಖ್ಯೆಯನ್ನು ಬರೆಯಬೇಕು ಮತ್ತು ನಂತರ ಬರೆಯಬೇಕು: ಅಂತಹ ಮತ್ತು ಅಂತಹವುಗಳಿಗಿಂತ ಕಡಿಮೆ ಆವೃತ್ತಿ. ಇದರರ್ಥ, ಹೆಚ್ಚಾಗಿ, ನಾವು ಇದನ್ನು ಉತ್ಸಾಹಿಗಳಿಗೆ ನೀಡುತ್ತೇವೆ. ನೀವು ಉತ್ಸಾಹಿಯೇ?
ಹೌದು, ಆದರೆ, ದುರದೃಷ್ಟವಶಾತ್, C++ ನಲ್ಲಿ ಅಲ್ಲ.
C++ ನಲ್ಲಿ ಬರೆಯುವುದು ಹೇಗೆ ಎಂದು ನಿಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳಿಗೆ ತಿಳಿದಿದೆಯೇ?
ನಾನು ಯಾರನ್ನಾದರೂ ಹುಡುಕುತ್ತೇನೆ.
ಶ್ರೇಷ್ಠ *.
* ವರದಿಯ ಎರಡು ತಿಂಗಳ ನಂತರ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಸೇರಿಸಲಾಗಿದೆ - ಪ್ರಶ್ನೆಯ ಲೇಖಕರು ಅದನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದರು ಮತ್ತು ಕಳುಹಿಸಿದರು .
ಧನ್ಯವಾದಗಳು!
ನಮಸ್ಕಾರ! ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸೇವಿಸುವಲ್ಲಿ ಉತ್ತಮವಾಗಿದೆ ಎಂದು ನೀವು ಉಲ್ಲೇಖಿಸಿದ್ದೀರಿ. ಮತ್ತು ಲಕ್ಸಾಫ್ಟ್ ಪಕ್ಕದಲ್ಲಿರುವ ಸ್ಪೀಕರ್ ರಷ್ಯಾದ ಪೋಸ್ಟ್‌ಗೆ ಅವರ ಪರಿಹಾರದ ಬಗ್ಗೆ ಮಾತನಾಡಿದರು. ಅವರು ನಿಜವಾಗಿಯೂ ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಇಷ್ಟಪಟ್ಟಿದ್ದಾರೆ ಎಂದು ಅವರು ಹೇಳಿದರು, ಆದರೆ ಅವರು ತಮ್ಮ ಮುಖ್ಯ ಪ್ರತಿಸ್ಪರ್ಧಿಯ ಬದಲಿಗೆ ಅದನ್ನು ಬಳಸಲಿಲ್ಲ ಏಕೆಂದರೆ ಅದು ಎಲ್ಲಾ CPU ಅನ್ನು ತಿನ್ನುತ್ತದೆ. ಮತ್ತು ಅವರು ಅದನ್ನು ತಮ್ಮ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ, ಡಾಕರ್‌ಗಳೊಂದಿಗೆ ತಮ್ಮ ZooKeeper ಗೆ ಪ್ಲಗ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಹೇಗಾದರೂ ಮಿತಿಗೊಳಿಸಲು ಸಾಧ್ಯವೇ ಇದರಿಂದ ಅದು ಲಭ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ ಸೇವಿಸುವುದಿಲ್ಲವೇ?
ಹೌದು, ಇದು ಸಾಧ್ಯ ಮತ್ತು ತುಂಬಾ ಸುಲಭ. ನೀವು ಕಡಿಮೆ ಕೋರ್ಗಳನ್ನು ಸೇವಿಸಲು ಬಯಸಿದರೆ, ನಂತರ ಬರೆಯಿರಿ set max_threads = 1. ಮತ್ತು ಅದು ಇಲ್ಲಿದೆ, ಇದು ಒಂದು ಕೋರ್ನಲ್ಲಿ ವಿನಂತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ಇದಲ್ಲದೆ, ನೀವು ವಿಭಿನ್ನ ಬಳಕೆದಾರರಿಗೆ ವಿಭಿನ್ನ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು. ಹಾಗಾಗಿ ತೊಂದರೆ ಇಲ್ಲ. ಮತ್ತು ಲುಕ್ಸಾಫ್ಟ್‌ನಿಂದ ನಿಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳಿಗೆ ಅವರು ಈ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಡಾಕ್ಯುಮೆಂಟೇಶನ್‌ನಲ್ಲಿ ಕಂಡುಹಿಡಿಯದಿರುವುದು ಒಳ್ಳೆಯದಲ್ಲ ಎಂದು ಹೇಳಿ.
ಅಲೆಕ್ಸಿ, ಹಲೋ! ನಾನು ಈ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳಲು ಬಯಸುತ್ತೇನೆ. ಅನೇಕ ಜನರು ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಲಾಗ್‌ಗಳಿಗಾಗಿ ಸಂಗ್ರಹಣೆಯಾಗಿ ಬಳಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದಾರೆ ಎಂದು ನಾನು ಕೇಳಿದ್ದು ಇದೇ ಮೊದಲಲ್ಲ. ವರದಿಯಲ್ಲಿ ನೀವು ಇದನ್ನು ಮಾಡಬೇಡಿ ಎಂದು ಹೇಳಿದ್ದೀರಿ, ಅಂದರೆ ನೀವು ಉದ್ದವಾದ ತಂತಿಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಇದರ ಬಗ್ಗೆ ನಿನಗೆ ಏನು ಅನ್ನಿಸುತ್ತದೆ?
ಮೊದಲನೆಯದಾಗಿ, ಲಾಗ್ಗಳು ನಿಯಮದಂತೆ, ಉದ್ದವಾದ ತಂತಿಗಳಲ್ಲ. ಸಹಜವಾಗಿ, ವಿನಾಯಿತಿಗಳಿವೆ. ಉದಾಹರಣೆಗೆ, ಜಾವಾದಲ್ಲಿ ಬರೆಯಲಾದ ಕೆಲವು ಸೇವೆಗಳು ವಿನಾಯಿತಿಯನ್ನು ಎಸೆಯುತ್ತವೆ, ಅದು ಲಾಗ್ ಆಗಿದೆ. ಮತ್ತು ಅಂತ್ಯವಿಲ್ಲದ ಲೂಪ್ನಲ್ಲಿ, ಮತ್ತು ಹಾರ್ಡ್ ಡ್ರೈವಿನಲ್ಲಿನ ಸ್ಥಳವು ಖಾಲಿಯಾಗುತ್ತದೆ. ಪರಿಹಾರವು ತುಂಬಾ ಸರಳವಾಗಿದೆ. ಸಾಲುಗಳು ತುಂಬಾ ಉದ್ದವಾಗಿದ್ದರೆ, ನಂತರ ಅವುಗಳನ್ನು ಕತ್ತರಿಸಿ. ದೀರ್ಘ ಎಂದರೆ ಏನು? ಹತ್ತಾರು ಕಿಲೋಬೈಟ್‌ಗಳು ಕೆಟ್ಟವು*.
* ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಗಳಲ್ಲಿ, “ಹೊಂದಾಣಿಕೆ ಸೂಚ್ಯಂಕ ಗ್ರ್ಯಾನ್ಯುಲಾರಿಟಿ” ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ, ಇದು ಬಹುಪಾಲು ದೀರ್ಘ ಸಾಲುಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ನಿವಾರಿಸುತ್ತದೆ.
ಕಿಲೋಬೈಟ್ ಸಾಮಾನ್ಯವೇ?
ಸಾಮಾನ್ಯವಾಗಿದೆ
ನಮಸ್ಕಾರ! ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ನಾನು ಈಗಾಗಲೇ ಚಾಟ್‌ನಲ್ಲಿ ಇದರ ಬಗ್ಗೆ ಕೇಳಿದ್ದೇನೆ, ಆದರೆ ನಾನು ಉತ್ತರವನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇನೆ ಎಂದು ನನಗೆ ನೆನಪಿಲ್ಲ. CTE ರೀತಿಯಲ್ಲಿ ಹೇಗಾದರೂ ವಿಭಾಗದೊಂದಿಗೆ ವಿಸ್ತರಿಸಲು ಯೋಜನೆಗಳಿವೆಯೇ?
ಇನ್ನು ಇಲ್ಲ. ನಮ್ಮೊಂದಿಗೆ ವಿಭಾಗವು ಸ್ವಲ್ಪ ಕ್ಷುಲ್ಲಕವಾಗಿದೆ. ಇದು ನಮಗೆ ಒಂದು ಸಣ್ಣ ವೈಶಿಷ್ಟ್ಯದಂತಿದೆ.
ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ. ಧನ್ಯವಾದ!
ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ಬಹಳ ಆಸಕ್ತಿದಾಯಕ! ಜಾಗತಿಕ ಪ್ರಶ್ನೆ. ಬಹುಶಃ ಕೆಲವು ರೀತಿಯ ಸ್ಟಬ್‌ಗಳ ರೂಪದಲ್ಲಿ ಡೇಟಾ ಅಳಿಸುವಿಕೆಯನ್ನು ಮಾರ್ಪಡಿಸಲು ಯಾವುದೇ ಯೋಜನೆಗಳಿವೆಯೇ?
ಅಗತ್ಯವಾಗಿ. ನಮ್ಮ ಸರತಿ ಸಾಲಿನಲ್ಲಿ ಇದು ನಮ್ಮ ಮೊದಲ ಕಾರ್ಯವಾಗಿದೆ. ಎಲ್ಲವನ್ನೂ ಸರಿಯಾಗಿ ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ನಾವು ಈಗ ಸಕ್ರಿಯವಾಗಿ ಯೋಚಿಸುತ್ತಿದ್ದೇವೆ. ಮತ್ತು ನೀವು ಕೀಬೋರ್ಡ್* ಅನ್ನು ಒತ್ತುವುದನ್ನು ಪ್ರಾರಂಭಿಸಬೇಕು.
* ಕೀಬೋರ್ಡ್‌ನಲ್ಲಿರುವ ಬಟನ್‌ಗಳನ್ನು ಒತ್ತಿ ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಮಾಡಿದರು.
ಇದು ಹೇಗಾದರೂ ಸಿಸ್ಟಮ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ? ಅಳವಡಿಕೆಯು ಈಗಿರುವಂತೆಯೇ ವೇಗವಾಗಿರುತ್ತದೆಯೇ?
ಬಹುಶಃ ಸ್ವತಃ ಅಳಿಸುವಿಕೆಗಳು ಮತ್ತು ನವೀಕರಣಗಳು ತುಂಬಾ ಭಾರವಾಗಿರುತ್ತದೆ, ಆದರೆ ಇದು ಆಯ್ಕೆಗಳ ಕಾರ್ಯಕ್ಷಮತೆ ಅಥವಾ ಒಳಸೇರಿಸುವಿಕೆಯ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.
ಮತ್ತು ಇನ್ನೂ ಒಂದು ಸಣ್ಣ ಪ್ರಶ್ನೆ. ಪ್ರಸ್ತುತಿಯಲ್ಲಿ ನೀವು ಪ್ರಾಥಮಿಕ ಕೀಲಿಯ ಬಗ್ಗೆ ಮಾತನಾಡಿದ್ದೀರಿ. ಅಂತೆಯೇ, ನಾವು ವಿಭಜನೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಇದು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಮಾಸಿಕವಾಗಿದೆ, ಸರಿ? ಮತ್ತು ನಾವು ಒಂದು ತಿಂಗಳಿಗೆ ಸರಿಹೊಂದುವ ದಿನಾಂಕ ಶ್ರೇಣಿಯನ್ನು ಹೊಂದಿಸಿದಾಗ, ಈ ವಿಭಾಗವನ್ನು ಮಾತ್ರ ಓದಲಾಗುತ್ತದೆ, ಸರಿ?
ಹೌದು.
ಒಂದು ಪ್ರಶ್ನೆ. ನಾವು ಯಾವುದೇ ಪ್ರಾಥಮಿಕ ಕೀಲಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, "ದಿನಾಂಕ" ಕ್ಷೇತ್ರದ ಪ್ರಕಾರ ಅದನ್ನು ನಿರ್ದಿಷ್ಟವಾಗಿ ಮಾಡುವುದು ಸರಿಯಾಗಿದೆಯೇ ಆದ್ದರಿಂದ ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಈ ಡೇಟಾದ ಕಡಿಮೆ ಮರುಜೋಡಣೆ ಇರುತ್ತದೆ ಆದ್ದರಿಂದ ಅದು ಹೆಚ್ಚು ಕ್ರಮಬದ್ಧವಾಗಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆಯೇ? ನೀವು ಶ್ರೇಣಿಯ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ ಮತ್ತು ನೀವು ಯಾವುದೇ ಪ್ರಾಥಮಿಕ ಕೀಲಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಪ್ರಾಥಮಿಕ ಕೀಲಿಯಲ್ಲಿ ದಿನಾಂಕವನ್ನು ಹಾಕುವುದು ಯೋಗ್ಯವಾಗಿದೆಯೇ?
ಹೌದು.
ಪ್ರಾಯಶಃ ಪ್ರಾಥಮಿಕ ಕೀಲಿಯಲ್ಲಿ ಕ್ಷೇತ್ರವನ್ನು ಹಾಕಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ ಅದು ಈ ಕ್ಷೇತ್ರದಿಂದ ವಿಂಗಡಿಸಿದರೆ ಡೇಟಾವನ್ನು ಉತ್ತಮವಾಗಿ ಸಂಕುಚಿತಗೊಳಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಬಳಕೆದಾರ ID. ಬಳಕೆದಾರ, ಉದಾಹರಣೆಗೆ, ಅದೇ ಸೈಟ್ಗೆ ಹೋಗುತ್ತಾನೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಬಳಕೆದಾರ ಐಡಿ ಮತ್ತು ಸಮಯವನ್ನು ಹಾಕಿ. ತದನಂತರ ನಿಮ್ಮ ಡೇಟಾವನ್ನು ಉತ್ತಮವಾಗಿ ಸಂಕುಚಿತಗೊಳಿಸಲಾಗುತ್ತದೆ. ದಿನಾಂಕಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ, ನೀವು ನಿಜವಾಗಿಯೂ ದಿನಾಂಕಗಳಲ್ಲಿ ಶ್ರೇಣಿಯ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ ಮತ್ತು ಎಂದಿಗೂ ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ನೀವು ದಿನಾಂಕವನ್ನು ಪ್ರಾಥಮಿಕ ಕೀಲಿಯಲ್ಲಿ ಹಾಕಬೇಕಾಗಿಲ್ಲ.
ಸರಿ ತುಂಬಾ ಧನ್ಯವಾದಗಳು!
ಮೂಲ: www.habr.com