ಇನ್ನೂ "ಅವರ್ ಸೀಕ್ರೆಟ್ ಯೂನಿವರ್ಸ್: ದಿ ಹಿಡನ್ ಲೈಫ್ ಆಫ್ ದಿ ಸೆಲ್" ಚಿತ್ರದಿಂದ
ಹೂಡಿಕೆ ವ್ಯವಹಾರವು ಬ್ಯಾಂಕಿಂಗ್ ಜಗತ್ತಿನಲ್ಲಿ ಅತ್ಯಂತ ಸಂಕೀರ್ಣವಾದ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ, ಏಕೆಂದರೆ ಸಾಲಗಳು, ಎರವಲುಗಳು ಮತ್ತು ಠೇವಣಿಗಳು ಮಾತ್ರವಲ್ಲದೆ ಭದ್ರತೆಗಳು, ಕರೆನ್ಸಿಗಳು, ಸರಕುಗಳು, ಉತ್ಪನ್ನಗಳು ಮತ್ತು ರಚನಾತ್ಮಕ ಉತ್ಪನ್ನಗಳ ರೂಪದಲ್ಲಿ ಎಲ್ಲಾ ರೀತಿಯ ಸಂಕೀರ್ಣತೆಗಳೂ ಇವೆ.
ಇತ್ತೀಚೆಗೆ, ಜನಸಂಖ್ಯೆಯ ಆರ್ಥಿಕ ಸಾಕ್ಷರತೆಯ ಹೆಚ್ಚಳವನ್ನು ನಾವು ನೋಡಿದ್ದೇವೆ. ಹೆಚ್ಚು ಹೆಚ್ಚು ಜನರು ಸೆಕ್ಯುರಿಟೀಸ್ ಮಾರುಕಟ್ಟೆಗಳಲ್ಲಿ ವ್ಯಾಪಾರದಲ್ಲಿ ತೊಡಗಿಸಿಕೊಳ್ಳುತ್ತಿದ್ದಾರೆ. ವೈಯಕ್ತಿಕ ಹೂಡಿಕೆ ಖಾತೆಗಳು ಬಹಳ ಹಿಂದೆಯೇ ಕಾಣಿಸಿಕೊಂಡಿಲ್ಲ. ಸೆಕ್ಯುರಿಟೀಸ್ ಮಾರುಕಟ್ಟೆಗಳನ್ನು ವ್ಯಾಪಾರ ಮಾಡಲು ಮತ್ತು ತೆರಿಗೆ ವಿನಾಯಿತಿಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಅಥವಾ ತೆರಿಗೆಗಳನ್ನು ಪಾವತಿಸುವುದನ್ನು ತಪ್ಪಿಸಲು ಅವರು ನಿಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತಾರೆ. ಮತ್ತು ನಮ್ಮ ಬಳಿಗೆ ಬರುವ ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳು ತಮ್ಮ ಪೋರ್ಟ್‌ಫೋಲಿಯೊವನ್ನು ನಿರ್ವಹಿಸಲು ಮತ್ತು ನೈಜ ಸಮಯದಲ್ಲಿ ವರದಿ ಮಾಡುವುದನ್ನು ನೋಡಲು ಬಯಸುತ್ತಾರೆ. ಇದಲ್ಲದೆ, ಹೆಚ್ಚಾಗಿ ಈ ಪೋರ್ಟ್ಫೋಲಿಯೋ ಬಹು-ಉತ್ಪನ್ನವಾಗಿದೆ, ಅಂದರೆ, ಜನರು ವಿವಿಧ ವ್ಯಾಪಾರ ಮಾರ್ಗಗಳ ಗ್ರಾಹಕರು.
ಇದರ ಜೊತೆಗೆ, ರಷ್ಯನ್ ಮತ್ತು ವಿದೇಶಿ ಎರಡೂ ನಿಯಂತ್ರಕರ ಅಗತ್ಯತೆಗಳು ಬೆಳೆಯುತ್ತಿವೆ.
ಪ್ರಸ್ತುತ ಅಗತ್ಯಗಳನ್ನು ಪೂರೈಸಲು ಮತ್ತು ಭವಿಷ್ಯದ ಅಪ್‌ಗ್ರೇಡ್‌ಗಳಿಗೆ ಅಡಿಪಾಯ ಹಾಕಲು, ನಾವು ಟ್ಯಾರಂಟೂಲ್ ಅನ್ನು ಆಧರಿಸಿ ಹೂಡಿಕೆ ವ್ಯವಹಾರ ಕೇಂದ್ರವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ.
ಕೆಲವು ಅಂಕಿಅಂಶಗಳು. ಆಲ್ಫಾ-ಬ್ಯಾಂಕ್‌ನ ಹೂಡಿಕೆ ವ್ಯವಹಾರವು ವ್ಯಕ್ತಿಗಳು ಮತ್ತು ಕಾನೂನು ಘಟಕಗಳಿಗೆ ವಿವಿಧ ಸೆಕ್ಯುರಿಟೀಸ್ ಮಾರುಕಟ್ಟೆಗಳಲ್ಲಿ ವ್ಯಾಪಾರ ಮಾಡಲು ಅವಕಾಶವನ್ನು ಒದಗಿಸಲು ಬ್ರೋಕರೇಜ್ ಸೇವೆಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ, ಸೆಕ್ಯೂರಿಟಿಗಳ ಶೇಖರಣೆಗಾಗಿ ಠೇವಣಿ ಸೇವೆಗಳು, ಖಾಸಗಿ ಮತ್ತು ದೊಡ್ಡ ಬಂಡವಾಳ ಹೊಂದಿರುವ ವ್ಯಕ್ತಿಗಳಿಗೆ ಟ್ರಸ್ಟ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಸೇವೆಗಳು, ಇತರ ಕಂಪನಿಗಳಿಗೆ ಭದ್ರತೆಗಳನ್ನು ನೀಡುವ ಸೇವೆಗಳು . ಆಲ್ಫಾ-ಬ್ಯಾಂಕ್‌ನ ಹೂಡಿಕೆ ವ್ಯವಹಾರವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 3 ಸಾವಿರಕ್ಕೂ ಹೆಚ್ಚು ಉಲ್ಲೇಖಗಳನ್ನು ಒಳಗೊಂಡಿದೆ, ಇವುಗಳನ್ನು ವಿವಿಧ ವ್ಯಾಪಾರ ವೇದಿಕೆಗಳಿಂದ ಡೌನ್‌ಲೋಡ್ ಮಾಡಲಾಗುತ್ತದೆ. ಕೆಲಸದ ದಿನದಲ್ಲಿ, ಬ್ಯಾಂಕ್ ಅಥವಾ ಅದರ ಗ್ರಾಹಕರ ಪರವಾಗಿ ಮಾರುಕಟ್ಟೆಗಳಲ್ಲಿ 300 ಸಾವಿರಕ್ಕೂ ಹೆಚ್ಚು ವಹಿವಾಟುಗಳನ್ನು ಮುಕ್ತಾಯಗೊಳಿಸಲಾಗುತ್ತದೆ. ಬಾಹ್ಯ ಮತ್ತು ಆಂತರಿಕ ವೇದಿಕೆಗಳಲ್ಲಿ ಸೆಕೆಂಡಿಗೆ 5 ಸಾವಿರ ಆದೇಶದ ಮರಣದಂಡನೆಗಳು ಸಂಭವಿಸುತ್ತವೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಎಲ್ಲಾ ಗ್ರಾಹಕರು, ಆಂತರಿಕ ಮತ್ತು ಬಾಹ್ಯ ಎರಡೂ, ನೈಜ ಸಮಯದಲ್ಲಿ ತಮ್ಮ ಸ್ಥಾನಗಳನ್ನು ನೋಡಲು ಬಯಸುತ್ತಾರೆ.
ಪೂರ್ವೇತಿಹಾಸದ
2000 ರ ದಶಕದ ಆರಂಭದಿಂದ ಎಲ್ಲೋ, ನಮ್ಮ ಹೂಡಿಕೆ ವ್ಯವಹಾರದ ಕ್ಷೇತ್ರಗಳು ಸ್ವತಂತ್ರವಾಗಿ ಅಭಿವೃದ್ಧಿ ಹೊಂದಿದವು: ವಿನಿಮಯ ವ್ಯಾಪಾರ, ಬ್ರೋಕರೇಜ್ ಸೇವೆಗಳು, ಕರೆನ್ಸಿ ವ್ಯಾಪಾರ, ಸೆಕ್ಯುರಿಟೀಸ್ ಮತ್ತು ವಿವಿಧ ಉತ್ಪನ್ನಗಳಲ್ಲಿ ಪ್ರತ್ಯಕ್ಷವಾದ ವ್ಯಾಪಾರ. ಪರಿಣಾಮವಾಗಿ, ನಾವು ಕ್ರಿಯಾತ್ಮಕ ಬಾವಿಗಳ ಬಲೆಗೆ ಬಿದ್ದಿದ್ದೇವೆ. ಅದು ಏನು? ವ್ಯವಹಾರದ ಪ್ರತಿಯೊಂದು ಸಾಲು ತನ್ನದೇ ಆದ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಹೊಂದಿದ್ದು ಅದು ಪರಸ್ಪರ ಕಾರ್ಯಗಳನ್ನು ನಕಲು ಮಾಡುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ವ್ಯವಸ್ಥೆಯು ತನ್ನದೇ ಆದ ಡೇಟಾ ಮಾದರಿಯನ್ನು ಹೊಂದಿದೆ, ಆದಾಗ್ಯೂ ಅವುಗಳು ಒಂದೇ ಪರಿಕಲ್ಪನೆಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ: ವಹಿವಾಟುಗಳು, ಉಪಕರಣಗಳು, ಕೌಂಟರ್ಪಾರ್ಟಿಗಳು, ಉಲ್ಲೇಖಗಳು, ಇತ್ಯಾದಿ. ಮತ್ತು ಪ್ರತಿಯೊಂದು ವ್ಯವಸ್ಥೆಯು ಸ್ವತಂತ್ರವಾಗಿ ವಿಕಸನಗೊಂಡಂತೆ, ತಂತ್ರಜ್ಞಾನಗಳ ವೈವಿಧ್ಯಮಯ ಪ್ರಾಣಿಸಂಗ್ರಹಾಲಯವು ಹೊರಹೊಮ್ಮಿತು.
ಇದರ ಜೊತೆಗೆ, ವ್ಯವಸ್ಥೆಗಳ ಕೋಡ್ ಬೇಸ್ ಈಗಾಗಲೇ ಸಾಕಷ್ಟು ಹಳೆಯದಾಗಿದೆ, ಏಕೆಂದರೆ ಕೆಲವು ಉತ್ಪನ್ನಗಳು 1990 ರ ದಶಕದ ಮಧ್ಯಭಾಗದಲ್ಲಿ ಹುಟ್ಟಿಕೊಂಡಿವೆ. ಮತ್ತು ಕೆಲವು ಪ್ರದೇಶಗಳಲ್ಲಿ ಇದು ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿಧಾನಗೊಳಿಸಿತು ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳಿವೆ.
ಹೊಸ ಪರಿಹಾರಕ್ಕಾಗಿ ಅಗತ್ಯತೆಗಳು
ಮತ್ತಷ್ಟು ಅಭಿವೃದ್ಧಿಗೆ ತಾಂತ್ರಿಕ ರೂಪಾಂತರವು ಅತ್ಯಗತ್ಯ ಎಂದು ವ್ಯಾಪಾರಗಳು ಅರಿತುಕೊಂಡಿವೆ. ನಮಗೆ ಕಾರ್ಯಗಳನ್ನು ನೀಡಲಾಗಿದೆ:
- ಎಲ್ಲಾ ವ್ಯಾಪಾರ ಡೇಟಾವನ್ನು ಒಂದೇ, ವೇಗದ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಮತ್ತು ಒಂದೇ ಡೇಟಾ ಮಾದರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ.
- ನಾವು ಈ ಮಾಹಿತಿಯನ್ನು ಕಳೆದುಕೊಳ್ಳಬಾರದು ಅಥವಾ ಬದಲಾಯಿಸಬಾರದು.
- ಡೇಟಾವನ್ನು ಆವೃತ್ತಿ ಮಾಡುವುದು ಅವಶ್ಯಕ, ಏಕೆಂದರೆ ಯಾವುದೇ ಕ್ಷಣದಲ್ಲಿ ನಿಯಂತ್ರಕರು ಹಿಂದಿನ ವರ್ಷಗಳ ಅಂಕಿಅಂಶಗಳನ್ನು ಕೇಳಬಹುದು.
- ನಾವು ಕೆಲವು ಹೊಸ, ಫ್ಯಾಶನ್ DBMS ಅನ್ನು ತರಬಾರದು, ಆದರೆ ವ್ಯಾಪಾರ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ವೇದಿಕೆಯನ್ನು ರಚಿಸಬೇಕು.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಮ್ಮ ವಾಸ್ತುಶಿಲ್ಪಿಗಳು ತಮ್ಮದೇ ಆದ ಷರತ್ತುಗಳನ್ನು ಹೊಂದಿಸುತ್ತಾರೆ:
- ಹೊಸ ಪರಿಹಾರವು ಎಂಟರ್‌ಪ್ರೈಸ್-ಕ್ಲಾಸ್ ಆಗಿರಬೇಕು, ಅಂದರೆ, ಇದನ್ನು ಈಗಾಗಲೇ ಕೆಲವು ದೊಡ್ಡ ಕಂಪನಿಗಳಲ್ಲಿ ಪರೀಕ್ಷಿಸಬೇಕು.
- ಪರಿಹಾರದ ಆಪರೇಟಿಂಗ್ ಮೋಡ್ ಮಿಷನ್ ಕ್ರಿಟಿಕಲ್ ಆಗಿರಬೇಕು. ಇದರರ್ಥ ನಾವು ಹಲವಾರು ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಏಕಕಾಲದಲ್ಲಿ ಇರಬೇಕು ಮತ್ತು ಒಂದು ಡೇಟಾ ಸೆಂಟರ್‌ನ ಸ್ಥಗಿತವನ್ನು ಶಾಂತವಾಗಿ ಬದುಕಬೇಕು.
- ವ್ಯವಸ್ಥೆಯು ಅಡ್ಡಲಾಗಿ ಸ್ಕೇಲೆಬಲ್ ಆಗಿರಬೇಕು. ವಾಸ್ತವವೆಂದರೆ ನಮ್ಮ ಎಲ್ಲಾ ಪ್ರಸ್ತುತ ವ್ಯವಸ್ಥೆಗಳು ಲಂಬವಾಗಿ ಸ್ಕೇಲೆಬಲ್ ಆಗಿರುತ್ತವೆ ಮತ್ತು ಹಾರ್ಡ್‌ವೇರ್ ಶಕ್ತಿಯ ಕಡಿಮೆ ಬೆಳವಣಿಗೆಯಿಂದಾಗಿ ನಾವು ಈಗಾಗಲೇ ಸೀಲಿಂಗ್ ಅನ್ನು ಹೊಡೆಯುತ್ತಿದ್ದೇವೆ. ಆದ್ದರಿಂದ, ನಾವು ಬದುಕಲು ಸಮತಲವಾಗಿ ಸ್ಕೇಲೆಬಲ್ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಂದಿರಬೇಕಾದ ಕ್ಷಣ ಬಂದಿದೆ.
- ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ, ಪರಿಹಾರವು ಅಗ್ಗವಾಗಿರಬೇಕು ಎಂದು ನಮಗೆ ತಿಳಿಸಲಾಯಿತು.
ನಾವು ಪ್ರಮಾಣಿತ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸಿದ್ದೇವೆ: ನಾವು ಅವಶ್ಯಕತೆಗಳನ್ನು ರೂಪಿಸಿದ್ದೇವೆ ಮತ್ತು ಖರೀದಿ ವಿಭಾಗವನ್ನು ಸಂಪರ್ಕಿಸಿದ್ದೇವೆ. ಅಲ್ಲಿಂದ ನಾವು ಸಾಮಾನ್ಯವಾಗಿ, ನಮಗಾಗಿ ಇದನ್ನು ಮಾಡಲು ಸಿದ್ಧವಾಗಿರುವ ಕಂಪನಿಗಳ ಪಟ್ಟಿಯನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ. ನಾವು ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ ಎಲ್ಲರಿಗೂ ಹೇಳಿದ್ದೇವೆ ಮತ್ತು ಅವರಲ್ಲಿ ಆರು ಜನರ ಪರಿಹಾರಗಳ ಮೌಲ್ಯಮಾಪನವನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ.
ಬ್ಯಾಂಕಿನಲ್ಲಿ, ನಾವು ಯಾರ ಮಾತನ್ನೂ ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ; ನಾವು ಎಲ್ಲವನ್ನೂ ನಾವೇ ಪರೀಕ್ಷಿಸಲು ಇಷ್ಟಪಡುತ್ತೇವೆ. ಆದ್ದರಿಂದ, ಲೋಡ್ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಉತ್ತೀರ್ಣರಾಗುವುದು ನಮ್ಮ ಟೆಂಡರ್ ಸ್ಪರ್ಧೆಯ ಕಡ್ಡಾಯ ಷರತ್ತು. ನಾವು ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಕಾರ್ಯಗಳನ್ನು ರೂಪಿಸಿದ್ದೇವೆ ಮತ್ತು ಆರು ಕಂಪನಿಗಳಲ್ಲಿ ಮೂರು ಕಂಪನಿಗಳು ಅದನ್ನು ಪರೀಕ್ಷಿಸಲು ತಮ್ಮ ಸ್ವಂತ ವೆಚ್ಚದಲ್ಲಿ ಇನ್-ಮೆಮೊರಿ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ಆಧರಿಸಿ ಮೂಲಮಾದರಿಯ ಪರಿಹಾರವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಈಗಾಗಲೇ ಒಪ್ಪಿಕೊಂಡಿವೆ.
ನಾವು ಎಲ್ಲವನ್ನೂ ಹೇಗೆ ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ ಮತ್ತು ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುವುದಿಲ್ಲ, ನಾನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುತ್ತೇನೆ: Mail.ru ಗ್ರೂಪ್ ಡೆವಲಪ್‌ಮೆಂಟ್ ತಂಡದಿಂದ Tarantool ಆಧಾರಿತ ಮೂಲಮಾದರಿಯ ಪರಿಹಾರದಿಂದ ಲೋಡ್ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಉತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ತೋರಿಸಲಾಗಿದೆ. ನಾವು ಒಪ್ಪಂದಕ್ಕೆ ಸಹಿ ಹಾಕಿದ್ದೇವೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿಯನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. Mail.ru ಗುಂಪಿನಿಂದ ನಾಲ್ಕು ಜನರಿದ್ದರು, ಮತ್ತು ಆಲ್ಫಾ-ಬ್ಯಾಂಕ್‌ನಿಂದ ಮೂರು ಡೆವಲಪರ್‌ಗಳು, ಮೂರು ಸಿಸ್ಟಮ್ ವಿಶ್ಲೇಷಕರು, ಪರಿಹಾರ ವಾಸ್ತುಶಿಲ್ಪಿ, ಉತ್ಪನ್ನ ಮಾಲೀಕರು ಮತ್ತು ಸ್ಕ್ರಮ್ ಮಾಸ್ಟರ್ ಇದ್ದರು.
ನಮ್ಮ ವ್ಯವಸ್ಥೆಯು ಹೇಗೆ ಬೆಳೆಯಿತು, ಅದು ಹೇಗೆ ವಿಕಸನಗೊಂಡಿತು, ನಾವು ಏನು ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಏಕೆ ನಿಖರವಾಗಿ ಇದನ್ನು ಕುರಿತು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.
ಅಭಿವೃದ್ಧಿ
ನಮ್ಮ ಪ್ರಸ್ತುತ ಸಿಸ್ಟಮ್‌ಗಳಿಂದ ಡೇಟಾವನ್ನು ಹೇಗೆ ಪಡೆಯುವುದು ಎಂಬುದೇ ನಾವು ಕೇಳಿಕೊಂಡ ಮೊದಲ ಪ್ರಶ್ನೆ. HTTP ನಮಗೆ ಸಾಕಷ್ಟು ಸೂಕ್ತವಾಗಿದೆ ಎಂದು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ, ಏಕೆಂದರೆ ಎಲ್ಲಾ ಪ್ರಸ್ತುತ ಸಿಸ್ಟಮ್‌ಗಳು HTTP ಮೂಲಕ XML ಅಥವಾ JSON ಅನ್ನು ಕಳುಹಿಸುವ ಮೂಲಕ ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸುತ್ತವೆ.
ನಾವು SSL ಸೆಷನ್‌ಗಳನ್ನು ಅಂತ್ಯಗೊಳಿಸುವ ಅಗತ್ಯವಿಲ್ಲದ ಕಾರಣ ಟಾರಂಟೂಲ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ HTTP ಸರ್ವರ್ ಅನ್ನು ನಾವು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ಅದರ ಕಾರ್ಯಕ್ಷಮತೆ ನಮಗೆ ಸಾಕಾಗುತ್ತದೆ.
ನಾನು ಈಗಾಗಲೇ ಹೇಳಿದಂತೆ, ನಮ್ಮ ಎಲ್ಲಾ ಸಿಸ್ಟಮ್‌ಗಳು ವಿಭಿನ್ನ ಡೇಟಾ ಮಾದರಿಗಳಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ ಮತ್ತು ಇನ್‌ಪುಟ್‌ನಲ್ಲಿ ನಾವು ವಸ್ತುವನ್ನು ನಾವೇ ವಿವರಿಸುವ ಮಾದರಿಗೆ ತರಬೇಕಾಗಿದೆ. ಡೇಟಾ ರೂಪಾಂತರಗೊಳ್ಳಲು ಅನುಮತಿಸುವ ಭಾಷೆಯ ಅಗತ್ಯವಿದೆ. ನಾವು ಕಡ್ಡಾಯವಾದ ಲುವಾವನ್ನು ಆರಿಸಿದ್ದೇವೆ. ನಾವು ಎಲ್ಲಾ ಡೇಟಾ ಪರಿವರ್ತನೆ ಕೋಡ್ ಅನ್ನು ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ರನ್ ಮಾಡುತ್ತೇವೆ - ಇದು ಸುರಕ್ಷಿತ ಸ್ಥಳವಾಗಿದ್ದು, ಚಾಲನೆಯಲ್ಲಿರುವ ಕೋಡ್ ಹೋಗುವುದಿಲ್ಲ. ಇದನ್ನು ಮಾಡಲು, ನಾವು ಅಗತ್ಯವಿರುವ ಕೋಡ್ ಅನ್ನು ಸರಳವಾಗಿ ಲೋಡ್ ಮಾಡುತ್ತೇವೆ, ಯಾವುದನ್ನೂ ನಿರ್ಬಂಧಿಸಲು ಅಥವಾ ಬಿಡಲು ಸಾಧ್ಯವಾಗದ ಕಾರ್ಯಗಳೊಂದಿಗೆ ಪರಿಸರವನ್ನು ರಚಿಸುತ್ತೇವೆ.
ಪರಿವರ್ತನೆಯ ನಂತರ, ನಾವು ರಚಿಸುತ್ತಿರುವ ಮಾದರಿಯ ಅನುಸರಣೆಗಾಗಿ ಡೇಟಾವನ್ನು ಪರಿಶೀಲಿಸಬೇಕು. ಮಾದರಿ ಹೇಗಿರಬೇಕು ಮತ್ತು ಅದನ್ನು ವಿವರಿಸಲು ಯಾವ ಭಾಷೆ ಬಳಸಬೇಕು ಎಂದು ನಾವು ದೀರ್ಘಕಾಲ ಚರ್ಚಿಸಿದ್ದೇವೆ. ನಾವು Apache Avro ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ ಏಕೆಂದರೆ ಭಾಷೆ ಸರಳವಾಗಿದೆ ಮತ್ತು ಇದು Tarantool ನಿಂದ ಬೆಂಬಲವನ್ನು ಹೊಂದಿದೆ. ಮಾದರಿ ಮತ್ತು ಕಸ್ಟಮ್ ಕೋಡ್‌ನ ಹೊಸ ಆವೃತ್ತಿಗಳನ್ನು ದಿನಕ್ಕೆ ಹಲವಾರು ಬಾರಿ ಕಾರ್ಯಾಚರಣೆಗೆ ಒಳಪಡಿಸಬಹುದು, ಲೋಡ್‌ನಲ್ಲಿ ಅಥವಾ ಇಲ್ಲದೆಯೇ, ದಿನದ ಯಾವುದೇ ಸಮಯದಲ್ಲಿ, ಮತ್ತು ಬದಲಾವಣೆಗಳಿಗೆ ತ್ವರಿತವಾಗಿ ಹೊಂದಿಕೊಳ್ಳಬಹುದು.
ಪರಿಶೀಲನೆಯ ನಂತರ, ಡೇಟಾವನ್ನು ಉಳಿಸಬೇಕು. ನಾವು ಇದನ್ನು ವಿಶಾರ್ಡ್ ಬಳಸಿ ಮಾಡುತ್ತೇವೆ (ನಾವು ಚೂರುಗಳ ಜಿಯೋ-ಚದುರಿದ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ).
ಇದಲ್ಲದೆ, ನಿರ್ದಿಷ್ಟತೆಯು ನಮಗೆ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುವ ಹೆಚ್ಚಿನ ವ್ಯವಸ್ಥೆಗಳು ನಾವು ಅದನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದನ್ನು ಕಾಳಜಿ ವಹಿಸುವುದಿಲ್ಲ. ಅದಕ್ಕಾಗಿಯೇ ನಾವು ಮೊದಲಿನಿಂದಲೂ ದುರಸ್ತಿ ಸರತಿಯನ್ನು ಜಾರಿಗೆ ತಂದಿದ್ದೇವೆ. ಅದು ಏನು? ಕೆಲವು ಕಾರಣಕ್ಕಾಗಿ ವಸ್ತುವು ಡೇಟಾ ರೂಪಾಂತರ ಅಥವಾ ಪರಿಶೀಲನೆಗೆ ಒಳಗಾಗದಿದ್ದರೆ, ನಾವು ಇನ್ನೂ ರಶೀದಿಯನ್ನು ದೃಢೀಕರಿಸುತ್ತೇವೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ದುರಸ್ತಿ ಸರದಿಯಲ್ಲಿ ವಸ್ತುವನ್ನು ಉಳಿಸಿ. ಇದು ಸ್ಥಿರವಾಗಿದೆ ಮತ್ತು ಮುಖ್ಯ ವ್ಯಾಪಾರ ಡೇಟಾ ಗೋದಾಮಿನಲ್ಲಿದೆ. ನಾವು ತಕ್ಷಣವೇ ಅದಕ್ಕೆ ನಿರ್ವಾಹಕರ ಇಂಟರ್ಫೇಸ್, ವಿವಿಧ ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಎಚ್ಚರಿಕೆಗಳನ್ನು ಬರೆದಿದ್ದೇವೆ. ಪರಿಣಾಮವಾಗಿ, ನಾವು ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದಿಲ್ಲ. ಮೂಲದಲ್ಲಿ ಏನಾದರೂ ಬದಲಾಗಿದ್ದರೂ, ಡೇಟಾ ಮಾದರಿ ಬದಲಾಗಿದ್ದರೆ, ನಾವು ಅದನ್ನು ತಕ್ಷಣವೇ ಪತ್ತೆ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಹೊಂದಿಕೊಳ್ಳಬಹುದು.
ಉಳಿಸಿದ ಡೇಟಾವನ್ನು ಹಿಂಪಡೆಯುವುದು ಹೇಗೆ ಎಂದು ಈಗ ನೀವು ಕಲಿಯಬೇಕಾಗಿದೆ. ನಾವು ನಮ್ಮ ಸಿಸ್ಟಂಗಳನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ವಿಶ್ಲೇಷಿಸಿದ್ದೇವೆ ಮತ್ತು ಜಾವಾ ಮತ್ತು ಒರಾಕಲ್‌ನ ಕ್ಲಾಸಿಕ್ ಸ್ಟಾಕ್ ಅಗತ್ಯವಾಗಿ ಕೆಲವು ರೀತಿಯ ORM ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಎಂದು ನೋಡಿದ್ದೇವೆ ಅದು ಡೇಟಾವನ್ನು ಸಂಬಂಧದಿಂದ ವಸ್ತುವಿಗೆ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಹಾಗಾದರೆ ಗ್ರಾಫ್ ರೂಪದಲ್ಲಿ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ವಸ್ತುಗಳನ್ನು ತಕ್ಷಣವೇ ಏಕೆ ನೀಡಬಾರದು? ಆದ್ದರಿಂದ ನಾವು ಸಂತೋಷದಿಂದ ನಮ್ಮ ಎಲ್ಲಾ ಅಗತ್ಯಗಳನ್ನು ಪೂರೈಸುವ GraphQL ಅನ್ನು ಅಳವಡಿಸಿಕೊಂಡಿದ್ದೇವೆ. ಗ್ರಾಫ್‌ಗಳ ರೂಪದಲ್ಲಿ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಲು ಮತ್ತು ಇದೀಗ ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ಮಾತ್ರ ಹೊರತೆಗೆಯಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ನೀವು ಸಾಕಷ್ಟು ನಮ್ಯತೆಯೊಂದಿಗೆ API ಅನ್ನು ಸಹ ಆವೃತ್ತಿ ಮಾಡಬಹುದು.
ನಾವು ಹೊರತೆಗೆಯುತ್ತಿರುವ ಡೇಟಾವು ಸಾಕಾಗುವುದಿಲ್ಲ ಎಂದು ತಕ್ಷಣವೇ ನಾವು ಅರಿತುಕೊಂಡೆವು. ಮಾದರಿಯಲ್ಲಿನ ವಸ್ತುಗಳಿಗೆ ಲಿಂಕ್ ಮಾಡಬಹುದಾದ ಕಾರ್ಯಗಳನ್ನು ನಾವು ರಚಿಸಿದ್ದೇವೆ - ಮೂಲಭೂತವಾಗಿ, ಲೆಕ್ಕಾಚಾರದ ಕ್ಷೇತ್ರಗಳು. ಅಂದರೆ, ನಾವು ಕ್ಷೇತ್ರಕ್ಕೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯವನ್ನು ಲಗತ್ತಿಸುತ್ತೇವೆ, ಉದಾಹರಣೆಗೆ, ಸರಾಸರಿ ಉಲ್ಲೇಖ ಬೆಲೆಯನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ. ಮತ್ತು ಡೇಟಾವನ್ನು ವಿನಂತಿಸುವ ಬಾಹ್ಯ ಗ್ರಾಹಕನಿಗೆ ಇದು ಲೆಕ್ಕ ಹಾಕಿದ ಕ್ಷೇತ್ರ ಎಂದು ತಿಳಿದಿರುವುದಿಲ್ಲ.
ದೃಢೀಕರಣ ವ್ಯವಸ್ಥೆಯನ್ನು ಅಳವಡಿಸಲಾಗಿದೆ.
ನಂತರ ನಮ್ಮ ನಿರ್ಧಾರದಲ್ಲಿ ಹಲವಾರು ಪಾತ್ರಗಳು ಹರಳುಗಟ್ಟಿರುವುದನ್ನು ನಾವು ಗಮನಿಸಿದ್ದೇವೆ. ಪಾತ್ರವು ಕಾರ್ಯಗಳ ಒಂದು ರೀತಿಯ ಸಂಗ್ರಾಹಕವಾಗಿದೆ. ವಿಶಿಷ್ಟವಾಗಿ, ಪಾತ್ರಗಳು ವಿಭಿನ್ನ ಸಾಧನ ಬಳಕೆಯ ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು ಹೊಂದಿವೆ:
- ಟಿ-ಕನೆಕ್ಟ್: ಒಳಬರುವ ಸಂಪರ್ಕಗಳನ್ನು ನಿಭಾಯಿಸುತ್ತದೆ, CPU ಸೀಮಿತ, ಕಡಿಮೆ ಮೆಮೊರಿ ಬಳಕೆ, ಸ್ಥಿತಿಯಿಲ್ಲ.
- IB-ಕೋರ್: Tarantool ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಸ್ವೀಕರಿಸುವ ಡೇಟಾವನ್ನು ರೂಪಾಂತರಗೊಳಿಸುತ್ತದೆ, ಅಂದರೆ, ಇದು ಕೋಷ್ಟಕಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು ಸ್ಥಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುವುದಿಲ್ಲ ಮತ್ತು ಸ್ಕೇಲೆಬಲ್ ಆಗಿದೆ.
- ಸಂಗ್ರಹಣೆ: ಡೇಟಾವನ್ನು ಮಾತ್ರ ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಯಾವುದೇ ತರ್ಕವನ್ನು ಬಳಸುವುದಿಲ್ಲ. ಈ ಪಾತ್ರವು ಸರಳವಾದ ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. vshard ಗೆ ಸ್ಕೇಲೆಬಲ್ ಧನ್ಯವಾದಗಳು.
ಅಂದರೆ, ಪಾತ್ರಗಳನ್ನು ಬಳಸಿ, ನಾವು ಕ್ಲಸ್ಟರ್‌ನ ವಿವಿಧ ಭಾಗಗಳನ್ನು ಪರಸ್ಪರ ಬೇರ್ಪಡಿಸುತ್ತೇವೆ, ಅದನ್ನು ಪರಸ್ಪರ ಸ್ವತಂತ್ರವಾಗಿ ಅಳೆಯಬಹುದು.
ಆದ್ದರಿಂದ, ನಾವು ಅಸಮಕಾಲಿಕ ವಹಿವಾಟಿನ ಡೇಟಾ ಹರಿವು ರೆಕಾರ್ಡಿಂಗ್ ಮತ್ತು ನಿರ್ವಾಹಕ ಇಂಟರ್ಫೇಸ್ನೊಂದಿಗೆ ದುರಸ್ತಿ ಸರತಿಯನ್ನು ರಚಿಸಿದ್ದೇವೆ. ವ್ಯಾಪಾರದ ದೃಷ್ಟಿಕೋನದಿಂದ ರೆಕಾರ್ಡಿಂಗ್ ಅಸಮಕಾಲಿಕವಾಗಿದೆ: ನಮಗೆ ಡೇಟಾವನ್ನು ಬರೆಯುವ ಭರವಸೆ ಇದ್ದರೆ, ಎಲ್ಲಿಯಾದರೂ, ನಾವು ಅದನ್ನು ದೃಢೀಕರಿಸುತ್ತೇವೆ. ಅದನ್ನು ದೃಢೀಕರಿಸದಿದ್ದರೆ, ಏನೋ ತಪ್ಪಾಗಿದೆ ಮತ್ತು ಡೇಟಾವನ್ನು ಕಳುಹಿಸಬೇಕಾಗಿದೆ. ಇದು ಅಸಮಕಾಲಿಕ ರೆಕಾರ್ಡಿಂಗ್ ಆಗಿದೆ.
ಪರೀಕ್ಷೆ
ಯೋಜನೆಯ ಪ್ರಾರಂಭದಿಂದಲೂ, ನಾವು ಪರೀಕ್ಷಾ ಚಾಲಿತ ಅಭಿವೃದ್ಧಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ ಎಂದು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ನಾವು ಟ್ಯಾರಂಟೂಲ್/ಟ್ಯಾಪ್ ಫ್ರೇಮ್‌ವರ್ಕ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಲುವಾದಲ್ಲಿ ಘಟಕ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯುತ್ತೇವೆ ಮತ್ತು ಪೈಟೆಸ್ಟ್ ಫ್ರೇಮ್‌ವರ್ಕ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಪೈಥಾನ್‌ನಲ್ಲಿ ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯುತ್ತೇವೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ನಾವು ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯುವಲ್ಲಿ ಡೆವಲಪರ್‌ಗಳು ಮತ್ತು ವಿಶ್ಲೇಷಕರನ್ನು ಒಳಗೊಳ್ಳುತ್ತೇವೆ.
ಪರೀಕ್ಷಾ ಚಾಲಿತ ಅಭಿವೃದ್ಧಿಯನ್ನು ನಾವು ಹೇಗೆ ಬಳಸುತ್ತೇವೆ?
ನಾವು ಕೆಲವು ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬಯಸಿದರೆ, ನಾವು ಮೊದಲು ಪರೀಕ್ಷೆಯನ್ನು ಬರೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ನಾವು ದೋಷವನ್ನು ಕಂಡುಕೊಂಡಾಗ, ನಾವು ಮೊದಲು ಪರೀಕ್ಷೆಯನ್ನು ಬರೆಯುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ನಂತರ ಮಾತ್ರ ಅದನ್ನು ಸರಿಪಡಿಸುತ್ತೇವೆ. ಮೊದಲಿಗೆ ಈ ರೀತಿ ಕೆಲಸ ಮಾಡುವುದು ಕಷ್ಟ, ಉದ್ಯೋಗಿಗಳ ಕಡೆಯಿಂದ ತಪ್ಪು ತಿಳುವಳಿಕೆ ಇದೆ, ವಿಧ್ವಂಸಕತೆಯೂ ಇದೆ: "ಈಗ ಅದನ್ನು ತ್ವರಿತವಾಗಿ ಸರಿಪಡಿಸೋಣ, ಹೊಸದನ್ನು ಮಾಡೋಣ, ತದನಂತರ ಅದನ್ನು ಪರೀಕ್ಷೆಗಳೊಂದಿಗೆ ಒಳಗೊಳ್ಳೋಣ." ಈ "ನಂತರ" ಮಾತ್ರ ಎಂದಿಗೂ ಬರುವುದಿಲ್ಲ.
ಆದ್ದರಿಂದ, ನೀವು ಮೊದಲು ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಲು ನಿಮ್ಮನ್ನು ಒತ್ತಾಯಿಸಬೇಕು ಮತ್ತು ಅದನ್ನು ಮಾಡಲು ಇತರರನ್ನು ಕೇಳಿಕೊಳ್ಳಿ. ನನ್ನನ್ನು ನಂಬಿರಿ, ಪರೀಕ್ಷಾ ಚಾಲಿತ ಅಭಿವೃದ್ಧಿಯು ಅಲ್ಪಾವಧಿಯಲ್ಲಿಯೂ ಸಹ ಪ್ರಯೋಜನಗಳನ್ನು ತರುತ್ತದೆ. ನಿಮ್ಮ ಜೀವನವು ಸುಲಭವಾಗಿದೆ ಎಂದು ನೀವು ಭಾವಿಸುವಿರಿ. 99% ಕೋಡ್ ಈಗ ಪರೀಕ್ಷೆಗಳಿಂದ ಆವರಿಸಲ್ಪಟ್ಟಿದೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ. ಇದು ಬಹಳಷ್ಟು ತೋರುತ್ತದೆ, ಆದರೆ ನಮಗೆ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲ: ಪ್ರತಿ ಬದ್ಧತೆಯಲ್ಲೂ ಪರೀಕ್ಷೆಗಳು ನಡೆಯುತ್ತವೆ.
ಆದಾಗ್ಯೂ, ನಾವು ಹೆಚ್ಚು ಇಷ್ಟಪಡುವದು ಲೋಡ್ ಪರೀಕ್ಷೆ; ನಾವು ಅದನ್ನು ಅತ್ಯಂತ ಮುಖ್ಯವೆಂದು ಪರಿಗಣಿಸುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ನಿಯಮಿತವಾಗಿ ನಿರ್ವಹಿಸುತ್ತೇವೆ.
ಮೊದಲ ಆವೃತ್ತಿಗಳಲ್ಲಿ ಒಂದಾದ ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಮೊದಲ ಹಂತವನ್ನು ನಾವು ಹೇಗೆ ನಡೆಸಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು ನಾನು ನಿಮಗೆ ಸ್ವಲ್ಪ ಕಥೆಯನ್ನು ಹೇಳುತ್ತೇನೆ. ನಾವು ಡೆವಲಪರ್ನ ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದ್ದೇವೆ, ಲೋಡ್ ಅನ್ನು ಆನ್ ಮಾಡಿ ಮತ್ತು ಸೆಕೆಂಡಿಗೆ 4 ಸಾವಿರ ವಹಿವಾಟುಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ. ಲ್ಯಾಪ್‌ಟಾಪ್‌ಗೆ ಉತ್ತಮ ಫಲಿತಾಂಶ. ನಾವು ಅದನ್ನು ನಾಲ್ಕು ಸರ್ವರ್‌ಗಳ ವರ್ಚುವಲ್ ಲೋಡ್ ಬೆಂಚ್‌ನಲ್ಲಿ ಸ್ಥಾಪಿಸಿದ್ದೇವೆ, ಉತ್ಪಾದನೆಗಿಂತ ದುರ್ಬಲವಾಗಿದೆ. ಕನಿಷ್ಠಕ್ಕೆ ನಿಯೋಜಿಸಲಾಗಿದೆ. ನಾವು ಅದನ್ನು ಓಡಿಸುತ್ತೇವೆ ಮತ್ತು ಒಂದು ಥ್ರೆಡ್ನಲ್ಲಿ ಲ್ಯಾಪ್ಟಾಪ್ಗಿಂತ ಕೆಟ್ಟ ಫಲಿತಾಂಶವನ್ನು ನಾವು ಪಡೆಯುತ್ತೇವೆ. ಆಘಾತ ವಿಷಯ.
ನಮಗೆ ತುಂಬಾ ದುಃಖವಾಯಿತು. ನಾವು ಸರ್ವರ್ ಲೋಡ್ ಅನ್ನು ನೋಡುತ್ತೇವೆ, ಆದರೆ ಅವು ನಿಷ್ಕ್ರಿಯವಾಗಿವೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ.
ನಾವು ಡೆವಲಪರ್‌ಗಳನ್ನು ಕರೆಯುತ್ತೇವೆ ಮತ್ತು ಅವರು ನಮಗೆ ವಿವರಿಸುತ್ತಾರೆ, ಜಾವಾ ಪ್ರಪಂಚದಿಂದ ಬಂದ ಜನರು, ಟ್ಯಾರಂಟೂಲ್ ಏಕ-ಥ್ರೆಡ್ ಆಗಿದೆ. ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಒಂದು ಪ್ರೊಸೆಸರ್ ಕೋರ್ನಿಂದ ಮಾತ್ರ ಇದನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬಳಸಬಹುದು. ನಂತರ ನಾವು ಪ್ರತಿ ಸರ್ವರ್‌ನಲ್ಲಿ ಗರಿಷ್ಠ ಸಂಭವನೀಯ ಸಂಖ್ಯೆಯ ಟ್ಯಾರಂಟೂಲ್ ನಿದರ್ಶನಗಳನ್ನು ನಿಯೋಜಿಸಿದ್ದೇವೆ, ಲೋಡ್ ಅನ್ನು ಆನ್ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಈಗಾಗಲೇ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 14,5 ಸಾವಿರ ವಹಿವಾಟುಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ.
ಮತ್ತೊಮ್ಮೆ ವಿವರಿಸುತ್ತೇನೆ. ಸಂಪನ್ಮೂಲಗಳನ್ನು ವಿಭಿನ್ನವಾಗಿ ಬಳಸುವ ಪಾತ್ರಗಳಾಗಿ ವಿಭಜಿಸುವುದರಿಂದ, ಸಂಪರ್ಕಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಮತ್ತು ಡೇಟಾ ರೂಪಾಂತರಕ್ಕೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ನಮ್ಮ ಪಾತ್ರಗಳು ಪ್ರೊಸೆಸರ್ ಅನ್ನು ಮಾತ್ರ ಲೋಡ್ ಮಾಡುತ್ತವೆ ಮತ್ತು ಲೋಡ್‌ಗೆ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಅನುಪಾತದಲ್ಲಿರುತ್ತವೆ.
ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಒಳಬರುವ ಸಂಪರ್ಕಗಳು ಮತ್ತು ತಾತ್ಕಾಲಿಕ ವಸ್ತುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಮಾತ್ರ ಮೆಮೊರಿಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.
ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಶೇಖರಣಾ ಸರ್ವರ್‌ಗಳಲ್ಲಿ, ಪ್ರೊಸೆಸರ್ ಲೋಡ್ ಹೆಚ್ಚಾಯಿತು, ಆದರೆ ಸಂಪರ್ಕಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಸರ್ವರ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು ನಿಧಾನವಾಗಿದೆ.
ಮತ್ತು ಮೆಮೊರಿ ಬಳಕೆ ಲೋಡ್ ಮಾಡಿದ ಡೇಟಾದ ಪ್ರಮಾಣಕ್ಕೆ ನೇರ ಅನುಪಾತದಲ್ಲಿ ಬೆಳೆಯಿತು.
ಸೇವೆಗಳು
ನಮ್ಮ ಹೊಸ ಉತ್ಪನ್ನವನ್ನು ನಿರ್ದಿಷ್ಟವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಂತೆ ಅಭಿವೃದ್ಧಿಪಡಿಸಲು, ಅದರ ಮೇಲೆ ಸೇವೆಗಳು ಮತ್ತು ಲೈಬ್ರರಿಗಳನ್ನು ನಿಯೋಜಿಸಲು ನಾವು ಒಂದು ಘಟಕವನ್ನು ರಚಿಸಿದ್ದೇವೆ.
ಸೇವೆಗಳು ಕೆಲವು ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಕೋಡ್‌ನ ಸಣ್ಣ ತುಣುಕುಗಳಲ್ಲ. ಅವು ಕ್ಲಸ್ಟರ್‌ನ ಭಾಗವಾಗಿರುವ ಸಾಕಷ್ಟು ದೊಡ್ಡ ಮತ್ತು ಸಂಕೀರ್ಣ ರಚನೆಗಳಾಗಿರಬಹುದು, ಉಲ್ಲೇಖ ಡೇಟಾವನ್ನು ಪರಿಶೀಲಿಸಿ, ವ್ಯವಹಾರ ತರ್ಕವನ್ನು ಚಲಾಯಿಸಿ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು. ನಾವು ಸೇವಾ ಸ್ಕೀಮಾವನ್ನು GraphQL ಗೆ ರಫ್ತು ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಗ್ರಾಹಕರು ಸಂಪೂರ್ಣ ಮಾದರಿಯಾದ್ಯಂತ ಆತ್ಮಾವಲೋಕನದೊಂದಿಗೆ ಡೇಟಾಗೆ ಸಾರ್ವತ್ರಿಕ ಪ್ರವೇಶ ಬಿಂದುವನ್ನು ಪಡೆಯುತ್ತಾರೆ. ಇದು ತುಂಬಾ ಆರಾಮದಾಯಕವಾಗಿದೆ.
ಸೇವೆಗಳು ಹೆಚ್ಚಿನ ಕಾರ್ಯಗಳನ್ನು ಒಳಗೊಂಡಿರುವುದರಿಂದ, ನಾವು ಆಗಾಗ್ಗೆ ಬಳಸಿದ ಕೋಡ್ ಅನ್ನು ಚಲಿಸುವ ಲೈಬ್ರರಿಗಳು ಇರಬೇಕೆಂದು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ನಾವು ಅವುಗಳನ್ನು ಸುರಕ್ಷಿತ ಪರಿಸರಕ್ಕೆ ಸೇರಿಸಿದ್ದೇವೆ, ಅದು ನಮಗೆ ಏನನ್ನೂ ಮುರಿಯುವುದಿಲ್ಲ ಎಂದು ಹಿಂದೆ ಪರಿಶೀಲಿಸಿದ್ದೇವೆ. ಮತ್ತು ಈಗ ನಾವು ಲೈಬ್ರರಿಗಳ ರೂಪದಲ್ಲಿ ಕಾರ್ಯಗಳಿಗೆ ಹೆಚ್ಚುವರಿ ಪರಿಸರಗಳನ್ನು ನಿಯೋಜಿಸಬಹುದು.
ಶೇಖರಣೆಗಾಗಿ ಮಾತ್ರವಲ್ಲ, ಕಂಪ್ಯೂಟಿಂಗ್‌ಗೂ ವೇದಿಕೆಯನ್ನು ಹೊಂದಲು ನಾವು ಬಯಸಿದ್ದೇವೆ. ಮತ್ತು ನಾವು ಈಗಾಗಲೇ ಪ್ರತಿಕೃತಿಗಳು ಮತ್ತು ಚೂರುಗಳ ಗುಂಪನ್ನು ಹೊಂದಿರುವುದರಿಂದ, ನಾವು ಒಂದು ರೀತಿಯ ವಿತರಿಸಿದ ಕಂಪ್ಯೂಟಿಂಗ್ ಅನ್ನು ಅಳವಡಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ನಕ್ಷೆ ಕಡಿತ ಎಂದು ಕರೆಯುತ್ತೇವೆ, ಏಕೆಂದರೆ ಇದು ಮೂಲ ನಕ್ಷೆಯ ಕಡಿತಕ್ಕೆ ಹೋಲುತ್ತದೆ.
ಹಳೆಯ ವ್ಯವಸ್ಥೆಗಳು
ನಮ್ಮ ಎಲ್ಲಾ ಲೆಗಸಿ ಸಿಸ್ಟಮ್‌ಗಳು ನಮಗೆ HTTP ಮೂಲಕ ಕರೆ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಮತ್ತು GraphQL ಅನ್ನು ಬಳಸುತ್ತವೆ, ಆದರೂ ಅವು ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತವೆ. ಆದ್ದರಿಂದ, ಈ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ಪುನರಾವರ್ತಿಸಲು ಅನುಮತಿಸುವ ಕಾರ್ಯವಿಧಾನವನ್ನು ನಾವು ರಚಿಸಿದ್ದೇವೆ.
ನಮಗಾಗಿ ಏನಾದರೂ ಬದಲಾವಣೆಯಾದರೆ, ಶೇಖರಣಾ ಪಾತ್ರದಲ್ಲಿ ಅನನ್ಯ ಟ್ರಿಗ್ಗರ್‌ಗಳನ್ನು ಪ್ರಚೋದಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ಸಂದೇಶವು ಪ್ರಕ್ರಿಯೆಯ ಸರದಿಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ. ಪ್ರತ್ಯೇಕ ರೆಪ್ಲಿಕೇಟರ್ ಪಾತ್ರವನ್ನು ಬಳಸಿಕೊಂಡು ಇದನ್ನು ಬಾಹ್ಯ ವ್ಯವಸ್ಥೆಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಈ ಪಾತ್ರವು ಸ್ಥಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುವುದಿಲ್ಲ.
ಹೊಸ ಸುಧಾರಣೆಗಳು
ನಿಮಗೆ ನೆನಪಿರುವಂತೆ, ವ್ಯವಹಾರದ ದೃಷ್ಟಿಕೋನದಿಂದ, ನಾವು ಅಸಮಕಾಲಿಕ ರೆಕಾರ್ಡಿಂಗ್ ಮಾಡಿದ್ದೇವೆ. ಆದರೆ ನಂತರ ಅದು ಸಾಕಾಗುವುದಿಲ್ಲ ಎಂದು ಅವರು ಅರಿತುಕೊಂಡರು, ಏಕೆಂದರೆ ಕಾರ್ಯಾಚರಣೆಯ ಸ್ಥಿತಿಯ ಬಗ್ಗೆ ತಕ್ಷಣವೇ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯಬೇಕಾದ ವ್ಯವಸ್ಥೆಗಳ ವರ್ಗವಿದೆ. ಆದ್ದರಿಂದ ನಾವು ನಮ್ಮ GraphQL ಅನ್ನು ವಿಸ್ತರಿಸಿದ್ದೇವೆ ಮತ್ತು ರೂಪಾಂತರಗಳನ್ನು ಸೇರಿಸಿದ್ದೇವೆ. ಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮಾದರಿಗೆ ಅವು ಸಾವಯವವಾಗಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ. ನಮಗೆ, ಇದು ಮತ್ತೊಂದು ವರ್ಗದ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಓದುವ ಮತ್ತು ಬರೆಯುವ ಎರಡರ ಒಂದೇ ಅಂಶವಾಗಿದೆ.
ಸೇವೆಗಳು ಮಾತ್ರ ನಮಗೆ ಸಾಕಾಗುವುದಿಲ್ಲ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ, ಏಕೆಂದರೆ ದಿನಕ್ಕೊಮ್ಮೆ, ವಾರಕ್ಕೊಮ್ಮೆ, ತಿಂಗಳಿಗೊಮ್ಮೆ ನಿರ್ಮಿಸಬೇಕಾದ ಸಾಕಷ್ಟು ಭಾರೀ ವರದಿಗಳಿವೆ. ಇದು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಮತ್ತು ವರದಿಗಳು Tarantool ನ ಈವೆಂಟ್ ಲೂಪ್ ಅನ್ನು ಸಹ ನಿರ್ಬಂಧಿಸಬಹುದು. ಆದ್ದರಿಂದ, ನಾವು ಪ್ರತ್ಯೇಕ ಪಾತ್ರಗಳನ್ನು ರಚಿಸಿದ್ದೇವೆ: ಶೆಡ್ಯೂಲರ್ ಮತ್ತು ರನ್ನರ್. ಓಟಗಾರರು ರಾಜ್ಯವನ್ನು ಸಂಗ್ರಹಿಸುವುದಿಲ್ಲ. ನಾವು ಹಾರಾಡುತ್ತ ಲೆಕ್ಕಹಾಕಲು ಸಾಧ್ಯವಾಗದಂತಹ ಭಾರೀ ಕಾರ್ಯಗಳನ್ನು ಅವರು ನಡೆಸುತ್ತಾರೆ. ಮತ್ತು ಶೆಡ್ಯೂಲರ್ ಪಾತ್ರವು ಈ ಕಾರ್ಯಗಳ ಉಡಾವಣಾ ವೇಳಾಪಟ್ಟಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತದೆ, ಇದನ್ನು ಸಂರಚನೆಯಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ. ಕಾರ್ಯಗಳನ್ನು ವ್ಯವಹಾರ ಡೇಟಾದಂತೆಯೇ ಅದೇ ಸ್ಥಳದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಸರಿಯಾದ ಸಮಯ ಬಂದಾಗ, ಶೆಡ್ಯೂಲರ್ ಕಾರ್ಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾನೆ, ಅದನ್ನು ಕೆಲವು ಓಟಗಾರರಿಗೆ ನೀಡುತ್ತಾನೆ, ಅವರು ಅದನ್ನು ಎಣಿಸುತ್ತಾರೆ ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಉಳಿಸುತ್ತಾರೆ.
ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ವೇಳಾಪಟ್ಟಿಯಲ್ಲಿ ನಡೆಸಬೇಕಾಗಿಲ್ಲ. ಕೆಲವು ವರದಿಗಳನ್ನು ಬೇಡಿಕೆಯ ಮೇರೆಗೆ ಓದಬೇಕು. ಈ ಅವಶ್ಯಕತೆಯು ಬಂದ ತಕ್ಷಣ, ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಕಾರ್ಯವನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಮರಣದಂಡನೆಗಾಗಿ ರನ್ನರ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ, ಎಲ್ಲವನ್ನೂ ಲೆಕ್ಕಹಾಕಲಾಗಿದೆ ಮತ್ತು ವರದಿ ಸಿದ್ಧವಾಗಿದೆ ಎಂದು ಬಳಕೆದಾರರು ಅಸಮಕಾಲಿಕ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ.
ಆರಂಭದಲ್ಲಿ, ನಾವು ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವ ಮಾದರಿಗೆ ಬದ್ಧರಾಗಿದ್ದೇವೆ, ಅದರ ಆವೃತ್ತಿ ಮತ್ತು ಅದನ್ನು ಅಳಿಸುವುದಿಲ್ಲ. ಆದರೆ ಜೀವನದಲ್ಲಿ, ಕಾಲಕಾಲಕ್ಕೆ ನೀವು ಇನ್ನೂ ಏನನ್ನಾದರೂ ಅಳಿಸಬೇಕಾಗುತ್ತದೆ, ಹೆಚ್ಚಾಗಿ ಕೆಲವು ಕಚ್ಚಾ ಅಥವಾ ಮಧ್ಯಂತರ ಮಾಹಿತಿ. ಅವಧಿ ಮೀರಿದ ಆಧಾರದ ಮೇಲೆ, ಹಳೆಯ ಡೇಟಾದಿಂದ ಸಂಗ್ರಹಣೆಯನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಲು ನಾವು ಕಾರ್ಯವಿಧಾನವನ್ನು ರಚಿಸಿದ್ದೇವೆ.
ಮೆಮೊರಿಯಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಾಕಷ್ಟು ಸ್ಥಳಾವಕಾಶವಿಲ್ಲದಿರುವಾಗ ಬೇಗ ಅಥವಾ ನಂತರ ಪರಿಸ್ಥಿತಿ ಬರುತ್ತದೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ, ಆದರೆ ಆದಾಗ್ಯೂ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಬೇಕು. ಈ ಉದ್ದೇಶಗಳಿಗಾಗಿ, ನಾವು ಶೀಘ್ರದಲ್ಲೇ ಡಿಸ್ಕ್ ಸಂಗ್ರಹಣೆಯನ್ನು ಮಾಡುತ್ತೇವೆ.
ತೀರ್ಮಾನಕ್ಕೆ
ನಾವು ಡೇಟಾವನ್ನು ಒಂದೇ ಮಾದರಿಯಲ್ಲಿ ಲೋಡ್ ಮಾಡುವ ಕಾರ್ಯವನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಮೂರು ತಿಂಗಳುಗಳನ್ನು ಕಳೆದಿದ್ದೇವೆ. ನಾವು ಆರು ಡೇಟಾ ಪೂರೈಕೆ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಒಂದೇ ಮಾದರಿಯಲ್ಲಿ ಸಂಪೂರ್ಣ ರೂಪಾಂತರ ಕೋಡ್ ಲುವಾದಲ್ಲಿ ಸುಮಾರು 30 ಸಾವಿರ ಸಾಲುಗಳನ್ನು ಹೊಂದಿದೆ. ಮತ್ತು ಹೆಚ್ಚಿನ ಕೆಲಸಗಳು ಇನ್ನೂ ಮುಂದಿವೆ. ಕೆಲವೊಮ್ಮೆ ನೆರೆಯ ತಂಡಗಳಿಂದ ಪ್ರೇರಣೆಯ ಕೊರತೆಯಿದೆ, ಮತ್ತು ಕೆಲಸವನ್ನು ಸಂಕೀರ್ಣಗೊಳಿಸುವ ಅನೇಕ ಸಂದರ್ಭಗಳಿವೆ. ನೀವು ಎಂದಾದರೂ ಇದೇ ರೀತಿಯ ಕೆಲಸವನ್ನು ಎದುರಿಸಿದರೆ, ಅದರ ಅನುಷ್ಠಾನಕ್ಕಾಗಿ ನಿಮಗೆ ಸಾಮಾನ್ಯವೆಂದು ತೋರುವ ಸಮಯವನ್ನು ಮೂರು ಅಥವಾ ನಾಲ್ಕರಿಂದ ಗುಣಿಸಿ.
ವ್ಯಾಪಾರ ಪ್ರಕ್ರಿಯೆಗಳಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಸ DBMS ಅನ್ನು ಬಳಸಿಕೊಂಡು ಪರಿಹರಿಸಲಾಗುವುದಿಲ್ಲ, ಇದು ತುಂಬಾ ಉತ್ಪಾದಕವಾಗಿದೆ ಎಂದು ನೆನಪಿಡಿ. ನಾನು ಹೇಳುವುದು ಏನೆಂದರೆ? ನಮ್ಮ ಯೋಜನೆಯ ಪ್ರಾರಂಭದಲ್ಲಿ, ಈಗ ನಾವು ಹೊಸ ವೇಗದ ಡೇಟಾಬೇಸ್ ಅನ್ನು ತರುತ್ತೇವೆ ಮತ್ತು ನಾವು ಬದುಕುತ್ತೇವೆ ಎಂಬ ಅಭಿಪ್ರಾಯವನ್ನು ನಾವು ಗ್ರಾಹಕರಲ್ಲಿ ರಚಿಸಿದ್ದೇವೆ! ಪ್ರಕ್ರಿಯೆಗಳು ವೇಗವಾಗಿ ಹೋಗುತ್ತವೆ, ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿರುತ್ತದೆ. ವಾಸ್ತವವಾಗಿ, ವ್ಯಾಪಾರ ಪ್ರಕ್ರಿಯೆಗಳು ಹೊಂದಿರುವ ಸಮಸ್ಯೆಗಳನ್ನು ತಂತ್ರಜ್ಞಾನವು ಪರಿಹರಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ವ್ಯಾಪಾರ ಪ್ರಕ್ರಿಯೆಗಳು ಜನರು. ಮತ್ತು ನೀವು ಜನರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬೇಕಾಗಿದೆ, ತಂತ್ರಜ್ಞಾನವಲ್ಲ.
ಪರೀಕ್ಷಾ-ಚಾಲಿತ ಬೆಳವಣಿಗೆಯು ಆರಂಭಿಕ ಹಂತಗಳಲ್ಲಿ ನೋವಿನಿಂದ ಕೂಡಿದೆ ಮತ್ತು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಆದರೆ ಅದರ ಸಕಾರಾತ್ಮಕ ಪರಿಣಾಮವು ಅಲ್ಪಾವಧಿಯಲ್ಲಿಯೂ ಸಹ ಗಮನಿಸಬಹುದಾಗಿದೆ, ನೀವು ಹಿಂಜರಿತ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಲು ಏನನ್ನೂ ಮಾಡಬೇಕಾಗಿಲ್ಲ.
ಅಭಿವೃದ್ಧಿಯ ಎಲ್ಲಾ ಹಂತಗಳಲ್ಲಿ ಲೋಡ್ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸುವುದು ಬಹಳ ಮುಖ್ಯ. ವಾಸ್ತುಶಾಸ್ತ್ರದಲ್ಲಿನ ಕೆಲವು ದೋಷಗಳನ್ನು ನೀವು ಬೇಗನೆ ಗಮನಿಸಿದರೆ, ಅದನ್ನು ಸರಿಪಡಿಸಲು ಸುಲಭವಾಗುತ್ತದೆ, ಇದು ಭವಿಷ್ಯದಲ್ಲಿ ನಿಮಗೆ ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ಉಳಿಸುತ್ತದೆ.
ಲುವಾದಲ್ಲಿ ಯಾವುದೇ ತಪ್ಪಿಲ್ಲ. ಯಾರಾದರೂ ಅದರಲ್ಲಿ ಬರೆಯಲು ಕಲಿಯಬಹುದು: ಜಾವಾ ಡೆವಲಪರ್, ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಡೆವಲಪರ್, ಪೈಥಾನ್ ಡೆವಲಪರ್, ಫ್ರಂಟ್-ಎಂಡ್ ಅಥವಾ ಬ್ಯಾಕ್-ಎಂಡ್. ನಮ್ಮ ವಿಶ್ಲೇಷಕರು ಕೂಡ ಅದರ ಮೇಲೆ ಬರೆಯುತ್ತಾರೆ.
ನಾವು SQL ಹೊಂದಿಲ್ಲ ಎಂಬ ಅಂಶದ ಬಗ್ಗೆ ಮಾತನಾಡುವಾಗ, ಅದು ಜನರನ್ನು ಭಯಭೀತಗೊಳಿಸುತ್ತದೆ. "SQL ಇಲ್ಲದೆ ನೀವು ಡೇಟಾವನ್ನು ಹೇಗೆ ಪಡೆಯುತ್ತೀರಿ? ಇದು ಸಾಧ್ಯವೇ? ಖಂಡಿತವಾಗಿಯೂ. OLTP ವರ್ಗ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, SQL ಅಗತ್ಯವಿಲ್ಲ. ಕೆಲವು ರೀತಿಯ ಭಾಷೆಯ ರೂಪದಲ್ಲಿ ಪರ್ಯಾಯವಿದೆ ಅದು ತಕ್ಷಣವೇ ನಿಮ್ಮನ್ನು ಡಾಕ್ಯುಮೆಂಟ್-ಆಧಾರಿತ ವೀಕ್ಷಣೆಗೆ ಹಿಂದಿರುಗಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, GraphQL. ಮತ್ತು ವಿತರಿಸಿದ ಕಂಪ್ಯೂಟಿಂಗ್ ರೂಪದಲ್ಲಿ ಪರ್ಯಾಯವಿದೆ.
ನೀವು ಅಳೆಯುವ ಅಗತ್ಯವಿದೆ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡರೆ, ನಂತರ ನಿಮ್ಮ ಪರಿಹಾರವನ್ನು ಟ್ಯಾರಂಟೂಲ್‌ನಲ್ಲಿ ವಿನ್ಯಾಸಗೊಳಿಸಿ ಅದು ಡಜನ್‌ಗಟ್ಟಲೆ ಟ್ಯಾರಂಟೂಲ್ ನಿದರ್ಶನಗಳಲ್ಲಿ ಸಮಾನಾಂತರವಾಗಿ ಚಲಿಸಬಹುದು. ನೀವು ಇದನ್ನು ಮಾಡದಿದ್ದರೆ, ನಂತರ ಅದು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ ಮತ್ತು ನೋವಿನಿಂದ ಕೂಡಿರುತ್ತದೆ, ಏಕೆಂದರೆ Tarantool ಕೇವಲ ಒಂದು ಪ್ರೊಸೆಸರ್ ಕೋರ್ ಅನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬಳಸುತ್ತದೆ.
ಮೂಲ: www.habr.com