ಪ್ರೊಹೋಸ್ಟರ್ > Блог > ಆಡಳಿತ > ಮೆಟ್ರಿಕ್ಸ್ ಸಂಗ್ರಹಣೆ: ನಾವು ಗ್ರ್ಯಾಫೈಟ್+ವಿಸ್ಪರ್ನಿಂದ ಗ್ರ್ಯಾಫೈಟ್+ಕ್ಲಿಕ್ಹೌಸ್ಗೆ ಹೇಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ
ಮೆಟ್ರಿಕ್ಸ್ ಸಂಗ್ರಹಣೆ: ನಾವು ಗ್ರ್ಯಾಫೈಟ್+ವಿಸ್ಪರ್ನಿಂದ ಗ್ರ್ಯಾಫೈಟ್+ಕ್ಲಿಕ್ಹೌಸ್ಗೆ ಹೇಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ
ಎಲ್ಲರಿಗು ನಮಸ್ಖರ! ಅವನಲ್ಲಿ ಕೊನೆಯ ಲೇಖನ ಮೈಕ್ರೋ ಸರ್ವಿಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ಗಾಗಿ ಮಾಡ್ಯುಲರ್ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಆಯೋಜಿಸುವ ಬಗ್ಗೆ ನಾನು ಬರೆದಿದ್ದೇನೆ. ಯಾವುದೂ ಇನ್ನೂ ನಿಂತಿಲ್ಲ, ನಮ್ಮ ಯೋಜನೆಯು ನಿರಂತರವಾಗಿ ಬೆಳೆಯುತ್ತಿದೆ ಮತ್ತು ಸಂಗ್ರಹಿಸಲಾದ ಮೆಟ್ರಿಕ್ಗಳ ಸಂಖ್ಯೆಯೂ ಇದೆ. ಹೆಚ್ಚಿನ ಲೋಡ್ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಗ್ರ್ಯಾಫೈಟ್+ವಿಸ್ಪರ್ನಿಂದ ಗ್ರ್ಯಾಫೈಟ್+ಕ್ಲಿಕ್ಹೌಸ್ಗೆ ಪರಿವರ್ತನೆಯನ್ನು ನಾವು ಹೇಗೆ ಆಯೋಜಿಸಿದ್ದೇವೆ, ಅದರಿಂದ ನಿರೀಕ್ಷೆಗಳು ಮತ್ತು ಕಟ್ ಅಡಿಯಲ್ಲಿ ವಲಸೆಯ ಫಲಿತಾಂಶಗಳ ಬಗ್ಗೆ ಓದಿ.
ಗ್ರ್ಯಾಫೈಟ್+ವಿಸ್ಪರ್ನಲ್ಲಿ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದರಿಂದ ಗ್ರ್ಯಾಫೈಟ್+ಕ್ಲಿಕ್ಹೌಸ್ಗೆ ಪರಿವರ್ತನೆಯನ್ನು ನಾವು ಹೇಗೆ ಆಯೋಜಿಸಿದ್ದೇವೆ ಎಂಬುದನ್ನು ನಾನು ನಿಮಗೆ ಹೇಳುವ ಮೊದಲು, ಅಂತಹ ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಕಾರಣಗಳ ಬಗ್ಗೆ ಮತ್ತು ನಾವು ದೀರ್ಘಕಾಲ ವಾಸಿಸುತ್ತಿದ್ದ ವಿಸ್ಪರ್ನ ಅನಾನುಕೂಲತೆಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ನೀಡಲು ನಾನು ಬಯಸುತ್ತೇನೆ.
ಗ್ರ್ಯಾಫೈಟ್+ವಿಸ್ಪರ್ ಸಮಸ್ಯೆಗಳು
1. ಡಿಸ್ಕ್ ಉಪವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಹೆಚ್ಚಿನ ಲೋಡ್
ಪರಿವರ್ತನೆಯ ಸಮಯದಲ್ಲಿ, ಪ್ರತಿ ನಿಮಿಷಕ್ಕೆ ಸರಿಸುಮಾರು 1.5 ಮಿಲಿಯನ್ ಮೆಟ್ರಿಕ್ಗಳು ನಮ್ಮ ಬಳಿಗೆ ಬರುತ್ತಿದ್ದವು. ಅಂತಹ ಹರಿವಿನೊಂದಿಗೆ, ಸರ್ವರ್ಗಳಲ್ಲಿ ಡಿಸ್ಕ್ ಬಳಕೆಯು ~30% ಆಗಿತ್ತು. ಸಾಮಾನ್ಯವಾಗಿ, ಇದು ಸಾಕಷ್ಟು ಸ್ವೀಕಾರಾರ್ಹವಾಗಿತ್ತು - ಎಲ್ಲವೂ ಸ್ಥಿರವಾಗಿ ಕೆಲಸ ಮಾಡಿದೆ, ತ್ವರಿತವಾಗಿ ಬರೆಯಲಾಗಿದೆ, ತ್ವರಿತವಾಗಿ ಓದುತ್ತದೆ ... ಅಭಿವೃದ್ಧಿ ತಂಡಗಳಲ್ಲಿ ಒಂದು ಹೊಸ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊರತರುವವರೆಗೆ ಮತ್ತು ನಿಮಿಷಕ್ಕೆ 10 ಮಿಲಿಯನ್ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ನಮಗೆ ಕಳುಹಿಸಲು ಪ್ರಾರಂಭಿಸಿತು. ಡಿಸ್ಕ್ ಉಪವ್ಯವಸ್ಥೆಯು ಬಿಗಿಯಾದಾಗ ಮತ್ತು ನಾವು 100% ಬಳಕೆಯನ್ನು ನೋಡಿದ್ದೇವೆ. ಸಮಸ್ಯೆಯನ್ನು ತ್ವರಿತವಾಗಿ ಪರಿಹರಿಸಲಾಯಿತು, ಆದರೆ ಶೇಷವು ಉಳಿದಿದೆ.
2. ಪುನರಾವರ್ತನೆ ಮತ್ತು ಸ್ಥಿರತೆಯ ಕೊರತೆ
ಹೆಚ್ಚಾಗಿ, ಗ್ರ್ಯಾಫೈಟ್+ವಿಸ್ಪರ್ ಅನ್ನು ಬಳಸುವ/ಬಳಸುವ ಪ್ರತಿಯೊಬ್ಬರಂತೆ, ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಸೃಷ್ಟಿಸುವ ಸಲುವಾಗಿ ನಾವು ಒಂದೇ ಬಾರಿಗೆ ಹಲವಾರು ಗ್ರ್ಯಾಫೈಟ್ ಸರ್ವರ್ಗಳಲ್ಲಿ ಒಂದೇ ರೀತಿಯ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಸುರಿಯುತ್ತೇವೆ. ಮತ್ತು ಇದರೊಂದಿಗೆ ಯಾವುದೇ ವಿಶೇಷ ಸಮಸ್ಯೆಗಳಿಲ್ಲ - ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ಸರ್ವರ್ಗಳಲ್ಲಿ ಒಂದು ಕ್ರ್ಯಾಶ್ ಆಗುವ ಕ್ಷಣದವರೆಗೆ. ಕೆಲವೊಮ್ಮೆ ನಾವು ಬಿದ್ದ ಸರ್ವರ್ ಅನ್ನು ತ್ವರಿತವಾಗಿ ತೆಗೆದುಕೊಳ್ಳಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಕಾರ್ಬನ್-ಸಿ-ರಿಲೇ ಅದರ ಸಂಗ್ರಹದಿಂದ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಲೋಡ್ ಮಾಡಲು ನಿರ್ವಹಿಸುತ್ತಿದೆ, ಆದರೆ ಕೆಲವೊಮ್ಮೆ ಅಲ್ಲ. ತದನಂತರ ಮೆಟ್ರಿಕ್ಸ್ನಲ್ಲಿ ರಂಧ್ರವಿತ್ತು, ಅದನ್ನು ನಾವು rsync ನೊಂದಿಗೆ ತುಂಬಿದ್ದೇವೆ. ಕಾರ್ಯವಿಧಾನವು ಸಾಕಷ್ಟು ಉದ್ದವಾಗಿತ್ತು. ಇದು ಬಹಳ ವಿರಳವಾಗಿ ಸಂಭವಿಸಿತು ಎಂಬುದು ಮಾತ್ರ ಉಳಿಸುವ ಅನುಗ್ರಹವಾಗಿದೆ. ನಾವು ನಿಯತಕಾಲಿಕವಾಗಿ ಮೆಟ್ರಿಕ್ಗಳ ಯಾದೃಚ್ಛಿಕ ಸೆಟ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್ನ ನೆರೆಯ ನೋಡ್ಗಳಲ್ಲಿ ಅದೇ ರೀತಿಯ ಇತರರೊಂದಿಗೆ ಹೋಲಿಸುತ್ತೇವೆ. ಸುಮಾರು 5% ಪ್ರಕರಣಗಳಲ್ಲಿ, ಹಲವಾರು ಮೌಲ್ಯಗಳು ವಿಭಿನ್ನವಾಗಿವೆ, ಅದು ನಮಗೆ ತುಂಬಾ ಸಂತೋಷವಾಗಿರಲಿಲ್ಲ.
3. ದೊಡ್ಡ ಹೆಜ್ಜೆಗುರುತು
ನಾವು ಗ್ರ್ಯಾಫೈಟ್ನಲ್ಲಿ ಮೂಲಸೌಕರ್ಯ ಮಾತ್ರವಲ್ಲದೆ ವ್ಯಾಪಾರದ ಮೆಟ್ರಿಕ್ಗಳನ್ನು (ಮತ್ತು ಈಗ ಕುಬರ್ನೆಟ್ಸ್ನ ಮೆಟ್ರಿಕ್ಗಳು ಸಹ) ಬರೆಯುವುದರಿಂದ, ಮೆಟ್ರಿಕ್ ಕೆಲವೇ ಮೌಲ್ಯಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಪರಿಸ್ಥಿತಿಯನ್ನು ನಾವು ಆಗಾಗ್ಗೆ ಪಡೆಯುತ್ತೇವೆ ಮತ್ತು ಎಲ್ಲಾ ಧಾರಣವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು .wsp ಫೈಲ್ ಅನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ ಅವಧಿ, ಮತ್ತು ಮೊದಲೇ ನಿಗದಿಪಡಿಸಿದ ಜಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಅದು ನಮಗೆ ~2MB ಆಗಿತ್ತು. ಕಾಲಾನಂತರದಲ್ಲಿ ಬಹಳಷ್ಟು ರೀತಿಯ ಫೈಲ್ಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಅವುಗಳ ಮೇಲೆ ವರದಿಗಳನ್ನು ನಿರ್ಮಿಸುವಾಗ, ಖಾಲಿ ಅಂಕಗಳನ್ನು ಓದುವುದು ಸಾಕಷ್ಟು ಸಮಯ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂಬ ಅಂಶದಿಂದ ಸಮಸ್ಯೆಯನ್ನು ಇನ್ನಷ್ಟು ಉಲ್ಬಣಗೊಳಿಸಲಾಗುತ್ತದೆ.
ಮೇಲೆ ವಿವರಿಸಿದ ಸಮಸ್ಯೆಗಳನ್ನು ವಿವಿಧ ವಿಧಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಮತ್ತು ವಿವಿಧ ಹಂತದ ಪರಿಣಾಮಕಾರಿತ್ವದೊಂದಿಗೆ ವ್ಯವಹರಿಸಬಹುದು ಎಂದು ನಾನು ತಕ್ಷಣ ಗಮನಿಸಲು ಬಯಸುತ್ತೇನೆ, ಆದರೆ ನೀವು ಹೆಚ್ಚು ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ಅವು ಇನ್ನಷ್ಟು ಹದಗೆಡುತ್ತವೆ.
ಮೇಲಿನ ಎಲ್ಲವನ್ನು ಹೊಂದಿರುವುದು (ಹಿಂದಿನದನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು ಲೇಖನಗಳು), ಹಾಗೆಯೇ ಸ್ವೀಕರಿಸಿದ ಮೆಟ್ರಿಕ್ಗಳ ಸಂಖ್ಯೆಯಲ್ಲಿ ನಿರಂತರ ಹೆಚ್ಚಳ, ಎಲ್ಲಾ ಮೆಟ್ರಿಕ್ಗಳನ್ನು 30 ಸೆಕೆಂಡುಗಳ ಶೇಖರಣಾ ಮಧ್ಯಂತರಕ್ಕೆ ವರ್ಗಾಯಿಸುವ ಬಯಕೆ. (ಅಗತ್ಯವಿದ್ದರೆ 10 ಸೆಕೆಂಡುಗಳವರೆಗೆ), ನಾವು ವಿಸ್ಪರ್ಗೆ ಭರವಸೆಯ ಪರ್ಯಾಯವಾಗಿ ಗ್ರ್ಯಾಫೈಟ್+ಕ್ಲಿಕ್ಹೌಸ್ ಅನ್ನು ಪ್ರಯತ್ನಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.
ಗ್ರ್ಯಾಫೈಟ್+ಕ್ಲಿಕ್ಹೌಸ್. ನಿರೀಕ್ಷೆಗಳು
ಯಾಂಡೆಕ್ಸ್ನ ಹುಡುಗರ ಹಲವಾರು ಸಭೆಗಳಿಗೆ ಭೇಟಿ ನೀಡಿದ ನಂತರ, ಓದಿದ ನಂತರ ಹಬ್ರೆ ಕುರಿತು ಒಂದೆರಡು ಲೇಖನಗಳು, ದಸ್ತಾವೇಜನ್ನು ಪರಿಶೀಲಿಸಿದ ನಂತರ ಮತ್ತು ಗ್ರ್ಯಾಫೈಟ್ ಅಡಿಯಲ್ಲಿ ಕ್ಲಿಕ್ಹೌಸ್ ಅನ್ನು ಬಂಧಿಸಲು ಸರಿಯಾದ ಘಟಕಗಳನ್ನು ಕಂಡುಕೊಂಡ ನಂತರ, ನಾವು ಕ್ರಮ ತೆಗೆದುಕೊಳ್ಳಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ!
ನಾನು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಬಯಸುತ್ತೇನೆ:
ಡಿಸ್ಕ್ ಉಪವ್ಯವಸ್ಥೆಯ ಬಳಕೆಯನ್ನು 30% ರಿಂದ 5% ಕ್ಕೆ ಕಡಿಮೆ ಮಾಡಿ;
1TB ನಿಂದ 100GB ಗೆ ಆಕ್ರಮಿಸಿಕೊಂಡಿರುವ ಜಾಗದ ಪ್ರಮಾಣವನ್ನು ಕಡಿಮೆ ಮಾಡಿ;
ಪ್ರತಿ ನಿಮಿಷಕ್ಕೆ 100 ಮಿಲಿಯನ್ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಸರ್ವರ್ಗೆ ಸ್ವೀಕರಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ;
ಡೇಟಾ ಪ್ರತಿಕೃತಿ ಮತ್ತು ಬಾಕ್ಸ್ ಹೊರಗೆ ತಪ್ಪು ಸಹಿಷ್ಣುತೆ;
ಒಂದು ವರ್ಷದವರೆಗೆ ಈ ಯೋಜನೆಯಲ್ಲಿ ಕುಳಿತುಕೊಳ್ಳಬೇಡಿ ಮತ್ತು ಸಮಂಜಸವಾದ ಸಮಯದ ಚೌಕಟ್ಟಿನೊಳಗೆ ಪರಿವರ್ತನೆ ಮಾಡಿ;
ಅಲಭ್ಯತೆ ಇಲ್ಲದೆ ಬದಲಿಸಿ.
ಸಾಕಷ್ಟು ಮಹತ್ವಾಕಾಂಕ್ಷೆಯ, ಸರಿ?
ಗ್ರ್ಯಾಫೈಟ್+ಕ್ಲಿಕ್ಹೌಸ್. ಘಟಕಗಳು
ಗ್ರ್ಯಾಫೈಟ್ ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಲು ಮತ್ತು ನಂತರ ಅದನ್ನು ಕ್ಲಿಕ್ಹೌಸ್ನಲ್ಲಿ ರೆಕಾರ್ಡ್ ಮಾಡಲು, ನಾನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇನೆ ಕಾರ್ಬನ್-ಕ್ಲಿಕ್ಹೌಸ್ (ಗೋಲಾಂಗ್).
ಕ್ಲಿಕ್ಹೌಸ್ನ ಇತ್ತೀಚಿನ ಬಿಡುಗಡೆ, ಸ್ಥಿರ ಆವೃತ್ತಿ 1.1.54253, ಸಮಯ ಸರಣಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಡೇಟಾಬೇಸ್ನಂತೆ ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ. ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಸಮಸ್ಯೆಗಳಿದ್ದವು: ದೋಷಗಳ ಪರ್ವತವು ಲಾಗ್ಗಳಲ್ಲಿ ಸುರಿಯಿತು, ಮತ್ತು ಅವರೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕೆಂದು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ಜೊತೆ ಚರ್ಚೆಯಲ್ಲಿದೆ ರೋಮನ್ ಲೋಮೊನೊಸೊವ್ (ಕಾರ್ಬನ್-ಕ್ಲಿಕ್ಹೌಸ್, ಗ್ರ್ಯಾಫೈಟ್-ಕ್ಲಿಕ್ಹೌಸ್ ಮತ್ತು ಇನ್ನೂ ಹಲವು) ಹಳೆಯದನ್ನು ಆಯ್ಕೆ ಮಾಡಲಾಗಿದೆ ಬಿಡುಗಡೆ 1.1.54236. ದೋಷಗಳು ಕಣ್ಮರೆಯಾಯಿತು - ಎಲ್ಲವೂ ಅಬ್ಬರದಿಂದ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿತು.
"ಗ್ರ್ಯಾಫೈಟ್" ಎಂಬುದು ಕೋಷ್ಟಕಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ನಾವು ರಚಿಸಿದ ಡೇಟಾಬೇಸ್ ಆಗಿದೆ.
"graphite.metrics" - ReplicatedReplacingMergeTree ಎಂಜಿನ್ ಹೊಂದಿರುವ ಟೇಬಲ್ (ನಕಲು ಮಾಡಲಾಗಿದೆ MergeTree ಅನ್ನು ಬದಲಿಸುವುದು) ಈ ಕೋಷ್ಟಕವು ಮೆಟ್ರಿಕ್ಗಳ ಹೆಸರುಗಳು ಮತ್ತು ಅವುಗಳಿಗೆ ಮಾರ್ಗಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ.
“graphite.data” - ರೆಪ್ಲಿಕೇಟೆಡ್ ಗ್ರಾಫೈಟ್ಮರ್ಜ್ಟ್ರೀ ಎಂಜಿನ್ನೊಂದಿಗೆ ಟೇಬಲ್ (ನಕಲಿಸಲಾಗಿದೆ GraphiteMergeTree) ಈ ಟೇಬಲ್ ಮೆಟ್ರಿಕ್ ಮೌಲ್ಯಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ.
CREATE TABLE graphite.data ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = ReplicatedGraphiteMergeTree('/clickhouse/tables/replicator/graphite.data', 'r1', Date, (Path, Time), 8192, 'graphite_rollup')
"graphite.date_metrics" ಎಂಬುದು ReplicatedReplacingMergeTree ಎಂಜಿನ್ನೊಂದಿಗೆ ಷರತ್ತುಬದ್ಧವಾಗಿ ತುಂಬಿದ ಟೇಬಲ್ ಆಗಿದೆ. ಈ ಕೋಷ್ಟಕವು ದಿನದಲ್ಲಿ ಎದುರಾಗುವ ಎಲ್ಲಾ ಮೆಟ್ರಿಕ್ಗಳ ಹೆಸರುಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಅದರ ರಚನೆಯ ಕಾರಣಗಳನ್ನು ವಿಭಾಗದಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ "ಸಮಸ್ಯೆಗಳು" ಈ ಲೇಖನದ ಕೊನೆಯಲ್ಲಿ.
CREATE MATERIALIZED VIEW graphite.date_metrics ( Path String, Level UInt32, Date Date) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.date_metrics', 'r1', Date, (Level, Path, Date), 8192) AS SELECT toUInt32(length(splitByChar('.', Path))) AS Level, Date, Path FROM graphite.data
“graphite.data_stat” - ರೆಪ್ಲಿಕೇಟೆಡ್ಅಗ್ರೆಗೇಟಿಂಗ್ಮರ್ಜ್ಟ್ರೀ ಎಂಜಿನ್ನೊಂದಿಗೆ ಷರತ್ತುಗಳಿಗೆ ಅನುಗುಣವಾಗಿ ತುಂಬಿದ ಟೇಬಲ್ (ಪ್ರತಿರೂಪಿಸಲಾಗಿದೆ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆ ಮರ್ಜ್ ಟ್ರೀ) ಈ ಕೋಷ್ಟಕವು ಒಳಬರುವ ಮೆಟ್ರಿಕ್ಗಳ ಸಂಖ್ಯೆಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಇದನ್ನು 4 ಗೂಡುಕಟ್ಟುವ ಹಂತಗಳಿಗೆ ವಿಭಜಿಸುತ್ತದೆ.
CREATE MATERIALIZED VIEW graphite.data_stat ( Date Date, Prefix String, Timestamp UInt32, Count AggregateFunction(count)) ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/replicator/graphite.data_stat', 'r1', Date, (Timestamp, Prefix), 8192) AS SELECT toStartOfMonth(now()) AS Date, replaceRegexpOne(Path, '^([^.]+.[^.]+.[^.]+).*$', '1') AS Prefix, toUInt32(toStartOfMinute(toDateTime(Timestamp))) AS Timestamp, countState() AS Count FROM graphite.data GROUP BY Timestamp, Prefix
ಈ ಪ್ರಾಜೆಕ್ಟ್ನ ನಿರೀಕ್ಷೆಗಳಿಂದ ನಾವು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವಂತೆ, ಕ್ಲಿಕ್ಹೌಸ್ಗೆ ಪರಿವರ್ತನೆಯು ಅಲಭ್ಯತೆಯಿಲ್ಲದೆ ಇರಬೇಕು; ಅದರ ಪ್ರಕಾರ, ನಾವು ಹೇಗಾದರೂ ನಮ್ಮ ಬಳಕೆದಾರರಿಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ಪಾರದರ್ಶಕವಾಗಿ ಹೊಸ ಸಂಗ್ರಹಣೆಗೆ ನಮ್ಮ ಸಂಪೂರ್ಣ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಬದಲಾಯಿಸಬೇಕಾಗಿತ್ತು.
ನಾವು ಇದನ್ನು ಹೇಗೆ ಮಾಡಿದ್ದೇವೆ.
ಕ್ಲಿಕ್ಹೌಸ್ ಕೋಷ್ಟಕಗಳ ಪುನರಾವರ್ತನೆಯಲ್ಲಿ ಭಾಗವಹಿಸುವ ಸರ್ವರ್ಗಳ ಕಾರ್ಬನ್-ಕ್ಲಿಕ್ಹೌಸ್ಗೆ ಮೆಟ್ರಿಕ್ಗಳ ಹೆಚ್ಚುವರಿ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಕಳುಹಿಸಲು ಕಾರ್ಬನ್-ಸಿ-ರಿಲೇಗೆ ನಿಯಮವನ್ನು ಸೇರಿಸಲಾಗಿದೆ.
ನಾವು ಪೈಥಾನ್ನಲ್ಲಿ ಸಣ್ಣ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಬರೆದಿದ್ದೇವೆ, ಇದು ವಿಸ್ಪರ್-ಡಂಪ್ ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಿಕೊಂಡು, ನಮ್ಮ ಸಂಗ್ರಹಣೆಯಿಂದ ಎಲ್ಲಾ .wsp ಫೈಲ್ಗಳನ್ನು ಓದುತ್ತದೆ ಮತ್ತು ಈ ಡೇಟಾವನ್ನು ಮೇಲಿನ-ವಿವರಿಸಿದ ಕಾರ್ಬನ್-ಕ್ಲಿಕ್ಹೌಸ್ಗೆ 24 ಥ್ರೆಡ್ಗಳಲ್ಲಿ ಕಳುಹಿಸಿದೆ. ಕಾರ್ಬನ್-ಕ್ಲಿಕ್ಹೌಸ್ನಲ್ಲಿ ಅಂಗೀಕರಿಸಲ್ಪಟ್ಟ ಮೆಟ್ರಿಕ್ ಮೌಲ್ಯಗಳ ಸಂಖ್ಯೆಯು 125 ಮಿಲಿಯನ್/ನಿಮಿಷವನ್ನು ತಲುಪಿತು ಮತ್ತು ಕ್ಲಿಕ್ಹೌಸ್ ಬೆವರನ್ನೂ ಮುರಿಯಲಿಲ್ಲ.
ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗಳಲ್ಲಿ ಬಳಸಲಾದ ಕಾರ್ಯಗಳನ್ನು ಡೀಬಗ್ ಮಾಡಲು ನಾವು ಗ್ರಾಫಾನಾದಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಡೇಟಾಸೋರ್ಸ್ ಅನ್ನು ರಚಿಸಿದ್ದೇವೆ. ನಾವು ಬಳಸಿದ ಕಾರ್ಯಗಳ ಪಟ್ಟಿಯನ್ನು ನಾವು ಗುರುತಿಸಿದ್ದೇವೆ, ಆದರೆ ಅವುಗಳನ್ನು ಕಾರ್ಬೊನಾಪಿಯಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿಲ್ಲ. ನಾವು ಈ ಕಾರ್ಯಗಳನ್ನು ಸೇರಿಸಿದ್ದೇವೆ ಮತ್ತು ಕಾರ್ಬೊನಾಪಿಯ ಲೇಖಕರಿಗೆ PR ಗಳನ್ನು ಕಳುಹಿಸಿದ್ದೇವೆ (ಅವರಿಗೆ ವಿಶೇಷ ಧನ್ಯವಾದಗಳು).
ಬ್ಯಾಲೆನ್ಸರ್ ಸೆಟ್ಟಿಂಗ್ಗಳಲ್ಲಿ ಓದುವ ಲೋಡ್ ಅನ್ನು ಬದಲಾಯಿಸಲು, ನಾವು ಗ್ರ್ಯಾಫೈಟ್-ಎಪಿಐ (ಗ್ರ್ಯಾಫೈಟ್+ವಿಸ್ಪರ್ಗಾಗಿ ಎಪಿಐ ಇಂಟರ್ಫೇಸ್) ನಿಂದ ಕಾರ್ಬೊನಾಪಿಗೆ ಎಂಡ್ಪಾಯಿಂಟ್ಗಳನ್ನು ಬದಲಾಯಿಸಿದ್ದೇವೆ.
ಗ್ರ್ಯಾಫೈಟ್+ಕ್ಲಿಕ್ಹೌಸ್. ಫಲಿತಾಂಶಗಳು
ಡಿಸ್ಕ್ ಉಪವ್ಯವಸ್ಥೆಯ ಬಳಕೆಯನ್ನು 30% ರಿಂದ 1% ಕ್ಕೆ ಇಳಿಸಲಾಗಿದೆ;
1 TB ನಿಂದ 300 GB ವರೆಗೆ ಆಕ್ರಮಿಸಿಕೊಂಡಿರುವ ಜಾಗದ ಪ್ರಮಾಣವನ್ನು ಕಡಿಮೆ ಮಾಡಿದೆ;
ನಾವು ಪ್ರತಿ ನಿಮಿಷಕ್ಕೆ 125 ಮಿಲಿಯನ್ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಸರ್ವರ್ಗೆ ಸ್ವೀಕರಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ (ವಲಸೆಯ ಸಮಯದಲ್ಲಿ ಗರಿಷ್ಠ);
ಎಲ್ಲಾ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಮೂವತ್ತು-ಸೆಕೆಂಡ್ ಶೇಖರಣಾ ಮಧ್ಯಂತರಕ್ಕೆ ವರ್ಗಾಯಿಸಲಾಗಿದೆ;
ಸ್ವೀಕರಿಸಿದ ಡೇಟಾ ಪ್ರತಿಕೃತಿ ಮತ್ತು ತಪ್ಪು ಸಹಿಷ್ಣುತೆ;
ಅಲಭ್ಯತೆ ಇಲ್ಲದೆ ಬದಲಾಯಿಸಲಾಗಿದೆ;
ಎಲ್ಲವನ್ನೂ ಪೂರ್ಣಗೊಳಿಸಲು ಸುಮಾರು 7 ವಾರಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು.
ಗ್ರ್ಯಾಫೈಟ್+ಕ್ಲಿಕ್ಹೌಸ್. ಸಮಸ್ಯೆಗಳು
ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಕೆಲವು ಮೋಸಗಳು ಇದ್ದವು. ಪರಿವರ್ತನೆಯ ನಂತರ ನಾವು ಎದುರಿಸಿದ್ದು ಇದನ್ನೇ.
ಕ್ಲಿಕ್ಹೌಸ್ ಯಾವಾಗಲೂ ಫ್ಲೈನಲ್ಲಿ ಸಂರಚನೆಗಳನ್ನು ಪುನಃ ಓದುವುದಿಲ್ಲ; ಕೆಲವೊಮ್ಮೆ ಅದನ್ನು ರೀಬೂಟ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಕ್ಲಿಕ್ಹೌಸ್ ಸಂರಚನೆಯಲ್ಲಿನ ಝೂಕೀಪರ್ ಕ್ಲಸ್ಟರ್ನ ವಿವರಣೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ಕ್ಲಿಕ್ಹೌಸ್-ಸರ್ವರ್ ಅನ್ನು ರೀಬೂಟ್ ಮಾಡುವವರೆಗೆ ಅದನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ.
ದೊಡ್ಡ ಕ್ಲಿಕ್ಹೌಸ್ ವಿನಂತಿಗಳು ಹಾದುಹೋಗಲಿಲ್ಲ, ಆದ್ದರಿಂದ ಗ್ರ್ಯಾಫೈಟ್-ಕ್ಲಿಕ್ಹೌಸ್ನಲ್ಲಿ ನಮ್ಮ ಕ್ಲಿಕ್ಹೌಸ್ ಸಂಪರ್ಕ ಸ್ಟ್ರಿಂಗ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
ಕ್ಲಿಕ್ಹೌಸ್ ಸ್ಥಿರ ಬಿಡುಗಡೆಗಳ ಹೊಸ ಆವೃತ್ತಿಗಳನ್ನು ಆಗಾಗ್ಗೆ ಬಿಡುಗಡೆ ಮಾಡುತ್ತದೆ; ಅವುಗಳು ಆಶ್ಚರ್ಯವನ್ನು ಹೊಂದಿರಬಹುದು: ಜಾಗರೂಕರಾಗಿರಿ.
ಕುಬರ್ನೆಟ್ಗಳಲ್ಲಿ ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ರಚಿಸಲಾದ ಕಂಟೈನರ್ಗಳು ಕಡಿಮೆ ಮತ್ತು ಯಾದೃಚ್ಛಿಕ ಜೀವಿತಾವಧಿಯೊಂದಿಗೆ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಕಳುಹಿಸುತ್ತವೆ. ಅಂತಹ ಮೆಟ್ರಿಕ್ಗಳಿಗೆ ಹೆಚ್ಚಿನ ಅಂಕಗಳಿಲ್ಲ, ಮತ್ತು ಜಾಗದಲ್ಲಿ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲ. ಆದರೆ ಪ್ರಶ್ನೆಗಳನ್ನು ನಿರ್ಮಿಸುವಾಗ, ಕ್ಲಿಕ್ಹೌಸ್ 'ಮೆಟ್ರಿಕ್ಸ್' ಕೋಷ್ಟಕದಿಂದ ಇದೇ ರೀತಿಯ ಮೆಟ್ರಿಕ್ಗಳ ದೊಡ್ಡ ಸಂಖ್ಯೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. 90% ಪ್ರಕರಣಗಳಲ್ಲಿ, ವಿಂಡೋ (24 ಗಂಟೆಗಳ) ಆಚೆಗೆ ಅವುಗಳ ಮೇಲೆ ಯಾವುದೇ ಡೇಟಾ ಇಲ್ಲ. ಆದರೆ 'ಡೇಟಾ' ಕೋಷ್ಟಕದಲ್ಲಿ ಈ ಡೇಟಾವನ್ನು ಹುಡುಕಲು ಸಮಯವನ್ನು ಕಳೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಅಂತಿಮವಾಗಿ ಸಮಯ ಮೀರುತ್ತದೆ. ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನಾವು ದಿನದಲ್ಲಿ ಎದುರಿಸಿದ ಮೆಟ್ರಿಕ್ಗಳ ಮಾಹಿತಿಯೊಂದಿಗೆ ಪ್ರತ್ಯೇಕ ವೀಕ್ಷಣೆಯನ್ನು ನಿರ್ವಹಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಹೀಗಾಗಿ, ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ರಚಿಸಲಾದ ಕಂಟೇನರ್ಗಳಿಗಾಗಿ ವರದಿಗಳನ್ನು (ಗ್ರಾಫ್ಗಳು) ನಿರ್ಮಿಸುವಾಗ, ನಿರ್ದಿಷ್ಟ ವಿಂಡೋದಲ್ಲಿ ಎದುರಾಗುವ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಮಾತ್ರ ನಾವು ಪ್ರಶ್ನಿಸುತ್ತೇವೆ ಮತ್ತು ಸಂಪೂರ್ಣ ಸಮಯಕ್ಕೆ ಅಲ್ಲ, ಅದು ಅವುಗಳ ಮೇಲೆ ವರದಿಗಳ ನಿರ್ಮಾಣವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ವೇಗಗೊಳಿಸುತ್ತದೆ. ಮೇಲೆ ವಿವರಿಸಿದ ಪರಿಹಾರಕ್ಕಾಗಿ, ನಾನು ಸಂಗ್ರಹಿಸಿದೆ ಗ್ರ್ಯಾಫೈಟ್-ಕ್ಲಿಕ್ ಹೌಸ್ (ಫೋರ್ಕ್), ಇದು ದಿನಾಂಕ_ಮೆಟ್ರಿಕ್ಸ್ ಕೋಷ್ಟಕದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಅನುಷ್ಠಾನವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.
ಗ್ರ್ಯಾಫೈಟ್+ಕ್ಲಿಕ್ಹೌಸ್. ಟ್ಯಾಗ್ಗಳು
1.1.0 ಆವೃತ್ತಿಯೊಂದಿಗೆ ಗ್ರ್ಯಾಫೈಟ್ ಅಧಿಕೃತವಾಯಿತು ಬೆಂಬಲ ಟ್ಯಾಗ್ಗಳು. ಮತ್ತು ಗ್ರ್ಯಾಫೈಟ್+ಕ್ಲಿಕ್ಹೌಸ್ ಸ್ಟಾಕ್ನಲ್ಲಿ ಈ ಉಪಕ್ರಮವನ್ನು ಬೆಂಬಲಿಸಲು ಏನು ಮತ್ತು ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ನಾವು ಸಕ್ರಿಯವಾಗಿ ಯೋಚಿಸುತ್ತಿದ್ದೇವೆ.
ಗ್ರ್ಯಾಫೈಟ್+ಕ್ಲಿಕ್ಹೌಸ್. ಅಸಂಗತತೆ ಪತ್ತೆಕಾರಕ
ಮೇಲೆ ವಿವರಿಸಿದ ಮೂಲಸೌಕರ್ಯವನ್ನು ಆಧರಿಸಿ, ನಾವು ಅಸಂಗತತೆ ಪತ್ತೆಕಾರಕದ ಮೂಲಮಾದರಿಯನ್ನು ಅಳವಡಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ! ಆದರೆ ಮುಂದಿನ ಲೇಖನದಲ್ಲಿ ಅವನ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು.
ಚಂದಾದಾರರಾಗಿ, ಮೇಲಿನ ಬಾಣವನ್ನು ಒತ್ತಿ ಮತ್ತು ಸಂತೋಷವಾಗಿರಿ!