ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಸ್ಥಳೀಯ ವಿಭಜನೆ: ಟೈಮ್‌ಸ್ಕೇಲ್‌ಡಿಬಿ ಬೆಂಬಲದೊಂದಿಗೆ ಝಬ್ಬಿಕ್ಸ್

Zabbix ಒಂದು ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ. ಯಾವುದೇ ಇತರ ವ್ಯವಸ್ಥೆಯಂತೆ, ಇದು ಎಲ್ಲಾ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗಳ ಮೂರು ಪ್ರಮುಖ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುತ್ತದೆ: ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದು, ಇತಿಹಾಸವನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಮತ್ತು ಅದನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುವುದು.

ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುವ, ಸಂಸ್ಕರಿಸುವ ಮತ್ತು ರೆಕಾರ್ಡಿಂಗ್ ಮಾಡುವ ಹಂತಗಳು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಹೆಚ್ಚು ಅಲ್ಲ, ಆದರೆ ದೊಡ್ಡ ವ್ಯವಸ್ಥೆಗೆ ಇದು ದೊಡ್ಡ ವಿಳಂಬಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು. ಶೇಖರಣಾ ಸಮಸ್ಯೆಯು ಡೇಟಾ ಪ್ರವೇಶ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಅವುಗಳನ್ನು ವರದಿಗಳು, ತಪಾಸಣೆಗಳು ಮತ್ತು ಪ್ರಚೋದಕಗಳಿಗಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಡೇಟಾ ಪ್ರವೇಶದಲ್ಲಿನ ಲೇಟೆನ್ಸಿಗಳು ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ. ಡೇಟಾಬೇಸ್‌ಗಳು ಬೆಳೆದಾಗ, ಅಪ್ರಸ್ತುತ ಡೇಟಾವನ್ನು ಅಳಿಸಬೇಕಾಗುತ್ತದೆ. ತೆಗೆದುಹಾಕುವುದು ಕಷ್ಟಕರವಾದ ಕಾರ್ಯಾಚರಣೆಯಾಗಿದ್ದು ಅದು ಕೆಲವು ಸಂಪನ್ಮೂಲಗಳನ್ನು ತಿನ್ನುತ್ತದೆ.

Zabbix ನಲ್ಲಿ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಸಂಗ್ರಹಣೆಯ ಸಮಯದಲ್ಲಿ ವಿಳಂಬದ ಸಮಸ್ಯೆಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಮೂಲಕ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ: ಹಲವಾರು ರೀತಿಯ ಸಂಗ್ರಹಗಳು, ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದು. ಮೂರನೇ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದು ಸೂಕ್ತವಲ್ಲ, ಆದ್ದರಿಂದ Zabbix TimescaleDB ಅನ್ನು ಬಳಸಿದೆ. ಅವನು ಅದರ ಬಗ್ಗೆ ಹೇಳುತ್ತಾನೆ ಆಂಡ್ರೆ ಗುಶ್ಚಿನ್ - ತಾಂತ್ರಿಕ ಬೆಂಬಲ ಎಂಜಿನಿಯರ್ ಜಬ್ಬಿಕ್ಸ್ SIA. ಆಂಡ್ರೆ 6 ವರ್ಷಗಳಿಗೂ ಹೆಚ್ಚು ಕಾಲ ಜಬ್ಬಿಕ್ಸ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯೊಂದಿಗೆ ನೇರ ಅನುಭವವನ್ನು ಹೊಂದಿದ್ದಾರೆ.

TimescaleDB ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಸಾಮಾನ್ಯ PostgreSQL ಗೆ ಹೋಲಿಸಿದರೆ ಇದು ಯಾವ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನೀಡುತ್ತದೆ? TimescaleDB ಡೇಟಾಬೇಸ್‌ಗಾಗಿ Zabbix ಯಾವ ಪಾತ್ರವನ್ನು ವಹಿಸುತ್ತದೆ? ಮೊದಲಿನಿಂದ ಹೇಗೆ ಪ್ರಾರಂಭಿಸುವುದು ಮತ್ತು PostgreSQL ನಿಂದ ಹೇಗೆ ವಲಸೆ ಹೋಗುವುದು ಮತ್ತು ಯಾವ ಕಾನ್ಫಿಗರೇಶನ್ ಉತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೊಂದಿದೆ? ಕಟ್ ಅಡಿಯಲ್ಲಿ ಈ ಎಲ್ಲಾ ಬಗ್ಗೆ.

ಉತ್ಪಾದಕತೆಯ ಸವಾಲುಗಳು

ಪ್ರತಿಯೊಂದು ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯು ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸವಾಲುಗಳನ್ನು ಎದುರಿಸುತ್ತಿದೆ. ನಾನು ಅವುಗಳಲ್ಲಿ ಮೂರು ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇನೆ: ಡೇಟಾ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಸಂಸ್ಕರಣೆ, ಸಂಗ್ರಹಣೆ ಮತ್ತು ಇತಿಹಾಸವನ್ನು ತೆರವುಗೊಳಿಸುವುದು.

ವೇಗದ ಡೇಟಾ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಪ್ರಕ್ರಿಯೆ. ಉತ್ತಮ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯು ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ತ್ವರಿತವಾಗಿ ಸ್ವೀಕರಿಸಬೇಕು ಮತ್ತು ಪ್ರಚೋದಕ ಅಭಿವ್ಯಕ್ತಿಗಳ ಪ್ರಕಾರ ಅದನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕು - ಅದರ ಮಾನದಂಡಗಳ ಪ್ರಕಾರ. ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದ ನಂತರ, ಸಿಸ್ಟಮ್ ಈ ಡೇಟಾವನ್ನು ನಂತರದ ಬಳಕೆಗಾಗಿ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ತ್ವರಿತವಾಗಿ ಉಳಿಸಬೇಕು.

ಇತಿಹಾಸ ಸಂಗ್ರಹಣೆ. ಉತ್ತಮ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯು ಇತಿಹಾಸವನ್ನು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಬೇಕು ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳಿಗೆ ಸುಲಭ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸಬೇಕು. ವರದಿಗಳು, ಗ್ರಾಫ್‌ಗಳು, ಟ್ರಿಗ್ಗರ್‌ಗಳು, ಥ್ರೆಶೋಲ್ಡ್‌ಗಳು ಮತ್ತು ಲೆಕ್ಕಾಚಾರದ ಎಚ್ಚರಿಕೆ ಡೇಟಾ ಐಟಂಗಳಲ್ಲಿ ಇತಿಹಾಸವನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ.

ಇತಿಹಾಸವನ್ನು ತೆರವುಗೊಳಿಸುವುದು. ಕೆಲವೊಮ್ಮೆ ನೀವು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲದ ದಿನ ಬರುತ್ತದೆ. 5 ವರ್ಷಗಳ ಹಿಂದೆ, ಒಂದು ತಿಂಗಳು ಅಥವಾ ಎರಡು ತಿಂಗಳ ಹಿಂದೆ ಸಂಗ್ರಹಿಸಿದ ಡೇಟಾ ನಿಮಗೆ ಏಕೆ ಬೇಕು: ಕೆಲವು ನೋಡ್‌ಗಳನ್ನು ಅಳಿಸಲಾಗಿದೆ, ಕೆಲವು ಹೋಸ್ಟ್‌ಗಳು ಅಥವಾ ಮೆಟ್ರಿಕ್‌ಗಳು ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲ ಏಕೆಂದರೆ ಅವುಗಳು ಹಳೆಯದಾಗಿರುತ್ತವೆ ಮತ್ತು ಇನ್ನು ಮುಂದೆ ಸಂಗ್ರಹಿಸಲಾಗುವುದಿಲ್ಲ. ಉತ್ತಮ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯು ಐತಿಹಾಸಿಕ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಬೇಕು ಮತ್ತು ಡೇಟಾಬೇಸ್ ಬೆಳೆಯದಂತೆ ಕಾಲಕಾಲಕ್ಕೆ ಅಳಿಸಬೇಕು.

