ಏಪ್ರಿಲ್‌ನಲ್ಲಿ, ಅವಿಟೊ ಎಂಜಿನಿಯರ್‌ಗಳು ಮುಖ್ಯ ಕ್ಲಿಕ್‌ಹೌಸ್ ಡೆವಲಪರ್ ಅಲೆಕ್ಸಿ ಮಿಲೋವಿಡೋವ್ ಮತ್ತು ಇಂಟೆಗ್ರೋಸ್ ಕಂಪನಿಯ ಗೋಲಾಂಗ್ ಡೆವಲಪರ್ ಕಿರಿಲ್ ಶ್ವಾಕೋವ್ ಅವರೊಂದಿಗೆ ಆನ್‌ಲೈನ್ ಸಭೆಗಳಿಗಾಗಿ ಒಟ್ಟುಗೂಡಿದರು. ನಾವು ಡೇಟಾಬೇಸ್ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೇಗೆ ಬಳಸುತ್ತೇವೆ ಮತ್ತು ನಾವು ಯಾವ ತೊಂದರೆಗಳನ್ನು ಎದುರಿಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ನಾವು ಚರ್ಚಿಸಿದ್ದೇವೆ.
ಸಭೆಯ ಆಧಾರದ ಮೇಲೆ, ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳು, ಡೇಟಾ ಮರುಹಂಚಿಕೆ, ಬಾಹ್ಯ ನಿಘಂಟುಗಳು, ಗೋಲಾಂಗ್ ಡ್ರೈವರ್ ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್ ಆವೃತ್ತಿಗಳನ್ನು ನವೀಕರಿಸುವ ಕುರಿತು ನಮ್ಮ ಮತ್ತು ಪ್ರೇಕ್ಷಕರ ಪ್ರಶ್ನೆಗಳಿಗೆ ತಜ್ಞರ ಉತ್ತರಗಳೊಂದಿಗೆ ನಾವು ಲೇಖನವನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ. Yandex DBMS ನೊಂದಿಗೆ ಈಗಾಗಲೇ ಸಕ್ರಿಯವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ಮತ್ತು ಅದರ ಪ್ರಸ್ತುತ ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿರುವ ಅಭಿವರ್ಧಕರಿಗೆ ಇದು ಉಪಯುಕ್ತವಾಗಬಹುದು. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಉತ್ತರಗಳು ಅಲೆಕ್ಸಿ ಮಿಲೋವಿಡೋವ್ ಅವರಿಂದ ಬರೆಯಲ್ಪಟ್ಟಿಲ್ಲದಿದ್ದರೆ.
ಜಾಗರೂಕರಾಗಿರಿ, ಕಟ್ ಅಡಿಯಲ್ಲಿ ಬಹಳಷ್ಟು ಪಠ್ಯವಿದೆ. ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿರುವ ವಿಷಯವು ನಿಮಗೆ ನ್ಯಾವಿಗೇಟ್ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ.
ಪರಿವಿಡಿ
ನೀವು ಪಠ್ಯವನ್ನು ಓದಲು ಬಯಸದಿದ್ದರೆ, ನೀವು ಕೂಟಗಳ ರೆಕಾರ್ಡಿಂಗ್ ಅನ್ನು ವೀಕ್ಷಿಸಬಹುದು . ಟೈಮ್‌ಕೋಡ್‌ಗಳು ವೀಡಿಯೊದ ಅಡಿಯಲ್ಲಿ ಮೊದಲ ಕಾಮೆಂಟ್‌ನಲ್ಲಿವೆ.
ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ನಿರಂತರವಾಗಿ ನವೀಕರಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ನಮ್ಮ ಡೇಟಾ ಅಲ್ಲ. ಅದಕ್ಕೆ ಏನು ಮಾಡಬೇಕು?
ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ನಿರಂತರವಾಗಿ ನವೀಕರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅಂತಿಮ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾದ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲಾದ ನಮ್ಮ ಡೇಟಾವನ್ನು ನವೀಕರಿಸಲಾಗಿಲ್ಲ ಮತ್ತು ಬ್ಯಾಕಪ್ ಪ್ರತಿಯಲ್ಲಿದೆ.
ನಮಗೆ ಕೆಲವು ಸಮಸ್ಯೆ ಇದೆ ಮತ್ತು ಡೇಟಾ ಕಳೆದುಹೋಗಿದೆ ಎಂದು ಹೇಳೋಣ. ನಾವು ಪುನಃಸ್ಥಾಪಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು ಬ್ಯಾಕ್ಅಪ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿರುವ ಹಳೆಯ ವಿಭಾಗಗಳು ಪ್ರಸ್ತುತ ಬಳಕೆಯಲ್ಲಿರುವ ಕ್ಲಿಕ್‌ಹೌಸ್ ಆವೃತ್ತಿಯಿಂದ ಬಹಳ ಭಿನ್ನವಾಗಿವೆ ಎಂದು ಅದು ಬದಲಾಯಿತು. ಅಂತಹ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಏನು ಮಾಡಬೇಕು, ಮತ್ತು ಅದು ಸಾಧ್ಯವೇ?
ನೀವು ಹಳೆಯ ಸ್ವರೂಪದಲ್ಲಿ ಬ್ಯಾಕ್‌ಅಪ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಮರುಸ್ಥಾಪಿಸಿದ ಪರಿಸ್ಥಿತಿ, ಆದರೆ ಅದು ಹೊಸ ಆವೃತ್ತಿಗೆ ಸಂಪರ್ಕ ಹೊಂದಿಲ್ಲ, ಅಸಾಧ್ಯ. ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿರುವ ಡೇಟಾ ಫಾರ್ಮ್ಯಾಟ್ ಯಾವಾಗಲೂ ಹಿಮ್ಮುಖ ಹೊಂದಾಣಿಕೆಯಾಗಿರುತ್ತದೆ ಎಂದು ನಾವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುತ್ತೇವೆ. ಅಪರೂಪವಾಗಿ ಬಳಸಿದ ಕೆಲವು ಕಾರ್ಯಗಳ ವರ್ತನೆಯು ಬದಲಾಗಿದ್ದರೆ ಕ್ರಿಯಾತ್ಮಕತೆಯ ವಿಷಯದಲ್ಲಿ ಹಿಮ್ಮುಖ ಹೊಂದಾಣಿಕೆಗಿಂತ ಇದು ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿದೆ. ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯು ಯಾವಾಗಲೂ ಡಿಸ್ಕ್ನಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿರುವ ಡೇಟಾವನ್ನು ಓದಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಇದು ಕಾನೂನು.
ClickHouse ನಿಂದ ಡೇಟಾವನ್ನು ಬ್ಯಾಕಪ್ ಮಾಡಲು ಪ್ರಸ್ತುತ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು ಯಾವುವು?
ನಾವು ಅಂತಿಮ ಕಾರ್ಯಾಚರಣೆಗಳು, ಟೆರಾಬೈಟ್‌ಗಳ ಬೃಹತ್ ಡೇಟಾಬೇಸ್ ಮತ್ತು ಕಳೆದ ಮೂರು ದಿನಗಳಿಂದ ನವೀಕರಿಸಿದ ಡೇಟಾವನ್ನು ಉತ್ತಮಗೊಳಿಸಿದ್ದೇವೆ ಮತ್ತು ನಂತರ ಅವರಿಗೆ ಯಾವುದೇ ಕಾರ್ಯವಿಧಾನಗಳು ಸಂಭವಿಸುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು ಬ್ಯಾಕಪ್‌ಗಳನ್ನು ಮಾಡುವುದು ಹೇಗೆ?
ನಾವು ನಮ್ಮದೇ ಆದ ಪರಿಹಾರವನ್ನು ಮಾಡಬಹುದು ಮತ್ತು ಬ್ಯಾಷ್‌ನಲ್ಲಿ ಬರೆಯಬಹುದು: ಈ ಬ್ಯಾಕ್ಅಪ್ ಪ್ರತಿಗಳನ್ನು ಅಂತಹ ಮತ್ತು ಅಂತಹ ರೀತಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ. ಬಹುಶಃ ಯಾವುದನ್ನಾದರೂ ಊರುಗೋಲು ಅಗತ್ಯವಿಲ್ಲ, ಮತ್ತು ಬೈಸಿಕಲ್ ಅನ್ನು ಬಹಳ ಹಿಂದೆಯೇ ಕಂಡುಹಿಡಿಯಲಾಯಿತು?
ಕೆಲವು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ. ನನ್ನ ಸಹೋದ್ಯೋಗಿಗಳು ಯಾವಾಗಲೂ ಸಲಹೆ ನೀಡುತ್ತಾರೆ, ಬ್ಯಾಕ್ಅಪ್ಗಳ ಬಗ್ಗೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ, Yandex.Cloud ಸೇವೆಯ ಬಗ್ಗೆ ಅವರಿಗೆ ನೆನಪಿಸಲು, ಈ ಸಮಸ್ಯೆಯನ್ನು ಈಗಾಗಲೇ ಪರಿಹರಿಸಲಾಗಿದೆ. ಆದ್ದರಿಂದ ಸಾಧ್ಯವಾದರೆ ಅದನ್ನು ಬಳಸಿ.
ಯಾವುದೇ ಸಂಪೂರ್ಣ ಪರಿಹಾರವಿಲ್ಲ, ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳಿಗಾಗಿ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ನೂರು ಪ್ರತಿಶತ ನಿರ್ಮಿಸಲಾಗಿದೆ. ಬಳಸಬಹುದಾದ ಕೆಲವು ಖಾಲಿ ಜಾಗಗಳಿವೆ. ಸಂಪೂರ್ಣ ಪರಿಹಾರವನ್ನು ಪಡೆಯಲು, ನೀವು ಸ್ವಲ್ಪ ಹಸ್ತಚಾಲಿತವಾಗಿ ಟಿಂಕರ್ ಮಾಡಬೇಕು ಅಥವಾ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳ ರೂಪದಲ್ಲಿ ಹೊದಿಕೆಗಳನ್ನು ರಚಿಸಬೇಕು.
ಡೇಟಾದ ಪರಿಮಾಣ ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ನ ಗಾತ್ರವನ್ನು ಅವಲಂಬಿಸಿ ನಾನು ಸರಳವಾದ ಪರಿಹಾರಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುತ್ತೇನೆ ಮತ್ತು ಅತ್ಯಾಧುನಿಕವಾದವುಗಳೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತೇನೆ. ಕ್ಲಸ್ಟರ್ ದೊಡ್ಡದಾಗಿದೆ, ಪರಿಹಾರವು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗುತ್ತದೆ.
ಡೇಟಾದೊಂದಿಗೆ ಟೇಬಲ್ ಕೆಲವು ಗಿಗಾಬೈಟ್‌ಗಳನ್ನು ಮಾತ್ರ ತೆಗೆದುಕೊಂಡರೆ, ಬ್ಯಾಕಪ್ ಅನ್ನು ಈ ರೀತಿ ಮಾಡಬಹುದು:
- ಟೇಬಲ್ ವ್ಯಾಖ್ಯಾನವನ್ನು ಉಳಿಸಿ ಅಂದರೆ ಮೆಟಾಡೇಟಾ - ಟೇಬಲ್ ರಚಿಸಿ ತೋರಿಸು.
- ಕ್ಲಿಕ್‌ಹೌಸ್ ಕ್ಲೈಂಟ್ ಬಳಸಿ ಡಂಪ್ ಮಾಡಿ - ಆಯ್ಕೆಮಾಡಿ * ಮೇಜಿನಿಂದ ಒಂದು ಕಡತಕ್ಕೆ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ನೀವು TabSeparated ಸ್ವರೂಪದಲ್ಲಿ ಫೈಲ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ. ನೀವು ಅದನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬಯಸಿದರೆ, ನೀವು ಅದನ್ನು ಸ್ಥಳೀಯ ಸ್ವರೂಪದಲ್ಲಿ ಮಾಡಬಹುದು.
ಡೇಟಾದ ಪ್ರಮಾಣವು ದೊಡ್ಡದಾಗಿದ್ದರೆ, ಬ್ಯಾಕಪ್ ಹೆಚ್ಚು ಸಮಯ ಮತ್ತು ಸಾಕಷ್ಟು ಜಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಇದನ್ನು ತಾರ್ಕಿಕ ಬ್ಯಾಕಪ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ; ಇದು ಕ್ಲಿಕ್‌ಹೌಸ್ ಡೇಟಾ ಸ್ವರೂಪಕ್ಕೆ ಸಂಬಂಧಿಸಿಲ್ಲ. ಅದು ಇದ್ದರೆ, ಕೊನೆಯ ಉಪಾಯವಾಗಿ ನೀವು ಬ್ಯಾಕಪ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಮತ್ತು ಅದನ್ನು ಮರುಸ್ಥಾಪಿಸಲು MySQL ಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಬಹುದು.
ಹೆಚ್ಚು ಮುಂದುವರಿದ ಪ್ರಕರಣಗಳಿಗಾಗಿ, ಸ್ಥಳೀಯ ಕಡತ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ವಿಭಾಗಗಳ ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಅನ್ನು ರಚಿಸಲು ಕ್ಲಿಕ್‌ಹೌಸ್ ಅಂತರ್ನಿರ್ಮಿತ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದೆ. ಈ ವೈಶಿಷ್ಟ್ಯವು ವಿನಂತಿಯಂತೆ ಲಭ್ಯವಿದೆ. ಟೇಬಲ್ ಫ್ರೀಜ್ ವಿಭಾಗವನ್ನು ಬದಲಾಯಿಸಿ. ಅಥವಾ ಸರಳವಾಗಿ ಟೇಬಲ್ ಫ್ರೀಜ್ ಅನ್ನು ಬದಲಾಯಿಸಿ - ಇದು ಸಂಪೂರ್ಣ ಟೇಬಲ್‌ನ ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಆಗಿದೆ.
ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಅನ್ನು ಒಂದು ಚೂರುಗಳ ಮೇಲೆ ಒಂದು ಟೇಬಲ್‌ಗೆ ಸ್ಥಿರವಾಗಿ ರಚಿಸಲಾಗುತ್ತದೆ, ಅಂದರೆ, ಈ ರೀತಿಯಲ್ಲಿ ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್‌ನ ಸ್ಥಿರವಾದ ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಅನ್ನು ರಚಿಸುವುದು ಅಸಾಧ್ಯ. ಆದರೆ ಹೆಚ್ಚಿನ ಕಾರ್ಯಗಳಿಗೆ ಅಂತಹ ಅಗತ್ಯವಿಲ್ಲ, ಮತ್ತು ಪ್ರತಿ ಚೂರುಗಳಲ್ಲಿ ವಿನಂತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಮತ್ತು ಸ್ಥಿರವಾದ ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಅನ್ನು ಪಡೆಯಲು ಸಾಕು. ಇದನ್ನು ಹಾರ್ಡ್‌ಲಿಂಕ್‌ಗಳ ರೂಪದಲ್ಲಿ ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ಆದ್ದರಿಂದ ಹೆಚ್ಚುವರಿ ಜಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ. ಮುಂದೆ, ನೀವು ಈ ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಅನ್ನು ಬ್ಯಾಕಪ್ ಸರ್ವರ್‌ಗೆ ಅಥವಾ ನೀವು ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳಿಗಾಗಿ ಬಳಸುವ ಸಂಗ್ರಹಣೆಗೆ ನಕಲಿಸುತ್ತೀರಿ.
ಅಂತಹ ಬ್ಯಾಕ್ಅಪ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸುವುದು ತುಂಬಾ ಸುಲಭ. ಮೊದಲಿಗೆ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಟೇಬಲ್ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನೀವು ಕೋಷ್ಟಕಗಳನ್ನು ರಚಿಸುತ್ತೀರಿ. ಮುಂದೆ, ಟೇಬಲ್ ಡೇಟಾಕ್ಕಾಗಿ ವಿಭಾಗಗಳ ಉಳಿಸಿದ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳನ್ನು ಡೈರೆಕ್ಟರಿ-ಡಿಟ್ಯಾಚ್‌ಗೆ ನಕಲಿಸಿ ಮತ್ತು ಪ್ರಶ್ನೆಯನ್ನು ಚಲಾಯಿಸಿ ವಿಭಾಗವನ್ನು ಲಗತ್ತಿಸಿ. ಈ ಪರಿಹಾರವು ಅತ್ಯಂತ ಗಂಭೀರವಾದ ದತ್ತಾಂಶಗಳಿಗೆ ಸಾಕಷ್ಟು ಸೂಕ್ತವಾಗಿದೆ.
ಪ್ರತಿ ಸರ್ವರ್‌ನಲ್ಲಿ ಹತ್ತಾರು ಅಥವಾ ನೂರಾರು ಟೆರಾಬೈಟ್‌ಗಳು ಮತ್ತು ನೂರಾರು ಸರ್ವರ್ಗಳನ್ನು ಹೊಂದಿರುವ ಸಂದರ್ಭಗಳಲ್ಲಿ - ಕೆಲವೊಮ್ಮೆ ನಿಮಗೆ ಇನ್ನೂ ತಂಪಾಗಿರುವ ಏನಾದರೂ ಅಗತ್ಯವಿರುತ್ತದೆ. Yandex.Metrica ನಿಂದ ನನ್ನ ಸಹೋದ್ಯೋಗಿಗಳಿಂದ ನಾನು ತೆಗೆದುಕೊಂಡ ಪರಿಹಾರ ಇಲ್ಲಿದೆ. ನಾನು ಅದನ್ನು ಎಲ್ಲರಿಗೂ ಶಿಫಾರಸು ಮಾಡುವುದಿಲ್ಲ - ಅದನ್ನು ಓದಿ ಮತ್ತು ಅದು ಸೂಕ್ತವೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದನ್ನು ನೀವೇ ನಿರ್ಧರಿಸಿ.
ಮೊದಲು ನೀವು ದೊಡ್ಡ ಡಿಸ್ಕ್ ಕಪಾಟಿನಲ್ಲಿ ಹಲವಾರು ಸರ್ವರ್ಗಳನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ. ಮುಂದೆ, ಈ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಹಲವಾರು ಕ್ಲಿಕ್‌ಹೌಸ್ ಸರ್ವರ್ಗಳನ್ನು ಸ್ಥಾಪಿಸಿ ಮತ್ತು ಅವುಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ ಇದರಿಂದ ಅವು ಅದೇ ಚೂರುಗಳಿಗೆ ಮತ್ತೊಂದು ಪ್ರತಿಕೃತಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ತದನಂತರ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳನ್ನು ರಚಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಈ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅಥವಾ ಕೆಲವು ಉಪಕರಣವನ್ನು ಬಳಸಿ. ಇಲ್ಲಿ ಎರಡು ಆಯ್ಕೆಗಳಿವೆ. ಮೊದಲ ಆಯ್ಕೆಯು LVM ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು, ಎರಡನೆಯ ಆಯ್ಕೆಯು Linux ನಲ್ಲಿ ZFS ಆಗಿದೆ.
ಅದರ ನಂತರ, ಪ್ರತಿದಿನ ನೀವು ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಅನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ, ಅದು ಸುಳ್ಳು ಮತ್ತು ಸ್ವಲ್ಪ ಜಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ಡೇಟಾ ಬದಲಾದರೆ, ಕಾಲಾನಂತರದಲ್ಲಿ ಜಾಗದ ಪ್ರಮಾಣವು ಹೆಚ್ಚಾಗುತ್ತದೆ. ಈ ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಅನ್ನು ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ತೆಗೆಯಬಹುದು ಮತ್ತು ಡೇಟಾವನ್ನು ಮರುಸ್ಥಾಪಿಸಬಹುದು, ಎಂತಹ ವಿಚಿತ್ರ ಪರಿಹಾರ. ಜೊತೆಗೆ, ನಾವು ಈ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಸಂರಚನೆಯಲ್ಲಿ ಮಿತಿಗೊಳಿಸಬೇಕಾಗಿದೆ ಇದರಿಂದ ಅವರು ನಾಯಕರಾಗಲು ಪ್ರಯತ್ನಿಸುವುದಿಲ್ಲ.
ಶಾಫ್ಟ್‌ಗಳಲ್ಲಿ ಪ್ರತಿಕೃತಿಗಳ ನಿಯಂತ್ರಿತ ಮಂದಗತಿಯನ್ನು ಸಂಘಟಿಸಲು ಸಾಧ್ಯವೇ?
ಈ ವರ್ಷ ನೀವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಶಾಫ್ಟ್‌ಗಳನ್ನು ಮಾಡಲು ಯೋಜಿಸುತ್ತಿದ್ದೀರಿ. ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಕೃತಿಗಳ ನಿಯಂತ್ರಿತ ಮಂದಗತಿಯನ್ನು ಸಂಘಟಿಸಲು ಸಾಧ್ಯವೇ? ಬದಲಾವಣೆಗಳು ಮತ್ತು ಇತರ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ನಕಾರಾತ್ಮಕ ಸನ್ನಿವೇಶಗಳಿಂದ ನಮ್ಮನ್ನು ರಕ್ಷಿಸಿಕೊಳ್ಳಲು ನಾವು ಅದನ್ನು ಬಳಸಲು ಬಯಸುತ್ತೇವೆ.
ಮಾರ್ಪಾಡುಗಳಿಗಾಗಿ ಕೆಲವು ರೀತಿಯ ರೋಲ್ ಬ್ಯಾಕ್ ಮಾಡಲು ಸಾಧ್ಯವೇ? ಉದಾಹರಣೆಗೆ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಶಾಫ್ಟ್‌ನಲ್ಲಿ, ಅದನ್ನು ತೆಗೆದುಕೊಂಡು ಈ ಕ್ಷಣದವರೆಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸಿ ಮತ್ತು ಈ ಕ್ಷಣದಿಂದ ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ ಎಂದು ಹೇಳಿ?
ಒಂದು ಆಜ್ಞೆಯು ನಮ್ಮ ಕ್ಲಸ್ಟರ್‌ಗೆ ಬಂದು ಅದನ್ನು ಮುರಿದರೆ, ನಾವು ಒಂದು ಗಂಟೆಯ ವಿಳಂಬದೊಂದಿಗೆ ಷರತ್ತುಬದ್ಧ ಪ್ರತಿಕೃತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅಲ್ಲಿ ನಾವು ಅದನ್ನು ಈ ಸಮಯದಲ್ಲಿ ಬಳಸೋಣ ಎಂದು ಹೇಳಬಹುದು, ಆದರೆ ನಾವು ಅದರಲ್ಲಿ ಕೊನೆಯ ಹತ್ತು ನಿಮಿಷಗಳ ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸುವುದಿಲ್ಲವೇ?
ಮೊದಲಿಗೆ, ಪ್ರತಿಕೃತಿಗಳ ನಿಯಂತ್ರಿತ ಮಂದಗತಿಯ ಬಗ್ಗೆ. ಬಳಕೆದಾರರಿಂದ ಅಂತಹ ವಿನಂತಿಯಿದೆ ಮತ್ತು ನಾವು ಗಿಥಬ್‌ನಲ್ಲಿ ವಿನಂತಿಯೊಂದಿಗೆ ಸಮಸ್ಯೆಯನ್ನು ರಚಿಸಿದ್ದೇವೆ: “ಯಾರಿಗಾದರೂ ಇದು ಅಗತ್ಯವಿದ್ದರೆ, ಅದನ್ನು ಇಷ್ಟಪಡಿ, ಹೃದಯವನ್ನು ಇರಿಸಿ.” ಯಾರೂ ವಿತರಿಸಲಿಲ್ಲ, ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ಮುಚ್ಚಲಾಯಿತು. ಆದಾಗ್ಯೂ, ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ ನೀವು ಈಗಾಗಲೇ ಈ ಅವಕಾಶವನ್ನು ಪಡೆಯಬಹುದು. ನಿಜ, ಆವೃತ್ತಿ 20.3 ರಿಂದ ಮಾತ್ರ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.
ಕ್ಲಿಕ್‌ಹೌಸ್ ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಡೇಟಾ ವಿಲೀನವನ್ನು ನಿರಂತರವಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ. ವಿಲೀನವು ಪೂರ್ಣಗೊಂಡಾಗ, ಡೇಟಾದ ನಿರ್ದಿಷ್ಟ ತುಣುಕುಗಳನ್ನು ದೊಡ್ಡ ತುಣುಕಿನಿಂದ ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಮೊದಲು ಇದ್ದ ಡೇಟಾದ ತುಣುಕುಗಳು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಡಿಸ್ಕ್ನಲ್ಲಿ ಉಳಿಯುತ್ತವೆ.
ಮೊದಲನೆಯದಾಗಿ, ನಿರ್ಬಂಧಿಸದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ಅವುಗಳನ್ನು ಬಳಸುವ ಆಯ್ದ ಪ್ರಶ್ನೆಗಳು ಇರುವವರೆಗೆ ಅವುಗಳನ್ನು ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಆಯ್ದ ಪ್ರಶ್ನೆಗಳನ್ನು ಹಳೆಯ ಭಾಗಗಳಿಂದ ಸುಲಭವಾಗಿ ಓದಬಹುದು.
ಎರಡನೆಯದಾಗಿ, ಸಮಯದ ಮಿತಿ ಕೂಡ ಇದೆ - ಹಳೆಯ ಡೇಟಾ ತುಣುಕುಗಳು ಡಿಸ್ಕ್ನಲ್ಲಿ ಎಂಟು ನಿಮಿಷಗಳವರೆಗೆ ಇರುತ್ತದೆ. ಈ ಎಂಟು ನಿಮಿಷಗಳನ್ನು ಕಸ್ಟಮೈಸ್ ಮಾಡಬಹುದು ಮತ್ತು ಒಂದು ದಿನವನ್ನಾಗಿ ಪರಿವರ್ತಿಸಬಹುದು. ಇದು ಡಿಸ್ಕ್ ಜಾಗವನ್ನು ವೆಚ್ಚ ಮಾಡುತ್ತದೆ: ಡೇಟಾ ಹರಿವನ್ನು ಅವಲಂಬಿಸಿ, ಕೊನೆಯ ದಿನದಲ್ಲಿ ಡೇಟಾವು ದ್ವಿಗುಣಗೊಳ್ಳುವುದಿಲ್ಲ, ಅದು ಐದು ಪಟ್ಟು ಹೆಚ್ಚು ಆಗಬಹುದು. ಆದರೆ ಗಂಭೀರ ಸಮಸ್ಯೆ ಇದ್ದರೆ, ನೀವು ಕ್ಲಿಕ್‌ಹೌಸ್ ಸರ್ವರ್ ಅನ್ನು ನಿಲ್ಲಿಸಬಹುದು ಮತ್ತು ಎಲ್ಲವನ್ನೂ ವಿಂಗಡಿಸಬಹುದು.
ಇದು ಬದಲಾವಣೆಗಳ ವಿರುದ್ಧ ಹೇಗೆ ರಕ್ಷಿಸುತ್ತದೆ ಎಂಬುದು ಈಗ ಪ್ರಶ್ನೆಯಾಗಿದೆ. ಇಲ್ಲಿ ಆಳವಾದ ನೋಟವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು ಯೋಗ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ ClickHouse ನ ಹಳೆಯ ಆವೃತ್ತಿಗಳಲ್ಲಿ, ಬದಲಾವಣೆಯು ನೇರವಾಗಿ ಭಾಗಗಳನ್ನು ಬದಲಾಯಿಸುವ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಕೆಲವು ಫೈಲ್‌ಗಳೊಂದಿಗೆ ಡೇಟಾದ ತುಣುಕು ಇದೆ, ಮತ್ತು ನಾವು ಮಾಡುತ್ತೇವೆ, ಉದಾಹರಣೆಗೆ, ಡ್ರಾಪ್ ಕಾಲಮ್ ಅನ್ನು ಬದಲಾಯಿಸಿ. ನಂತರ ಈ ಕಾಲಮ್ ಅನ್ನು ಎಲ್ಲಾ ಭಾಗಗಳಿಂದ ಭೌತಿಕವಾಗಿ ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ.
ಆದರೆ ಆವೃತ್ತಿ 20.3 ರಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಆಲ್ಟರ್ ಕಾರ್ಯವಿಧಾನವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸಲಾಗಿದೆ ಮತ್ತು ಈಗ ಡೇಟಾದ ತುಣುಕುಗಳು ಯಾವಾಗಲೂ ಬದಲಾಗುವುದಿಲ್ಲ. ಅವು ಬದಲಾಗುವುದಿಲ್ಲ - ಈಗ ಮಾರ್ಪಾಡುಗಳು ವಿಲೀನದಂತೆಯೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಸ್ಥಳದಲ್ಲಿ ತುಂಡನ್ನು ಬದಲಿಸುವ ಬದಲು, ನಾವು ಹೊಸದನ್ನು ರಚಿಸುತ್ತೇವೆ. ಹೊಸ ಚಂಕ್‌ನಲ್ಲಿ, ಬದಲಾಗದ ಫೈಲ್‌ಗಳು ಹಾರ್ಡ್‌ಲಿಂಕ್‌ಗಳಾಗುತ್ತವೆ ಮತ್ತು ನಾವು ಕಾಲಮ್ ಅನ್ನು ಅಳಿಸಿದರೆ, ಅದು ಹೊಸ ಚಂಕ್‌ನಲ್ಲಿ ಕಾಣೆಯಾಗುತ್ತದೆ. ಎಂಟು ನಿಮಿಷಗಳ ನಂತರ ಹಳೆಯ ತುಣುಕನ್ನು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಅಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಇಲ್ಲಿ ನೀವು ಮೇಲೆ ತಿಳಿಸಲಾದ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ತಿರುಚಬಹುದು.
ರೂಪಾಂತರಗಳಂತಹ ಬದಲಾವಣೆಗಳಿಗೆ ಇದು ಅನ್ವಯಿಸುತ್ತದೆ. ನೀವು ಮಾಡಿದಾಗ ಅಳಿಸುವಿಕೆಯನ್ನು ಬದಲಾಯಿಸಿ ಅಥವಾ ನವೀಕರಣವನ್ನು ಬದಲಾಯಿಸಿ, ಇದು ತುಣುಕನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ, ಆದರೆ ಹೊಸದನ್ನು ರಚಿಸುತ್ತದೆ. ತದನಂತರ ಹಳೆಯದನ್ನು ಅಳಿಸುತ್ತದೆ.
ಮೇಜಿನ ರಚನೆಯು ಬದಲಾಗಿದ್ದರೆ ಏನು?
ಹಳೆಯ ಸ್ಕೀಮ್‌ನೊಂದಿಗೆ ಮಾಡಲಾದ ಬ್ಯಾಕಪ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸುವುದು ಹೇಗೆ? ಮತ್ತು ಎರಡನೇ ಪ್ರಶ್ನೆ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು ಮತ್ತು ಫೈಲ್ ಸಿಸ್ಟಮ್ ಪರಿಕರಗಳ ಬಗ್ಗೆ. Linux LVM ನಲ್ಲಿ ZFS ಬದಲಿಗೆ Btrfs ಉತ್ತಮವಾಗಿದೆಯೇ?
ನೀವು ಮಾಡಿದರೆ ವಿಭಾಗವನ್ನು ಲಗತ್ತಿಸಿ ವಿಭಿನ್ನ ರಚನೆಯೊಂದಿಗೆ ವಿಭಾಗಗಳು, ನಂತರ ಕ್ಲಿಕ್‌ಹೌಸ್ ಇದು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ನಿಮಗೆ ತಿಳಿಸುತ್ತದೆ. ಇದು ಪರಿಹಾರವಾಗಿದೆ. ಮೊದಲನೆಯದು ಹಳೆಯ ರಚನೆಯೊಂದಿಗೆ MergeTree ಪ್ರಕಾರದ ತಾತ್ಕಾಲಿಕ ಕೋಷ್ಟಕವನ್ನು ರಚಿಸುವುದು, ಲಗತ್ತನ್ನು ಬಳಸಿಕೊಂಡು ಡೇಟಾವನ್ನು ಲಗತ್ತಿಸುವುದು ಮತ್ತು ಪರ್ಯಾಯ ಪ್ರಶ್ನೆಯನ್ನು ಮಾಡುವುದು. ನಂತರ ನೀವು ಈ ಡೇಟಾವನ್ನು ನಕಲಿಸಬಹುದು ಅಥವಾ ವರ್ಗಾಯಿಸಬಹುದು ಮತ್ತು ಮತ್ತೆ ಲಗತ್ತಿಸಬಹುದು ಅಥವಾ ವಿನಂತಿಯನ್ನು ಬಳಸಬಹುದು ಟೇಬಲ್ ಮೂವ್ ವಿಭಾಗವನ್ನು ಬದಲಾಯಿಸಿ.
ಈಗ ಎರಡನೇ ಪ್ರಶ್ನೆ Btrfs ಅನ್ನು ಬಳಸಬಹುದೇ ಎಂಬುದು. ಪ್ರಾರಂಭಿಸಲು, ನೀವು LVM ಹೊಂದಿದ್ದರೆ, ನಂತರ LVM ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು ಸಾಕು, ಮತ್ತು ಫೈಲ್ ಸಿಸ್ಟಮ್ ext4 ಆಗಿರಬಹುದು, ಅದು ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ. Btrts ನೊಂದಿಗೆ, ಎಲ್ಲವೂ ಅದನ್ನು ಬಳಸುವ ನಿಮ್ಮ ಅನುಭವವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಇದು ಪ್ರಬುದ್ಧ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಆಗಿದೆ, ಆದರೆ ನಿರ್ದಿಷ್ಟ ಸನ್ನಿವೇಶದಲ್ಲಿ ಆಚರಣೆಯಲ್ಲಿ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಇನ್ನೂ ಕೆಲವು ಅನುಮಾನಗಳಿವೆ. ನೀವು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಬಿಟಿಆರ್‌ಎಫ್‌ಗಳನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ ಇದನ್ನು ಬಳಸಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುವುದಿಲ್ಲ.
ಡೇಟಾ ಮರುಹೊಂದಿಕೆಯಲ್ಲಿ ಪ್ರಸ್ತುತ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು ಯಾವುವು?
ಮರುಹೊಂದಾಣಿಕೆಯ ಸಮಸ್ಯೆಯು ಸಂಕೀರ್ಣ ಮತ್ತು ಬಹುಮುಖಿಯಾಗಿದೆ. ಇಲ್ಲಿ ಹಲವಾರು ಸಂಭವನೀಯ ಉತ್ತರಗಳಿವೆ. ನೀವು ಒಂದು ಕಡೆಯಿಂದ ಹೋಗಿ ಹೀಗೆ ಹೇಳಬಹುದು: ClickHouse ಅಂತರ್ನಿರ್ಮಿತ ಮರುಹಂಚಿಕೆ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊಂದಿಲ್ಲ. ಆದರೆ ಈ ಉತ್ತರವು ಯಾರಿಗೂ ಸರಿಹೊಂದುವುದಿಲ್ಲ ಎಂದು ನಾನು ಹೆದರುತ್ತೇನೆ. ಆದ್ದರಿಂದ, ನೀವು ಇನ್ನೊಂದು ಬದಿಯಿಂದ ಹೋಗಬಹುದು ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಮರುಹೊಂದಿಸಲು ಹಲವು ಮಾರ್ಗಗಳಿವೆ ಎಂದು ಹೇಳಬಹುದು.
ಕ್ಲಸ್ಟರ್ ಸ್ಥಳಾವಕಾಶವಿಲ್ಲದಿದ್ದರೆ ಅಥವಾ ಲೋಡ್ ಅನ್ನು ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ನೀವು ಹೊಸ ಸರ್ವರ್ಗಳನ್ನು ಸೇರಿಸಿ. ಆದರೆ ಈ ಸರ್ವರ್‌ಗಳು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಖಾಲಿಯಾಗಿವೆ, ಅವುಗಳಲ್ಲಿ ಯಾವುದೇ ಡೇಟಾ ಇಲ್ಲ ಮತ್ತು ಯಾವುದೇ ಲೋಡ್ ಇಲ್ಲ. ನೀವು ಡೇಟಾವನ್ನು ಮರುಹೊಂದಿಸಬೇಕಾಗಿದೆ ಇದರಿಂದ ಅದು ಹೊಸ, ದೊಡ್ಡ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸಮವಾಗಿ ಹರಡುತ್ತದೆ.
ವಿನಂತಿಯನ್ನು ಬಳಸಿಕೊಂಡು ವಿಭಾಗಗಳ ಭಾಗವನ್ನು ಹೊಸ ಸರ್ವರ್‌ಗಳಿಗೆ ನಕಲಿಸುವುದು ಇದನ್ನು ಮಾಡಬಹುದಾದ ಮೊದಲ ಮಾರ್ಗವಾಗಿದೆ ಟೇಬಲ್ ಪಡೆಯುವ ವಿಭಾಗವನ್ನು ಬದಲಿಸಿ. ಉದಾಹರಣೆಗೆ, ನೀವು ತಿಂಗಳ ಮೂಲಕ ವಿಭಾಗಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ನೀವು 2017 ರ ಮೊದಲ ತಿಂಗಳನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಹೊಸ ಸರ್ವರ್‌ಗೆ ನಕಲಿಸಿ, ನಂತರ ಮೂರನೇ ತಿಂಗಳನ್ನು ಬೇರೆ ಕೆಲವು ಹೊಸ ಸರ್ವರ್‌ಗೆ ನಕಲಿಸಿ. ಮತ್ತು ಅದು ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಆಗುವವರೆಗೆ ನೀವು ಇದನ್ನು ಮಾಡಿ.
ರೆಕಾರ್ಡಿಂಗ್ ಮಾಡುವಾಗ ಬದಲಾಗದ ಆ ವಿಭಾಗಗಳಿಗೆ ಮಾತ್ರ ವರ್ಗಾವಣೆಯನ್ನು ಕೈಗೊಳ್ಳಬಹುದು. ತಾಜಾ ವಿಭಾಗಗಳಿಗಾಗಿ, ರೆಕಾರ್ಡಿಂಗ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಅವುಗಳ ವರ್ಗಾವಣೆ ಪರಮಾಣು ಅಲ್ಲ. ಇಲ್ಲದಿದ್ದರೆ, ನಿಮ್ಮ ಡೇಟಾದಲ್ಲಿ ನೀವು ನಕಲುಗಳು ಅಥವಾ ಅಂತರಗಳೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುವಿರಿ. ಆದಾಗ್ಯೂ, ಈ ವಿಧಾನವು ಪ್ರಾಯೋಗಿಕವಾಗಿದೆ ಮತ್ತು ಸಾಕಷ್ಟು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ರೆಡಿಮೇಡ್ ಸಂಕುಚಿತ ವಿಭಾಗಗಳನ್ನು ನೆಟ್ವರ್ಕ್ ಮೂಲಕ ರವಾನಿಸಲಾಗುತ್ತದೆ, ಅಂದರೆ, ಡೇಟಾವನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಲಾಗಿಲ್ಲ ಅಥವಾ ಮರು-ಎನ್ಕೋಡ್ ಮಾಡಲಾಗಿಲ್ಲ.
ಈ ವಿಧಾನವು ಒಂದು ನ್ಯೂನತೆಯನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಇದು ಶಾರ್ಡಿಂಗ್ ಸ್ಕೀಮ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ, ನೀವು ಈ ಶಾರ್ಡಿಂಗ್ ಸ್ಕೀಮ್‌ಗೆ ವಾಗ್ದಾನ ಮಾಡಿದ್ದೀರಾ, ನೀವು ಯಾವ ಶಾರ್ಡಿಂಗ್ ಕೀ ಹೊಂದಿದ್ದೀರಿ. ಮೆಟ್ರಿಕ್‌ಗಳೊಂದಿಗಿನ ನಿಮ್ಮ ಉದಾಹರಣೆಯಲ್ಲಿ, ಶಾರ್ಡಿಂಗ್ ಕೀ ಪಾಥ್‌ನ ಹ್ಯಾಶ್ ಆಗಿದೆ. ನೀವು ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಟೇಬಲ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿದಾಗ, ಅದು ನೇರವಾಗಿ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಚೂರುಗಳಿಗೆ ಹೋಗುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿಂದ ಡೇಟಾವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಇದರರ್ಥ, ವಾಸ್ತವವಾಗಿ, ಯಾವ ಚೂರುಗಳಲ್ಲಿ ಯಾವ ಡೇಟಾ ಕೊನೆಗೊಂಡಿತು ಎಂಬುದು ನಿಮಗೆ ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ. ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ಒಂದು ಹಾದಿಯಲ್ಲಿರುವ ಡೇಟಾವು ಒಂದು ಚೂರುಗಳಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಯಾವುದು ಮುಖ್ಯವಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ರೆಡಿಮೇಡ್ ವಿಭಾಗಗಳನ್ನು ವರ್ಗಾಯಿಸುವುದು ಪರಿಪೂರ್ಣವಾಗಿದೆ, ಏಕೆಂದರೆ ಆಯ್ದ ಪ್ರಶ್ನೆಗಳೊಂದಿಗೆ ನೀವು ಸಂಪೂರ್ಣ ಡೇಟಾವನ್ನು ಸಹ ಸ್ವೀಕರಿಸುತ್ತೀರಿ, ಮರುಹಂಚಿಕೆ ಮಾಡುವ ಮೊದಲು ಅಥವಾ ನಂತರ, ಯೋಜನೆಯು ನಿಜವಾಗಿಯೂ ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ.
ಆದರೆ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಪ್ರಕರಣಗಳಿವೆ. ಅಪ್ಲಿಕೇಶನ್ ಲಾಜಿಕ್ ಮಟ್ಟದಲ್ಲಿ ನೀವು ವಿಶೇಷವಾದ ಶೇರ್ಡಿಂಗ್ ಸ್ಕೀಮ್ ಅನ್ನು ಅವಲಂಬಿಸಿದ್ದರೆ, ಈ ಕ್ಲೈಂಟ್ ಅಂತಹ ಮತ್ತು ಅಂತಹ ಚೂರುಗಳ ಮೇಲೆ ನೆಲೆಗೊಂಡಿದೆ ಮತ್ತು ವಿನಂತಿಯನ್ನು ನೇರವಾಗಿ ಅಲ್ಲಿಗೆ ಕಳುಹಿಸಬಹುದು ಮತ್ತು ವಿತರಿಸಿದ ಟೇಬಲ್‌ಗೆ ಅಲ್ಲ. ಅಥವಾ ನೀವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತಿರುವಿರಿ ಮತ್ತು ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದ್ದೀರಿ ಬಳಕೆಯಾಗದ ಚೂರುಗಳನ್ನು ಬಿಟ್ಟುಬಿಡಿ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಆಯ್ದ ಪ್ರಶ್ನೆಯ ಸಮಯದಲ್ಲಿ, ವಿಭಾಗದಲ್ಲಿನ ಅಭಿವ್ಯಕ್ತಿಯನ್ನು ವಿಶ್ಲೇಷಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಶೇರ್ಡಿಂಗ್ ಯೋಜನೆಯ ಪ್ರಕಾರ ಯಾವ ಚೂರುಗಳನ್ನು ಬಳಸಬೇಕೆಂದು ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ. ಈ ಹಂಚಿಕೆ ಯೋಜನೆಗೆ ಅನುಗುಣವಾಗಿ ಡೇಟಾವನ್ನು ನಿಖರವಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ ಎಂದು ಇದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನೀವು ಅವುಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಮರುಹೊಂದಿಸಿದರೆ, ಪತ್ರವ್ಯವಹಾರವು ಬದಲಾಗಬಹುದು.
ಆದ್ದರಿಂದ ಇದು ವಿಧಾನ ನಂಬರ್ ಒನ್ ಆಗಿದೆ. ಮತ್ತು ನಿಮ್ಮ ಉತ್ತರಕ್ಕಾಗಿ ನಾನು ಕಾಯುತ್ತಿದ್ದೇನೆ, ವಿಧಾನವು ಸೂಕ್ತವಾಗಿದೆಯೇ ಅಥವಾ ನಾವು ಮುಂದುವರಿಯೋಣ.
ವ್ಲಾಡಿಮಿರ್ ಕೊಲೊಬೇವ್, ಅವಿಟೊದಲ್ಲಿ ಪ್ರಮುಖ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು: ಅಲೆಕ್ಸಿ, ಓದುವಿಕೆ ಸೇರಿದಂತೆ ನೀವು ಲೋಡ್ ಅನ್ನು ಹರಡಬೇಕಾದಾಗ ನೀವು ಹೇಳಿದ ವಿಧಾನವು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ನಾವು ಮಾಸಿಕವಾದ ವಿಭಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಮತ್ತು ಹಿಂದಿನ ತಿಂಗಳನ್ನು ಮತ್ತೊಂದು ನೋಡ್‌ಗೆ ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಆದರೆ ಈ ಡೇಟಾಕ್ಕಾಗಿ ವಿನಂತಿಯು ಬಂದಾಗ, ನಾವು ಅದನ್ನು ಮಾತ್ರ ಲೋಡ್ ಮಾಡುತ್ತೇವೆ. ಆದರೆ ನಾವು ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಲೋಡ್ ಮಾಡಲು ಬಯಸುತ್ತೇವೆ, ಇಲ್ಲದಿದ್ದರೆ, ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಸಂಪೂರ್ಣ ಓದುವ ಲೋಡ್ ಅನ್ನು ಎರಡು ಚೂರುಗಳಿಂದ ಸಂಸ್ಕರಿಸಲಾಗುತ್ತದೆ.
ಅಲೆಕ್ಸಿ ಮಿಲೋವಿಡೋವ್: ಇಲ್ಲಿ ಉತ್ತರ ವಿಚಿತ್ರವಾಗಿದೆ - ಹೌದು, ಇದು ಕೆಟ್ಟದು, ಆದರೆ ಅದು ಕೆಲಸ ಮಾಡಬಹುದು. ಹೇಗೆ ಎಂದು ನಾನು ನಿಖರವಾಗಿ ವಿವರಿಸುತ್ತೇನೆ. ನಿಮ್ಮ ಡೇಟಾದೊಂದಿಗೆ ಬರುವ ಲೋಡ್ ಸನ್ನಿವೇಶವನ್ನು ನೋಡುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ಇದು ಡೇಟಾವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತಿದ್ದರೆ, ಬಹುಪಾಲು ವಿನಂತಿಗಳು ತಾಜಾ ಡೇಟಾಕ್ಕಾಗಿ ಎಂದು ನಾವು ಖಚಿತವಾಗಿ ಹೇಳಬಹುದು.
ನೀವು ಹೊಸ ಸರ್ವರ್ಗಳನ್ನು ಸ್ಥಾಪಿಸಿದ್ದೀರಿ, ಹಳೆಯ ವಿಭಾಗಗಳನ್ನು ಸ್ಥಳಾಂತರಿಸಿದ್ದೀರಿ, ಆದರೆ ತಾಜಾ ಡೇಟಾವನ್ನು ಹೇಗೆ ದಾಖಲಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಸಹ ಬದಲಾಯಿಸಿದ್ದೀರಿ. ಮತ್ತು ತಾಜಾ ಡೇಟಾವನ್ನು ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಹರಡಲಾಗುತ್ತದೆ. ಹೀಗಾಗಿ, ಕೇವಲ ಐದು ನಿಮಿಷಗಳ ನಂತರ, ಕೊನೆಯ ಐದು ನಿಮಿಷಗಳ ವಿನಂತಿಗಳು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸಮವಾಗಿ ಲೋಡ್ ಮಾಡುತ್ತದೆ; ಒಂದು ದಿನದ ನಂತರ, ಒಂದು ದಿನದ ವಿನಂತಿಗಳು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸಮವಾಗಿ ಲೋಡ್ ಮಾಡುತ್ತದೆ. ಮತ್ತು ಹಿಂದಿನ ತಿಂಗಳ ವಿನಂತಿಗಳು, ದುರದೃಷ್ಟವಶಾತ್, ಕ್ಲಸ್ಟರ್ ಸರ್ವರ್‌ಗಳ ಭಾಗಕ್ಕೆ ಮಾತ್ರ ಹೋಗುತ್ತವೆ.
ಆದರೆ ಆಗಾಗ್ಗೆ ನೀವು ಫೆಬ್ರವರಿ 2019 ಕ್ಕೆ ವಿನಂತಿಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. ಹೆಚ್ಚಾಗಿ, ವಿನಂತಿಗಳು 2019 ಕ್ಕೆ ಹೋದರೆ, ಅವು ಸಂಪೂರ್ಣ 2019 ಕ್ಕೆ ಇರುತ್ತವೆ - ದೊಡ್ಡ ಅವಧಿಗೆ, ಮತ್ತು ಕೆಲವು ಸಣ್ಣ ಶ್ರೇಣಿಗಳಿಗೆ ಅಲ್ಲ. ಮತ್ತು ಅಂತಹ ವಿನಂತಿಗಳು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸಮವಾಗಿ ಲೋಡ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ, ಇದು ತಾತ್ಕಾಲಿಕ ಪರಿಹಾರವಾಗಿದ್ದು, ಡೇಟಾವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸಮವಾಗಿ ಹರಡುವುದಿಲ್ಲ ಎಂದು ನಿಮ್ಮ ಹೇಳಿಕೆಯು ಸಂಪೂರ್ಣವಾಗಿ ಸರಿಯಾಗಿದೆ.
ನಿಮ್ಮ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಲು ನನ್ನ ಬಳಿ ಇನ್ನೂ ಕೆಲವು ಅಂಶಗಳಿವೆ. ಅವುಗಳಲ್ಲಿ ಒಂದು ಆರಂಭದಲ್ಲಿ ಷರ್ಡಿಂಗ್ ಸ್ಕೀಮ್ ಅನ್ನು ಹೇಗೆ ಮಾಡುವುದು, ಇದರಿಂದಾಗಿ ಮರು-ಶರ್ಡಿಂಗ್ ಕಡಿಮೆ ನೋವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಇದು ಯಾವಾಗಲೂ ಸಾಧ್ಯವಿಲ್ಲ.
ಉದಾಹರಣೆಗೆ, ನೀವು ಮಾನಿಟರಿಂಗ್ ಡೇಟಾವನ್ನು ಹೊಂದಿರುವಿರಿ. ಮಾನಿಟರಿಂಗ್ ಡೇಟಾ ಮೂರು ಕಾರಣಗಳಿಗಾಗಿ ಬೆಳೆಯುತ್ತಿದೆ. ಮೊದಲನೆಯದು ಐತಿಹಾಸಿಕ ದತ್ತಾಂಶಗಳ ಸಂಗ್ರಹವಾಗಿದೆ. ಎರಡನೆಯದು ಟ್ರಾಫಿಕ್ ಬೆಳವಣಿಗೆ. ಮತ್ತು ಮೂರನೆಯದು ಮೇಲ್ವಿಚಾರಣೆಗೆ ಒಳಪಟ್ಟಿರುವ ವಸ್ತುಗಳ ಸಂಖ್ಯೆಯಲ್ಲಿ ಹೆಚ್ಚಳವಾಗಿದೆ. ಹೊಸ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳು ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಉಳಿಸಬೇಕಾಗಿದೆ.
ಇವುಗಳಲ್ಲಿ, ದೊಡ್ಡ ಹೆಚ್ಚಳವು ಮೂರನೇ ಕಾರಣಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ - ಮೇಲ್ವಿಚಾರಣೆಯ ಬಳಕೆಯ ಹೆಚ್ಚಳ. ಮತ್ತು ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಲೋಡ್ನ ಸ್ವರೂಪವನ್ನು ನೋಡುವುದು ಯೋಗ್ಯವಾಗಿದೆ, ಆಯ್ಕೆಗಾಗಿ ಮುಖ್ಯ ವಿನಂತಿಗಳು ಯಾವುವು. ಮೂಲಭೂತ ಆಯ್ಕೆ ಪ್ರಶ್ನೆಗಳು ಮೆಟ್ರಿಕ್‌ಗಳ ಕೆಲವು ಉಪವಿಭಾಗಗಳನ್ನು ಆಧರಿಸಿರುತ್ತವೆ.
ಉದಾಹರಣೆಗೆ, ಕೆಲವು ಸೇವೆಯಿಂದ ಕೆಲವು ಸರ್ವರ್‌ಗಳಲ್ಲಿ CPU ಬಳಕೆ. ನೀವು ಈ ಡೇಟಾವನ್ನು ಪಡೆಯುವ ಕೀಗಳ ನಿರ್ದಿಷ್ಟ ಉಪವಿಭಾಗವಿದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಮತ್ತು ಈ ಡೇಟಾಕ್ಕಾಗಿ ವಿನಂತಿಯು ತುಂಬಾ ಸರಳವಾಗಿದೆ ಮತ್ತು ಹತ್ತಾರು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಲ್ಲಿ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ. ಮಾನಿಟರಿಂಗ್ ಸೇವೆಗಳು ಮತ್ತು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳಿಗಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ನಾನು ಇದನ್ನು ಸರಿಯಾಗಿ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.
ವ್ಲಾಡಿಮಿರ್ ಕೊಲೊಬೇವ್: ವಾಸ್ತವವೆಂದರೆ ನಾವು ಐತಿಹಾಸಿಕ ದತ್ತಾಂಶಗಳಿಗೆ ಆಗಾಗ್ಗೆ ಮನವಿ ಮಾಡುತ್ತೇವೆ, ಏಕೆಂದರೆ ನಾವು ಪ್ರಸ್ತುತ ಪರಿಸ್ಥಿತಿಯನ್ನು ಐತಿಹಾಸಿಕ ಪರಿಸ್ಥಿತಿಯೊಂದಿಗೆ ನೈಜ ಸಮಯದಲ್ಲಿ ಹೋಲಿಸುತ್ತೇವೆ. ಮತ್ತು ನಮಗೆ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಡೇಟಾಗೆ ತ್ವರಿತ ಪ್ರವೇಶವನ್ನು ಹೊಂದುವುದು ಮುಖ್ಯವಾಗಿದೆ ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್ ಇದರೊಂದಿಗೆ ಅತ್ಯುತ್ತಮವಾದ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತದೆ.
ನೀವು ಹೇಳುವುದು ಸಂಪೂರ್ಣವಾಗಿ ಸರಿ, ಯಾವುದೇ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್‌ನಂತೆ ನಾವು ಕೊನೆಯ ದಿನದಲ್ಲಿ ಹೆಚ್ಚಿನ ಓದುವ ವಿನಂತಿಗಳನ್ನು ಅನುಭವಿಸುತ್ತೇವೆ. ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ, ಐತಿಹಾಸಿಕ ದತ್ತಾಂಶದ ಮೇಲಿನ ಹೊರೆ ಸಹ ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿದೆ. ಇದು ಮೂಲಭೂತವಾಗಿ ಪ್ರತಿ ಮೂವತ್ತು ಸೆಕೆಂಡ್‌ಗಳಿಗೆ ಹೋಗುವ ಎಚ್ಚರಿಕೆಯ ವ್ಯವಸ್ಥೆಯಿಂದ ಬಂದಿದೆ ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಹೀಗೆ ಹೇಳುತ್ತದೆ: “ಕಳೆದ ಆರು ವಾರಗಳ ಡೇಟಾವನ್ನು ನನಗೆ ನೀಡಿ. ಈಗ ಅವುಗಳಿಂದ ನನಗೆ ಕೆಲವು ರೀತಿಯ ಚಲಿಸುವ ಸರಾಸರಿಯನ್ನು ನಿರ್ಮಿಸಿ ಮತ್ತು ಪ್ರಸ್ತುತ ಮೌಲ್ಯವನ್ನು ಐತಿಹಾಸಿಕ ಮೌಲ್ಯದೊಂದಿಗೆ ಹೋಲಿಸೋಣ.
ಅಂತಹ ಇತ್ತೀಚಿನ ವಿನಂತಿಗಳಿಗಾಗಿ ನಾವು ಇನ್ನೊಂದು ಸಣ್ಣ ಕೋಷ್ಟಕವನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದರಲ್ಲಿ ನಾವು ಕೇವಲ ಎರಡು ದಿನಗಳ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಮತ್ತು ಮುಖ್ಯ ವಿನಂತಿಗಳು ಅದರಲ್ಲಿ ಹಾರುತ್ತವೆ ಎಂದು ನಾನು ಹೇಳಲು ಬಯಸುತ್ತೇನೆ. ನಾವು ದೊಡ್ಡ ಐತಿಹಾಸಿಕ ಪ್ರಶ್ನೆಗಳನ್ನು ದೊಡ್ಡ ಚೂರುಗಳ ಟೇಬಲ್‌ಗೆ ಮಾತ್ರ ಕಳುಹಿಸುತ್ತೇವೆ.
ಅಲೆಕ್ಸಿ ಮಿಲೋವಿಡೋವ್: ದುರದೃಷ್ಟವಶಾತ್, ಇದು ನಿಮ್ಮ ಸನ್ನಿವೇಶದಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ, ಆದರೆ ನೀವು ಬಳಸಬೇಕಾಗಿಲ್ಲದ ಆದರೆ ನನ್ನ ಸ್ನೇಹಿತರ ಸೇವೆಯಲ್ಲಿ ಬಳಸಲಾಗುವ ಎರಡು ಕೆಟ್ಟ ಮತ್ತು ಸಂಕೀರ್ಣವಾದ ಹಂಚಿಕೆ ಯೋಜನೆಗಳನ್ನು ನಾನು ವಿವರಿಸುತ್ತೇನೆ.
Yandex.Metrica ಘಟನೆಗಳೊಂದಿಗೆ ಮುಖ್ಯ ಕ್ಲಸ್ಟರ್ ಇದೆ. ಈವೆಂಟ್‌ಗಳು ಪುಟ ವೀಕ್ಷಣೆಗಳು, ಕ್ಲಿಕ್‌ಗಳು ಮತ್ತು ಪರಿವರ್ತನೆಗಳಾಗಿವೆ. ಹೆಚ್ಚಿನ ವಿನಂತಿಗಳು ನಿರ್ದಿಷ್ಟ ವೆಬ್‌ಸೈಟ್‌ಗೆ ಹೋಗುತ್ತವೆ. ನೀವು Yandex.Metrica ಸೇವೆಯನ್ನು ತೆರೆಯಿರಿ, ನೀವು ವೆಬ್‌ಸೈಟ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ - avito.ru, ವರದಿಗೆ ಹೋಗಿ, ಮತ್ತು ನಿಮ್ಮ ವೆಬ್‌ಸೈಟ್‌ಗಾಗಿ ವಿನಂತಿಯನ್ನು ಮಾಡಲಾಗಿದೆ.
ಆದರೆ ಆಂತರಿಕ ವಿಶ್ಲೇಷಕರು ಮಾಡಿದ ಇತರ ವಿನಂತಿಗಳು - ವಿಶ್ಲೇಷಣಾತ್ಮಕ ಮತ್ತು ಜಾಗತಿಕ - ಇವೆ. ಒಂದು ವೇಳೆ, ಆಂತರಿಕ ವಿಶ್ಲೇಷಕರು ಯಾಂಡೆಕ್ಸ್ ಸೇವೆಗಳಿಗೆ ಮಾತ್ರ ವಿನಂತಿಗಳನ್ನು ಮಾಡುತ್ತಾರೆ ಎಂದು ನಾನು ಗಮನಿಸುತ್ತೇನೆ. ಆದರೆ ಅದೇನೇ ಇದ್ದರೂ, ಯಾಂಡೆಕ್ಸ್ ಸೇವೆಗಳು ಸಹ ಎಲ್ಲಾ ಡೇಟಾದ ಗಮನಾರ್ಹ ಪಾಲನ್ನು ಆಕ್ರಮಿಸುತ್ತವೆ. ಇವುಗಳು ನಿರ್ದಿಷ್ಟ ಕೌಂಟರ್‌ಗಳಿಗಾಗಿ ಅಲ್ಲ, ಆದರೆ ವಿಶಾಲವಾದ ಫಿಲ್ಟರಿಂಗ್‌ಗಾಗಿ ವಿನಂತಿಗಳಾಗಿವೆ.
ಜಾಗತಿಕ ಪ್ರಶ್ನೆಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಒಂದು ಕೌಂಟರ್‌ಗಾಗಿ ಎಲ್ಲವೂ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ರೀತಿಯಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಘಟಿಸುವುದು ಹೇಗೆ? ಮತ್ತೊಂದು ತೊಂದರೆ ಏನೆಂದರೆ, ಮೆಟ್ರಿಕ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಾಗಿ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿನ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಹಲವಾರು ಸಾವಿರ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಒಂದು ಕ್ಲಿಕ್‌ಹೌಸ್ ಸರ್ವರ್ ಕ್ಷುಲ್ಲಕವಲ್ಲದ ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಉದಾಹರಣೆಗೆ, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಹಲವಾರು ಸಾವಿರ.
ಕ್ಲಸ್ಟರ್ ಗಾತ್ರವು ಆರು ನೂರು-ಏನೋ ಸರ್ವರ್‌ಗಳು. ನೀವು ಈ ಕ್ಲಸ್ಟರ್‌ನ ಮೇಲೆ ವಿತರಣಾ ಕೋಷ್ಟಕವನ್ನು ಎಳೆದರೆ ಮತ್ತು ಅಲ್ಲಿಗೆ ಹಲವಾರು ಸಾವಿರ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸಿದರೆ, ಅವುಗಳನ್ನು ಒಂದು ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸುವುದಕ್ಕಿಂತ ಕೆಟ್ಟದಾಗಿರುತ್ತದೆ. ಮತ್ತೊಂದೆಡೆ, ಡೇಟಾವು ಸಮವಾಗಿ ಹರಡಿರುತ್ತದೆ ಮತ್ತು ನಾವು ಹೋಗಿ ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳಿಂದ ವಿನಂತಿಸುವ ಆಯ್ಕೆಯನ್ನು ತಕ್ಷಣವೇ ವಜಾಗೊಳಿಸಲಾಗುತ್ತದೆ.
ಸಂಪೂರ್ಣವಾಗಿ ವಿರುದ್ಧವಾಗಿರುವ ಒಂದು ಆಯ್ಕೆ ಇದೆ. ನಾವು ಸೈಟ್‌ಗಳಾದ್ಯಂತ ಡೇಟಾವನ್ನು ಹಂಚಿಕೊಂಡರೆ ಮತ್ತು ಒಂದು ಸೈಟ್‌ಗಾಗಿ ವಿನಂತಿಯು ಒಂದು ಚೂರುಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ಊಹಿಸಿ. ಈಗ ಕ್ಲಸ್ಟರ್ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಹತ್ತು ಸಾವಿರ ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಆದರೆ ಒಂದು ಚೂರುಗಳಲ್ಲಿ ಯಾವುದೇ ಒಂದು ವಿನಂತಿಯು ತುಂಬಾ ನಿಧಾನವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು ಇನ್ನು ಮುಂದೆ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ವಿಷಯದಲ್ಲಿ ಅಳೆಯುವುದಿಲ್ಲ. ವಿಶೇಷವಾಗಿ ಇದು ಸೈಟ್ avito.ru ಆಗಿದ್ದರೆ. RuNet ನಲ್ಲಿ ಹೆಚ್ಚು ಭೇಟಿ ನೀಡಿದ ಸೈಟ್‌ಗಳಲ್ಲಿ Avito ಒಂದಾಗಿದೆ ಎಂದು ನಾನು ಹೇಳಿದರೆ ನಾನು ರಹಸ್ಯವನ್ನು ಬಹಿರಂಗಪಡಿಸುವುದಿಲ್ಲ. ಮತ್ತು ಅದನ್ನು ಒಂದು ಚೂರುನಲ್ಲಿ ಸಂಸ್ಕರಿಸುವುದು ಹುಚ್ಚುತನವಾಗಿರುತ್ತದೆ.
ಆದ್ದರಿಂದ, ಶಾರ್ಡಿಂಗ್ ಯೋಜನೆಯನ್ನು ಹೆಚ್ಚು ಕುತಂತ್ರ ರೀತಿಯಲ್ಲಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹಲವಾರು ಕ್ಲಸ್ಟರ್ಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ, ಅದನ್ನು ನಾವು ಪದರಗಳು ಎಂದು ಕರೆಯುತ್ತೇವೆ. ಪ್ರತಿ ಕ್ಲಸ್ಟರ್ ಹತ್ತರಿಂದ ಹಲವಾರು ಡಜನ್ ಚೂರುಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಒಟ್ಟು ಮೂವತ್ತೊಂಬತ್ತು ಇಂತಹ ಸಮೂಹಗಳಿವೆ.
ಇದೆಲ್ಲವೂ ಹೇಗೆ ಅಳೆಯುತ್ತದೆ? ಸಮೂಹಗಳ ಸಂಖ್ಯೆಯು ಬದಲಾಗುವುದಿಲ್ಲ - ಕೆಲವು ವರ್ಷಗಳ ಹಿಂದೆ ಅದು ಮೂವತ್ತೊಂಬತ್ತು ಇದ್ದಂತೆ, ಅದು ಹಾಗೆಯೇ ಉಳಿದಿದೆ. ಆದರೆ ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದರಲ್ಲೂ, ಡೇಟಾ ಸಂಗ್ರಹವಾದಂತೆ ನಾವು ಚೂರುಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕ್ರಮೇಣ ಹೆಚ್ಚಿಸುತ್ತೇವೆ. ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಶೇರ್ಡಿಂಗ್ ಯೋಜನೆ ಹೀಗಿದೆ: ಈ ಕ್ಲಸ್ಟರ್‌ಗಳ ವಿಭಜನೆಯು ವೆಬ್‌ಸೈಟ್‌ಗಳಾದ್ಯಂತ ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ಯಾವ ಸೈಟ್ ಯಾವ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, MySQL ನಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಮೆಟಾಬೇಸ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಒಂದು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಒಂದು ಸೈಟ್. ಮತ್ತು ಅದರೊಳಗೆ, ಸಂದರ್ಶಕರ ID ಗಳ ಆಧಾರದ ಮೇಲೆ ಹಂಚಿಕೆ ಸಂಭವಿಸುತ್ತದೆ.
ರೆಕಾರ್ಡಿಂಗ್ ಮಾಡುವಾಗ, ಸಂದರ್ಶಕರ ID ಯ ಉಳಿದ ಭಾಗದಿಂದ ನಾವು ಅವುಗಳನ್ನು ಭಾಗಿಸುತ್ತೇವೆ. ಆದರೆ ನಾವು ಹೊಸ ಚೂರುಗಳನ್ನು ಸೇರಿಸಿದಾಗ, ಹಂಚುವಿಕೆಯ ಯೋಜನೆಯು ಬದಲಾಗುತ್ತದೆ, ನಾವು ವಿಭಜನೆಯನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ, ಆದರೆ ವಿಭಜನೆಯ ಉಳಿದ ಭಾಗವು ಮತ್ತೊಂದು ಸಂಖ್ಯೆಯಿಂದ. ಇದರರ್ಥ ಒಬ್ಬ ಸಂದರ್ಶಕರು ಈಗಾಗಲೇ ಹಲವಾರು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ನೆಲೆಸಿದ್ದಾರೆ ಮತ್ತು ನೀವು ಇದನ್ನು ಅವಲಂಬಿಸಲಾಗುವುದಿಲ್ಲ. ಡೇಟಾವನ್ನು ಉತ್ತಮವಾಗಿ ಸಂಕುಚಿತಗೊಳಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಇದನ್ನು ಮಾಡಲಾಗುತ್ತದೆ. ಮತ್ತು ಪ್ರಶ್ನೆಗಳನ್ನು ಮಾಡುವಾಗ, ನಾವು ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಟೇಬಲ್‌ಗೆ ಹೋಗುತ್ತೇವೆ, ಅದು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನೋಡುತ್ತದೆ ಮತ್ತು ಡಜನ್ಗಟ್ಟಲೆ ಸರ್ವರ್ಗಳನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ. ಇದು ಅಂತಹ ಮೂರ್ಖ ಯೋಜನೆಯಾಗಿದೆ.
ಆದರೆ ನಾವು ಈ ಯೋಜನೆಯನ್ನು ಕೈಬಿಟ್ಟಿದ್ದೇವೆ ಎಂದು ನಾನು ಹೇಳದಿದ್ದರೆ ನನ್ನ ಕಥೆ ಅಪೂರ್ಣವಾಗುತ್ತದೆ. ಹೊಸ ಯೋಜನೆಯಲ್ಲಿ, ನಾವು ಎಲ್ಲವನ್ನೂ ಬದಲಾಯಿಸಿದ್ದೇವೆ ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್-ಕಾಪಿಯರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ನಕಲಿಸಿದ್ದೇವೆ.
ಹೊಸ ಯೋಜನೆಯಲ್ಲಿ, ಎಲ್ಲಾ ಸೈಟ್ಗಳನ್ನು ಎರಡು ವರ್ಗಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ - ದೊಡ್ಡ ಮತ್ತು ಸಣ್ಣ. ಥ್ರೆಶೋಲ್ಡ್ ಅನ್ನು ಹೇಗೆ ಆರಿಸಲಾಗಿದೆ ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ, ಆದರೆ ಇದರ ಫಲಿತಾಂಶವೆಂದರೆ ಒಂದು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ದೊಡ್ಡ ಸೈಟ್ಗಳನ್ನು ದಾಖಲಿಸಲಾಗಿದೆ, ಅಲ್ಲಿ ತಲಾ ಮೂರು ಪ್ರತಿಕೃತಿಗಳೊಂದಿಗೆ 120 ಚೂರುಗಳಿವೆ - ಅಂದರೆ 360 ಸರ್ವರ್‌ಗಳು. ಮತ್ತು ಹಂಚಿಕೆ ಯೋಜನೆಯು ಯಾವುದೇ ವಿನಂತಿಯು ಎಲ್ಲಾ ಚೂರುಗಳಿಗೆ ಒಂದೇ ಬಾರಿಗೆ ಹೋಗುತ್ತದೆ. ನೀವು ಈಗ Yandex.Metrica ನಲ್ಲಿ avito.ru ಗಾಗಿ ಯಾವುದೇ ವರದಿ ಪುಟವನ್ನು ತೆರೆದರೆ, ವಿನಂತಿಯು 120 ಸರ್ವರ್‌ಗಳಿಗೆ ಹೋಗುತ್ತದೆ. RuNet ನಲ್ಲಿ ಕೆಲವು ದೊಡ್ಡ ಸೈಟ್‌ಗಳಿವೆ. ಮತ್ತು ವಿನಂತಿಗಳು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸಾವಿರವಲ್ಲ, ಆದರೆ ನೂರಕ್ಕಿಂತ ಕಡಿಮೆ. ವಿತರಣಾ ಕೋಷ್ಟಕದಿಂದ ಇದೆಲ್ಲವನ್ನೂ ಸದ್ದಿಲ್ಲದೆ ಅಗಿಯಲಾಗುತ್ತದೆ, ಪ್ರತಿಯೊಂದೂ 120 ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ.
ಮತ್ತು ಎರಡನೇ ಕ್ಲಸ್ಟರ್ ಸಣ್ಣ ಸೈಟ್ಗಳಿಗೆ ಆಗಿದೆ. ಸೈಟ್ ಐಡಿಯನ್ನು ಆಧರಿಸಿ ಶೇರ್ಡಿಂಗ್ ಸ್ಕೀಮ್ ಇಲ್ಲಿದೆ ಮತ್ತು ಪ್ರತಿ ವಿನಂತಿಯು ನಿಖರವಾಗಿ ಒಂದು ಶಾರ್ಡ್‌ಗೆ ಹೋಗುತ್ತದೆ.
ಕ್ಲಿಕ್‌ಹೌಸ್ ಕ್ಲಿಕ್‌ಹೌಸ್-ಕಾಪಿಯರ್ ಉಪಯುಕ್ತತೆಯನ್ನು ಹೊಂದಿದೆ. ನೀವು ಅವಳ ಬಗ್ಗೆ ನಮಗೆ ಹೇಳಬಹುದೇ?
ಈ ಪರಿಹಾರವು ಹೆಚ್ಚು ತೊಡಕಿನ ಮತ್ತು ಸ್ವಲ್ಪ ಕಡಿಮೆ ಉತ್ಪಾದಕವಾಗಿದೆ ಎಂದು ನಾನು ಈಗಿನಿಂದಲೇ ಹೇಳುತ್ತೇನೆ. ಪ್ರಯೋಜನವೆಂದರೆ ಅದು ನೀವು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಮಾದರಿಯ ಪ್ರಕಾರ ಡೇಟಾವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಮೀಯರ್ ಮಾಡುತ್ತದೆ. ಆದರೆ ಉಪಯುಕ್ತತೆಯ ನ್ಯೂನತೆಯೆಂದರೆ ಅದು ಮರುಹೊಂದಿಸುವುದಿಲ್ಲ. ಇದು ಒಂದು ಕ್ಲಸ್ಟರ್ ಸ್ಕೀಮಾದಿಂದ ಮತ್ತೊಂದು ಕ್ಲಸ್ಟರ್ ಸ್ಕೀಮಾಗೆ ಡೇಟಾವನ್ನು ನಕಲಿಸುತ್ತದೆ.
ಇದರರ್ಥ ಅದು ಕೆಲಸ ಮಾಡಲು ನೀವು ಎರಡು ಕ್ಲಸ್ಟರ್ಗಳನ್ನು ಹೊಂದಿರಬೇಕು. ಅವುಗಳನ್ನು ಒಂದೇ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಇರಿಸಬಹುದು, ಆದರೆ, ಆದಾಗ್ಯೂ, ಡೇಟಾವನ್ನು ಕ್ರಮೇಣವಾಗಿ ಸರಿಸಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ನಕಲಿಸಲಾಗುತ್ತದೆ.
ಉದಾಹರಣೆಗೆ, ನಾಲ್ಕು ಸರ್ವರ್‌ಗಳು ಇದ್ದವು, ಈಗ ಎಂಟು ಇವೆ. ನೀವು ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳು, ಹೊಸ ಸ್ಥಳೀಯ ಕೋಷ್ಟಕಗಳಲ್ಲಿ ಹೊಸ ವಿತರಣಾ ಕೋಷ್ಟಕವನ್ನು ರಚಿಸುತ್ತೀರಿ ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್-ಕಾಪಿಯರ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿ, ಅದರಲ್ಲಿ ಕೆಲಸದ ಯೋಜನೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಅದು ಅಲ್ಲಿಂದ ಓದಬೇಕು, ಹೊಸ ಶಾರ್ಡಿಂಗ್ ಸ್ಕೀಮ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿ ಮತ್ತು ಡೇಟಾವನ್ನು ಅಲ್ಲಿಗೆ ವರ್ಗಾಯಿಸಬೇಕು. ಮತ್ತು ಹಳೆಯ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ನಿಮಗೆ ಈಗ ಇರುವುದಕ್ಕಿಂತ ಒಂದೂವರೆ ಪಟ್ಟು ಹೆಚ್ಚು ಸ್ಥಳಾವಕಾಶ ಬೇಕಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಹಳೆಯ ಡೇಟಾವು ಅವುಗಳ ಮೇಲೆ ಉಳಿಯಬೇಕು ಮತ್ತು ಅದೇ ಹಳೆಯ ಡೇಟಾದ ಅರ್ಧದಷ್ಟು ಅವುಗಳ ಮೇಲೆ ಬರುತ್ತದೆ. ಡೇಟಾವನ್ನು ಮರುಹಂಚಿಕೆ ಮಾಡಬೇಕಾಗಿದೆ ಮತ್ತು ಸ್ಥಳಾವಕಾಶವಿದೆ ಎಂದು ನೀವು ಮುಂಚಿತವಾಗಿ ಯೋಚಿಸಿದರೆ, ಈ ವಿಧಾನವು ಸೂಕ್ತವಾಗಿದೆ.
ಕ್ಲಿಕ್‌ಹೌಸ್-ಕಾಪಿಯರ್ ಒಳಗೆ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ? ಒಂದು ಚೂರುಗಳ ಮೇಲೆ ಒಂದು ಟೇಬಲ್‌ನ ಒಂದು ವಿಭಾಗವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಇದು ಎಲ್ಲಾ ಕೆಲಸವನ್ನು ಕಾರ್ಯಗಳ ಗುಂಪಾಗಿ ವಿಭಜಿಸುತ್ತದೆ. ಈ ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ನಿರ್ವಹಿಸಬಹುದು, ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್-ಕಾಪಿಯರ್ ಅನ್ನು ಹಲವಾರು ನಿದರ್ಶನಗಳಲ್ಲಿ ವಿವಿಧ ಗಣಕಗಳಲ್ಲಿ ಚಲಾಯಿಸಬಹುದು, ಆದರೆ ಒಂದು ಬ್ಯಾಚ್‌ಗೆ ಅದು ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದು ಇನ್ಸರ್ಟ್ ಆಯ್ಕೆಗಿಂತ ಹೆಚ್ಚೇನೂ ಅಲ್ಲ. ಡೇಟಾವನ್ನು ಓದಲಾಗುತ್ತದೆ, ಡಿಕಂಪ್ರೆಸ್ ಮಾಡಲಾಗುತ್ತದೆ, ಮರುವಿಭಾಗಗೊಳಿಸಲಾಗುತ್ತದೆ, ನಂತರ ಮತ್ತೆ ಸಂಕುಚಿತಗೊಳಿಸಲಾಗುತ್ತದೆ, ಎಲ್ಲೋ ಬರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಮರು-ವಿಂಗಡಿಸಲಾಗುತ್ತದೆ. ಇದು ಕಠಿಣ ನಿರ್ಧಾರ.
ನೀವು ರೀಶಾರ್ಡ್ ಎಂಬ ಪೈಲಟ್ ವಿಷಯವನ್ನು ಹೊಂದಿದ್ದೀರಿ. ಅವಳೊಂದಿಗೆ ಏನು?
2017 ರಲ್ಲಿ, ನೀವು ರೀಶಾರ್ಡ್ ಎಂಬ ಪೈಲಟ್ ವಿಷಯವನ್ನು ಹೊಂದಿದ್ದೀರಿ. ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಒಂದು ಆಯ್ಕೆಯೂ ಇದೆ. ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, ಅದು ಹೊರಡಲಿಲ್ಲ. ಇದು ಏಕೆ ಸಂಭವಿಸಿತು ಎಂದು ನೀವು ನನಗೆ ಹೇಳಬಲ್ಲಿರಾ? ಇದು ತುಂಬಾ ಪ್ರಸ್ತುತವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ.
ಸಂಪೂರ್ಣ ಸಮಸ್ಯೆಯೆಂದರೆ, ಡೇಟಾವನ್ನು ಮರುಹೊಂದಿಸಲು ಅಗತ್ಯವಾದಾಗ, ಪರಮಾಣುವಾಗಿ ಇದನ್ನು ಮಾಡಲು ಬಹಳ ಸಂಕೀರ್ಣವಾದ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅಗತ್ಯವಿದೆ. ಈ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಮೂಲಭೂತ ಸಮಸ್ಯೆಗಳಿವೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಯಿತು. ಮತ್ತು ಈ ಮೂಲಭೂತ ಸಮಸ್ಯೆಗಳು ಕೇವಲ ಸೈದ್ಧಾಂತಿಕವಲ್ಲ, ಆದರೆ ತಕ್ಷಣವೇ ಸರಳವಾಗಿ ವಿವರಿಸಬಹುದಾದ ಯಾವುದನ್ನಾದರೂ ರೂಪದಲ್ಲಿ ಆಚರಣೆಯಲ್ಲಿ ತೋರಿಸಲು ಪ್ರಾರಂಭಿಸಿದವು - ಏನೂ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.
ನಿಧಾನವಾದ ಡಿಸ್ಕ್ಗಳಿಗೆ ಚಲಿಸುವ ಮೊದಲು ಎಲ್ಲಾ ಡೇಟಾ ತುಣುಕುಗಳನ್ನು ಒಟ್ಟಿಗೆ ವಿಲೀನಗೊಳಿಸಲು ಸಾಧ್ಯವೇ?
ವಿಲೀನದ ಸಂದರ್ಭದಲ್ಲಿ ನಿಧಾನವಾದ ಡಿಸ್ಕ್ ಆಯ್ಕೆಯೊಂದಿಗೆ TTL ಕುರಿತು ಪ್ರಶ್ನೆ. ನಿಧಾನವಾದ ಡಿಸ್ಕ್ಗಳಿಗೆ ಚಲಿಸುವ ಮೊದಲು ಎಲ್ಲಾ ಭಾಗಗಳನ್ನು ಒಂದಾಗಿ ವಿಲೀನಗೊಳಿಸಲು ಕ್ರಾನ್ ಅನ್ನು ಬಳಸದೆ ಬೇರೆ ಮಾರ್ಗವಿದೆಯೇ?
ಎಲ್ಲಾ ತುಣುಕುಗಳನ್ನು ವರ್ಗಾಯಿಸುವ ಮೊದಲು ಹೇಗಾದರೂ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅಂಟಿಸಲು ಸಾಧ್ಯವೇ ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರ ಇಲ್ಲ. ಇದು ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ. ನೀವು ಎಲ್ಲಾ ಭಾಗಗಳನ್ನು ಒಂದರೊಳಗೆ ವಿಲೀನಗೊಳಿಸಬೇಕಾಗಿಲ್ಲ, ಆದರೆ ಅವುಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿಧಾನವಾದ ಡಿಸ್ಕ್ಗಳಿಗೆ ವರ್ಗಾಯಿಸುವುದನ್ನು ಎಣಿಸಿ.
ವರ್ಗಾವಣೆ ನಿಯಮಗಳಿಗೆ ನಾವು ಎರಡು ಮಾನದಂಡಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮೊದಲನೆಯದು ತುಂಬುವಿಕೆಯನ್ನು ಆಧರಿಸಿದೆ. ಪ್ರಸ್ತುತ ಸಂಗ್ರಹಣೆಯ ಮಟ್ಟವು ನಿರ್ದಿಷ್ಟ ಶೇಕಡಾವಾರು ಉಚಿತ ಸ್ಥಳಕ್ಕಿಂತ ಕಡಿಮೆಯಿದ್ದರೆ, ನಾವು ಒಂದು ತುಣುಕನ್ನು ಆಯ್ಕೆಮಾಡಿ ಮತ್ತು ಅದನ್ನು ನಿಧಾನವಾದ ಸಂಗ್ರಹಣೆಗೆ ಸರಿಸುತ್ತೇವೆ. ಅಥವಾ ಬದಲಿಗೆ, ನಿಧಾನವಾಗಿ ಅಲ್ಲ, ಆದರೆ ಮುಂದಿನದು, ನೀವು ಅದನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದಂತೆ.
ಎರಡನೇ ಮಾನದಂಡವು ಗಾತ್ರವಾಗಿದೆ. ಇದು ದೊಡ್ಡ ತುಂಡುಗಳನ್ನು ಒಯ್ಯುವುದು. ವೇಗದ ಡಿಸ್ಕ್ನಲ್ಲಿನ ಮುಕ್ತ ಜಾಗವನ್ನು ಆಧರಿಸಿ ನೀವು ಮಿತಿಯನ್ನು ಸರಿಹೊಂದಿಸಬಹುದು ಮತ್ತು ಡೇಟಾವನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ.
ಹೊಂದಾಣಿಕೆಯನ್ನು ಮುಂಚಿತವಾಗಿ ಪರಿಶೀಲಿಸಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲದಿದ್ದರೆ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಹೊಸ ಆವೃತ್ತಿಗಳಿಗೆ ಹೇಗೆ ವಲಸೆ ಹೋಗುವುದು?
ಈ ವಿಷಯವನ್ನು ನಿಯಮಿತವಾಗಿ ಚರ್ಚಿಸಲಾಗುತ್ತದೆ ವಿಭಿನ್ನ ಆವೃತ್ತಿಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು, ಮತ್ತು ಇನ್ನೂ. ಆವೃತ್ತಿ 19.11 ರಿಂದ 19.16 ಕ್ಕೆ ಮತ್ತು ಉದಾಹರಣೆಗೆ, 19.16 ರಿಂದ 20.3 ಕ್ಕೆ ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡುವುದು ಎಷ್ಟು ಸುರಕ್ಷಿತವಾಗಿದೆ. ಮುಂಚಿತವಾಗಿ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಹೊಂದಾಣಿಕೆಯನ್ನು ಪರಿಶೀಲಿಸಲು ಸಾಧ್ಯವಾಗದೆ ಹೊಸ ಆವೃತ್ತಿಗಳಿಗೆ ಸರಿಸಲು ಉತ್ತಮ ಮಾರ್ಗ ಯಾವುದು?
ಇಲ್ಲಿ ಹಲವಾರು "ಗೋಲ್ಡನ್" ನಿಯಮಗಳಿವೆ. ಪ್ರಥಮ - . ಇದು ದೊಡ್ಡದಾಗಿದೆ, ಆದರೆ ಹಿಂದಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗದ ಬದಲಾವಣೆಗಳ ಬಗ್ಗೆ ಪ್ರತ್ಯೇಕ ಪ್ಯಾರಾಗಳು ಇವೆ. ಈ ಬಿಂದುಗಳನ್ನು ಕೆಂಪು ಧ್ವಜ ಎಂದು ಪರಿಗಣಿಸಬೇಡಿ. ಇವುಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಚಿಕ್ಕ ಅಸಾಮರಸ್ಯಗಳಾಗಿದ್ದು, ನೀವು ಬಳಸದಿರುವ ಕೆಲವು ಅಂಚಿನ ಕ್ರಿಯಾತ್ಮಕತೆಗೆ ಸಂಬಂಧಿಸಿರುತ್ತವೆ.
ಎರಡನೆಯದಾಗಿ, ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಹೊಂದಾಣಿಕೆಯನ್ನು ಪರಿಶೀಲಿಸಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲದಿದ್ದರೆ ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿ ನೀವು ತಕ್ಷಣ ನವೀಕರಿಸಲು ಬಯಸಿದರೆ, ನೀವು ಇದನ್ನು ಮಾಡಬೇಕಾಗಿಲ್ಲ ಎಂಬುದು ಶಿಫಾರಸು. ಮೊದಲು ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಅನ್ನು ರಚಿಸಿ ಮತ್ತು ಪರೀಕ್ಷಿಸಿ. ಯಾವುದೇ ಪರೀಕ್ಷಾ ವಾತಾವರಣವಿಲ್ಲದಿದ್ದರೆ, ನೀವು ಹೆಚ್ಚಾಗಿ ದೊಡ್ಡ ಕಂಪನಿಯನ್ನು ಹೊಂದಿಲ್ಲ, ಅಂದರೆ ನೀವು ಕೆಲವು ಡೇಟಾವನ್ನು ನಿಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್‌ಗೆ ನಕಲಿಸಬಹುದು ಮತ್ತು ಅದರಲ್ಲಿ ಎಲ್ಲವೂ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ನಿಮ್ಮ ಗಣಕದಲ್ಲಿ ಸ್ಥಳೀಯವಾಗಿ ಹಲವಾರು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಸಹ ನೀವು ಹೆಚ್ಚಿಸಬಹುದು. ಅಥವಾ ನೀವು ಎಲ್ಲೋ ಹತ್ತಿರದ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಮತ್ತು ಅಲ್ಲಿ ಕೆಲವು ಡೇಟಾವನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡಬಹುದು - ಅಂದರೆ, ಸುಧಾರಿತ ಪರೀಕ್ಷಾ ಪರಿಸರವನ್ನು ರಚಿಸಿ.
ಉತ್ಪಾದನೆಯಲ್ಲಿನ ದೋಷಗಳು ಮತ್ತು ನಂತರದ ತ್ವರಿತ ಪರಿಹಾರಗಳಿಂದಾಗಿ ಆವೃತ್ತಿಯ ಬಿಡುಗಡೆಯ ನಂತರ ಒಂದು ವಾರದವರೆಗೆ ನವೀಕರಿಸದಿರುವುದು ಮತ್ತೊಂದು ನಿಯಮವಾಗಿದೆ. ಗೊಂದಲಕ್ಕೀಡಾಗದಂತೆ ಕ್ಲಿಕ್‌ಹೌಸ್ ಆವೃತ್ತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ.
ಆವೃತ್ತಿ 20.3.4 ಇದೆ. ಸಂಖ್ಯೆ 20 ಉತ್ಪಾದನೆಯ ವರ್ಷವನ್ನು ಸೂಚಿಸುತ್ತದೆ - 2020. ಒಳಗಿರುವ ದೃಷ್ಟಿಕೋನದಿಂದ, ಇದು ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ನಾವು ಇದಕ್ಕೆ ಗಮನ ಕೊಡುವುದಿಲ್ಲ. ಮುಂದಿನದು 20.3. ನಾವು ಎರಡನೇ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತೇವೆ - ಈ ಸಂದರ್ಭದಲ್ಲಿ 3 - ಪ್ರತಿ ಬಾರಿ ನಾವು ಕೆಲವು ಹೊಸ ಕ್ರಿಯಾತ್ಮಕತೆಯೊಂದಿಗೆ ಬಿಡುಗಡೆಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡುತ್ತೇವೆ. ನಾವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಯಾವುದೇ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಸೇರಿಸಲು ಬಯಸಿದರೆ, ನಾವು ಈ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸಬೇಕು. ಅಂದರೆ, ಆವೃತ್ತಿ 20.4 ನಲ್ಲಿ ಕ್ಲಿಕ್‌ಹೌಸ್ ಇನ್ನೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಮೂರನೇ ಅಂಕಿಯು 20.3.4 ಆಗಿದೆ. ಇಲ್ಲಿ 4 ಪ್ಯಾಚ್ ಬಿಡುಗಡೆಗಳ ಸಂಖ್ಯೆ, ಇದರಲ್ಲಿ ನಾವು ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸೇರಿಸಲಿಲ್ಲ, ಆದರೆ ಕೆಲವು ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಿದ್ದೇವೆ. ಮತ್ತು 4 ಎಂದರೆ ನಾವು ಅದನ್ನು ನಾಲ್ಕು ಬಾರಿ ಮಾಡಿದ್ದೇವೆ.
ಇದು ಭಯಾನಕ ವಿಷಯ ಎಂದು ಭಾವಿಸಬೇಡಿ. ವಿಶಿಷ್ಟವಾಗಿ, ಬಳಕೆದಾರರು ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಯನ್ನು ಸ್ಥಾಪಿಸಬಹುದು ಮತ್ತು ಇದು ವರ್ಷಕ್ಕೆ ಅಪ್ಟೈಮ್ನೊಂದಿಗೆ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆದರೆ ನಮ್ಮ ಚೀನೀ ಒಡನಾಡಿಗಳಿಂದ ಸೇರಿಸಲ್ಪಟ್ಟ ಬಿಟ್‌ಮ್ಯಾಪ್‌ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಕೆಲವು ಕಾರ್ಯದಲ್ಲಿ, ತಪ್ಪಾದ ವಾದಗಳನ್ನು ರವಾನಿಸುವಾಗ ಸರ್ವರ್ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ ಎಂದು ಊಹಿಸಿ. ಇದನ್ನು ಸರಿಪಡಿಸುವ ಜವಾಬ್ದಾರಿ ನಮ್ಮ ಮೇಲಿದೆ. ನಾವು ಹೊಸ ಪ್ಯಾಚ್ ಆವೃತ್ತಿಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್ ಹೆಚ್ಚು ಸ್ಥಿರವಾಗಿರುತ್ತದೆ.
ನೀವು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಕ್ಲಿಕ್‌ಹೌಸ್ ಚಾಲನೆಯಲ್ಲಿದ್ದರೆ ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯು ಹೆಚ್ಚುವರಿ ವೈಶಿಷ್ಟ್ಯಗಳೊಂದಿಗೆ ಹೊರಬಂದರೆ - ಉದಾಹರಣೆಗೆ, 20.4.1 ಮೊದಲನೆಯದು, ಮೊದಲ ದಿನದಲ್ಲಿ ಅದನ್ನು ಉತ್ಪಾದನೆಗೆ ಹಾಕಲು ಹೊರದಬ್ಬಬೇಡಿ. ಅದು ಏಕೆ ಬೇಕು? ನೀವು ಈಗಾಗಲೇ ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಬಳಸದಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಸ್ಥಾಪಿಸಬಹುದು ಮತ್ತು ಹೆಚ್ಚಾಗಿ ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿರುತ್ತದೆ. ಆದರೆ ಕ್ಲಿಕ್‌ಹೌಸ್ ಈಗಾಗಲೇ ಸ್ಥಿರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, ನಾವು ಯಾವ ಸಮಸ್ಯೆಗಳನ್ನು ಸರಿಪಡಿಸುತ್ತಿದ್ದೇವೆ ಎಂಬುದನ್ನು ನೋಡಲು ಪ್ಯಾಚ್‌ಗಳು ಮತ್ತು ನವೀಕರಣಗಳ ಮೇಲೆ ಕಣ್ಣಿಟ್ಟಿರಿ.
ಕಿರಿಲ್ ಶ್ವಾಕೋವ್: ಪರೀಕ್ಷಾ ಪರಿಸರಗಳ ಬಗ್ಗೆ ನಾನು ಸ್ವಲ್ಪ ಸೇರಿಸಲು ಬಯಸುತ್ತೇನೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ಪರೀಕ್ಷಾ ಪರಿಸರದ ಬಗ್ಗೆ ತುಂಬಾ ಹೆದರುತ್ತಾರೆ ಮತ್ತು ಕೆಲವು ಕಾರಣಗಳಿಂದಾಗಿ ನೀವು ತುಂಬಾ ದೊಡ್ಡ ಕ್ಲಿಕ್‌ಹೌಸ್ ಕ್ಲಸ್ಟರ್ ಹೊಂದಿದ್ದರೆ, ಪರೀಕ್ಷಾ ಪರಿಸರವು ಕಡಿಮೆ ಅಥವಾ ಕನಿಷ್ಠ ಹತ್ತು ಪಟ್ಟು ಚಿಕ್ಕದಾಗಿರಬೇಕು ಎಂದು ಅವರು ನಂಬುತ್ತಾರೆ. ಅದು ಹಾಗಲ್ಲ.
ನನ್ನ ಸ್ವಂತ ಉದಾಹರಣೆಯಿಂದ ನಾನು ನಿಮಗೆ ಹೇಳಬಲ್ಲೆ. ನನ್ನ ಬಳಿ ಪ್ರಾಜೆಕ್ಟ್ ಇದೆ, ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್ ಇದೆ. ಅವನಿಗಾಗಿ ನಮ್ಮ ಪರೀಕ್ಷಾ ಪರಿಸರವು ಇಪ್ಪತ್ತು ಯೂರೋಗಳಿಗೆ ಹೆಟ್ಜ್ನರ್‌ನಲ್ಲಿ ಒಂದು ಸಣ್ಣ ವರ್ಚುವಲ್ ಯಂತ್ರವಾಗಿದೆ, ಅಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಎಲ್ಲವನ್ನೂ ನಿಯೋಜಿಸಲಾಗಿದೆ. ಇದನ್ನು ಮಾಡಲು, ನಾವು ಅನ್ಸಿಬಲ್‌ನಲ್ಲಿ ಸಂಪೂರ್ಣ ಯಾಂತ್ರೀಕೃತಗೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಆದ್ದರಿಂದ, ತಾತ್ವಿಕವಾಗಿ, ಎಲ್ಲಿಗೆ ಹೋಗಬೇಕು - ಹಾರ್ಡ್‌ವೇರ್ ಸರ್ವರ್‌ಗಳಿಗೆ ಅಥವಾ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಲ್ಲಿ ನಿಯೋಜಿಸಲು ಯಾವುದೇ ವ್ಯತ್ಯಾಸವಿಲ್ಲ.
ಏನು ಮಾಡಬಹುದು? ನಿಮ್ಮದೇ ಆದ ಒಂದು ಸಣ್ಣ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೇಗೆ ನಿಯೋಜಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಕ್ಲಿಕ್‌ಹೌಸ್ ದಾಖಲಾತಿಯಲ್ಲಿ ಉದಾಹರಣೆಯನ್ನು ನೀಡುವುದು ಒಳ್ಳೆಯದು - ಡಾಕರ್‌ನಲ್ಲಿ, ಎಲ್‌ಎಕ್ಸ್‌ಸಿಯಲ್ಲಿ, ಬಹುಶಃ ಅನ್ಸಿಬಲ್ ಪ್ಲೇಬುಕ್ ಅನ್ನು ರಚಿಸಿ, ಏಕೆಂದರೆ ವಿಭಿನ್ನ ಜನರು ವಿಭಿನ್ನ ನಿಯೋಜನೆಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ. ಇದು ಬಹಳಷ್ಟು ಸರಳಗೊಳಿಸುತ್ತದೆ. ನೀವು ಐದು ನಿಮಿಷಗಳಲ್ಲಿ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡು ನಿಯೋಜಿಸಿದಾಗ, ಏನನ್ನಾದರೂ ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುವುದು ತುಂಬಾ ಸುಲಭ. ಇದು ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿದೆ, ಏಕೆಂದರೆ ನೀವು ಪರಿಶೀಲಿಸದ ಉತ್ಪಾದನಾ ಆವೃತ್ತಿಗೆ ರೋಲಿಂಗ್ ಮಾಡುವುದು ಎಲ್ಲಿಯೂ ಇಲ್ಲದಿರುವ ಮಾರ್ಗವಾಗಿದೆ. ಕೆಲವೊಮ್ಮೆ ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಅದು ಮಾಡುವುದಿಲ್ಲ. ಮತ್ತು ಆದ್ದರಿಂದ, ಯಶಸ್ಸಿನ ಭರವಸೆ ಕೆಟ್ಟದು.
ಮ್ಯಾಕ್ಸಿಮ್ ಕೋಟ್ಯಾಕೋವ್, ಹಿರಿಯ ಬ್ಯಾಕೆಂಡ್ ಎಂಜಿನಿಯರ್ ಅವಿಟೊ: ದೊಡ್ಡ ಕಂಪನಿಗಳಿಗೆ ಸಮಸ್ಯೆಗಳ ಸರಣಿಯಿಂದ ಪರೀಕ್ಷಾ ಪರಿಸರದ ಬಗ್ಗೆ ನಾನು ಸ್ವಲ್ಪ ಸೇರಿಸುತ್ತೇನೆ. ನಾವು ಪೂರ್ಣ ಪ್ರಮಾಣದ ಕ್ಲಿಕ್‌ಹೌಸ್ ಸ್ವೀಕಾರ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಡೇಟಾ ಸ್ಕೀಮಾಗಳು ಮತ್ತು ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಉತ್ಪಾದನೆಯಲ್ಲಿರುವುದರ ನಿಖರವಾದ ನಕಲು. ಈ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಕನಿಷ್ಠ ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ಹಳೆಯ ಧಾರಕಗಳಲ್ಲಿ ನಿಯೋಜಿಸಲಾಗಿದೆ. ನಾವು ಅಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಶೇಕಡಾವಾರು ಉತ್ಪಾದನಾ ಡೇಟಾವನ್ನು ಬರೆಯುತ್ತೇವೆ, ಅದೃಷ್ಟವಶಾತ್ ಕಾಫ್ಕಾದಲ್ಲಿ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಪುನರಾವರ್ತಿಸಲು ಸಾಧ್ಯವಿದೆ. ಅಲ್ಲಿರುವ ಎಲ್ಲವನ್ನೂ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಸ್ಕೇಲ್ ಮಾಡಲಾಗಿದೆ - ಶಕ್ತಿಯ ವಿಷಯದಲ್ಲಿ ಮತ್ತು ಹರಿವಿನ ಪರಿಭಾಷೆಯಲ್ಲಿ, ಮತ್ತು, ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಎಲ್ಲಾ ಇತರ ವಿಷಯಗಳು ಸಮಾನವಾಗಿರುತ್ತವೆ, ಮೆಟ್ರಿಕ್‌ಗಳ ವಿಷಯದಲ್ಲಿ ಉತ್ಪಾದನೆಯಂತೆ ವರ್ತಿಸಬೇಕು. ಸಂಭಾವ್ಯ ಸ್ಫೋಟಕ ಎಲ್ಲವನ್ನೂ ಮೊದಲು ಈ ಸ್ಟ್ಯಾಂಡ್‌ಗೆ ಸುತ್ತಿಕೊಳ್ಳಲಾಗುತ್ತದೆ ಮತ್ತು ಅದು ಸಿದ್ಧವಾಗುವವರೆಗೆ ಹಲವಾರು ದಿನಗಳವರೆಗೆ ಬಿಡಲಾಗುತ್ತದೆ. ಆದರೆ ಸ್ವಾಭಾವಿಕವಾಗಿ, ಈ ಪರಿಹಾರವು ದುಬಾರಿಯಾಗಿದೆ, ಕಷ್ಟಕರವಾಗಿದೆ ಮತ್ತು ಶೂನ್ಯವಲ್ಲದ ಬೆಂಬಲ ವೆಚ್ಚಗಳೊಂದಿಗೆ.
ಅಲೆಕ್ಸಿ ಮಿಲೋವಿಡೋವ್: Yandex.Metrica ನಿಂದ ನಮ್ಮ ಸ್ನೇಹಿತರ ಪರೀಕ್ಷಾ ವಾತಾವರಣವು ಹೇಗಿದೆ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ. ಒಂದು ಕ್ಲಸ್ಟರ್ 600-ಬೆಸ ಸರ್ವರ್ಗಳನ್ನು ಹೊಂದಿತ್ತು, ಇನ್ನೊಂದು 360 ಅನ್ನು ಹೊಂದಿತ್ತು ಮತ್ತು ಮೂರನೇ ಮತ್ತು ಹಲವಾರು ಕ್ಲಸ್ಟರ್‌ಗಳಿವೆ. ಅವುಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಪರೀಕ್ಷಾ ಪರಿಸರವು ಕೇವಲ ಎರಡು ಚೂರುಗಳು ಪ್ರತಿ ಎರಡು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಹೊಂದಿದೆ. ಎರಡು ಚೂರುಗಳು ಏಕೆ? ಆದ್ದರಿಂದ ನೀವು ಒಬ್ಬಂಟಿಯಾಗಿಲ್ಲ. ಮತ್ತು ಪ್ರತಿಕೃತಿಗಳೂ ಇರಬೇಕು. ನೀವು ನಿಭಾಯಿಸಬಹುದಾದ ಒಂದು ನಿರ್ದಿಷ್ಟ ಕನಿಷ್ಠ ಮೊತ್ತ.
ಈ ಪರೀಕ್ಷಾ ಪರಿಸರವು ನಿಮ್ಮ ಪ್ರಶ್ನೆಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿವೆಯೇ ಮತ್ತು ಯಾವುದಾದರೂ ಪ್ರಮುಖವಾದವು ಮುರಿದುಹೋಗಿವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಆದರೆ ಆಗಾಗ್ಗೆ ಸಮಸ್ಯೆಗಳು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಸ್ವಭಾವದ ಉದ್ಭವಿಸುತ್ತವೆ, ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುವಾಗ, ಆದರೆ ಲೋಡ್ನೊಂದಿಗೆ ಕೆಲವು ಸಣ್ಣ ಬದಲಾವಣೆಗಳಿವೆ.
ಒಂದು ಉದಾಹರಣೆ ಕೊಡುತ್ತೇನೆ. ನಾವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಸ್ಥಾಪಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಇದನ್ನು ಪರೀಕ್ಷಾ ಪರಿಸರದಲ್ಲಿ ಪೋಸ್ಟ್ ಮಾಡಲಾಗಿದೆ, Yandex.Metrica ನಲ್ಲಿಯೇ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಲಾಗಿದೆ, ಇದು ಹಳೆಯ ಆವೃತ್ತಿ ಮತ್ತು ಹೊಸದರಲ್ಲಿ ಡೇಟಾವನ್ನು ಹೋಲಿಸುತ್ತದೆ, ಸಂಪೂರ್ಣ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತದೆ. ಮತ್ತು ಸಹಜವಾಗಿ, ನಮ್ಮ CI ನ ಹಸಿರು ಪರೀಕ್ಷೆಗಳು. ಇಲ್ಲದಿದ್ದರೆ ನಾವು ಈ ಆವೃತ್ತಿಯನ್ನು ಪ್ರಸ್ತಾಪಿಸುತ್ತಿರಲಿಲ್ಲ.
ಎಲ್ಲವು ಚೆನ್ನಾಗಿದೆ. ನಾವು ಉತ್ಪಾದನೆಗೆ ಹೋಗಲು ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದೇವೆ. ಗ್ರಾಫ್‌ಗಳಲ್ಲಿನ ಲೋಡ್ ಹಲವಾರು ಬಾರಿ ಹೆಚ್ಚಾಗಿದೆ ಎಂಬ ಸಂದೇಶವನ್ನು ನಾನು ಸ್ವೀಕರಿಸುತ್ತೇನೆ. ನಾವು ಆವೃತ್ತಿಯನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತಿದ್ದೇವೆ. ನಾನು ಗ್ರಾಫ್ ಅನ್ನು ನೋಡುತ್ತೇನೆ ಮತ್ತು ನೋಡುತ್ತೇನೆ: ರೋಲ್‌ಔಟ್ ಸಮಯದಲ್ಲಿ ಲೋಡ್ ವಾಸ್ತವವಾಗಿ ಹಲವಾರು ಬಾರಿ ಹೆಚ್ಚಾಯಿತು ಮತ್ತು ಅದನ್ನು ಉರುಳಿಸಿದಾಗ ಮತ್ತೆ ಕಡಿಮೆಯಾಯಿತು. ನಂತರ ನಾವು ಆವೃತ್ತಿಯನ್ನು ಹಿಂತಿರುಗಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಮತ್ತು ಲೋಡ್ ಅದೇ ರೀತಿಯಲ್ಲಿ ಹೆಚ್ಚಾಯಿತು ಮತ್ತು ಅದೇ ರೀತಿಯಲ್ಲಿ ಹಿಂತಿರುಗಿತು. ಆದ್ದರಿಂದ ತೀರ್ಮಾನವು ಹೀಗಿದೆ: ಲೇಔಟ್ ಕಾರಣದಿಂದಾಗಿ ಲೋಡ್ ಹೆಚ್ಚಾಗಿದೆ, ಆಶ್ಚರ್ಯವೇನಿಲ್ಲ.
ನಂತರ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಸ್ಥಾಪಿಸಲು ಸಹೋದ್ಯೋಗಿಗಳನ್ನು ಮನವೊಲಿಸುವುದು ಕಷ್ಟಕರವಾಗಿತ್ತು. ನಾನು ಹೇಳುತ್ತೇನೆ: "ಇದು ಪರವಾಗಿಲ್ಲ, ಹೊರತೆಗೆಯಿರಿ. ನಿಮ್ಮ ಬೆರಳುಗಳನ್ನು ಅಡ್ಡಲಾಗಿ ಇರಿಸಿ, ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಈಗ ಗ್ರಾಫ್‌ಗಳಲ್ಲಿ ಲೋಡ್ ಹೆಚ್ಚಾಗಿದೆ, ಆದರೆ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ. ಅಲ್ಲಿಯೇ ಇರಿ." ಸಾಮಾನ್ಯವಾಗಿ, ನಾವು ಇದನ್ನು ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಅದು ಇಲ್ಲಿದೆ - ಆವೃತ್ತಿಯನ್ನು ಉತ್ಪಾದನಾ ಸೈಟ್‌ನಲ್ಲಿ ಪೋಸ್ಟ್ ಮಾಡಲಾಗಿದೆ. ಆದರೆ ಪ್ರತಿಯೊಂದು ವಿನ್ಯಾಸದಲ್ಲೂ ಇದೇ ರೀತಿಯ ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸುತ್ತವೆ.
ಪ್ರಶ್ನೆಯನ್ನು ಕೊಲ್ಲುವುದು ಪ್ರಶ್ನೆಗಳನ್ನು ಕೊಲ್ಲುತ್ತದೆ, ಆದರೆ ಅದು ಮಾಡುವುದಿಲ್ಲ. ಏಕೆ?
ಒಬ್ಬ ಬಳಕೆದಾರರು, ಕೆಲವು ರೀತಿಯ ವಿಶ್ಲೇಷಕರು, ನನ್ನ ಬಳಿಗೆ ಬಂದು ನನ್ನ ಕ್ಲಿಕ್‌ಹೌಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹಾಕುವ ವಿನಂತಿಯನ್ನು ರಚಿಸಿದರು. ಕೆಲವು ನೋಡ್ ಅಥವಾ ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್, ವಿನಂತಿಯು ಯಾವ ಪ್ರತಿಕೃತಿ ಅಥವಾ ಚೂರುಗಳಿಗೆ ಹೋಗಿದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ. ಈ ಸರ್ವರ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ CPU ಸಂಪನ್ಮೂಲಗಳು ಶೆಲ್ಫ್‌ನಲ್ಲಿವೆ ಎಂದು ನಾನು ನೋಡುತ್ತೇನೆ, ಎಲ್ಲವೂ ಕೆಂಪು ಬಣ್ಣದ್ದಾಗಿದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಕ್ಲಿಕ್‌ಹೌಸ್ ಸ್ವತಃ ವಿನಂತಿಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ. ಮತ್ತು ನಾನು ಬರೆಯುತ್ತೇನೆ: "ದಯವಿಟ್ಟು ನನಗೆ ತೋರಿಸಿ, ಪ್ರಕ್ರಿಯೆ ಪಟ್ಟಿ, ಯಾವ ವಿನಂತಿಯು ಈ ಹುಚ್ಚುತನವನ್ನು ಸೃಷ್ಟಿಸಿದೆ."
ನಾನು ಈ ವಿನಂತಿಯನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇನೆ ಮತ್ತು ಅದನ್ನು ಕೊಲ್ಲಲು ಬರೆಯುತ್ತೇನೆ. ಮತ್ತು ಏನೂ ಆಗುತ್ತಿಲ್ಲ ಎಂದು ನಾನು ನೋಡುತ್ತೇನೆ. ನನ್ನ ಸರ್ವರ್ ಶೆಲ್ಫ್‌ನಲ್ಲಿದೆ, ಕ್ಲಿಕ್‌ಹೌಸ್ ನಂತರ ನನಗೆ ಕೆಲವು ಆಜ್ಞೆಗಳನ್ನು ನೀಡುತ್ತದೆ, ಸರ್ವರ್ ಜೀವಂತವಾಗಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ ಮತ್ತು ಎಲ್ಲವೂ ಅದ್ಭುತವಾಗಿದೆ. ಆದರೆ ನಾನು ಎಲ್ಲಾ ಬಳಕೆದಾರರ ವಿನಂತಿಗಳಲ್ಲಿ ಅವನತಿ ಹೊಂದಿದ್ದೇನೆ, ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿನ ದಾಖಲೆಗಳಲ್ಲಿ ಅವನತಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ನನ್ನ ಕಿಲ್ ಪ್ರಶ್ನೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಏಕೆ? ಪ್ರಶ್ನೆಗಳನ್ನು ಕೊಲ್ಲುವುದು ಪ್ರಶ್ನೆಗಳನ್ನು ಕೊಲ್ಲುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸಿದೆ, ಆದರೆ ಅದು ಹಾಗಲ್ಲ.
ಈಗ ಬದಲಿಗೆ ವಿಚಿತ್ರ ಉತ್ತರ ಇರುತ್ತದೆ. ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೊಲ್ಲುವುದು ಪ್ರಶ್ನೆಗಳನ್ನು ಕೊಲ್ಲುವುದಿಲ್ಲ.
ಕಿಲ್ ಪ್ರಶ್ನೆಯು "ಈ ಪ್ರಶ್ನೆಯನ್ನು ಕೊಲ್ಲಬೇಕೆಂದು ನಾನು ಬಯಸುತ್ತೇನೆ" ಎಂಬ ಪುಟ್ಟ ಪೆಟ್ಟಿಗೆಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಮತ್ತು ಪ್ರತಿ ಬ್ಲಾಕ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವಾಗ ವಿನಂತಿಯು ಸ್ವತಃ ಈ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ನೋಡುತ್ತದೆ. ಅದನ್ನು ಹೊಂದಿಸಿದರೆ, ವಿನಂತಿಯು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ವಿನಂತಿಯನ್ನು ಯಾರೂ ಕೊಲ್ಲುವುದಿಲ್ಲ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ, ಅವನು ಸ್ವತಃ ಎಲ್ಲವನ್ನೂ ಪರಿಶೀಲಿಸಬೇಕು ಮತ್ತು ನಿಲ್ಲಿಸಬೇಕು. ಮತ್ತು ವಿನಂತಿಯು ಡೇಟಾದ ಬ್ಲಾಕ್ಗಳನ್ನು ಸಂಸ್ಕರಿಸುವ ಸ್ಥಿತಿಯಲ್ಲಿದ್ದ ಎಲ್ಲಾ ಸಂದರ್ಭಗಳಲ್ಲಿ ಇದು ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು. ಇದು ಡೇಟಾದ ಮುಂದಿನ ಬ್ಲಾಕ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ, ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು ನಿಲ್ಲಿಸುತ್ತದೆ.
ಕೆಲವು ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ವಿನಂತಿಯನ್ನು ನಿರ್ಬಂಧಿಸಿದ ಸಂದರ್ಭಗಳಲ್ಲಿ ಇದು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ನಿಜ, ಹೆಚ್ಚಾಗಿ ಇದು ನಿಮ್ಮ ಪ್ರಕರಣವಲ್ಲ, ಏಕೆಂದರೆ, ನಿಮ್ಮ ಪ್ರಕಾರ, ಇದು ಒಂದು ಟನ್ ಸರ್ವರ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತದೆ. ಬಾಹ್ಯ ವಿಂಗಡಣೆಯ ಸಂದರ್ಭದಲ್ಲಿ ಮತ್ತು ಇತರ ಕೆಲವು ವಿವರಗಳಲ್ಲಿ ಇದು ಕಾರ್ಯನಿರ್ವಹಿಸದಿರುವ ಸಾಧ್ಯತೆಯಿದೆ. ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಇದು ಸಂಭವಿಸಬಾರದು, ಇದು ದೋಷವಾಗಿದೆ. ಮತ್ತು ನಾನು ಶಿಫಾರಸು ಮಾಡಬಹುದಾದ ಏಕೈಕ ವಿಷಯವೆಂದರೆ ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ನವೀಕರಿಸುವುದು.
ಓದುವ ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ಹೇಗೆ ಲೆಕ್ಕ ಹಾಕುವುದು?
ಐಟಂ ಮೂಲಕ ಒಟ್ಟುಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಟೇಬಲ್ ಇದೆ - ವಿವಿಧ ಕೌಂಟರ್‌ಗಳು. ಸಾಲುಗಳ ಸಂಖ್ಯೆ ಸುಮಾರು ನೂರು ಮಿಲಿಯನ್. ನೀವು 1K ಐಟಂಗಳ ಮೇಲೆ 1K RPS ಅನ್ನು ಸುರಿದರೆ ಊಹಿಸಬಹುದಾದ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ಲೆಕ್ಕಹಾಕಲು ಸಾಧ್ಯವೇ?
ಸಂದರ್ಭದ ಮೂಲಕ ನಿರ್ಣಯಿಸುವುದು, ನಾವು ಓದುವ ಲೋಡ್ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ, ಏಕೆಂದರೆ ಬರವಣಿಗೆಯಲ್ಲಿ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲ - ಸಾವಿರ, ಒಂದು ನೂರು ಸಾವಿರ, ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಹಲವಾರು ಮಿಲಿಯನ್ ಸಾಲುಗಳನ್ನು ಸೇರಿಸಬಹುದು.
ಓದುವ ವಿನಂತಿಗಳು ತುಂಬಾ ವಿಭಿನ್ನವಾಗಿವೆ. ಆಯ್ಕೆ 1 ರಲ್ಲಿ, ಕ್ಲಿಕ್‌ಹೌಸ್ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸುಮಾರು ಹತ್ತು ಸಾವಿರ ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸಬಹುದು, ಆದ್ದರಿಂದ ಒಂದು ಕೀಲಿಗಾಗಿ ವಿನಂತಿಗಳಿಗೆ ಸಹ ಈಗಾಗಲೇ ಕೆಲವು ಸಂಪನ್ಮೂಲಗಳು ಬೇಕಾಗುತ್ತವೆ. ಮತ್ತು ಅಂತಹ ಪಾಯಿಂಟ್ ಪ್ರಶ್ನೆಗಳು ಕೆಲವು ಪ್ರಮುಖ ಮೌಲ್ಯದ ಡೇಟಾಬೇಸ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ, ಏಕೆಂದರೆ ಪ್ರತಿ ಓದುವಿಕೆಗೆ ಸೂಚ್ಯಂಕದ ಮೂಲಕ ಡೇಟಾದ ಬ್ಲಾಕ್ ಅನ್ನು ಓದುವುದು ಅವಶ್ಯಕ. ನಮ್ಮ ಸೂಚ್ಯಂಕವು ಪ್ರತಿ ದಾಖಲೆಯಲ್ಲ, ಆದರೆ ಪ್ರತಿ ಶ್ರೇಣಿಯನ್ನು ತಿಳಿಸುತ್ತದೆ. ಅಂದರೆ, ನೀವು ಸಂಪೂರ್ಣ ಶ್ರೇಣಿಯನ್ನು ಓದಬೇಕಾಗುತ್ತದೆ - ಇದು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ 8192 ಸಾಲುಗಳು. ಮತ್ತು ನೀವು ಸಂಕುಚಿತ ಡೇಟಾ ಬ್ಲಾಕ್ ಅನ್ನು 64 KB ನಿಂದ 1 MB ವರೆಗೆ ಡಿಕಂಪ್ರೆಸ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ವಿಶಿಷ್ಟವಾಗಿ, ಅಂತಹ ಪಾಯಿಂಟ್ ವಿನಂತಿಗಳು ಕೆಲವು ಮಿಲಿಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ. ಆದರೆ ಇದು ಸರಳವಾದ ಆಯ್ಕೆಯಾಗಿದೆ.
ಕೆಲವು ಸರಳ ಅಂಕಗಣಿತವನ್ನು ಪ್ರಯತ್ನಿಸೋಣ. ನೀವು ಕೆಲವು ಮಿಲಿಸೆಕೆಂಡುಗಳನ್ನು ಸಾವಿರದಿಂದ ಗುಣಿಸಿದರೆ, ನೀವು ಕೆಲವು ಸೆಕೆಂಡುಗಳನ್ನು ಪಡೆಯುತ್ತೀರಿ. ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸಾವಿರ ವಿನಂತಿಗಳನ್ನು ಇಡುವುದು ಅಸಾಧ್ಯವೆಂದು ತೋರುತ್ತದೆ, ಆದರೆ ವಾಸ್ತವವಾಗಿ ಇದು ಸಾಧ್ಯ, ಏಕೆಂದರೆ ನಾವು ಹಲವಾರು ಪ್ರೊಸೆಸರ್ ಕೋರ್ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಆದ್ದರಿಂದ, ತಾತ್ವಿಕವಾಗಿ, ಕ್ಲಿಕ್‌ಹೌಸ್ ಕೆಲವೊಮ್ಮೆ 1000 RPS ಅನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಬಹುದು, ಆದರೆ ಸಣ್ಣ ವಿನಂತಿಗಳಿಗಾಗಿ, ನಿರ್ದಿಷ್ಟವಾಗಿ ಗುರಿಪಡಿಸಲಾಗಿದೆ.
ನೀವು ಕ್ಲಿಕ್‌ಹೌಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸರಳ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯಿಂದ ಅಳೆಯಬೇಕಾದರೆ, ನಾನು ಸರಳವಾದ ವಿಷಯವನ್ನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ - ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸಿ ಮತ್ತು ಯಾದೃಚ್ಛಿಕ ಪ್ರತಿಕೃತಿಗೆ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸಿ. ಒಂದು ಪ್ರತಿಕೃತಿಯು ಸೆಕೆಂಡಿಗೆ ಐನೂರು ವಿನಂತಿಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದು ಸಂಪೂರ್ಣವಾಗಿ ವಾಸ್ತವಿಕವಾಗಿದೆ, ನಂತರ ಮೂರು ಪ್ರತಿಕೃತಿಗಳು ಒಂದೂವರೆ ಸಾವಿರವನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುತ್ತವೆ.
ಕೆಲವೊಮ್ಮೆ, ಸಹಜವಾಗಿ, ನೀವು ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಪಾಯಿಂಟ್ ರೀಡಿಂಗ್‌ಗಳಿಗಾಗಿ ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. ಇದಕ್ಕೆ ಏನು ಬೇಕು? ಮೊದಲನೆಯದು ಸೂಚ್ಯಂಕದ ಗ್ರ್ಯಾನ್ಯುಲಾರಿಟಿಯನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಅದನ್ನು ಒಂದಕ್ಕೆ ಕಡಿಮೆ ಮಾಡಬಾರದು, ಆದರೆ ಸೂಚ್ಯಂಕದಲ್ಲಿನ ದಾಖಲೆಗಳ ಸಂಖ್ಯೆಯು ಪ್ರತಿ ಸರ್ವರ್‌ಗೆ ಹಲವಾರು ಮಿಲಿಯನ್ ಅಥವಾ ಹತ್ತಾರು ಮಿಲಿಯನ್ ಆಗಿರುತ್ತದೆ ಎಂಬ ಲೆಕ್ಕಾಚಾರದ ಆಧಾರದ ಮೇಲೆ. ಒಂದು ಕೋಷ್ಟಕದಲ್ಲಿ ನೂರು ಮಿಲಿಯನ್ ಸಾಲುಗಳಿದ್ದರೆ, ಗ್ರ್ಯಾನ್ಯುಲಾರಿಟಿಯನ್ನು 64 ಕ್ಕೆ ಹೊಂದಿಸಬಹುದು.
ಸಂಕುಚಿತ ಬ್ಲಾಕ್ನ ಗಾತ್ರವನ್ನು ನೀವು ಕಡಿಮೆ ಮಾಡಬಹುದು. ಇದಕ್ಕಾಗಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿವೆ ನಿಮಿಷ ಸಂಕುಚಿತ ಬ್ಲಾಕ್ ಗಾತ್ರ, ಗರಿಷ್ಠ ಸಂಕುಚಿತ ಬ್ಲಾಕ್ ಗಾತ್ರ. ಅವುಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು, ಡೇಟಾದೊಂದಿಗೆ ಮರುಪೂರಣ ಮಾಡಬಹುದು ಮತ್ತು ನಂತರ ಉದ್ದೇಶಿತ ಪ್ರಶ್ನೆಗಳು ವೇಗವಾಗಿರುತ್ತವೆ. ಆದರೆ ಇನ್ನೂ, ClickHouse ಒಂದು ಪ್ರಮುಖ ಮೌಲ್ಯದ ಡೇಟಾಬೇಸ್ ಅಲ್ಲ. ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಣ್ಣ ವಿನಂತಿಗಳು ಲೋಡ್ ಆಂಟಿಪ್ಯಾಟರ್ನ್ ಆಗಿದೆ.
ಕಿರಿಲ್ ಶ್ವಾಕೋವ್: ಅಲ್ಲಿ ಸಾಮಾನ್ಯ ಖಾತೆಗಳಿದ್ದರೆ ನಾನು ಸಲಹೆ ನೀಡುತ್ತೇನೆ. ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಕೆಲವು ರೀತಿಯ ಕೌಂಟರ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಿದಾಗ ಇದು ಸಾಕಷ್ಟು ಪ್ರಮಾಣಿತ ಪರಿಸ್ಥಿತಿಯಾಗಿದೆ. ನಾನು ಬಳಕೆದಾರರನ್ನು ಹೊಂದಿದ್ದೇನೆ, ಅವನು ಅಂತಹ ಮತ್ತು ಅಂತಹ ದೇಶದಿಂದ ಬಂದವನು, ಕೆಲವು ಮೂರನೇ ಕ್ಷೇತ್ರ, ಮತ್ತು ನಾನು ಏನನ್ನಾದರೂ ಹೆಚ್ಚಿಸಬೇಕಾಗಿದೆ. MySQL ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ, ಅನನ್ಯ ಕೀಲಿಯನ್ನು ಮಾಡಿ - MySQL ನಲ್ಲಿ ಇದು ನಕಲಿ ಕೀ, ಮತ್ತು PostgreSQL ನಲ್ಲಿ ಇದು ಸಂಘರ್ಷವಾಗಿದೆ - ಮತ್ತು ಪ್ಲಸ್ ಚಿಹ್ನೆಯನ್ನು ಸೇರಿಸಿ. ಇದು ಹೆಚ್ಚು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ನೀವು ಹೆಚ್ಚು ಡೇಟಾ ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಬಳಸುವುದರಲ್ಲಿ ಹೆಚ್ಚಿನ ಅರ್ಥವಿಲ್ಲ. ನಿಯಮಿತ ಡೇಟಾಬೇಸ್‌ಗಳಿವೆ ಮತ್ತು ಅವರು ಇದನ್ನು ಉತ್ತಮವಾಗಿ ಮಾಡುತ್ತಾರೆ.
ಹೆಚ್ಚಿನ ಡೇಟಾ ಸಂಗ್ರಹದಲ್ಲಿರಲು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ನಾನು ಏನು ತಿರುಚಬಹುದು?
ಪರಿಸ್ಥಿತಿಯನ್ನು ಊಹಿಸೋಣ - ಸರ್ವರ್‌ಗಳು 256 GB RAM ಅನ್ನು ಹೊಂದಿದ್ದು, ದೈನಂದಿನ ದಿನಚರಿಯಲ್ಲಿ ClickHouse ಸುಮಾರು 60-80 GB ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಗರಿಷ್ಠ - 130 ವರೆಗೆ. ಏನು ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು ಮತ್ತು ಟ್ವೀಕ್ ಮಾಡಬಹುದು ಆದ್ದರಿಂದ ಹೆಚ್ಚಿನ ಡೇಟಾ ಸಂಗ್ರಹದಲ್ಲಿದೆ ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಡಿಸ್ಕ್‌ಗೆ ಕಡಿಮೆ ಪ್ರಯಾಣಗಳಿವೆಯೇ?
ವಿಶಿಷ್ಟವಾಗಿ, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನ ಪುಟ ಸಂಗ್ರಹವು ಈ ಕಾರ್ಯದ ಉತ್ತಮ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತದೆ. ನೀವು ಕೇವಲ ಮೇಲಿನ ಪುಟವನ್ನು ತೆರೆದರೆ, ಅಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿದೆ ಅಥವಾ ಮುಕ್ತವಾಗಿ ನೋಡಿ - ಅದು ಎಷ್ಟು ಸಂಗ್ರಹವಾಗಿದೆ ಎಂದು ಸಹ ಹೇಳುತ್ತದೆ - ನಂತರ ಎಲ್ಲಾ ಉಚಿತ ಮೆಮೊರಿಯನ್ನು ಸಂಗ್ರಹಕ್ಕಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ ಎಂದು ನೀವು ಗಮನಿಸಬಹುದು. ಮತ್ತು ಈ ಡೇಟಾವನ್ನು ಓದಿದಾಗ, ಡಿಸ್ಕ್ನಿಂದ ಅಲ್ಲ, ಆದರೆ RAM ನಿಂದ ಓದಲಾಗುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಕ್ಯಾಶ್ ಅನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ ಎಂದು ನಾನು ಹೇಳಬಲ್ಲೆ ಏಕೆಂದರೆ ಅದು ಸಂಗ್ರಹವಾಗಿರುವ ಸಂಕುಚಿತ ಡೇಟಾ.
ಆದಾಗ್ಯೂ, ನೀವು ಕೆಲವು ಸರಳ ಪ್ರಶ್ನೆಗಳನ್ನು ಇನ್ನಷ್ಟು ವೇಗಗೊಳಿಸಲು ಬಯಸಿದರೆ, ಡಿಕಂಪ್ರೆಸ್ಡ್ ಡೇಟಾದಲ್ಲಿ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು ಒಂದು ಆಯ್ಕೆ ಇದೆ. ಇದನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ಸಂಕ್ಷೇಪಿಸದ ಸಂಗ್ರಹ. config.xml ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ನಲ್ಲಿ, ಸಂಕ್ಷೇಪಿಸದ ಸಂಗ್ರಹ ಗಾತ್ರವನ್ನು ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಮೌಲ್ಯಕ್ಕೆ ಹೊಂದಿಸಿ - ಉಚಿತ RAM ನ ಅರ್ಧಕ್ಕಿಂತ ಹೆಚ್ಚಿನದನ್ನು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ, ಏಕೆಂದರೆ ಉಳಿದವು ಪುಟ ಸಂಗ್ರಹದ ಅಡಿಯಲ್ಲಿ ಹೋಗುತ್ತದೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಎರಡು ವಿನಂತಿ ಮಟ್ಟದ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿವೆ. ಮೊದಲ ಸೆಟ್ಟಿಂಗ್ - ಸಂಕ್ಷೇಪಿಸದ ಸಂಗ್ರಹವನ್ನು ಬಳಸಿ - ಅದರ ಬಳಕೆಯನ್ನು ಒಳಗೊಂಡಿದೆ. ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಓದಲು ಮತ್ತು ಸಂಗ್ರಹವನ್ನು ಫ್ಲಶ್ ಮಾಡುವ ಭಾರೀ ಪದಗಳಿಗಿಂತ ಹೊರತುಪಡಿಸಿ, ಎಲ್ಲಾ ವಿನಂತಿಗಳಿಗೆ ಅದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ. ಮತ್ತು ಎರಡನೇ ಸೆಟ್ಟಿಂಗ್ ಕ್ಯಾಶ್ ಬಳಕೆಗಾಗಿ ಗರಿಷ್ಟ ಸಂಖ್ಯೆಯ ಸಾಲುಗಳಂತಿದೆ. ಇದು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ದೊಡ್ಡ ಪ್ರಶ್ನೆಗಳನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ ಇದರಿಂದ ಅವು ಸಂಗ್ರಹವನ್ನು ಬೈಪಾಸ್ ಮಾಡುತ್ತವೆ.
RAM ನಲ್ಲಿ ಶೇಖರಣೆಗಾಗಿ ನಾನು storage_configuration ಅನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು?
ಹೊಸ ClickHouse ದಸ್ತಾವೇಜನ್ನು ನಾನು ಸಂಬಂಧಿಸಿದ ವಿಭಾಗವನ್ನು ಓದಿದ್ದೇನೆ . ವಿವರಣೆಯು ವೇಗದ SSD ಯೊಂದಿಗೆ ಉದಾಹರಣೆಯನ್ನು ಒಳಗೊಂಡಿದೆ.
ವಾಲ್ಯೂಮ್ ಹಾಟ್ ಮೆಮೊರಿಯೊಂದಿಗೆ ಅದನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು ಎಂದು ನಾನು ಆಶ್ಚರ್ಯ ಪಡುತ್ತೇನೆ. ಮತ್ತು ಇನ್ನೂ ಒಂದು ಪ್ರಶ್ನೆ. ಆಯ್ಕೆಯು ಈ ಡೇಟಾ ಸಂಸ್ಥೆಯೊಂದಿಗೆ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಅದು ಸಂಪೂರ್ಣ ಸೆಟ್ ಅನ್ನು ಓದುತ್ತದೆ ಅಥವಾ ಡಿಸ್ಕ್ನಲ್ಲಿರುವ ಒಂದನ್ನು ಮಾತ್ರ ಓದುತ್ತದೆ ಮತ್ತು ಈ ಡೇಟಾವನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಸಂಕುಚಿತಗೊಳಿಸಲಾಗಿದೆಯೇ? ಮತ್ತು ಅಂತಹ ಡೇಟಾ ಸಂಸ್ಥೆಯೊಂದಿಗೆ ಪ್ರಿವೇರ್ ವಿಭಾಗವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ?
ಈ ಸೆಟ್ಟಿಂಗ್ ಡೇಟಾ ಭಾಗಗಳ ಸಂಗ್ರಹಣೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಮತ್ತು ಅವುಗಳ ಸ್ವರೂಪವು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಬದಲಾಗುವುದಿಲ್ಲ.
ಹತ್ತಿರದಿಂದ ನೋಡೋಣ.
ನೀವು RAM ನಲ್ಲಿ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. ಡಿಸ್ಕ್‌ಗಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿರುವುದು ಅದರ ಮಾರ್ಗವಾಗಿದೆ. ನೀವು ಫೈಲ್ ಸಿಸ್ಟಂನಲ್ಲಿ ಕೆಲವು ಮಾರ್ಗಕ್ಕೆ ಜೋಡಿಸಲಾದ tmpfs ವಿಭಾಗವನ್ನು ರಚಿಸುತ್ತೀರಿ. ಹಾಟೆಸ್ಟ್ ವಿಭಾಗಕ್ಕಾಗಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವ ಮಾರ್ಗವಾಗಿ ನೀವು ಈ ಮಾರ್ಗವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೀರಿ, ಡೇಟಾದ ತುಣುಕುಗಳು ಬರಲು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿ ಬರೆಯಲಾಗುತ್ತದೆ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ.
ಆದರೆ ಕಡಿಮೆ ವಿಶ್ವಾಸಾರ್ಹತೆಯಿಂದಾಗಿ ಇದನ್ನು ಮಾಡಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುವುದಿಲ್ಲ, ಆದರೂ ನೀವು ವಿಭಿನ್ನ ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಕನಿಷ್ಠ ಮೂರು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದು ಸಾಧ್ಯ. ಏನಾದರೂ ಸಂಭವಿಸಿದಲ್ಲಿ, ಡೇಟಾವನ್ನು ಮರುಸ್ಥಾಪಿಸಲಾಗುತ್ತದೆ. ಸರ್ವರ್ ಅನ್ನು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಆಫ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಮತ್ತೆ ಆನ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ಊಹಿಸೋಣ. ವಿಭಜನೆಯನ್ನು ಮತ್ತೆ ಜೋಡಿಸಲಾಗಿದೆ, ಆದರೆ ಅಲ್ಲಿ ಏನೂ ಇರಲಿಲ್ಲ. ಕ್ಲಿಕ್‌ಹೌಸ್ ಸರ್ವರ್ ಪ್ರಾರಂಭವಾದಾಗ, ಅದು ಈ ತುಣುಕುಗಳನ್ನು ಹೊಂದಿಲ್ಲ ಎಂದು ನೋಡುತ್ತದೆ, ಆದಾಗ್ಯೂ, ZooKeeper ಮೆಟಾಡೇಟಾ ಪ್ರಕಾರ, ಅವುಗಳು ಇರಬೇಕು. ಅವರು ಯಾವ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ ಎಂಬುದನ್ನು ನೋಡುತ್ತಾರೆ, ಅವುಗಳನ್ನು ವಿನಂತಿಸುತ್ತಾರೆ ಮತ್ತು ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತಾರೆ. ಈ ರೀತಿಯಲ್ಲಿ ಡೇಟಾವನ್ನು ಮರುಸ್ಥಾಪಿಸಲಾಗುತ್ತದೆ.
ಈ ಅರ್ಥದಲ್ಲಿ, RAM ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಡಿಸ್ಕ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುವುದಕ್ಕಿಂತ ಮೂಲಭೂತವಾಗಿ ಭಿನ್ನವಾಗಿರುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಡೇಟಾವನ್ನು ಡಿಸ್ಕ್‌ಗೆ ಬರೆಯುವಾಗ, ಅದು ಮೊದಲು ಪುಟದ ಸಂಗ್ರಹದಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ನಂತರ ಭೌತಿಕವಾಗಿ ಬರೆಯಲಾಗುತ್ತದೆ. ಇದು ಫೈಲ್ ಸಿಸ್ಟಮ್ ಮೌಂಟ್ ಆಯ್ಕೆಯನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಆದರೆ ಒಂದು ವೇಳೆ, ಸೇರಿಸುವಾಗ ಕ್ಲಿಕ್‌ಹೌಸ್ fsync ಮಾಡುವುದಿಲ್ಲ ಎಂದು ನಾನು ಹೇಳುತ್ತೇನೆ.
ಈ ಸಂದರ್ಭದಲ್ಲಿ, RAM ನಲ್ಲಿನ ಡೇಟಾವನ್ನು ಡಿಸ್ಕ್ನಲ್ಲಿರುವ ಅದೇ ಸ್ವರೂಪದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಆಯ್ದ ಪ್ರಶ್ನೆಯು ಅದೇ ರೀತಿಯಲ್ಲಿ ಓದಬೇಕಾದ ತುಣುಕುಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ತುಣುಕುಗಳಲ್ಲಿ ಅಗತ್ಯವಾದ ಡೇಟಾ ಶ್ರೇಣಿಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಓದುತ್ತದೆ. ಮತ್ತು ಡೇಟಾವು RAM ಅಥವಾ ಡಿಸ್ಕ್‌ನಲ್ಲಿದೆಯೇ ಎಂಬುದನ್ನು ಲೆಕ್ಕಿಸದೆಯೇ ಪ್ರಿವೇರ್ ನಿಖರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಕಡಿಮೆ ಕಾರ್ಡಿನಾಲಿಟಿ ಎಷ್ಟು ವಿಶಿಷ್ಟ ಮೌಲ್ಯಗಳವರೆಗೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ?
ಕಡಿಮೆ ಕಾರ್ಡಿನಾಲಿಟಿಯನ್ನು ಬುದ್ಧಿವಂತಿಕೆಯಿಂದ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಇದು ಡೇಟಾ ನಿಘಂಟುಗಳನ್ನು ಕಂಪೈಲ್ ಮಾಡುತ್ತದೆ, ಆದರೆ ಅವು ಸ್ಥಳೀಯವಾಗಿವೆ. ಮೊದಲನೆಯದಾಗಿ, ಪ್ರತಿ ತುಣುಕಿಗೆ ವಿಭಿನ್ನ ನಿಘಂಟುಗಳಿವೆ, ಮತ್ತು ಎರಡನೆಯದಾಗಿ, ಒಂದು ತುಣುಕಿನೊಳಗೆ ಸಹ ಅವು ಪ್ರತಿ ಶ್ರೇಣಿಗೆ ವಿಭಿನ್ನವಾಗಿರಬಹುದು. ಅನನ್ಯ ಮೌಲ್ಯಗಳ ಸಂಖ್ಯೆಯು ಮಿತಿ ಸಂಖ್ಯೆಯನ್ನು ತಲುಪಿದಾಗ - ಒಂದು ಮಿಲಿಯನ್, ನಾನು ಭಾವಿಸುತ್ತೇನೆ - ನಿಘಂಟನ್ನು ಸರಳವಾಗಿ ಸ್ಥಗಿತಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಹೊಸದನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ.
ಉತ್ತರವು ಸಾಮಾನ್ಯವಾಗಿದೆ: ಪ್ರತಿ ಸ್ಥಳೀಯ ಶ್ರೇಣಿಗೆ - ಹೇಳಲು, ಪ್ರತಿ ದಿನಕ್ಕೆ - ಎಲ್ಲೋ ಒಂದು ಮಿಲಿಯನ್ ಅನನ್ಯ ಮೌಲ್ಯಗಳು, ಕಡಿಮೆ ಕಾರ್ಡಿನಾಲಿಟಿ ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ. ನಂತರ ಕೇವಲ ಒಂದು ಫಾಲ್ಬ್ಯಾಕ್ ಇರುತ್ತದೆ, ಇದರಲ್ಲಿ ಹಲವಾರು ವಿಭಿನ್ನ ನಿಘಂಟುಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಕೇವಲ ಒಂದಲ್ಲ. ಇದು ಸರಿಸುಮಾರು ಸಾಮಾನ್ಯ ಸ್ಟ್ರಿಂಗ್ ಕಾಲಮ್‌ನಂತೆಯೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಬಹುಶಃ ಸ್ವಲ್ಪ ಕಡಿಮೆ ದಕ್ಷತೆ ಇರುತ್ತದೆ, ಆದರೆ ಯಾವುದೇ ಗಂಭೀರ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅವನತಿ ಇರುವುದಿಲ್ಲ.
ಐದು ಬಿಲಿಯನ್ ಸಾಲುಗಳನ್ನು ಹೊಂದಿರುವ ಟೇಬಲ್ ಅನ್ನು ಪೂರ್ಣ-ಪಠ್ಯವನ್ನು ಹುಡುಕಲು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು ಯಾವುವು?
ವಿಭಿನ್ನ ಉತ್ತರಗಳಿವೆ. ಕ್ಲಿಕ್‌ಹೌಸ್ ಪೂರ್ಣ-ಪಠ್ಯ ಹುಡುಕಾಟ ಎಂಜಿನ್ ಅಲ್ಲ ಎಂದು ಹೇಳುವುದು ಮೊದಲನೆಯದು. ಇದಕ್ಕಾಗಿ ವಿಶೇಷ ವ್ಯವಸ್ಥೆಗಳಿವೆ, ಉದಾಹರಣೆಗೆ, и . ಆದಾಗ್ಯೂ, ಜನರು Elasticsearch ನಿಂದ ClickHouse ಗೆ ಬದಲಾಯಿಸುತ್ತಿದ್ದಾರೆ ಎಂದು ಹೇಳುವುದನ್ನು ನಾನು ಹೆಚ್ಚಾಗಿ ನೋಡುತ್ತೇನೆ.
ಇದು ಏಕೆ ಸಂಭವಿಸುತ್ತದೆ? ಸೂಚ್ಯಂಕಗಳ ನಿರ್ಮಾಣದಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಕೆಲವು ಸಂಪುಟಗಳಲ್ಲಿ ಲೋಡ್ ಅನ್ನು ನಿಭಾಯಿಸಲು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟವು ನಿಲ್ಲಿಸುತ್ತದೆ ಎಂಬ ಅಂಶದಿಂದ ಅವರು ಇದನ್ನು ವಿವರಿಸುತ್ತಾರೆ. ಸೂಚ್ಯಂಕಗಳು ತುಂಬಾ ತೊಡಕಾಗುತ್ತವೆ, ಮತ್ತು ನೀವು ಸರಳವಾಗಿ ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸಿದರೆ, ಅದನ್ನು ಪರಿಮಾಣದ ವಿಷಯದಲ್ಲಿ ಹಲವಾರು ಬಾರಿ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಹುಡುಕಾಟ ಪ್ರಶ್ನೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಡೇಟಾದ ಸಂಪೂರ್ಣ ಪರಿಮಾಣದಲ್ಲಿ ಕೆಲವು ಪದಗುಚ್ಛಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಅಗತ್ಯವಾಗಿರಲಿಲ್ಲ, ರೂಪವಿಜ್ಞಾನವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾಗಿವೆ. ಉದಾಹರಣೆಗೆ, ಕಳೆದ ಕೆಲವು ಗಂಟೆಗಳಲ್ಲಿ ಲಾಗ್‌ಗಳಲ್ಲಿ ಕೆಲವು ಬೈಟ್‌ಗಳ ಅನುಕ್ರಮವನ್ನು ಹುಡುಕಿ.
ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಸೂಚ್ಯಂಕವನ್ನು ರಚಿಸುತ್ತೀರಿ, ಇದರಲ್ಲಿ ಮೊದಲ ಕ್ಷೇತ್ರವು ದಿನಾಂಕ ಮತ್ತು ಸಮಯವಾಗಿರುತ್ತದೆ. ಮತ್ತು ಅತಿದೊಡ್ಡ ಡೇಟಾ ಕಟ್-ಆಫ್ ದಿನಾಂಕ ಶ್ರೇಣಿಯನ್ನು ಆಧರಿಸಿರುತ್ತದೆ. ಆಯ್ಕೆಮಾಡಿದ ದಿನಾಂಕದ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ, ನಿಯಮದಂತೆ, ಬ್ರೂಟ್ ಫೋರ್ಸ್ ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಪೂರ್ಣ-ಪಠ್ಯ ಹುಡುಕಾಟವನ್ನು ಕೈಗೊಳ್ಳಲು ಈಗಾಗಲೇ ಸಾಧ್ಯವಿದೆ. ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿರುವ ಲೈಕ್ ಆಪರೇಟರ್ ನೀವು ಕಂಡುಕೊಳ್ಳಬಹುದಾದ ಅತ್ಯಂತ ಪರಿಣಾಮಕಾರಿ ಆಪರೇಟರ್ ಆಗಿದೆ. ನೀವು ಏನಾದರೂ ಉತ್ತಮವಾದುದನ್ನು ಕಂಡುಕೊಂಡರೆ, ನನಗೆ ತಿಳಿಸಿ.
ಆದರೆ ಇನ್ನೂ, ಪೂರ್ಣ ಸ್ಕ್ಯಾನ್ ಆಗಿದೆ. ಮತ್ತು ಪೂರ್ಣ ಸ್ಕ್ಯಾನ್ CPU ನಲ್ಲಿ ಮಾತ್ರವಲ್ಲದೆ ಡಿಸ್ಕ್ನಲ್ಲಿಯೂ ನಿಧಾನವಾಗಬಹುದು. ಇದ್ದಕ್ಕಿದ್ದಂತೆ ನೀವು ದಿನಕ್ಕೆ ಒಂದು ಟೆರಾಬೈಟ್ ಡೇಟಾವನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ನೀವು ದಿನದಲ್ಲಿ ಪದವನ್ನು ಹುಡುಕುತ್ತಿದ್ದರೆ, ನೀವು ಟೆರಾಬೈಟ್ ಅನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಮತ್ತು ಇದು ಪ್ರಾಯಶಃ ಸಾಮಾನ್ಯ ಹಾರ್ಡ್ ಡ್ರೈವ್‌ಗಳಲ್ಲಿದೆ, ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಅವರು SSH ಮೂಲಕ ಈ ಸರ್ವರ್ ಅನ್ನು ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಾಗದ ರೀತಿಯಲ್ಲಿ ಅವುಗಳನ್ನು ಲೋಡ್ ಮಾಡಲಾಗುತ್ತದೆ.
ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾನು ಇನ್ನೂ ಒಂದು ಸಣ್ಣ ಟ್ರಿಕ್ ನೀಡಲು ಸಿದ್ಧನಿದ್ದೇನೆ. ಇದು ಪ್ರಾಯೋಗಿಕವಾಗಿದೆ - ಇದು ಕೆಲಸ ಮಾಡಬಹುದು, ಇಲ್ಲದಿರಬಹುದು. ಕ್ಲಿಕ್‌ಹೌಸ್ ಟ್ರಿಗ್ರಾಮ್ ಬ್ಲೂಮ್ ಫಿಲ್ಟರ್‌ಗಳ ರೂಪದಲ್ಲಿ ಪೂರ್ಣ-ಪಠ್ಯ ಸೂಚ್ಯಂಕಗಳನ್ನು ಹೊಂದಿದೆ. ಅರೆನಾಡಾಟಾದಲ್ಲಿನ ನಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳು ಈಗಾಗಲೇ ಈ ಸೂಚಿಕೆಗಳನ್ನು ಪ್ರಯತ್ನಿಸಿದ್ದಾರೆ ಮತ್ತು ಅವರು ಸಾಮಾನ್ಯವಾಗಿ ಉದ್ದೇಶಿಸಿದಂತೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ.
ಅವುಗಳನ್ನು ಸರಿಯಾಗಿ ಬಳಸಲು, ಅವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದರ ಕುರಿತು ನೀವು ಉತ್ತಮ ತಿಳುವಳಿಕೆಯನ್ನು ಹೊಂದಿರಬೇಕು: ಟ್ರಿಗ್ರಾಮ್ ಬ್ಲೂಮ್ ಫಿಲ್ಟರ್ ಎಂದರೇನು ಮತ್ತು ಅದರ ಗಾತ್ರವನ್ನು ಹೇಗೆ ಆರಿಸಬೇಕು. ಡೇಟಾದಲ್ಲಿ ಅಪರೂಪವಾಗಿ ಕಂಡುಬರುವ ಕೆಲವು ಅಪರೂಪದ ನುಡಿಗಟ್ಟುಗಳು, ಸಬ್‌ಸ್ಟ್ರಿಂಗ್‌ಗಳ ಮೇಲಿನ ಪ್ರಶ್ನೆಗಳಿಗೆ ಅವರು ಸಹಾಯ ಮಾಡುತ್ತಾರೆ ಎಂದು ನಾನು ಹೇಳಬಲ್ಲೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಉಪಶ್ರೇಣಿಗಳನ್ನು ಸೂಚ್ಯಂಕಗಳಿಂದ ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಕಡಿಮೆ ಡೇಟಾವನ್ನು ಓದಲಾಗುತ್ತದೆ.
ಇತ್ತೀಚೆಗೆ, ಕ್ಲಿಕ್‌ಹೌಸ್ ಪೂರ್ಣ-ಪಠ್ಯ ಹುಡುಕಾಟಕ್ಕಾಗಿ ಇನ್ನಷ್ಟು ಸುಧಾರಿತ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸೇರಿಸಿದೆ. ಇದು ಮೊದಲನೆಯದಾಗಿ, UTF-8 ಗಾಗಿ ಅಥವಾ ASCII ಗೆ ಮಾತ್ರ ಬೆಂಬಲದೊಂದಿಗೆ ಕೇಸ್-ಸೆನ್ಸಿಟಿವ್, ಕೇಸ್-ಸೆನ್ಸಿಟಿವ್ ಆಯ್ಕೆಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಒಂದು ಪಾಸ್‌ನಲ್ಲಿ ಒಂದೇ ಬಾರಿಗೆ ಸಬ್‌ಸ್ಟ್ರಿಂಗ್‌ಗಳ ಗುಂಪಿಗಾಗಿ ಹುಡುಕಾಟವಾಗಿದೆ. ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾದದನ್ನು ಆರಿಸಿ.
ಒಂದು ಪಾಸ್‌ನಲ್ಲಿ ಬಹು ನಿಯಮಿತ ಅಭಿವ್ಯಕ್ತಿಗಳಿಗಾಗಿ ಹುಡುಕಾಟ ಕೂಡ ಕಾಣಿಸಿಕೊಂಡಿದೆ. ನೀವು ಒಂದು ಸಬ್‌ಸ್ಟ್ರಿಂಗ್‌ನಂತೆ ಎಕ್ಸ್ ಅಥವಾ ಇನ್ನೊಂದು ಸಬ್‌ಸ್ಟ್ರಿಂಗ್‌ನಂತೆ ಎಕ್ಸ್ ಅನ್ನು ಬರೆಯಬೇಕಾಗಿಲ್ಲ. ನೀವು ಈಗಿನಿಂದಲೇ ಬರೆಯಿರಿ, ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಸಾಧ್ಯವಾದಷ್ಟು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಮಾಡಲಾಗುತ್ತದೆ.
ಮೂರನೆಯದಾಗಿ, ಈಗ regexps ಗಾಗಿ ಅಂದಾಜು ಹುಡುಕಾಟ ಮತ್ತು ಸಬ್‌ಸ್ಟ್ರಿಂಗ್‌ಗಳಿಗಾಗಿ ಅಂದಾಜು ಹುಡುಕಾಟವಿದೆ. ಯಾರಾದರೂ ಪದವನ್ನು ತಪ್ಪಾಗಿ ಬರೆದರೆ, ಅದನ್ನು ಗರಿಷ್ಠ ಹೊಂದಾಣಿಕೆಗಾಗಿ ಹುಡುಕಲಾಗುತ್ತದೆ.
ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಬಳಕೆದಾರರಿಗೆ ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಪ್ರವೇಶವನ್ನು ಸಂಘಟಿಸಲು ಉತ್ತಮ ಮಾರ್ಗ ಯಾವುದು?
ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಗ್ರಾಹಕರು ಮತ್ತು ವಿಶ್ಲೇಷಕರಿಗೆ ಪ್ರವೇಶವನ್ನು ಉತ್ತಮವಾಗಿ ಸಂಘಟಿಸುವುದು ಹೇಗೆ ಎಂದು ನಮಗೆ ತಿಳಿಸಿ. ಕ್ಯೂ ಅನ್ನು ಹೇಗೆ ರಚಿಸುವುದು, ಗರಿಷ್ಠ ಏಕಕಾಲಿಕ ಪ್ರಶ್ನೆಗಳಿಗೆ ಆದ್ಯತೆ ನೀಡುವುದು ಮತ್ತು ಯಾವ ಸಾಧನಗಳೊಂದಿಗೆ?
ಕ್ಲಸ್ಟರ್ ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿದ್ದರೆ, ಇನ್ನೂ ಎರಡು ಸರ್ವರ್ಗಳನ್ನು ಹೆಚ್ಚಿಸುವುದು ಉತ್ತಮ ಪರಿಹಾರವಾಗಿದೆ, ಇದು ವಿಶ್ಲೇಷಕರಿಗೆ ಪ್ರವೇಶ ಬಿಂದುವಾಗುತ್ತದೆ. ಅಂದರೆ, ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಚೂರುಗಳನ್ನು ಪ್ರವೇಶಿಸಲು ವಿಶ್ಲೇಷಕರನ್ನು ಅನುಮತಿಸಬೇಡಿ, ಆದರೆ ಡೇಟಾ ಇಲ್ಲದೆ ಎರಡು ಖಾಲಿ ಸರ್ವರ್ಗಳನ್ನು ರಚಿಸಿ ಮತ್ತು ಅವುಗಳ ಮೇಲೆ ಪ್ರವೇಶ ಹಕ್ಕುಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ವಿತರಿಸಿದ ವಿನಂತಿಗಳಿಗಾಗಿ ಬಳಕೆದಾರರ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ರಿಮೋಟ್ ಸರ್ವರ್‌ಗಳಿಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ. ಅಂದರೆ, ನೀವು ಈ ಎರಡು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ಕಾನ್ಫಿಗರ್ ಮಾಡಿ, ಮತ್ತು ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ.
ತಾತ್ವಿಕವಾಗಿ, ಈ ಸರ್ವರ್‌ಗಳು ಯಾವುದೇ ಡೇಟಾವನ್ನು ಹೊಂದಿಲ್ಲ, ಆದರೆ ವಿನಂತಿಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಅವುಗಳಲ್ಲಿ RAM ನ ಪ್ರಮಾಣವು ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ. ಬಾಹ್ಯ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆ ಅಥವಾ ಬಾಹ್ಯ ವಿಂಗಡಣೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದರೆ ತಾತ್ಕಾಲಿಕ ಡೇಟಾಕ್ಕಾಗಿ ಡಿಸ್ಕ್ ಅನ್ನು ಸಹ ಬಳಸಬಹುದು.
ಸಾಧ್ಯವಿರುವ ಎಲ್ಲ ಮಿತಿಗಳೊಂದಿಗೆ ಸಂಯೋಜಿತವಾಗಿರುವ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ನೋಡುವುದು ಮುಖ್ಯ. ನಾನು ಈಗ Yandex.Metrica ಕ್ಲಸ್ಟರ್‌ಗೆ ವಿಶ್ಲೇಷಕನಾಗಿ ಹೋಗಿ ವಿನಂತಿಯನ್ನು ಕೇಳಿದರೆ ಹಿಟ್‌ಗಳಿಂದ ಎಣಿಕೆ ಆಯ್ಕೆಮಾಡಿ, ನಂತರ ನಾನು ವಿನಂತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂಬ ವಿನಾಯಿತಿಯನ್ನು ತಕ್ಷಣವೇ ನೀಡಲಾಗುವುದು. ನಾನು ಸ್ಕ್ಯಾನ್ ಮಾಡಲು ಅನುಮತಿಸಲಾದ ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಸಾಲುಗಳು ನೂರು ಶತಕೋಟಿ, ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಒಂದು ಕೋಷ್ಟಕದಲ್ಲಿ ಒಟ್ಟು ಐವತ್ತು ಟ್ರಿಲಿಯನ್ ಇವೆ. ಇದು ಮೊದಲ ಮಿತಿಯಾಗಿದೆ.
ನಾನು ಸಾಲುಗಳ ಸಂಖ್ಯೆಯ ಮೇಲಿನ ಮಿತಿಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತೇನೆ ಮತ್ತು ಪ್ರಶ್ನೆಯನ್ನು ಮತ್ತೆ ರನ್ ಮಾಡುತ್ತೇನೆ ಎಂದು ಹೇಳೋಣ. ನಂತರ ನಾನು ಈ ಕೆಳಗಿನ ವಿನಾಯಿತಿಯನ್ನು ನೋಡುತ್ತೇನೆ - ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ ದಿನಾಂಕದ ಪ್ರಕಾರ ಬಲ ಸೂಚ್ಯಂಕ. ನಾನು ದಿನಾಂಕ ಶ್ರೇಣಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸದಿದ್ದರೆ ನಾನು ಪ್ರಶ್ನೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅದನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ನೀವು ವಿಶ್ಲೇಷಕರನ್ನು ಅವಲಂಬಿಸಬೇಕಾಗಿಲ್ಲ. ಒಂದು ವಿಶಿಷ್ಟವಾದ ಪ್ರಕರಣವು ದಿನಾಂಕ ಶ್ರೇಣಿಯಾಗಿದ್ದು, ವಾರದ ನಡುವಿನ ಈವೆಂಟ್ ದಿನಾಂಕವನ್ನು ಬರೆಯಲಾಗುತ್ತದೆ. ತದನಂತರ ಅವರು ಸರಳವಾಗಿ ತಪ್ಪಾದ ಸ್ಥಳದಲ್ಲಿ ಬ್ರಾಕೆಟ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದರು, ಮತ್ತು ಬದಲಿಗೆ ಮತ್ತು ಅದು ಅಥವಾ - ಅಥವಾ URL ಹೊಂದಾಣಿಕೆಯಾಗಿದೆ. ಯಾವುದೇ ಮಿತಿ ಇಲ್ಲದಿದ್ದರೆ, ಅದು URL ಕಾಲಮ್ ಅನ್ನು ಕ್ರಾಲ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಕೇವಲ ಒಂದು ಟನ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕ್ಲಿಕ್‌ಹೌಸ್ ಎರಡು ಆದ್ಯತೆಯ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಹೊಂದಿದೆ. ದುರದೃಷ್ಟವಶಾತ್, ಅವರು ಬಹಳ ಪ್ರಾಚೀನರು. ಒಂದನ್ನು ಸರಳವಾಗಿ ಕರೆಯಲಾಗುತ್ತದೆ ಆದ್ಯತೆ. ಆದ್ಯತೆ ≠ 0, ಮತ್ತು ಕೆಲವು ಆದ್ಯತೆಗಳೊಂದಿಗೆ ವಿನಂತಿಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತಿದ್ದರೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಕಡಿಮೆ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರುವ ಆದ್ಯತೆಯ ಮೌಲ್ಯದೊಂದಿಗೆ ವಿನಂತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ, ಅಂದರೆ ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯರ್ಥ, ನಂತರ ಆದ್ಯತೆಯ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರುವ ವಿನಂತಿಯು ಹೆಚ್ಚಾಗಿರುತ್ತದೆ. ಕಡಿಮೆ ಆದ್ಯತೆ ಎಂದರೆ, ಸರಳವಾಗಿ ಅಮಾನತುಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಈ ಸಮಯದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.
ಇದು ಅತ್ಯಂತ ಕಚ್ಚಾ ಸೆಟ್ಟಿಂಗ್ ಆಗಿದೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್ ನಿರಂತರ ಲೋಡ್ ಹೊಂದಿರುವ ಸಂದರ್ಭಗಳಲ್ಲಿ ಸೂಕ್ತವಲ್ಲ. ಆದರೆ ನೀವು ಚಿಕ್ಕದಾದ, ಬರ್ಸ್ಟಿ ವಿನಂತಿಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್ ಹೆಚ್ಚಾಗಿ ನಿಷ್ಕ್ರಿಯವಾಗಿದ್ದರೆ, ಈ ಸೆಟಪ್ ಸೂಕ್ತವಾಗಿದೆ.
ಮುಂದಿನ ಆದ್ಯತೆಯ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ಓಎಸ್ ಥ್ರೆಡ್ ಆದ್ಯತೆ. ಇದು ಲಿನಕ್ಸ್ ಶೆಡ್ಯೂಲರ್‌ಗಾಗಿ ಎಲ್ಲಾ ವಿನಂತಿಯ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಥ್ರೆಡ್‌ಗಳಿಗೆ ಉತ್ತಮ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿಸುತ್ತದೆ. ಇದು ಹಾಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಅದು ಇನ್ನೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನೀವು ಕನಿಷ್ಟ ಉತ್ತಮ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿಸಿದರೆ - ಇದು ಮೌಲ್ಯದಲ್ಲಿ ದೊಡ್ಡದಾಗಿದೆ ಮತ್ತು ಕಡಿಮೆ ಆದ್ಯತೆಯ ಅರ್ಥ - ಮತ್ತು ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯೊಂದಿಗೆ ವಿನಂತಿಗಳಿಗಾಗಿ -19 ಅನ್ನು ಹೊಂದಿಸಿದರೆ, ನಂತರ CPU ಕಡಿಮೆ ಆದ್ಯತೆಯ ವಿನಂತಿಗಳನ್ನು ಹೆಚ್ಚಿನ ಆದ್ಯತೆಗಳಿಗಿಂತ ಸುಮಾರು ನಾಲ್ಕು ಪಟ್ಟು ಕಡಿಮೆ ಬಳಸುತ್ತದೆ.
ನೀವು ಗರಿಷ್ಠ ವಿನಂತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯವನ್ನು ಸಹ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ - ಹೇಳಿ, ಐದು ನಿಮಿಷಗಳು. ಕನಿಷ್ಠ ಪ್ರಶ್ನೆಯ ವೇಗವು ತಂಪಾದ ವಿಷಯವಾಗಿದೆ. ಈ ಸೆಟ್ಟಿಂಗ್ ಬಹಳ ಸಮಯದಿಂದ ಇದೆ, ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್ ನಿಧಾನವಾಗುವುದಿಲ್ಲ ಎಂದು ಪ್ರತಿಪಾದಿಸಲು ಮಾತ್ರವಲ್ಲ, ಅದನ್ನು ಒತ್ತಾಯಿಸಲು ಇದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ.
ಇಮ್ಯಾಜಿನ್, ನೀವು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ: ಕೆಲವು ಪ್ರಶ್ನೆಗಳು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಒಂದು ಮಿಲಿಯನ್ ಸಾಲುಗಳಿಗಿಂತ ಕಡಿಮೆಯಿದ್ದರೆ, ನೀವು ಇದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಇದು ನಮ್ಮ ಒಳ್ಳೆಯ ಹೆಸರು, ನಮ್ಮ ಉತ್ತಮ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಅವಮಾನಿಸುತ್ತದೆ. ಇದನ್ನು ನಿಷೇಧಿಸೋಣ. ವಾಸ್ತವವಾಗಿ ಎರಡು ಸೆಟ್ಟಿಂಗ್‌ಗಳಿವೆ. ಒಂದನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ನಿಮಿಷ ಮರಣದಂಡನೆಯ ವೇಗ - ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸಾಲುಗಳಲ್ಲಿ, ಮತ್ತು ನಿಮಿಷದ ಮರಣದಂಡನೆಯ ವೇಗವನ್ನು ಪರಿಶೀಲಿಸುವ ಮೊದಲು ಎರಡನೆಯದನ್ನು ಸಮಯ ಮೀರಿದೆ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ - ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಹದಿನೈದು ಸೆಕೆಂಡುಗಳು. ಅಂದರೆ, ಹದಿನೈದು ಸೆಕೆಂಡುಗಳು ಸಾಧ್ಯ, ಮತ್ತು ನಂತರ, ಅದು ನಿಧಾನವಾಗಿದ್ದರೆ, ಕೇವಲ ಒಂದು ವಿನಾಯಿತಿಯನ್ನು ಎಸೆಯಿರಿ ಮತ್ತು ವಿನಂತಿಯನ್ನು ಸ್ಥಗಿತಗೊಳಿಸಿ.
ನೀವು ಕೋಟಾಗಳನ್ನು ಸಹ ಹೊಂದಿಸಬೇಕಾಗಿದೆ. ClickHouse ಸಂಪನ್ಮೂಲ ಬಳಕೆಯನ್ನು ಎಣಿಸುವ ಅಂತರ್ನಿರ್ಮಿತ ಕೋಟಾ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊಂದಿದೆ. ಆದರೆ, ದುರದೃಷ್ಟವಶಾತ್, CPU, ಡಿಸ್ಕ್ಗಳಂತಹ ಹಾರ್ಡ್‌ವೇರ್ ಸಂಪನ್ಮೂಲಗಳಲ್ಲ, ಆದರೆ ತಾರ್ಕಿಕ ಪದಗಳಿಗಿಂತ - ಸಂಸ್ಕರಿಸಿದ ವಿನಂತಿಗಳು, ಸಾಲುಗಳು ಮತ್ತು ಬೈಟ್‌ಗಳನ್ನು ಓದುವ ಸಂಖ್ಯೆ. ಮತ್ತು ನೀವು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು, ಉದಾಹರಣೆಗೆ, ಐದು ನಿಮಿಷಗಳಲ್ಲಿ ಗರಿಷ್ಠ ನೂರು ವಿನಂತಿಗಳು ಮತ್ತು ಗಂಟೆಗೆ ಸಾವಿರ ವಿನಂತಿಗಳು.
ಇದು ಏಕೆ ಮುಖ್ಯ? ಏಕೆಂದರೆ ಕೆಲವು ವಿಶ್ಲೇಷಣಾ ಪ್ರಶ್ನೆಗಳನ್ನು ಕ್ಲಿಕ್‌ಹೌಸ್ ಕ್ಲೈಂಟ್‌ನಿಂದ ನೇರವಾಗಿ ಹಸ್ತಚಾಲಿತವಾಗಿ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ. ಮತ್ತು ಎಲ್ಲಾ ಚೆನ್ನಾಗಿ ಇರುತ್ತದೆ. ಆದರೆ ನಿಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ ನೀವು ಮುಂದುವರಿದ ವಿಶ್ಲೇಷಕರನ್ನು ಹೊಂದಿದ್ದರೆ, ಅವರು ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಬರೆಯುತ್ತಾರೆ ಮತ್ತು ಸ್ಕ್ರಿಪ್ಟ್ನಲ್ಲಿ ದೋಷವಿರಬಹುದು. ಮತ್ತು ಈ ದೋಷವು ವಿನಂತಿಯನ್ನು ಅನಂತ ಲೂಪ್‌ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಕಾರಣವಾಗುತ್ತದೆ. ಇದರಿಂದ ನಮ್ಮನ್ನು ನಾವು ರಕ್ಷಿಸಿಕೊಳ್ಳಬೇಕು.
ಹತ್ತು ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಒಂದು ಪ್ರಶ್ನೆಯ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡಲು ಸಾಧ್ಯವೇ?
ಒಂದೇ ಸಮಯದಲ್ಲಿ ದೊಡ್ಡ ವಿನಂತಿಗಳೊಂದಿಗೆ ಬರಲು ಇಷ್ಟಪಡುವ ಹಲವಾರು ಬಳಕೆದಾರರನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ. ವಿನಂತಿಯು ದೊಡ್ಡದಾಗಿದೆ, ಮತ್ತು ತಾತ್ವಿಕವಾಗಿ ಅದನ್ನು ತ್ವರಿತವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಅಂತಹ ಅನೇಕ ವಿನಂತಿಗಳು ಇರುವುದರಿಂದ ಇದು ತುಂಬಾ ನೋವಿನಿಂದ ಕೂಡಿದೆ. ಸತತ ಹತ್ತು ಬಾರಿ ಬಂದ ಅದೇ ವಿನಂತಿಯನ್ನು ಒಮ್ಮೆ ಕಾರ್ಯಗತಗೊಳಿಸಿ ಹತ್ತು ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಫಲಿತಾಂಶವನ್ನು ನೀಡಲು ಸಾಧ್ಯವೇ?
ಸಮಸ್ಯೆಯೆಂದರೆ ನಾವು ಮಧ್ಯಂತರ ಡೇಟಾದ ಸಂಗ್ರಹ ಅಥವಾ ಸಂಗ್ರಹದ ಫಲಿತಾಂಶಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನ ಒಂದು ಪುಟ ಸಂಗ್ರಹವಿದೆ, ಅದು ಡಿಸ್ಕ್ನಿಂದ ಡೇಟಾವನ್ನು ಮತ್ತೆ ಓದುವುದನ್ನು ತಡೆಯುತ್ತದೆ, ಆದರೆ, ದುರದೃಷ್ಟವಶಾತ್, ಡೇಟಾವನ್ನು ಇನ್ನೂ ಡಿಕಂಪ್ರೆಸ್ ಮಾಡಲಾಗುತ್ತದೆ, ಡಿಸರಿಯಲೈಸ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಮರುಸಂಸ್ಕರಿಸಲಾಗುತ್ತದೆ.
ಮಧ್ಯಂತರ ಡೇಟಾವನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಮೂಲಕ ಅಥವಾ ಕೆಲವು ರೀತಿಯ ಕ್ಯೂನಲ್ಲಿ ಒಂದೇ ರೀತಿಯ ಪ್ರಶ್ನೆಗಳನ್ನು ಜೋಡಿಸುವ ಮೂಲಕ ಮತ್ತು ಫಲಿತಾಂಶಗಳ ಸಂಗ್ರಹವನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ನಾನು ಹೇಗಾದರೂ ಇದನ್ನು ತಪ್ಪಿಸಲು ಬಯಸುತ್ತೇನೆ. ಪ್ರಸ್ತುತ ನಾವು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಒಂದು ಪುಲ್ ವಿನಂತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಅದು ವಿನಂತಿಯ ಸಂಗ್ರಹವನ್ನು ಸೇರಿಸುತ್ತದೆ, ಆದರೆ ಇನ್ ಮತ್ತು ಸೇರ್ಪಡೆ ವಿಭಾಗಗಳಲ್ಲಿನ ಉಪಪ್ರಶ್ನೆಗಳಿಗೆ ಮಾತ್ರ - ಅಂದರೆ, ಪರಿಹಾರವು ಅಪೂರ್ಣವಾಗಿದೆ.
ಆದಾಗ್ಯೂ, ನಾವು ಸಹ ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ಎದುರಿಸುತ್ತೇವೆ. ನಿರ್ದಿಷ್ಟವಾಗಿ ಅಂಗೀಕೃತ ಉದಾಹರಣೆಯೆಂದರೆ ಪುಟವಿನ್ಯಾಸದೊಂದಿಗೆ ಪ್ರಶ್ನೆಗಳು. ಒಂದು ವರದಿ ಇದೆ, ಇದು ಹಲವಾರು ಪುಟಗಳನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಮಿತಿ 10 ಗಾಗಿ ವಿನಂತಿಯಿದೆ. ನಂತರ ಅದೇ ವಿಷಯ, ಆದರೆ ಮಿತಿ 10,10. ನಂತರ ಇನ್ನೊಂದು ಮುಂದಿನ ಪುಟ. ಮತ್ತು ಪ್ರಶ್ನೆಯೆಂದರೆ, ನಾವು ಇದನ್ನು ಪ್ರತಿ ಬಾರಿಯೂ ಏಕೆ ಎಣಿಸುತ್ತೇವೆ? ಆದರೆ ಈಗ ಯಾವುದೇ ಪರಿಹಾರವಿಲ್ಲ, ಮತ್ತು ಅದನ್ನು ತಪ್ಪಿಸಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ.
ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಪಕ್ಕದಲ್ಲಿ ಸೈಡ್‌ಕಾರ್ ಆಗಿ ಇರಿಸಲಾದ ಪರ್ಯಾಯ ಪರಿಹಾರವಿದೆ - .
ಕಿರಿಲ್ ಶ್ವಾಕೋವ್: ClickHouse ಪ್ರಾಕ್ಸಿ ಅಂತರ್ನಿರ್ಮಿತ ದರ ಮಿತಿಯನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಅಂತರ್ನಿರ್ಮಿತ ಫಲಿತಾಂಶಗಳ ಸಂಗ್ರಹವನ್ನು ಹೊಂದಿದೆ. ಇದೇ ರೀತಿಯ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಕಾರಣ ಅಲ್ಲಿ ಸಾಕಷ್ಟು ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಮಾಡಲಾಗಿದೆ. ಪ್ರಾಕ್ಸಿ ನಿಮಗೆ ವಿನಂತಿಗಳನ್ನು ಸರದಿಯಲ್ಲಿ ಇರಿಸುವ ಮೂಲಕ ಮಿತಿಗೊಳಿಸಲು ಮತ್ತು ವಿನಂತಿಯ ಸಂಗ್ರಹವು ಎಷ್ಟು ಸಮಯದವರೆಗೆ ಜೀವಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ. ವಿನಂತಿಗಳು ನಿಜವಾಗಿಯೂ ಒಂದೇ ಆಗಿದ್ದರೆ, ಪ್ರಾಕ್ಸಿ ಅವುಗಳನ್ನು ಹಲವು ಬಾರಿ ಕಳುಹಿಸುತ್ತದೆ, ಆದರೆ ಒಮ್ಮೆ ಮಾತ್ರ ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಹೋಗುತ್ತದೆ.
Nginx ಸಹ ಉಚಿತ ಆವೃತ್ತಿಯಲ್ಲಿ ಸಂಗ್ರಹವನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಇದು ಸಹ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ವಿನಂತಿಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಬಂದರೆ, ಒಂದು ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಅದು ಇತರವನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತದೆ ಎಂಬ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಸಹ Nginx ಹೊಂದಿದೆ. ಆದರೆ ಕ್ಲಿಕ್‌ಹೌಸ್ ಪ್ರಾಕ್ಸಿಯಲ್ಲಿ ಸೆಟಪ್ ಹೆಚ್ಚು ಉತ್ತಮವಾಗಿ ಮಾಡಲಾಗುತ್ತದೆ. ಇದನ್ನು ನಿರ್ದಿಷ್ಟವಾಗಿ ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗಾಗಿ, ನಿರ್ದಿಷ್ಟವಾಗಿ ಈ ವಿನಂತಿಗಳಿಗಾಗಿ ಮಾಡಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಇದು ಹೆಚ್ಚು ಸೂಕ್ತವಾಗಿದೆ. ಸರಿ, ಅದನ್ನು ಸ್ಥಾಪಿಸುವುದು ಸುಲಭ.
ಅಸಮಕಾಲಿಕ ಕಾರ್ಯಾಚರಣೆಗಳು ಮತ್ತು ವಸ್ತುನಿಷ್ಠ ವೀಕ್ಷಣೆಗಳ ಬಗ್ಗೆ ಏನು?
ಮರುಪಂದ್ಯದ ಎಂಜಿನ್ನೊಂದಿಗಿನ ಕಾರ್ಯಾಚರಣೆಗಳು ಅಸಮಕಾಲಿಕವಾಗಿದೆ ಎಂಬ ಸಮಸ್ಯೆ ಇದೆ - ಮೊದಲು ಡೇಟಾವನ್ನು ಬರೆಯಲಾಗುತ್ತದೆ, ನಂತರ ಅದು ಕುಸಿಯುತ್ತದೆ. ಕೆಲವು ಸಮುಚ್ಚಯಗಳನ್ನು ಹೊಂದಿರುವ ವಸ್ತುರೂಪದ ಟ್ಯಾಬ್ಲೆಟ್ ಟ್ಯಾಬ್ಲೆಟ್ ಅಡಿಯಲ್ಲಿ ವಾಸಿಸುತ್ತಿದ್ದರೆ, ನಂತರ ನಕಲುಗಳನ್ನು ಅದರಲ್ಲಿ ದಾಖಲಿಸಲಾಗುತ್ತದೆ. ಮತ್ತು ಯಾವುದೇ ಸಂಕೀರ್ಣ ತರ್ಕವಿಲ್ಲದಿದ್ದರೆ, ನಂತರ ಡೇಟಾವನ್ನು ನಕಲು ಮಾಡಲಾಗುತ್ತದೆ. ಇದರ ಬಗ್ಗೆ ಏನು ಮಾಡಬಹುದು?
ಒಂದು ಸ್ಪಷ್ಟ ಪರಿಹಾರವಿದೆ - ಅಸಮಕಾಲಿಕ ಕುಸಿತದ ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ವರ್ಗದ ಮ್ಯಾಟ್‌ವ್ಯೂಗಳ ಮೇಲೆ ಪ್ರಚೋದಕವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು. ಇದೇ ರೀತಿಯ ಕಾರ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಯಾವುದೇ ಬೆಳ್ಳಿ ಗುಂಡುಗಳು ಅಥವಾ ಯೋಜನೆಗಳಿವೆಯೇ?
ಡಿಡ್ಪ್ಲಿಕೇಶನ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ನಾನು ಈಗ ಮಾತನಾಡಲು ಹೊರಟಿರುವುದು ಪ್ರಶ್ನೆಗೆ ಸಂಬಂಧಿಸಿಲ್ಲ, ಆದರೆ ಅದನ್ನು ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳುವುದು ಯೋಗ್ಯವಾಗಿದೆ.
ಪುನರಾವರ್ತಿತ ಕೋಷ್ಟಕದಲ್ಲಿ ಸೇರಿಸುವಾಗ, ಸಂಪೂರ್ಣ ಸೇರಿಸಿದ ಬ್ಲಾಕ್ಗಳನ್ನು ನಕಲಿಸಲಾಗುತ್ತದೆ. ಅದೇ ಕ್ರಮದಲ್ಲಿ ಅದೇ ಸಂಖ್ಯೆಯ ಅದೇ ಸಾಲುಗಳನ್ನು ಹೊಂದಿರುವ ಅದೇ ಬ್ಲಾಕ್ ಅನ್ನು ನೀವು ಮರುಸೇರ್ಪಡಿಸಿದರೆ, ನಂತರ ಡೇಟಾವನ್ನು ಡಿಪ್ಲಿಕೇಟೆಡ್ ಮಾಡಲಾಗುತ್ತದೆ. ಇನ್ಸರ್ಟ್ಗೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ನೀವು "ಸರಿ" ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ, ಆದರೆ ವಾಸ್ತವವಾಗಿ ಒಂದು ಪ್ಯಾಕೆಟ್ ಡೇಟಾವನ್ನು ಬರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ನಕಲು ಮಾಡಲಾಗುವುದಿಲ್ಲ.
ಖಚಿತತೆಗೆ ಇದು ಅವಶ್ಯಕ. ಅಳವಡಿಕೆಯ ಸಮಯದಲ್ಲಿ ನೀವು "ಸರಿ" ಸ್ವೀಕರಿಸಿದರೆ, ನಿಮ್ಮ ಡೇಟಾವನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ. ನೀವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಿಂದ ದೋಷವನ್ನು ಸ್ವೀಕರಿಸಿದರೆ, ಅವುಗಳನ್ನು ಸೇರಿಸಲಾಗಿಲ್ಲ ಎಂದರ್ಥ ಮತ್ತು ನೀವು ಅಳವಡಿಕೆಯನ್ನು ಪುನರಾವರ್ತಿಸಬೇಕಾಗಿದೆ. ಆದರೆ ಅಳವಡಿಕೆಯ ಸಮಯದಲ್ಲಿ ಸಂಪರ್ಕವು ಕಳೆದುಹೋದರೆ, ಡೇಟಾವನ್ನು ಸೇರಿಸಲಾಗಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿಲ್ಲ. ಅಳವಡಿಕೆಯನ್ನು ಮತ್ತೆ ಪುನರಾವರ್ತಿಸುವುದು ಒಂದೇ ಆಯ್ಕೆಯಾಗಿದೆ. ಡೇಟಾವನ್ನು ವಾಸ್ತವವಾಗಿ ಸೇರಿಸಿದ್ದರೆ ಮತ್ತು ನೀವು ಅದನ್ನು ಮರುಸೇರ್ಪಡಿಸಿದರೆ, ಬ್ಲಾಕ್ ಡಿಪ್ಲಿಕೇಶನ್ ಇರುತ್ತದೆ. ನಕಲುಗಳನ್ನು ತಪ್ಪಿಸಲು ಇದು ಅಗತ್ಯವಿದೆ.
ಮತ್ತು ವಸ್ತುನಿಷ್ಠ ವೀಕ್ಷಣೆಗಳಿಗೆ ಇದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದು ಸಹ ಮುಖ್ಯವಾಗಿದೆ. ಮುಖ್ಯ ಕೋಷ್ಟಕದಲ್ಲಿ ಸೇರಿಸಿದಾಗ ಡೇಟಾವನ್ನು ಡಿಡಪ್ಲಿಕೇಟೆಡ್ ಮಾಡಿದರೆ, ಅದು ವಸ್ತುರೂಪದ ವೀಕ್ಷಣೆಗೆ ಹೋಗುವುದಿಲ್ಲ.
ಈಗ ಪ್ರಶ್ನೆಯ ಬಗ್ಗೆ. ನೀವು ಪ್ರತ್ಯೇಕ ಸಾಲುಗಳ ನಕಲುಗಳನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡುತ್ತಿರುವುದರಿಂದ ನಿಮ್ಮ ಪರಿಸ್ಥಿತಿಯು ಹೆಚ್ಚು ಜಟಿಲವಾಗಿದೆ. ಅಂದರೆ, ಇದು ನಕಲು ಮಾಡಲಾದ ಸಂಪೂರ್ಣ ಪ್ಯಾಕ್ ಅಲ್ಲ, ಆದರೆ ನಿರ್ದಿಷ್ಟ ಸಾಲುಗಳು, ಮತ್ತು ಅವು ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಕುಸಿಯುತ್ತವೆ. ವಾಸ್ತವವಾಗಿ, ಡೇಟಾವನ್ನು ಮುಖ್ಯ ಕೋಷ್ಟಕದಲ್ಲಿ ಕುಗ್ಗಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಕುಗ್ಗಿಸದ ಡೇಟಾವು ವಸ್ತುರೂಪದ ವೀಕ್ಷಣೆಗೆ ಹೋಗುತ್ತದೆ ಮತ್ತು ವಿಲೀನದ ಸಮಯದಲ್ಲಿ ವಸ್ತುರೂಪದ ವೀಕ್ಷಣೆಗಳಿಗೆ ಏನೂ ಆಗುವುದಿಲ್ಲ. ಏಕೆಂದರೆ ವಸ್ತುರೂಪದ ನೋಟವು ಒಳಸೇರಿಸುವ ಪ್ರಚೋದಕಕ್ಕಿಂತ ಹೆಚ್ಚೇನೂ ಅಲ್ಲ. ಇತರ ಕಾರ್ಯಾಚರಣೆಗಳ ಸಮಯದಲ್ಲಿ, ಅದಕ್ಕೆ ಹೆಚ್ಚುವರಿ ಏನೂ ಸಂಭವಿಸುವುದಿಲ್ಲ.
ಮತ್ತು ನಾನು ಇಲ್ಲಿ ನಿಮ್ಮನ್ನು ಸಂತೋಷಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಈ ಪ್ರಕರಣಕ್ಕೆ ನೀವು ನಿರ್ದಿಷ್ಟ ಪರಿಹಾರವನ್ನು ಹುಡುಕಬೇಕಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಅದನ್ನು ವಸ್ತುರೂಪದ ವೀಕ್ಷಣೆಯಲ್ಲಿ ಮರುಪಂದ್ಯ ಮಾಡುವುದು ಸಾಧ್ಯವೇ ಮತ್ತು ಡಿಡ್ಪ್ಲಿಕೇಶನ್ ವಿಧಾನವು ಅದೇ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು. ಆದರೆ ದುರದೃಷ್ಟವಶಾತ್, ಯಾವಾಗಲೂ ಅಲ್ಲ. ಅದನ್ನು ಒಟ್ಟುಗೂಡಿಸಿದರೆ, ಅದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.
ಕಿರಿಲ್ ಶ್ವಾಕೋವ್: ನಮ್ಮಲ್ಲಿಯೂ ಒಂದು ಕಾಲದಲ್ಲಿ ಊರುಗೋಲು ನಿರ್ಮಾಣವಾಗಿತ್ತು. ಆ್ಯಡ್ ಇಂಪ್ರೆಶನ್‌ಗಳಿರುವಲ್ಲಿ ಸಮಸ್ಯೆ ಇದೆ ಮತ್ತು ನೈಜ ಸಮಯದಲ್ಲಿ ನಾವು ತೋರಿಸಬಹುದಾದ ಕೆಲವು ಡೇಟಾ ಇದೆ - ಇವು ಕೇವಲ ಇಂಪ್ರೆಶನ್‌ಗಳಾಗಿವೆ. ಅವುಗಳು ಅಪರೂಪವಾಗಿ ನಕಲು ಮಾಡಲ್ಪಡುತ್ತವೆ, ಆದರೆ ಇದು ಸಂಭವಿಸಿದಲ್ಲಿ, ನಾವು ಹೇಗಾದರೂ ನಂತರ ಅವುಗಳನ್ನು ಕುಸಿಯುತ್ತೇವೆ. ಮತ್ತು ನಕಲು ಮಾಡಲಾಗದ ವಿಷಯಗಳಿದ್ದವು-ಕ್ಲಿಕ್‌ಗಳು ಮತ್ತು ಇಡೀ ಕಥೆ. ಆದರೆ ನಾನು ಅವುಗಳನ್ನು ತಕ್ಷಣವೇ ತೋರಿಸಲು ಬಯಸುತ್ತೇನೆ.
ಭೌತಿಕ ದೃಷ್ಟಿಕೋನಗಳನ್ನು ಹೇಗೆ ಮಾಡಲಾಯಿತು? ಅದನ್ನು ನೇರವಾಗಿ ಬರೆಯಲಾದ ವೀಕ್ಷಣೆಗಳು ಇದ್ದವು - ಅದನ್ನು ಕಚ್ಚಾ ಡೇಟಾಕ್ಕೆ ಬರೆಯಲಾಗಿದೆ ಮತ್ತು ವೀಕ್ಷಣೆಗಳಿಗೆ ಬರೆಯಲಾಗಿದೆ. ಅಲ್ಲಿ, ಕೆಲವು ಹಂತದಲ್ಲಿ, ಡೇಟಾವು ತುಂಬಾ ಸರಿಯಾಗಿಲ್ಲ, ಅದು ನಕಲಿಯಾಗಿದೆ, ಇತ್ಯಾದಿ. ಮತ್ತು ಟೇಬಲ್‌ನ ಎರಡನೇ ಭಾಗವಿದೆ, ಅಲ್ಲಿ ಅವು ಭೌತಿಕ ದೃಷ್ಟಿಕೋನಗಳಂತೆಯೇ ಕಾಣುತ್ತವೆ, ಅಂದರೆ, ಅವುಗಳ ರಚನೆಯ ವಿಷಯದಲ್ಲಿ ಅವು ಸಂಪೂರ್ಣವಾಗಿ ಒಂದೇ ಆಗಿರುತ್ತವೆ. ಒಮ್ಮೊಮ್ಮೆ ನಾವು ಡೇಟಾವನ್ನು ಮರು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತೇವೆ, ನಕಲುಗಳಿಲ್ಲದೆ ಡೇಟಾವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಆ ಕೋಷ್ಟಕಗಳಲ್ಲಿ ಬರೆಯುತ್ತೇವೆ.
ನಾವು API ಮೂಲಕ ಹೋಗಿದ್ದೇವೆ - ಇದು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಹಸ್ತಚಾಲಿತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಮತ್ತು API ಕಾಣುತ್ತದೆ: ನಾನು ಟೇಬಲ್‌ಗೆ ಕೊನೆಯ ಸೇರ್ಪಡೆಯ ದಿನಾಂಕವನ್ನು ಹೊಂದಿರುವಾಗ, ಸರಿಯಾದ ಡೇಟಾವನ್ನು ಈಗಾಗಲೇ ಲೆಕ್ಕಹಾಕಲಾಗಿದೆ ಎಂದು ಖಾತರಿಪಡಿಸಲಾಗಿದೆ ಮತ್ತು ಇದು ಒಂದು ಟೇಬಲ್‌ಗೆ ಮತ್ತು ಇನ್ನೊಂದು ಟೇಬಲ್‌ಗೆ ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತದೆ. ಒಂದರಿಂದ, ವಿನಂತಿಯು ನಿರ್ದಿಷ್ಟ ಸಮಯದವರೆಗೆ ಆಯ್ಕೆಮಾಡುತ್ತದೆ, ಮತ್ತು ಇನ್ನೊಂದರಿಂದ, ಇದು ಇನ್ನೂ ಲೆಕ್ಕಹಾಕದಿರುವುದನ್ನು ಪಡೆಯುತ್ತದೆ. ಮತ್ತು ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಕ್ಲಿಕ್‌ಹೌಸ್ ಮೂಲಕ ಅಲ್ಲ.
ನೀವು ಕೆಲವು ರೀತಿಯ API ಅನ್ನು ಹೊಂದಿದ್ದರೆ - ವಿಶ್ಲೇಷಕರಿಗೆ, ಬಳಕೆದಾರರಿಗೆ - ನಂತರ, ತಾತ್ವಿಕವಾಗಿ, ಇದು ಒಂದು ಆಯ್ಕೆಯಾಗಿದೆ. ನೀವು ಯಾವಾಗಲೂ ಎಣಿಸುತ್ತಿರುತ್ತೀರಿ, ಯಾವಾಗಲೂ ಎಣಿಸುತ್ತಿರುತ್ತೀರಿ. ಇದನ್ನು ದಿನಕ್ಕೆ ಒಮ್ಮೆ ಅಥವಾ ಇನ್ನೊಂದು ಸಮಯದಲ್ಲಿ ಮಾಡಬಹುದು. ನಿಮಗೆ ಅಗತ್ಯವಿಲ್ಲದ ಮತ್ತು ನಿರ್ಣಾಯಕವಲ್ಲದ ಶ್ರೇಣಿಯನ್ನು ನೀವೇ ಆರಿಸಿಕೊಳ್ಳಿ.
ಕ್ಲಿಕ್‌ಹೌಸ್ ಬಹಳಷ್ಟು ಲಾಗ್‌ಗಳನ್ನು ಹೊಂದಿದೆ. ಸರ್ವರ್‌ಗೆ ಸಂಭವಿಸುವ ಎಲ್ಲವನ್ನೂ ನಾನು ಒಂದು ನೋಟದಲ್ಲಿ ಹೇಗೆ ನೋಡಬಹುದು?
ಕ್ಲಿಕ್‌ಹೌಸ್ ಬಹಳ ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ವಿವಿಧ ಲಾಗ್‌ಗಳನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಈ ಸಂಖ್ಯೆ ಹೆಚ್ಚುತ್ತಿದೆ. ಹೊಸ ಆವೃತ್ತಿಗಳಲ್ಲಿ, ಅವುಗಳಲ್ಲಿ ಕೆಲವು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಸಹ ಸಕ್ರಿಯಗೊಳಿಸಲ್ಪಡುತ್ತವೆ; ಹಳೆಯ ಆವೃತ್ತಿಗಳಲ್ಲಿ ನವೀಕರಿಸುವಾಗ ಅವುಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬೇಕು. ಆದಾಗ್ಯೂ, ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚು ಹೆಚ್ಚು ಇವೆ. ನನ್ನ ಸರ್ವರ್‌ನಲ್ಲಿ ಈಗ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ನಾನು ಅಂತಿಮವಾಗಿ ನೋಡಲು ಬಯಸುತ್ತೇನೆ, ಬಹುಶಃ ಕೆಲವು ರೀತಿಯ ಸಾರಾಂಶ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ.
ನಿಮ್ಮ ಕ್ಲಿಕ್‌ಹೌಸ್ ತಂಡದಲ್ಲಿ ಅಥವಾ ನಿಮ್ಮ ಸ್ನೇಹಿತರ ತಂಡಗಳಲ್ಲಿ ನೀವು ಹೊಂದಿದ್ದೀರಾ, ಅವರು ಈ ಲಾಗ್‌ಗಳನ್ನು ಸಿದ್ಧಪಡಿಸಿದ ಉತ್ಪನ್ನವಾಗಿ ಪ್ರದರ್ಶಿಸುವ ರೆಡಿಮೇಡ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳ ಕೆಲವು ಕಾರ್ಯಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತಾರೆಯೇ? ಅಂತಿಮವಾಗಿ, ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಲಾಗ್‌ಗಳನ್ನು ನೋಡುವುದು ಅದ್ಭುತವಾಗಿದೆ. ಆದರೆ ಇದನ್ನು ಈಗಾಗಲೇ ಡ್ಯಾಶ್ಬೋರ್ಡ್ ರೂಪದಲ್ಲಿ ಸಿದ್ಧಪಡಿಸಿದರೆ ಅದು ತುಂಬಾ ತಂಪಾಗಿರುತ್ತದೆ. ಇದರಿಂದ ನಾನು ಹೆಚ್ಚಿನದನ್ನು ಪಡೆಯುತ್ತೇನೆ.
ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳಿವೆ, ಆದರೂ ಅವು ಪ್ರಮಾಣಿತವಾಗಿಲ್ಲ. ನಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ, ಸುಮಾರು 60 ತಂಡಗಳು ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಬಳಸುತ್ತವೆ, ಮತ್ತು ವಿಚಿತ್ರವಾದ ವಿಷಯವೆಂದರೆ ಅವುಗಳಲ್ಲಿ ಹಲವರು ತಮಗಾಗಿ ಮಾಡಿದ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿವೆ. ಕೆಲವು ತಂಡಗಳು ಆಂತರಿಕ Yandex.Cloud ಅನುಸ್ಥಾಪನೆಯನ್ನು ಬಳಸುತ್ತವೆ. ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ವರದಿಗಳಿಲ್ಲದಿದ್ದರೂ ಕೆಲವು ಸಿದ್ಧ ವರದಿಗಳಿವೆ. ಇತರರು ತಮ್ಮದೇ ಆದದ್ದನ್ನು ಹೊಂದಿದ್ದಾರೆ.
ಮೆಟ್ರಿಕಾದ ನನ್ನ ಸಹೋದ್ಯೋಗಿಗಳು ಗ್ರಾಫಾನಾದಲ್ಲಿ ತಮ್ಮದೇ ಆದ ಡ್ಯಾಶ್ಬೋರ್ಡ್ ಅನ್ನು ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಅವರ ಸ್ವಂತ ಕ್ಲಸ್ಟರ್‌ಗಾಗಿ ನಾನು ನನ್ನದೇ ಆದದ್ದನ್ನು ಹೊಂದಿದ್ದೇನೆ. ನಾನು ಸೆರಿಫ್ ಕ್ಯಾಶ್‌ಗಾಗಿ ಕ್ಯಾಶ್ ಹಿಟ್‌ನಂತಹ ವಿಷಯಗಳನ್ನು ನೋಡುತ್ತಿದ್ದೇನೆ. ಮತ್ತು ಇನ್ನೂ ಕಷ್ಟವೆಂದರೆ ನಾವು ವಿಭಿನ್ನ ಸಾಧನಗಳನ್ನು ಬಳಸುತ್ತೇವೆ. ನಾನು ಗ್ರ್ಯಾಫೈಟ್-ವೆಬ್ ಎಂಬ ಹಳೆಯ ಉಪಕರಣವನ್ನು ಬಳಸಿಕೊಂಡು ನನ್ನ ಡ್ಯಾಶ್ಬೋರ್ಡ್ ಅನ್ನು ರಚಿಸಿದ್ದೇನೆ. ಅವನು ಸಂಪೂರ್ಣವಾಗಿ ಕೊಳಕು. ಮತ್ತು ನಾನು ಅದನ್ನು ಇನ್ನೂ ಹೇಗೆ ಬಳಸುತ್ತಿದ್ದೇನೆ, ಆದರೂ ಗ್ರಾಫಾನಾ ಬಹುಶಃ ಹೆಚ್ಚು ಅನುಕೂಲಕರ ಮತ್ತು ಸುಂದರವಾಗಿರುತ್ತದೆ.
ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳಲ್ಲಿನ ಮೂಲಭೂತ ವಿಷಯ ಒಂದೇ ಆಗಿರುತ್ತದೆ. ಇವುಗಳು ಕ್ಲಸ್ಟರ್‌ಗಾಗಿ ಸಿಸ್ಟಮ್ ಮೆಟ್ರಿಕ್‌ಗಳಾಗಿವೆ: CPU, ಮೆಮೊರಿ, ಡಿಸ್ಕ್, ನೆಟ್ವರ್ಕ್. ಇತರೆ ಏಕಕಾಲಿಕ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ, ಏಕಕಾಲಿಕ ವಿಲೀನಗಳ ಸಂಖ್ಯೆ, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ, MergeTree ಕೋಷ್ಟಕಗಳ ವಿಭಾಗಗಳಿಗೆ ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ತುಣುಕುಗಳು, ಪ್ರತಿಕೃತಿ ಮಂದಗತಿ, ಪ್ರತಿಕೃತಿ ಸರತಿ ಗಾತ್ರ, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸೇರಿಸಲಾದ ಸಾಲುಗಳ ಸಂಖ್ಯೆ, ಸೇರಿಸಿದ ಬ್ಲಾಕ್ಗಳ ಸಂಖ್ಯೆ ಪ್ರತಿ ಸೆಕೆಂಡ್. ಇದು ಲಾಗ್‌ಗಳಿಂದಲ್ಲ, ಆದರೆ ಮೆಟ್ರಿಕ್‌ಗಳಿಂದ ಪಡೆಯಲಾಗಿದೆ.
ವ್ಲಾಡಿಮಿರ್ ಕೊಲೊಬೇವ್: ಅಲೆಕ್ಸಿ, ನಾನು ಅದನ್ನು ಸ್ವಲ್ಪ ಸರಿಪಡಿಸಲು ಬಯಸುತ್ತೇನೆ. ಗ್ರಾಪಂ ಇದೆ. ಗ್ರಾಫಾನಾ ಡೇಟಾ ಮೂಲವನ್ನು ಹೊಂದಿದೆ, ಅದು ಕ್ಲಿಕ್‌ಹೌಸ್. ಅಂದರೆ, ನಾನು ಗ್ರಾಫನಾದಿಂದ ನೇರವಾಗಿ ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ವಿನಂತಿಗಳನ್ನು ಮಾಡಬಹುದು. ಕ್ಲಿಕ್‌ಹೌಸ್ ಲಾಗ್‌ಗಳೊಂದಿಗೆ ಟೇಬಲ್ ಅನ್ನು ಹೊಂದಿದೆ, ಇದು ಎಲ್ಲರಿಗೂ ಒಂದೇ ಆಗಿರುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ನಾನು ಗ್ರಾಫನಾದಲ್ಲಿ ಈ ಲಾಗ್ ಟೇಬಲ್ ಅನ್ನು ಪ್ರವೇಶಿಸಲು ಬಯಸುತ್ತೇನೆ ಮತ್ತು ನನ್ನ ಸರ್ವರ್ ಮಾಡುವ ವಿನಂತಿಗಳನ್ನು ನೋಡಲು ಬಯಸುತ್ತೇನೆ. ಈ ರೀತಿಯ ಡ್ಯಾಶ್ಬೋರ್ಡ್ ಇದ್ದರೆ ಅದು ತುಂಬಾ ಒಳ್ಳೆಯದು.
ನಾನೇ ಬೈಕ್ ಓಡಿಸಿದೆ. ಆದರೆ ನನಗೆ ಒಂದು ಪ್ರಶ್ನೆ ಇದೆ: ಇದು ಎಲ್ಲಾ ಪ್ರಮಾಣಿತವಾಗಿದ್ದರೆ ಮತ್ತು ಗ್ರಾಫಾನಾವನ್ನು ಎಲ್ಲರೂ ಬಳಸಿದರೆ, Yandex ನಲ್ಲಿ ಅಂತಹ ಅಧಿಕೃತ ಡ್ಯಾಶ್ಬೋರ್ಡ್ ಏಕೆ ಇಲ್ಲ?
ಕಿರಿಲ್ ಶ್ವಾಕೋವ್: ವಾಸ್ತವವಾಗಿ, ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಹೋಗುವ ಡೇಟಾ ಮೂಲವು ಈಗ ಆಲ್ಟಿನಿಟಿಯನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಮತ್ತು ನಾನು ಎಲ್ಲಿ ಅಗೆಯಬೇಕು ಮತ್ತು ಯಾರನ್ನು ತಳ್ಳಬೇಕು ಎಂಬುದರ ವೆಕ್ಟರ್ ಅನ್ನು ನೀಡಲು ನಾನು ಬಯಸುತ್ತೇನೆ. ನೀವು ಅವರನ್ನು ಕೇಳಬಹುದು, ಏಕೆಂದರೆ ಯಾಂಡೆಕ್ಸ್ ಇನ್ನೂ ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದರ ಸುತ್ತಲಿನ ಕಥೆಯಲ್ಲ. ಆಲ್ಟಿನಿಟಿಯು ಪ್ರಸ್ತುತ ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಪ್ರಚಾರ ಮಾಡುತ್ತಿರುವ ಪ್ರಮುಖ ಕಂಪನಿಯಾಗಿದೆ. ಅವರು ಅವನನ್ನು ಕೈಬಿಡುವುದಿಲ್ಲ, ಆದರೆ ಅವನನ್ನು ಬೆಂಬಲಿಸುತ್ತಾರೆ. ಏಕೆಂದರೆ, ತಾತ್ವಿಕವಾಗಿ, ಗ್ರಾಫನಾ ವೆಬ್‌ಸೈಟ್‌ಗೆ ಡ್ಯಾಶ್ಬೋರ್ಡ್ ಅನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡಲು, ನೀವು ಅದನ್ನು ನೋಂದಾಯಿಸಲು ಮತ್ತು ಅಪ್‌ಲೋಡ್ ಮಾಡಲು ಮಾತ್ರ ಅಗತ್ಯವಿದೆ - ಯಾವುದೇ ವಿಶೇಷ ಸಮಸ್ಯೆಗಳಿಲ್ಲ.
ಅಲೆಕ್ಸಿ ಮಿಲೋವಿಡೋವ್: ಕಳೆದ ವರ್ಷದಲ್ಲಿ, ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನೇಕ ಪ್ರಶ್ನೆ ಪ್ರೊಫೈಲಿಂಗ್ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಸೇರಿಸಿದೆ. ಸಂಪನ್ಮೂಲ ಬಳಕೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಪ್ರತಿ ವಿನಂತಿಗೆ ಮೆಟ್ರಿಕ್‌ಗಳಿವೆ. ಮತ್ತು ಇತ್ತೀಚೆಗಷ್ಟೇ, ಪ್ರತಿ ಮಿಲಿಸೆಕೆಂಡ್‌ನಲ್ಲಿ ಪ್ರಶ್ನೆಯು ಎಲ್ಲಿ ಕಳೆಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ನೋಡಲು ನಾವು ಇನ್ನೂ ಕೆಳಮಟ್ಟದ ಪ್ರಶ್ನೆ ಪ್ರೊಫೈಲರ್ ಅನ್ನು ಸೇರಿಸಿದ್ದೇವೆ. ಆದರೆ ಈ ಕಾರ್ಯವನ್ನು ಬಳಸಲು, ನಾನು ಕನ್ಸೋಲ್ ಕ್ಲೈಂಟ್ ಅನ್ನು ತೆರೆಯಬೇಕು ಮತ್ತು ವಿನಂತಿಯನ್ನು ಟೈಪ್ ಮಾಡಬೇಕು, ಅದನ್ನು ನಾನು ಯಾವಾಗಲೂ ಮರೆತುಬಿಡುತ್ತೇನೆ. ನಾನು ಅದನ್ನು ಎಲ್ಲೋ ಉಳಿಸಿದ್ದೇನೆ ಮತ್ತು ನಿಖರವಾಗಿ ಎಲ್ಲಿದೆ ಎಂಬುದನ್ನು ಮರೆತುಬಿಡುತ್ತೇನೆ.
ಪ್ರಶ್ನೆ ವರ್ಗದ ಮೂಲಕ ಗುಂಪು ಮಾಡಲಾದ ನಿಮ್ಮ ಭಾರೀ ಪ್ರಶ್ನೆಗಳು ಇಲ್ಲಿವೆ ಎಂದು ಸರಳವಾಗಿ ಹೇಳುವ ಸಾಧನವೊಂದು ಇರಬೇಕೆಂದು ನಾನು ಬಯಸುತ್ತೇನೆ. ನಾನು ಒಂದನ್ನು ಒತ್ತಿದಿದ್ದೇನೆ ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಅದು ಭಾರವಾಗಿದೆ ಎಂದು ಅವರು ನನಗೆ ಹೇಳುತ್ತಿದ್ದರು. ಈಗ ಅಂತಹ ಪರಿಹಾರವಿಲ್ಲ. ಮತ್ತು ಜನರು ನನ್ನನ್ನು ಕೇಳಿದಾಗ ಇದು ನಿಜವಾಗಿಯೂ ವಿಚಿತ್ರವಾಗಿದೆ: “ಹೇಳಿ, ಗ್ರಾಫಾನಾಗೆ ಯಾವುದೇ ರೆಡಿಮೇಡ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳಿವೆಯೇ?”, ನಾನು ಹೇಳುತ್ತೇನೆ: “ಗ್ರಾಫನಾ ವೆಬ್‌ಸೈಟ್‌ಗೆ ಹೋಗಿ, “ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳು” ಸಮುದಾಯವಿದೆ ಮತ್ತು ಡ್ಯಾಶ್ಬೋರ್ಡ್ ಇದೆ. ಡಿಮ್ಕಾದಿಂದ, ಕೋಸ್ಟ್ಯಾನ್‌ನಿಂದ ಡ್ಯಾಶ್ಬೋರ್ಡ್ ಇದೆ. ಅದು ಏನು ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ, ನಾನು ಅದನ್ನು ನಾನೇ ಬಳಸಿಲ್ಲ.
ಸರ್ವರ್ OOM ಗೆ ಕ್ರ್ಯಾಶ್ ಆಗದಂತೆ ವಿಲೀನಗಳ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರುವುದು ಹೇಗೆ?
ನನ್ನ ಬಳಿ ಟೇಬಲ್ ಇದೆ, ಟೇಬಲ್‌ನಲ್ಲಿ ಒಂದೇ ಒಂದು ವಿಭಾಗವಿದೆ, ಅದು ರಿಪ್ಲೇಸಿಂಗ್ ಮರ್ಜ್‌ಟ್ರೀ ಆಗಿದೆ. ನಾನು ನಾಲ್ಕು ವರ್ಷಗಳಿಂದ ಅದರಲ್ಲಿ ಡೇಟಾವನ್ನು ಬರೆಯುತ್ತಿದ್ದೇನೆ. ನಾನು ಅದರಲ್ಲಿ ಬದಲಾವಣೆಯನ್ನು ಮಾಡಬೇಕಾಗಿತ್ತು ಮತ್ತು ಕೆಲವು ಡೇಟಾವನ್ನು ಅಳಿಸಬೇಕಾಗಿದೆ.
ನಾನು ಇದನ್ನು ಮಾಡಿದ್ದೇನೆ ಮತ್ತು ಈ ವಿನಂತಿಯ ಪ್ರಕ್ರಿಯೆಯ ಸಮಯದಲ್ಲಿ, ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳಲ್ಲಿನ ಎಲ್ಲಾ ಮೆಮೊರಿಯನ್ನು ಸೇವಿಸಲಾಗಿದೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳು OOM ಗೆ ಹೋದವು. ನಂತರ ಅವರೆಲ್ಲರೂ ಒಟ್ಟಿಗೆ ಎದ್ದು, ಇದೇ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ವಿಲೀನಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸಿದರು, ಈ ಡೇಟಾ ಬ್ಲಾಕ್, ಮತ್ತು OOM ಗೆ ಮರಳಿದರು. ನಂತರ ಅವರು ಮತ್ತೆ ಎದ್ದು ಮತ್ತೆ ಬಿದ್ದರು. ಮತ್ತು ಈ ವಿಷಯ ನಿಲ್ಲಲಿಲ್ಲ.
ನಂತರ ಇದು ಹುಡುಗರು ಸರಿಪಡಿಸಿದ ದೋಷ ಎಂದು ಬದಲಾಯಿತು. ಇದು ತುಂಬಾ ತಂಪಾಗಿದೆ, ತುಂಬಾ ಧನ್ಯವಾದಗಳು. ಆದರೆ ಒಂದು ಶೇಷ ಉಳಿಯಿತು. ಮತ್ತು ಈಗ, ನಾನು ಟೇಬಲ್‌ನಲ್ಲಿ ಕೆಲವು ರೀತಿಯ ವಿಲೀನವನ್ನು ಮಾಡುವ ಬಗ್ಗೆ ಯೋಚಿಸಿದಾಗ, ನನಗೆ ಒಂದು ಪ್ರಶ್ನೆಯಿದೆ: ಈ ವಿಲೀನಗಳ ಮೇಲೆ ನಾನು ಹೇಗಾದರೂ ಪ್ರಭಾವ ಬೀರಲು ಸಾಧ್ಯವಿಲ್ಲ? ಉದಾಹರಣೆಗೆ, ಅಗತ್ಯವಿರುವ RAM ಪ್ರಮಾಣದಿಂದ ಅಥವಾ ತಾತ್ವಿಕವಾಗಿ, ಈ ನಿರ್ದಿಷ್ಟ ಕೋಷ್ಟಕವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಮೊತ್ತದಿಂದ ಅವುಗಳನ್ನು ಮಿತಿಗೊಳಿಸಿ.
ನನ್ನ ಬಳಿ "ಮೆಟ್ರಿಕ್ಸ್" ಎಂಬ ಟೇಬಲ್ ಇದೆ, ದಯವಿಟ್ಟು ನನಗೆ ಅದನ್ನು ಎರಡು ಥ್ರೆಡ್‌ಗಳಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿ. ಹತ್ತು ಅಥವಾ ಐದು ವಿಲೀನಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ಉತ್ಪಾದಿಸುವ ಅಗತ್ಯವಿಲ್ಲ, ಎರಡರಲ್ಲಿ ಮಾಡಿ. ನನ್ನಲ್ಲಿ ಇಬ್ಬರಿಗೆ ಸಾಕಷ್ಟು ಮೆಮೊರಿ ಇದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಆದರೆ ಹತ್ತನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಇದು ಸಾಕಾಗುವುದಿಲ್ಲ. ಭಯ ಏಕೆ ಉಳಿಯುತ್ತದೆ? ಏಕೆಂದರೆ ಟೇಬಲ್ ಬೆಳೆಯುತ್ತಿದೆ, ಮತ್ತು ಒಂದು ದಿನ ನಾನು ಪರಿಸ್ಥಿತಿಯನ್ನು ಎದುರಿಸುತ್ತೇನೆ, ಅದು ತಾತ್ವಿಕವಾಗಿ, ಇನ್ನು ಮುಂದೆ ದೋಷದಿಂದಾಗಿಲ್ಲ, ಆದರೆ ಡೇಟಾವು ಅಂತಹ ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ ಬದಲಾಗುವುದರಿಂದ ನಾನು ಸರ್ವರ್‌ನಲ್ಲಿ ಸಾಕಷ್ಟು ಮೆಮೊರಿಯನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. . ತದನಂತರ ವಿಲೀನಗೊಳಿಸುವಾಗ ಸರ್ವರ್ OOM ಗೆ ಬೀಳುತ್ತದೆ. ಇದಲ್ಲದೆ, ನಾನು ರೂಪಾಂತರವನ್ನು ರದ್ದುಗೊಳಿಸಬಹುದು, ಆದರೆ ಮೆರ್ಜಿ ಇನ್ನು ಮುಂದೆ ಇರುವುದಿಲ್ಲ.
ನಿಮಗೆ ತಿಳಿದಿದೆ, ವಿಲೀನಗೊಳಿಸುವಾಗ, ಸರ್ವರ್ OOM ಗೆ ಬರುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ವಿಲೀನಗೊಳಿಸುವಾಗ, RAM ನ ಪ್ರಮಾಣವನ್ನು ಒಂದು ಸಣ್ಣ ಶ್ರೇಣಿಯ ಡೇಟಾಗೆ ಮಾತ್ರ ಬಳಸಲಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ ಡೇಟಾದ ಪ್ರಮಾಣವನ್ನು ಲೆಕ್ಕಿಸದೆ ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿರುತ್ತದೆ.
ವ್ಲಾಡಿಮಿರ್ ಕೊಲೊಬೇವ್: ಫೈನ್. ಇಲ್ಲಿ ಕ್ಷಣವೆಂದರೆ ದೋಷವನ್ನು ಸರಿಪಡಿಸಿದ ನಂತರ, ನಾನು ನನಗಾಗಿ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ್ದೇನೆ ಮತ್ತು ಇನ್ನೊಂದು ಟೇಬಲ್‌ನಲ್ಲಿ ಚಿಕ್ಕದಾಗಿದೆ, ಅಲ್ಲಿ ಅನೇಕ ವಿಭಾಗಗಳಿವೆ, ನಾನು ಇದೇ ರೀತಿಯ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಮಾಡಿದ್ದೇನೆ. ಮತ್ತು ವಿಲೀನದ ಸಮಯದಲ್ಲಿ, ಸುಮಾರು 100 GB RAM ಅನ್ನು ಸರ್ವರ್‌ನಲ್ಲಿ ಸುಡಲಾಯಿತು. ನಾನು 150 ಆಕ್ರಮಿಸಿಕೊಂಡಿದ್ದೇನೆ, 100 ತಿನ್ನುತ್ತಿದ್ದೆ ಮತ್ತು 50 GB ವಿಂಡೋ ಉಳಿದಿದೆ, ಹಾಗಾಗಿ ನಾನು OOM ಗೆ ಬೀಳಲಿಲ್ಲ.
ಇದು ನಿಜವಾಗಿ 100 GB RAM ಅನ್ನು ಬಳಸಿದರೆ OOM ಗೆ ಬೀಳದಂತೆ ಪ್ರಸ್ತುತ ಏನು ರಕ್ಷಿಸುತ್ತದೆ? ವಿಲೀನದಲ್ಲಿ RAM ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಖಾಲಿಯಾದರೆ ನೀವು ಏನು ಮಾಡಬೇಕು?
ಅಲೆಕ್ಸಿ ಮಿಲೋವಿಡೋವ್: RAM ಬಳಕೆಯು ವಿಲೀನಕ್ಕೆ ಸೀಮಿತವಾಗಿಲ್ಲ ಎಂಬ ಸಮಸ್ಯೆ ಇದೆ. ಮತ್ತು ಎರಡನೆಯ ಸಮಸ್ಯೆಯೆಂದರೆ, ಕೆಲವು ರೀತಿಯ ವಿಲೀನವನ್ನು ನಿಯೋಜಿಸಿದ್ದರೆ, ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕು ಏಕೆಂದರೆ ಅದು ಪ್ರತಿಕೃತಿ ಲಾಗ್‌ನಲ್ಲಿ ದಾಖಲಾಗಿದೆ. ಪ್ರತಿಕೃತಿ ಲಾಗ್ ಪ್ರತಿಕೃತಿಯನ್ನು ಸ್ಥಿರ ಸ್ಥಿತಿಗೆ ತರಲು ಅಗತ್ಯವಿರುವ ಕ್ರಿಯೆಗಳು. ಈ ಪ್ರತಿಕೃತಿ ಲಾಗ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುವ ಹಸ್ತಚಾಲಿತ ಮ್ಯಾನಿಪ್ಯುಲೇಷನ್‌ಗಳನ್ನು ನೀವು ಮಾಡದಿದ್ದರೆ, ವಿಲೀನವನ್ನು ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ ನಿರ್ವಹಿಸಬೇಕಾಗುತ್ತದೆ.
ಸಹಜವಾಗಿ, OOM ವಿರುದ್ಧ "ಕೇವಲ ಸಂದರ್ಭದಲ್ಲಿ" ರಕ್ಷಿಸುವ RAM ಮಿತಿಯನ್ನು ಹೊಂದಿರುವುದು ಅತಿಯಾಗಿರುವುದಿಲ್ಲ. ಇದು ವಿಲೀನವನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ, ಅದು ಮತ್ತೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಕೆಲವು ಮಿತಿಯನ್ನು ತಲುಪುತ್ತದೆ, ವಿನಾಯಿತಿಯನ್ನು ಎಸೆಯಿರಿ ಮತ್ತು ನಂತರ ಮತ್ತೆ ಪ್ರಾರಂಭಿಸಿ - ಇದರಿಂದ ಏನೂ ಒಳ್ಳೆಯದು ಬರುವುದಿಲ್ಲ. ಆದರೆ ತಾತ್ವಿಕವಾಗಿ, ಈ ನಿರ್ಬಂಧವನ್ನು ಪರಿಚಯಿಸಲು ಇದು ಉಪಯುಕ್ತವಾಗಿದೆ.
ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗಾಗಿ ಗೋಲಾಂಗ್ ಡ್ರೈವರ್ ಅನ್ನು ಹೇಗೆ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗುತ್ತದೆ?
ಕಿರಿಲ್ ಶ್ವಾಕೋವ್ ಬರೆದ ಗೋಲಾಂಗ್ ಡ್ರೈವರ್ ಅನ್ನು ಈಗ ಅಧಿಕೃತವಾಗಿ ಕ್ಲಿಕ್‌ಹೌಸ್ ತಂಡವು ಬೆಂಬಲಿಸುತ್ತದೆ. ಅವನು , ಅವರು ಈಗ ದೊಡ್ಡ ಮತ್ತು ನಿಜವಾದ.
ಒಂದು ಸಣ್ಣ ಟಿಪ್ಪಣಿ. ಅನಂತ ಕ್ರಮದ ಸಾಮಾನ್ಯ ರೂಪಗಳ ಅದ್ಭುತ ಮತ್ತು ಪ್ರೀತಿಯ ಭಂಡಾರವಿದೆ - ಇದು ವರ್ಟಿಕಾ. ಅವರು ತಮ್ಮದೇ ಆದ ಅಧಿಕೃತ ಪೈಥಾನ್ ಡ್ರೈವರ್ ಅನ್ನು ಸಹ ಹೊಂದಿದ್ದಾರೆ, ಇದನ್ನು ವರ್ಟಿಕಾ ಡೆವಲಪರ್‌ಗಳು ಬೆಂಬಲಿಸುತ್ತಾರೆ. ಮತ್ತು ಹಲವಾರು ಬಾರಿ ಶೇಖರಣಾ ಆವೃತ್ತಿಗಳು ಮತ್ತು ಚಾಲಕ ಆವೃತ್ತಿಗಳು ಸಾಕಷ್ಟು ನಾಟಕೀಯವಾಗಿ ಭಿನ್ನವಾಗಿವೆ, ಮತ್ತು ಚಾಲಕವು ಕೆಲವು ಹಂತದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿತು. ಮತ್ತು ಎರಡನೇ ಪಾಯಿಂಟ್. ಈ ಅಧಿಕೃತ ಡ್ರೈವರ್‌ಗೆ ಬೆಂಬಲವನ್ನು "ಮೊಲೆತೊಟ್ಟು" ವ್ಯವಸ್ಥೆಯಿಂದ ನಡೆಸಲಾಗುತ್ತದೆ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ - ನೀವು ಅವರಿಗೆ ಸಮಸ್ಯೆಯನ್ನು ಬರೆಯುತ್ತೀರಿ ಮತ್ತು ಅದು ಶಾಶ್ವತವಾಗಿ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ.
ನನಗೆ ಎರಡು ಪ್ರಶ್ನೆಗಳಿವೆ. ಈಗ ಕಿರಿಲ್‌ನ ಗೋಲಾಂಗ್ ಡ್ರೈವರ್ ಗೋಲಾಂಗ್‌ನಿಂದ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಬಹುತೇಕ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವಾಗಿದೆ. ಯಾರಾದರೂ ಇನ್ನೂ http ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಸಂವಹನ ಮಾಡದ ಹೊರತು ಅವರು ಅದನ್ನು ಇಷ್ಟಪಡುತ್ತಾರೆ. ಈ ಚಾಲಕನ ಅಭಿವೃದ್ಧಿಯು ಹೇಗೆ ಮುಂದುವರಿಯುತ್ತದೆ? ರೆಪೊಸಿಟರಿಯಲ್ಲಿಯೇ ಯಾವುದೇ ಬ್ರೇಕಿಂಗ್ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ಇದು ಸಿಂಕ್ರೊನೈಸ್ ಆಗುತ್ತದೆಯೇ? ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಗಣಿಸುವ ವಿಧಾನ ಯಾವುದು?
ಕಿರಿಲ್ ಶ್ವಾಕೋವ್: ಮೊದಲನೆಯದು ಎಲ್ಲವನ್ನೂ ಅಧಿಕಾರಶಾಹಿಯಾಗಿ ಹೇಗೆ ರಚಿಸಲಾಗಿದೆ. ಈ ವಿಷಯವನ್ನು ಚರ್ಚಿಸಲಾಗಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾನು ಉತ್ತರಿಸಲು ಏನೂ ಇಲ್ಲ.
ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಲು, ನಮಗೆ ಚಾಲಕನ ಸ್ವಲ್ಪ ಇತಿಹಾಸ ಬೇಕು. ನಾನು ಸಾಕಷ್ಟು ಡೇಟಾವನ್ನು ಹೊಂದಿರುವ ಕಂಪನಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ್ದೇನೆ. ಇದು ಎಲ್ಲೋ ಸಂಗ್ರಹಿಸಬೇಕಾದ ಬೃಹತ್ ಸಂಖ್ಯೆಯ ಈವೆಂಟ್‌ಗಳೊಂದಿಗೆ ಜಾಹೀರಾತು ಸ್ಪಿನ್ನರ್ ಆಗಿತ್ತು. ಮತ್ತು ಕೆಲವು ಹಂತದಲ್ಲಿ ಕ್ಲಿಕ್‌ಹೌಸ್ ಕಾಣಿಸಿಕೊಂಡಿತು. ನಾವು ಅದನ್ನು ಡೇಟಾದೊಂದಿಗೆ ತುಂಬಿದ್ದೇವೆ ಮತ್ತು ಮೊದಲಿಗೆ ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿತ್ತು, ಆದರೆ ನಂತರ ಕ್ಲಿಕ್‌ಹೌಸ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದೆ. ಆ ಕ್ಷಣದಲ್ಲಿ ನಮಗೆ ಅದು ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ನಿರ್ಧರಿಸಿದೆವು.
ಒಂದು ವರ್ಷದ ನಂತರ, ನಾವು ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಬಳಸುವ ಕಲ್ಪನೆಗೆ ಮರಳಿದೆವು ಮತ್ತು ನಾವು ಹೇಗಾದರೂ ಅಲ್ಲಿ ಡೇಟಾವನ್ನು ಬರೆಯಬೇಕಾಗಿದೆ. ಪರಿಚಯಾತ್ಮಕ ಸಂದೇಶ ಹೀಗಿತ್ತು: ಹಾರ್ಡ್‌ವೇರ್ ತುಂಬಾ ದುರ್ಬಲವಾಗಿದೆ, ಕೆಲವು ಸಂಪನ್ಮೂಲಗಳಿವೆ. ಆದರೆ ನಾವು ಯಾವಾಗಲೂ ಈ ರೀತಿ ಕೆಲಸ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಆದ್ದರಿಂದ ನಾವು ಸ್ಥಳೀಯ ಪ್ರೋಟೋಕಾಲ್ ಕಡೆಗೆ ನೋಡಿದ್ದೇವೆ.
ನಾವು ಗೋದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರಿಂದ, ನಮಗೆ ಗೋ ಡ್ರೈವರ್ ಅಗತ್ಯವಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಯಿತು. ನಾನು ಬಹುತೇಕ ಪೂರ್ಣ ಸಮಯವನ್ನು ಮಾಡಿದ್ದೇನೆ - ಇದು ನನ್ನ ಕೆಲಸದ ಕಾರ್ಯವಾಗಿತ್ತು. ನಾವು ಅದನ್ನು ಒಂದು ನಿರ್ದಿಷ್ಟ ಹಂತಕ್ಕೆ ತಂದಿದ್ದೇವೆ ಮತ್ತು ತಾತ್ವಿಕವಾಗಿ ಯಾರೂ ನಮ್ಮನ್ನು ಹೊರತುಪಡಿಸಿ ಬೇರೆಯವರು ಅದನ್ನು ಬಳಸುತ್ತಾರೆ ಎಂದು ಊಹಿಸಲಿಲ್ಲ. ನಂತರ ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ಅದೇ ಸಮಸ್ಯೆಯೊಂದಿಗೆ ಬಂದಿತು ಮತ್ತು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ನಾವು ಅವರೊಂದಿಗೆ ತುಂಬಾ ಸರಾಗವಾಗಿ ಕೆಲಸ ಮಾಡಿದೆವು, ಏಕೆಂದರೆ ಅವರು ಅದೇ ಕಾರ್ಯಗಳನ್ನು ಹೊಂದಿದ್ದರು. ಇದಲ್ಲದೆ, ನಾವು ಇದನ್ನು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಮತ್ತು ಡ್ರೈವರ್‌ನಲ್ಲಿ ಮಾಡಿದ್ದೇವೆ.
ಕೆಲವು ಹಂತದಲ್ಲಿ, ನಾನು ಅದನ್ನು ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿದೆ, ಏಕೆಂದರೆ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ದೃಷ್ಟಿಕೋನದಿಂದ ಮತ್ತು ನನ್ನ ಕೆಲಸದಿಂದ ನನ್ನ ಚಟುವಟಿಕೆ ಸ್ವಲ್ಪ ಬದಲಾಗಿದೆ. ಆದ್ದರಿಂದ ಸಮಸ್ಯೆಗಳನ್ನು ಮುಚ್ಚಲಾಗಿಲ್ಲ. ನಿಯತಕಾಲಿಕವಾಗಿ, ಏನನ್ನಾದರೂ ಅಗತ್ಯವಿರುವ ಜನರು ಭಂಡಾರಕ್ಕೆ ಬದ್ಧರಾಗುತ್ತಾರೆ. ನಂತರ ನಾನು ಪುಲ್ ವಿನಂತಿಯನ್ನು ನೋಡುತ್ತೇನೆ ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ನಾನು ಏನನ್ನಾದರೂ ಸಂಪಾದಿಸುತ್ತೇನೆ, ಆದರೆ ಇದು ವಿರಳವಾಗಿ ಸಂಭವಿಸುತ್ತದೆ.
ನಾನು ಚಾಲಕನಿಗೆ ಹಿಂತಿರುಗಲು ಬಯಸುತ್ತೇನೆ. ಕೆಲವು ವರ್ಷಗಳ ಹಿಂದೆ, ಈ ಸಂಪೂರ್ಣ ವಿಷಯ ಪ್ರಾರಂಭವಾದಾಗ, ಕ್ಲಿಕ್‌ಹೌಸ್ ಕೂಡ ವಿಭಿನ್ನವಾಗಿತ್ತು ಮತ್ತು ವಿಭಿನ್ನ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿತ್ತು. ಚಾಲಕವನ್ನು ಹೇಗೆ ರೀಮೇಕ್ ಮಾಡುವುದು ಎಂಬುದರ ಕುರಿತು ಈಗ ನಮಗೆ ತಿಳುವಳಿಕೆ ಇದೆ ಇದರಿಂದ ಅದು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು ಸಂಭವಿಸಿದಲ್ಲಿ, ಸಂಗ್ರಹವಾದ ಊರುಗೋಲುಗಳಿಂದಾಗಿ ಆವೃತ್ತಿ 2 ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.
ಈ ವಿಷಯವನ್ನು ಹೇಗೆ ಸಂಘಟಿಸುವುದು ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ. ನನಗೇ ಹೆಚ್ಚು ಸಮಯವಿಲ್ಲ. ಕೆಲವರು ಚಾಲಕನನ್ನು ಮುಗಿಸಿದರೆ, ನಾನು ಅವರಿಗೆ ಸಹಾಯ ಮಾಡುತ್ತೇನೆ ಮತ್ತು ಏನು ಮಾಡಬೇಕೆಂದು ಹೇಳುತ್ತೇನೆ. ಆದರೆ ಯೋಜನೆಯ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಯಾಂಡೆಕ್ಸ್ನ ಸಕ್ರಿಯ ಭಾಗವಹಿಸುವಿಕೆಯನ್ನು ಇನ್ನೂ ಚರ್ಚಿಸಲಾಗಿಲ್ಲ.
ಅಲೆಕ್ಸಿ ಮಿಲೋವಿಡೋವ್: ವಾಸ್ತವವಾಗಿ, ಈ ಚಾಲಕರ ಬಗ್ಗೆ ಇನ್ನೂ ಯಾವುದೇ ಅಧಿಕಾರಶಾಹಿ ಇಲ್ಲ. ಒಂದೇ ವಿಷಯವೆಂದರೆ ಅವುಗಳನ್ನು ಅಧಿಕೃತ ಸಂಸ್ಥೆಗೆ ಸಲ್ಲಿಸಲಾಗಿದೆ, ಅಂದರೆ, ಈ ಚಾಲಕವನ್ನು Go ಗಾಗಿ ಅಧಿಕೃತ ಡೀಫಾಲ್ಟ್ ಪರಿಹಾರವೆಂದು ಗುರುತಿಸಲಾಗಿದೆ. ಇನ್ನೂ ಕೆಲವು ಚಾಲಕರು ಇದ್ದಾರೆ, ಆದರೆ ಅವರು ಪ್ರತ್ಯೇಕವಾಗಿ ಬರುತ್ತಾರೆ.
ಈ ಚಾಲಕರಿಗೆ ನಾವು ಯಾವುದೇ ಆಂತರಿಕ ಬೆಳವಣಿಗೆಯನ್ನು ಹೊಂದಿಲ್ಲ. ಈ ನಿರ್ದಿಷ್ಟ ಚಾಲಕನಿಗೆ ಅಲ್ಲ, ಆದರೆ ಎಲ್ಲಾ ಸಮುದಾಯದ ಚಾಲಕರ ಅಭಿವೃದ್ಧಿಗಾಗಿ ನಾವು ಒಬ್ಬ ವ್ಯಕ್ತಿಯನ್ನು ನೇಮಿಸಿಕೊಳ್ಳಬಹುದೇ ಅಥವಾ ಹೊರಗಿನಿಂದ ಯಾರನ್ನಾದರೂ ಹುಡುಕಬಹುದೇ ಎಂಬುದು ಪ್ರಶ್ನೆ.
lazy_load ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದರೊಂದಿಗೆ ರೀಬೂಟ್ ಮಾಡಿದ ನಂತರ ಬಾಹ್ಯ ನಿಘಂಟನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ. ಏನ್ ಮಾಡೋದು?
ನಾವು lazy_load ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದ್ದೇವೆ ಮತ್ತು ಸರ್ವರ್ ಅನ್ನು ರೀಬೂಟ್ ಮಾಡಿದ ನಂತರ, ನಿಘಂಟು ತನ್ನದೇ ಆದ ಮೇಲೆ ಲೋಡ್ ಆಗುವುದಿಲ್ಲ. ಬಳಕೆದಾರರು ಈ ನಿಘಂಟನ್ನು ಪ್ರವೇಶಿಸಿದ ನಂತರವೇ ಇದನ್ನು ಹೆಚ್ಚಿಸಲಾಗುತ್ತದೆ. ಮತ್ತು ಮೊದಲ ಪ್ರವೇಶದಲ್ಲಿ ಅದು ದೋಷವನ್ನು ನೀಡುತ್ತದೆ. ಕ್ಲಿಕ್‌ಹೌಸ್ ಬಳಸಿ ನಿಘಂಟುಗಳನ್ನು ಹೇಗಾದರೂ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಲೋಡ್ ಮಾಡಲು ಸಾಧ್ಯವೇ ಅಥವಾ ಬಳಕೆದಾರರು ದೋಷಗಳನ್ನು ಸ್ವೀಕರಿಸದಂತೆ ನೀವು ಯಾವಾಗಲೂ ಅವರ ಸಿದ್ಧತೆಯನ್ನು ನೀವೇ ನಿಯಂತ್ರಿಸುವ ಅಗತ್ಯವಿದೆಯೇ?
ಬಹುಶಃ ನಾವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಹಳೆಯ ಆವೃತ್ತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ನಿಘಂಟು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಲೋಡ್ ಆಗಲಿಲ್ಲ. ಇದು ಹೀಗಿರಬಹುದೇ?
ಮೊದಲನೆಯದಾಗಿ, ಒಂದು ಪ್ರಶ್ನೆಯನ್ನು ಬಳಸಿಕೊಂಡು ನಿಘಂಟುಗಳನ್ನು ಬಲವಂತವಾಗಿ ಲೋಡ್ ಮಾಡಬಹುದು ಸಿಸ್ಟಮ್ ರೀಲೋಡ್ ನಿಘಂಟುಗಳು. ಎರಡನೆಯದಾಗಿ, ದೋಷದ ಬಗ್ಗೆ - ನಿಘಂಟನ್ನು ಈಗಾಗಲೇ ಲೋಡ್ ಮಾಡಿದ್ದರೆ, ನಂತರ ಪ್ರಶ್ನೆಗಳು ಲೋಡ್ ಮಾಡಲಾದ ಡೇಟಾವನ್ನು ಆಧರಿಸಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ನಿಘಂಟನ್ನು ಇನ್ನೂ ಲೋಡ್ ಮಾಡದಿದ್ದರೆ, ವಿನಂತಿಯ ಸಮಯದಲ್ಲಿ ಅದನ್ನು ನೇರವಾಗಿ ಲೋಡ್ ಮಾಡಲಾಗುತ್ತದೆ.
ಭಾರೀ ನಿಘಂಟುಗಳಿಗೆ ಇದು ತುಂಬಾ ಅನುಕೂಲಕರವಲ್ಲ. ಉದಾಹರಣೆಗೆ, ನೀವು MySQL ನಿಂದ ಮಿಲಿಯನ್ ಸಾಲುಗಳನ್ನು ಎಳೆಯುವ ಅಗತ್ಯವಿದೆ. ಯಾರೋ ಸರಳ ಆಯ್ಕೆ ಮಾಡುತ್ತಾರೆ, ಆದರೆ ಈ ಆಯ್ಕೆಯು ಅದೇ ಮಿಲಿಯನ್ ಸಾಲುಗಳಿಗಾಗಿ ಕಾಯುತ್ತದೆ. ಇಲ್ಲಿ ಎರಡು ಪರಿಹಾರಗಳಿವೆ. ಲೇಜಿ_ಲೋಡ್ ಅನ್ನು ಆಫ್ ಮಾಡುವುದು ಮೊದಲನೆಯದು. ಎರಡನೆಯದಾಗಿ, ಸರ್ವರ್ ಅಪ್ ಆಗಿರುವಾಗ, ಅದರ ಮೇಲೆ ಲೋಡ್ ಅನ್ನು ಹಾಕುವ ಮೊದಲು, ಮಾಡಿ ಸಿಸ್ಟಮ್ ರೀಲೋಡ್ ನಿಘಂಟು ಅಥವಾ ನಿಘಂಟನ್ನು ಬಳಸುವ ಪ್ರಶ್ನೆಯನ್ನು ಮಾಡಿ. ನಂತರ ನಿಘಂಟು ಲೋಡ್ ಆಗುತ್ತದೆ. Lazy_load ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದರೊಂದಿಗೆ ನೀವು ನಿಘಂಟುಗಳ ಲಭ್ಯತೆಯನ್ನು ನಿಯಂತ್ರಿಸಬೇಕಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ClickHouse ಅವುಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಲೋಡ್ ಮಾಡುವುದಿಲ್ಲ.
ಕೊನೆಯ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರವು ಆವೃತ್ತಿಯು ಹಳೆಯದಾಗಿದೆ ಅಥವಾ ಅದನ್ನು ಡೀಬಗ್ ಮಾಡಬೇಕಾಗಿದೆ.
ಸಿಸ್ಟಂ ರೀಲೋಡ್ ಡಿಕ್ಷನರಿಗಳು ಅನೇಕ ಡಿಕ್ಷನರಿಗಳಲ್ಲಿ ಒಂದಾದರೂ ದೋಷದಿಂದ ವಿಫಲವಾದಲ್ಲಿ ಯಾವುದನ್ನೂ ಲೋಡ್ ಮಾಡುವುದಿಲ್ಲ ಎಂಬ ಅಂಶವನ್ನು ಏನು ಮಾಡಬೇಕು?
ಸಿಸ್ಟಮ್ ರೀಲೋಡ್ ಡಿಕ್ಷನರಿಗಳ ಬಗ್ಗೆ ಮತ್ತೊಂದು ಪ್ರಶ್ನೆ ಇದೆ. ನಮ್ಮಲ್ಲಿ ಎರಡು ನಿಘಂಟುಗಳಿವೆ - ಒಂದನ್ನು ಲೋಡ್ ಮಾಡಲಾಗಿಲ್ಲ, ಎರಡನೆಯದು ಲೋಡ್ ಆಗಿದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸಿಸ್ಟಮ್ ರೀಲೋಡ್ ಡಿಕ್ಷನರಿಗಳು ಯಾವುದೇ ನಿಘಂಟನ್ನು ಲೋಡ್ ಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ಸಿಸ್ಟಮ್ ರೀಲೋಡ್ ನಿಘಂಟನ್ನು ಬಳಸಿಕೊಂಡು ಅದರ ಹೆಸರಿನಿಂದ ನಿರ್ದಿಷ್ಟವಾದ ಒಂದನ್ನು ಪಾಯಿಂಟ್-ಬೈ-ಪಾಯಿಂಟ್ ಲೋಡ್ ಮಾಡಬೇಕು. ಇದು ಕ್ಲಿಕ್‌ಹೌಸ್ ಆವೃತ್ತಿಗೂ ಸಂಬಂಧಿಸಿದೆಯೇ?
ನಾನು ನಿನ್ನನ್ನು ಸಂತೋಷಪಡಿಸಲು ಬಯಸುತ್ತೇನೆ. ಈ ನಡವಳಿಕೆ ಬದಲಾಗುತ್ತಿತ್ತು. ಇದರರ್ಥ ನೀವು ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ನವೀಕರಿಸಿದರೆ, ಅದು ಸಹ ಬದಲಾಗುತ್ತದೆ. ನಿಮ್ಮ ಪ್ರಸ್ತುತ ನಡವಳಿಕೆಯಿಂದ ನೀವು ಸಂತೋಷವಾಗಿರದಿದ್ದರೆ ಸಿಸ್ಟಮ್ ರೀಲೋಡ್ ನಿಘಂಟುಗಳು, ನಿಮ್ಮನ್ನು ನವೀಕರಿಸಿ, ಮತ್ತು ಅದು ಉತ್ತಮವಾಗಿ ಬದಲಾಗುತ್ತದೆ ಎಂದು ಭಾವಿಸೋಣ.
ಕ್ಲಿಕ್‌ಹೌಸ್ ಕಾನ್ಫಿಗರ್‌ನಲ್ಲಿ ವಿವರಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಒಂದು ಮಾರ್ಗವಿದೆಯೇ, ಆದರೆ ದೋಷಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಅವುಗಳನ್ನು ಪ್ರದರ್ಶಿಸುವುದಿಲ್ಲವೇ?
ಮುಂದಿನ ಪ್ರಶ್ನೆಯು ನಿಘಂಟಿಗೆ ಸಂಬಂಧಿಸಿದ ದೋಷಗಳ ಬಗ್ಗೆ, ಅವುಗಳೆಂದರೆ ವಿವರಗಳು. ನಾವು ನಿಘಂಟಿಗಾಗಿ ಕ್ಲಿಕ್‌ಹೌಸ್ ಕಾನ್ಫಿಗರ್‌ನಲ್ಲಿ ಸಂಪರ್ಕ ವಿವರಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ್ದೇವೆ ಮತ್ತು ದೋಷವಿದ್ದರೆ, ನಾವು ಈ ವಿವರಗಳನ್ನು ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ಸ್ವೀಕರಿಸುತ್ತೇವೆ.
ODBC ಡ್ರೈವರ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ವಿವರಗಳನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ನಾವು ಈ ದೋಷವನ್ನು ಪರಿಹರಿಸಿದ್ದೇವೆ. ಕ್ಲಿಕ್‌ಹೌಸ್ ಕಾನ್ಫಿಗರ್‌ನಲ್ಲಿ ವಿವರಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಯಾವುದೇ ಮಾರ್ಗವಿದೆಯೇ, ಆದರೆ ದೋಷಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಈ ವಿವರಗಳನ್ನು ಪ್ರದರ್ಶಿಸುವುದಿಲ್ಲವೇ?
ಇಲ್ಲಿ ನಿಜವಾದ ಪರಿಹಾರವೆಂದರೆ ಈ ರುಜುವಾತುಗಳನ್ನು odbc.ini ನಲ್ಲಿ ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿಯೇ ODBC ಡೇಟಾ ಮೂಲ ಹೆಸರನ್ನು ಮಾತ್ರ ನಿರ್ದಿಷ್ಟಪಡಿಸುವುದು. ಇತರ ನಿಘಂಟು ಮೂಲಗಳಿಗೆ ಇದು ಸಂಭವಿಸುವುದಿಲ್ಲ - MySQL ನೊಂದಿಗೆ ನಿಘಂಟಿಗಾಗಿ ಅಥವಾ ಇತರರಿಗೆ, ದೋಷ ಸಂದೇಶವನ್ನು ಸ್ವೀಕರಿಸುವಾಗ ನೀವು ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ನೋಡಬಾರದು. ODBC ಗಾಗಿ, ನಾನು ಸಹ ನೋಡುತ್ತೇನೆ - ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದರೆ, ನೀವು ಅದನ್ನು ತೆಗೆದುಹಾಕಬೇಕಾಗಿದೆ.
ಬೋನಸ್: ಕೂಟಗಳಿಂದ ಹಿನ್ನೆಲೆಗಳನ್ನು ಜೂಮ್ ಮಾಡಿ
ಚಿತ್ರದ ಮೇಲೆ ಕ್ಲಿಕ್ ಮಾಡುವುದರ ಮೂಲಕ, ಕೂಟಗಳ ಬೋನಸ್ ಹಿನ್ನೆಲೆಗಳು ಹೆಚ್ಚು ನಿರಂತರ ಓದುಗರಿಗೆ ತೆರೆದುಕೊಳ್ಳುತ್ತವೆ. ನಾವು Avito ತಂತ್ರಜ್ಞಾನದ ಮ್ಯಾಸ್ಕಾಟ್‌ಗಳೊಂದಿಗೆ ಬೆಂಕಿಯನ್ನು ನಂದಿಸುತ್ತೇವೆ, ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರ ಕೊಠಡಿ ಅಥವಾ ಹಳೆಯ ಶಾಲಾ ಕಂಪ್ಯೂಟರ್ ಕ್ಲಬ್‌ನ ಸಹೋದ್ಯೋಗಿಗಳೊಂದಿಗೆ ಸಮಾಲೋಚಿಸುತ್ತೇವೆ ಮತ್ತು ಗೀಚುಬರಹದ ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಸೇತುವೆಯ ಕೆಳಗೆ ದೈನಂದಿನ ಸಭೆಗಳನ್ನು ನಡೆಸುತ್ತೇವೆ.
ಮೂಲ: www.habr.com