ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್‌ನಲ್ಲಿ ಗೋ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳು. ಅಲೆಕ್ಸಾಂಡರ್ ವಲ್ಯಾಲ್ಕಿನ್

ಅಲೆಕ್ಸಾಂಡರ್ ವಲ್ಯಾಲ್ಕಿನ್ ಅವರ 2019 ರ ಅಂತ್ಯದ ವರದಿಯ ಪ್ರತಿಲೇಖನವನ್ನು ಓದಲು ನಾನು ನಿಮಗೆ ಸಲಹೆ ನೀಡುತ್ತೇನೆ “ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್‌ನಲ್ಲಿ ಗೋ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳು”

ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ - ಸಮಯ ಸರಣಿಯ ರೂಪದಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ವೇಗವಾದ ಮತ್ತು ಸ್ಕೇಲೆಬಲ್ DBMS (ದಾಖಲೆಯು ಈ ಸಮಯಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಸಮಯ ಮತ್ತು ಮೌಲ್ಯಗಳ ಗುಂಪನ್ನು ರೂಪಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಸಂವೇದಕಗಳ ಸ್ಥಿತಿಯ ಆವರ್ತಕ ಮತದಾನದ ಮೂಲಕ ಅಥವಾ ಸಂಗ್ರಹಣೆಯ ಮೂಲಕ ಪಡೆಯಲಾಗುತ್ತದೆ ಮೆಟ್ರಿಕ್ಸ್).

ಈ ವರದಿಯ ವಿಡಿಯೋ ಲಿಂಕ್ ಇಲ್ಲಿದೆ - https://youtu.be/MZ5P21j_HLE

ಸ್ಲೈಡ್‌ಗಳು

ನಿನ್ನ ಬಗ್ಗೆ ನಮಗೆ ತಿಳಿಸು. ನಾನು ಅಲೆಕ್ಸಾಂಡರ್ ವಲ್ಯಾಲ್ಕಿನ್. ಇಲ್ಲಿ ನನ್ನ GitHub ಖಾತೆ. ನಾನು ಗೋ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆ ಆಪ್ಟಿಮೈಸೇಶನ್ ಬಗ್ಗೆ ಉತ್ಸುಕನಾಗಿದ್ದೇನೆ. ನಾನು ಬಹಳಷ್ಟು ಉಪಯುಕ್ತ ಮತ್ತು ಹೆಚ್ಚು ಉಪಯುಕ್ತವಲ್ಲದ ಗ್ರಂಥಾಲಯಗಳನ್ನು ಬರೆದಿದ್ದೇನೆ. ಅವರು ಒಂದರಿಂದ ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ fast, ಅಥವಾ ಜೊತೆ quick ಪೂರ್ವಪ್ರತ್ಯಯ.

ನಾನು ಪ್ರಸ್ತುತ ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇನೆ. ಅದು ಏನು ಮತ್ತು ನಾನು ಅಲ್ಲಿ ಏನು ಮಾಡುತ್ತಿದ್ದೇನೆ? ಈ ಪ್ರಸ್ತುತಿಯಲ್ಲಿ ನಾನು ಈ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇನೆ.

ವರದಿಯ ರೂಪುರೇಷೆ ಹೀಗಿದೆ:

• ಮೊದಲಿಗೆ, ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಎಂದರೇನು ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.
• ನಂತರ ಯಾವ ಸಮಯದ ಸರಣಿ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.
• ಸಮಯ ಸರಣಿಯ ಡೇಟಾಬೇಸ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.
• ಮುಂದೆ, ಡೇಟಾಬೇಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಬಗ್ಗೆ ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ: ಅದು ಏನು ಒಳಗೊಂಡಿದೆ.
• ತದನಂತರ ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಹೊಂದಿರುವ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳಿಗೆ ಹೋಗೋಣ. ಇದು ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕಕ್ಕೆ ಆಪ್ಟಿಮೈಸೇಶನ್ ಮತ್ತು Go ನಲ್ಲಿ ಬಿಟ್‌ಸೆಟ್ ಅನುಷ್ಠಾನಕ್ಕೆ ಆಪ್ಟಿಮೈಸೇಶನ್ ಆಗಿದೆ.

ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಎಂದರೇನು ಎಂದು ಪ್ರೇಕ್ಷಕರಲ್ಲಿ ಯಾರಿಗಾದರೂ ತಿಳಿದಿದೆಯೇ? ವಾಹ್, ಬಹಳಷ್ಟು ಜನರಿಗೆ ಈಗಾಗಲೇ ತಿಳಿದಿದೆ. ಇದೊಂದು ಒಳ್ಳೆಯ ಸುದ್ದಿ. ತಿಳಿದಿಲ್ಲದವರಿಗೆ, ಇದು ಸಮಯ ಸರಣಿಯ ಡೇಟಾಬೇಸ್ ಆಗಿದೆ. ಇದು ಕ್ಲಿಕ್‌ಹೌಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್, ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನುಷ್ಠಾನದ ಕೆಲವು ವಿವರಗಳನ್ನು ಆಧರಿಸಿದೆ. ಉದಾಹರಣೆಗೆ, ಉದಾಹರಣೆಗೆ: MergeTree, ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ ಪ್ರೊಸೆಸರ್ ಕೋರ್‌ಗಳಲ್ಲಿ ಸಮಾನಾಂತರ ಲೆಕ್ಕಾಚಾರ ಮತ್ತು ಪ್ರೊಸೆಸರ್ ಸಂಗ್ರಹದಲ್ಲಿ ಇರಿಸಲಾದ ಡೇಟಾ ಬ್ಲಾಕ್‌ಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಮೂಲಕ ಕಾರ್ಯಕ್ಷಮತೆಯ ಆಪ್ಟಿಮೈಸೇಶನ್.

ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಇತರ ಸಮಯ ಸರಣಿ ಡೇಟಾಬೇಸ್‌ಗಳಿಗಿಂತ ಉತ್ತಮ ಡೇಟಾ ಸಂಕುಚನವನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಇದು ಲಂಬವಾಗಿ ಅಳೆಯುತ್ತದೆ - ಅಂದರೆ, ನೀವು ಒಂದು ಕಂಪ್ಯೂಟರ್‌ನಲ್ಲಿ ಹೆಚ್ಚಿನ ಪ್ರೊಸೆಸರ್‌ಗಳು, ಹೆಚ್ಚಿನ RAM ಅನ್ನು ಸೇರಿಸಬಹುದು. VictoriaMetrics ಈ ಲಭ್ಯವಿರುವ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಬಳಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ರೇಖೀಯ ಉತ್ಪಾದಕತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ.

ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಸಹ ಅಡ್ಡಲಾಗಿ ಅಳೆಯುತ್ತದೆ - ಅಂದರೆ, ನೀವು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಹೆಚ್ಚುವರಿ ನೋಡ್‌ಗಳನ್ನು ಸೇರಿಸಬಹುದು ಮತ್ತು ಅದರ ಕಾರ್ಯಕ್ಷಮತೆ ಬಹುತೇಕ ರೇಖೀಯವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ.

ನೀವು ಊಹಿಸಿದಂತೆ, ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ವೇಗದ ಡೇಟಾಬೇಸ್ ಆಗಿದೆ, ಏಕೆಂದರೆ ನಾನು ಇತರರನ್ನು ಬರೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ಮತ್ತು ಇದನ್ನು Go ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ, ಆದ್ದರಿಂದ ನಾನು ಈ ಸಭೆಯಲ್ಲಿ ಅದರ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇನೆ.

ಸಮಯದ ಸರಣಿ ಏನು ಎಂದು ಯಾರಿಗೆ ತಿಳಿದಿದೆ? ಅವನಿಗೂ ಬಹಳ ಜನ ಗೊತ್ತು. ಸಮಯ ಸರಣಿಯು ಜೋಡಿಗಳ ಸರಣಿಯಾಗಿದೆ (timestamp, значение), ಅಲ್ಲಿ ಈ ಜೋಡಿಗಳನ್ನು ಸಮಯದಿಂದ ವಿಂಗಡಿಸಲಾಗುತ್ತದೆ. ಮೌಲ್ಯವು ಫ್ಲೋಟಿಂಗ್ ಪಾಯಿಂಟ್ ಸಂಖ್ಯೆ - float64.

ಪ್ರತಿ ಬಾರಿಯ ಸರಣಿಯನ್ನು ಒಂದು ಕೀಲಿಯಿಂದ ಅನನ್ಯವಾಗಿ ಗುರುತಿಸಲಾಗುತ್ತದೆ. ಈ ಕೀಲಿಯು ಏನು ಒಳಗೊಂಡಿದೆ? ಇದು ಕೀ-ಮೌಲ್ಯದ ಜೋಡಿಗಳ ಖಾಲಿ-ಅಲ್ಲದ ಗುಂಪನ್ನು ಒಳಗೊಂಡಿದೆ.

ಸಮಯ ಸರಣಿಯ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ. ಈ ಸರಣಿಯ ಕೀಲಿಯು ಜೋಡಿಗಳ ಪಟ್ಟಿಯಾಗಿದೆ: __name__="cpu_usage" ಮೆಟ್ರಿಕ್‌ನ ಹೆಸರು, instance="my-server" - ಇದು ಈ ಮೆಟ್ರಿಕ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಿದ ಕಂಪ್ಯೂಟರ್ ಆಗಿದೆ, datacenter="us-east" - ಇದು ಈ ಕಂಪ್ಯೂಟರ್ ಇರುವ ಡೇಟಾ ಸೆಂಟರ್ ಆಗಿದೆ.

ನಾವು ಮೂರು ಪ್ರಮುಖ-ಮೌಲ್ಯದ ಜೋಡಿಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಸಮಯ ಸರಣಿಯ ಹೆಸರಿನೊಂದಿಗೆ ಕೊನೆಗೊಂಡಿದ್ದೇವೆ. ಈ ಕೀಲಿಯು ಜೋಡಿಗಳ ಪಟ್ಟಿಗೆ ಅನುರೂಪವಾಗಿದೆ (timestamp, value). t1, t3, t3, ..., tN - ಇವು ಸಮಯಮುದ್ರೆಗಳು, 10, 20, 12, ..., 15 - ಅನುಗುಣವಾದ ಮೌಲ್ಯಗಳು. ಇದು ನಿರ್ದಿಷ್ಟ ಸರಣಿಗೆ ನಿರ್ದಿಷ್ಟ ಸಮಯದಲ್ಲಿ ಸಿಪಿಯು-ಬಳಕೆಯಾಗಿದೆ.

ಸಮಯದ ಸರಣಿಯನ್ನು ಎಲ್ಲಿ ಬಳಸಬಹುದು? ಯಾರಿಗಾದರೂ ಏನಾದರೂ ಕಲ್ಪನೆ ಇದೆಯೇ?

• DevOps ನಲ್ಲಿ, ನೀವು CPU, RAM, ನೆಟ್‌ವರ್ಕ್, rps, ದೋಷಗಳ ಸಂಖ್ಯೆ ಇತ್ಯಾದಿಗಳನ್ನು ಅಳೆಯಬಹುದು.
• IoT - ನಾವು ತಾಪಮಾನ, ಒತ್ತಡ, ಜಿಯೋ ನಿರ್ದೇಶಾಂಕಗಳು ಮತ್ತು ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ಅಳೆಯಬಹುದು.
• ಹಣಕಾಸು ಸಹ - ನಾವು ಎಲ್ಲಾ ರೀತಿಯ ಸ್ಟಾಕ್‌ಗಳು ಮತ್ತು ಕರೆನ್ಸಿಗಳ ಬೆಲೆಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು.
• ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕಾರ್ಖಾನೆಗಳಲ್ಲಿನ ಉತ್ಪಾದನಾ ಪ್ರಕ್ರಿಯೆಗಳ ಮೇಲ್ವಿಚಾರಣೆಯಲ್ಲಿ ಸಮಯದ ಸರಣಿಯನ್ನು ಬಳಸಬಹುದು. ರೋಬೋಟ್‌ಗಳಿಗಾಗಿ ವಿಂಡ್ ಟರ್ಬೈನ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಅನ್ನು ಬಳಸುವ ಬಳಕೆದಾರರನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ.
• ವಿವಿಧ ಸಾಧನಗಳ ಸಂವೇದಕಗಳಿಂದ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಮಯ ಸರಣಿಯು ಸಹ ಉಪಯುಕ್ತವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಎಂಜಿನ್ಗಾಗಿ; ಟೈರ್ ಒತ್ತಡವನ್ನು ಅಳೆಯಲು; ವೇಗ, ದೂರವನ್ನು ಅಳೆಯಲು; ಗ್ಯಾಸೋಲಿನ್ ಬಳಕೆಯನ್ನು ಅಳೆಯಲು, ಇತ್ಯಾದಿ.
• ವಿಮಾನವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಸಮಯ ಸರಣಿಯನ್ನು ಸಹ ಬಳಸಬಹುದು. ಪ್ರತಿಯೊಂದು ವಿಮಾನವು ಕಪ್ಪು ಪೆಟ್ಟಿಗೆಯನ್ನು ಹೊಂದಿದ್ದು ಅದು ವಿಮಾನದ ಆರೋಗ್ಯದ ವಿವಿಧ ನಿಯತಾಂಕಗಳಿಗಾಗಿ ಸಮಯದ ಸರಣಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಏರೋಸ್ಪೇಸ್ ಉದ್ಯಮದಲ್ಲಿ ಸಮಯದ ಸರಣಿಯನ್ನು ಸಹ ಬಳಸಲಾಗುತ್ತದೆ.
• ಆರೋಗ್ಯ ರಕ್ಷಣೆ ಎಂದರೆ ರಕ್ತದೊತ್ತಡ, ನಾಡಿಮಿಡಿತ ಇತ್ಯಾದಿ.

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

ನಿಮಗೆ ಸಮಯ ಸರಣಿ ಡೇಟಾಬೇಸ್ ಏಕೆ ಬೇಕು? ಸಮಯ ಸರಣಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ನೀವು ಸಾಮಾನ್ಯ ಸಂಬಂಧಿತ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಏಕೆ ಬಳಸಬಾರದು?