ಹಳೆಯ ಡೇಟಾವನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುವುದು ಒಂದು ನಿರ್ಣಾಯಕ ಸಮಸ್ಯೆಯಾಗಿದ್ದು ಅದು ಡೇಟಾಬೇಸ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.

Zabbix ನಲ್ಲಿ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದು

Zabbix ನಲ್ಲಿ, ಮೊದಲ ಮತ್ತು ಎರಡನೆಯ ಕರೆಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಮೂಲಕ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ. ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು RAM ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಸಂಗ್ರಹಣೆಗಾಗಿ - ಟ್ರಿಗ್ಗರ್‌ಗಳು, ಗ್ರಾಫ್‌ಗಳು ಮತ್ತು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿದ ಡೇಟಾ ಅಂಶಗಳಲ್ಲಿನ ಇತಿಹಾಸ. ಡೇಟಾಬೇಸ್ ಭಾಗದಲ್ಲಿ ಮೂಲಭೂತ ಆಯ್ಕೆಗಳಿಗಾಗಿ ಕೆಲವು ಕ್ಯಾಶಿಂಗ್ ಇದೆ, ಉದಾಹರಣೆಗೆ, ಗ್ರಾಫ್ಗಳು.

Zabbix ಸರ್ವರ್‌ನ ಬದಿಯಲ್ಲಿ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದು:

• ಸಂರಚನಾ ಸಂಗ್ರಹ;
• ಮೌಲ್ಯ ಸಂಗ್ರಹ;
• ಇತಿಹಾಸ ಸಂಗ್ರಹ;
• TrendsCache.

ಅವುಗಳನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ಪರಿಗಣಿಸೋಣ.

ಸಂರಚನಾ ಸಂಗ್ರಹ

ಇದು ನಾವು ಮೆಟ್ರಿಕ್‌ಗಳು, ಹೋಸ್ಟ್‌ಗಳು, ಡೇಟಾ ಐಟಂಗಳು, ಟ್ರಿಗ್ಗರ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಮುಖ್ಯ ಸಂಗ್ರಹವಾಗಿದೆ - ಪೂರ್ವ ಸಂಸ್ಕರಣೆಗೆ ಮತ್ತು ಡೇಟಾ ಸಂಗ್ರಹಣೆಗಾಗಿ ನಮಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ.

ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಅನಗತ್ಯ ಪ್ರಶ್ನೆಗಳನ್ನು ರಚಿಸದಂತೆ ಇದೆಲ್ಲವನ್ನೂ ಕಾನ್ಫಿಗರೇಶನ್ ಕ್ಯಾಶ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ. ಸರ್ವರ್ ಪ್ರಾರಂಭವಾದ ನಂತರ, ನಾವು ಈ ಸಂಗ್ರಹವನ್ನು ನವೀಕರಿಸುತ್ತೇವೆ, ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ರಚಿಸುತ್ತೇವೆ ಮತ್ತು ನಿಯತಕಾಲಿಕವಾಗಿ ನವೀಕರಿಸುತ್ತೇವೆ.

ಮಾಹಿತಿ ಸಂಗ್ರಹ

ರೇಖಾಚಿತ್ರವು ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿದೆ, ಆದರೆ ಅದರಲ್ಲಿ ಮುಖ್ಯ ವಿಷಯ ಸಂಗ್ರಾಹಕರು. ಇವು ವಿವಿಧ “ಪೋಲರ್‌ಗಳು” - ಅಸೆಂಬ್ಲಿ ಪ್ರಕ್ರಿಯೆಗಳು. ಅವರು ವಿವಿಧ ರೀತಿಯ ಜೋಡಣೆಗೆ ಜವಾಬ್ದಾರರಾಗಿರುತ್ತಾರೆ: ಅವರು SNMP, IPMI ಮೂಲಕ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತಾರೆ ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಪೂರ್ವ ಪ್ರಕ್ರಿಯೆಗೆ ವರ್ಗಾಯಿಸುತ್ತಾರೆ.

ಸಂಗ್ರಾಹಕರನ್ನು ಕಿತ್ತಳೆ ಬಣ್ಣದಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ.

ಚೆಕ್‌ಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸಲು ಅಗತ್ಯವಿರುವ ಒಟ್ಟುಗೂಡಿಸುವ ಐಟಂಗಳನ್ನು Zabbix ಲೆಕ್ಕಾಚಾರ ಮಾಡಿದೆ. ನಾವು ಅವುಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನಾವು ಅವರಿಗೆ ಡೇಟಾವನ್ನು ನೇರವಾಗಿ ValueCache ನಿಂದ ಪಡೆದುಕೊಳ್ಳುತ್ತೇವೆ.

ಪೂರ್ವ ಸಂಸ್ಕರಣೆ ಇತಿಹಾಸ ಸಂಗ್ರಹ

ಎಲ್ಲಾ ಸಂಗ್ರಾಹಕರು ಉದ್ಯೋಗಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಕಾನ್ಫಿಗರೇಶನ್ ಕ್ಯಾಶ್ ಅನ್ನು ಬಳಸುತ್ತಾರೆ. ನಂತರ ಅವರು ಅವುಗಳನ್ನು ಪ್ರಿಪ್ರೊಸೆಸಿಂಗ್‌ಗೆ ವರ್ಗಾಯಿಸುತ್ತಾರೆ.

ಪ್ರಿಪ್ರೊಸೆಸಿಂಗ್ ಹಂತಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಕಾನ್ಫಿಗರೇಶನ್ ಕ್ಯಾಶ್ ಅನ್ನು ಪ್ರಿಪ್ರೊಸೆಸಿಂಗ್ ಬಳಸುತ್ತದೆ. ಇದು ಈ ಡೇಟಾವನ್ನು ವಿವಿಧ ರೀತಿಯಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ.

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

ಗಮನಿಸಿ: ಪೂರ್ವ ಸಂಸ್ಕರಣೆಯು ತುಂಬಾ ಕಷ್ಟಕರವಾದ ಕಾರ್ಯಾಚರಣೆಯಾಗಿದೆ. ವಿ 4.2 ನೊಂದಿಗೆ ಅದನ್ನು ಪ್ರಾಕ್ಸಿಗೆ ಸರಿಸಲಾಗಿದೆ. ನೀವು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಡೇಟಾ ಅಂಶಗಳು ಮತ್ತು ಸಂಗ್ರಹಣೆ ಆವರ್ತನದೊಂದಿಗೆ ಬಹಳ ದೊಡ್ಡ Zabbix ಹೊಂದಿದ್ದರೆ, ಇದು ಕೆಲಸವನ್ನು ಹೆಚ್ಚು ಸುಲಭಗೊಳಿಸುತ್ತದೆ.

ಮೌಲ್ಯ ಸಂಗ್ರಹ, ಇತಿಹಾಸ ಮತ್ತು ಪ್ರವೃತ್ತಿಗಳ ಸಂಗ್ರಹ

ಇತಿಹಾಸ ಸಿನ್ಸರ್ ಮುಖ್ಯ ಪ್ರಕ್ರಿಯೆಯಾಗಿದ್ದು ಅದು ಪ್ರತಿ ಡೇಟಾ ಅಂಶವನ್ನು ಪರಮಾಣುವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ, ಅಂದರೆ ಪ್ರತಿ ಮೌಲ್ಯ.

ಹಿಸ್ಟರಿ ಸಿನ್ಸರ್ ಹಿಸ್ಟರಿ ಕ್ಯಾಶ್‌ನಿಂದ ಮೌಲ್ಯಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಲೆಕ್ಕಾಚಾರಗಳಿಗೆ ಟ್ರಿಗ್ಗರ್‌ಗಳ ಉಪಸ್ಥಿತಿಗಾಗಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಅವರು ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದರೆ, ಅದು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ.

