ಚಿಂತಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುವುದು ಮತ್ತು ಏಕಶಿಲೆಯಿಲ್ಲದೆ ಬದುಕಲು ಪ್ರಾರಂಭಿಸುವುದು ಹೇಗೆ

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

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

ಒಂದಾನೊಂದು ಕಾಲದಲ್ಲಿ, ನಮ್ಮ ಕಂಪನಿಯು ಎಲ್ಲರಿಗೂ ಒಂದೆರಡು "ಏಕಶಿಲೆಗಳು" ಮತ್ತು ಒಂದು "ಸೀಲಿಂಗ್" ಅನ್ನು ಹೊಂದಿತ್ತು, ಈ ಏಕಶಿಲೆಗಳು ನಿಧಾನವಾಗಿ ಆದರೆ ಖಂಡಿತವಾಗಿಯೂ ಸಮೀಪಿಸುತ್ತಿವೆ, ನಮ್ಮ ಕಂಪನಿಯ ಹಾರಾಟವನ್ನು ಸೀಮಿತಗೊಳಿಸುತ್ತವೆ, ನಮ್ಮ ಅಭಿವೃದ್ಧಿ. ಮತ್ತು ಸ್ಪಷ್ಟವಾದ ತಿಳುವಳಿಕೆ ಇತ್ತು: ಒಂದು ದಿನ ನಾವು ಈ ಸೀಲಿಂಗ್ ಅನ್ನು ಬಲವಾಗಿ ಹೊಡೆಯುತ್ತೇವೆ.

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

ಇಂದು, CI/CD, K8S, ಇತ್ಯಾದಿ ರೂಪದಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಸಾಕಷ್ಟು ಉಪಕರಣಗಳು ಮತ್ತು ಸಾಧನಗಳಿವೆ. "ಏಕಶಿಲೆಯ" ಸಮಯದಲ್ಲಿ, ನಮಗೆ ಹೆಚ್ಚು ವಿದೇಶಿ ಪದಗಳ ಅಗತ್ಯವಿರಲಿಲ್ಲ. ಡೇಟಾಬೇಸ್ನಲ್ಲಿ "ಸಂಗ್ರಹಣೆ" ಅನ್ನು ಸರಳವಾಗಿ ಸರಿಪಡಿಸಲು ಸಾಕು.

ಆದರೆ ಸಮಯವು ಮುಂದಕ್ಕೆ ಹೋಯಿತು, ಮತ್ತು ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯು ಅದರೊಂದಿಗೆ ಮುಂದಕ್ಕೆ ಸಾಗಿತು, ಕೆಲವೊಮ್ಮೆ ನಮ್ಮ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಮೀರಿ RPS ಅನ್ನು ಚಿತ್ರೀಕರಿಸುತ್ತದೆ. ಮಾರುಕಟ್ಟೆಗೆ ಸಿಐಎಸ್ ದೇಶಗಳ ಪ್ರವೇಶದೊಂದಿಗೆ, ಮೊದಲ ಏಕಶಿಲೆಯ ಡೇಟಾಬೇಸ್ ಪ್ರೊಸೆಸರ್‌ನಲ್ಲಿನ ಹೊರೆ 90% ಕ್ಕಿಂತ ಕಡಿಮೆಯಿಲ್ಲ, ಮತ್ತು RPS 2400 ಮಟ್ಟದಲ್ಲಿ ಉಳಿಯಿತು. ಮತ್ತು ಇವುಗಳು ಕೇವಲ ಸಣ್ಣ ಆಯ್ಕೆಗಳಲ್ಲ, ಆದರೆ ಭಾರೀ ಪ್ರಶ್ನೆಗಳು ದೊಡ್ಡ IO ನ ಹಿನ್ನೆಲೆಯ ವಿರುದ್ಧ ಸುಮಾರು ಅರ್ಧದಷ್ಟು ಡೇಟಾವನ್ನು ರನ್ ಮಾಡಬಹುದಾದ ಚೆಕ್‌ಗಳು ಮತ್ತು JOINಗಳ ಗುಂಪನ್ನು.

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

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

