InfluxDB ಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಕೋಪ, ಚೌಕಾಶಿ ಮತ್ತು ಖಿನ್ನತೆ

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

ಹಕ್ಕುತ್ಯಾಗ: ಪಟ್ಟಿ ಮಾಡಲಾದ ಸಮಸ್ಯೆಗಳು InfluxDB ಆವೃತ್ತಿ 1.7.4 ಗೆ ಅನ್ವಯಿಸುತ್ತವೆ.

ಸಮಯ ಸರಣಿ ಏಕೆ?

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

ವಹಿವಾಟುಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುವಾಗ, ಒಂದು ಉಪಾಯ ಬಂದಿತು: InfluxDB ಸಮಯ ಸರಣಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಮುಖ್ಯ ಸಂಗ್ರಹಣೆಯಾಗಿ ಬಳಸಲು. ವಹಿವಾಟುಗಳು ಸಮಯದ ಬಿಂದುಗಳಾಗಿವೆ ಮತ್ತು ಅವು ಸಮಯ ಸರಣಿಯ ಮಾದರಿಗೆ ಚೆನ್ನಾಗಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ.

ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಯ ಕಾರ್ಯಗಳು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿ ಕಾಣುತ್ತವೆ - ದೀರ್ಘಕಾಲದವರೆಗೆ ಚಾರ್ಟ್‌ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಸೂಕ್ತವಾಗಿದೆ. ಬಳಕೆದಾರರಿಗೆ ಒಂದು ವರ್ಷಕ್ಕೆ ಚಾರ್ಟ್ ಅಗತ್ಯವಿದೆ, ಮತ್ತು ಡೇಟಾಬೇಸ್ ಐದು ನಿಮಿಷಗಳ ಸಮಯದ ಚೌಕಟ್ಟಿನೊಂದಿಗೆ ಡೇಟಾ ಸೆಟ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ. ಅವನಿಗೆ ಎಲ್ಲಾ ನೂರು ಸಾವಿರ ಚುಕ್ಕೆಗಳನ್ನು ಕಳುಹಿಸುವುದು ಅರ್ಥಹೀನ - ದೀರ್ಘ ಸಂಸ್ಕರಣೆಯ ಹೊರತಾಗಿ, ಅವು ಪರದೆಯ ಮೇಲೆ ಸಹ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ಸಮಯದ ಚೌಕಟ್ಟನ್ನು ಹೆಚ್ಚಿಸುವ ನಿಮ್ಮ ಸ್ವಂತ ಅನುಷ್ಠಾನವನ್ನು ನೀವು ಬರೆಯಬಹುದು ಅಥವಾ ಒಳಹರಿವಿನಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಯ ಕಾರ್ಯಗಳನ್ನು ಬಳಸಬಹುದು. ಅವರ ಸಹಾಯದಿಂದ, ನೀವು ದಿನದ ಮೂಲಕ ಡೇಟಾವನ್ನು ಗುಂಪು ಮಾಡಬಹುದು ಮತ್ತು ಅಗತ್ಯವಿರುವ 365 ಅಂಕಗಳನ್ನು ಕಳುಹಿಸಬಹುದು.

ಅಂತಹ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಉದ್ದೇಶಕ್ಕಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ ಎಂಬುದು ಸ್ವಲ್ಪ ಗೊಂದಲಮಯವಾಗಿತ್ತು. ಸರ್ವರ್‌ಗಳ ಮಾನಿಟರಿಂಗ್, ಐಒಟಿ ಸಾಧನಗಳು, "ಫ್ಲೋ" ಫಾರ್ಮ್‌ನ ಲಕ್ಷಾಂತರ ಬಿಂದುಗಳಿಂದ ಎಲ್ಲವೂ: [ - ]. ಆದರೆ ಡೇಟಾಬೇಸ್ ದೊಡ್ಡ ಡೇಟಾ ಹರಿವಿನೊಂದಿಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿದರೆ, ಸಣ್ಣ ಪರಿಮಾಣವು ಏಕೆ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಬೇಕು? ಇದನ್ನು ಗಮನದಲ್ಲಿಟ್ಟುಕೊಂಡು, ನಾವು ಕೆಲಸ ಮಾಡಲು InfluxDB ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ.