ಇತಿಹಾಸ ಸಿನ್ಸರ್ ಈವೆಂಟ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ, ಕಾನ್ಫಿಗರೇಶನ್ ಮತ್ತು ದಾಖಲೆಗಳ ಮೂಲಕ ಅಗತ್ಯವಿದ್ದರೆ ಎಚ್ಚರಿಕೆಗಳನ್ನು ರಚಿಸಲು ಉಲ್ಬಣಗೊಳ್ಳುತ್ತದೆ. ನಂತರದ ಪ್ರಕ್ರಿಯೆಗೆ ಪ್ರಚೋದಕಗಳು ಇದ್ದಲ್ಲಿ, ಇತಿಹಾಸ ಕೋಷ್ಟಕವನ್ನು ಪ್ರವೇಶಿಸದಂತೆ ಮೌಲ್ಯ ಸಂಗ್ರಹದಲ್ಲಿ ಈ ಮೌಲ್ಯವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಟ್ರಿಗ್ಗರ್‌ಗಳು ಮತ್ತು ಲೆಕ್ಕಹಾಕಿದ ಅಂಶಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಅಗತ್ಯವಾದ ಡೇಟಾದೊಂದಿಗೆ ValueCache ತುಂಬಿದೆ.

ಇತಿಹಾಸ ಸಿನ್ಸರ್ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಡೇಟಾಬೇಸ್‌ಗೆ ಬರೆಯುತ್ತದೆ ಮತ್ತು ಅದು ಡಿಸ್ಕ್‌ಗೆ ಬರೆಯುತ್ತದೆ. ಸಂಸ್ಕರಣಾ ಪ್ರಕ್ರಿಯೆಯು ಇಲ್ಲಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.

ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಕ್ಯಾಶಿಂಗ್

ಡೇಟಾಬೇಸ್ ಬದಿಯಲ್ಲಿ ನೀವು ಈವೆಂಟ್‌ಗಳ ಗ್ರಾಫ್‌ಗಳು ಅಥವಾ ವರದಿಗಳನ್ನು ವೀಕ್ಷಿಸಲು ಬಯಸಿದಾಗ ವಿವಿಧ ಸಂಗ್ರಹಗಳಿವೆ:

• Innodb_buffer_pool MySQL ಬದಿಯಲ್ಲಿ;
• shared_buffers PostgreSQL ಬದಿಯಲ್ಲಿ;
• effective_cache_size ಒರಾಕಲ್ ಭಾಗದಲ್ಲಿ;
• shared_pool DB2 ಬದಿಯಲ್ಲಿ.

ಅನೇಕ ಇತರ ಕ್ಯಾಶ್‌ಗಳಿವೆ, ಆದರೆ ಇವು ಎಲ್ಲಾ ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಮುಖ್ಯವಾದವುಗಳಾಗಿವೆ. ಪ್ರಶ್ನೆಗಳಿಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಅಗತ್ಯವಿರುವ RAM ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಅವು ನಿಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತವೆ. ಇದಕ್ಕಾಗಿ ಅವರು ತಮ್ಮದೇ ಆದ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ.

ಡೇಟಾಬೇಸ್ ಕಾರ್ಯಕ್ಷಮತೆ ನಿರ್ಣಾಯಕವಾಗಿದೆ

Zabbix ಸರ್ವರ್ ನಿರಂತರವಾಗಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಬರೆಯುತ್ತದೆ. ಮರುಪ್ರಾರಂಭಿಸಿದಾಗ, ಮೌಲ್ಯ ಸಂಗ್ರಹವನ್ನು ತುಂಬಲು ಇದು ಇತಿಹಾಸದಿಂದ ಓದುತ್ತದೆ. ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಮತ್ತು ವರದಿಗಳನ್ನು ಬಳಸುತ್ತದೆ Zabbix API, ಇದು ವೆಬ್ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾಗಿದೆ. Zabbix API ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ ಮತ್ತು ಗ್ರಾಫ್‌ಗಳು, ವರದಿಗಳು, ಈವೆಂಟ್ ಪಟ್ಟಿಗಳು ಮತ್ತು ಇತ್ತೀಚಿನ ಸಮಸ್ಯೆಗಳಿಗೆ ಅಗತ್ಯವಾದ ಡೇಟಾವನ್ನು ಹಿಂಪಡೆಯುತ್ತದೆ.

ದೃಶ್ಯೀಕರಣಕ್ಕಾಗಿ - ಗ್ರಾಫಾನಾ. ಇದು ನಮ್ಮ ಬಳಕೆದಾರರಲ್ಲಿ ಜನಪ್ರಿಯ ಪರಿಹಾರವಾಗಿದೆ. ಇದು ನೇರವಾಗಿ Zabbix API ಮೂಲಕ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗೆ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸಬಹುದು ಮತ್ತು ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಲು ನಿರ್ದಿಷ್ಟ ಸ್ಪರ್ಧೆಯನ್ನು ರಚಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ, ಫಲಿತಾಂಶಗಳು ಮತ್ತು ಪರೀಕ್ಷೆಯ ವೇಗದ ವಿತರಣೆಯನ್ನು ಹೊಂದಿಸಲು ಡೇಟಾಬೇಸ್‌ನ ಉತ್ತಮ ಮತ್ತು ಉತ್ತಮ ಶ್ರುತಿ ಅಗತ್ಯವಿದೆ.

ಮನೆಕೆಲಸದಾಕೆ

ಜಬ್ಬಿಕ್ಸ್‌ನಲ್ಲಿನ ಮೂರನೇ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸವಾಲು ಹೌಸ್‌ಕೀಪರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಇತಿಹಾಸವನ್ನು ತೆರವುಗೊಳಿಸುತ್ತದೆ. ಇದು ಎಲ್ಲಾ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಅನುಸರಿಸುತ್ತದೆ - ದಿನಗಳಲ್ಲಿ ಬದಲಾವಣೆಗಳ (ಟ್ರೆಂಡ್‌ಗಳು) ಡೈನಾಮಿಕ್ಸ್ ಅನ್ನು ಎಷ್ಟು ಸಮಯದವರೆಗೆ ಸಂಗ್ರಹಿಸಬೇಕು ಎಂಬುದನ್ನು ಡೇಟಾ ಅಂಶಗಳು ಸೂಚಿಸುತ್ತವೆ.

ನಾವು ಹಾರಾಡುತ್ತ TrendsCache ಅನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತೇವೆ. ಡೇಟಾ ಬಂದಾಗ, ನಾವು ಅದನ್ನು ಒಂದು ಗಂಟೆಯವರೆಗೆ ಒಟ್ಟುಗೂಡಿಸುತ್ತೇವೆ ಮತ್ತು ಪ್ರವೃತ್ತಿಯ ಬದಲಾವಣೆಗಳ ಡೈನಾಮಿಕ್ಸ್‌ಗಾಗಿ ಅದನ್ನು ಕೋಷ್ಟಕಗಳಲ್ಲಿ ರೆಕಾರ್ಡ್ ಮಾಡುತ್ತೇವೆ.

ಹೌಸ್‌ಕೀಪರ್ ಸಾಮಾನ್ಯ "ಆಯ್ಕೆಗಳು" ಬಳಸಿಕೊಂಡು ಡೇಟಾಬೇಸ್‌ನಿಂದ ಮಾಹಿತಿಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಅಳಿಸುತ್ತದೆ. ಆಂತರಿಕ ಪ್ರಕ್ರಿಯೆಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯ ಗ್ರಾಫ್‌ಗಳಿಂದ ನೋಡಬಹುದಾದಂತೆ ಇದು ಯಾವಾಗಲೂ ಪರಿಣಾಮಕಾರಿಯಾಗಿರುವುದಿಲ್ಲ.

