ಟೈಮ್‌ಸ್ಕೇಲ್‌ಡಿಬಿ ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಬ್ಯಾಕೆಂಡ್‌ನಂತೆ Zabbix ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ. ಮೊದಲಿನಿಂದ ಹೇಗೆ ಪ್ರಾರಂಭಿಸಬೇಕು ಮತ್ತು PostgreSQL ನಿಂದ ಹೇಗೆ ವಲಸೆ ಹೋಗಬೇಕು ಎಂಬುದನ್ನು ನಾವು ನಿಮಗೆ ತೋರಿಸುತ್ತೇವೆ. ನಾವು ಎರಡು ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳ ತುಲನಾತ್ಮಕ ಕಾರ್ಯಕ್ಷಮತೆ ಪರೀಕ್ಷೆಗಳನ್ನು ಸಹ ಒದಗಿಸುತ್ತೇವೆ.
ಹೈಲೋಡ್++ ಸೈಬೀರಿಯಾ 2019. ಟಾಮ್ಸ್ಕ್ ಹಾಲ್. ಜೂನ್ 24, 16:00. ಪ್ರಬಂಧಗಳು ಮತ್ತು . ಮುಂದಿನ HighLoad++ ಸಮ್ಮೇಳನವನ್ನು 6 ರ ಏಪ್ರಿಲ್ 7 ಮತ್ತು 2020 ರಂದು ಸೇಂಟ್ ಪೀಟರ್ಸ್‌ಬರ್ಗ್‌ನಲ್ಲಿ ನಡೆಸಲಾಗುವುದು. ವಿವರಗಳು ಮತ್ತು ಟಿಕೆಟ್‌ಗಳು .
ಆಂಡ್ರೆ ಗುಶ್ಚಿನ್ (ಇನ್ನು ಮುಂದೆ - ಎಜಿ): - ನಾನು ZABBIX ತಾಂತ್ರಿಕ ಬೆಂಬಲ ಎಂಜಿನಿಯರ್ (ಇನ್ನು ಮುಂದೆ "Zabbix" ಎಂದು ಉಲ್ಲೇಖಿಸಲಾಗುತ್ತದೆ), ತರಬೇತುದಾರ. ನಾನು 6 ವರ್ಷಗಳಿಗೂ ಹೆಚ್ಚು ಕಾಲ ತಾಂತ್ರಿಕ ಬೆಂಬಲದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇನೆ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯೊಂದಿಗೆ ನೇರ ಅನುಭವವನ್ನು ಹೊಂದಿದ್ದೇನೆ. ನಿಯಮಿತವಾದ PostgreSQL 10 ರೊಂದಿಗೆ ಹೋಲಿಸಿದಾಗ TimescaleDB ಒದಗಿಸಬಹುದಾದ ಕಾರ್ಯಕ್ಷಮತೆಯ ಕುರಿತು ಇಂದು ನಾನು ಮಾತನಾಡುತ್ತೇನೆ. ಅಲ್ಲದೆ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಕೆಲವು ಪರಿಚಯಾತ್ಮಕ ಭಾಗವಾಗಿದೆ.
ಉನ್ನತ ಉತ್ಪಾದಕತೆಯ ಸವಾಲುಗಳು: ಡೇಟಾ ಸಂಗ್ರಹಣೆಯಿಂದ ಡೇಟಾ ಶುದ್ಧೀಕರಣದವರೆಗೆ
ಮೊದಲಿಗೆ, ಪ್ರತಿ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್ ಎದುರಿಸುವ ಕೆಲವು ಕಾರ್ಯಕ್ಷಮತೆ ಸವಾಲುಗಳಿವೆ. ಮೊದಲ ಉತ್ಪಾದಕತೆಯ ಸವಾಲು ಡೇಟಾವನ್ನು ತ್ವರಿತವಾಗಿ ಸಂಗ್ರಹಿಸುವುದು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದು.
ಉತ್ತಮ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯು ತ್ವರಿತವಾಗಿ, ಸಮಯೋಚಿತವಾಗಿ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಬೇಕು, ಪ್ರಚೋದಕ ಅಭಿವ್ಯಕ್ತಿಗಳ ಪ್ರಕಾರ ಅದನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕು, ಅಂದರೆ, ಕೆಲವು ಮಾನದಂಡಗಳ ಪ್ರಕಾರ (ಇದು ವಿಭಿನ್ನ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ವಿಭಿನ್ನವಾಗಿದೆ) ಮತ್ತು ಈ ಡೇಟಾವನ್ನು ಬಳಸಲು ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಉಳಿಸಿ ಭವಿಷ್ಯ
ಎರಡನೇ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸವಾಲು ಇತಿಹಾಸ ಸಂಗ್ರಹವಾಗಿದೆ. ಆಗಾಗ್ಗೆ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ ಮತ್ತು ಸಮಯದ ಅವಧಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾದ ಈ ಮೆಟ್ರಿಕ್‌ಗಳಿಗೆ ತ್ವರಿತ ಮತ್ತು ಅನುಕೂಲಕರ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರಿ. ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯವೆಂದರೆ ಈ ಡೇಟಾವನ್ನು ಪಡೆಯಲು, ಅದನ್ನು ವರದಿಗಳು, ಗ್ರಾಫ್‌ಗಳು, ಟ್ರಿಗ್ಗರ್‌ಗಳು, ಕೆಲವು ಮಿತಿ ಮೌಲ್ಯಗಳಲ್ಲಿ, ಎಚ್ಚರಿಕೆಗಳಿಗಾಗಿ ಬಳಸಲು ಅನುಕೂಲಕರವಾಗಿದೆ.
ಮೂರನೆಯ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸವಾಲು ಇತಿಹಾಸವನ್ನು ತೆರವುಗೊಳಿಸುವುದು, ಅಂದರೆ, ನೀವು 5 ವರ್ಷಗಳಲ್ಲಿ (ತಿಂಗಳು ಅಥವಾ ಎರಡು ತಿಂಗಳುಗಳು) ಸಂಗ್ರಹಿಸಲಾದ ಯಾವುದೇ ವಿವರವಾದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲದ ಹಂತಕ್ಕೆ ಬಂದಾಗ. ಕೆಲವು ನೆಟ್‌ವರ್ಕ್ ನೋಡ್‌ಗಳನ್ನು ಅಳಿಸಲಾಗಿದೆ, ಅಥವಾ ಕೆಲವು ಹೋಸ್ಟ್‌ಗಳು, ಮೆಟ್ರಿಕ್‌ಗಳು ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲ ಏಕೆಂದರೆ ಅವುಗಳು ಈಗಾಗಲೇ ಹಳೆಯದಾಗಿದೆ ಮತ್ತು ಇನ್ನು ಮುಂದೆ ಸಂಗ್ರಹಿಸಲಾಗುವುದಿಲ್ಲ. ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ತುಂಬಾ ದೊಡ್ಡದಾಗಿ ಬೆಳೆಯದಂತೆ ಇದೆಲ್ಲವನ್ನೂ ಸ್ವಚ್ಛಗೊಳಿಸಬೇಕಾಗಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಇತಿಹಾಸವನ್ನು ತೆರವುಗೊಳಿಸುವುದು ಶೇಖರಣೆಗಾಗಿ ಗಂಭೀರ ಪರೀಕ್ಷೆಯಾಗಿದೆ - ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಬಲವಾದ ಪ್ರಭಾವ ಬೀರುತ್ತದೆ.
ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಸಮಸ್ಯೆಗಳನ್ನು ಹೇಗೆ ಪರಿಹರಿಸುವುದು?
ನಾನು ಈಗ ಜಬ್ಬಿಕ್ಸ್ ಬಗ್ಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ಮಾತನಾಡುತ್ತೇನೆ. Zabbix ನಲ್ಲಿ, ಮೊದಲ ಮತ್ತು ಎರಡನೆಯ ಕರೆಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಮೂಲಕ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ.
ಡೇಟಾ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಸಂಸ್ಕರಣೆ - ಈ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ನಾವು RAM ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಈ ಡೇಟಾವನ್ನು ಈಗ ಹೆಚ್ಚು ವಿವರವಾಗಿ ಚರ್ಚಿಸಲಾಗುವುದು.
ಡೇಟಾಬೇಸ್ ಬದಿಯಲ್ಲಿ ಮುಖ್ಯ ಆಯ್ಕೆಗಳಿಗಾಗಿ ಕೆಲವು ಕ್ಯಾಶಿಂಗ್ ಇದೆ - ಗ್ರಾಫ್‌ಗಳು ಮತ್ತು ಇತರ ವಿಷಯಗಳಿಗಾಗಿ.
Zabbix ಸರ್ವರ್‌ನ ಬದಿಯಲ್ಲಿಯೇ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದು: ನಾವು ಕಾನ್ಫಿಗರೇಶನ್‌ಕ್ಯಾಶ್, ವ್ಯಾಲ್ಯೂ ಕ್ಯಾಶ್, ಹಿಸ್ಟರಿ ಕ್ಯಾಶ್, ಟ್ರೆಂಡ್ಸ್‌ಕಾಶ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅದು ಏನು?
ಕಾನ್ಫಿಗರೇಶನ್‌ಕ್ಯಾಶ್ ನಾವು ಮೆಟ್ರಿಕ್‌ಗಳು, ಹೋಸ್ಟ್‌ಗಳು, ಡೇಟಾ ಐಟಂಗಳು, ಟ್ರಿಗ್ಗರ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಮುಖ್ಯ ಸಂಗ್ರಹವಾಗಿದೆ; ನೀವು ಪ್ರಿಪ್ರೊಸೆಸಿಂಗ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಅಗತ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ, ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು, ಯಾವ ಹೋಸ್ಟ್‌ಗಳಿಂದ ಸಂಗ್ರಹಿಸಲು, ಯಾವ ಆವರ್ತನದೊಂದಿಗೆ. ಡೇಟಾಬೇಸ್ಗೆ ಹೋಗದಂತೆ ಮತ್ತು ಅನಗತ್ಯ ಪ್ರಶ್ನೆಗಳನ್ನು ರಚಿಸದಂತೆ ಇವೆಲ್ಲವನ್ನೂ ಕಾನ್ಫಿಗರೇಶನ್‌ಕ್ಯಾಶ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ. ಸರ್ವರ್ ಪ್ರಾರಂಭವಾದ ನಂತರ, ನಾವು ಈ ಸಂಗ್ರಹವನ್ನು ನವೀಕರಿಸುತ್ತೇವೆ (ಅದನ್ನು ರಚಿಸಿ) ಮತ್ತು ಅದನ್ನು ನಿಯತಕಾಲಿಕವಾಗಿ ನವೀಕರಿಸಿ (ಕಾನ್ಫಿಗರೇಶನ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಅವಲಂಬಿಸಿ).
Zabbix ನಲ್ಲಿ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದು. ಮಾಹಿತಿ ಸಂಗ್ರಹ
ಇಲ್ಲಿ ರೇಖಾಚಿತ್ರವು ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿದೆ:
ಯೋಜನೆಯಲ್ಲಿ ಮುಖ್ಯವಾದವುಗಳು ಈ ಸಂಗ್ರಾಹಕರು:
ಇವುಗಳು ಅಸೆಂಬ್ಲಿ ಪ್ರಕ್ರಿಯೆಗಳು, ವಿವಿಧ ರೀತಿಯ ಅಸೆಂಬ್ಲಿಗಳಿಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ವಿವಿಧ "ಪೋಲರ್ಗಳು". ಅವರು icmp, ipmi, ಮತ್ತು ವಿವಿಧ ಪ್ರೋಟೋಕಾಲ್‌ಗಳ ಮೂಲಕ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತಾರೆ ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಪೂರ್ವ ಸಂಸ್ಕರಣೆಗೆ ವರ್ಗಾಯಿಸುತ್ತಾರೆ.
ಪೂರ್ವ ಸಂಸ್ಕರಣೆ ಇತಿಹಾಸ ಸಂಗ್ರಹ
ಅಲ್ಲದೆ, ನಾವು ಡೇಟಾ ಎಲಿಮೆಂಟ್‌ಗಳನ್ನು ಲೆಕ್ಕ ಹಾಕಿದ್ದರೆ (ಝಬ್ಬಿಕ್ಸ್‌ಗೆ ತಿಳಿದಿರುವವರಿಗೆ ತಿಳಿದಿದೆ), ಅಂದರೆ, ಲೆಕ್ಕಹಾಕಿದ, ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಯ ಡೇಟಾ ಅಂಶಗಳು, ನಾವು ಅವುಗಳನ್ನು ನೇರವಾಗಿ ವ್ಯಾಲ್ಯೂಕ್ಯಾಶ್‌ನಿಂದ ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ. ಅದು ಹೇಗೆ ತುಂಬುತ್ತದೆ ಎಂದು ನಾನು ನಿಮಗೆ ನಂತರ ಹೇಳುತ್ತೇನೆ. ಈ ಎಲ್ಲಾ ಸಂಗ್ರಾಹಕರು ತಮ್ಮ ಉದ್ಯೋಗಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಕಾನ್ಫಿಗರೇಶನ್ ಕ್ಯಾಶ್ ಅನ್ನು ಬಳಸುತ್ತಾರೆ ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಪೂರ್ವ ಸಂಸ್ಕರಣೆಗೆ ರವಾನಿಸುತ್ತಾರೆ.
ಪೂರ್ವ ಸಂಸ್ಕರಣೆಯು ಪೂರ್ವ ಸಂಸ್ಕರಣಾ ಹಂತಗಳನ್ನು ಪಡೆಯಲು ಕಾನ್ಫಿಗರೇಶನ್ ಕ್ಯಾಶ್ ಅನ್ನು ಸಹ ಬಳಸುತ್ತದೆ ಮತ್ತು ಈ ಡೇಟಾವನ್ನು ವಿವಿಧ ರೀತಿಯಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ. ಆವೃತ್ತಿ 4.2 ರಿಂದ ಪ್ರಾರಂಭಿಸಿ, ನಾವು ಅದನ್ನು ಪ್ರಾಕ್ಸಿಗೆ ಸರಿಸಿದ್ದೇವೆ. ಇದು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ, ಏಕೆಂದರೆ ಪ್ರಿಪ್ರೊಸೆಸಿಂಗ್ ಸ್ವತಃ ಕಷ್ಟಕರವಾದ ಕಾರ್ಯಾಚರಣೆಯಾಗಿದೆ. ಮತ್ತು ನೀವು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಡೇಟಾ ಅಂಶಗಳು ಮತ್ತು ಹೆಚ್ಚಿನ ಸಂಗ್ರಹ ಆವರ್ತನದೊಂದಿಗೆ ಬಹಳ ದೊಡ್ಡ Zabbix ಹೊಂದಿದ್ದರೆ, ಇದು ಕೆಲಸವನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸುತ್ತದೆ.
ಅಂತೆಯೇ, ಪೂರ್ವ ಸಂಸ್ಕರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಈ ಡೇಟಾವನ್ನು ಕೆಲವು ರೀತಿಯಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದ ನಂತರ, ಅದನ್ನು ಮತ್ತಷ್ಟು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ನಾವು ಅದನ್ನು ಹಿಸ್ಟರಿ ಕ್ಯಾಶ್‌ನಲ್ಲಿ ಉಳಿಸುತ್ತೇವೆ. ಇದು ಡೇಟಾ ಸಂಗ್ರಹಣೆಯನ್ನು ಮುಕ್ತಾಯಗೊಳಿಸುತ್ತದೆ. ನಾವು ಮುಖ್ಯ ಪ್ರಕ್ರಿಯೆಗೆ ಹೋಗುತ್ತೇವೆ.
ಇತಿಹಾಸ ಸಿನ್ಸರ್ ಕೆಲಸ
ಜಬ್ಬಿಕ್ಸ್‌ನಲ್ಲಿನ ಮುಖ್ಯ ಪ್ರಕ್ರಿಯೆ (ಇದು ಏಕಶಿಲೆಯ ಆರ್ಕಿಟೆಕ್ಚರ್ ಆಗಿರುವುದರಿಂದ) ಇತಿಹಾಸ ಸಿನ್ಸರ್ ಆಗಿದೆ. ಇದು ಪ್ರತಿ ಡೇಟಾ ಅಂಶದ ಪರಮಾಣು ಸಂಸ್ಕರಣೆಯೊಂದಿಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ವ್ಯವಹರಿಸುವ ಮುಖ್ಯ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ, ಅಂದರೆ, ಪ್ರತಿ ಮೌಲ್ಯ:
- ಮೌಲ್ಯವು ಬರುತ್ತದೆ (ಇದು ಇತಿಹಾಸ ಸಂಗ್ರಹದಿಂದ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ);
- ಕಾನ್ಫಿಗರೇಶನ್ ಸಿನ್ಸರ್‌ನಲ್ಲಿ ಪರಿಶೀಲಿಸುತ್ತದೆ: ಲೆಕ್ಕಾಚಾರಕ್ಕೆ ಯಾವುದೇ ಪ್ರಚೋದಕಗಳಿವೆಯೇ - ಅವುಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ;
ಇದ್ದರೆ - ಈವೆಂಟ್‌ಗಳನ್ನು ರಚಿಸುತ್ತದೆ, ಸಂರಚನೆಯ ಪ್ರಕಾರ ಅಗತ್ಯವಿದ್ದರೆ ಎಚ್ಚರಿಕೆಯನ್ನು ರಚಿಸಲು ಉಲ್ಬಣವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ; - ದಾಖಲೆಗಳು ನಂತರದ ಪ್ರಕ್ರಿಯೆಗೆ ಪ್ರಚೋದಕಗಳು, ಒಟ್ಟುಗೂಡಿಸುವಿಕೆ; ನೀವು ಕೊನೆಯ ಗಂಟೆಯಲ್ಲಿ ಒಟ್ಟುಗೂಡಿಸಿದರೆ ಮತ್ತು ಇತಿಹಾಸದ ಕೋಷ್ಟಕಕ್ಕೆ ಹೋಗದಂತೆ ಮೌಲ್ಯ ಸಂಗ್ರಹದಿಂದ ಈ ಮೌಲ್ಯವನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳಲಾಗುತ್ತದೆ; ಹೀಗಾಗಿ, ValueCache ಟ್ರಿಗ್ಗರ್‌ಗಳು, ಲೆಕ್ಕಹಾಕಿದ ಅಂಶಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಅಗತ್ಯವಾದ ಡೇಟಾದೊಂದಿಗೆ ತುಂಬಿರುತ್ತದೆ.
- ನಂತರ ಹಿಸ್ಟರಿ ಸಿನ್ಸರ್ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಡೇಟಾಬೇಸ್ಗೆ ಬರೆಯುತ್ತದೆ;
- ಡೇಟಾಬೇಸ್ ಅವುಗಳನ್ನು ಡಿಸ್ಕ್ಗೆ ಬರೆಯುತ್ತದೆ - ಇಲ್ಲಿ ಪ್ರಕ್ರಿಯೆ ಪ್ರಕ್ರಿಯೆಯು ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.
ಡೇಟಾಬೇಸ್. ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದು
ಡೇಟಾಬೇಸ್ ಬದಿಯಲ್ಲಿ, ನೀವು ಈವೆಂಟ್‌ಗಳ ಕುರಿತು ಗ್ರಾಫ್‌ಗಳು ಅಥವಾ ಕೆಲವು ವರದಿಗಳನ್ನು ವೀಕ್ಷಿಸಲು ಬಯಸಿದಾಗ, ವಿವಿಧ ಕ್ಯಾಶ್‌ಗಳಿವೆ. ಆದರೆ ಈ ವರದಿಯಲ್ಲಿ ನಾನು ಅವರ ಬಗ್ಗೆ ಮಾತನಾಡುವುದಿಲ್ಲ.
MySQL ಗಾಗಿ Innodb_buffer_pool ಇದೆ, ಮತ್ತು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದಾದ ವಿಭಿನ್ನ ಕ್ಯಾಶ್‌ಗಳ ಗುಂಪಿದೆ.
ಆದರೆ ಇವು ಮುಖ್ಯವಾದವುಗಳು:
- ಹಂಚಿದ_ಬಫರ್ಸ್;
- ಪರಿಣಾಮಕಾರಿ_ಸಂಗ್ರಹ_ಗಾತ್ರ;
- ಹಂಚಿದ_ಪೂಲ್.
ಎಲ್ಲಾ ಡೇಟಾಬೇಸ್‌ಗಳಿಗಾಗಿ, ಪ್ರಶ್ನೆಗಳಿಗೆ ಹೆಚ್ಚಾಗಿ ಅಗತ್ಯವಿರುವ ಡೇಟಾವನ್ನು RAM ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಕೆಲವು ಸಂಗ್ರಹಗಳಿವೆ ಎಂದು ನಾನು ಹೇಳಿದೆ. ಇದಕ್ಕಾಗಿ ಅವರು ತಮ್ಮದೇ ಆದ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ.
ಡೇಟಾಬೇಸ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಬಗ್ಗೆ
ಅಂತೆಯೇ, ಸ್ಪರ್ಧಾತ್ಮಕ ವಾತಾವರಣವಿದೆ, ಅಂದರೆ, Zabbix ಸರ್ವರ್ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಮರುಪ್ರಾರಂಭಿಸಿದಾಗ, ಮೌಲ್ಯ ಸಂಗ್ರಹವನ್ನು ತುಂಬಲು ಇದು ಇತಿಹಾಸದಿಂದ ಓದುತ್ತದೆ ಮತ್ತು ಹೀಗೆ. ವೆಬ್ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ Zabbix API ಅನ್ನು ಬಳಸುವ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಮತ್ತು ವರದಿಗಳನ್ನು ಇಲ್ಲಿ ನೀವು ಹೊಂದಬಹುದು. Zabbix API ಡೇಟಾಬೇಸ್ಗೆ ಪ್ರವೇಶಿಸುತ್ತದೆ ಮತ್ತು ಗ್ರಾಫ್‌ಗಳು, ವರದಿಗಳು ಅಥವಾ ಕೆಲವು ರೀತಿಯ ಘಟನೆಗಳ ಪಟ್ಟಿ, ಇತ್ತೀಚಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಪಡೆಯಲು ಅಗತ್ಯವಾದ ಡೇಟಾವನ್ನು ಪಡೆಯುತ್ತದೆ.
ನಮ್ಮ ಬಳಕೆದಾರರು ಬಳಸುವ ಗ್ರಾಫನಾ ಅತ್ಯಂತ ಜನಪ್ರಿಯ ದೃಶ್ಯೀಕರಣ ಪರಿಹಾರವಾಗಿದೆ. Zabbix API ಮೂಲಕ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಮೂಲಕ ನೇರವಾಗಿ ಲಾಗ್ ಇನ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಇದು ಡೇಟಾವನ್ನು ಪಡೆಯಲು ಒಂದು ನಿರ್ದಿಷ್ಟ ಸ್ಪರ್ಧೆಯನ್ನು ಸಹ ಸೃಷ್ಟಿಸುತ್ತದೆ: ಫಲಿತಾಂಶಗಳು ಮತ್ತು ಪರೀಕ್ಷೆಯ ತ್ವರಿತ ವಿತರಣೆಯನ್ನು ಅನುಸರಿಸಲು ಡೇಟಾಬೇಸ್ನ ಉತ್ತಮವಾದ, ಉತ್ತಮವಾದ ಶ್ರುತಿ ಅಗತ್ಯವಿದೆ.
ಇತಿಹಾಸವನ್ನು ತೆರವುಗೊಳಿಸುವುದು. ಜಬ್ಬಿಕ್ಸ್‌ಗೆ ಹೌಸ್ಕೀಪರ್ ಇದ್ದಾರೆ
ಜಬ್ಬಿಕ್ಸ್‌ನಲ್ಲಿ ಬಳಸಲಾಗುವ ಮೂರನೇ ಕರೆಯು ಹೌಸ್ಕೀಪರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಇತಿಹಾಸವನ್ನು ತೆರವುಗೊಳಿಸುತ್ತಿದೆ. ಹೌಸ್ಕೀಪರ್ ಎಲ್ಲಾ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಅನುಸರಿಸುತ್ತಾರೆ, ಅಂದರೆ, ನಮ್ಮ ಡೇಟಾ ಅಂಶಗಳು ಎಷ್ಟು ಸಮಯ ಸಂಗ್ರಹಿಸಬೇಕು (ದಿನಗಳಲ್ಲಿ), ಎಷ್ಟು ಸಮಯದವರೆಗೆ ಟ್ರೆಂಡ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಬೇಕು ಮತ್ತು ಬದಲಾವಣೆಗಳ ಡೈನಾಮಿಕ್ಸ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ.
ನಾನು ಟ್ರೆಂಡ್‌ಕ್ಯಾಶ್ ಬಗ್ಗೆ ಮಾತನಾಡಲಿಲ್ಲ, ನಾವು ಹಾರಾಡುತ್ತ ಲೆಕ್ಕ ಹಾಕುತ್ತೇವೆ: ಡೇಟಾ ಬರುತ್ತದೆ, ನಾವು ಅದನ್ನು ಒಂದು ಗಂಟೆಯವರೆಗೆ ಒಟ್ಟುಗೂಡಿಸುತ್ತೇವೆ (ಹೆಚ್ಚಾಗಿ ಇವು ಕೊನೆಯ ಗಂಟೆಯ ಸಂಖ್ಯೆಗಳು), ಮೊತ್ತವು ಸರಾಸರಿ/ಕನಿಷ್ಠ ಮತ್ತು ನಾವು ಅದನ್ನು ಗಂಟೆಗೆ ಒಮ್ಮೆ ರೆಕಾರ್ಡ್ ಮಾಡುತ್ತೇವೆ ಬದಲಾವಣೆಗಳ ಡೈನಾಮಿಕ್ಸ್ ಟೇಬಲ್ ("ಟ್ರೆಂಡ್ಸ್") . "ಹೌಸ್ಕೀಪರ್" ನಿಯಮಿತ ಆಯ್ಕೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಡೇಟಾಬೇಸ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಅಳಿಸುತ್ತದೆ, ಅದು ಯಾವಾಗಲೂ ಪರಿಣಾಮಕಾರಿಯಾಗಿರುವುದಿಲ್ಲ.
ಅದು ನಿಷ್ಪರಿಣಾಮಕಾರಿ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಹೇಗೆ? ಆಂತರಿಕ ಪ್ರಕ್ರಿಯೆಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯ ಗ್ರಾಫ್‌ಗಳಲ್ಲಿ ನೀವು ಈ ಕೆಳಗಿನ ಚಿತ್ರವನ್ನು ನೋಡಬಹುದು:
ನಿಮ್ಮ ಇತಿಹಾಸ ಸಿನ್ಸರ್ ನಿರಂತರವಾಗಿ ಕಾರ್ಯನಿರತವಾಗಿದೆ (ಕೆಂಪು ಗ್ರಾಫ್). ಮತ್ತು ಮೇಲಕ್ಕೆ ಹೋಗುವ "ಕೆಂಪು" ಗ್ರಾಫ್. ಇದು "ಹೌಸ್ಕೀಪರ್" ಆಗಿದ್ದು ಅದು ಡೇಟಾಬೇಸ್ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಎಲ್ಲಾ ಸಾಲುಗಳನ್ನು ಅಳಿಸಲು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ಕಾಯುತ್ತದೆ.
ಕೆಲವು ಐಟಂ ಐಡಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ: ನೀವು ಕೊನೆಯ 5 ಸಾವಿರವನ್ನು ಅಳಿಸಬೇಕಾಗಿದೆ; ಸಹಜವಾಗಿ, ಸೂಚ್ಯಂಕಗಳ ಮೂಲಕ. ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಡೇಟಾಸೆಟ್ ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿದೆ - ಡೇಟಾಬೇಸ್ ಇನ್ನೂ ಅದನ್ನು ಡಿಸ್ಕ್ನಿಂದ ಓದುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಸಂಗ್ರಹಕ್ಕೆ ಇರಿಸುತ್ತದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ಗೆ ಇದು ತುಂಬಾ ದುಬಾರಿ ಕಾರ್ಯಾಚರಣೆಯಾಗಿದೆ. ಅದರ ಗಾತ್ರವನ್ನು ಅವಲಂಬಿಸಿ, ಇದು ಕೆಲವು ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.
ನೀವು ಹೌಸ್ಕೀಪರ್ ಅನ್ನು ಸರಳ ರೀತಿಯಲ್ಲಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬಹುದು - ನಮಗೆ ಪರಿಚಿತ ವೆಬ್ ಇಂಟರ್ಫೇಸ್ ಇದೆ. ಆಡಳಿತದ ಸಾಮಾನ್ಯ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ("ಹೌಸ್ಕೀಪರ್" ಗಾಗಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳು) ನಾವು ಆಂತರಿಕ ಇತಿಹಾಸ ಮತ್ತು ಪ್ರವೃತ್ತಿಗಳಿಗಾಗಿ ಆಂತರಿಕ ಮನೆಗೆಲಸವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುತ್ತೇವೆ. ಅಂತೆಯೇ, ಹೌಸ್ಕೀಪರ್ ಇನ್ನು ಮುಂದೆ ಇದನ್ನು ನಿಯಂತ್ರಿಸುವುದಿಲ್ಲ:
ನೀವು ಮುಂದೆ ಏನು ಮಾಡಬಹುದು? ನೀವು ಅದನ್ನು ಆಫ್ ಮಾಡಿದ್ದೀರಿ, ನಿಮ್ಮ ಗ್ರಾಫ್‌ಗಳು ನೆಲಸಮವಾಗಿವೆ... ಈ ಸಂದರ್ಭದಲ್ಲಿ ಮುಂದೆ ಯಾವ ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸಬಹುದು? ಏನು ಸಹಾಯ ಮಾಡಬಹುದು?
ವಿಭಜನೆ (ವಿಭಾಗ)
ವಿಶಿಷ್ಟವಾಗಿ ನಾನು ಪಟ್ಟಿ ಮಾಡಿದ ಪ್ರತಿ ಸಂಬಂಧಿತ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಇದನ್ನು ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ. MySQL ತನ್ನದೇ ಆದ ತಂತ್ರಜ್ಞಾನವನ್ನು ಹೊಂದಿದೆ. ಆದರೆ ಒಟ್ಟಾರೆಯಾಗಿ PostgreSQL 10 ಮತ್ತು MySQL ಗೆ ಬಂದಾಗ ಅವು ತುಂಬಾ ಹೋಲುತ್ತವೆ. ಸಹಜವಾಗಿ, ಎಲ್ಲವನ್ನೂ ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಅದು ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದರಲ್ಲಿ ಬಹಳಷ್ಟು ಆಂತರಿಕ ವ್ಯತ್ಯಾಸಗಳಿವೆ. ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ, ಹೊಸ ವಿಭಾಗದ ರಚನೆಯು ಕೆಲವು ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ನಿಮ್ಮ ಸೆಟಪ್ ಅನ್ನು ಅವಲಂಬಿಸಿ (ಒಂದು ದಿನದಲ್ಲಿ ನೀವು ಎಷ್ಟು ಡೇಟಾವನ್ನು ರಚಿಸುತ್ತೀರಿ), ಅವರು ಸಾಮಾನ್ಯವಾಗಿ ಕನಿಷ್ಠವನ್ನು ಹೊಂದಿಸುತ್ತಾರೆ - ಇದು 1 ದಿನ / ಬ್ಯಾಚ್, ಮತ್ತು “ಟ್ರೆಂಡ್‌ಗಳು”, ಬದಲಾವಣೆಗಳ ಡೈನಾಮಿಕ್ಸ್ - 1 ತಿಂಗಳು / ಹೊಸ ಬ್ಯಾಚ್. ನೀವು ತುಂಬಾ ದೊಡ್ಡ ಸೆಟಪ್ ಹೊಂದಿದ್ದರೆ ಇದು ಬದಲಾಗಬಹುದು.
ಸೆಟಪ್‌ನ ಗಾತ್ರದ ಬಗ್ಗೆ ಈಗಿನಿಂದಲೇ ಹೇಳೋಣ: ಸೆಕೆಂಡಿಗೆ 5 ಸಾವಿರ ಹೊಸ ಮೌಲ್ಯಗಳು (nvps ಎಂದು ಕರೆಯಲ್ಪಡುವ) - ಇದನ್ನು ಸಣ್ಣ "ಸೆಟಪ್" ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಸರಾಸರಿ - ಸೆಕೆಂಡಿಗೆ 5 ರಿಂದ 25 ಸಾವಿರ ಮೌಲ್ಯಗಳು. ಮೇಲಿನ ಎಲ್ಲವು ಈಗಾಗಲೇ ದೊಡ್ಡದಾಗಿದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ನ ಅತ್ಯಂತ ಎಚ್ಚರಿಕೆಯಿಂದ ಸಂರಚನೆಯ ಅಗತ್ಯವಿರುವ ಅತ್ಯಂತ ದೊಡ್ಡ ಅನುಸ್ಥಾಪನೆಗಳು.
ದೊಡ್ಡ ಅನುಸ್ಥಾಪನೆಗಳಲ್ಲಿ, 1 ದಿನವು ಸೂಕ್ತವಾಗಿರುವುದಿಲ್ಲ. ನಾನು ವೈಯಕ್ತಿಕವಾಗಿ MySQL ನಲ್ಲಿ ದಿನಕ್ಕೆ 40 ಗಿಗಾಬೈಟ್‌ಗಳ ವಿಭಾಗಗಳನ್ನು ನೋಡಿದ್ದೇನೆ (ಮತ್ತು ಹೆಚ್ಚು ಇರಬಹುದು). ಇದು ಬಹಳ ದೊಡ್ಡ ಪ್ರಮಾಣದ ಡೇಟಾ, ಇದು ಕೆಲವು ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು. ಅದನ್ನು ಕಡಿಮೆ ಮಾಡಬೇಕಾಗಿದೆ.
ನಿಮಗೆ ವಿಭಜನೆ ಏಕೆ ಬೇಕು?
ವಿಭಜನೆಯು ಏನು ಒದಗಿಸುತ್ತದೆ, ಎಲ್ಲರಿಗೂ ತಿಳಿದಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಟೇಬಲ್ ವಿಭಜನೆಯಾಗಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ ಇವುಗಳು ಡಿಸ್ಕ್ ಮತ್ತು ಸ್ಪ್ಯಾನ್ ವಿನಂತಿಗಳಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಫೈಲ್ಗಳಾಗಿವೆ. ಸಾಮಾನ್ಯ ವಿಭಜನೆಯ ಭಾಗವಾಗಿದ್ದರೆ ಅದು ಒಂದು ವಿಭಾಗವನ್ನು ಹೆಚ್ಚು ಅತ್ಯುತ್ತಮವಾಗಿ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ.
Zabbix ಗಾಗಿ, ನಿರ್ದಿಷ್ಟವಾಗಿ, ಇದು ಶ್ರೇಣಿಯ ಮೂಲಕ, ಶ್ರೇಣಿಯ ಮೂಲಕ ಬಳಸಲ್ಪಡುತ್ತದೆ, ಅಂದರೆ, ನಾವು ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ (ನಿಯಮಿತ ಸಂಖ್ಯೆ, ಯುಗದ ಆರಂಭದಿಂದ ಸಮಯ). ನೀವು ದಿನದ ಪ್ರಾರಂಭ/ದಿನದ ಅಂತ್ಯವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೀರಿ ಮತ್ತು ಇದು ವಿಭಜನೆಯಾಗಿದೆ. ಅಂತೆಯೇ, ನೀವು ಎರಡು ದಿನಗಳ ಹಳೆಯ ಡೇಟಾವನ್ನು ಕೇಳುತ್ತಿದ್ದರೆ, ಎಲ್ಲವನ್ನೂ ಡೇಟಾಬೇಸ್‌ನಿಂದ ವೇಗವಾಗಿ ಹಿಂಪಡೆಯಲಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ನೀವು ಕೇವಲ ಒಂದು ಫೈಲ್ ಅನ್ನು ಸಂಗ್ರಹಕ್ಕೆ ಲೋಡ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕು (ದೊಡ್ಡ ಟೇಬಲ್ ಬದಲಿಗೆ).
ಅನೇಕ ಡೇಟಾಬೇಸ್‌ಗಳು ಇನ್ಸರ್ಟ್ ಅನ್ನು ವೇಗಗೊಳಿಸುತ್ತವೆ (ಒಂದು ಮಕ್ಕಳ ಕೋಷ್ಟಕದಲ್ಲಿ ಅಳವಡಿಕೆ). ನಾನು ಸದ್ಯಕ್ಕೆ ಅಮೂರ್ತವಾಗಿ ಮಾತನಾಡುತ್ತಿದ್ದೇನೆ, ಆದರೆ ಇದು ಸಹ ಸಾಧ್ಯ. ವಿಭಜನೆಯು ಆಗಾಗ್ಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.
NoSQL ಗಾಗಿ ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟ
ಇತ್ತೀಚೆಗೆ, 3.4 ರಲ್ಲಿ, ನಾವು NoSQL ಪರಿಹಾರವನ್ನು ಅಳವಡಿಸಿದ್ದೇವೆ. ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟದಲ್ಲಿ ಬರೆಯುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಸೇರಿಸಲಾಗಿದೆ. ನೀವು ಕೆಲವು ಪ್ರಕಾರಗಳನ್ನು ಬರೆಯಬಹುದು: ನೀವು ಆರಿಸಿಕೊಳ್ಳಿ - ಸಂಖ್ಯೆಗಳನ್ನು ಬರೆಯಿರಿ ಅಥವಾ ಕೆಲವು ಚಿಹ್ನೆಗಳನ್ನು ಬರೆಯಿರಿ; ನಾವು ಸ್ಟ್ರಿಂಗ್ ಪಠ್ಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ, ನೀವು Elasticsearch ಗೆ ಲಾಗ್‌ಗಳನ್ನು ಬರೆಯಬಹುದು... ಅದರ ಪ್ರಕಾರ, ವೆಬ್ ಇಂಟರ್ಫೇಸ್ Elasticsearch ಅನ್ನು ಸಹ ಪ್ರವೇಶಿಸುತ್ತದೆ. ಇದು ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಈ ಸಮಯದಲ್ಲಿ ಅದನ್ನು ಬಳಸಬಹುದು.
ಟೈಮ್ಸ್ಕೇಲ್DB. ಹೈಪರ್ಟೇಬಲ್ಸ್
4.4.2 ಕ್ಕೆ ನಾವು TimescaleDB ಯಂತಹ ಒಂದು ವಿಷಯಕ್ಕೆ ಗಮನ ನೀಡಿದ್ದೇವೆ. ಅದು ಏನು? ಇದು PostgreSQL ಗಾಗಿ ವಿಸ್ತರಣೆಯಾಗಿದೆ, ಅಂದರೆ, ಇದು ಸ್ಥಳೀಯ PostgreSQL ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹೊಂದಿದೆ. ಜೊತೆಗೆ, ಈ ವಿಸ್ತರಣೆಯು ನಿಮಗೆ ಟೈಮ್‌ಸರೀಸ್ ಡೇಟಾದೊಂದಿಗೆ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕೆಲಸ ಮಾಡಲು ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ ವಿಭಜನೆಯನ್ನು ಹೊಂದಲು ಅನುಮತಿಸುತ್ತದೆ. ಅದು ಹೇಗೆ ಕಾಣುತ್ತದೆ:
ಇದು ಹೈಪರ್ಟೇಬಲ್ - ಟೈಮ್ಸ್ಕೇಲ್ನಲ್ಲಿ ಅಂತಹ ಪರಿಕಲ್ಪನೆ ಇದೆ. ಇದು ನೀವು ರಚಿಸುವ ಹೈಪರ್ಟೇಬಲ್ ಆಗಿದೆ, ಮತ್ತು ಇದು ಭಾಗಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಭಾಗಗಳು ವಿಭಜನೆಗಳು, ಇವು ಮಕ್ಕಳ ಕೋಷ್ಟಕಗಳು, ನಾನು ತಪ್ಪಾಗಿ ಭಾವಿಸದಿದ್ದರೆ. ಇದು ನಿಜವಾಗಿಯೂ ಪರಿಣಾಮಕಾರಿ.
TimescaleDB ಮತ್ತು PostgreSQL
ಟೈಮ್‌ಸ್ಕೇಲ್‌ಡಿಬಿ ತಯಾರಕರು ಭರವಸೆ ನೀಡಿದಂತೆ, ಅವರು ಪ್ರಶ್ನೆಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಹೆಚ್ಚು ಸರಿಯಾದ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಬಳಸುತ್ತಾರೆ, ನಿರ್ದಿಷ್ಟ ಒಳಸೇರಿಸುವಿಕೆಗಳು, ಇದು ಡೇಟಾಸೆಟ್ ಇನ್ಸರ್ಟ್‌ನ ಹೆಚ್ಚುತ್ತಿರುವ ಗಾತ್ರದೊಂದಿಗೆ ಸರಿಸುಮಾರು ಸ್ಥಿರವಾದ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೊಂದಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಅಂದರೆ, ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನ 200 ಮಿಲಿಯನ್ ಸಾಲುಗಳ ನಂತರ, ಸಾಮಾನ್ಯವು ತುಂಬಾ ಕುಸಿಯಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಅಕ್ಷರಶಃ ಶೂನ್ಯಕ್ಕೆ ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಟೈಮ್ಸ್ಕೇಲ್ ಯಾವುದೇ ಪ್ರಮಾಣದ ಡೇಟಾದೊಂದಿಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಒಳಸೇರಿಸುವಿಕೆಯನ್ನು ಸೇರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
TimescaleDB ಅನ್ನು ಹೇಗೆ ಸ್ಥಾಪಿಸುವುದು? ಇದು ಸರಳವಾಗಿದೆ!
ಇದು ಡಾಕ್ಯುಮೆಂಟೇಶನ್‌ನಲ್ಲಿದೆ, ಅದನ್ನು ವಿವರಿಸಲಾಗಿದೆ - ನೀವು ಅದನ್ನು ಯಾವುದೇ ಪ್ಯಾಕೇಜ್‌ಗಳಿಂದ ಸ್ಥಾಪಿಸಬಹುದು... ಇದು ಅಧಿಕೃತ ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಹಸ್ತಚಾಲಿತವಾಗಿ ಕಂಪೈಲ್ ಮಾಡಬಹುದು. ನಾನು ಡೇಟಾಬೇಸ್‌ಗಾಗಿ ಕಂಪೈಲ್ ಮಾಡಬೇಕಾಗಿತ್ತು.
Zabbix ನಲ್ಲಿ ನಾವು ವಿಸ್ತರಣೆಯನ್ನು ಸರಳವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸುತ್ತೇವೆ. ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಲ್ಲಿ ವಿಸ್ತರಣೆಯನ್ನು ಬಳಸಿದವರು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ... ನೀವು ಸರಳವಾಗಿ ವಿಸ್ತರಣೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ, ನೀವು ಬಳಸುತ್ತಿರುವ Zabbix ಡೇಟಾಬೇಸ್‌ಗಾಗಿ ಅದನ್ನು ರಚಿಸಿ.
ಮತ್ತು ಕೊನೆಯ ಹಂತ ...
ಟೈಮ್ಸ್ಕೇಲ್DB. ಇತಿಹಾಸ ಕೋಷ್ಟಕಗಳ ವಲಸೆ
ನೀವು ಹೈಪರ್ಟೇಬಲ್ ಅನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ. ಇದಕ್ಕಾಗಿ ವಿಶೇಷ ಕಾರ್ಯವಿದೆ - ಹೈಪರ್ಟೇಬಲ್ ರಚಿಸಿ. ಅದರಲ್ಲಿ, ಮೊದಲ ಪ್ಯಾರಾಮೀಟರ್ ಈ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಅಗತ್ಯವಿರುವ ಟೇಬಲ್ ಆಗಿದೆ (ಇದಕ್ಕಾಗಿ ನೀವು ಹೈಪರ್ಟೇಬಲ್ ಅನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ).
ರಚಿಸಬೇಕಾದ ಕ್ಷೇತ್ರ, ಮತ್ತು chunk_time_interval (ಇದು ಚಂಕ್‌ಗಳ ಮಧ್ಯಂತರವಾಗಿದೆ (ಬಳಸಬೇಕಾದ ವಿಭಾಗಗಳು). 86 ಒಂದು ದಿನ.
Migrate_data ಪ್ಯಾರಾಮೀಟರ್: ನೀವು true ಗೆ ಸೇರಿಸಿದರೆ, ಇದು ಎಲ್ಲಾ ಪ್ರಸ್ತುತ ಡೇಟಾವನ್ನು ಮೊದಲೇ ರಚಿಸಲಾದ ಭಾಗಗಳಿಗೆ ಸ್ಥಳಾಂತರಿಸುತ್ತದೆ.
ನಾನೇ migrate_data ಬಳಸಿದ್ದೇನೆ - ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಎಷ್ಟು ದೊಡ್ಡದಾಗಿದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಇದು ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ನನ್ನ ಬಳಿ ಒಂದು ಟೆರಾಬೈಟ್ ಇತ್ತು - ಇದನ್ನು ರಚಿಸಲು ಒಂದು ಗಂಟೆಗೂ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಂಡಿತು. ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ, ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ, ಪಠ್ಯ (history_text) ಮತ್ತು ಸ್ಟ್ರಿಂಗ್ (history_str) ಗಾಗಿ ನಾನು ಐತಿಹಾಸಿಕ ಡೇಟಾವನ್ನು ಅಳಿಸಿದ್ದೇನೆ ಆದ್ದರಿಂದ ಅವುಗಳನ್ನು ವರ್ಗಾಯಿಸುವುದಿಲ್ಲ - ಅವು ನನಗೆ ನಿಜವಾಗಿಯೂ ಆಸಕ್ತಿದಾಯಕವಾಗಿರಲಿಲ್ಲ.
ಮತ್ತು ನಾವು ನಮ್ಮ db_extention ನಲ್ಲಿ ಕೊನೆಯ ನವೀಕರಣವನ್ನು ಮಾಡುತ್ತೇವೆ: ನಾವು timescaledb ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತೇವೆ ಇದರಿಂದ ಡೇಟಾಬೇಸ್ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ, ನಮ್ಮ Zabbix db_extention ಇದೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ. ಅವನು ಅದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತಾನೆ ಮತ್ತು ಟೈಮ್‌ಸ್ಕೇಲ್‌ಡಿಬಿಗೆ ಅಗತ್ಯವಾದ “ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು” ಬಳಸಿಕೊಂಡು ಡೇಟಾಬೇಸ್ಗೆ ಸರಿಯಾದ ಸಿಂಟ್ಯಾಕ್ಸ್ ಮತ್ತು ಪ್ರಶ್ನೆಗಳನ್ನು ಬಳಸುತ್ತಾನೆ.
ಸರ್ವರ್ ಕಾನ್ಫಿಗರೇಶನ್
ನಾನು ಎರಡು ಸರ್ವರ್‌ಗಳನ್ನು ಬಳಸಿದ್ದೇನೆ. ಮೊದಲ ಸರ್ವರ್ ಸಾಕಷ್ಟು ಸಣ್ಣ ವರ್ಚುವಲ್ ಯಂತ್ರ, 20 ಪ್ರೊಸೆಸರ್ಗಳು, 16 ಗಿಗಾಬೈಟ್ RAM ಆಗಿದೆ. ನಾನು ಅದರ ಮೇಲೆ Postgres 10.8 ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದೇನೆ:
ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಡೆಬಿಯನ್ ಆಗಿತ್ತು, ಫೈಲ್ ಸಿಸ್ಟಮ್ xfs ಆಗಿತ್ತು. ಈ ನಿರ್ದಿಷ್ಟ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬಳಸಲು ನಾನು ಕನಿಷ್ಟ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಮಾಡಿದ್ದೇನೆ, Zabbix ಸ್ವತಃ ಏನು ಬಳಸುತ್ತದೆ ಎಂಬುದನ್ನು ಕಡಿಮೆ ಮಾಡಿ. ಅದೇ ಯಂತ್ರದಲ್ಲಿ Zabbix ಸರ್ವರ್, PostgreSQL ಮತ್ತು ಲೋಡ್ ಏಜೆಂಟ್‌ಗಳು ಇದ್ದವು.
ವಿಭಿನ್ನ ಫಲಿತಾಂಶಗಳನ್ನು ತ್ವರಿತವಾಗಿ ರಚಿಸಲು LoadableModule ಅನ್ನು ಬಳಸುವ 50 ಸಕ್ರಿಯ ಏಜೆಂಟ್‌ಗಳನ್ನು ನಾನು ಬಳಸಿದ್ದೇನೆ. ಅವರು ತಂತಿಗಳು, ಸಂಖ್ಯೆಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ಸೃಷ್ಟಿಸಿದವರು. ನಾನು ಬಹಳಷ್ಟು ಡೇಟಾದೊಂದಿಗೆ ಡೇಟಾಬೇಸ್ ಅನ್ನು ತುಂಬಿದೆ. ಆರಂಭದಲ್ಲಿ, ಕಾನ್ಫಿಗರೇಶನ್ ಪ್ರತಿ ಹೋಸ್ಟ್‌ಗೆ 5 ಸಾವಿರ ಡೇಟಾ ಅಂಶಗಳನ್ನು ಒಳಗೊಂಡಿತ್ತು ಮತ್ತು ಸರಿಸುಮಾರು ಪ್ರತಿ ಡೇಟಾ ಅಂಶವು ಒಂದು ಪ್ರಚೋದಕವನ್ನು ಹೊಂದಿರುತ್ತದೆ - ಇದು ನಿಜವಾದ ಸೆಟಪ್ ಆಗಲು. ಕೆಲವೊಮ್ಮೆ ನೀವು ಬಳಸಲು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಪ್ರಚೋದಕಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ.
ನಾನು 50 ಏಜೆಂಟ್‌ಗಳನ್ನು ಬಳಸುವುದರ ಮೂಲಕ (ಹೆಚ್ಚು ಸೇರಿಸುವ ಮೂಲಕ) ಅಪ್‌ಡೇಟ್ ಮಧ್ಯಂತರ ಮತ್ತು ಲೋಡ್ ಅನ್ನು ನಿಯಂತ್ರಿಸಿದೆ, ಆದರೆ ಡೈನಾಮಿಕ್ ಡೇಟಾ ಅಂಶಗಳನ್ನು ಬಳಸಿ ಮತ್ತು ಅಪ್‌ಡೇಟ್ ಮಧ್ಯಂತರವನ್ನು 4 ಸೆಕೆಂಡುಗಳಿಗೆ ಕಡಿಮೆ ಮಾಡಿದೆ.
ಕಾರ್ಯಕ್ಷಮತೆ ಪರೀಕ್ಷೆ. PostgreSQL: 36 ಸಾವಿರ NVP ಗಳು
ಮೊದಲ ಉಡಾವಣೆ, ನಾನು ಹೊಂದಿದ್ದ ಮೊದಲ ಸೆಟಪ್ ಈ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಶುದ್ಧ PostreSQL 10 ನಲ್ಲಿತ್ತು (ಸೆಕೆಂಡಿಗೆ 35 ಸಾವಿರ ಮೌಲ್ಯಗಳು). ಸಾಮಾನ್ಯವಾಗಿ, ನೀವು ಪರದೆಯ ಮೇಲೆ ನೋಡುವಂತೆ, ಡೇಟಾವನ್ನು ಸೇರಿಸುವುದು ಒಂದು ಸೆಕೆಂಡಿನ ಭಿನ್ನರಾಶಿಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ - ಎಲ್ಲವೂ ಒಳ್ಳೆಯದು ಮತ್ತು ವೇಗವಾಗಿರುತ್ತದೆ, SSD ಡ್ರೈವ್ಗಳು (200 ಗಿಗಾಬೈಟ್ಗಳು). ಒಂದೇ ವಿಷಯವೆಂದರೆ 20 ಜಿಬಿ ತ್ವರಿತವಾಗಿ ತುಂಬುತ್ತದೆ.
ಭವಿಷ್ಯದಲ್ಲಿ ಇಂತಹ ಗ್ರಾಫ್‌ಗಳು ಸಾಕಷ್ಟು ಇರುತ್ತದೆ. ಇದು ಪ್ರಮಾಣಿತ Zabbix ಸರ್ವರ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಆಗಿದೆ.
ಮೊದಲ ಗ್ರಾಫ್ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಮೌಲ್ಯಗಳ ಸಂಖ್ಯೆ (ನೀಲಿ, ಮೇಲಿನ ಎಡ), ಈ ಸಂದರ್ಭದಲ್ಲಿ 35 ಸಾವಿರ ಮೌಲ್ಯಗಳು. ಇದು (ಮೇಲಿನ ಕೇಂದ್ರ) ನಿರ್ಮಾಣ ಪ್ರಕ್ರಿಯೆಗಳ ಲೋಡ್ ಆಗಿದೆ, ಮತ್ತು ಇದು (ಮೇಲಿನ ಬಲ) ಆಂತರಿಕ ಪ್ರಕ್ರಿಯೆಗಳ ಲೋಡ್ ಆಗಿದೆ: ಇತಿಹಾಸ ಸಿಂಕರ್‌ಗಳು ಮತ್ತು ಹೌಸ್ಕೀಪರ್, ಇಲ್ಲಿ (ಕೆಳಗಿನ ಮಧ್ಯದಲ್ಲಿ) ಸ್ವಲ್ಪ ಸಮಯದಿಂದ ಚಾಲನೆಯಲ್ಲಿದೆ.
ಈ ಗ್ರಾಫ್ (ಕೆಳಗಿನ ಮಧ್ಯಭಾಗ) ValueCache ಬಳಕೆಯನ್ನು ತೋರಿಸುತ್ತದೆ - ಟ್ರಿಗ್ಗರ್‌ಗಳಿಗಾಗಿ ಎಷ್ಟು ValueCache ಹಿಟ್‌ಗಳು (ಸೆಕೆಂಡಿಗೆ ಹಲವಾರು ಸಾವಿರ ಮೌಲ್ಯಗಳು). ಮತ್ತೊಂದು ಪ್ರಮುಖ ಗ್ರಾಫ್ ನಾಲ್ಕನೆಯದು (ಕೆಳಭಾಗದ ಎಡ), ಇದು ನಾನು ಮಾತನಾಡಿದ ಹಿಸ್ಟರಿ ಕ್ಯಾಶ್ ಬಳಕೆಯನ್ನು ತೋರಿಸುತ್ತದೆ, ಇದು ಡೇಟಾಬೇಸ್ಗೆ ಸೇರಿಸುವ ಮೊದಲು ಬಫರ್ ಆಗಿದೆ.
ಕಾರ್ಯಕ್ಷಮತೆ ಪರೀಕ್ಷೆ. PostgreSQL: 50 ಸಾವಿರ NVP ಗಳು
ಮುಂದೆ, ನಾನು ಅದೇ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಸೆಕೆಂಡಿಗೆ 50 ಸಾವಿರ ಮೌಲ್ಯಗಳಿಗೆ ಲೋಡ್ ಅನ್ನು ಹೆಚ್ಚಿಸಿದೆ. ಹೌಸ್‌ಕೀಪರ್‌ನಿಂದ ಲೋಡ್ ಮಾಡಿದಾಗ, 10-2 ಸೆಕೆಂಡುಗಳಲ್ಲಿ 3 ಸಾವಿರ ಮೌಲ್ಯಗಳನ್ನು ಲೆಕ್ಕಾಚಾರದೊಂದಿಗೆ ದಾಖಲಿಸಲಾಗಿದೆ. ವಾಸ್ತವವಾಗಿ, ಈ ಕೆಳಗಿನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ನಲ್ಲಿ ಏನು ತೋರಿಸಲಾಗಿದೆ:
"ಗೃಹರಕ್ಷಕ" ಈಗಾಗಲೇ ಕೆಲಸದಲ್ಲಿ ಹಸ್ತಕ್ಷೇಪ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದೆ, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ, ಇತಿಹಾಸ-ಸಿಂಕರ್ ಟ್ರ್ಯಾಪರ್ಗಳ ಮೇಲಿನ ಹೊರೆ ಇನ್ನೂ 60% (ಮೂರನೇ ಗ್ರಾಫ್, ಮೇಲಿನ ಬಲ) ಮಟ್ಟದಲ್ಲಿದೆ. ಹೌಸ್ಕೀಪರ್ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ಹಿಸ್ಟರಿಕ್ಯಾಶ್ ಈಗಾಗಲೇ ಸಕ್ರಿಯವಾಗಿ ತುಂಬಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ (ಕೆಳಗಿನ ಎಡಭಾಗದಲ್ಲಿ). ಇದು ಸುಮಾರು ಅರ್ಧ ಗಿಗಾಬೈಟ್, 20% ತುಂಬಿತ್ತು.
ಕಾರ್ಯಕ್ಷಮತೆ ಪರೀಕ್ಷೆ. PostgreSQL: 80 ಸಾವಿರ NVP ಗಳು
ನಂತರ ನಾನು ಅದನ್ನು ಸೆಕೆಂಡಿಗೆ 80 ಸಾವಿರ ಮೌಲ್ಯಗಳಿಗೆ ಹೆಚ್ಚಿಸಿದೆ:
ಇದು ಸರಿಸುಮಾರು 400 ಸಾವಿರ ಡೇಟಾ ಅಂಶಗಳು, 280 ಸಾವಿರ ಟ್ರಿಗ್ಗರ್‌ಗಳು. ಇನ್ಸರ್ಟ್, ನೀವು ನೋಡುವಂತೆ, ಇತಿಹಾಸದ ಸಿಂಕರ್ಗಳ ಹೊರೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ (ಅವುಗಳಲ್ಲಿ 30 ಇದ್ದವು) ಈಗಾಗಲೇ ಸಾಕಷ್ಟು ಹೆಚ್ಚಾಗಿದೆ. ನಂತರ ನಾನು ವಿವಿಧ ನಿಯತಾಂಕಗಳನ್ನು ಹೆಚ್ಚಿಸಿದೆ: ಇತಿಹಾಸ ಸಿಂಕರ್‌ಗಳು, ಸಂಗ್ರಹ... ಈ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ, ಹಿಸ್ಟರಿ ಸಿಂಕರ್ಗಳ ಮೇಲಿನ ಲೋಡ್ ಗರಿಷ್ಠಕ್ಕೆ ಹೆಚ್ಚಾಗಲು ಪ್ರಾರಂಭಿಸಿತು, ಬಹುತೇಕ “ಶೆಲ್ಫ್ನಲ್ಲಿ” - ಅದರ ಪ್ರಕಾರ, ಹಿಸ್ಟರಿ ಕ್ಯಾಶ್ ತುಂಬಾ ಹೆಚ್ಚಿನ ಹೊರೆಗೆ ಹೋಯಿತು:
ಈ ಸಮಯದಲ್ಲಿ ನಾನು ಎಲ್ಲಾ ಸಿಸ್ಟಮ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು (ಪ್ರೊಸೆಸರ್ ಅನ್ನು ಹೇಗೆ ಬಳಸಲಾಗುತ್ತದೆ, RAM) ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿದ್ದೇನೆ ಮತ್ತು ಡಿಸ್ಕ್ ಬಳಕೆ ಗರಿಷ್ಠವಾಗಿದೆ ಎಂದು ಕಂಡುಹಿಡಿದಿದೆ - ಈ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಈ ವರ್ಚುವಲ್ ಗಣಕದಲ್ಲಿ ನಾನು ಈ ಡಿಸ್ಕ್‌ನ ಗರಿಷ್ಠ ಸಾಮರ್ಥ್ಯವನ್ನು ಸಾಧಿಸಿದೆ. "ಪೋಸ್ಟ್ಗ್ರೆಸ್" ಅಂತಹ ತೀವ್ರತೆಯಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಾಕಷ್ಟು ಸಕ್ರಿಯವಾಗಿ ಡಂಪ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿತು, ಮತ್ತು ಡಿಸ್ಕ್ಗೆ ಇನ್ನು ಮುಂದೆ ಬರೆಯಲು, ಓದಲು ಸಮಯವಿರಲಿಲ್ಲ ...
ನಾನು ಈಗಾಗಲೇ 48 ಪ್ರೊಸೆಸರ್ಗಳು ಮತ್ತು 128 ಗಿಗಾಬೈಟ್ RAM ಅನ್ನು ಹೊಂದಿರುವ ಮತ್ತೊಂದು ಸರ್ವರ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡೆ:
ನಾನು ಅದನ್ನು "ಟ್ಯೂನ್" ಮಾಡಿದ್ದೇನೆ - ಇತಿಹಾಸ ಸಿನ್ಸರ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದೆ (60 ತುಣುಕುಗಳು) ಮತ್ತು ಸ್ವೀಕಾರಾರ್ಹ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಾಧಿಸಿದೆ. ವಾಸ್ತವವಾಗಿ, ನಾವು "ಶೆಲ್ಫ್ನಲ್ಲಿ" ಇಲ್ಲ, ಆದರೆ ಇದು ಬಹುಶಃ ಉತ್ಪಾದಕತೆಯ ಮಿತಿಯಾಗಿದೆ, ಅಲ್ಲಿ ಅದರ ಬಗ್ಗೆ ಏನಾದರೂ ಮಾಡಲು ಈಗಾಗಲೇ ಅವಶ್ಯಕವಾಗಿದೆ.
ಕಾರ್ಯಕ್ಷಮತೆ ಪರೀಕ್ಷೆ. ಟೈಮ್ಸ್ಕೇಲ್ ಡಿಬಿ: 80 ಸಾವಿರ ಎನ್‌ವಿಪಿಗಳು
ಟೈಮ್‌ಸ್ಕೇಲ್‌ಡಿಬಿಯನ್ನು ಬಳಸುವುದು ನನ್ನ ಮುಖ್ಯ ಕಾರ್ಯವಾಗಿತ್ತು. ಪ್ರತಿ ಗ್ರಾಫ್ ಒಂದು ಕುಸಿತವನ್ನು ತೋರಿಸುತ್ತದೆ:
ಈ ವೈಫಲ್ಯಗಳು ನಿಖರವಾಗಿ ಡೇಟಾ ವಲಸೆ. ಅದರ ನಂತರ, Zabbix ಸರ್ವರ್‌ನಲ್ಲಿ, ಇತಿಹಾಸ ಸಿಂಕರ್ಗಳ ಲೋಡಿಂಗ್ ಪ್ರೊಫೈಲ್, ನೀವು ನೋಡುವಂತೆ, ಬಹಳಷ್ಟು ಬದಲಾಗಿದೆ. ಇದು ಸುಮಾರು 3 ಪಟ್ಟು ವೇಗವಾಗಿ ಡೇಟಾವನ್ನು ಸೇರಿಸಲು ಮತ್ತು ಕಡಿಮೆ ಹಿಸ್ಟರಿ ಕ್ಯಾಶ್ ಅನ್ನು ಬಳಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ - ಅದರ ಪ್ರಕಾರ, ನೀವು ಸಮಯಕ್ಕೆ ಡೇಟಾವನ್ನು ತಲುಪಿಸುತ್ತೀರಿ. ಮತ್ತೆ, ಸೆಕೆಂಡಿಗೆ 80 ಸಾವಿರ ಮೌಲ್ಯಗಳು ಸಾಕಷ್ಟು ಹೆಚ್ಚಿನ ದರವಾಗಿದೆ (ಸಹಜವಾಗಿ, ಯಾಂಡೆಕ್ಸ್‌ಗೆ ಅಲ್ಲ). ಒಟ್ಟಾರೆಯಾಗಿ ಇದು ಒಂದು ಸರ್ವರ್‌ನೊಂದಿಗೆ ಸಾಕಷ್ಟು ದೊಡ್ಡ ಸೆಟಪ್ ಆಗಿದೆ.
PostgreSQL ಕಾರ್ಯಕ್ಷಮತೆ ಪರೀಕ್ಷೆ: 120 ಸಾವಿರ NVP ಗಳು
ಮುಂದೆ, ನಾನು ಡೇಟಾ ಅಂಶಗಳ ಸಂಖ್ಯೆಯ ಮೌಲ್ಯವನ್ನು ಅರ್ಧ ಮಿಲಿಯನ್‌ಗೆ ಹೆಚ್ಚಿಸಿದೆ ಮತ್ತು ಸೆಕೆಂಡಿಗೆ 125 ಸಾವಿರ ಲೆಕ್ಕಾಚಾರದ ಮೌಲ್ಯವನ್ನು ಪಡೆದಿದ್ದೇನೆ:
ಮತ್ತು ನಾನು ಈ ಗ್ರಾಫ್‌ಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇನೆ:
ತಾತ್ವಿಕವಾಗಿ, ಇದು ಕೆಲಸ ಮಾಡುವ ಸೆಟಪ್ ಆಗಿದೆ, ಇದು ಸಾಕಷ್ಟು ಸಮಯದವರೆಗೆ ಕೆಲಸ ಮಾಡಬಹುದು. ಆದರೆ ನಾನು ಕೇವಲ 1,5 ಟೆರಾಬೈಟ್ ಡಿಸ್ಕ್ ಅನ್ನು ಹೊಂದಿದ್ದರಿಂದ, ನಾನು ಅದನ್ನು ಒಂದೆರಡು ದಿನಗಳಲ್ಲಿ ಬಳಸಿದ್ದೇನೆ. ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯವೆಂದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಟೈಮ್‌ಸ್ಕೇಲ್‌ಡಿಬಿಯಲ್ಲಿ ಹೊಸ ವಿಭಾಗಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ, ಮತ್ತು ಇದು ಕಾರ್ಯಕ್ಷಮತೆಗಾಗಿ ಸಂಪೂರ್ಣವಾಗಿ ಗಮನಿಸಲಿಲ್ಲ, ಇದನ್ನು MySQL ಬಗ್ಗೆ ಹೇಳಲಾಗುವುದಿಲ್ಲ.
ವಿಶಿಷ್ಟವಾಗಿ, ವಿಭಾಗಗಳನ್ನು ರಾತ್ರಿಯಲ್ಲಿ ರಚಿಸಲಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಅಳವಡಿಕೆಯನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ ಮತ್ತು ಕೋಷ್ಟಕಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸೇವೆಯ ಅವನತಿಗೆ ಕಾರಣವಾಗಬಹುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ ಇದು ಹಾಗಲ್ಲ! ಟೈಮ್‌ಸ್ಕೇಲ್‌ಡಿಬಿಯ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಪರೀಕ್ಷಿಸುವುದು ಮುಖ್ಯ ಕಾರ್ಯವಾಗಿತ್ತು. ಫಲಿತಾಂಶವು ಈ ಕೆಳಗಿನ ಅಂಕಿ ಅಂಶವಾಗಿದೆ: ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 120 ಸಾವಿರ ಮೌಲ್ಯಗಳು.
ಸಮುದಾಯದಲ್ಲಿ ಉದಾಹರಣೆಗಳೂ ಇವೆ:
ವ್ಯಕ್ತಿಯು TimescaleDB ಅನ್ನು ಆನ್ ಮಾಡಿದ್ದಾನೆ ಮತ್ತು io.weight ಅನ್ನು ಬಳಸುವುದರ ಮೇಲಿನ ಹೊರೆಯು ಪ್ರೊಸೆಸರ್‌ನಲ್ಲಿ ಇಳಿಯಿತು; ಮತ್ತು ಟೈಮ್‌ಸ್ಕೇಲ್‌ಡಿಬಿಯ ಸೇರ್ಪಡೆಯಿಂದಾಗಿ ಆಂತರಿಕ ಪ್ರಕ್ರಿಯೆಯ ಅಂಶಗಳ ಬಳಕೆಯು ಸಹ ಕಡಿಮೆಯಾಗಿದೆ. ಇದಲ್ಲದೆ, ಇವು ಸಾಮಾನ್ಯ ಪ್ಯಾನ್‌ಕೇಕ್ ಡಿಸ್ಕ್‌ಗಳು, ಅಂದರೆ ಸಾಮಾನ್ಯ ಡಿಸ್ಕ್‌ಗಳಲ್ಲಿನ ಸಾಮಾನ್ಯ ವರ್ಚುವಲ್ ಯಂತ್ರ (ಎಸ್‌ಎಸ್‌ಡಿ ಅಲ್ಲ)!
ಡಿಸ್ಕ್ ಕಾರ್ಯಕ್ಷಮತೆಯಿಂದ ಸೀಮಿತವಾಗಿರುವ ಕೆಲವು ಸಣ್ಣ ಸೆಟಪ್‌ಗಳಿಗೆ, ಟೈಮ್‌ಸ್ಕೇಲ್‌ಡಿಬಿ, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಉತ್ತಮ ಪರಿಹಾರವಾಗಿದೆ. ಡೇಟಾಬೇಸ್‌ಗಾಗಿ ವೇಗವಾದ ಹಾರ್ಡ್‌ವೇರ್‌ಗೆ ವಲಸೆ ಹೋಗುವ ಮೊದಲು ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ.
ನಮ್ಮ ಈವೆಂಟ್‌ಗಳಿಗೆ ನಾನು ನಿಮ್ಮೆಲ್ಲರನ್ನೂ ಆಹ್ವಾನಿಸುತ್ತೇನೆ: ಮಾಸ್ಕೋದಲ್ಲಿ ಸಮ್ಮೇಳನ, ರಿಗಾದಲ್ಲಿ ಶೃಂಗಸಭೆ. ನಮ್ಮ ಚಾನಲ್‌ಗಳನ್ನು ಬಳಸಿ - ಟೆಲಿಗ್ರಾಮ್, ಫೋರಮ್, IRC. ನೀವು ಯಾವುದೇ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನಮ್ಮ ಮೇಜಿನ ಬಳಿಗೆ ಬನ್ನಿ, ನಾವು ಎಲ್ಲದರ ಬಗ್ಗೆ ಮಾತನಾಡಬಹುದು.
ಪ್ರೇಕ್ಷಕರ ಪ್ರಶ್ನೆಗಳು
ಪ್ರೇಕ್ಷಕರಿಂದ ಪ್ರಶ್ನೆ (ಇನ್ನು ಮುಂದೆ - ಎ): - ಟೈಮ್‌ಸ್ಕೇಲ್‌ಡಿಬಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ತುಂಬಾ ಸುಲಭವಾಗಿದ್ದರೆ ಮತ್ತು ಅದು ಅಂತಹ ಕಾರ್ಯಕ್ಷಮತೆಯ ವರ್ಧಕವನ್ನು ನೀಡಿದರೆ, ಬಹುಶಃ ಇದನ್ನು ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನೊಂದಿಗೆ ಜಬ್ಬಿಕ್ಸ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಉತ್ತಮ ಅಭ್ಯಾಸವಾಗಿ ಬಳಸಬೇಕೇ? ಮತ್ತು ಈ ಪರಿಹಾರದ ಯಾವುದೇ ಅಪಾಯಗಳು ಮತ್ತು ಅನಾನುಕೂಲತೆಗಳಿವೆಯೇ, ಅಥವಾ ಎಲ್ಲಾ ನಂತರ, ನಾನು ಜಬ್ಬಿಕ್ಸ್ ಅನ್ನು ನನಗಾಗಿ ಮಾಡಲು ನಿರ್ಧರಿಸಿದರೆ, ನಾನು ಸುಲಭವಾಗಿ ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಈಗಿನಿಂದಲೇ ಟೈಮ್ಸ್ಕೇಲ್ ಅನ್ನು ಸ್ಥಾಪಿಸಬಹುದು, ಅದನ್ನು ಬಳಸಿ ಮತ್ತು ಯಾವುದೇ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಯೋಚಿಸುವುದಿಲ್ಲವೇ?
AG: – ಹೌದು, ಇದು ಉತ್ತಮ ಶಿಫಾರಸು ಎಂದು ನಾನು ಹೇಳುತ್ತೇನೆ: TimescaleDB ವಿಸ್ತರಣೆಯೊಂದಿಗೆ ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಅನ್ನು ತಕ್ಷಣವೇ ಬಳಸಿ. ನಾನು ಈಗಾಗಲೇ ಹೇಳಿದಂತೆ, ಈ "ವೈಶಿಷ್ಟ್ಯ" ಪ್ರಾಯೋಗಿಕವಾಗಿದೆ ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ ಬಹಳಷ್ಟು ಉತ್ತಮ ವಿಮರ್ಶೆಗಳು. ಆದರೆ ವಾಸ್ತವವಾಗಿ ಪರೀಕ್ಷೆಗಳು ಇದು ಉತ್ತಮ ಪರಿಹಾರವಾಗಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ (ಟೈಮ್‌ಸ್ಕೇಲ್‌ಡಿಬಿಯೊಂದಿಗೆ) ಮತ್ತು ಇದು ವಿಕಸನಗೊಳ್ಳುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ! ಈ ವಿಸ್ತರಣೆಯು ಹೇಗೆ ಅಭಿವೃದ್ಧಿಗೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಅಗತ್ಯವಿರುವಂತೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುತ್ತೇವೆ.
ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ ಸಹ, ನಾವು ಅವರ ಪ್ರಸಿದ್ಧ "ವೈಶಿಷ್ಟ್ಯ" ಗಳಲ್ಲಿ ಒಂದನ್ನು ಅವಲಂಬಿಸಿದ್ದೇವೆ: ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿ ತುಂಡುಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಾಯಿತು. ಆದರೆ ನಂತರ ಅವರು ಅದನ್ನು ಮುಂದಿನ ಬಿಡುಗಡೆಯಲ್ಲಿ ಕಡಿತಗೊಳಿಸಿದರು ಮತ್ತು ನಾವು ಈ ಕೋಡ್ ಅನ್ನು ಅವಲಂಬಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಬೇಕಾಯಿತು. ಅನೇಕ ಸೆಟಪ್‌ಗಳಲ್ಲಿ ಈ ಪರಿಹಾರವನ್ನು ಬಳಸಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ನೀವು MySQL ಅನ್ನು ಬಳಸಿದರೆ... ಸರಾಸರಿ ಸೆಟಪ್‌ಗಳಿಗಾಗಿ, ಯಾವುದೇ ಪರಿಹಾರವು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಉ: - ಸಮುದಾಯದ ಕೊನೆಯ ಗ್ರಾಫ್‌ಗಳಲ್ಲಿ, "ಗೃಹರಕ್ಷಕ" ನೊಂದಿಗೆ ಗ್ರಾಫ್ ಇತ್ತು:
ಅವರು ಕೆಲಸ ಮುಂದುವರೆಸಿದರು. ಟೈಮ್‌ಸ್ಕೇಲ್‌ಡಿಬಿಯೊಂದಿಗೆ ಹೌಸ್ಕೀಪರ್ ಏನು ಮಾಡುತ್ತಾರೆ?
AG: - ಈಗ ನಾನು ಖಚಿತವಾಗಿ ಹೇಳಲಾರೆ - ನಾನು ಕೋಡ್ ಅನ್ನು ನೋಡುತ್ತೇನೆ ಮತ್ತು ಹೆಚ್ಚು ವಿವರವಾಗಿ ಹೇಳುತ್ತೇನೆ. ಇದು ಚಂಕ್‌ಗಳನ್ನು ಅಳಿಸಲು ಟೈಮ್‌ಸ್ಕೇಲ್‌ಡಿಬಿ ಪ್ರಶ್ನೆಗಳನ್ನು ಬಳಸುತ್ತದೆ, ಆದರೆ ಹೇಗಾದರೂ ಅವುಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸಲು. ಈ ತಾಂತ್ರಿಕ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಲು ನಾನು ಇನ್ನೂ ಸಿದ್ಧವಾಗಿಲ್ಲ. ನಾವು ಇಂದು ಅಥವಾ ನಾಳೆ ಸ್ಟ್ಯಾಂಡ್‌ನಲ್ಲಿ ಹೆಚ್ಚಿನದನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ.
ಉ: - ನನಗೆ ಇದೇ ರೀತಿಯ ಪ್ರಶ್ನೆ ಇದೆ - ಟೈಮ್ಸ್ಕೇಲ್ನಲ್ಲಿ ಅಳಿಸುವಿಕೆ ಕಾರ್ಯಾಚರಣೆಯ ಕಾರ್ಯಕ್ಷಮತೆಯ ಬಗ್ಗೆ.
ಎ (ಪ್ರೇಕ್ಷಕರಿಂದ ಉತ್ತರ): – ನೀವು ಟೇಬಲ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಅಳಿಸಿದಾಗ, ನೀವು ಅದನ್ನು ಅಳಿಸುವ ಮೂಲಕ ಮಾಡಿದರೆ, ನಂತರ ನೀವು ಟೇಬಲ್ ಮೂಲಕ ಹೋಗಬೇಕಾಗುತ್ತದೆ - ಅಳಿಸಿ, ಸ್ವಚ್ಛಗೊಳಿಸಿ, ಭವಿಷ್ಯದ ನಿರ್ವಾತಕ್ಕಾಗಿ ಎಲ್ಲವನ್ನೂ ಗುರುತಿಸಿ. ಟೈಮ್ಸ್ಕೇಲ್ನಲ್ಲಿ, ನೀವು ತುಂಡುಗಳನ್ನು ಹೊಂದಿರುವುದರಿಂದ, ನೀವು ಬಿಡಬಹುದು. ಸ್ಥೂಲವಾಗಿ ಹೇಳುವುದಾದರೆ, ದೊಡ್ಡ ಡೇಟಾದಲ್ಲಿರುವ ಫೈಲ್ ಅನ್ನು ನೀವು ಸರಳವಾಗಿ ಹೇಳುತ್ತೀರಿ: "ಅಳಿಸು!"
ಅಂತಹ ಒಂದು ಭಾಗವು ಇನ್ನು ಮುಂದೆ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ ಎಂದು ಟೈಮ್ಸ್ಕೇಲ್ ಸರಳವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ. ಮತ್ತು ಇದು ಕ್ವೆರಿ ಪ್ಲಾನರ್‌ನಲ್ಲಿ ಸಂಯೋಜಿಸಲ್ಪಟ್ಟಿರುವುದರಿಂದ, ಆಯ್ದ ಅಥವಾ ಇತರ ಕಾರ್ಯಾಚರಣೆಗಳಲ್ಲಿ ನಿಮ್ಮ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ಹಿಡಿಯಲು ಇದು ಕೊಕ್ಕೆಗಳನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ಈ ಭಾಗವು ಇನ್ನು ಮುಂದೆ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ ಎಂದು ತಕ್ಷಣವೇ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ - "ನಾನು ಇನ್ನು ಮುಂದೆ ಅಲ್ಲಿಗೆ ಹೋಗುವುದಿಲ್ಲ!" (ಡೇಟಾ ಲಭ್ಯವಿಲ್ಲ). ಅಷ್ಟೇ! ಅಂದರೆ, ಟೇಬಲ್ ಸ್ಕ್ಯಾನ್ ಅನ್ನು ಬೈನರಿ ಫೈಲ್ ಅಳಿಸುವಿಕೆಯಿಂದ ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಇದು ವೇಗವಾಗಿರುತ್ತದೆ.
ಉ: - ನಾವು ಈಗಾಗಲೇ SQL ಅಲ್ಲದ ವಿಷಯದ ಮೇಲೆ ಸ್ಪರ್ಶಿಸಿದ್ದೇವೆ. ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, Zabbix ನಿಜವಾಗಿಯೂ ಡೇಟಾವನ್ನು ಮಾರ್ಪಡಿಸುವ ಅಗತ್ಯವಿಲ್ಲ, ಮತ್ತು ಇದೆಲ್ಲವೂ ಲಾಗ್‌ನಂತಿದೆ. ತಮ್ಮ ಡೇಟಾವನ್ನು ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಾಗದ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಹೆಚ್ಚು ವೇಗವಾಗಿ ಉಳಿಸಲು, ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ವಿತರಿಸಲು ವಿಶೇಷ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಬಳಸಲು ಸಾಧ್ಯವೇ - ಕ್ಲಿಕ್‌ಹೌಸ್, ಉದಾಹರಣೆಗೆ, ಕಾಫ್ಕಾ ರೀತಿಯದ್ದೇ?.. ಕಾಫ್ಕಾ ಕೂಡ ಲಾಗ್ ಆಗಿದೆ! ಅವುಗಳನ್ನು ಹೇಗಾದರೂ ಸಂಯೋಜಿಸಲು ಸಾಧ್ಯವೇ?
AG: - ಇಳಿಸುವಿಕೆಯನ್ನು ಮಾಡಬಹುದು. ನಾವು ಆವೃತ್ತಿ 3.4 ರಿಂದ ನಿರ್ದಿಷ್ಟ "ವೈಶಿಷ್ಟ್ಯ" ವನ್ನು ಹೊಂದಿದ್ದೇವೆ: ನೀವು ಎಲ್ಲಾ ಐತಿಹಾಸಿಕ ಫೈಲ್‌ಗಳು, ಈವೆಂಟ್‌ಗಳು, ಎಲ್ಲವನ್ನೂ ಫೈಲ್‌ಗಳಿಗೆ ಬರೆಯಬಹುದು; ತದನಂತರ ಕೆಲವು ಹ್ಯಾಂಡ್ಲರ್ ಬಳಸಿ ಅದನ್ನು ಬೇರೆ ಯಾವುದೇ ಡೇಟಾಬೇಸ್ಗೆ ಕಳುಹಿಸಿ. ವಾಸ್ತವವಾಗಿ, ಅನೇಕ ಜನರು ಮರು ಕೆಲಸ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ನೇರವಾಗಿ ಡೇಟಾಬೇಸ್ಗೆ ಬರೆಯುತ್ತಾರೆ. ಹಾರಾಡುತ್ತಿರುವಾಗ, ಇತಿಹಾಸ ಸಿಂಕರ್‌ಗಳು ಈ ಎಲ್ಲವನ್ನು ಫೈಲ್‌ಗಳಾಗಿ ಬರೆಯುತ್ತಾರೆ, ಈ ಫೈಲ್‌ಗಳನ್ನು ತಿರುಗಿಸಿ, ಮತ್ತು ಹೀಗೆ, ಮತ್ತು ನೀವು ಇದನ್ನು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ವರ್ಗಾಯಿಸಬಹುದು. ಯೋಜನೆಗಳ ಬಗ್ಗೆ ನಾನು ಹೇಳಲಾರೆ, ಆದರೆ ಬಹುಶಃ NoSQL ಪರಿಹಾರಗಳಿಗೆ (ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಂತಹ) ಹೆಚ್ಚಿನ ಬೆಂಬಲ ಮುಂದುವರಿಯುತ್ತದೆ.
ಉ: - ಸಾಮಾನ್ಯವಾಗಿ, ನೀವು ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೊಡೆದುಹಾಕಬಹುದು ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ?
AG: - ಸಹಜವಾಗಿ, ಜಬ್ಬಿಕ್ಸ್‌ನಲ್ಲಿ ಅತ್ಯಂತ ಕಷ್ಟಕರವಾದ ಭಾಗವೆಂದರೆ ಐತಿಹಾಸಿಕ ಕೋಷ್ಟಕಗಳು, ಇದು ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಮತ್ತು ಘಟನೆಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಈವೆಂಟ್‌ಗಳನ್ನು ದೀರ್ಘಕಾಲದವರೆಗೆ ಸಂಗ್ರಹಿಸದಿದ್ದರೆ ಮತ್ತು ಇತಿಹಾಸವನ್ನು ಇತರ ವೇಗದ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಟ್ರೆಂಡ್‌ಗಳೊಂದಿಗೆ ಸಂಗ್ರಹಿಸಿದರೆ, ಸಾಮಾನ್ಯವಾಗಿ, ಯಾವುದೇ ತೊಂದರೆಗಳಿಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.
ಉ: - ನೀವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಬದಲಾಯಿಸಿದರೆ ಎಲ್ಲವೂ ಎಷ್ಟು ವೇಗವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ನೀವು ಅಂದಾಜು ಮಾಡಬಹುದೇ?
AG: - ನಾನು ಅದನ್ನು ಪರೀಕ್ಷಿಸಿಲ್ಲ. ಕ್ಲಿಕ್‌ಹೌಸ್ ತನ್ನದೇ ಆದ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹೊಂದಿರುವುದರಿಂದ ಕನಿಷ್ಠ ಅದೇ ಸಂಖ್ಯೆಗಳನ್ನು ಸರಳವಾಗಿ ಸಾಧಿಸಬಹುದು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಆದರೆ ನಾನು ಖಚಿತವಾಗಿ ಹೇಳಲಾರೆ. ಪರೀಕ್ಷಿಸುವುದು ಉತ್ತಮ. ಇದು ಎಲ್ಲಾ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ: ನೀವು ಎಷ್ಟು ಹೋಸ್ಟ್ಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಇತ್ಯಾದಿ. ಸೇರಿಸುವುದು ಒಂದು ವಿಷಯ, ಆದರೆ ನೀವು ಈ ಡೇಟಾವನ್ನು ಹಿಂಪಡೆಯಬೇಕು - ಗ್ರಾಫನಾ ಅಥವಾ ಇನ್ನೇನಾದರೂ.
ಉ: - ಆದ್ದರಿಂದ ನಾವು ಸಮಾನ ಹೋರಾಟದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಈ ವೇಗದ ಡೇಟಾಬೇಸ್‌ಗಳ ಉತ್ತಮ ಪ್ರಯೋಜನದ ಬಗ್ಗೆ ಅಲ್ಲವೇ?
AG: - ನಾವು ಸಂಯೋಜಿಸಿದಾಗ, ಹೆಚ್ಚು ನಿಖರವಾದ ಪರೀಕ್ಷೆಗಳು ಇರುತ್ತವೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.
ಉ: - ಒಳ್ಳೆಯ ಹಳೆಯ RRD ಎಲ್ಲಿಗೆ ಹೋಯಿತು? ನೀವು SQL ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಬದಲಾಯಿಸಲು ಕಾರಣವೇನು? ಆರಂಭದಲ್ಲಿ, ಎಲ್ಲಾ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು RRD ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ.
AG: - ಜಬ್ಬಿಕ್ಸ್ RRD ಅನ್ನು ಹೊಂದಿತ್ತು, ಬಹುಶಃ ಬಹಳ ಪ್ರಾಚೀನ ಆವೃತ್ತಿಯಲ್ಲಿದೆ. ಯಾವಾಗಲೂ SQL ಡೇಟಾಬೇಸ್‌ಗಳಿವೆ - ಒಂದು ಶ್ರೇಷ್ಠ ವಿಧಾನ. ಕ್ಲಾಸಿಕ್ ವಿಧಾನವೆಂದರೆ MySQL, PostgreSQL (ಅವು ಬಹಳ ಸಮಯದಿಂದ ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ). SQL ಮತ್ತು RRD ಡೇಟಾಬೇಸ್‌ಗಳಿಗಾಗಿ ನಾವು ಎಂದಿಗೂ ಸಾಮಾನ್ಯ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಬಳಸಲಿಲ್ಲ.
ಕೆಲವು ಜಾಹೀರಾತುಗಳು 🙂
ನಮ್ಮೊಂದಿಗೆ ಇರುವುದಕ್ಕೆ ಧನ್ಯವಾದಗಳು. ನೀವು ನಮ್ಮ ಲೇಖನಗಳನ್ನು ಇಷ್ಟಪಡುತ್ತೀರಾ? ಹೆಚ್ಚು ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವನ್ನು ನೋಡಲು ಬಯಸುವಿರಾ? ಆರ್ಡರ್ ಮಾಡುವ ಮೂಲಕ ಅಥವಾ ಸ್ನೇಹಿತರಿಗೆ ಶಿಫಾರಸು ಮಾಡುವ ಮೂಲಕ ನಮ್ಮನ್ನು ಬೆಂಬಲಿಸಿ, , ಪ್ರವೇಶ ಮಟ್ಟದ ಸರ್ವರ್‌ಗಳ ಅನನ್ಯ ಅನಲಾಗ್, ಇದನ್ನು ನಿಮಗಾಗಿ ನಾವು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ: (RAID1 ಮತ್ತು RAID10, 24 ಕೋರ್‌ಗಳವರೆಗೆ ಮತ್ತು 40GB DDR4 ವರೆಗೆ ಲಭ್ಯವಿದೆ).
ಆಮ್‌ಸ್ಟರ್‌ಡ್ಯಾಮ್‌ನಲ್ಲಿರುವ Equinix Tier IV ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ Dell R730xd 2x ಅಗ್ಗವಾಗಿದೆಯೇ? ಇಲ್ಲಿ ಮಾತ್ರ ನೆದರ್ಲ್ಯಾಂಡ್ಸ್ನಲ್ಲಿ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 ರಿಂದ! ಬಗ್ಗೆ ಓದು
ಮೂಲ: www.habr.com