InfluxDB ಯಲ್ಲಿ ಬೇರೆ ಏನು ಅನುಕೂಲಕರವಾಗಿದೆ

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

ಸಹ ಇದೆ ಧಾರಣ ನೀತಿಗಳು (ಡಾಕ್) - ನಿರ್ದಿಷ್ಟ ಅವಧಿಯ ನಂತರ ಡೇಟಾ ಅಳಿಸುವಿಕೆಯನ್ನು ಹೊಂದಿಸುವುದು. ಉದಾಹರಣೆಗೆ, ನೀವು ಒಂದು ವಾರದವರೆಗೆ CPU ಲೋಡ್ ಅನ್ನು ಸೆಕೆಂಡಿಗೆ ಒಮ್ಮೆ ಅಳತೆಗಳೊಂದಿಗೆ ಸಂಗ್ರಹಿಸಬೇಕಾದಾಗ ಇದು ಉಪಯುಕ್ತವಾಗಿದೆ, ಆದರೆ ಒಂದೆರಡು ತಿಂಗಳ ಅಂತರದಲ್ಲಿ ಅಂತಹ ನಿಖರತೆ ಅಗತ್ಯವಿಲ್ಲ. ಅಂತಹ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ನೀವು ಇದನ್ನು ಮಾಡಬಹುದು:

1. ಮತ್ತೊಂದು ಕೋಷ್ಟಕದಲ್ಲಿ ಡೇಟಾವನ್ನು ಒಟ್ಟುಗೂಡಿಸಲು ನಿರಂತರ ಪ್ರಶ್ನೆಯನ್ನು ರಚಿಸಿ;
2. ಮೊದಲ ಕೋಷ್ಟಕದಲ್ಲಿ, ಅದೇ ವಾರಕ್ಕಿಂತ ಹಳೆಯದಾದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಅಳಿಸಲು ನೀತಿಯನ್ನು ವಿವರಿಸಿ.

ಮತ್ತು ಒಳಹರಿವು ಸ್ವತಂತ್ರವಾಗಿ ಡೇಟಾದ ಗಾತ್ರವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅನಗತ್ಯ ವಿಷಯಗಳನ್ನು ಅಳಿಸುತ್ತದೆ.

ಸಂಗ್ರಹಿಸಿದ ಡೇಟಾದ ಬಗ್ಗೆ

ಹೆಚ್ಚು ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿಲ್ಲ: ಸುಮಾರು 70 ಸಾವಿರ ವಹಿವಾಟುಗಳು ಮತ್ತು ಮಾರುಕಟ್ಟೆ ಮಾಹಿತಿಯೊಂದಿಗೆ ಮತ್ತೊಂದು ಮಿಲಿಯನ್ ಅಂಕಗಳು. ಹೊಸ ನಮೂದುಗಳನ್ನು ಸೇರಿಸಲಾಗುತ್ತಿದೆ - ದಿನಕ್ಕೆ 3000 ಅಂಕಗಳಿಗಿಂತ ಹೆಚ್ಚಿಲ್ಲ. ಸೈಟ್‌ಗಾಗಿ ಮೆಟ್ರಿಕ್‌ಗಳು ಸಹ ಇವೆ, ಆದರೆ ಅಲ್ಲಿ ಸ್ವಲ್ಪ ಡೇಟಾ ಇದೆ ಮತ್ತು ಧಾರಣ ನೀತಿಯ ಪ್ರಕಾರ, ಅವುಗಳನ್ನು ಒಂದು ತಿಂಗಳಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಸಂಗ್ರಹಿಸಲಾಗುವುದಿಲ್ಲ.

ತೊಂದರೆಗಳು

ಸೇವೆಯ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ನಂತರದ ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ, InfluxDB ಯ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಹೆಚ್ಚು ಹೆಚ್ಚು ನಿರ್ಣಾಯಕ ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸಿದವು.

1. ಡೇಟಾವನ್ನು ಅಳಿಸಲಾಗುತ್ತಿದೆ