ಇತಿಹಾಸ ಸಿನ್ಸರ್ ನಿರಂತರವಾಗಿ ಕಾರ್ಯನಿರತವಾಗಿದೆ ಎಂದು ಕೆಂಪು ಗ್ರಾಫ್ ತೋರಿಸುತ್ತದೆ. ಮೇಲ್ಭಾಗದಲ್ಲಿರುವ ಕಿತ್ತಳೆ ಗ್ರಾಫ್ ಹೌಸ್‌ಕೀಪರ್ ಆಗಿದೆ, ಅದು ನಿರಂತರವಾಗಿ ಚಾಲನೆಯಲ್ಲಿದೆ. ಅವನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಎಲ್ಲಾ ಸಾಲುಗಳನ್ನು ಅಳಿಸಲು ಡೇಟಾಬೇಸ್‌ಗಾಗಿ ಅವನು ಕಾಯುತ್ತಾನೆ.

ನೀವು ಯಾವಾಗ ಹೌಸ್‌ಕೀಪರ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಕು? ಉದಾಹರಣೆಗೆ, "ಐಟಂ ಐಡಿ" ಇದೆ ಮತ್ತು ನೀವು ನಿರ್ದಿಷ್ಟ ಸಮಯದೊಳಗೆ ಕೊನೆಯ 5 ಸಾವಿರ ಸಾಲುಗಳನ್ನು ಅಳಿಸಬೇಕಾಗಿದೆ. ಸಹಜವಾಗಿ, ಇದು ಸೂಚ್ಯಂಕದಿಂದ ಸಂಭವಿಸುತ್ತದೆ. ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಡೇಟಾಸೆಟ್ ತುಂಬಾ ದೊಡ್ಡದಾಗಿದೆ, ಮತ್ತು ಡೇಟಾಬೇಸ್ ಇನ್ನೂ ಡಿಸ್ಕ್ನಿಂದ ಓದುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಸಂಗ್ರಹಕ್ಕೆ ಇರಿಸುತ್ತದೆ. ಡೇಟಾಬೇಸ್‌ಗೆ ಇದು ಯಾವಾಗಲೂ ಅತ್ಯಂತ ದುಬಾರಿ ಕಾರ್ಯಾಚರಣೆಯಾಗಿದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ನ ಗಾತ್ರವನ್ನು ಅವಲಂಬಿಸಿ, ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.

ಹೌಸ್‌ಕೀಪರ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಸುಲಭ. ವೆಬ್ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಹೌಸ್‌ಕೀಪರ್‌ಗಾಗಿ "ಅಡ್ಮಿನಿಸ್ಟ್ರೇಷನ್ ಜನರಲ್" ನಲ್ಲಿ ಸೆಟ್ಟಿಂಗ್ ಇದೆ. ಆಂತರಿಕ ಪ್ರವೃತ್ತಿಯ ಇತಿಹಾಸಕ್ಕಾಗಿ ನಾವು ಆಂತರಿಕ ಮನೆಗೆಲಸವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುತ್ತೇವೆ ಮತ್ತು ಅದು ಇನ್ನು ಮುಂದೆ ಅದನ್ನು ನಿರ್ವಹಿಸುವುದಿಲ್ಲ.

ಹೌಸ್‌ಕೀಪರ್ ಅನ್ನು ಆಫ್ ಮಾಡಲಾಗಿದೆ, ಗ್ರಾಫ್‌ಗಳನ್ನು ನೆಲಸಮಗೊಳಿಸಲಾಗಿದೆ - ಈ ಸಂದರ್ಭದಲ್ಲಿ ಯಾವ ಸಮಸ್ಯೆಗಳಿರಬಹುದು ಮತ್ತು ಮೂರನೇ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸವಾಲನ್ನು ಪರಿಹರಿಸಲು ಯಾವುದು ಸಹಾಯ ಮಾಡುತ್ತದೆ?

ವಿಭಜನೆ - ವಿಭಜನೆ ಅಥವಾ ವಿಭಜನೆ

ವಿಶಿಷ್ಟವಾಗಿ, ನಾನು ಪಟ್ಟಿ ಮಾಡಿದ ಪ್ರತಿಯೊಂದು ಸಂಬಂಧಿತ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ವಿಭಜನೆಯನ್ನು ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ. ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಆದ ತಂತ್ರಜ್ಞಾನವನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ಅವುಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಹೋಲುತ್ತವೆ. ಹೊಸ ವಿಭಾಗವನ್ನು ರಚಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲವು ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

ವಿಶಿಷ್ಟವಾಗಿ, "ಸೆಟಪ್" ಅನ್ನು ಅವಲಂಬಿಸಿ ವಿಭಾಗಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗುತ್ತದೆ - ಒಂದು ದಿನದಲ್ಲಿ ರಚಿಸಲಾದ ಡೇಟಾದ ಪ್ರಮಾಣ. ನಿಯಮದಂತೆ, ವಿಭಜನೆಯನ್ನು ಒಂದು ದಿನದಲ್ಲಿ ನೀಡಲಾಗುತ್ತದೆ, ಇದು ಕನಿಷ್ಠವಾಗಿದೆ. ಹೊಸ ಬ್ಯಾಚ್ನ ಪ್ರವೃತ್ತಿಗಳಿಗಾಗಿ - 1 ತಿಂಗಳು.

"ಸೆಟಪ್" ತುಂಬಾ ದೊಡ್ಡದಾಗಿದ್ದರೆ ಮೌಲ್ಯಗಳು ಬದಲಾಗಬಹುದು. ಒಂದು ಸಣ್ಣ "ಸೆಟಪ್" 5 nvps (ಸೆಕೆಂಡಿಗೆ ಹೊಸ ಮೌಲ್ಯಗಳು) ವರೆಗೆ ಇದ್ದರೆ, ಮಧ್ಯಮ ಒಂದು 000 ರಿಂದ 5 ವರೆಗೆ ಇರುತ್ತದೆ, ನಂತರ ದೊಡ್ಡದು 000 nvps ಗಿಂತ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ. ಇವುಗಳು ದೊಡ್ಡದಾದ ಮತ್ತು ಅತಿ ದೊಡ್ಡ ಅನುಸ್ಥಾಪನೆಗಳಾಗಿದ್ದು, ಡೇಟಾಬೇಸ್ನ ಎಚ್ಚರಿಕೆಯಿಂದ ಸಂರಚಿಸುವ ಅಗತ್ಯವಿರುತ್ತದೆ.

ದೊಡ್ಡ ಅನುಸ್ಥಾಪನೆಗಳಲ್ಲಿ, ಒಂದು ದಿನದ ಅವಧಿಯು ಸೂಕ್ತವಾಗಿರುವುದಿಲ್ಲ. ನಾನು ದಿನಕ್ಕೆ 40 GB ಅಥವಾ ಅದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ MySQL ವಿಭಾಗಗಳನ್ನು ನೋಡಿದ್ದೇನೆ. ಇದು ಬಹಳ ದೊಡ್ಡ ಪ್ರಮಾಣದ ಡೇಟಾವಾಗಿದ್ದು ಅದು ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು ಮತ್ತು ಕಡಿಮೆ ಮಾಡಬೇಕಾಗಿದೆ.

ವಿಭಜನೆ ಏನು ನೀಡುತ್ತದೆ?

ವಿಭಜನಾ ಕೋಷ್ಟಕಗಳು. ಸಾಮಾನ್ಯವಾಗಿ ಇವುಗಳು ಡಿಸ್ಕ್ನಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಫೈಲ್ಗಳಾಗಿವೆ. ಪ್ರಶ್ನೆ ಯೋಜನೆಯು ಒಂದು ವಿಭಾಗವನ್ನು ಹೆಚ್ಚು ಅತ್ಯುತ್ತಮವಾಗಿ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ ವಿಭಜನೆಯನ್ನು ವ್ಯಾಪ್ತಿಯಿಂದ ಬಳಸಲಾಗುತ್ತದೆ - ಇದು Zabbix ಗೆ ಸಹ ನಿಜವಾಗಿದೆ. ನಾವು ಅಲ್ಲಿ “ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್” ಅನ್ನು ಬಳಸುತ್ತೇವೆ - ಯುಗದ ಆರಂಭದಿಂದಲೂ ಸಮಯ. ಇವು ನಮಗೆ ಸಾಮಾನ್ಯ ಸಂಖ್ಯೆಗಳು. ನೀವು ದಿನದ ಆರಂಭ ಮತ್ತು ಅಂತ್ಯವನ್ನು ಹೊಂದಿಸಿದ್ದೀರಿ - ಇದು ವಿಭಜನೆಯಾಗಿದೆ.