ಏಕೆಂದರೆ ಸಮಯ ಸರಣಿಯು ಸಾಮಾನ್ಯವಾಗಿ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಮಾಹಿತಿಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಇದು ಸಾಂಪ್ರದಾಯಿಕ ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ. ಆದ್ದರಿಂದ, ಸಮಯ ಸರಣಿಗಾಗಿ ವಿಶೇಷ ಡೇಟಾಬೇಸ್ಗಳು ಕಾಣಿಸಿಕೊಂಡವು. ಈ ನೆಲೆಗಳು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಅಂಕಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತವೆ (timestamp, value) ನೀಡಿದ ಕೀಲಿಯೊಂದಿಗೆ. ಕೀ ಮೂಲಕ, ಒಂದೇ ಕೀ-ಮೌಲ್ಯದ ಜೋಡಿ, ಅಥವಾ ಬಹು ಕೀ-ಮೌಲ್ಯ ಜೋಡಿಗಳು ಅಥವಾ regexp ಮೂಲಕ ಸಂಗ್ರಹಿಸಲಾದ ಡೇಟಾವನ್ನು ಓದಲು ಅವರು API ಅನ್ನು ಒದಗಿಸುತ್ತಾರೆ. ಉದಾಹರಣೆಗೆ, ಅಮೆರಿಕಾದಲ್ಲಿನ ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ ನಿಮ್ಮ ಎಲ್ಲಾ ಸೇವೆಗಳ CPU ಲೋಡ್ ಅನ್ನು ಕಂಡುಹಿಡಿಯಲು ನೀವು ಬಯಸುತ್ತೀರಿ, ನಂತರ ನೀವು ಈ ಹುಸಿ ಪ್ರಶ್ನೆಯನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ.

ವಿಶಿಷ್ಟವಾಗಿ ಸಮಯ ಸರಣಿಯ ಡೇಟಾಬೇಸ್‌ಗಳು ವಿಶೇಷ ಪ್ರಶ್ನೆ ಭಾಷೆಗಳನ್ನು ಒದಗಿಸುತ್ತವೆ ಏಕೆಂದರೆ ಸಮಯ ಸರಣಿ SQL ಹೆಚ್ಚು ಸೂಕ್ತವಲ್ಲ. SQL ಅನ್ನು ಬೆಂಬಲಿಸುವ ಡೇಟಾಬೇಸ್‌ಗಳಿದ್ದರೂ, ಇದು ತುಂಬಾ ಸೂಕ್ತವಲ್ಲ. ಮುಂತಾದ ಭಾಷೆಗಳನ್ನು ಪ್ರಶ್ನಿಸಿ PromQL, InfluxQL, ಹರಿಯುವಂತೆ, Q. ಯಾರಾದರೂ ಈ ಭಾಷೆಗಳಲ್ಲಿ ಒಂದನ್ನಾದರೂ ಕೇಳಿದ್ದಾರೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. PromQL ಬಗ್ಗೆ ಅನೇಕ ಜನರು ಬಹುಶಃ ಕೇಳಿರಬಹುದು. ಇದು ಪ್ರಮೀತಿಯಸ್ ಪ್ರಶ್ನೆ ಭಾಷೆ.

ಆಧುನಿಕ ಸಮಯದ ಸರಣಿಯ ಡೇಟಾಬೇಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಅನ್ನು ಉದಾಹರಣೆಯಾಗಿ ಬಳಸುತ್ತಿರುವಂತೆ ಕಾಣುತ್ತದೆ.

ಇದು ಎರಡು ಭಾಗಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಇದು ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕ ಮತ್ತು ಸಮಯ ಸರಣಿ ಮೌಲ್ಯಗಳಿಗಾಗಿ ಸಂಗ್ರಹಣೆಯಾಗಿದೆ. ಈ ರೆಪೊಸಿಟರಿಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲಾಗಿದೆ.

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

TSDB ಯಿಂದ ಡೇಟಾವನ್ನು ಹಿಂಪಡೆಯಲು ವಿನಂತಿಯು ಬಂದಾಗ, ನಾವು ಮೊದಲು ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕಕ್ಕೆ ಹೋಗುತ್ತೇವೆ. ಎಲ್ಲವನ್ನೂ ಪಡೆಯೋಣ timeseries_ids ಈ ಸೆಟ್‌ಗೆ ಹೊಂದಿಕೆಯಾಗುವ ದಾಖಲೆಗಳು label=value. ಮತ್ತು ನಂತರ ನಾವು ಡೇಟಾ ವೇರ್ಹೌಸ್ನಿಂದ ಎಲ್ಲಾ ಅಗತ್ಯ ಡೇಟಾವನ್ನು ಪಡೆಯುತ್ತೇವೆ, ಸೂಚ್ಯಂಕದಿಂದ timeseries_ids.

ಒಳಬರುವ ಆಯ್ದ ಪ್ರಶ್ನೆಯನ್ನು ಸಮಯ ಸರಣಿಯ ಡೇಟಾಬೇಸ್ ಹೇಗೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಎಂಬುದರ ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ.

• ಮೊದಲನೆಯದಾಗಿ, ಅವಳು ಎಲ್ಲವನ್ನೂ ಪಡೆಯುತ್ತಾಳೆ timeseries_ids ನೀಡಿರುವ ಜೋಡಿಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕದಿಂದ label=value, ಅಥವಾ ನೀಡಿರುವ ನಿಯಮಿತ ಅಭಿವ್ಯಕ್ತಿಯನ್ನು ಪೂರೈಸಿ.
• ನಂತರ ಅದು ಎಲ್ಲಾ ಡೇಟಾ ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಡೇಟಾ ಸಂಗ್ರಹಣೆಯಿಂದ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಮಯದ ಮಧ್ಯಂತರದಲ್ಲಿ ಪತ್ತೆಯಾದವುಗಳಿಗೆ ಹಿಂಪಡೆಯುತ್ತದೆ timeseries_ids.
• ಇದರ ನಂತರ, ಬಳಕೆದಾರರ ಕೋರಿಕೆಯ ಪ್ರಕಾರ ಡೇಟಾಬೇಸ್ ಈ ಡೇಟಾ ಬಿಂದುಗಳಲ್ಲಿ ಕೆಲವು ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಮತ್ತು ಅದರ ನಂತರ ಅದು ಉತ್ತರವನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ.

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

ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕಕ್ಕೆ ಹೋಗೋಣ. ಇದು ಸರಳ ಎಂದು ಹಲವರು ಭಾವಿಸಬಹುದು. ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕ ಎಂದರೇನು ಮತ್ತು ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಯಾರಿಗೆ ತಿಳಿದಿದೆ? ಓಹ್, ಇನ್ನು ಹೆಚ್ಚು ಜನರಿಲ್ಲ. ಅದು ಏನೆಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸೋಣ.

ಇದು ವಾಸ್ತವವಾಗಿ ಸರಳವಾಗಿದೆ. ಇದು ಕೇವಲ ಒಂದು ಮೌಲ್ಯಕ್ಕೆ ಕೀಲಿಯನ್ನು ನಕ್ಷೆ ಮಾಡುವ ನಿಘಂಟು. ಕೀ ಎಂದರೇನು? ಈ ದಂಪತಿಗಳು label=valueಅಲ್ಲಿ label и value - ಇವು ಸಾಲುಗಳು. ಮತ್ತು ಮೌಲ್ಯಗಳು ಒಂದು ಸೆಟ್ timeseries_ids, ನೀಡಿರುವ ಜೋಡಿಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ label=value.

ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕವು ಎಲ್ಲವನ್ನೂ ತ್ವರಿತವಾಗಿ ಕಂಡುಹಿಡಿಯಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ timeseries_ids, ಕೊಟ್ಟಿದ್ದಾರೆ label=value.

ಇದು ತ್ವರಿತವಾಗಿ ಹುಡುಕಲು ಸಹ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ timeseries_ids ಹಲವಾರು ಜೋಡಿಗಳಿಗೆ ಸಮಯ ಸರಣಿ label=value, ಅಥವಾ ದಂಪತಿಗಳಿಗೆ label=regexp. ಇದು ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ? ಸೆಟ್ನ ಛೇದಕವನ್ನು ಕಂಡುಹಿಡಿಯುವ ಮೂಲಕ timeseries_ids ಪ್ರತಿ ಜೋಡಿಗೆ label=value.

ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕದ ವಿವಿಧ ಅನುಷ್ಠಾನಗಳನ್ನು ನೋಡೋಣ. ಸರಳವಾದ ನಿಷ್ಕಪಟ ಅನುಷ್ಠಾನದೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ. ಅವಳು ಈ ರೀತಿ ಕಾಣುತ್ತಾಳೆ.

ಕಾರ್ಯ getMetricIDs ತಂತಿಗಳ ಪಟ್ಟಿಯನ್ನು ಪಡೆಯುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಸಾಲು ಒಳಗೊಂಡಿದೆ label=value. ಈ ಕಾರ್ಯವು ಪಟ್ಟಿಯನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ metricIDs.

ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ? ಇಲ್ಲಿ ನಾವು ಎಂಬ ಜಾಗತಿಕ ವೇರಿಯಬಲ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ invertedIndex. ಇದು ಸಾಮಾನ್ಯ ನಿಘಂಟು (map), ಇದು ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಇಂಟ್ಸ್ ಸ್ಲೈಸ್ ಮಾಡಲು ಮ್ಯಾಪ್ ಮಾಡುತ್ತದೆ. ಸಾಲು ಒಳಗೊಂಡಿದೆ label=value.

ಕಾರ್ಯ ಅನುಷ್ಠಾನ: ಪಡೆಯಿರಿ metricIDs ಮೊದಲನೆಯದು label=value, ನಂತರ ನಾವು ಎಲ್ಲದರ ಮೂಲಕ ಹೋಗುತ್ತೇವೆ label=value, ನಾವು ಅದನ್ನು ಪಡೆಯುತ್ತೇವೆ metricIDs ಅವರಿಗೆ. ಮತ್ತು ಕಾರ್ಯವನ್ನು ಕರೆ ಮಾಡಿ intersectInts, ಇದನ್ನು ಕೆಳಗೆ ಚರ್ಚಿಸಲಾಗುವುದು. ಮತ್ತು ಈ ಕಾರ್ಯವು ಈ ಪಟ್ಟಿಗಳ ಛೇದಕವನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ.

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

ಎರಡನೆಯ ನ್ಯೂನತೆಯು ಮೆಮೊರಿಗೆ ಸಂಬಂಧಿಸಿದೆ. ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕವು RAM ಗೆ ಹೊಂದಿಕೊಳ್ಳಬೇಕು. ಇದು RAM ನ ಗಾತ್ರವನ್ನು ಮೀರಿದರೆ, ನಿಸ್ಸಂಶಯವಾಗಿ ನಾವು ಪಡೆಯುತ್ತೇವೆ - ಮೆಮೊರಿ ದೋಷದಿಂದ. ಮತ್ತು ಪ್ರೋಗ್ರಾಂ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.

ಮುಂತಾದ ಸಿದ್ಧ ಪರಿಹಾರಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಬಹುದು ಲೆವೆಲ್ ಡಿಬಿ, ಅಥವಾ ರಾಕ್ಸ್ ಡಿಬಿ.

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

• ಮೊದಲ ಕಾರ್ಯಾಚರಣೆಯು ರೆಕಾರ್ಡಿಂಗ್ ಆಗಿದೆ ключ-значение ಈ ಡೇಟಾಬೇಸ್‌ಗೆ. ಅವಳು ಇದನ್ನು ಬೇಗನೆ ಮಾಡುತ್ತಾಳೆ, ಅಲ್ಲಿ ключ-значение ಅನಿಯಂತ್ರಿತ ತಂತಿಗಳಾಗಿವೆ.
• ಎರಡನೇ ಕಾರ್ಯಾಚರಣೆಯು ನಿರ್ದಿಷ್ಟ ಕೀಲಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಮೌಲ್ಯಕ್ಕಾಗಿ ತ್ವರಿತ ಹುಡುಕಾಟವಾಗಿದೆ.
• ಮತ್ತು ಮೂರನೇ ಕಾರ್ಯಾಚರಣೆಯು ನಿರ್ದಿಷ್ಟ ಪೂರ್ವಪ್ರತ್ಯಯದಿಂದ ಎಲ್ಲಾ ಮೌಲ್ಯಗಳಿಗೆ ತ್ವರಿತ ಹುಡುಕಾಟವಾಗಿದೆ.

LevelDB ಮತ್ತು RocksDB - ಈ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಗೂಗಲ್ ಮತ್ತು ಫೇಸ್‌ಬುಕ್ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದೆ. ಮೊದಲು LevelDB ಬಂದಿತು. ನಂತರ ಫೇಸ್‌ಬುಕ್‌ನ ವ್ಯಕ್ತಿಗಳು ಲೆವೆಲ್‌ಡಿಬಿಯನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಸುಧಾರಿಸಲು ಪ್ರಾರಂಭಿಸಿದರು, ಅವರು ರಾಕ್ಸ್‌ಡಿಬಿ ಮಾಡಿದರು. ಈಗ ಬಹುತೇಕ ಎಲ್ಲಾ ಆಂತರಿಕ ಡೇಟಾಬೇಸ್‌ಗಳು RocksDB ಮತ್ತು MySQL ಗೆ ವರ್ಗಾಯಿಸಲ್ಪಟ್ಟವುಗಳನ್ನು ಒಳಗೊಂಡಂತೆ Facebook ಒಳಗೆ RocksDB ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಅವರು ಅವನಿಗೆ ಹೆಸರಿಟ್ಟರು ಮೈರಾಕ್ಸ್.

ಲೆವೆಲ್‌ಡಿಬಿ ಬಳಸಿ ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ಅದನ್ನು ಹೇಗೆ ಮಾಡುವುದು? ನಾವು ಕೀಲಿಯಾಗಿ ಉಳಿಸುತ್ತೇವೆ label=value. ಮತ್ತು ಮೌಲ್ಯವು ಜೋಡಿ ಇರುವ ಸಮಯ ಸರಣಿಯ ಗುರುತಿಸುವಿಕೆಯಾಗಿದೆ label=value.