ವಹಿವಾಟುಗಳೊಂದಿಗೆ ಡೇಟಾದ ಸರಣಿ ಇದೆ:

SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'

ಫಲಿತಾಂಶ:

ಡೇಟಾವನ್ನು ಅಳಿಸಲು ನಾನು ಆಜ್ಞೆಯನ್ನು ಕಳುಹಿಸುತ್ತಿದ್ದೇನೆ:

DELETE FROM transactions WHERE symbol=’USDT’

ಮುಂದೆ ನಾನು ಈಗಾಗಲೇ ಅಳಿಸಲಾದ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಲು ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತೇನೆ. ಮತ್ತು ಖಾಲಿ ಪ್ರತಿಕ್ರಿಯೆಯ ಬದಲಿಗೆ, ಒಳಹರಿವು ಅಳಿಸಬೇಕಾದ ಡೇಟಾದ ಭಾಗವನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ.

ನಾನು ಸಂಪೂರ್ಣ ಟೇಬಲ್ ಅನ್ನು ಅಳಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇನೆ:

DROP MEASUREMENT transactions

ನಾನು ಟೇಬಲ್ ಅಳಿಸುವಿಕೆಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇನೆ:

SHOW MEASUREMENTS

ನಾನು ಪಟ್ಟಿಯಲ್ಲಿ ಟೇಬಲ್ ಅನ್ನು ನೋಡುತ್ತಿಲ್ಲ, ಆದರೆ ಹೊಸ ಡೇಟಾ ಪ್ರಶ್ನೆಯು ಇನ್ನೂ ಅದೇ ವಹಿವಾಟುಗಳನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ.

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

ಪರಿಣಾಮವಾಗಿ, ಸಂಪೂರ್ಣ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಅಳಿಸುವುದು ಮತ್ತು ಮರುಸ್ಥಾಪಿಸುವುದು ಸಹಾಯ ಮಾಡಿತು.

2. ಫ್ಲೋಟಿಂಗ್ ಪಾಯಿಂಟ್ ಸಂಖ್ಯೆಗಳು

InfluxDB ಯಲ್ಲಿ ಅಂತರ್ನಿರ್ಮಿತ ಕಾರ್ಯಗಳನ್ನು ಬಳಸುವಾಗ ಗಣಿತ ಲೆಕ್ಕಾಚಾರಗಳು ನಿಖರತೆ ದೋಷಗಳನ್ನು ಹೊಂದಿವೆ. ಇದು ಅಸಾಮಾನ್ಯವಾದುದು ಎಂದು ಅಲ್ಲ, ಆದರೆ ಇದು ಅಹಿತಕರವಾಗಿದೆ.

ನನ್ನ ಸಂದರ್ಭದಲ್ಲಿ, ಡೇಟಾವು ಹಣಕಾಸಿನ ಘಟಕವನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ನಾನು ಅದನ್ನು ಹೆಚ್ಚಿನ ನಿಖರತೆಯೊಂದಿಗೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಬಯಸುತ್ತೇನೆ. ಈ ಕಾರಣದಿಂದಾಗಿ, ನಾವು ನಿರಂತರ ಪ್ರಶ್ನೆಗಳನ್ನು ತ್ಯಜಿಸಲು ಯೋಜಿಸುತ್ತೇವೆ.

3. ನಿರಂತರ ಪ್ರಶ್ನೆಗಳನ್ನು ವಿವಿಧ ಸಮಯ ವಲಯಗಳಿಗೆ ಅಳವಡಿಸಿಕೊಳ್ಳಲಾಗುವುದಿಲ್ಲ