ತ್ವರಿತ ತೆಗೆಯುವಿಕೆ - DELETE. ಅಳಿಸುವಿಕೆಗೆ ಸಾಲುಗಳ ಆಯ್ಕೆಯ ಬದಲಿಗೆ ಒಂದು ಫೈಲ್/ಸಬ್ಟೇಬಲ್ ಅನ್ನು ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ.

ಡೇಟಾ ಮರುಪಡೆಯುವಿಕೆಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ವೇಗಗೊಳಿಸುತ್ತದೆ SELECT - ಸಂಪೂರ್ಣ ಕೋಷ್ಟಕಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ವಿಭಾಗಗಳನ್ನು ಬಳಸುತ್ತದೆ. ನೀವು ಎರಡು ದಿನಗಳ ಹಳೆಯ ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸಿದರೆ, ಅದನ್ನು ಡೇಟಾಬೇಸ್‌ನಿಂದ ವೇಗವಾಗಿ ಹಿಂಪಡೆಯಲಾಗುತ್ತದೆ ಏಕೆಂದರೆ ನೀವು ಕೇವಲ ಒಂದು ಫೈಲ್ ಅನ್ನು ಸಂಗ್ರಹಕ್ಕೆ ಲೋಡ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕು, ದೊಡ್ಡ ಟೇಬಲ್ ಅಲ್ಲ.

ಸಾಮಾನ್ಯವಾಗಿ ಅನೇಕ ಡೇಟಾಬೇಸ್‌ಗಳು ವೇಗವರ್ಧಿತವಾಗಿರುತ್ತವೆ INSERT - ಮಕ್ಕಳ ಕೋಷ್ಟಕದಲ್ಲಿ ಅಳವಡಿಕೆಗಳು.

ಟೈಮ್ಸ್ ಸ್ಕೇಲ್ಡಿಬಿ

v 4.2 ಗಾಗಿ, ನಾವು ನಮ್ಮ ಗಮನವನ್ನು TimescaleDB ಗೆ ತಿರುಗಿಸಿದ್ದೇವೆ. ಇದು ಸ್ಥಳೀಯ ಇಂಟರ್‌ಫೇಸ್‌ನೊಂದಿಗೆ PostgreSQL ಗಾಗಿ ವಿಸ್ತರಣೆಯಾಗಿದೆ. ಸಂಬಂಧಿತ ಡೇಟಾಬೇಸ್‌ಗಳ ಪ್ರಯೋಜನಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳದೆ, ಸಮಯ ಸರಣಿಯ ಡೇಟಾದೊಂದಿಗೆ ವಿಸ್ತರಣೆಯು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. TimescaleDB ಸಹ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ವಿಭಾಗಿಸುತ್ತದೆ.

TimescaleDB ಒಂದು ಪರಿಕಲ್ಪನೆಯನ್ನು ಹೊಂದಿದೆ ಹೈಪರ್ಟೇಬಲ್ (ಹೈಪರ್ಟೇಬಲ್) ನೀವು ರಚಿಸುವ. ಇದು ಒಳಗೊಂಡಿದೆ ತುಂಡುಗಳು - ವಿಭಾಗಗಳು. ಭಾಗಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿರ್ವಹಿಸಲ್ಪಡುವ ಹೈಪರ್ಟೇಬಲ್ ತುಣುಕುಗಳಾಗಿವೆ, ಅದು ಇತರ ತುಣುಕುಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ. ಪ್ರತಿಯೊಂದು ಭಾಗವು ತನ್ನದೇ ಆದ ಸಮಯದ ವ್ಯಾಪ್ತಿಯನ್ನು ಹೊಂದಿದೆ.

TimescaleDB vs PostgreSQL

TimescaleDB ನಿಜವಾಗಿಯೂ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ವಿಸ್ತರಣೆಯ ತಯಾರಕರು ಅವರು ಹೆಚ್ಚು ಸರಿಯಾದ ಪ್ರಶ್ನೆ ಸಂಸ್ಕರಣಾ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಬಳಸುತ್ತಾರೆ ಎಂದು ಹೇಳಿಕೊಳ್ಳುತ್ತಾರೆ, ನಿರ್ದಿಷ್ಟವಾಗಿ inserts . ಡೇಟಾಸೆಟ್ ಇನ್ಸರ್ಟ್ ಗಾತ್ರವು ಬೆಳೆದಂತೆ, ಅಲ್ಗಾರಿದಮ್ ನಿರಂತರ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.

200 ಮಿಲಿಯನ್ ಸಾಲುಗಳ ನಂತರ, PostgreSQL ಸಾಮಾನ್ಯವಾಗಿ ಗಮನಾರ್ಹವಾಗಿ ಕುಸಿಯಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು 0 ಗೆ ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ. TimescaleDB ನಿಮಗೆ ಯಾವುದೇ ಪ್ರಮಾಣದ ಡೇಟಾಗೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿ "ಇನ್ಸರ್ಟ್" ಅನ್ನು ಸೇರಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.

ಸೆಟ್ಟಿಂಗ್

ಟೈಮ್‌ಸ್ಕೇಲ್‌ಡಿಬಿ ಅನ್ನು ಸ್ಥಾಪಿಸುವುದು ಯಾವುದೇ ಪ್ಯಾಕೇಜ್‌ಗೆ ಸಾಕಷ್ಟು ಸುಲಭವಾಗಿದೆ. IN ದಸ್ತಾವೇಜನ್ನು ಎಲ್ಲವನ್ನೂ ವಿವರವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ - ಇದು ಅಧಿಕೃತ PostgreSQL ಪ್ಯಾಕೇಜುಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. TimescaleDB ಅನ್ನು ಕೈಯಾರೆ ನಿರ್ಮಿಸಬಹುದು ಮತ್ತು ಕಂಪೈಲ್ ಮಾಡಬಹುದು.

Zabbix ಡೇಟಾಬೇಸ್‌ಗಾಗಿ ನಾವು ವಿಸ್ತರಣೆಯನ್ನು ಸರಳವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸುತ್ತೇವೆ:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

ನೀವು ಸಕ್ರಿಯಗೊಳಿಸಿ extension ಮತ್ತು Zabbix ಡೇಟಾಬೇಸ್‌ಗಾಗಿ ಅದನ್ನು ರಚಿಸಿ. ಹೈಪರ್ಟೇಬಲ್ ಅನ್ನು ರಚಿಸುವುದು ಕೊನೆಯ ಹಂತವಾಗಿದೆ.

TimescaleDB ಗೆ ಇತಿಹಾಸ ಕೋಷ್ಟಕಗಳನ್ನು ಸ್ಥಳಾಂತರಿಸಲಾಗುತ್ತಿದೆ

ಇದಕ್ಕಾಗಿ ವಿಶೇಷ ಕಾರ್ಯವಿದೆ create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

ಕಾರ್ಯವು ಮೂರು ನಿಯತಾಂಕಗಳನ್ನು ಹೊಂದಿದೆ. ಪ್ರಥಮ - ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಟೇಬಲ್, ಇದಕ್ಕಾಗಿ ನೀವು ಹೈಪರ್ಟೇಬಲ್ ಅನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ. ಎರಡನೇ - ಕ್ಷೇತ್ರ, ಅದರ ಪ್ರಕಾರ ನೀವು ರಚಿಸಬೇಕಾಗಿದೆ chunk_time_interval - ಬಳಸಬೇಕಾದ ವಿಭಜನೆಯ ಭಾಗಗಳ ಮಧ್ಯಂತರ. ನನ್ನ ವಿಷಯದಲ್ಲಿ, ಮಧ್ಯಂತರವು ಒಂದು ದಿನ - 86.