ವಿವಿಧ ಘಟನೆಗಳಲ್ಲಿ ನಾನು ಹೇಳುತ್ತೇನೆ: "ನೀವು ಏಕಶಿಲೆಯನ್ನು ನೋಡದಿದ್ದರೆ, ನೀವು ಬೆಳೆಯಲಿಲ್ಲ!" ಈ ವಿಷಯದ ಬಗ್ಗೆ ನಿಮ್ಮ ಅಭಿಪ್ರಾಯದಲ್ಲಿ ನಾನು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇನೆ, ದಯವಿಟ್ಟು ಅದನ್ನು ಕಾಮೆಂಟ್ಗಳಲ್ಲಿ ಬರೆಯಿರಿ.

ಎ ಸೌಂಡ್ ಆಫ್ ಥಂಡರ್

ನಮ್ಮ "ದೀಪೋತ್ಸವ" ಗೆ ಹಿಂತಿರುಗೋಣ. "ಏಕಶಿಲೆಯ" ಕ್ರಿಯಾತ್ಮಕತೆಯ ಲೋಡ್ ಅನ್ನು ವಿತರಿಸಲು, ಓಪನ್ ಸೋರ್ಸ್ ತಂತ್ರಜ್ಞಾನಗಳ ಆಧಾರದ ಮೇಲೆ ನಾವು ಸಿಸ್ಟಮ್ ಅನ್ನು ಮೈಕ್ರೋಸರ್ವಿಸ್ಗಳಾಗಿ ವಿಭಜಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಏಕೆಂದರೆ, ಕನಿಷ್ಠ, ಅವರು ಅಳೆಯಲು ಅಗ್ಗವಾಗಿದೆ. ಮತ್ತು ನಾವು ಅಳೆಯಬೇಕು (ಮತ್ತು ಬಹಳಷ್ಟು) ಎಂದು 100% ತಿಳುವಳಿಕೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಎಲ್ಲಾ ನಂತರ, ಈಗಾಗಲೇ ಆ ಸಮಯದಲ್ಲಿ ನೆರೆಯ ದೇಶಗಳ ಮಾರುಕಟ್ಟೆಗಳನ್ನು ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಾಯಿತು, ಮತ್ತು ನೋಂದಣಿಗಳ ಸಂಖ್ಯೆ, ಹಾಗೆಯೇ ಆದೇಶಗಳ ಸಂಖ್ಯೆಯು ಇನ್ನಷ್ಟು ಬಲವಾಗಿ ಬೆಳೆಯಲು ಪ್ರಾರಂಭಿಸಿತು.

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

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

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

ಪರಿಣಾಮವಾಗಿ, ನಾವು ಟ್ಯಾರಂಟೂಲ್‌ಗೆ ಉತ್ತಮವಾಗಿ ಹೊಂದಿಕೊಳ್ಳುವ ಯೋಜನೆಯೊಂದಿಗೆ ಬಂದಿದ್ದೇವೆ.

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

ವಾಸ್ತುಶಿಲ್ಪ. ಆಯ್ಕೆ 1. ಬಳಕೆದಾರ ಸೇವೆ

ಪ್ರಸ್ತುತ ಸಮಯದಲ್ಲಿ, 24 ಚೂರುಗಳು ಇವೆ, ಪ್ರತಿಯೊಂದೂ 2 ನಿದರ್ಶನಗಳನ್ನು ಹೊಂದಿದೆ (ಪ್ರತಿ DC ಗೆ ಒಂದು), ಎಲ್ಲವೂ ಮಾಸ್ಟರ್-ಮಾಸ್ಟರ್ ಮೋಡ್‌ನಲ್ಲಿದೆ.

ಡೇಟಾಬೇಸ್‌ನ ಮೇಲ್ಭಾಗದಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಪ್ರವೇಶಿಸುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿವೆ. ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ನಮ್ಮ ಕಸ್ಟಮ್ ಲೈಬ್ರರಿಯ ಮೂಲಕ Tarantool ನೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಇದು Tarantool Go ಡ್ರೈವರ್ ಇಂಟರ್‌ಫೇಸ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ಅವಳು ಎಲ್ಲಾ ಪ್ರತಿಕೃತಿಗಳನ್ನು ನೋಡುತ್ತಾಳೆ ಮತ್ತು ಓದಲು ಮತ್ತು ಬರೆಯಲು ಮಾಸ್ಟರ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದು. ಮೂಲಭೂತವಾಗಿ, ಇದು ಪ್ರತಿಕೃತಿ ಸೆಟ್ ಮಾದರಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ, ಇದು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಆಯ್ಕೆಮಾಡಲು, ಮರುಪ್ರಯತ್ನಗಳನ್ನು ಮಾಡಲು, ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್ ಮತ್ತು ದರ ಮಿತಿಗೆ ತರ್ಕವನ್ನು ಸೇರಿಸುತ್ತದೆ.

ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಚೂರುಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಪ್ರತಿಕೃತಿ ಆಯ್ಕೆ ನೀತಿಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಸಾಧ್ಯವಿದೆ. ಉದಾಹರಣೆಗೆ, ರೌಂಡ್ರೊಬಿನ್.