ಸೇವೆಯು ದೈನಂದಿನ ವಹಿವಾಟಿನ ಅಂಕಿಅಂಶಗಳೊಂದಿಗೆ ಟೇಬಲ್ ಅನ್ನು ಹೊಂದಿದೆ. ಪ್ರತಿ ದಿನಕ್ಕೆ, ಆ ದಿನದ ಎಲ್ಲಾ ವಹಿವಾಟುಗಳನ್ನು ನೀವು ಗುಂಪು ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಆದರೆ ಪ್ರತಿ ಬಳಕೆದಾರರ ದಿನವು ವಿಭಿನ್ನ ಸಮಯದಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ಆದ್ದರಿಂದ ವಹಿವಾಟುಗಳ ಸೆಟ್ ವಿಭಿನ್ನವಾಗಿರುತ್ತದೆ. UTC ಮೂಲಕ ಹೌದು 37 ರೂಪಾಂತರಗಳು ನೀವು ಡೇಟಾವನ್ನು ಒಟ್ಟುಗೂಡಿಸಬೇಕಾದ ವರ್ಗಾವಣೆಗಳು.

InfluxDB ನಲ್ಲಿ, ಸಮಯದ ಪ್ರಕಾರ ಗುಂಪು ಮಾಡುವಾಗ, ನೀವು ಹೆಚ್ಚುವರಿಯಾಗಿ ಶಿಫ್ಟ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ ಮಾಸ್ಕೋ ಸಮಯಕ್ಕೆ (UTC+3):

SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)

ಆದರೆ ಪ್ರಶ್ನೆಯ ಫಲಿತಾಂಶವು ತಪ್ಪಾಗಿರುತ್ತದೆ. ಕೆಲವು ಕಾರಣಕ್ಕಾಗಿ, ದಿನದಿಂದ ಗುಂಪು ಮಾಡಲಾದ ಡೇಟಾವು 1677 ಕ್ಕೆ ಹಿಂತಿರುಗುತ್ತದೆ (ಇನ್‌ಫ್ಲಕ್ಸ್‌ಡಿಬಿ ಅಧಿಕೃತವಾಗಿ ಈ ವರ್ಷದಿಂದ ಸಮಯದ ಅವಧಿಯನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ):

ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನಾವು ತಾತ್ಕಾಲಿಕವಾಗಿ ಸೇವೆಯನ್ನು UTC+0 ಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ.

4. ಕಾರ್ಯಕ್ಷಮತೆ

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

ನನ್ನ ಪ್ರಕರಣವನ್ನು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.

ಸೇವೆಯು ಕೊನೆಯ ದಿನದ ಅಂಕಿಅಂಶಗಳನ್ನು ಹಿಂದಿರುಗಿಸುವ API ವಿಧಾನವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ನಿರ್ವಹಿಸುವಾಗ, ವಿಧಾನವು ಈ ಕೆಳಗಿನ ಪ್ರಶ್ನೆಗಳೊಂದಿಗೆ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಮೂರು ಬಾರಿ ಪ್ರಶ್ನಿಸುತ್ತದೆ:

SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1

SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1

SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESC

ವಿವರಣೆ

1. ಮೊದಲ ವಿನಂತಿಯಲ್ಲಿ, ನಾವು ಮಾರುಕಟ್ಟೆ ಡೇಟಾದೊಂದಿಗೆ ಪ್ರತಿ ನಾಣ್ಯಕ್ಕೆ ಕೊನೆಯ ಅಂಕಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ. ನನ್ನ ವಿಷಯದಲ್ಲಿ ಎಂಟು ನಾಣ್ಯಗಳಿಗೆ ಎಂಟು ಅಂಕಗಳು.
2. ಎರಡನೆಯ ವಿನಂತಿಯು ಹೊಸ ಅಂಕಗಳಲ್ಲಿ ಒಂದನ್ನು ಪಡೆಯುತ್ತದೆ.
3. ಮೂರನೆಯದು ಕಳೆದ XNUMX ಗಂಟೆಗಳ ವಹಿವಾಟುಗಳ ಪಟ್ಟಿಯನ್ನು ವಿನಂತಿಸುತ್ತದೆ; ಅವುಗಳಲ್ಲಿ ನೂರಾರು ಇರಬಹುದು.

InfluxDB ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಟ್ಯಾಗ್‌ಗಳು ಮತ್ತು ಸಮಯದ ಆಧಾರದ ಮೇಲೆ ಸೂಚ್ಯಂಕವನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ ಎಂದು ನಾನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತೇನೆ, ಇದು ಪ್ರಶ್ನೆಗಳನ್ನು ವೇಗಗೊಳಿಸುತ್ತದೆ. ಮೊದಲ ವಿನಂತಿಯಲ್ಲಿ ಚಿಹ್ನೆ ಒಂದು ಟ್ಯಾಗ್ ಆಗಿದೆ.