ಮೂರನೇ ನಿಯತಾಂಕ - migrate_data. ನೀವು ಹೊಂದಿಸಿದರೆ true, ನಂತರ ಎಲ್ಲಾ ಪ್ರಸ್ತುತ ಡೇಟಾವನ್ನು ಮೊದಲೇ ರಚಿಸಿದ ಭಾಗಗಳಿಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ. ನಾನೇ ಬಳಸಿಕೊಂಡೆ migrate_data. ನಾನು ಸುಮಾರು 1 TB ಹೊಂದಿದ್ದೆ, ಇದು ಒಂದು ಗಂಟೆಗೂ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಂಡಿತು. ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ, ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ, ಸಂಗ್ರಹಣೆಗೆ ಅಗತ್ಯವಿಲ್ಲದ ಅಕ್ಷರ ಪ್ರಕಾರಗಳ ಐತಿಹಾಸಿಕ ಡೇಟಾವನ್ನು ನಾನು ಅಳಿಸಿದ್ದೇನೆ, ಆದ್ದರಿಂದ ಅವುಗಳನ್ನು ವರ್ಗಾಯಿಸುವುದಿಲ್ಲ.

ಕೊನೆಯ ಹಂತ - UPDATE: ನಲ್ಲಿ db_extension ಹಾಕಿದರು timescaledbಈ ವಿಸ್ತರಣೆಯು ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂದು ಡೇಟಾಬೇಸ್ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ. Zabbix ಅದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗೆ ಸಿಂಟ್ಯಾಕ್ಸ್ ಮತ್ತು ಪ್ರಶ್ನೆಗಳನ್ನು ಸರಿಯಾಗಿ ಬಳಸುತ್ತದೆ - TimescaleDB ಗೆ ಅಗತ್ಯವಿರುವ ವೈಶಿಷ್ಟ್ಯಗಳು.

ಹಾರ್ಡ್ವೇರ್ ಕಾನ್ಫಿಗರೇಶನ್

ನಾನು ಎರಡು ಸರ್ವರ್‌ಗಳನ್ನು ಬಳಸಿದ್ದೇನೆ. ಪ್ರಥಮ - VMware ಯಂತ್ರ. ಇದು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz ಪ್ರೊಸೆಸರ್‌ಗಳು, 16 GB RAM ಮತ್ತು 200 GB SSD.

ನಾನು Debian 10.8-10.8.pgdg1+90 OS ಮತ್ತು xfs ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ PostgreSQL 1 ಅನ್ನು ಸ್ಥಾಪಿಸಿದ್ದೇನೆ. ಈ ನಿರ್ದಿಷ್ಟ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬಳಸಲು ನಾನು ಎಲ್ಲವನ್ನೂ ಕನಿಷ್ಠವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದೇನೆ, Zabbix ಸ್ವತಃ ಏನು ಬಳಸುತ್ತದೆ ಎಂಬುದನ್ನು ಕಡಿಮೆ ಮಾಡಿ.

ಅದೇ ಯಂತ್ರದಲ್ಲಿ Zabbix ಸರ್ವರ್ ಇತ್ತು, PostgreSQL ಮತ್ತು ಲೋಡ್ ಏಜೆಂಟ್. ನಾನು ಬಳಸುತ್ತಿರುವ 50 ಸಕ್ರಿಯ ಏಜೆಂಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇನೆ LoadableModuleವಿಭಿನ್ನ ಫಲಿತಾಂಶಗಳನ್ನು ತ್ವರಿತವಾಗಿ ರಚಿಸಲು: ಸಂಖ್ಯೆಗಳು, ತಂತಿಗಳು. ನಾನು ಬಹಳಷ್ಟು ಡೇಟಾದೊಂದಿಗೆ ಡೇಟಾಬೇಸ್ ಅನ್ನು ತುಂಬಿದೆ.

ಆರಂಭದಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಒಳಗೊಂಡಿತ್ತು 5 ಅಂಶಗಳು ಪ್ರತಿ ಹೋಸ್ಟ್ ಡೇಟಾ. ಬಹುತೇಕ ಪ್ರತಿಯೊಂದು ಅಂಶವು ನೈಜ ಸ್ಥಾಪನೆಗಳಿಗೆ ಹೋಲುವ ಪ್ರಚೋದಕವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಪ್ರಚೋದಕಗಳು ಇದ್ದವು. ಒಂದು ನೆಟ್ವರ್ಕ್ ನೋಡ್ ಇದ್ದವು 3-000 ಟ್ರಿಗ್ಗರ್‌ಗಳು.

ಡೇಟಾ ಐಟಂ ನವೀಕರಣ ಮಧ್ಯಂತರ - 4-7 ಸೆಕೆಂಡುಗಳು. ನಾನು 50 ಏಜೆಂಟ್‌ಗಳನ್ನು ಮಾತ್ರವಲ್ಲದೆ ಹೆಚ್ಚಿನದನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಲೋಡ್ ಅನ್ನು ನಿಯಂತ್ರಿಸಿದೆ. ಅಲ್ಲದೆ, ಡೇಟಾ ಅಂಶಗಳನ್ನು ಬಳಸಿಕೊಂಡು, ನಾನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಲೋಡ್ ಅನ್ನು ಸರಿಹೊಂದಿಸಿದೆ ಮತ್ತು ನವೀಕರಣ ಮಧ್ಯಂತರವನ್ನು 4 ಸೆ.

PostgreSQL. 35 nvps

ಈ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ನನ್ನ ಮೊದಲ ಓಟವು ಶುದ್ಧ PostgreSQL ನಲ್ಲಿತ್ತು - ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 35 ಸಾವಿರ ಮೌಲ್ಯಗಳು. ನೀವು ನೋಡುವಂತೆ, ಡೇಟಾವನ್ನು ಸೇರಿಸುವುದು ಸೆಕೆಂಡಿನ ಭಿನ್ನರಾಶಿಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ - ಎಲ್ಲವೂ ಉತ್ತಮ ಮತ್ತು ವೇಗವಾಗಿರುತ್ತದೆ. ಒಂದೇ ವಿಷಯವೆಂದರೆ 200 GB SSD ಡಿಸ್ಕ್ ತ್ವರಿತವಾಗಿ ತುಂಬುತ್ತದೆ.

ಇದು ಪ್ರಮಾಣಿತ Zabbix ಸರ್ವರ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಆಗಿದೆ.

ಮೊದಲ ನೀಲಿ ಗ್ರಾಫ್ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಮೌಲ್ಯಗಳ ಸಂಖ್ಯೆ. ಬಲಭಾಗದಲ್ಲಿರುವ ಎರಡನೇ ಗ್ರಾಫ್ ನಿರ್ಮಾಣ ಪ್ರಕ್ರಿಯೆಗಳ ಲೋಡ್ ಆಗಿದೆ. ಮೂರನೆಯದು ಆಂತರಿಕ ನಿರ್ಮಾಣ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಲೋಡ್ ಮಾಡುತ್ತಿದೆ: ಇತಿಹಾಸ ಸಿಂಕರ್‌ಗಳು ಮತ್ತು ಹೌಸ್‌ಕೀಪರ್, ಇದು ಇಲ್ಲಿ ಸ್ವಲ್ಪ ಸಮಯದಿಂದ ಚಾಲನೆಯಲ್ಲಿದೆ.