ಕೊಟ್ಟಿರುವ ಜೋಡಿಯೊಂದಿಗೆ ನಾವು ಅನೇಕ ಸಮಯದ ಸರಣಿಯನ್ನು ಹೊಂದಿದ್ದರೆ label=value, ನಂತರ ಈ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಒಂದೇ ಕೀಲಿಯೊಂದಿಗೆ ಮತ್ತು ವಿಭಿನ್ನವಾಗಿರುವ ಹಲವು ಸಾಲುಗಳು ಇರುತ್ತವೆ timeseries_ids. ಎಲ್ಲದರ ಪಟ್ಟಿಯನ್ನು ಪಡೆಯಲು timeseries_ids, ಇದರೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ label=prefix, ಈ ಡೇಟಾಬೇಸ್ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲಾದ ಶ್ರೇಣಿಯ ಸ್ಕ್ಯಾನ್ ಅನ್ನು ನಾವು ಮಾಡುತ್ತೇವೆ. ಅಂದರೆ, ನಾವು ಪ್ರಾರಂಭವಾಗುವ ಎಲ್ಲಾ ಸಾಲುಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ label=prefix ಮತ್ತು ಅಗತ್ಯವನ್ನು ಪಡೆಯಿರಿ timeseries_ids.

Go ನಲ್ಲಿ ಅದು ಹೇಗಿರುತ್ತದೆ ಎಂಬುದರ ಮಾದರಿ ಅನುಷ್ಠಾನ ಇಲ್ಲಿದೆ. ನಾವು ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಇದು LevelDB ಆಗಿದೆ.

ಕಾರ್ಯವು ನಿಷ್ಕಪಟ ಅನುಷ್ಠಾನದಂತೆಯೇ ಇರುತ್ತದೆ. ಇದು ನಿಷ್ಕಪಟ ಅನುಷ್ಠಾನವನ್ನು ಬಹುತೇಕ ಸಾಲಿನ ಮೂಲಕ ಪುನರಾವರ್ತಿಸುತ್ತದೆ. ಒಂದೇ ಅಂಶವೆಂದರೆ ತಿರುಗುವ ಬದಲು map ನಾವು ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕವನ್ನು ಪ್ರವೇಶಿಸುತ್ತೇವೆ. ನಾವು ಮೊದಲನೆಯದಕ್ಕೆ ಎಲ್ಲಾ ಮೌಲ್ಯಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ label=value. ನಂತರ ನಾವು ಉಳಿದ ಎಲ್ಲಾ ಜೋಡಿಗಳ ಮೂಲಕ ಹೋಗುತ್ತೇವೆ label=value ಮತ್ತು ಅವುಗಳಿಗೆ ಅನುಗುಣವಾದ ಮೆಟ್ರಿಕ್‌ಐಡಿ ಸೆಟ್‌ಗಳನ್ನು ಪಡೆಯಿರಿ. ನಂತರ ನಾವು ಛೇದಕವನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ.

ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಈ ಪರಿಹಾರಕ್ಕೆ ನ್ಯೂನತೆಗಳಿವೆ. VictoriaMetrics ಆರಂಭದಲ್ಲಿ LevelDB ಆಧಾರದ ಮೇಲೆ ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕವನ್ನು ಜಾರಿಗೆ ತಂದಿತು. ಆದರೆ ಕೊನೆಯಲ್ಲಿ ನಾನು ಅದನ್ನು ಬಿಟ್ಟುಕೊಡಬೇಕಾಯಿತು.

ಏಕೆ? ಏಕೆಂದರೆ LevelDB ನಿಷ್ಕಪಟ ಅನುಷ್ಠಾನಕ್ಕಿಂತ ನಿಧಾನವಾಗಿರುತ್ತದೆ. ನಿಷ್ಕಪಟವಾದ ಅನುಷ್ಠಾನದಲ್ಲಿ, ಕೊಟ್ಟಿರುವ ಕೀಲಿಯನ್ನು ನೀಡಿದರೆ, ನಾವು ತಕ್ಷಣವೇ ಸಂಪೂರ್ಣ ಸ್ಲೈಸ್ ಅನ್ನು ಹಿಂಪಡೆಯುತ್ತೇವೆ metricIDs. ಇದು ಅತ್ಯಂತ ವೇಗದ ಕಾರ್ಯಾಚರಣೆಯಾಗಿದೆ - ಸಂಪೂರ್ಣ ಸ್ಲೈಸ್ ಬಳಕೆಗೆ ಸಿದ್ಧವಾಗಿದೆ.

LevelDB ನಲ್ಲಿ, ಪ್ರತಿ ಬಾರಿ ಒಂದು ಕಾರ್ಯವನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ GetValues ನೀವು ಪ್ರಾರಂಭವಾಗುವ ಎಲ್ಲಾ ಸಾಲುಗಳ ಮೂಲಕ ಹೋಗಬೇಕಾಗುತ್ತದೆ label=value. ಮತ್ತು ಪ್ರತಿ ಸಾಲಿಗೆ ಮೌಲ್ಯವನ್ನು ಪಡೆಯಿರಿ timeseries_ids. ಅಂತಹವುಗಳಲ್ಲಿ timeseries_ids ಇವುಗಳ ಸ್ಲೈಸ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಿ timeseries_ids. ನಿಸ್ಸಂಶಯವಾಗಿ, ಕೀಲಿಯಿಂದ ಸಾಮಾನ್ಯ ನಕ್ಷೆಯನ್ನು ಪ್ರವೇಶಿಸುವುದಕ್ಕಿಂತ ಇದು ತುಂಬಾ ನಿಧಾನವಾಗಿರುತ್ತದೆ.

ಎರಡನೆಯ ನ್ಯೂನತೆಯೆಂದರೆ LevelDB ಅನ್ನು C ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ. Go ನಿಂದ C ಕಾರ್ಯಗಳನ್ನು ಕರೆಯುವುದು ತುಂಬಾ ವೇಗವಲ್ಲ. ಇದು ನೂರಾರು ನ್ಯಾನೊಸೆಕೆಂಡ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಇದು ತುಂಬಾ ವೇಗವಾಗಿಲ್ಲ, ಏಕೆಂದರೆ 1-5 ನ್ಯಾನೋಸೆಕೆಂಡ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಗೋದಲ್ಲಿ ಬರೆಯಲಾದ ಸಾಮಾನ್ಯ ಕಾರ್ಯದ ಕರೆಗೆ ಹೋಲಿಸಿದರೆ, ಕಾರ್ಯಕ್ಷಮತೆಯ ವ್ಯತ್ಯಾಸವು ಹತ್ತಾರು ಬಾರಿ ಇರುತ್ತದೆ. ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್‌ಗೆ ಇದು ಮಾರಣಾಂತಿಕ ನ್ಯೂನತೆಯಾಗಿದೆ :)

ಹಾಗಾಗಿ ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕದ ನನ್ನ ಸ್ವಂತ ಅನುಷ್ಠಾನವನ್ನು ನಾನು ಬರೆದಿದ್ದೇನೆ. ಮತ್ತು ಅವನು ಅವಳನ್ನು ಕರೆದನು ವಿಲೀನಗೊಳಿಸು.

Mergeset MergeTree ಡೇಟಾ ರಚನೆಯನ್ನು ಆಧರಿಸಿದೆ. ಈ ಡೇಟಾ ರಚನೆಯನ್ನು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಿಂದ ಎರವಲು ಪಡೆಯಲಾಗಿದೆ. ನಿಸ್ಸಂಶಯವಾಗಿ, ವೇಗದ ಹುಡುಕಾಟಕ್ಕಾಗಿ ವಿಲೀನಗೊಳಿಸುವಿಕೆಯನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಬೇಕು timeseries_ids ನೀಡಿರುವ ಕೀಲಿ ಪ್ರಕಾರ. ಮರ್ಜೆಸೆಟ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ Go ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ. ನೀವು ನೋಡಬಹುದು GitHub ನಲ್ಲಿ VictoriaMetrics ಮೂಲಗಳು. ವಿಲೀನಗೊಳಿಸುವಿಕೆಯ ಅನುಷ್ಠಾನವು ಫೋಲ್ಡರ್‌ನಲ್ಲಿದೆ /lib/mergeset. ಅಲ್ಲಿ ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ನೀವು ಪ್ರಯತ್ನಿಸಬಹುದು.

ವಿಲೀನ API LevelDB ಮತ್ತು RocksDB ಗೆ ಹೋಲುತ್ತದೆ. ಅಂದರೆ, ಅಲ್ಲಿ ಹೊಸ ದಾಖಲೆಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಉಳಿಸಲು ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಪೂರ್ವಪ್ರತ್ಯಯದಿಂದ ದಾಖಲೆಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಆಯ್ಕೆ ಮಾಡಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ.

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

ಅವರು ಏಕೆ ಹುಟ್ಟಿಕೊಂಡರು?

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

ಎರಡನೆಯ ಕಾರಣವೆಂದರೆ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಮಯ ಸರಣಿ. ಆರಂಭದಲ್ಲಿ, ಮಾನಿಟರಿಂಗ್ ಜನಪ್ರಿಯತೆ ಗಳಿಸುತ್ತಿದ್ದಾಗ, ಸಮಯದ ಸರಣಿಗಳ ಸಂಖ್ಯೆಯು ಚಿಕ್ಕದಾಗಿತ್ತು. ಉದಾಹರಣೆಗೆ, ಪ್ರತಿ ಕಂಪ್ಯೂಟರ್ಗೆ ನೀವು CPU, ಮೆಮೊರಿ, ನೆಟ್ವರ್ಕ್ ಮತ್ತು ಡಿಸ್ಕ್ ಲೋಡ್ ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಪ್ರತಿ ಕಂಪ್ಯೂಟರ್‌ಗೆ 4 ಸಮಯದ ಸರಣಿ. ನೀವು 100 ಕಂಪ್ಯೂಟರ್‌ಗಳು ಮತ್ತು 400 ಸಮಯದ ಸರಣಿಯನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ಹೇಳೋಣ. ಇದು ಬಹಳ ಕಡಿಮೆ.

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

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

ಒಂದು ಮೆಟ್ರಿಕ್‌ನಿಂದ ನಾವು ಕೇವಲ ಒಂದು ಕಂಪ್ಯೂಟರ್‌ಗೆ 40 x 8 = 320 ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ. 100 ರಿಂದ ಗುಣಿಸಿದಾಗ, ನಾವು 32 ರ ಬದಲಿಗೆ 000 ಪಡೆಯುತ್ತೇವೆ.

ನಂತರ ಕುಬರ್ನೆಟ್ಸ್ ಬಂದರು. ಮತ್ತು ಇದು ಕೆಟ್ಟದಾಗಿದೆ ಏಕೆಂದರೆ ಕುಬರ್ನೆಟ್ಸ್ ವಿವಿಧ ಸೇವೆಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡಬಹುದು. ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಸೇವೆಯು ಅನೇಕ ಪಾಡ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಮತ್ತು ಈ ಎಲ್ಲಾ ಮೇಲ್ವಿಚಾರಣೆ ಅಗತ್ಯವಿದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಿಮ್ಮ ಸೇವೆಗಳ ಹೊಸ ಆವೃತ್ತಿಗಳ ನಿರಂತರ ನಿಯೋಜನೆಯನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ. ಪ್ರತಿ ಹೊಸ ಆವೃತ್ತಿಗೆ, ಹೊಸ ಸಮಯದ ಸರಣಿಯನ್ನು ರಚಿಸಬೇಕು. ಪರಿಣಾಮವಾಗಿ, ಸಮಯ ಸರಣಿಯ ಸಂಖ್ಯೆಯು ಘಾತೀಯವಾಗಿ ಬೆಳೆಯುತ್ತದೆ ಮತ್ತು ನಾವು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಮಯ ಸರಣಿಯ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸುತ್ತೇವೆ, ಇದನ್ನು ಹೈ-ಕಾರ್ಡಿನಾಲಿಟಿ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಇತರ ಸಮಯ ಸರಣಿ ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಹೋಲಿಸಿದರೆ ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಅದನ್ನು ಯಶಸ್ವಿಯಾಗಿ ನಿಭಾಯಿಸುತ್ತದೆ.

ಹೆಚ್ಚಿನ ಮಂಥನ ದರವನ್ನು ಹತ್ತಿರದಿಂದ ನೋಡೋಣ. ಉತ್ಪಾದನೆಯಲ್ಲಿ ಹೆಚ್ಚಿನ ಮಂದಗತಿಗೆ ಕಾರಣವೇನು? ಏಕೆಂದರೆ ಲೇಬಲ್‌ಗಳು ಮತ್ತು ಟ್ಯಾಗ್‌ಗಳ ಕೆಲವು ಅರ್ಥಗಳು ನಿರಂತರವಾಗಿ ಬದಲಾಗುತ್ತಿರುತ್ತವೆ.

ಉದಾಹರಣೆಗೆ, ಪರಿಕಲ್ಪನೆಯನ್ನು ಹೊಂದಿರುವ ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ deployment, ಅಂದರೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಹೊರತಂದಾಗ. ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ, ಕುಬರ್ನೆಟ್ಸ್ ಡೆವಲಪರ್‌ಗಳು ಲೇಬಲ್‌ಗೆ ನಿಯೋಜನೆ ಐಡಿಯನ್ನು ಸೇರಿಸಲು ನಿರ್ಧರಿಸಿದ್ದಾರೆ.

ಇದು ಯಾವುದಕ್ಕೆ ಕಾರಣವಾಯಿತು? ಇದಲ್ಲದೆ, ಪ್ರತಿ ಹೊಸ ನಿಯೋಜನೆಯೊಂದಿಗೆ, ಎಲ್ಲಾ ಹಳೆಯ ಸಮಯದ ಸರಣಿಗಳು ಅಡಚಣೆಯಾಗುತ್ತವೆ ಮತ್ತು ಅವುಗಳ ಬದಲಿಗೆ, ಹೊಸ ಸಮಯ ಸರಣಿಯು ಹೊಸ ಲೇಬಲ್ ಮೌಲ್ಯದೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ deployment_id. ಅಂತಹ ಸಾಲುಗಳು ನೂರಾರು ಸಾವಿರ ಮತ್ತು ಲಕ್ಷಾಂತರ ಇರಬಹುದು.

ಈ ಎಲ್ಲದರ ಬಗ್ಗೆ ಮುಖ್ಯವಾದ ವಿಷಯವೆಂದರೆ ಒಟ್ಟು ಸಮಯ ಸರಣಿಯ ಸಂಖ್ಯೆಯು ಬೆಳೆಯುತ್ತದೆ, ಆದರೆ ಪ್ರಸ್ತುತ ಸಕ್ರಿಯವಾಗಿರುವ ಮತ್ತು ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುವ ಸಮಯ ಸರಣಿಯ ಸಂಖ್ಯೆಯು ಸ್ಥಿರವಾಗಿರುತ್ತದೆ. ಈ ಸ್ಥಿತಿಯನ್ನು ಹೆಚ್ಚಿನ ಮಂಥನ ದರ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.

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