ವಾಸ್ತುಶಿಲ್ಪ. ಆಯ್ಕೆ 2. ಸರಕುಗಳ ಅಂತಿಮ ವೆಚ್ಚವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಸೇವೆ

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

ಸೇವಾ ಡೇಟಾಬೇಸ್ 4 ಮಾಸ್ಟರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಅದರಲ್ಲಿ ಸಿಂಕ್ರೊನೈಜರ್ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಮತ್ತು ಈ ಪ್ರತಿಯೊಂದು ಪ್ರತಿಕೃತಿ ಮಾಸ್ಟರ್‌ಗಳು ಡೇಟಾವನ್ನು ಓದಲು ಮಾತ್ರ ಪ್ರತಿಕೃತಿಗಳಿಗೆ ವಿತರಿಸುತ್ತದೆ. ಪ್ರತಿ ಮಾಸ್ಟರ್ ಸರಿಸುಮಾರು 15 ಇಂತಹ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಹೊಂದಿದೆ.

ಮೊದಲ ಅಥವಾ ಎರಡನೆಯ ಯೋಜನೆಯಲ್ಲಿ, ಒಂದು DC ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ, ಅಪ್ಲಿಕೇಶನ್ ಎರಡನೆಯದರಲ್ಲಿ ಡೇಟಾವನ್ನು ಪಡೆಯಬಹುದು.

ಟ್ಯಾರಂಟೂಲ್‌ನಲ್ಲಿ ನಕಲು ಮಾಡುವಿಕೆಯು ಸಾಕಷ್ಟು ಮೃದುವಾಗಿರುತ್ತದೆ ಮತ್ತು ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು ಎಂಬುದು ಗಮನಿಸಬೇಕಾದ ಸಂಗತಿ. ಇತರ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ, ತೊಂದರೆಗಳು ಹುಟ್ಟಿಕೊಂಡವು. ಉದಾಹರಣೆಗೆ, PostgreSQL ನಲ್ಲಿ max_wal_senders ಮತ್ತು max_replication_slots ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಲು ಮಾಂತ್ರಿಕನ ಮರುಪ್ರಾರಂಭದ ಅಗತ್ಯವಿದೆ, ಇದು ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು DBMS ನಡುವಿನ ಸಂಪರ್ಕಗಳ ಕಡಿತಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು.

ಹುಡುಕು ಮತ್ತು ನೀವು ಕಂಡುಕೊಳ್ಳುವಿರಿ!

ನಾವು ಅದನ್ನು "ಸಾಮಾನ್ಯ ಜನರಂತೆ" ಏಕೆ ಮಾಡಲಿಲ್ಲ, ಆದರೆ ವಿಲಕ್ಷಣವಾದ ಮಾರ್ಗವನ್ನು ಆರಿಸಿಕೊಂಡಿದ್ದೇವೆ? ಇದು ಸಾಮಾನ್ಯವೆಂದು ಪರಿಗಣಿಸಲ್ಪಟ್ಟಿರುವುದನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಅನೇಕರು ಸಾಮಾನ್ಯವಾಗಿ ಮೊಂಗೊದಿಂದ ಒಂದು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅದನ್ನು ಮೂರು ಜಿಯೋ-ವಿತರಣೆ DC ಗಳಲ್ಲಿ ಹರಡುತ್ತಾರೆ.

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