ನಾಲ್ಕನೇ ಗ್ರಾಫ್ ಹಿಸ್ಟರಿ ಕ್ಯಾಶ್ ಬಳಕೆಯನ್ನು ತೋರಿಸುತ್ತದೆ. ಡೇಟಾಬೇಸ್‌ಗೆ ಸೇರಿಸುವ ಮೊದಲು ಇದು ಒಂದು ರೀತಿಯ ಬಫರ್ ಆಗಿದೆ. ಹಸಿರು ಐದನೇ ಗ್ರಾಫ್ ValueCache ಬಳಕೆಯನ್ನು ತೋರಿಸುತ್ತದೆ, ಅಂದರೆ, ಟ್ರಿಗ್ಗರ್‌ಗಳಿಗಾಗಿ ಎಷ್ಟು ValueCache ಹಿಟ್‌ಗಳು - ಇದು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಹಲವಾರು ಸಾವಿರ ಮೌಲ್ಯಗಳು.

PostgreSQL. 50 nvps

ನಂತರ ನಾನು ಅದೇ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಸೆಕೆಂಡಿಗೆ 50 ಸಾವಿರ ಮೌಲ್ಯಗಳಿಗೆ ಲೋಡ್ ಅನ್ನು ಹೆಚ್ಚಿಸಿದೆ.

ಹೌಸ್‌ಕೀಪರ್‌ನಿಂದ ಲೋಡ್ ಮಾಡುವಾಗ, 10 ಸಾವಿರ ಮೌಲ್ಯಗಳನ್ನು ಸೇರಿಸುವುದು 2-3 ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು.

ಮನೆಗೆಲಸದವರು ಈಗಾಗಲೇ ಕೆಲಸದಲ್ಲಿ ಹಸ್ತಕ್ಷೇಪ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದಾರೆ.

ಮೂರನೆಯ ಗ್ರಾಫ್ ಸಾಮಾನ್ಯವಾಗಿ, ಟ್ರ್ಯಾಪರ್‌ಗಳು ಮತ್ತು ಇತಿಹಾಸ ಸಿಂಚರ್‌ಗಳ ಮೇಲಿನ ಹೊರೆ ಇನ್ನೂ 60% ನಲ್ಲಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. ನಾಲ್ಕನೇ ಗ್ರಾಫ್‌ನಲ್ಲಿ, ಹಿಸ್ಟರಿ ಕ್ಯಾಶ್ ಈಗಾಗಲೇ ಹೌಸ್‌ಕೀಪರ್ ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ ಸಾಕಷ್ಟು ಸಕ್ರಿಯವಾಗಿ ತುಂಬಲು ಪ್ರಾರಂಭಿಸುತ್ತಿದೆ. ಇದು 20% ತುಂಬಿದೆ, ಅಂದರೆ ಸುಮಾರು 0,5 GB.

PostgreSQL. 80 nvps

ನಂತರ ನಾನು ಲೋಡ್ ಅನ್ನು ಸೆಕೆಂಡಿಗೆ 80 ಸಾವಿರ ಮೌಲ್ಯಗಳಿಗೆ ಹೆಚ್ಚಿಸಿದೆ. ಇದು ಸರಿಸುಮಾರು 400 ಸಾವಿರ ಡೇಟಾ ಅಂಶಗಳು ಮತ್ತು 280 ಸಾವಿರ ಟ್ರಿಗ್ಗರ್‌ಗಳು.

ಮೂವತ್ತು ಇತಿಹಾಸ ಸಿಂಚರ್‌ಗಳ ಲೋಡ್ ವೆಚ್ಚವು ಈಗಾಗಲೇ ಸಾಕಷ್ಟು ಹೆಚ್ಚಾಗಿದೆ.

ನಾನು ವಿವಿಧ ನಿಯತಾಂಕಗಳನ್ನು ಸಹ ಹೆಚ್ಚಿಸಿದೆ: ಇತಿಹಾಸ ಸಿನ್ಸರ್‌ಗಳು, ಕ್ಯಾಶ್‌ಗಳು.

ನನ್ನ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ, ಇತಿಹಾಸ ಸಿನ್ಸರ್‌ಗಳ ಲೋಡ್ ಗರಿಷ್ಠಕ್ಕೆ ಹೆಚ್ಚಿದೆ. HistoryCache ತ್ವರಿತವಾಗಿ ಡೇಟಾದಿಂದ ತುಂಬಿದೆ - ಪ್ರಕ್ರಿಯೆಗಾಗಿ ಡೇಟಾ ಬಫರ್‌ನಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿದೆ.

ಈ ಸಮಯದಲ್ಲಿ ಪ್ರೊಸೆಸರ್, RAM ಮತ್ತು ಇತರ ಸಿಸ್ಟಮ್ ನಿಯತಾಂಕಗಳನ್ನು ಹೇಗೆ ಬಳಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಾನು ಗಮನಿಸಿದ್ದೇನೆ ಮತ್ತು ಡಿಸ್ಕ್ ಬಳಕೆ ಗರಿಷ್ಠವಾಗಿದೆ ಎಂದು ಕಂಡುಕೊಂಡೆ.

ನಾನು ಬಳಕೆಯನ್ನು ಸಾಧಿಸಿದೆ ಗರಿಷ್ಠ ಡಿಸ್ಕ್ ಸಾಮರ್ಥ್ಯಗಳು ಈ ಯಂತ್ರಾಂಶದಲ್ಲಿ ಮತ್ತು ಈ ವರ್ಚುವಲ್ ಗಣಕದಲ್ಲಿ. ಅಂತಹ ತೀವ್ರತೆಯೊಂದಿಗೆ, PostgreSQL ಸಾಕಷ್ಟು ಸಕ್ರಿಯವಾಗಿ ಡೇಟಾವನ್ನು ಫ್ಲಶ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿತು, ಮತ್ತು ಡಿಸ್ಕ್ ಇನ್ನು ಮುಂದೆ ಬರೆಯಲು ಮತ್ತು ಓದಲು ಸಮಯವನ್ನು ಹೊಂದಿಲ್ಲ.

ಎರಡನೇ ಸರ್ವರ್

ನಾನು ಇನ್ನೊಂದು ಸರ್ವರ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡೆ, ಅದು ಈಗಾಗಲೇ 48 ಪ್ರೊಸೆಸರ್ಗಳು ಮತ್ತು 128 GB RAM ಅನ್ನು ಹೊಂದಿದೆ. ನಾನು ಅದನ್ನು ಟ್ಯೂನ್ ಮಾಡಿದ್ದೇನೆ - ಅದನ್ನು 60 ಹಿಸ್ಟರಿ ಸಿನ್ಸರ್‌ಗೆ ಹೊಂದಿಸಿ ಮತ್ತು ಸ್ವೀಕಾರಾರ್ಹ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಾಧಿಸಿದೆ.

ವಾಸ್ತವವಾಗಿ, ಇದು ಈಗಾಗಲೇ ಏನಾದರೂ ಮಾಡಬೇಕಾದ ಉತ್ಪಾದಕತೆಯ ಮಿತಿಯಾಗಿದೆ.

ಟೈಮ್ಸ್ಕೇಲ್DB. 80 nvps

Zabbix ಲೋಡ್ ವಿರುದ್ಧ TimescaleDB ಯ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಪರೀಕ್ಷಿಸುವುದು ನನ್ನ ಮುಖ್ಯ ಕಾರ್ಯವಾಗಿದೆ. ಸೆಕೆಂಡಿಗೆ 80 ಸಾವಿರ ಮೌಲ್ಯಗಳು ಬಹಳಷ್ಟು, ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಆವರ್ತನ (ಯಾಂಡೆಕ್ಸ್ ಹೊರತುಪಡಿಸಿ, ಸಹಜವಾಗಿ) ಮತ್ತು ಸಾಕಷ್ಟು ದೊಡ್ಡ "ಸೆಟಪ್".