ಈ ಸಮಸ್ಯೆಯನ್ನು ಹೇಗೆ ಪರಿಹರಿಸುವುದು? ಮೊದಲ ಆಯ್ಕೆ ಇಲ್ಲಿದೆ. ಇದು ತಲೆಕೆಳಗಾದ ಸೂಚಿಯನ್ನು ಕಾಲಾನಂತರದಲ್ಲಿ ಸ್ವತಂತ್ರ ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸುವುದು. ಅಂದರೆ, ಕೆಲವು ಸಮಯದ ಮಧ್ಯಂತರವು ಹಾದುಹೋಗುತ್ತದೆ, ನಾವು ಪ್ರಸ್ತುತ ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕದೊಂದಿಗೆ ಕೆಲಸವನ್ನು ಮುಗಿಸುತ್ತೇವೆ. ಮತ್ತು ಹೊಸ ತಲೆಕೆಳಗಾದ ಸೂಚಿಯನ್ನು ರಚಿಸಿ. ಮತ್ತೊಂದು ಸಮಯದ ಮಧ್ಯಂತರವು ಹಾದುಹೋಗುತ್ತದೆ, ನಾವು ಇನ್ನೊಂದನ್ನು ಮತ್ತು ಇನ್ನೊಂದನ್ನು ರಚಿಸುತ್ತೇವೆ.

ಮತ್ತು ಈ ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕಗಳಿಂದ ಮಾದರಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುವಾಗ, ನಿರ್ದಿಷ್ಟ ಮಧ್ಯಂತರದಲ್ಲಿ ಬರುವ ವಿಲೋಮ ಸೂಚ್ಯಂಕಗಳ ಗುಂಪನ್ನು ನಾವು ಕಾಣುತ್ತೇವೆ. ಮತ್ತು, ಅದರ ಪ್ರಕಾರ, ನಾವು ಅಲ್ಲಿಂದ ಸಮಯ ಸರಣಿಯ ಐಡಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ.

ಇದು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಉಳಿಸುತ್ತದೆ ಏಕೆಂದರೆ ನಾವು ನೀಡಿದ ಮಧ್ಯಂತರದಲ್ಲಿ ಬರದ ಭಾಗಗಳನ್ನು ನೋಡಬೇಕಾಗಿಲ್ಲ. ಅಂದರೆ, ಸಾಮಾನ್ಯವಾಗಿ, ನಾವು ಕೊನೆಯ ಗಂಟೆಗೆ ಡೇಟಾವನ್ನು ಆರಿಸಿದರೆ, ಹಿಂದಿನ ಸಮಯದ ಮಧ್ಯಂತರಗಳಿಗೆ ನಾವು ವಿನಂತಿಗಳನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತೇವೆ.

ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಮತ್ತೊಂದು ಆಯ್ಕೆ ಇದೆ. ಇದು ಆ ದಿನ ಸಂಭವಿಸಿದ ಸಮಯ ಸರಣಿಯ ಐಡಿಗಳ ಪ್ರತ್ಯೇಕ ಪಟ್ಟಿಯನ್ನು ಪ್ರತಿ ದಿನ ಸಂಗ್ರಹಿಸುವುದು.

ಹಿಂದಿನ ಪರಿಹಾರಕ್ಕಿಂತ ಈ ಪರಿಹಾರದ ಪ್ರಯೋಜನವೆಂದರೆ ನಾವು ಸಮಯ ಸರಣಿಯ ಮಾಹಿತಿಯನ್ನು ನಕಲು ಮಾಡುವುದಿಲ್ಲ, ಅದು ಕಾಲಾನಂತರದಲ್ಲಿ ಕಣ್ಮರೆಯಾಗುವುದಿಲ್ಲ. ಅವು ನಿರಂತರವಾಗಿ ಇರುತ್ತವೆ ಮತ್ತು ಬದಲಾಗುವುದಿಲ್ಲ.

ಅನನುಕೂಲವೆಂದರೆ ಅಂತಹ ಪರಿಹಾರವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಹೆಚ್ಚು ಕಷ್ಟ ಮತ್ತು ಡೀಬಗ್ ಮಾಡಲು ಹೆಚ್ಚು ಕಷ್ಟ. ಮತ್ತು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಈ ಪರಿಹಾರವನ್ನು ಆಯ್ಕೆ ಮಾಡಿದೆ. ಇದು ಐತಿಹಾಸಿಕವಾಗಿ ನಡೆದದ್ದು ಹೀಗೆ. ಹಿಂದಿನದಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಈ ಪರಿಹಾರವು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಏಕೆಂದರೆ ಈ ಪರಿಹಾರವು ಬದಲಾಗದ ಸಮಯ ಸರಣಿಗಾಗಿ ಪ್ರತಿ ವಿಭಾಗದಲ್ಲಿ ಡೇಟಾವನ್ನು ನಕಲು ಮಾಡುವುದು ಅವಶ್ಯಕ ಎಂಬ ಅಂಶದಿಂದಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿಲ್ಲ, ಅಂದರೆ ಅದು ಕಾಲಾನಂತರದಲ್ಲಿ ಕಣ್ಮರೆಯಾಗುವುದಿಲ್ಲ. ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಅನ್ನು ಪ್ರಾಥಮಿಕವಾಗಿ ಡಿಸ್ಕ್ ಸ್ಪೇಸ್ ಬಳಕೆಗೆ ಹೊಂದುವಂತೆ ಮಾಡಲಾಗಿತ್ತು ಮತ್ತು ಹಿಂದಿನ ಅಳವಡಿಕೆಯು ಡಿಸ್ಕ್ ಸ್ಪೇಸ್ ಬಳಕೆಯನ್ನು ಇನ್ನಷ್ಟು ಹದಗೆಡಿಸಿತು. ಆದರೆ ಡಿಸ್ಕ್ ಜಾಗದ ಬಳಕೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಈ ಅನುಷ್ಠಾನವು ಹೆಚ್ಚು ಸೂಕ್ತವಾಗಿದೆ, ಆದ್ದರಿಂದ ಇದನ್ನು ಆಯ್ಕೆ ಮಾಡಲಾಗಿದೆ.

ನಾನು ಅವಳೊಂದಿಗೆ ಹೋರಾಡಬೇಕಾಗಿತ್ತು. ಹೋರಾಟವು ಈ ಅನುಷ್ಠಾನದಲ್ಲಿ ನೀವು ಇನ್ನೂ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯನ್ನು ಆರಿಸಬೇಕಾಗುತ್ತದೆ timeseries_ids ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕವು ಸಮಯವನ್ನು ವಿಭಜಿಸಿದಾಗ ಡೇಟಾಕ್ಕಾಗಿ.

ನಾವು ಈ ಸಮಸ್ಯೆಯನ್ನು ಹೇಗೆ ಪರಿಹರಿಸಿದ್ದೇವೆ? ನಾವು ಅದನ್ನು ಮೂಲ ರೀತಿಯಲ್ಲಿ ಪರಿಹರಿಸಿದ್ದೇವೆ - ಒಂದು ಗುರುತಿಸುವಿಕೆಯ ಬದಲಿಗೆ ಪ್ರತಿ ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕ ಪ್ರವೇಶದಲ್ಲಿ ಹಲವಾರು ಸಮಯ ಸರಣಿ ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಮೂಲಕ. ಅಂದರೆ, ನಮ್ಮ ಬಳಿ ಒಂದು ಕೀಲಿ ಇದೆ label=value, ಇದು ಪ್ರತಿ ಬಾರಿ ಸರಣಿಯಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ. ಮತ್ತು ಈಗ ನಾವು ಹಲವಾರು ಉಳಿಸುತ್ತೇವೆ timeseries_ids ಒಂದು ಪ್ರವೇಶದಲ್ಲಿ.

ಒಂದು ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ. ಹಿಂದೆ ನಾವು N ನಮೂದುಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಆದರೆ ಈಗ ನಾವು ಒಂದು ನಮೂದನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದರ ಪೂರ್ವಪ್ರತ್ಯಯವು ಇತರ ಎಲ್ಲದರಂತೆಯೇ ಇರುತ್ತದೆ. ಹಿಂದಿನ ನಮೂದುಗಾಗಿ, ಮೌಲ್ಯವು ಎಲ್ಲಾ ಸಮಯ ಸರಣಿ ಐಡಿಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.

ಅಂತಹ ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕದ ಸ್ಕ್ಯಾನಿಂಗ್ ವೇಗವನ್ನು 10 ಪಟ್ಟು ಹೆಚ್ಚಿಸಲು ಇದು ಸಾಧ್ಯವಾಗಿಸಿತು. ಮತ್ತು ಸಂಗ್ರಹಕ್ಕಾಗಿ ಮೆಮೊರಿ ಬಳಕೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು, ಏಕೆಂದರೆ ಈಗ ನಾವು ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ label=value N ಬಾರಿ ಒಟ್ಟಿಗೆ ಸಂಗ್ರಹದಲ್ಲಿ ಒಮ್ಮೆ ಮಾತ್ರ. ಮತ್ತು ನಿಮ್ಮ ಟ್ಯಾಗ್‌ಗಳು ಮತ್ತು ಲೇಬಲ್‌ಗಳಲ್ಲಿ ನೀವು ಉದ್ದವಾದ ಸಾಲುಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದರೆ ಈ ಸಾಲು ದೊಡ್ಡದಾಗಿರಬಹುದು, ಕುಬರ್ನೆಟ್ಸ್ ಅಲ್ಲಿಗೆ ತಳ್ಳಲು ಇಷ್ಟಪಡುತ್ತಾರೆ.

ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕದಲ್ಲಿ ಹುಡುಕಾಟವನ್ನು ವೇಗಗೊಳಿಸಲು ಮತ್ತೊಂದು ಆಯ್ಕೆಯು ಶಾರ್ಡಿಂಗ್ ಆಗಿದೆ. ಒಂದರ ಬದಲಿಗೆ ಹಲವಾರು ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕಗಳನ್ನು ರಚಿಸುವುದು ಮತ್ತು ಕೀಲಿಯಿಂದ ಅವುಗಳ ನಡುವೆ ಡೇಟಾವನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದು. ಇದು ಒಂದು ಸೆಟ್ ಆಗಿದೆ key=value ಉಗಿ. ಅಂದರೆ, ನಾವು ಹಲವಾರು ಸ್ವತಂತ್ರ ವಿಲೋಮ ಸೂಚ್ಯಂಕಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ, ಅದನ್ನು ನಾವು ಹಲವಾರು ಪ್ರೊಸೆಸರ್‌ಗಳಲ್ಲಿ ಸಮಾನಾಂತರವಾಗಿ ಪ್ರಶ್ನಿಸಬಹುದು. ಹಿಂದಿನ ಅಳವಡಿಕೆಗಳು ಸಿಂಗಲ್-ಪ್ರೊಸೆಸರ್ ಮೋಡ್‌ನಲ್ಲಿ ಮಾತ್ರ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಅನುಮತಿಸುತ್ತವೆ, ಅಂದರೆ, ಕೇವಲ ಒಂದು ಕೋರ್‌ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುವುದು. ಈ ಪರಿಹಾರವು ಕ್ಲಿಕ್‌ಹೌಸ್ ಮಾಡಲು ಇಷ್ಟಪಡುವಂತೆ ಹಲವಾರು ಕೋರ್‌ಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಸ್ಕ್ಯಾನ್ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ. ಇದನ್ನೇ ನಾವು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಯೋಜಿಸಿದ್ದೇವೆ.

ಈಗ ನಾವು ನಮ್ಮ ಕುರಿಗಳಿಗೆ ಹಿಂತಿರುಗೋಣ - ಛೇದಕ ಕಾರ್ಯಕ್ಕೆ timeseries_ids. ಯಾವ ಅನುಷ್ಠಾನಗಳು ಇರಬಹುದು ಎಂಬುದನ್ನು ಪರಿಗಣಿಸೋಣ. ಈ ಕಾರ್ಯವು ನಿಮಗೆ ಹುಡುಕಲು ಅನುಮತಿಸುತ್ತದೆ timeseries_ids ಕೊಟ್ಟಿರುವ ಸೆಟ್‌ಗಾಗಿ label=value.

ಮೊದಲ ಆಯ್ಕೆಯು ನಿಷ್ಕಪಟ ಅನುಷ್ಠಾನವಾಗಿದೆ. ಎರಡು ನೆಸ್ಟೆಡ್ ಲೂಪ್ಗಳು. ಇಲ್ಲಿ ನಾವು ಫಂಕ್ಷನ್ ಇನ್ಪುಟ್ ಅನ್ನು ಪಡೆಯುತ್ತೇವೆ intersectInts ಎರಡು ಚೂರುಗಳು - a и b. ಔಟ್ಪುಟ್ನಲ್ಲಿ, ಈ ಸ್ಲೈಸ್ಗಳ ಛೇದಕವನ್ನು ನಮಗೆ ಹಿಂತಿರುಗಿಸಬೇಕು.

ನಿಷ್ಕಪಟ ಅನುಷ್ಠಾನವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ. ನಾವು ಸ್ಲೈಸ್‌ನಿಂದ ಎಲ್ಲಾ ಮೌಲ್ಯಗಳನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತೇವೆ a, ಈ ಲೂಪ್ ಒಳಗೆ ನಾವು ಸ್ಲೈಸ್ನ ಎಲ್ಲಾ ಮೌಲ್ಯಗಳ ಮೂಲಕ ಹೋಗುತ್ತೇವೆ b. ಮತ್ತು ನಾವು ಅವುಗಳನ್ನು ಹೋಲಿಸುತ್ತೇವೆ. ಅವು ಹೊಂದಾಣಿಕೆಯಾದರೆ, ನಾವು ಛೇದಕವನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ಮತ್ತು ಅದನ್ನು ಉಳಿಸಿ result.