ಅಂದರೆ, ರೆಡಿಸ್ ಸ್ಥಿತಿಯಿಲ್ಲದ ಕಾರ್ಯಗಳಿಗೆ ಉತ್ತಮವಾಗಿದೆ, ಆದರೆ ಸ್ಟೇಟ್‌ಫುಲ್ ಅಲ್ಲ. ತಾತ್ವಿಕವಾಗಿ, ಇದು ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು, ಆದರೆ ಅವು ಒಂದು ಜೋಡಿ ಸೂಚ್ಯಂಕಗಳೊಂದಿಗೆ ಪ್ರಮುಖ-ಮೌಲ್ಯ ಪರಿಹಾರಗಳಾಗಿದ್ದರೆ ಮಾತ್ರ. ಆದರೆ ಆ ಸಮಯದಲ್ಲಿ ರೆಡಿಸ್ ನಿರಂತರತೆ ಮತ್ತು ಪ್ರತಿಕೃತಿಯೊಂದಿಗೆ ಸಾಕಷ್ಟು ದುಃಖಿತರಾಗಿದ್ದರು. ಜತೆಗೆ ಕಾರ್ಯಕ್ಷಮತೆ ಬಗ್ಗೆಯೂ ದೂರುಗಳು ಬಂದಿದ್ದವು.

ನಾವು MySQL ಮತ್ತು PostgreSQL ಬಗ್ಗೆ ಯೋಚಿಸಿದ್ದೇವೆ. ಆದರೆ ಮೊದಲನೆಯದು ಹೇಗಾದರೂ ನಮ್ಮೊಂದಿಗೆ ಹಿಡಿಯಲಿಲ್ಲ, ಮತ್ತು ಎರಡನೆಯದು ಸ್ವತಃ ಅತ್ಯಾಧುನಿಕ ಉತ್ಪನ್ನವಾಗಿದೆ ಮತ್ತು ಅದರ ಮೇಲೆ ಸರಳವಾದ ಸೇವೆಗಳನ್ನು ನಿರ್ಮಿಸಲು ಇದು ಸೂಕ್ತವಲ್ಲ.
ನಾವು RIAK, ಕಸ್ಸಂದ್ರ, ಗ್ರಾಫ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸಹ ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ. ಸೇವೆಗಳನ್ನು ರಚಿಸಲು ಸಾಮಾನ್ಯ ಸಾರ್ವತ್ರಿಕ ಸಾಧನದ ಪಾತ್ರಕ್ಕೆ ಸೂಕ್ತವಲ್ಲದ ಇವೆಲ್ಲವೂ ಸಾಕಷ್ಟು ಸ್ಥಾಪಿತ ಪರಿಹಾರಗಳಾಗಿವೆ.

ಅಂತಿಮವಾಗಿ ನಾವು ಟರಂಟೂಲ್‌ನಲ್ಲಿ ನೆಲೆಸಿದ್ದೇವೆ.

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

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

ಅನುಷ್ಠಾನವು ಒರಟಾಗಿ ಪ್ರಾರಂಭವಾಯಿತು

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

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

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

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

ಒಡೆದು ಆಳಿ. ಲುವಾ ಜೊತೆಗಿನ ಒಪ್ಪಂದವೇನು?

ಗಂಭೀರ ಸಂದಿಗ್ಧತೆ ಇತ್ತು: ಲುವಾದಲ್ಲಿ ಸಾಕಷ್ಟು ತರ್ಕವನ್ನು ಹೊಂದಿರುವ ಸೇವೆಗೆ ಬದಲಾವಣೆಗಳನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಹೊರತರಲು ಕೆಲವು ತಂಡಗಳಿಗೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಇದರೊಂದಿಗೆ ಆಗಾಗ್ಗೆ ಸೇವೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ.

ಅಂದರೆ, ಅಭಿವರ್ಧಕರು ಕೆಲವು ರೀತಿಯ ಬದಲಾವಣೆಯನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತಿದ್ದಾರೆ. ಟ್ಯಾರಂಟೂಲ್ ವಲಸೆಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಆದರೆ ಪ್ರತಿಕೃತಿಯು ಇನ್ನೂ ಹಳೆಯ ಕೋಡ್‌ನಲ್ಲಿದೆ; ಕೆಲವು ಡಿಡಿಎಲ್ ಅಥವಾ ಇನ್ನೇನಾದರೂ ಪುನರಾವರ್ತನೆಯ ಮೂಲಕ ಅಲ್ಲಿಗೆ ಆಗಮಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳದ ಕಾರಣ ಕೋಡ್ ಸರಳವಾಗಿ ಬೀಳುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ನಿರ್ವಾಹಕರಿಗೆ ನವೀಕರಣ ಕಾರ್ಯವಿಧಾನವನ್ನು A4 ಶೀಟ್‌ನಲ್ಲಿ ಹಾಕಲಾಗಿದೆ: ಪ್ರತಿಕೃತಿಯನ್ನು ನಿಲ್ಲಿಸಿ, ಇದನ್ನು ನವೀಕರಿಸಿ, ಪ್ರತಿಕೃತಿಯನ್ನು ಆನ್ ಮಾಡಿ, ಇಲ್ಲಿ ಆಫ್ ಮಾಡಿ, ಅಲ್ಲಿ ನವೀಕರಿಸಿ. ದುಃಸ್ವಪ್ನ!

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

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