ಪ್ರತಿ ಗ್ರಾಫ್‌ನಲ್ಲಿ ಡಿಪ್ ಇದೆ - ಇದು ನಿಖರವಾಗಿ ಡೇಟಾ ವಲಸೆಯಾಗಿದೆ. Zabbix ಸರ್ವರ್‌ನಲ್ಲಿನ ವೈಫಲ್ಯಗಳ ನಂತರ, ಇತಿಹಾಸ ಸಿನ್ಸರ್‌ನ ಲೋಡಿಂಗ್ ಪ್ರೊಫೈಲ್ ಬಹಳಷ್ಟು ಬದಲಾಗಿದೆ - ಇದು ಮೂರು ಬಾರಿ ಕುಸಿಯಿತು.

TimescaleDB ಸುಮಾರು 3 ಪಟ್ಟು ವೇಗವಾಗಿ ಡೇಟಾವನ್ನು ಸೇರಿಸಲು ಮತ್ತು ಕಡಿಮೆ ಹಿಸ್ಟರಿ ಕ್ಯಾಶ್ ಅನ್ನು ಬಳಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಅಂತೆಯೇ, ನೀವು ಸಮಯಕ್ಕೆ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ.

ಟೈಮ್ಸ್ಕೇಲ್DB. 120 nvps

ನಂತರ ನಾನು ಡೇಟಾ ಅಂಶಗಳ ಸಂಖ್ಯೆಯನ್ನು 500 ಸಾವಿರಕ್ಕೆ ಹೆಚ್ಚಿಸಿದೆ. ಟೈಮ್‌ಸ್ಕೇಲ್‌ಡಿಬಿಯ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಪರೀಕ್ಷಿಸುವುದು ಮುಖ್ಯ ಕಾರ್ಯವಾಗಿತ್ತು - ನಾನು ಸೆಕೆಂಡಿಗೆ 125 ಸಾವಿರ ಮೌಲ್ಯಗಳ ಲೆಕ್ಕಾಚಾರದ ಮೌಲ್ಯವನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇನೆ.

ಇದು ಕೆಲಸ ಮಾಡುವ "ಸೆಟಪ್" ಆಗಿದ್ದು ಅದು ದೀರ್ಘಕಾಲದವರೆಗೆ ಕೆಲಸ ಮಾಡಬಹುದು. ಆದರೆ ನನ್ನ ಡಿಸ್ಕ್ ಕೇವಲ 1,5 TB ಆಗಿದ್ದರಿಂದ, ನಾನು ಅದನ್ನು ಒಂದೆರಡು ದಿನಗಳಲ್ಲಿ ತುಂಬಿದೆ.

ಅದೇ ಸಮಯದಲ್ಲಿ ಹೊಸ ಟೈಮ್‌ಸ್ಕೇಲ್‌ಡಿಬಿ ವಿಭಾಗಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ ಎಂಬುದು ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯ.

ಕಾರ್ಯಕ್ಷಮತೆಗೆ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಗಮನಿಸುವುದಿಲ್ಲ. MySQL ನಲ್ಲಿ ವಿಭಾಗಗಳನ್ನು ರಚಿಸಿದಾಗ, ಉದಾಹರಣೆಗೆ, ಎಲ್ಲವೂ ವಿಭಿನ್ನವಾಗಿರುತ್ತದೆ. ಇದು ಸಾಮಾನ್ಯವಾಗಿ ರಾತ್ರಿಯಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ ಏಕೆಂದರೆ ಇದು ಸಾಮಾನ್ಯ ಒಳಸೇರಿಸುವಿಕೆಯನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ, ಕೋಷ್ಟಕಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸೇವೆಯ ಅವನತಿಯನ್ನು ರಚಿಸಬಹುದು. ಇದು TimescaleDB ಯ ಸಂದರ್ಭದಲ್ಲಿ ಅಲ್ಲ.

ಉದಾಹರಣೆಯಾಗಿ, ನಾನು ಸಮುದಾಯದ ಅನೇಕರಿಂದ ಒಂದು ಗ್ರಾಫ್ ಅನ್ನು ತೋರಿಸುತ್ತೇನೆ. ಚಿತ್ರದಲ್ಲಿ, TimescaleDB ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ, ಇದಕ್ಕೆ ಧನ್ಯವಾದಗಳು ಪ್ರೊಸೆಸರ್‌ನಲ್ಲಿ io.weight ಅನ್ನು ಬಳಸುವ ಲೋಡ್ ಕಡಿಮೆಯಾಗಿದೆ. ಆಂತರಿಕ ಪ್ರಕ್ರಿಯೆಯ ಅಂಶಗಳ ಬಳಕೆಯೂ ಕಡಿಮೆಯಾಗಿದೆ. ಇದಲ್ಲದೆ, ಇದು ಸಾಮಾನ್ಯ ಪ್ಯಾನ್ಕೇಕ್ ಡಿಸ್ಕ್ಗಳಲ್ಲಿ ಸಾಮಾನ್ಯ ವರ್ಚುವಲ್ ಯಂತ್ರವಾಗಿದೆ, SSD ಅಲ್ಲ.

ಸಂಶೋಧನೆಗಳು

TimescaleDB ಸಣ್ಣ "ಸೆಟಪ್" ಗೆ ಉತ್ತಮ ಪರಿಹಾರವಾಗಿದೆ, ಇದು ಡಿಸ್ಕ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಡೇಟಾಬೇಸ್ ಅನ್ನು ಹಾರ್ಡ್‌ವೇರ್‌ಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಸ್ಥಳಾಂತರಿಸುವವರೆಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ.

TimescaleDB ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಸುಲಭವಾಗಿದೆ, ಕಾರ್ಯಕ್ಷಮತೆಯ ಲಾಭವನ್ನು ನೀಡುತ್ತದೆ, Zabbix ಜೊತೆಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು PostgreSQL ಗಿಂತ ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿದೆ.

ನೀವು PostgreSQL ಅನ್ನು ಬಳಸಿದರೆ ಮತ್ತು ಅದನ್ನು ಬದಲಾಯಿಸಲು ಯೋಜಿಸದಿದ್ದರೆ, ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ Zabbix ಜೊತೆಯಲ್ಲಿ TimescaleDB ವಿಸ್ತರಣೆಯೊಂದಿಗೆ PostgreSQL ಅನ್ನು ಬಳಸಿ. ಈ ಪರಿಹಾರವು ಮಧ್ಯಮ "ಸೆಟಪ್" ವರೆಗೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ನಾವು "ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆ" ಎಂದು ಹೇಳಿದಾಗ ನಾವು ಅರ್ಥ ಹೈಲೋಡ್ ++. ಲಕ್ಷಾಂತರ ಬಳಕೆದಾರರಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸಲು ಸೇವೆಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವ ತಂತ್ರಜ್ಞಾನಗಳು ಮತ್ತು ಅಭ್ಯಾಸಗಳ ಬಗ್ಗೆ ತಿಳಿಯಲು ನೀವು ಹೆಚ್ಚು ಸಮಯ ಕಾಯಬೇಕಾಗಿಲ್ಲ. ಪಟ್ಟಿ ವರದಿಗಳು ನವೆಂಬರ್ 7 ಮತ್ತು 8 ಕ್ಕೆ ನಾವು ಈಗಾಗಲೇ ಸಂಕಲಿಸಿದ್ದೇವೆ, ಆದರೆ ಇಲ್ಲಿ ಸಭೆಗಳು ಹೆಚ್ಚಿನದನ್ನು ಸೂಚಿಸಬಹುದು.

ನಮ್ಮ ಚಂದಾದಾರರಾಗಿ лкуылку и ಟೆಲಿಗ್ರಾಮ್, ಇದರಲ್ಲಿ ನಾವು ಮುಂಬರುವ ಸಮ್ಮೇಳನದ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತೇವೆ ಮತ್ತು ಅದರಲ್ಲಿ ಹೆಚ್ಚಿನದನ್ನು ಹೇಗೆ ಪಡೆಯುವುದು ಎಂಬುದನ್ನು ಕಂಡುಕೊಳ್ಳಿ.

ಮೂಲ: www.habr.com