ಅನಾನುಕೂಲಗಳೇನು? ಕ್ವಾಡ್ರಾಟಿಕ್ ಸಂಕೀರ್ಣತೆಯು ಅದರ ಮುಖ್ಯ ನ್ಯೂನತೆಯಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ನಿಮ್ಮ ಆಯಾಮಗಳು ಸ್ಲೈಸ್ ಆಗಿದ್ದರೆ a и b ಒಂದು ಸಮಯದಲ್ಲಿ ಒಂದು ಮಿಲಿಯನ್, ನಂತರ ಈ ಕಾರ್ಯವು ನಿಮಗೆ ಉತ್ತರವನ್ನು ಎಂದಿಗೂ ಹಿಂತಿರುಗಿಸುವುದಿಲ್ಲ. ಏಕೆಂದರೆ ಇದು ಒಂದು ಟ್ರಿಲಿಯನ್ ಪುನರಾವರ್ತನೆಗಳನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಇದು ಆಧುನಿಕ ಕಂಪ್ಯೂಟರ್‌ಗಳಿಗೆ ಸಹ ಬಹಳಷ್ಟು ಆಗಿದೆ.

ಎರಡನೇ ಅನುಷ್ಠಾನವು ನಕ್ಷೆಯನ್ನು ಆಧರಿಸಿದೆ. ನಾವು ನಕ್ಷೆಯನ್ನು ರಚಿಸುತ್ತೇವೆ. ನಾವು ಸ್ಲೈಸ್‌ನಿಂದ ಎಲ್ಲಾ ಮೌಲ್ಯಗಳನ್ನು ಈ ನಕ್ಷೆಯಲ್ಲಿ ಇರಿಸಿದ್ದೇವೆ a. ನಂತರ ನಾವು ಪ್ರತ್ಯೇಕ ಲೂಪ್ನಲ್ಲಿ ಸ್ಲೈಸ್ ಮೂಲಕ ಹೋಗುತ್ತೇವೆ b. ಮತ್ತು ಈ ಮೌಲ್ಯವು ಸ್ಲೈಸ್‌ನಿಂದ ಬಂದಿದೆಯೇ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ b ನಕ್ಷೆಯಲ್ಲಿ. ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದರೆ, ನಂತರ ಅದನ್ನು ಫಲಿತಾಂಶಕ್ಕೆ ಸೇರಿಸಿ.

ಪ್ರಯೋಜನಗಳೇನು? ಅನುಕೂಲವೆಂದರೆ ರೇಖೀಯ ಸಂಕೀರ್ಣತೆ ಮಾತ್ರ. ಅಂದರೆ, ದೊಡ್ಡ ಸ್ಲೈಸ್‌ಗಳಿಗೆ ಕಾರ್ಯವು ಹೆಚ್ಚು ವೇಗವಾಗಿ ಕಾರ್ಯಗತಗೊಳ್ಳುತ್ತದೆ. ಮಿಲಿಯನ್ ಗಾತ್ರದ ಸ್ಲೈಸ್‌ಗಾಗಿ, ಹಿಂದಿನ ಫಂಕ್ಷನ್‌ನ ಟ್ರಿಲಿಯನ್ ಪುನರಾವರ್ತನೆಗಳಿಗೆ ವಿರುದ್ಧವಾಗಿ ಈ ಕಾರ್ಯವು 2 ಮಿಲಿಯನ್ ಪುನರಾವರ್ತನೆಗಳಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳ್ಳುತ್ತದೆ.

ತೊಂದರೆಯೆಂದರೆ ಈ ನಕ್ಷೆಯನ್ನು ರಚಿಸಲು ಈ ಕಾರ್ಯಕ್ಕೆ ಹೆಚ್ಚಿನ ಮೆಮೊರಿ ಅಗತ್ಯವಿರುತ್ತದೆ.

ಎರಡನೆಯ ನ್ಯೂನತೆಯೆಂದರೆ ಹ್ಯಾಶಿಂಗ್ಗಾಗಿ ದೊಡ್ಡ ಓವರ್ಹೆಡ್. ಈ ನ್ಯೂನತೆಯು ತುಂಬಾ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ಮತ್ತು ನಮಗೆ ಇದು ತುಂಬಾ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ, ಆದ್ದರಿಂದ ಮೊದಲಿಗೆ ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ನಲ್ಲಿ ಛೇದನದ ಅನುಷ್ಠಾನವು ನಕ್ಷೆಯ ಮೂಲಕವಾಗಿತ್ತು. ಆದರೆ ನಂತರ ಪ್ರೊಫೈಲಿಂಗ್ ಮುಖ್ಯ ಪ್ರೊಸೆಸರ್ ಸಮಯವನ್ನು ನಕ್ಷೆಗೆ ಬರೆಯಲು ಮತ್ತು ಈ ನಕ್ಷೆಯಲ್ಲಿ ಮೌಲ್ಯದ ಉಪಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಲು ಖರ್ಚುಮಾಡುತ್ತದೆ ಎಂದು ತೋರಿಸಿದೆ.

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

ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಿರ್ದಿಷ್ಟವಾಗಿ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ ಬಿಟ್‌ಸೆಟ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಾನು ನಿರ್ಧರಿಸಿದೆ. ಎರಡು ಸ್ಲೈಸ್‌ಗಳ ಛೇದಕವು ಈಗ ತೋರುತ್ತಿದೆ. ಇಲ್ಲಿ ನಾವು ಬಿಟ್ಸೆಟ್ ಅನ್ನು ರಚಿಸುತ್ತೇವೆ. ನಾವು ಮೊದಲ ಸ್ಲೈಸ್‌ನಿಂದ ಅಂಶಗಳನ್ನು ಸೇರಿಸುತ್ತೇವೆ. ನಂತರ ನಾವು ಎರಡನೇ ಸ್ಲೈಸ್ನಲ್ಲಿ ಈ ಅಂಶಗಳ ಉಪಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ಮತ್ತು ಅವುಗಳನ್ನು ಫಲಿತಾಂಶಕ್ಕೆ ಸೇರಿಸಿ. ಅಂದರೆ, ಇದು ಹಿಂದಿನ ಉದಾಹರಣೆಯಿಂದ ಬಹುತೇಕ ಭಿನ್ನವಾಗಿಲ್ಲ. ಇಲ್ಲಿ ಒಂದೇ ವಿಷಯವೆಂದರೆ ನಾವು ಕಸ್ಟಮ್ ಕಾರ್ಯಗಳೊಂದಿಗೆ ನಕ್ಷೆಗೆ ಪ್ರವೇಶವನ್ನು ಬದಲಾಯಿಸಿದ್ದೇವೆ add и has.

ಮೊದಲ ನೋಟದಲ್ಲಿ, ಈ ಹಿಂದೆ ಪ್ರಮಾಣಿತ ನಕ್ಷೆಯನ್ನು ಬಳಸಿದ್ದರೆ ಅದು ನಿಧಾನವಾಗಿ ಕೆಲಸ ಮಾಡಬೇಕೆಂದು ತೋರುತ್ತದೆ, ಮತ್ತು ನಂತರ ಕೆಲವು ಇತರ ಕಾರ್ಯಗಳನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ, ಆದರೆ ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ನ ಸಂದರ್ಭದಲ್ಲಿ ಈ ವಿಷಯವು ಪ್ರಮಾಣಿತ ನಕ್ಷೆಗಿಂತ 10 ಪಟ್ಟು ವೇಗವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಪ್ರೊಫೈಲಿಂಗ್ ತೋರಿಸುತ್ತದೆ.

ಇದರ ಜೊತೆಗೆ, ನಕ್ಷೆಯ ಅನುಷ್ಠಾನಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಇದು ಕಡಿಮೆ ಮೆಮೊರಿಯನ್ನು ಬಳಸುತ್ತದೆ. ಏಕೆಂದರೆ ನಾವು ಇಲ್ಲಿ ಎಂಟು-ಬೈಟ್ ಮೌಲ್ಯಗಳ ಬದಲಿಗೆ ಬಿಟ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತಿದ್ದೇವೆ.

ಈ ಅನುಷ್ಠಾನದ ಅನನುಕೂಲವೆಂದರೆ ಅದು ಅಷ್ಟು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ, ಕ್ಷುಲ್ಲಕವಲ್ಲ.

ಅನೇಕರು ಗಮನಿಸದಿರುವ ಮತ್ತೊಂದು ನ್ಯೂನತೆಯೆಂದರೆ ಈ ಅನುಷ್ಠಾನವು ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸದಿರಬಹುದು. ಅಂದರೆ, ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಸಮಯ ಸರಣಿಯ ಐಡಿಗಳ ಛೇದನದ ಈ ಸಂದರ್ಭದಲ್ಲಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ಪ್ರಕರಣಕ್ಕೆ ಇದನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲಾಗಿದೆ. ಇದು ಎಲ್ಲಾ ಸಂದರ್ಭಗಳಲ್ಲಿ ಸೂಕ್ತವಾಗಿದೆ ಎಂದು ಅರ್ಥವಲ್ಲ. ಇದನ್ನು ತಪ್ಪಾಗಿ ಬಳಸಿದರೆ, ನಾವು ಕಾರ್ಯಕ್ಷಮತೆಯ ಹೆಚ್ಚಳವನ್ನು ಪಡೆಯುವುದಿಲ್ಲ, ಆದರೆ ಮೆಮೊರಿ ದೋಷ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯ ನಿಧಾನಗತಿಯನ್ನು ಪಡೆಯುತ್ತೇವೆ.

ಈ ರಚನೆಯ ಅನುಷ್ಠಾನವನ್ನು ಪರಿಗಣಿಸೋಣ. ನೀವು ನೋಡಲು ಬಯಸಿದರೆ, ಇದು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಮೂಲಗಳಲ್ಲಿ, ಫೋಲ್ಡರ್ನಲ್ಲಿದೆ lib/uint64set. ಇದನ್ನು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಪ್ರಕರಣಕ್ಕೆ ವಿಶೇಷವಾಗಿ ಹೊಂದುವಂತೆ ಮಾಡಲಾಗಿದೆ timeseries_id 64-ಬಿಟ್ ಮೌಲ್ಯವಾಗಿದೆ, ಅಲ್ಲಿ ಮೊದಲ 32 ಬಿಟ್‌ಗಳು ಮೂಲತಃ ಸ್ಥಿರವಾಗಿರುತ್ತವೆ ಮತ್ತು ಕೊನೆಯ 32 ಬಿಟ್‌ಗಳು ಮಾತ್ರ ಬದಲಾಗುತ್ತವೆ.

ಈ ಡೇಟಾ ರಚನೆಯನ್ನು ಡಿಸ್ಕ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿಲ್ಲ, ಇದು ಮೆಮೊರಿಯಲ್ಲಿ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

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

ಕಾರ್ಯಗಳಿವೆ add, ಇದು ಹೊಸ ಮೌಲ್ಯಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ. ಒಂದು ಕಾರ್ಯವಿದೆ has, ಇದು ಹೊಸ ಮೌಲ್ಯಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಮತ್ತು ಒಂದು ಕಾರ್ಯವಿದೆ del, ಇದು ಮೌಲ್ಯಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಸಹಾಯಕ ಕಾರ್ಯವಿದೆ len, ಇದು ಸೆಟ್ನ ಗಾತ್ರವನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ. ಕಾರ್ಯ clone ಬಹಳಷ್ಟು ತದ್ರೂಪುಗಳು. ಮತ್ತು ಕಾರ್ಯ appendto ಈ ಸೆಟ್ ಅನ್ನು ಸ್ಲೈಸ್ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ timeseries_ids.

ಈ ಡೇಟಾ ರಚನೆಯ ಅನುಷ್ಠಾನವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ. ಸೆಟ್ ಎರಡು ಅಂಶಗಳನ್ನು ಹೊಂದಿದೆ:

• ItemsCount ಸೆಟ್‌ನಲ್ಲಿರುವ ಅಂಶಗಳ ಸಂಖ್ಯೆಯನ್ನು ತ್ವರಿತವಾಗಿ ಹಿಂತಿರುಗಿಸಲು ಸಹಾಯಕ ಕ್ಷೇತ್ರವಾಗಿದೆ. ಈ ಸಹಾಯಕ ಕ್ಷೇತ್ರವಿಲ್ಲದೆ ಮಾಡಲು ಸಾಧ್ಯವಿದೆ, ಆದರೆ ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಸಾಮಾನ್ಯವಾಗಿ ಅದರ ಅಲ್ಗಾರಿದಮ್‌ಗಳಲ್ಲಿ ಬಿಟ್‌ಸೆಟ್ ಉದ್ದವನ್ನು ಪ್ರಶ್ನಿಸುವುದರಿಂದ ಅದನ್ನು ಇಲ್ಲಿ ಸೇರಿಸಬೇಕಾಗಿತ್ತು.

• ಎರಡನೆಯ ಕ್ಷೇತ್ರವಾಗಿದೆ buckets. ಇದು ರಚನೆಯಿಂದ ಸ್ಲೈಸ್ ಆಗಿದೆ bucket32. ಪ್ರತಿಯೊಂದು ರಚನೆಯು ಸಂಗ್ರಹಿಸುತ್ತದೆ hi ಕ್ಷೇತ್ರ. ಇವು ಮೇಲಿನ 32 ಬಿಟ್‌ಗಳು. ಮತ್ತು ಎರಡು ಚೂರುಗಳು - b16his и buckets ನಿಂದ bucket16 ರಚನೆಗಳು.

16-ಬಿಟ್ ರಚನೆಯ ಎರಡನೇ ಭಾಗದ ಟಾಪ್ 64 ಬಿಟ್‌ಗಳನ್ನು ಇಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ. ಮತ್ತು ಇಲ್ಲಿ ಬಿಟ್‌ಸೆಟ್‌ಗಳನ್ನು ಪ್ರತಿ ಬೈಟ್‌ನ ಕಡಿಮೆ 16 ಬಿಟ್‌ಗಳಿಗೆ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ.

Bucket64 ಒಂದು ಶ್ರೇಣಿಯನ್ನು ಒಳಗೊಂಡಿದೆ uint64. ಈ ಸ್ಥಿರಾಂಕಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಉದ್ದವನ್ನು ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ. ಒಂದರಲ್ಲಿ bucket16 ಗರಿಷ್ಠ ಸಂಗ್ರಹಿಸಬಹುದು 2^16=65536 ಸ್ವಲ್ಪ. ನೀವು ಇದನ್ನು 8 ರಿಂದ ಭಾಗಿಸಿದರೆ, ಅದು 8 ಕಿಲೋಬೈಟ್ಗಳು. ನೀವು ಮತ್ತೆ 8 ರಿಂದ ಭಾಗಿಸಿದರೆ, ಅದು 1000 uint64 ಅರ್ಥ. ಅದು Bucket16 - ಇದು ನಮ್ಮ 8 ಕಿಲೋಬೈಟ್ ರಚನೆಯಾಗಿದೆ.

