ಹೇ ಹಬ್ರ್! ನನ್ನ ಹೆಸರು ಮ್ಯಾಕ್ಸಿಮ್ ವಾಸಿಲೀವ್, ನಾನು FINCH ನಲ್ಲಿ ವಿಶ್ಲೇಷಕ ಮತ್ತು ಪ್ರಾಜೆಕ್ಟ್ ಮ್ಯಾನೇಜರ್ ಆಗಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ. ElasticSearch ಅನ್ನು ಬಳಸಿಕೊಂಡು, ನಾವು 15 ನಿಮಿಷಗಳಲ್ಲಿ 6 ಮಿಲಿಯನ್ ವಿನಂತಿಗಳನ್ನು ಹೇಗೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಮತ್ತು ನಮ್ಮ ಗ್ರಾಹಕರ ಸೈಟ್‌ನಲ್ಲಿ ದೈನಂದಿನ ಲೋಡ್‌ಗಳನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ಸಾಧ್ಯವಾಯಿತು ಎಂದು ಇಂದು ನಾನು ನಿಮಗೆ ಹೇಳಲು ಬಯಸುತ್ತೇನೆ. ದುರದೃಷ್ಟವಶಾತ್, ನಾವು ಹೆಸರುಗಳಿಲ್ಲದೆ ಮಾಡಬೇಕಾಗಿದೆ, ನಾವು ಎನ್ಡಿಎ ಹೊಂದಿರುವುದರಿಂದ, ಲೇಖನದ ವಿಷಯವು ಇದರಿಂದ ಬಳಲುತ್ತಿಲ್ಲ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ. ಹೋಗೋಣ.
ಯೋಜನೆಯು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ
ನಮ್ಮ ಬ್ಯಾಕೆಂಡ್‌ನಲ್ಲಿ, ನಮ್ಮ ಕ್ಲೈಂಟ್‌ನ ವೆಬ್‌ಸೈಟ್‌ಗಳು ಮತ್ತು ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಖಾತ್ರಿಪಡಿಸುವ ಸೇವೆಗಳನ್ನು ನಾವು ರಚಿಸುತ್ತೇವೆ. ಸಾಮಾನ್ಯ ರಚನೆಯನ್ನು ರೇಖಾಚಿತ್ರದಲ್ಲಿ ಕಾಣಬಹುದು:
ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ನಾವು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ವಹಿವಾಟುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತೇವೆ: ಖರೀದಿಗಳು, ಪಾವತಿಗಳು, ಬಳಕೆದಾರ ಸಮತೋಲನಗಳೊಂದಿಗೆ ಕಾರ್ಯಾಚರಣೆಗಳು, ಇದಕ್ಕಾಗಿ ನಾವು ಬಹಳಷ್ಟು ಲಾಗ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ, ಹಾಗೆಯೇ ಬಾಹ್ಯ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಈ ಡೇಟಾವನ್ನು ಆಮದು ಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ರಫ್ತು ಮಾಡುತ್ತೇವೆ.
ನಾವು ಕ್ಲೈಂಟ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ ಮತ್ತು ಅದನ್ನು ಬಳಕೆದಾರರಿಗೆ ವರ್ಗಾಯಿಸಿದಾಗ ರಿವರ್ಸ್ ಪ್ರಕ್ರಿಯೆಗಳು ಸಹ ಇವೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಪಾವತಿಗಳು ಮತ್ತು ಬೋನಸ್ ಕಾರ್ಯಕ್ರಮಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಇನ್ನೂ ಪ್ರಕ್ರಿಯೆಗಳಿವೆ.
ಸಂಕ್ಷಿಪ್ತ ಹಿನ್ನೆಲೆ
ಆರಂಭದಲ್ಲಿ, ನಾವು PostgreSQL ಅನ್ನು ಏಕೈಕ ಡೇಟಾ ಸ್ಟೋರ್ ಆಗಿ ಬಳಸಿದ್ದೇವೆ. DBMS ಗಾಗಿ ಇದರ ಪ್ರಮಾಣಿತ ಪ್ರಯೋಜನಗಳು: ವಹಿವಾಟುಗಳ ಉಪಸ್ಥಿತಿ, ಅಭಿವೃದ್ಧಿ ಹೊಂದಿದ ಡೇಟಾ ಮಾದರಿ ಭಾಷೆ, ಏಕೀಕರಣಕ್ಕಾಗಿ ವ್ಯಾಪಕ ಶ್ರೇಣಿಯ ಉಪಕರಣಗಳು; ಉತ್ತಮ ಕಾರ್ಯನಿರ್ವಹಣೆಯೊಂದಿಗೆ ಸಂಯೋಜಿತವಾಗಿ ಸಾಕಷ್ಟು ಸಮಯದವರೆಗೆ ನಮ್ಮ ಅಗತ್ಯಗಳನ್ನು ಪೂರೈಸಿದೆ.
ನಾವು ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ: ವಹಿವಾಟಿನಿಂದ ಸುದ್ದಿಯವರೆಗೆ. ಆದರೆ ಬಳಕೆದಾರರ ಸಂಖ್ಯೆ ಬೆಳೆಯಿತು, ಮತ್ತು ಅದರೊಂದಿಗೆ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ.
ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಡೆಸ್ಕ್‌ಟಾಪ್ ಸೈಟ್‌ನಲ್ಲಿ 2017 ರಲ್ಲಿ ವಾರ್ಷಿಕ ಸೆಷನ್‌ಗಳ ಸಂಖ್ಯೆ 131 ಮಿಲಿಯನ್. 2018 ರಲ್ಲಿ - 125 ಮಿಲಿಯನ್. 2019 ಮತ್ತೆ 130 ಮಿಲಿಯನ್. ಸೈಟ್‌ನ ಮೊಬೈಲ್ ಆವೃತ್ತಿ ಮತ್ತು ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಮತ್ತೊಂದು 100-200 ಮಿಲಿಯನ್ ಸೇರಿಸಿ, ಮತ್ತು ನೀವು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ವಿನಂತಿಗಳನ್ನು ಪಡೆಯುತ್ತದೆ.
ಯೋಜನೆಯ ಬೆಳವಣಿಗೆಯೊಂದಿಗೆ, ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಲೋಡ್ ಅನ್ನು ನಿಭಾಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದೆ, ನಮಗೆ ಸಮಯವಿಲ್ಲ - ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ವಿವಿಧ ಪ್ರಶ್ನೆಗಳು ಕಾಣಿಸಿಕೊಂಡವು, ಇದಕ್ಕಾಗಿ ನಾವು ಸಾಕಷ್ಟು ಸಂಖ್ಯೆಯ ಸೂಚ್ಯಂಕಗಳನ್ನು ರಚಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ.
ನಮ್ಮ ಅಗತ್ಯಗಳನ್ನು ಒದಗಿಸುವ ಮತ್ತು PostgreSQL ನಿಂದ ಹೊರೆಯನ್ನು ತೆಗೆದುಹಾಕುವ ಇತರ ಡೇಟಾ ಸ್ಟೋರ್‌ಗಳ ಅವಶ್ಯಕತೆಯಿದೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ. ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟ ಮತ್ತು ಮೊಂಗೋಡಿಬಿಯನ್ನು ಸಂಭವನೀಯ ಆಯ್ಕೆಗಳಾಗಿ ಪರಿಗಣಿಸಲಾಗಿದೆ. ನಂತರದವರು ಈ ಕೆಳಗಿನ ಅಂಶಗಳಲ್ಲಿ ಸೋತರು:
- ಇಂಡೆಕ್ಸ್‌ಗಳಲ್ಲಿನ ಡೇಟಾದ ಪ್ರಮಾಣವು ಹೆಚ್ಚಾದಂತೆ ನಿಧಾನವಾದ ಇಂಡೆಕ್ಸಿಂಗ್ ವೇಗ. ಸ್ಥಿತಿಸ್ಥಾಪಕದೊಂದಿಗೆ, ವೇಗವು ಡೇಟಾದ ಪ್ರಮಾಣವನ್ನು ಅವಲಂಬಿಸಿರುವುದಿಲ್ಲ.
- ಪೂರ್ಣ ಪಠ್ಯ ಹುಡುಕಾಟವಿಲ್ಲ
ಆದ್ದರಿಂದ ನಾವು ನಮಗಾಗಿ ಎಲಾಸ್ಟಿಕ್ ಅನ್ನು ಆರಿಸಿಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಪರಿವರ್ತನೆಗೆ ಸಿದ್ಧರಾಗಿದ್ದೇವೆ.
ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವಕ್ಕೆ ಪರಿವರ್ತನೆ
1. ನಾವು ಮಾರಾಟದ ಹುಡುಕಾಟ ಸೇವೆಯಿಂದ ಪರಿವರ್ತನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ನಮ್ಮ ಕ್ಲೈಂಟ್ ಒಟ್ಟು 70 ಪಾಯಿಂಟ್‌ಗಳ ಮಾರಾಟವನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಇದಕ್ಕೆ ಸೈಟ್‌ನಲ್ಲಿ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಹಲವಾರು ರೀತಿಯ ಹುಡುಕಾಟಗಳ ಅಗತ್ಯವಿದೆ:
- ನಗರದ ಹೆಸರಿನ ಮೂಲಕ ಪಠ್ಯ ಹುಡುಕಾಟ
- ಕೆಲವು ಹಂತದಿಂದ ನಿರ್ದಿಷ್ಟ ತ್ರಿಜ್ಯದೊಳಗೆ ಭೂಶೋಧನೆ. ಉದಾಹರಣೆಗೆ, ಬಳಕೆದಾರನು ತನ್ನ ಮನೆಗೆ ಸಮೀಪವಿರುವ ಮಾರಾಟದ ಬಿಂದುಗಳನ್ನು ನೋಡಲು ಬಯಸಿದರೆ.
- ನಿರ್ದಿಷ್ಟ ಚೌಕದಿಂದ ಹುಡುಕಿ - ಬಳಕೆದಾರರು ನಕ್ಷೆಯಲ್ಲಿ ಚೌಕವನ್ನು ಸೆಳೆಯುತ್ತಾರೆ ಮತ್ತು ಈ ತ್ರಿಜ್ಯದ ಎಲ್ಲಾ ಬಿಂದುಗಳನ್ನು ಅವನಿಗೆ ತೋರಿಸಲಾಗುತ್ತದೆ.
- ಹೆಚ್ಚುವರಿ ಫಿಲ್ಟರ್‌ಗಳ ಮೂಲಕ ಹುಡುಕಿ. ಮಾರಾಟದ ಬಿಂದುಗಳು ವಿಂಗಡಣೆಯಲ್ಲಿ ಪರಸ್ಪರ ಭಿನ್ನವಾಗಿರುತ್ತವೆ
ನಾವು ಸಂಸ್ಥೆಯ ಬಗ್ಗೆ ಮಾತನಾಡಿದರೆ, ನಂತರ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಲ್ಲಿ ನಾವು ನಕ್ಷೆ ಮತ್ತು ಸುದ್ದಿ ಎರಡಕ್ಕೂ ಡೇಟಾ ಮೂಲವನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳಲ್ಲಿ ಮೂಲ ಡೇಟಾದಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ. ವಾಸ್ತವವಾಗಿ, ಆರಂಭದಲ್ಲಿ ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಎಲ್ಲಾ ಮಾನದಂಡಗಳ ಮೂಲಕ ಹುಡುಕಾಟವನ್ನು ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಅನೇಕ ಸೂಚ್ಯಂಕಗಳು ಇದ್ದವು ಮಾತ್ರವಲ್ಲ, ಅವು ಅತಿಕ್ರಮಿಸಬಲ್ಲವು, ಆದ್ದರಿಂದ ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಶೆಡ್ಯೂಲರ್ ಕಳೆದುಹೋಯಿತು ಮತ್ತು ಯಾವ ಸೂಚ್ಯಂಕವನ್ನು ಬಳಸಬೇಕೆಂದು ಅರ್ಥವಾಗಲಿಲ್ಲ.
2. ಮುಂದಿನ ಸಾಲಿನಲ್ಲಿ ಸುದ್ದಿ ವಿಭಾಗವಾಗಿತ್ತು. ಪ್ರತಿದಿನ ಸೈಟ್‌ನಲ್ಲಿ ಪ್ರಕಟಣೆಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ ಇದರಿಂದ ಬಳಕೆದಾರರು ಮಾಹಿತಿಯ ಹರಿವಿನಲ್ಲಿ ಕಳೆದುಹೋಗುವುದಿಲ್ಲ, ಡೇಟಾವನ್ನು ನೀಡುವ ಮೊದಲು ಅದನ್ನು ವಿಂಗಡಿಸಬೇಕು. ಇದಕ್ಕಾಗಿ ಹುಡುಕಾಟವಾಗಿದೆ: ಪಠ್ಯ ಹೊಂದಾಣಿಕೆಯ ಮೂಲಕ ನೀವು ಸೈಟ್ ಅನ್ನು ಹುಡುಕಬಹುದು ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಹೆಚ್ಚುವರಿ ಫಿಲ್ಟರ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸಬಹುದು, ಏಕೆಂದರೆ ಅವುಗಳನ್ನು ಎಲಾಸ್ಟಿಕ್ ಮೂಲಕ ತಯಾರಿಸಲಾಗುತ್ತದೆ.
3. ನಂತರ ನಾವು ವಹಿವಾಟು ಪ್ರಕ್ರಿಯೆಗೆ ತೆರಳಿದ್ದೇವೆ. ಬಳಕೆದಾರರು ಸೈಟ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಉತ್ಪನ್ನವನ್ನು ಖರೀದಿಸಬಹುದು ಮತ್ತು ಬಹುಮಾನ ಡ್ರಾದಲ್ಲಿ ಭಾಗವಹಿಸಬಹುದು. ಅಂತಹ ಖರೀದಿಗಳ ನಂತರ, ವಿಶೇಷವಾಗಿ ವಾರಾಂತ್ಯ ಮತ್ತು ರಜಾದಿನಗಳಲ್ಲಿ ನಾವು ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತೇವೆ. ಹೋಲಿಕೆಗಾಗಿ, ಸಾಮಾನ್ಯ ದಿನಗಳಲ್ಲಿ ಖರೀದಿಗಳ ಸಂಖ್ಯೆ ಎಲ್ಲೋ 1,5-2 ಮಿಲಿಯನ್ ನಡುವೆ ಇದ್ದರೆ, ನಂತರ ರಜಾದಿನಗಳಲ್ಲಿ ಅಂಕಿ 53 ಮಿಲಿಯನ್ ತಲುಪಬಹುದು.
ಅದೇ ಸಮಯದಲ್ಲಿ, ಡೇಟಾವನ್ನು ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕು - ಬಳಕೆದಾರರು ಹಲವಾರು ದಿನಗಳವರೆಗೆ ಫಲಿತಾಂಶಕ್ಕಾಗಿ ಕಾಯಲು ಇಷ್ಟಪಡುವುದಿಲ್ಲ. ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಮೂಲಕ ಅಂತಹ ಗಡುವನ್ನು ಸಾಧಿಸಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ - ನಾವು ಆಗಾಗ್ಗೆ ಲಾಕ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತಿರುವಾಗ, ಬಳಕೆದಾರರು ಬಹುಮಾನಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ್ದಾರೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ವ್ಯಾಪಾರಕ್ಕೆ ಇದು ತುಂಬಾ ಆಹ್ಲಾದಕರವಲ್ಲ, ಆದ್ದರಿಂದ ನಾವು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವಿಕೆಯನ್ನು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟಕ್ಕೆ ಸರಿಸಿದೆವು.
ಆವರ್ತಕತೆ
ಈಗ ನವೀಕರಣಗಳನ್ನು ಈವೆಂಟ್ ಆಧಾರಿತವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ, ಈ ಕೆಳಗಿನ ಷರತ್ತುಗಳ ಪ್ರಕಾರ:
- ಮಾರಾಟದ ಬಿಂದುಗಳು. ನಾವು ಬಾಹ್ಯ ಮೂಲದಿಂದ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಿದ ತಕ್ಷಣ, ನಾವು ತಕ್ಷಣ ನವೀಕರಣವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ.
- ಸುದ್ದಿ. ಸೈಟ್‌ನಲ್ಲಿ ಯಾವುದೇ ಸುದ್ದಿಯನ್ನು ಸಂಪಾದಿಸಿದ ತಕ್ಷಣ, ಅದನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಎಲಾಸ್ಟಿಕ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ.
ಇಲ್ಲಿ ಮತ್ತೊಮ್ಮೆ ಎಲಾಸ್ಟಿಕ್ನ ಅನುಕೂಲಗಳನ್ನು ಉಲ್ಲೇಖಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಲ್ಲಿ, ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವಾಗ, ಅದು ಎಲ್ಲಾ ದಾಖಲೆಗಳನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವವರೆಗೆ ನೀವು ಕಾಯಬೇಕಾಗುತ್ತದೆ. ನೀವು 10 ದಾಖಲೆಗಳನ್ನು ಎಲಾಸ್ಟಿಕ್‌ಗೆ ಕಳುಹಿಸಬಹುದು ಮತ್ತು ಎಲ್ಲಾ ಚೂರುಗಳಾದ್ಯಂತ ದಾಖಲೆಗಳನ್ನು ವಿತರಿಸಲು ಕಾಯದೆ ತಕ್ಷಣವೇ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಬಹುದು. ಸಹಜವಾಗಿ, ಕೆಲವು ಶಾರ್ಡ್ ಅಥವಾ ರೆಪ್ಲಿಕಾ ಈಗಿನಿಂದಲೇ ಡೇಟಾವನ್ನು ನೋಡದಿರಬಹುದು, ಆದರೆ ಎಲ್ಲವೂ ಶೀಘ್ರದಲ್ಲೇ ಲಭ್ಯವಿರುತ್ತವೆ.
ಏಕೀಕರಣ ವಿಧಾನಗಳು
ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವದೊಂದಿಗೆ ಸಂಯೋಜಿಸಲು 2 ಮಾರ್ಗಗಳಿವೆ:
- TCP ಮೂಲಕ ಸ್ಥಳೀಯ ಕ್ಲೈಂಟ್ ಮೂಲಕ. ಸ್ಥಳೀಯ ಚಾಲಕ ಕ್ರಮೇಣ ಸಾಯುತ್ತಿದೆ: ಇದು ಇನ್ನು ಮುಂದೆ ಬೆಂಬಲಿತವಾಗಿಲ್ಲ, ಇದು ತುಂಬಾ ಅನನುಕೂಲವಾದ ಸಿಂಟ್ಯಾಕ್ಸ್ ಅನ್ನು ಹೊಂದಿದೆ. ಆದ್ದರಿಂದ, ನಾವು ಅದನ್ನು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಬಳಸುವುದಿಲ್ಲ ಮತ್ತು ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತ್ಯಜಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ.
- JSON ವಿನಂತಿಗಳು ಮತ್ತು ಲುಸೀನ್ ಸಿಂಟ್ಯಾಕ್ಸ್ ಎರಡನ್ನೂ ಬಳಸಬಹುದಾದ HTTP ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ. ಕೊನೆಯದು ಎಲಾಸ್ಟಿಕ್ ಅನ್ನು ಬಳಸುವ ಪಠ್ಯ ಎಂಜಿನ್ ಆಗಿದೆ. ಈ ಆವೃತ್ತಿಯಲ್ಲಿ, HTTP ಮೂಲಕ JSON ವಿನಂತಿಗಳ ಮೂಲಕ ಬ್ಯಾಚ್ ಮಾಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ನಾವು ಪಡೆಯುತ್ತೇವೆ. ಇದು ನಾವು ಬಳಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಆಯ್ಕೆಯಾಗಿದೆ.
HTTP ಇಂಟರ್ಫೇಸ್‌ಗೆ ಧನ್ಯವಾದಗಳು, ನಾವು HTTP ಕ್ಲೈಂಟ್‌ನ ಅಸಮಕಾಲಿಕ ಅನುಷ್ಠಾನವನ್ನು ಒದಗಿಸುವ ಲೈಬ್ರರಿಗಳನ್ನು ಬಳಸಬಹುದು. ನಾವು ಬ್ಯಾಚ್ ಮತ್ತು ಅಸಮಕಾಲಿಕ API ಯ ಲಾಭವನ್ನು ಪಡೆಯಬಹುದು, ಇದು ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ, ಇದು ದೊಡ್ಡ ಪ್ರಚಾರದ ದಿನಗಳಲ್ಲಿ ಬಹಳಷ್ಟು ಸಹಾಯ ಮಾಡಿದೆ (ಕೆಳಗಿನವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು)
ಹೋಲಿಕೆಗಾಗಿ ಕೆಲವು ಸಂಖ್ಯೆಗಳು:
- ಗುಂಪು ಮಾಡದೆಯೇ 20 ಥ್ರೆಡ್‌ಗಳಲ್ಲಿ ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಬೌಂಟಿ ಬಳಕೆದಾರರನ್ನು ಉಳಿಸಲಾಗುತ್ತಿದೆ: 460713 ಸೆಕೆಂಡುಗಳಲ್ಲಿ 42 ದಾಖಲೆಗಳು
- ಸ್ಥಿತಿಸ್ಥಾಪಕ + 10 ಎಳೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಾತ್ಮಕ ಕ್ಲೈಂಟ್ + 1000 ಅಂಶಗಳಿಗೆ ಬ್ಯಾಚ್: 596749 ಸೆಕೆಂಡುಗಳಲ್ಲಿ 11 ದಾಖಲೆಗಳು
- ಸ್ಥಿತಿಸ್ಥಾಪಕ + 10 ಎಳೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಾತ್ಮಕ ಕ್ಲೈಂಟ್ + 1000 ಅಂಶಗಳಿಗೆ ಬ್ಯಾಚ್: 23801684 ನಿಮಿಷಗಳಲ್ಲಿ 4 ನಮೂದುಗಳು
ಈಗ ನಾವು JSON ಅನ್ನು ಬ್ಯಾಚ್ / ಬ್ಯಾಚ್ ಅಲ್ಲ ಮತ್ತು ಲೈಬ್ರರಿಯನ್ನು ಲೆಕ್ಕಿಸದೆ ಯಾವುದೇ HTTP ಕ್ಲೈಂಟ್ ಮೂಲಕ ಕಳುಹಿಸುವ HTTP ವಿನಂತಿ ನಿರ್ವಾಹಕವನ್ನು ಬರೆದಿದ್ದೇವೆ. ನೀವು ವಿನಂತಿಗಳನ್ನು ಸಿಂಕ್ರೊನಸ್ ಅಥವಾ ಅಸಮಕಾಲಿಕವಾಗಿ ಕಳುಹಿಸಲು ಸಹ ಆಯ್ಕೆ ಮಾಡಬಹುದು.
ಕೆಲವು ಏಕೀಕರಣಗಳಲ್ಲಿ, ನಾವು ಇನ್ನೂ ಅಧಿಕೃತ ಸಾರಿಗೆ ಕ್ಲೈಂಟ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ, ಆದರೆ ಇದು ಮುಂದಿನ ಮರುಫಲಕೀಕರಣದ ವಿಷಯವಾಗಿದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸ್ಪ್ರಿಂಗ್ ವೆಬ್‌ಕ್ಲೈಂಟ್ ಆಧಾರದ ಮೇಲೆ ನಿರ್ಮಿಸಲಾದ ಕಸ್ಟಮ್ ಕ್ಲೈಂಟ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.
ದೊಡ್ಡ ಪ್ರಚಾರ
ವರ್ಷಕ್ಕೊಮ್ಮೆ, ಯೋಜನೆಯು ಬಳಕೆದಾರರಿಗೆ ದೊಡ್ಡ ಪ್ರಚಾರವನ್ನು ಆಯೋಜಿಸುತ್ತದೆ - ಇದು ಅದೇ ಹೈಲೋಡ್ ಆಗಿದೆ, ಏಕೆಂದರೆ ಈ ಸಮಯದಲ್ಲಿ ನಾವು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಹತ್ತಾರು ಮಿಲಿಯನ್ ಬಳಕೆದಾರರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ.
ಸಾಮಾನ್ಯವಾಗಿ ರಜಾದಿನಗಳಲ್ಲಿ ಲೋಡ್ಗಳ ಶಿಖರಗಳು ಸಂಭವಿಸುತ್ತವೆ, ಆದರೆ ಈ ಪ್ರಚಾರವು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಮಟ್ಟದಲ್ಲಿದೆ. ಹಿಂದಿನ ವರ್ಷ, ಪ್ರಚಾರದ ದಿನದಂದು, ನಾವು 27 ಯುನಿಟ್ ಸರಕುಗಳನ್ನು ಮಾರಾಟ ಮಾಡಿದ್ದೇವೆ. ಡೇಟಾವನ್ನು ಅರ್ಧ ಗಂಟೆಗೂ ಹೆಚ್ಚು ಕಾಲ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗಿದೆ, ಇದು ಬಳಕೆದಾರರಿಗೆ ಅನಾನುಕೂಲತೆಯನ್ನು ಉಂಟುಮಾಡಿದೆ. ಭಾಗವಹಿಸುವಿಕೆಗಾಗಿ ಬಳಕೆದಾರರು ಬಹುಮಾನಗಳನ್ನು ಪಡೆದರು, ಆದರೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವೇಗಗೊಳಿಸಬೇಕಾಗಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಯಿತು.
2019 ರ ಆರಂಭದಲ್ಲಿ, ನಮಗೆ ElasticSearch ಅಗತ್ಯವಿದೆ ಎಂದು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಇಡೀ ವರ್ಷ, ನಾವು ಎಲಾಸ್ಟಿಕ್‌ನಲ್ಲಿ ಸ್ವೀಕರಿಸಿದ ಡೇಟಾದ ಪ್ರಕ್ರಿಯೆ ಮತ್ತು ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ವೆಬ್‌ಸೈಟ್‌ನ API ನಲ್ಲಿ ಅವುಗಳ ವಿತರಣೆಯನ್ನು ಆಯೋಜಿಸಿದ್ದೇವೆ. ಪರಿಣಾಮವಾಗಿ, ಮುಂದಿನ ವರ್ಷ ಪ್ರಚಾರದ ಸಮಯದಲ್ಲಿ, ನಾವು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದ್ದೇವೆ 15 ನಿಮಿಷಗಳಲ್ಲಿ 131 ನಮೂದುಗಳು.
ನಾವು ಸರಕುಗಳನ್ನು ಖರೀದಿಸಲು ಮತ್ತು ಪ್ರಚಾರಗಳಲ್ಲಿ ಬಹುಮಾನಗಳ ಡ್ರಾಯಿಂಗ್ನಲ್ಲಿ ಭಾಗವಹಿಸಲು ಬಯಸುವ ಬಹಳಷ್ಟು ಜನರನ್ನು ಹೊಂದಿರುವುದರಿಂದ, ಇದು ತಾತ್ಕಾಲಿಕ ಕ್ರಮವಾಗಿದೆ. ಈಗ ನಾವು ಎಲಾಸ್ಟಿಕ್‌ಗೆ ನವೀಕೃತ ಮಾಹಿತಿಯನ್ನು ಕಳುಹಿಸುತ್ತಿದ್ದೇವೆ, ಆದರೆ ಭವಿಷ್ಯದಲ್ಲಿ ನಾವು ಕಳೆದ ತಿಂಗಳುಗಳ ಆರ್ಕೈವ್ ಮಾಡಿದ ಮಾಹಿತಿಯನ್ನು ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ಗೆ ಶಾಶ್ವತ ಸಂಗ್ರಹಣೆಯಾಗಿ ವರ್ಗಾಯಿಸಲು ಯೋಜಿಸುತ್ತೇವೆ. ಸ್ಥಿತಿಸ್ಥಾಪಕ ಸೂಚ್ಯಂಕವನ್ನು ಅಡ್ಡಿಪಡಿಸದಿರಲು, ಅದರ ಮಿತಿಗಳನ್ನು ಸಹ ಹೊಂದಿದೆ.
ತೀರ್ಮಾನ / ತೀರ್ಮಾನಗಳು
ಈ ಸಮಯದಲ್ಲಿ, ನಾವು ಬಯಸಿದ ಎಲ್ಲಾ ಸೇವೆಗಳನ್ನು ಎಲಾಸ್ಟಿಕ್‌ಗೆ ವರ್ಗಾಯಿಸಿದ್ದೇವೆ ಮತ್ತು ಸದ್ಯಕ್ಕೆ ಇದನ್ನು ವಿರಾಮಗೊಳಿಸಿದ್ದೇವೆ. ಈಗ ನಾವು ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಲ್ಲಿನ ಮುಖ್ಯ ನಿರಂತರ ಸಂಗ್ರಹಣೆಯ ಮೇಲೆ ಎಲಾಸ್ಟಿಕ್‌ನಲ್ಲಿ ಸೂಚ್ಯಂಕವನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದೇವೆ, ಇದು ಬಳಕೆದಾರರ ಹೊರೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಭವಿಷ್ಯದಲ್ಲಿ, ಡೇಟಾ ವಿನಂತಿಯು ತುಂಬಾ ವೈವಿಧ್ಯಮಯವಾಗಿದೆ ಮತ್ತು ಅನಿಯಮಿತ ಸಂಖ್ಯೆಯ ಕಾಲಮ್‌ಗಳಿಗಾಗಿ ಹುಡುಕಲಾಗುತ್ತದೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡರೆ ಸೇವೆಗಳನ್ನು ವರ್ಗಾಯಿಸಲು ನಾವು ಯೋಜಿಸುತ್ತೇವೆ. ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ಗೆ ಇದು ಇನ್ನು ಮುಂದೆ ಕಾರ್ಯವಲ್ಲ.
ನಮಗೆ ಕಾರ್ಯಸಾಧ್ಯತೆಯಲ್ಲಿ ಪೂರ್ಣ-ಪಠ್ಯ ಹುಡುಕಾಟ ಅಗತ್ಯವಿದ್ದರೆ ಅಥವಾ ನಾವು ಹಲವಾರು ವಿಭಿನ್ನ ಹುಡುಕಾಟ ಮಾನದಂಡಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಇದನ್ನು ಸ್ಥಿತಿಸ್ಥಾಪಕಕ್ಕೆ ಅನುವಾದಿಸಬೇಕಾಗಿದೆ ಎಂದು ನಮಗೆ ಈಗಾಗಲೇ ತಿಳಿದಿದೆ.
⌘⌘⌘
ಓದಿದ್ದಕ್ಕಾಗಿ ಧನ್ಯವಾದಗಳು. ನಿಮ್ಮ ಕಂಪನಿಯು ElasticSearch ಅನ್ನು ಬಳಸಿದರೆ ಮತ್ತು ಅದರ ಸ್ವಂತ ಅನುಷ್ಠಾನ ಪ್ರಕರಣಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ನಮಗೆ ತಿಳಿಸಿ. ಇತರರು ಹೇಗಿದ್ದಾರೆ ಎಂದು ತಿಳಿಯಲು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ 🙂
ಮೂಲ: www.habr.com