ಟ್ಯಾರಂಟೂಲ್ ಈಗ ಎಲ್ಲಿದೆ?
"ಪ್ರವರ್ತಕ" ಎಂದೂ ಕರೆಯಲ್ಪಡುವ ರಿಯಾಯಿತಿ ಕೂಪನ್‌ಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು ಸರಕುಗಳ ಅಂತಿಮ ವೆಚ್ಚವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಟ್ಯಾರಂಟೂಲ್ ಅನ್ನು ಸೇವೆಯಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ. ನಾನು ಮೊದಲೇ ಹೇಳಿದಂತೆ, ಅವರು ಈಗ ನಿವೃತ್ತರಾಗುತ್ತಿದ್ದಾರೆ: ಪೂರ್ವ-ಲೆಕ್ಕಾಚಾರದ ಬೆಲೆಗಳೊಂದಿಗೆ ಹೊಸ ಕ್ಯಾಟಲಾಗ್ ಸೇವೆಯಿಂದ ಅವರನ್ನು ಬದಲಾಯಿಸಲಾಗುತ್ತಿದೆ, ಆದರೆ ಆರು ತಿಂಗಳ ಹಿಂದೆ ಎಲ್ಲಾ ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ಪ್ರಚಾರಕದಲ್ಲಿ ಮಾಡಲಾಗಿತ್ತು. ಹಿಂದೆ, ಅದರ ಅರ್ಧದಷ್ಟು ತರ್ಕವನ್ನು ಲುವಾದಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ. ಎರಡು ವರ್ಷಗಳ ಹಿಂದೆ, ಸೇವೆಯನ್ನು ಶೇಖರಣಾ ಸೌಲಭ್ಯವಾಗಿ ಪರಿವರ್ತಿಸಲಾಯಿತು, ಮತ್ತು ತರ್ಕವನ್ನು ಗೋದಲ್ಲಿ ಪುನಃ ಬರೆಯಲಾಯಿತು, ಏಕೆಂದರೆ ರಿಯಾಯಿತಿಗಳ ಯಂತ್ರಶಾಸ್ತ್ರವು ಸ್ವಲ್ಪ ಬದಲಾಗಿದೆ ಮತ್ತು ಸೇವೆಯು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೊಂದಿಲ್ಲ.