ಹೊಸ ಮೌಲ್ಯವನ್ನು ಸೇರಿಸಲು ಈ ರಚನೆಯ ವಿಧಾನಗಳಲ್ಲಿ ಒಂದನ್ನು ಹೇಗೆ ಅಳವಡಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ.

ಇದು ಎಲ್ಲಾ ಆರಂಭವಾಗುತ್ತದೆ uint64 ಅರ್ಥಗಳು. ನಾವು ಮೇಲಿನ 32 ಬಿಟ್‌ಗಳನ್ನು ಲೆಕ್ಕ ಹಾಕುತ್ತೇವೆ, ನಾವು ಕೆಳಗಿನ 32 ಬಿಟ್‌ಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತೇವೆ. ಎಲ್ಲದರ ಮೂಲಕ ಹೋಗೋಣ buckets. ನಾವು ಪ್ರತಿ ಬಕೆಟ್‌ನಲ್ಲಿನ ಟಾಪ್ 32 ಬಿಟ್‌ಗಳನ್ನು ಸೇರಿಸುವ ಮೌಲ್ಯದೊಂದಿಗೆ ಹೋಲಿಸುತ್ತೇವೆ. ಮತ್ತು ಅವು ಹೊಂದಾಣಿಕೆಯಾದರೆ, ನಾವು ಕಾರ್ಯವನ್ನು ಕರೆಯುತ್ತೇವೆ add ರಚನೆ b32 ರಲ್ಲಿ buckets. ಮತ್ತು ಅಲ್ಲಿ ಕಡಿಮೆ 32 ಬಿಟ್‌ಗಳನ್ನು ಸೇರಿಸಿ. ಮತ್ತು ಅದು ಹಿಂತಿರುಗಿದರೆ true, ನಂತರ ನಾವು ಅಲ್ಲಿ ಅಂತಹ ಮೌಲ್ಯವನ್ನು ಸೇರಿಸಿದ್ದೇವೆ ಮತ್ತು ಅಂತಹ ಮೌಲ್ಯವನ್ನು ನಾವು ಹೊಂದಿರಲಿಲ್ಲ ಎಂದರ್ಥ. ಅದು ಹಿಂತಿರುಗಿದರೆ false, ನಂತರ ಅಂತಹ ಅರ್ಥವು ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ. ನಂತರ ನಾವು ರಚನೆಯಲ್ಲಿನ ಅಂಶಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತೇವೆ.

ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ನಾವು ಕಂಡುಹಿಡಿಯದಿದ್ದರೆ bucket ಅಗತ್ಯವಿರುವ ಹೈ-ಮೌಲ್ಯದೊಂದಿಗೆ, ನಂತರ ನಾವು ಕಾರ್ಯವನ್ನು ಕರೆಯುತ್ತೇವೆ addAlloc, ಇದು ಹೊಸದನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ bucket, ಅದನ್ನು ಬಕೆಟ್ ರಚನೆಗೆ ಸೇರಿಸುವುದು.

ಇದು ಕಾರ್ಯದ ಅನುಷ್ಠಾನವಾಗಿದೆ b32.add. ಇದು ಹಿಂದಿನ ಅನುಷ್ಠಾನಕ್ಕೆ ಹೋಲುತ್ತದೆ. ನಾವು ಅತ್ಯಂತ ಗಮನಾರ್ಹವಾದ 16 ಬಿಟ್‌ಗಳನ್ನು ಲೆಕ್ಕ ಹಾಕುತ್ತೇವೆ, ಕನಿಷ್ಠ ಗಮನಾರ್ಹವಾದ 16 ಬಿಟ್‌ಗಳು.

ನಂತರ ನಾವು ಎಲ್ಲಾ ಮೇಲಿನ 16 ಬಿಟ್‌ಗಳ ಮೂಲಕ ಹೋಗುತ್ತೇವೆ. ನಾವು ಹೊಂದಾಣಿಕೆಗಳನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ. ಮತ್ತು ಹೊಂದಾಣಿಕೆಯಿದ್ದರೆ, ನಾವು ಆಡ್ ವಿಧಾನವನ್ನು ಕರೆಯುತ್ತೇವೆ, ಅದನ್ನು ನಾವು ಮುಂದಿನ ಪುಟದಲ್ಲಿ ಪರಿಗಣಿಸುತ್ತೇವೆ bucket16.

ಮತ್ತು ಇಲ್ಲಿ ಕಡಿಮೆ ಮಟ್ಟವಿದೆ, ಅದನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಹೊಂದುವಂತೆ ಮಾಡಬೇಕು. ನಾವು ಲೆಕ್ಕ ಹಾಕುತ್ತೇವೆ uint64 ಸ್ಲೈಸ್ ಬಿಟ್‌ನಲ್ಲಿ ಐಡಿ ಮೌಲ್ಯ ಮತ್ತು ಸಹ bitmask. ಕೊಟ್ಟಿರುವ 64-ಬಿಟ್ ಮೌಲ್ಯಕ್ಕೆ ಇದು ಮಾಸ್ಕ್ ಆಗಿದೆ, ಇದನ್ನು ಈ ಬಿಟ್ ಇರುವಿಕೆಯನ್ನು ಪರಿಶೀಲಿಸಲು ಅಥವಾ ಅದನ್ನು ಹೊಂದಿಸಲು ಬಳಸಬಹುದು. ಈ ಬಿಟ್ ಅನ್ನು ಹೊಂದಿಸಲಾಗಿದೆಯೇ ಮತ್ತು ಅದನ್ನು ಹೊಂದಿಸಲಾಗಿದೆಯೇ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ ಮತ್ತು ಉಪಸ್ಥಿತಿಯನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತೇವೆ. ಇದು ನಮ್ಮ ಅನುಷ್ಠಾನವಾಗಿದೆ, ಇದು ಸಾಂಪ್ರದಾಯಿಕ ನಕ್ಷೆಗಳಿಗೆ ಹೋಲಿಸಿದರೆ ಸಮಯ ಸರಣಿಯ ಛೇದಿಸುವ ಐಡಿಗಳ ಕಾರ್ಯಾಚರಣೆಯನ್ನು 10 ಪಟ್ಟು ವೇಗಗೊಳಿಸಲು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು.

ಈ ಆಪ್ಟಿಮೈಸೇಶನ್ ಜೊತೆಗೆ, ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಅನೇಕ ಇತರ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳನ್ನು ಹೊಂದಿದೆ. ಈ ಹೆಚ್ಚಿನ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳನ್ನು ಒಂದು ಕಾರಣಕ್ಕಾಗಿ ಸೇರಿಸಲಾಗಿದೆ, ಆದರೆ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ಪ್ರೊಫೈಲ್ ಮಾಡಿದ ನಂತರ.

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

ನನಗೆ ಬಿಟ್‌ಸೆಟ್ ಕುರಿತು ಪ್ರಶ್ನೆ ಇದೆ. C++ ವೆಕ್ಟರ್ ಬೂಲ್ ಅನುಷ್ಠಾನಕ್ಕೆ ಹೋಲುತ್ತದೆ, ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ ಬಿಟ್‌ಸೆಟ್. ಅಲ್ಲಿಂದ ನೀವು ಅನುಷ್ಠಾನವನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೀರಾ?

ಇಲ್ಲ, ಅಲ್ಲಿಂದ ಅಲ್ಲ. ಈ ಬಿಟ್‌ಸೆಟ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ, ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್‌ನಲ್ಲಿ ಬಳಸಲಾಗುವ ಈ ಐಡಿಗಳ ಸಮಯಸರಣಿಗಳ ರಚನೆಯ ಜ್ಞಾನದಿಂದ ನನಗೆ ಮಾರ್ಗದರ್ಶನ ನೀಡಲಾಯಿತು. ಮತ್ತು ಅವುಗಳ ರಚನೆಯು ಮೇಲಿನ 32 ಬಿಟ್‌ಗಳು ಮೂಲತಃ ಸ್ಥಿರವಾಗಿರುತ್ತವೆ. ಕೆಳಗಿನ 32 ಬಿಟ್‌ಗಳು ಬದಲಾವಣೆಗೆ ಒಳಪಟ್ಟಿರುತ್ತವೆ. ಕಡಿಮೆ ಬಿಟ್, ಹೆಚ್ಚಾಗಿ ಅದು ಬದಲಾಗಬಹುದು. ಆದ್ದರಿಂದ, ಈ ಅನುಷ್ಠಾನವನ್ನು ನಿರ್ದಿಷ್ಟವಾಗಿ ಈ ಡೇಟಾ ರಚನೆಗೆ ಹೊಂದುವಂತೆ ಮಾಡಲಾಗಿದೆ. C++ ಅನುಷ್ಠಾನ, ನನಗೆ ತಿಳಿದಿರುವಂತೆ, ಸಾಮಾನ್ಯ ಪ್ರಕರಣಕ್ಕೆ ಹೊಂದುವಂತೆ ಮಾಡಲಾಗಿದೆ. ನೀವು ಸಾಮಾನ್ಯ ಪ್ರಕರಣಕ್ಕೆ ಆಪ್ಟಿಮೈಜ್ ಮಾಡಿದರೆ, ಇದು ನಿರ್ದಿಷ್ಟ ಪ್ರಕರಣಕ್ಕೆ ಹೆಚ್ಚು ಸೂಕ್ತವಾಗಿರುವುದಿಲ್ಲ ಎಂದರ್ಥ.

ಅಲೆಕ್ಸಿ ಮಿಲೋವಿಡ್ ಅವರ ವರದಿಯನ್ನು ವೀಕ್ಷಿಸಲು ನಾನು ನಿಮಗೆ ಸಲಹೆ ನೀಡುತ್ತೇನೆ. ಸುಮಾರು ಒಂದು ತಿಂಗಳ ಹಿಂದೆ, ಅವರು ನಿರ್ದಿಷ್ಟ ವಿಶೇಷತೆಗಳಿಗಾಗಿ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಆಪ್ಟಿಮೈಸೇಶನ್ ಕುರಿತು ಮಾತನಾಡಿದರು. ಸಾಮಾನ್ಯ ಸಂದರ್ಭದಲ್ಲಿ, ಒಂದು C++ ಅಳವಡಿಕೆ ಅಥವಾ ಇತರ ಕೆಲವು ಅಳವಡಿಕೆಗಳು ಆಸ್ಪತ್ರೆಯಲ್ಲಿ ಸರಾಸರಿ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಅನುಗುಣವಾಗಿರುತ್ತವೆ ಎಂದು ಅವರು ಹೇಳುತ್ತಾರೆ. ಇದು ನಮ್ಮಂತಹ ಜ್ಞಾನ-ನಿರ್ದಿಷ್ಟ ಅನುಷ್ಠಾನಕ್ಕಿಂತ ಕೆಟ್ಟದಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು, ಅಲ್ಲಿ ಟಾಪ್ 32 ಬಿಟ್‌ಗಳು ಹೆಚ್ಚಾಗಿ ಸ್ಥಿರವಾಗಿರುತ್ತವೆ ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ.

ನನಗೆ ಎರಡನೇ ಪ್ರಶ್ನೆ ಇದೆ. InfluxDB ಯಿಂದ ಮೂಲಭೂತ ವ್ಯತ್ಯಾಸವೇನು?

ಅನೇಕ ಮೂಲಭೂತ ವ್ಯತ್ಯಾಸಗಳಿವೆ. ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಮೆಮೊರಿ ಬಳಕೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಪರೀಕ್ಷೆಗಳಲ್ಲಿ InfluxDB ಹೆಚ್ಚಿನ ಕಾರ್ಡಿನಾಲಿಟಿ ಸಮಯದ ಸರಣಿಗಾಗಿ 10 ಪಟ್ಟು ಹೆಚ್ಚು ಮೆಮೊರಿ ಬಳಕೆಯನ್ನು ತೋರಿಸುತ್ತದೆ, ನೀವು ಅವುಗಳಲ್ಲಿ ಬಹಳಷ್ಟು ಹೊಂದಿರುವಾಗ, ಉದಾಹರಣೆಗೆ, ಲಕ್ಷಾಂತರ. ಉದಾಹರಣೆಗೆ, VictoriaMetrics ಪ್ರತಿ ಮಿಲಿಯನ್ ಸಕ್ರಿಯ ಸಾಲುಗಳಿಗೆ 1 GB ಅನ್ನು ಬಳಸುತ್ತದೆ, ಆದರೆ InfluxDB 10 GB ಅನ್ನು ಬಳಸುತ್ತದೆ. ಮತ್ತು ಅದು ದೊಡ್ಡ ವ್ಯತ್ಯಾಸವಾಗಿದೆ.

ಎರಡನೆಯ ಮೂಲಭೂತ ವ್ಯತ್ಯಾಸವೆಂದರೆ InfluxDB ವಿಚಿತ್ರವಾದ ಪ್ರಶ್ನೆ ಭಾಷೆಗಳನ್ನು ಹೊಂದಿದೆ - Flux ಮತ್ತು InfluxQL. ಹೋಲಿಸಿದರೆ ಸಮಯ ಸರಣಿಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಅವು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿಲ್ಲ PromQL, ಇದನ್ನು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಬೆಂಬಲಿಸುತ್ತದೆ. PromQL ಎಂಬುದು ಪ್ರಮೀತಿಯಸ್‌ನಿಂದ ಪ್ರಶ್ನೆ ಭಾಷೆಯಾಗಿದೆ.

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

ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್‌ನಲ್ಲಿ ಎಲ್ಲವೂ ಹೆಚ್ಚು ಸರಳವಾಗಿದೆ. ಅಲ್ಲಿ, ಪ್ರತಿ ಸಮಯದ ಸರಣಿಯು ಒಂದು ಪ್ರಮುಖ ಮೌಲ್ಯವಾಗಿದೆ. ಮೌಲ್ಯವು ಬಿಂದುಗಳ ಗುಂಪಾಗಿದೆ - (timestamp, value), ಮತ್ತು ಕೀಲಿಯು ಸೆಟ್ ಆಗಿದೆ label=value. ಕ್ಷೇತ್ರಗಳು ಮತ್ತು ಅಳತೆಗಳ ನಡುವೆ ಯಾವುದೇ ಪ್ರತ್ಯೇಕತೆಯಿಲ್ಲ. ಇದು ನಿಮಗೆ ಯಾವುದೇ ಡೇಟಾವನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ ಸಂಯೋಜಿಸಲು, ಸೇರಿಸಲು, ಕಳೆಯಲು, ಗುಣಿಸಿ, ಭಾಗಿಸಿ, InfluxDB ಗಿಂತ ಭಿನ್ನವಾಗಿ ವಿವಿಧ ಸಾಲುಗಳ ನಡುವಿನ ಲೆಕ್ಕಾಚಾರಗಳು ನನಗೆ ತಿಳಿದಿರುವಂತೆ ಇನ್ನೂ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿಲ್ಲ. ಅವುಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದರೂ, ಅದು ಕಷ್ಟ, ನೀವು ಬಹಳಷ್ಟು ಕೋಡ್ ಅನ್ನು ಬರೆಯಬೇಕು.