ನಾನು ಈ API ವಿಧಾನದಲ್ಲಿ ಒತ್ತಡ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಿದ್ದೇನೆ. 25 RPS ಗಾಗಿ, ಸರ್ವರ್ ಆರು CPUಗಳ ಸಂಪೂರ್ಣ ಲೋಡ್ ಅನ್ನು ಪ್ರದರ್ಶಿಸಿದೆ:

ಅದೇ ಸಮಯದಲ್ಲಿ, NodeJs ಪ್ರಕ್ರಿಯೆಯು ಯಾವುದೇ ಲೋಡ್ ಅನ್ನು ಒದಗಿಸಲಿಲ್ಲ.

ಮರಣದಂಡನೆಯ ವೇಗವು ಈಗಾಗಲೇ 7-10 RPS ನಿಂದ ಕೆಳಮಟ್ಟಕ್ಕಿಳಿದಿದೆ: ಒಬ್ಬ ಕ್ಲೈಂಟ್ 200 ms ನಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸಿದರೆ, ನಂತರ 10 ಕ್ಲೈಂಟ್‌ಗಳು ಒಂದು ಸೆಕೆಂಡ್ ಕಾಯಬೇಕಾಗಿತ್ತು. 25 RPS ಸ್ಥಿರತೆ ಅನುಭವಿಸಿದ ಮಿತಿಯಾಗಿದೆ; 500 ದೋಷಗಳನ್ನು ಗ್ರಾಹಕರಿಗೆ ಹಿಂತಿರುಗಿಸಲಾಗಿದೆ.

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

ತೀರ್ಮಾನಕ್ಕೆ

ಪಡೆದ ಅನುಭವದ ಪ್ರಮುಖ ತೀರ್ಮಾನವೆಂದರೆ ಸಾಕಷ್ಟು ವಿಶ್ಲೇಷಣೆಯಿಲ್ಲದೆ ನೀವು ಅಜ್ಞಾತ ತಂತ್ರಜ್ಞಾನವನ್ನು ಯೋಜನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ. Github ನಲ್ಲಿ ತೆರೆದ ಸಮಸ್ಯೆಗಳ ಸರಳ ಸ್ಕ್ರೀನಿಂಗ್ ಮುಖ್ಯ ಡೇಟಾ ಸ್ಟೋರ್ ಆಗಿ InfluxDB ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದನ್ನು ತಪ್ಪಿಸಲು ಮಾಹಿತಿಯನ್ನು ಒದಗಿಸುತ್ತದೆ.

InfluxDB ನನ್ನ ಯೋಜನೆಯ ಕಾರ್ಯಗಳಿಗೆ ಉತ್ತಮ ಫಿಟ್ ಆಗಿರಬೇಕು, ಆದರೆ ಅಭ್ಯಾಸವು ತೋರಿಸಿದಂತೆ, ಈ ಡೇಟಾಬೇಸ್ ಅಗತ್ಯಗಳನ್ನು ಪೂರೈಸುವುದಿಲ್ಲ ಮತ್ತು ಬಹಳಷ್ಟು ದೋಷಗಳನ್ನು ಹೊಂದಿದೆ.

ಪ್ರಾಜೆಕ್ಟ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ನೀವು ಈಗಾಗಲೇ ಆವೃತ್ತಿ 2.0.0-ಬೀಟಾವನ್ನು ಕಾಣಬಹುದು; ಎರಡನೇ ಆವೃತ್ತಿಯು ಗಮನಾರ್ಹ ಸುಧಾರಣೆಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ. ಈ ಮಧ್ಯೆ, ನಾನು TimescaleDB ದಸ್ತಾವೇಜನ್ನು ಅಧ್ಯಯನ ಮಾಡಲು ಹೋಗುತ್ತೇನೆ.

ಮೂಲ: www.habr.com