ಅತ್ಯಂತ ನಿರ್ಣಾಯಕ ಸೇವೆಗಳಲ್ಲಿ ಒಂದು ಬಳಕೆದಾರರ ಪ್ರೊಫೈಲ್ ಆಗಿದೆ. ಅಂದರೆ, ಎಲ್ಲಾ ವೈಲ್ಡ್‌ಬೆರ್ರಿ ಬಳಕೆದಾರರನ್ನು ಟ್ಯಾರಂಟೂಲ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ ಮತ್ತು ಅವರಲ್ಲಿ ಸುಮಾರು 50 ಮಿಲಿಯನ್‌ಗಳಿವೆ. ಬಳಕೆದಾರ ID ಯಿಂದ ಹಂಚಲಾದ ಸಿಸ್ಟಮ್, Go ಸೇವೆಗಳಿಗೆ ಸಂಪರ್ಕಗೊಂಡಿರುವ ಹಲವಾರು DC ಗಳಲ್ಲಿ ವಿತರಿಸಲಾಗಿದೆ.
RPS ಪ್ರಕಾರ, ಪ್ರವರ್ತಕರು ಒಮ್ಮೆ ನಾಯಕರಾಗಿದ್ದರು, 6 ಸಾವಿರ ವಿನಂತಿಗಳನ್ನು ತಲುಪಿದರು. ಒಂದು ಹಂತದಲ್ಲಿ ನಮ್ಮ ಬಳಿ 50-60 ಪ್ರತಿಗಳಿದ್ದವು. ಈಗ RPS ನಲ್ಲಿ ನಾಯಕ ಬಳಕೆದಾರರ ಪ್ರೊಫೈಲ್‌ಗಳು, ಸುಮಾರು 12 ಸಾವಿರ. ಈ ಸೇವೆಯು ಕಸ್ಟಮ್ ಶಾರ್ಡಿಂಗ್ ಅನ್ನು ಬಳಸುತ್ತದೆ, ಬಳಕೆದಾರ ID ಗಳ ವ್ಯಾಪ್ತಿಯಿಂದ ಭಾಗಿಸಲಾಗಿದೆ. ಸೇವೆಯು 20 ಕ್ಕೂ ಹೆಚ್ಚು ಯಂತ್ರಗಳಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ, ಆದರೆ ಇದು ತುಂಬಾ ಹೆಚ್ಚು; ನಾವು ನಿಗದಿಪಡಿಸಿದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಯೋಜಿಸುತ್ತೇವೆ, ಏಕೆಂದರೆ 4-5 ಯಂತ್ರಗಳ ಸಾಮರ್ಥ್ಯವು ಇದಕ್ಕೆ ಸಾಕಾಗುತ್ತದೆ.

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

ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿ ಮತ್ತು ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ವಿಭಿನ್ನ ಬ್ಯಾನರ್‌ಗಳನ್ನು ಪ್ರದರ್ಶಿಸುವ ಸೇವೆಯು ಟ್ಯಾರಂಟೂಲ್‌ನಲ್ಲಿ ನೇರವಾಗಿ ಬಿಡುಗಡೆಯಾದ ಮೊದಲನೆಯದು. ಈ ಸೇವೆಯು 6-7 ವರ್ಷ ಹಳೆಯದು ಎಂಬ ಅಂಶಕ್ಕೆ ಗಮನಾರ್ಹವಾಗಿದೆ, ಇದು ಇನ್ನೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಮತ್ತು ಎಂದಿಗೂ ರೀಬೂಟ್ ಮಾಡಲಾಗಿಲ್ಲ. ಮಾಸ್ಟರ್-ಮಾಸ್ಟರ್ ಪ್ರತಿಕೃತಿಯನ್ನು ಬಳಸಲಾಗಿದೆ. ಯಾವುದೂ ಎಂದಿಗೂ ಮುರಿಯಲಿಲ್ಲ.

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

ಕಾಯುವ ಪಟ್ಟಿ, ಕ್ಲೈಂಟ್ ಚಂದಾದಾರಿಕೆಗಳು, ಪ್ರಸ್ತುತ ಫ್ಯಾಶನ್ ಕಥೆಗಳು ಮತ್ತು ಮುಂದೂಡಲ್ಪಟ್ಟ ಸರಕುಗಳ ಸೇವೆಗಳು ಸಹ Tarantool ಜೊತೆಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಮೆಮೊರಿಯಲ್ಲಿ ಕೊನೆಯ ಸೇವೆಯು ಸುಮಾರು 120 GB ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಮೇಲಿನವುಗಳಲ್ಲಿ ಇದು ಅತ್ಯಂತ ವ್ಯಾಪಕವಾದ ಸೇವೆಯಾಗಿದೆ.

ತೀರ್ಮಾನಕ್ಕೆ

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

ವಿಷಯದ ಬಗ್ಗೆ ಇನ್ನೇನು ಓದಬೇಕು

• Tarantool ಬಳಸಿಕೊಂಡು ಮೊದಲಿನಿಂದ ಹೆಚ್ಚಿನ ಲೋಡ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ರಚಿಸಲಾಗುತ್ತಿದೆ habr.com/ru/company/mailru/blog/510440
• Tarantool ಕಾರ್ಟ್ರಿಡ್ಜ್‌ನಲ್ಲಿ ವಿಶ್ವಾಸಾರ್ಹ ನಾಯಕನ ಆಯ್ಕೆ habr.com/ru/company/mailru/blog/513912
• ಉತ್ಪನ್ನದ ಕುರಿತು ಸುದ್ದಿಯೊಂದಿಗೆ ಟೆಲಿಗ್ರಾಮ್ ಚಾನೆಲ್ Tarantool t.me/tarantool_news
• ಸಮುದಾಯ ಚಾಟ್‌ನಲ್ಲಿ Tarantool ಕುರಿತು ಚರ್ಚಿಸಿ t.me/tarantoolru

ಮೂಲ: www.habr.com