ನನಗೆ ಸ್ಪಷ್ಟವಾದ ಪ್ರಶ್ನೆ ಇದೆ. ನೀವು ಮಾತನಾಡಿದ ಕೆಲವು ರೀತಿಯ ಸಮಸ್ಯೆ ಇದೆ ಎಂದು ನಾನು ಸರಿಯಾಗಿ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ, ಈ ತಲೆಕೆಳಗಾದ ಸೂಚ್ಯಂಕವು ಮೆಮೊರಿಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅಲ್ಲಿ ವಿಭಜನೆ ಇದೆಯೇ?

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

ನಮಸ್ಕಾರ! ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ನನ್ನ ಹೆಸರು ಪಾವೆಲ್. ನಾನು ವೈಲ್ಡ್ ಬೆರ್ರಿಗಳಿಂದ ಬಂದವನು. ನಾನು ನಿಮಗಾಗಿ ಕೆಲವು ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿದ್ದೇನೆ. ಪ್ರಶ್ನೆ ಒಂದು. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ನಿರ್ಮಿಸುವಾಗ ನೀವು ವಿಭಿನ್ನ ತತ್ವವನ್ನು ಆರಿಸಿದ್ದರೆ ಮತ್ತು ಕಾಲಾನಂತರದಲ್ಲಿ ಡೇಟಾವನ್ನು ವಿಭಜಿಸಿದ್ದರೆ, ಬಹುಶಃ ಒಂದು ವಿಭಾಗವು ಒಂದಕ್ಕೆ ಡೇಟಾವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಎಂಬ ಅಂಶವನ್ನು ಆಧರಿಸಿ ನೀವು ಹುಡುಕುವಾಗ ಡೇಟಾವನ್ನು ಛೇದಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಎಂದು ನೀವು ಭಾವಿಸುತ್ತೀರಾ? ಸಮಯದ ಅವಧಿ, ಅಂದರೆ, ಒಂದು ಸಮಯದ ಮಧ್ಯಂತರದಲ್ಲಿ ಮತ್ತು ನಿಮ್ಮ ತುಣುಕುಗಳು ವಿಭಿನ್ನವಾಗಿ ಚದುರಿಹೋಗಿವೆ ಎಂಬ ಅಂಶದ ಬಗ್ಗೆ ನೀವು ಚಿಂತಿಸಬೇಕಾಗಿಲ್ಲವೇ? ಪ್ರಶ್ನೆ ಸಂಖ್ಯೆ 2 - ನೀವು ಬಿಟ್‌ಸೆಟ್ ಮತ್ತು ಎಲ್ಲದರೊಂದಿಗೆ ಒಂದೇ ರೀತಿಯ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತಿರುವುದರಿಂದ, ಬಹುಶಃ ನೀವು ಪ್ರೊಸೆಸರ್ ಸೂಚನೆಗಳನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸಿದ್ದೀರಾ? ಬಹುಶಃ ನೀವು ಅಂತಹ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳನ್ನು ಪ್ರಯತ್ನಿಸಿದ್ದೀರಾ?

ಎರಡನೆಯದಕ್ಕೆ ನಾನು ತಕ್ಷಣ ಉತ್ತರಿಸುತ್ತೇನೆ. ನಾವು ಇನ್ನೂ ಆ ಹಂತಕ್ಕೆ ಬಂದಿಲ್ಲ. ಆದರೆ ಅಗತ್ಯವಿದ್ದರೆ, ನಾವು ಅಲ್ಲಿಗೆ ಹೋಗುತ್ತೇವೆ. ಮತ್ತು ಮೊದಲನೆಯದು, ಪ್ರಶ್ನೆ ಏನು?

ನೀವು ಎರಡು ಸನ್ನಿವೇಶಗಳನ್ನು ಚರ್ಚಿಸಿದ್ದೀರಿ. ಮತ್ತು ಅವರು ಎರಡನೆಯದನ್ನು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಅನುಷ್ಠಾನದೊಂದಿಗೆ ಆಯ್ಕೆ ಮಾಡಿದ್ದಾರೆ ಎಂದು ಅವರು ಹೇಳಿದರು. ಮತ್ತು ಅವರು ಮೊದಲನೆಯದನ್ನು ಆದ್ಯತೆ ನೀಡಲಿಲ್ಲ, ಅಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಮಯದಿಂದ ವಿಂಗಡಿಸಲಾಗಿದೆ.

ಹೌದು. ಮೊದಲನೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ಸೂಚ್ಯಂಕದ ಒಟ್ಟು ಪರಿಮಾಣವು ದೊಡ್ಡದಾಗಿರುತ್ತದೆ, ಏಕೆಂದರೆ ಪ್ರತಿ ವಿಭಾಗದಲ್ಲಿ ನಾವು ಈ ಎಲ್ಲಾ ವಿಭಾಗಗಳ ಮೂಲಕ ಮುಂದುವರಿಯುವ ಆ ಸಮಯದ ಸರಣಿಗಳಿಗೆ ನಕಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಬೇಕಾಗುತ್ತದೆ. ಮತ್ತು ನಿಮ್ಮ ಸಮಯ ಸರಣಿ ಮಂಥನ ದರವು ಚಿಕ್ಕದಾಗಿದ್ದರೆ, ಅಂದರೆ ಅದೇ ಸರಣಿಯನ್ನು ನಿರಂತರವಾಗಿ ಬಳಸಿದರೆ, ಮೊದಲ ಪ್ರಕರಣದಲ್ಲಿ ನಾವು ಎರಡನೇ ಪ್ರಕರಣಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಆಕ್ರಮಿಸಿಕೊಂಡಿರುವ ಡಿಸ್ಕ್ ಜಾಗದಲ್ಲಿ ಹೆಚ್ಚು ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ.

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

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

ಡೇಟಾವನ್ನು ಸಂಚರಿಸಲು ನಾವು ಕರ್ಸರ್‌ಗಳನ್ನು ಏಕೆ ಬಳಸಬಾರದು?

ಹೌದು.

ನಾವು LevelDB ಅಥವಾ ವಿಲೀನದಲ್ಲಿ ವಿಂಗಡಿಸಲಾದ ಸಾಲುಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ. ನಾವು ಕರ್ಸರ್ ಅನ್ನು ಚಲಿಸಬಹುದು ಮತ್ತು ಛೇದಕವನ್ನು ಕಂಡುಹಿಡಿಯಬಹುದು. ನಾವು ಅದನ್ನು ಏಕೆ ಬಳಸಬಾರದು? ಏಕೆಂದರೆ ಅದು ನಿಧಾನವಾಗಿದೆ. ಏಕೆಂದರೆ ಕರ್ಸರ್‌ಗಳು ಎಂದರೆ ನೀವು ಪ್ರತಿ ಸಾಲಿಗೆ ಒಂದು ಕಾರ್ಯವನ್ನು ಕರೆಯಬೇಕು. ಒಂದು ಫಂಕ್ಷನ್ ಕರೆ 5 ನ್ಯಾನೊಸೆಕೆಂಡ್‌ಗಳು. ಮತ್ತು ನೀವು 100 ಸಾಲುಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನಾವು ಕಾರ್ಯವನ್ನು ಕರೆಯಲು ಅರ್ಧ ಸೆಕೆಂಡ್ ಅನ್ನು ಕಳೆಯುತ್ತೇವೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ.

ಅಂತಹ ವಿಷಯವಿದೆ, ಹೌದು. ಮತ್ತು ನನ್ನ ಕೊನೆಯ ಪ್ರಶ್ನೆ. ಪ್ರಶ್ನೆ ಸ್ವಲ್ಪ ವಿಚಿತ್ರ ಅನ್ನಿಸಬಹುದು. ಡೇಟಾ ಬರುವ ಕ್ಷಣದಲ್ಲಿ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಸಮುಚ್ಚಯಗಳನ್ನು ಓದಲು ಮತ್ತು ಅಗತ್ಯವಿರುವ ರೂಪದಲ್ಲಿ ಉಳಿಸಲು ಏಕೆ ಸಾಧ್ಯವಿಲ್ಲ? ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್, ಕ್ಲಿಕ್‌ಹೌಸ್, ಇತ್ಯಾದಿಗಳಂತಹ ಕೆಲವು ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಬೃಹತ್ ಸಂಪುಟಗಳನ್ನು ಏಕೆ ಉಳಿಸಬೇಕು ಮತ್ತು ನಂತರ ಅವುಗಳ ಮೇಲೆ ಹೆಚ್ಚಿನ ಸಮಯವನ್ನು ಕಳೆಯಬೇಕು?

ಅದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸಲು ನಾನು ಒಂದು ಉದಾಹರಣೆಯನ್ನು ನೀಡುತ್ತೇನೆ. ಸಣ್ಣ ಆಟಿಕೆ ಸ್ಪೀಡೋಮೀಟರ್ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಹೇಳೋಣ? ಇದು ನೀವು ಪ್ರಯಾಣಿಸಿದ ದೂರವನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಎಲ್ಲಾ ಸಮಯದಲ್ಲೂ ಅದನ್ನು ಒಂದು ಮೌಲ್ಯಕ್ಕೆ ಸೇರಿಸುತ್ತದೆ ಮತ್ತು ಎರಡನೆಯದು - ಸಮಯ. ಮತ್ತು ವಿಭಜಿಸುತ್ತದೆ. ಮತ್ತು ಸರಾಸರಿ ವೇಗವನ್ನು ಪಡೆಯುತ್ತದೆ. ನೀವು ಅದೇ ವಿಷಯದ ಬಗ್ಗೆ ಮಾಡಬಹುದು. ಹಾರಾಡುತ್ತ ಎಲ್ಲಾ ಅಗತ್ಯ ಸಂಗತಿಗಳನ್ನು ಸೇರಿಸಿ.

ಸರಿ, ನಾನು ಪ್ರಶ್ನೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ. ನಿಮ್ಮ ಉದಾಹರಣೆಯು ಅದರ ಸ್ಥಾನವನ್ನು ಹೊಂದಿದೆ. ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಒಟ್ಟುಗೂಡುವಿಕೆಗಳು ನಿಮಗೆ ತಿಳಿದಿದ್ದರೆ, ಇದು ಅತ್ಯುತ್ತಮ ಅನುಷ್ಠಾನವಾಗಿದೆ. ಆದರೆ ಸಮಸ್ಯೆಯೆಂದರೆ ಜನರು ಈ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು, ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಕೆಲವು ಡೇಟಾವನ್ನು ಉಳಿಸುತ್ತಾರೆ ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ ಅವುಗಳನ್ನು ಹೇಗೆ ಒಟ್ಟುಗೂಡಿಸುತ್ತಾರೆ ಮತ್ತು ಫಿಲ್ಟರ್ ಮಾಡುತ್ತಾರೆ ಎಂದು ಅವರಿಗೆ ಇನ್ನೂ ತಿಳಿದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅವರು ಎಲ್ಲಾ ಕಚ್ಚಾ ಡೇಟಾವನ್ನು ಉಳಿಸಬೇಕಾಗುತ್ತದೆ. ಆದರೆ ನೀವು ಸರಾಸರಿ ಏನನ್ನಾದರೂ ಲೆಕ್ಕ ಹಾಕಬೇಕೆಂದು ನಿಮಗೆ ತಿಳಿದಿದ್ದರೆ, ಕಚ್ಚಾ ಮೌಲ್ಯಗಳ ಗುಂಪನ್ನು ಅಲ್ಲಿ ಸಂಗ್ರಹಿಸುವ ಬದಲು ಅದನ್ನು ಏಕೆ ಲೆಕ್ಕ ಹಾಕಬಾರದು? ಆದರೆ ಇದು ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ನಿಖರವಾಗಿ ತಿಳಿದಿದ್ದರೆ ಮಾತ್ರ.

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

ಉದಾಹರಣೆಗೆ, ನನ್ನ ಹಿಂದಿನ ಕೆಲಸದಲ್ಲಿ ನಾನು ಕಳೆದ ಗಂಟೆಯಲ್ಲಿ ಸ್ಲೈಡಿಂಗ್ ವಿಂಡೋದಲ್ಲಿ ಈವೆಂಟ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಎಣಿಸುವ ಅಗತ್ಯವಿದೆ. ಸಮಸ್ಯೆಯೆಂದರೆ ನಾನು Go ನಲ್ಲಿ ಕಸ್ಟಮ್ ಅನುಷ್ಠಾನವನ್ನು ಮಾಡಬೇಕಾಗಿತ್ತು, ಅಂದರೆ ಈ ವಿಷಯವನ್ನು ಎಣಿಸುವ ಸೇವೆ. ಈ ಸೇವೆಯು ಅಂತಿಮವಾಗಿ ಕ್ಷುಲ್ಲಕವಲ್ಲ, ಏಕೆಂದರೆ ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವುದು ಕಷ್ಟ. ನಿಗದಿತ ಸಮಯದ ಮಧ್ಯಂತರಗಳಲ್ಲಿ ನೀವು ಕೆಲವು ಸಮುಚ್ಚಯಗಳನ್ನು ಎಣಿಕೆ ಮಾಡಬೇಕಾದರೆ ಅನುಷ್ಠಾನವು ಸರಳವಾಗಿರುತ್ತದೆ. ನೀವು ಸ್ಲೈಡಿಂಗ್ ವಿಂಡೋದಲ್ಲಿ ಈವೆಂಟ್‌ಗಳನ್ನು ಎಣಿಸಲು ಬಯಸಿದರೆ, ಅದು ತೋರುವಷ್ಟು ಸರಳವಲ್ಲ. ಇದನ್ನು ಇನ್ನೂ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಅಥವಾ ಟೈಮ್‌ಸರೀಸ್ ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಏಕೆಂದರೆ ಇದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಕಷ್ಟವಾಗುತ್ತದೆ.

ಮತ್ತು ಇನ್ನೂ ಒಂದು ಪ್ರಶ್ನೆ. ನಾವು ಕೇವಲ ಸರಾಸರಿ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಕಾರ್ಬನ್ ಬ್ಯಾಕೆಂಡ್‌ನೊಂದಿಗೆ ಗ್ರ್ಯಾಫೈಟ್‌ನಂತಹ ವಿಷಯವು ಒಮ್ಮೆ ಇತ್ತು ಎಂದು ನಾನು ನೆನಪಿಸಿಕೊಂಡೆ. ಮತ್ತು ಹಳೆಯ ಡೇಟಾವನ್ನು ಹೇಗೆ ತೆಳುಗೊಳಿಸುವುದು ಎಂದು ಅವರಿಗೆ ತಿಳಿದಿತ್ತು, ಅಂದರೆ, ನಿಮಿಷಕ್ಕೆ ಒಂದು ಪಾಯಿಂಟ್, ಗಂಟೆಗೆ ಒಂದು ಪಾಯಿಂಟ್, ಇತ್ಯಾದಿ. ತಾತ್ವಿಕವಾಗಿ, ನಮಗೆ ಕಚ್ಚಾ ಡೇಟಾ ಅಗತ್ಯವಿದ್ದರೆ, ತುಲನಾತ್ಮಕವಾಗಿ ಹೇಳುವುದಾದರೆ, ಒಂದು ತಿಂಗಳವರೆಗೆ ಮತ್ತು ಉಳಿದಂತೆ ಎಲ್ಲವೂ ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ. ತೆಳುವಾಗಬೇಕು. ಆದರೆ ಪ್ರಮೀತಿಯಸ್ ಮತ್ತು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಈ ಕಾರ್ಯವನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. ಅದನ್ನು ಬೆಂಬಲಿಸಲು ಯೋಜಿಸಲಾಗಿದೆಯೇ? ಇಲ್ಲದಿದ್ದರೆ, ಏಕೆ ಮಾಡಬಾರದು?

ಪ್ರಶ್ನೆಗೆ ಧನ್ಯವಾದಗಳು. ನಮ್ಮ ಬಳಕೆದಾರರು ನಿಯತಕಾಲಿಕವಾಗಿ ಈ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳುತ್ತಾರೆ. ಡೌನ್‌ಸಾಂಪ್ಲಿಂಗ್‌ಗೆ ನಾವು ಯಾವಾಗ ಬೆಂಬಲವನ್ನು ಸೇರಿಸುತ್ತೇವೆ ಎಂದು ಅವರು ಕೇಳುತ್ತಾರೆ. ಇಲ್ಲಿ ಹಲವಾರು ಸಮಸ್ಯೆಗಳಿವೆ. ಮೊದಲನೆಯದಾಗಿ, ಪ್ರತಿಯೊಬ್ಬ ಬಳಕೆದಾರರು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ downsampling ಬೇರೆಯದ್ದೇನಾದರೂ: ನೀಡಿದ ಮಧ್ಯಂತರದಲ್ಲಿ ಯಾರಾದರೂ ಯಾವುದೇ ಅನಿಯಂತ್ರಿತ ಬಿಂದುವನ್ನು ಪಡೆಯಲು ಬಯಸುತ್ತಾರೆ, ಯಾರಾದರೂ ಗರಿಷ್ಠ, ಕನಿಷ್ಠ, ಸರಾಸರಿ ಮೌಲ್ಯಗಳನ್ನು ಬಯಸುತ್ತಾರೆ. ಅನೇಕ ಸಿಸ್ಟಮ್‌ಗಳು ನಿಮ್ಮ ಡೇಟಾಬೇಸ್‌ಗೆ ಡೇಟಾವನ್ನು ಬರೆದರೆ, ನೀವು ಎಲ್ಲವನ್ನೂ ಒಟ್ಟಿಗೆ ಸೇರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಪ್ರತಿಯೊಂದು ವ್ಯವಸ್ಥೆಗೆ ವಿಭಿನ್ನ ತೆಳುಗೊಳಿಸುವಿಕೆ ಅಗತ್ಯವಿರುತ್ತದೆ. ಮತ್ತು ಇದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಕಷ್ಟ.

ಮತ್ತು ಎರಡನೆಯ ವಿಷಯವೆಂದರೆ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಂತಹ ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್, ದೊಡ್ಡ ಪ್ರಮಾಣದ ಕಚ್ಚಾ ಡೇಟಾದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಹೊಂದುವಂತೆ ಮಾಡಲಾಗಿದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಸಿಸ್ಟಂನಲ್ಲಿ ನೀವು ಅನೇಕ ಕೋರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಅದು ಒಂದು ಸೆಕೆಂಡಿಗಿಂತ ಕಡಿಮೆ ಅವಧಿಯಲ್ಲಿ ಒಂದು ಬಿಲಿಯನ್ ಲೈನ್‌ಗಳನ್ನು ಷೋವೆಲ್ ಮಾಡಬಹುದು. ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್‌ನಲ್ಲಿ ಸಮಯ ಸರಣಿಯ ಅಂಕಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಲಾಗುತ್ತಿದೆ - ಪ್ರತಿ ಕೋರ್‌ಗೆ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 50 ಅಂಕಗಳು. ಮತ್ತು ಈ ಕಾರ್ಯಕ್ಷಮತೆಯು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕೋರ್‌ಗಳಿಗೆ ಮಾಪಕವಾಗುತ್ತದೆ. ಅಂದರೆ, ನೀವು 000 ಕೋರ್ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಉದಾಹರಣೆಗೆ, ನೀವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಶತಕೋಟಿ ಅಂಕಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುತ್ತೀರಿ. ಮತ್ತು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಈ ಆಸ್ತಿ ಡೌನ್‌ಸಾಮ್ಲಿಂಗ್ ಅಗತ್ಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಮತ್ತೊಂದು ವೈಶಿಷ್ಟ್ಯವೆಂದರೆ ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಈ ಡೇಟಾವನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಸಂಕುಚಿತಗೊಳಿಸುತ್ತದೆ. ಉತ್ಪಾದನೆಯಲ್ಲಿ ಸರಾಸರಿ ಸಂಕೋಚನವು ಪ್ರತಿ ಬಿಂದುವಿಗೆ 0,4 ರಿಂದ 0,8 ಬೈಟ್‌ಗಳವರೆಗೆ ಇರುತ್ತದೆ. ಪ್ರತಿ ಪಾಯಿಂಟ್ ಒಂದು ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ + ಮೌಲ್ಯವಾಗಿದೆ. ಮತ್ತು ಇದನ್ನು ಸರಾಸರಿ ಒಂದು ಬೈಟ್‌ಗಿಂತ ಕಡಿಮೆ ಸಂಕುಚಿತಗೊಳಿಸಲಾಗುತ್ತದೆ.

ಸೆರ್ಗೆಯ್. ನನಗೆ ಒಂದು ಪ್ರಶ್ನೆ ಇದೆ. ಕನಿಷ್ಠ ರೆಕಾರ್ಡಿಂಗ್ ಸಮಯದ ಕ್ವಾಂಟಮ್ ಎಷ್ಟು?

ಒಂದು ಮಿಲಿಸೆಕೆಂಡ್. ನಾವು ಇತ್ತೀಚೆಗೆ ಇತರ ಸಮಯ ಸರಣಿ ಡೇಟಾಬೇಸ್ ಡೆವಲಪರ್‌ಗಳೊಂದಿಗೆ ಸಂವಾದ ನಡೆಸಿದ್ದೇವೆ. ಅವರ ಕನಿಷ್ಠ ಸಮಯ ಸ್ಲೈಸ್ ಒಂದು ಸೆಕೆಂಡ್. ಮತ್ತು ಗ್ರ್ಯಾಫೈಟ್‌ನಲ್ಲಿ, ಉದಾಹರಣೆಗೆ, ಇದು ಒಂದು ಸೆಕೆಂಡ್ ಕೂಡ. OpenTSDB ಯಲ್ಲಿ ಇದು ಒಂದು ಸೆಕೆಂಡ್ ಆಗಿದೆ. InfluxDB ನ್ಯಾನೊಸೆಕೆಂಡ್ ನಿಖರತೆಯನ್ನು ಹೊಂದಿದೆ. ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್‌ನಲ್ಲಿ ಇದು ಒಂದು ಮಿಲಿಸೆಕೆಂಡ್, ಏಕೆಂದರೆ ಪ್ರಮೀತಿಯಸ್‌ನಲ್ಲಿ ಇದು ಒಂದು ಮಿಲಿಸೆಕೆಂಡ್. ಮತ್ತು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಅನ್ನು ಮೂಲತಃ ಪ್ರೋಮಿತಿಯಸ್‌ಗಾಗಿ ರಿಮೋಟ್ ಶೇಖರಣೆಯಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ. ಆದರೆ ಈಗ ಇದು ಇತರ ಸಿಸ್ಟಮ್‌ಗಳಿಂದ ಡೇಟಾವನ್ನು ಉಳಿಸಬಹುದು.

ನಾನು ಮಾತನಾಡಿದ ವ್ಯಕ್ತಿಯು ಅವರು ಎರಡನೇ-ಸೆಕೆಂಡ್ ನಿಖರತೆಯನ್ನು ಹೊಂದಿದ್ದಾರೆಂದು ಹೇಳುತ್ತಾರೆ - ಇದು ಅವರಿಗೆ ಸಾಕಷ್ಟು ಸಾಕು ಏಕೆಂದರೆ ಅದು ಸಮಯ ಸರಣಿ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿರುವ ಡೇಟಾದ ಪ್ರಕಾರವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಇದು DevOps ಡೇಟಾ ಅಥವಾ ಮೂಲಸೌಕರ್ಯದಿಂದ ಡೇಟಾ ಆಗಿದ್ದರೆ, ನೀವು ಅದನ್ನು ನಿಮಿಷಕ್ಕೆ 30 ಸೆಕೆಂಡುಗಳ ಮಧ್ಯಂತರದಲ್ಲಿ ಸಂಗ್ರಹಿಸಿದರೆ, ಎರಡನೇ ನಿಖರತೆ ಸಾಕು, ನಿಮಗೆ ಕಡಿಮೆ ಏನೂ ಅಗತ್ಯವಿಲ್ಲ. ಮತ್ತು ನೀವು ಹೆಚ್ಚಿನ ಆವರ್ತನ ವ್ಯಾಪಾರ ವ್ಯವಸ್ಥೆಗಳಿಂದ ಈ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿದರೆ, ನಂತರ ನಿಮಗೆ ನ್ಯಾನೊಸೆಕೆಂಡ್ ನಿಖರತೆಯ ಅಗತ್ಯವಿದೆ.

ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್‌ನಲ್ಲಿನ ಮಿಲಿಸೆಕೆಂಡ್ ನಿಖರತೆಯು DevOps ಪ್ರಕರಣಕ್ಕೆ ಸಹ ಸೂಕ್ತವಾಗಿದೆ ಮತ್ತು ವರದಿಯ ಪ್ರಾರಂಭದಲ್ಲಿ ನಾನು ಉಲ್ಲೇಖಿಸಿರುವ ಹೆಚ್ಚಿನ ಪ್ರಕರಣಗಳಿಗೆ ಇದು ಸೂಕ್ತವಾಗಿರುತ್ತದೆ. ಇದು ಸೂಕ್ತವಲ್ಲದ ಏಕೈಕ ವಿಷಯವೆಂದರೆ ಹೆಚ್ಚಿನ ಆವರ್ತನ ವ್ಯಾಪಾರ ವ್ಯವಸ್ಥೆಗಳು.

ಧನ್ಯವಾದ! ಮತ್ತು ಇನ್ನೊಂದು ಪ್ರಶ್ನೆ. PromQL ನಲ್ಲಿ ಹೊಂದಾಣಿಕೆ ಎಂದರೇನು?

ಪೂರ್ಣ ಹಿಮ್ಮುಖ ಹೊಂದಾಣಿಕೆ. VictoriaMetrics ಸಂಪೂರ್ಣವಾಗಿ PromQL ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಇದು PromQL ನಲ್ಲಿ ಹೆಚ್ಚುವರಿ ಸುಧಾರಿತ ಕಾರ್ಯವನ್ನು ಸೇರಿಸುತ್ತದೆ, ಇದನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ MetricsQL. ಈ ವಿಸ್ತೃತ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಕುರಿತು YouTube ನಲ್ಲಿ ಚರ್ಚೆ ನಡೆಯುತ್ತಿದೆ. ಸೇಂಟ್ ಪೀಟರ್ಸ್ಬರ್ಗ್ನಲ್ಲಿ ವಸಂತಕಾಲದಲ್ಲಿ ಮಾನಿಟರಿಂಗ್ ಮೀಟಪ್ನಲ್ಲಿ ನಾನು ಮಾತನಾಡಿದೆ.

ಟೆಲಿಗ್ರಾಮ್ ಚಾನಲ್ ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್.

ನೋಂದಾಯಿತ ಬಳಕೆದಾರರು ಮಾತ್ರ ಸಮೀಕ್ಷೆಯಲ್ಲಿ ಭಾಗವಹಿಸಬಹುದು. ಸೈನ್ ಇನ್ ಮಾಡಿ, ದಯವಿಟ್ಟು.

Prometheus ಗಾಗಿ ನಿಮ್ಮ ದೀರ್ಘಾವಧಿಯ ಸಂಗ್ರಹಣೆಯಾಗಿ VictoriaMetrics ಗೆ ಬದಲಾಯಿಸುವುದರಿಂದ ನಿಮ್ಮನ್ನು ತಡೆಯುವುದು ಯಾವುದು? (ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ಬರೆಯಿರಿ, ನಾನು ಅದನ್ನು ಸಮೀಕ್ಷೆಗೆ ಸೇರಿಸುತ್ತೇನೆ))

• 71,4%ನಾನು Prometheus5 ಅನ್ನು ಬಳಸುವುದಿಲ್ಲ

• 28,6%ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ 2 ಬಗ್ಗೆ ತಿಳಿದಿರಲಿಲ್ಲ

7 ಬಳಕೆದಾರರು ಮತ ಹಾಕಿದ್ದಾರೆ. 12 ಬಳಕೆದಾರರು ದೂರ ಉಳಿದಿದ್ದಾರೆ.

ಮೂಲ: www.habr.com