ಆರ್ಟೆಮ್ ಡೆನಿಸೊವ್ ( , )
Badoo ವಿಶ್ವದ ಅತಿದೊಡ್ಡ ಡೇಟಿಂಗ್ ಸೈಟ್ ಆಗಿದೆ. ನಾವು ಪ್ರಸ್ತುತ ವಿಶ್ವಾದ್ಯಂತ ಸುಮಾರು 330 ಮಿಲಿಯನ್ ನೋಂದಾಯಿತ ಬಳಕೆದಾರರನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಆದರೆ ಇಂದು ನಮ್ಮ ಸಂಭಾಷಣೆಯ ಸಂದರ್ಭದಲ್ಲಿ ಹೆಚ್ಚು ಮುಖ್ಯವಾದುದು ನಾವು ಸುಮಾರು 3 ಪೆಟಾಬೈಟ್ ಬಳಕೆದಾರರ ಫೋಟೋಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ. ಪ್ರತಿದಿನ ನಮ್ಮ ಬಳಕೆದಾರರು ಸುಮಾರು 3,5 ಮಿಲಿಯನ್ ಹೊಸ ಫೋಟೋಗಳನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಓದುವ ಲೋಡ್ ಸುಮಾರು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 80 ಸಾವಿರ ವಿನಂತಿಗಳು. ಇದು ನಮ್ಮ ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಸಾಕಷ್ಟು ಆಗಿದೆ, ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಇದರೊಂದಿಗೆ ತೊಂದರೆಗಳಿವೆ.
ನಾನು ಈ ಸಿಸ್ಟಮ್ನ ವಿನ್ಯಾಸದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇನೆ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಫೋಟೋಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ನಾನು ಅದನ್ನು ಡೆವಲಪರ್ನ ದೃಷ್ಟಿಕೋನದಿಂದ ನೋಡುತ್ತೇನೆ. ಅದು ಹೇಗೆ ಅಭಿವೃದ್ಧಿಗೊಂಡಿದೆ ಎಂಬುದರ ಕುರಿತು ಸಂಕ್ಷಿಪ್ತ ಸಿಂಹಾವಲೋಕನ ಇರುತ್ತದೆ, ಅಲ್ಲಿ ನಾನು ಮುಖ್ಯ ಮೈಲಿಗಲ್ಲುಗಳನ್ನು ರೂಪಿಸುತ್ತೇನೆ, ಆದರೆ ನಾವು ಪ್ರಸ್ತುತ ಬಳಸುತ್ತಿರುವ ಪರಿಹಾರಗಳ ಬಗ್ಗೆ ಮಾತ್ರ ನಾನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ಮಾತನಾಡುತ್ತೇನೆ.
ಈಗ ಪ್ರಾರಂಭಿಸೋಣ.
ನಾನು ಹೇಳಿದಂತೆ, ಇದು ಪೂರ್ವಾವಲೋಕನವಾಗಿದೆ, ಮತ್ತು ಅದನ್ನು ಎಲ್ಲೋ ಪ್ರಾರಂಭಿಸಲು, ನಾವು ಸಾಮಾನ್ಯ ಉದಾಹರಣೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ.
ನಮಗೆ ಸಾಮಾನ್ಯ ಕಾರ್ಯವಿದೆ, ನಾವು ಬಳಕೆದಾರರ ಫೋಟೋಗಳನ್ನು ಸ್ವೀಕರಿಸಬೇಕು, ಸಂಗ್ರಹಿಸಬೇಕು ಮತ್ತು ಕಳುಹಿಸಬೇಕು. ಈ ರೂಪದಲ್ಲಿ, ಕಾರ್ಯವು ಸಾಮಾನ್ಯವಾಗಿದೆ, ನಾವು ಯಾವುದನ್ನಾದರೂ ಬಳಸಬಹುದು:
- ಆಧುನಿಕ ಮೇಘ ಸಂಗ್ರಹಣೆ,
- ಪೆಟ್ಟಿಗೆಯ ಪರಿಹಾರ, ಅದರಲ್ಲಿ ಈಗ ಬಹಳಷ್ಟು ಇವೆ;
- ನಾವು ನಮ್ಮ ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ ಹಲವಾರು ಯಂತ್ರಗಳನ್ನು ಹೊಂದಿಸಬಹುದು ಮತ್ತು ಅವುಗಳ ಮೇಲೆ ದೊಡ್ಡ ಹಾರ್ಡ್ ಡ್ರೈವ್‌ಗಳನ್ನು ಹಾಕಬಹುದು ಮತ್ತು ಫೋಟೋಗಳನ್ನು ಅಲ್ಲಿ ಸಂಗ್ರಹಿಸಬಹುದು.
Badoo ಐತಿಹಾಸಿಕವಾಗಿ - ಆಗೊಮ್ಮೆ ಈಗೊಮ್ಮೆ (ಅದು ಶೈಶವಾವಸ್ಥೆಯಲ್ಲಿದ್ದಾಗ) - ತನ್ನದೇ ಆದ ಸರ್ವರ್‌ಗಳಲ್ಲಿ, ನಮ್ಮದೇ DC ಗಳಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ, ಈ ಆಯ್ಕೆಯು ನಮಗೆ ಸೂಕ್ತವಾಗಿದೆ.
ನಾವು ಕೇವಲ ಹಲವಾರು ಯಂತ್ರಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ, ಅವುಗಳನ್ನು "ಫೋಟೋಗಳು" ಎಂದು ಕರೆಯುತ್ತೇವೆ ಮತ್ತು ಫೋಟೋಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನಾವು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ. ಆದರೆ ಏನೋ ಕಾಣೆಯಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ. ಇದೆಲ್ಲವೂ ಕೆಲಸ ಮಾಡಲು, ನಾವು ಯಾವ ಫೋಟೋಗಳನ್ನು ಯಾವ ಯಂತ್ರದಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ನಾವು ಹೇಗಾದರೂ ನಿರ್ಧರಿಸಬೇಕು. ಮತ್ತು ಇಲ್ಲಿಯೂ ಸಹ, ಅಮೆರಿಕವನ್ನು ತೆರೆಯುವ ಅಗತ್ಯವಿಲ್ಲ.
ಬಳಕೆದಾರರ ಬಗ್ಗೆ ಮಾಹಿತಿಯೊಂದಿಗೆ ನಾವು ನಮ್ಮ ಸಂಗ್ರಹಣೆಗೆ ಕೆಲವು ಕ್ಷೇತ್ರಗಳನ್ನು ಸೇರಿಸುತ್ತೇವೆ. ಇದು ಶಾರ್ಡಿಂಗ್ ಕೀ ಆಗಿರುತ್ತದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಇದನ್ನು place_id ಎಂದು ಕರೆಯುತ್ತೇವೆ ಮತ್ತು ಈ ಸ್ಥಳದ ಐಡಿ ಬಳಕೆದಾರರ ಫೋಟೋಗಳನ್ನು ಸಂಗ್ರಹಿಸಿರುವ ಸ್ಥಳಕ್ಕೆ ಸೂಚಿಸುತ್ತದೆ. ನಾವು ನಕ್ಷೆಗಳನ್ನು ತಯಾರಿಸುತ್ತೇವೆ.
ಮೊದಲ ಹಂತದಲ್ಲಿ, ಇದನ್ನು ಕೈಯಾರೆ ಸಹ ಮಾಡಬಹುದು - ಅಂತಹ ಸ್ಥಳವನ್ನು ಹೊಂದಿರುವ ಈ ಬಳಕೆದಾರರ ಫೋಟೋ ಅಂತಹ ಸರ್ವರ್‌ನಲ್ಲಿ ಇಳಿಯುತ್ತದೆ ಎಂದು ನಾವು ಹೇಳುತ್ತೇವೆ. ಈ ನಕ್ಷೆಗೆ ಧನ್ಯವಾದಗಳು, ಬಳಕೆದಾರರು ಫೋಟೋವನ್ನು ಯಾವಾಗ ಅಪ್ಲೋಡ್ ಮಾಡುತ್ತಾರೆ, ಅದನ್ನು ಎಲ್ಲಿ ಉಳಿಸಬೇಕು ಮತ್ತು ಅದನ್ನು ಎಲ್ಲಿಂದ ನೀಡಬೇಕೆಂದು ನಮಗೆ ತಿಳಿದಿರುತ್ತದೆ.
ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಕ್ಷುಲ್ಲಕ ಯೋಜನೆಯಾಗಿದೆ, ಆದರೆ ಇದು ಸಾಕಷ್ಟು ಗಮನಾರ್ಹ ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿದೆ. ಮೊದಲನೆಯದು ನಾನು ಹೇಳಿದಂತೆ ಇದು ಸರಳವಾಗಿದೆ, ಮತ್ತು ಎರಡನೆಯದು ಈ ವಿಧಾನದಿಂದ ನಾವು ಹೊಸ ಕಾರುಗಳನ್ನು ಸರಳವಾಗಿ ವಿತರಿಸುವ ಮೂಲಕ ಮತ್ತು ಅವುಗಳನ್ನು ನಕ್ಷೆಗೆ ಸೇರಿಸುವ ಮೂಲಕ ಸುಲಭವಾಗಿ ಅಡ್ಡಲಾಗಿ ಅಳೆಯಬಹುದು. ನೀವು ಬೇರೆ ಏನನ್ನೂ ಮಾಡಬೇಕಾಗಿಲ್ಲ.
ಕೆಲಕಾಲ ನಮಗೆ ಹೀಗೇ ಇತ್ತು.
ಇದು 2009 ರ ಸುಮಾರಿಗೆ. ಅವರು ಕಾರುಗಳನ್ನು ವಿತರಿಸಿದರು, ವಿತರಿಸಿದರು ...
ಮತ್ತು ಕೆಲವು ಹಂತದಲ್ಲಿ ಈ ಯೋಜನೆಯು ಕೆಲವು ಅನಾನುಕೂಲಗಳನ್ನು ಹೊಂದಿದೆ ಎಂದು ನಾವು ಗಮನಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಅನಾನುಕೂಲಗಳೇನು?
ಮೊದಲನೆಯದಾಗಿ, ಸೀಮಿತ ಸಾಮರ್ಥ್ಯವಿದೆ. ನಾವು ಬಯಸಿದಷ್ಟು ಹಾರ್ಡ್ ಡ್ರೈವ್‌ಗಳನ್ನು ಒಂದು ಭೌತಿಕ ಸರ್ವರ್‌ನಲ್ಲಿ ಕ್ರ್ಯಾಮ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಮತ್ತು ಇದು ಕಾಲಾನಂತರದಲ್ಲಿ ಮತ್ತು ಡೇಟಾಸೆಟ್‌ನ ಬೆಳವಣಿಗೆಯೊಂದಿಗೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಮಸ್ಯೆಯಾಗಿದೆ.
ಮತ್ತು ಎರಡನೆಯದು. ಇದು ಯಂತ್ರಗಳ ವಿಲಕ್ಷಣ ಸಂರಚನೆಯಾಗಿದೆ, ಏಕೆಂದರೆ ಅಂತಹ ಯಂತ್ರಗಳನ್ನು ಕೆಲವು ಇತರ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಮರುಬಳಕೆ ಮಾಡುವುದು ಕಷ್ಟ; ಅವು ಸಾಕಷ್ಟು ನಿರ್ದಿಷ್ಟವಾಗಿವೆ, ಅಂದರೆ. ಅವರು ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ದುರ್ಬಲವಾಗಿರಬೇಕು, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ದೊಡ್ಡ ಹಾರ್ಡ್ ಡ್ರೈವ್ನೊಂದಿಗೆ.
ಇದೆಲ್ಲವೂ 2009 ಕ್ಕೆ ಆಗಿತ್ತು, ಆದರೆ, ತಾತ್ವಿಕವಾಗಿ, ಈ ಅವಶ್ಯಕತೆಗಳು ಇಂದಿಗೂ ಪ್ರಸ್ತುತವಾಗಿವೆ. ನಾವು ಹಿಂದಿನದನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಆದ್ದರಿಂದ 2009 ರಲ್ಲಿ ಎಲ್ಲವೂ ಸಂಪೂರ್ಣವಾಗಿ ಕೆಟ್ಟದಾಗಿದೆ.
ಮತ್ತು ಕೊನೆಯ ಅಂಶವೆಂದರೆ ಬೆಲೆ.
ಆ ಸಮಯದಲ್ಲಿ ಬೆಲೆ ತುಂಬಾ ಕಡಿದಾಗಿತ್ತು ಮತ್ತು ನಾವು ಕೆಲವು ಪರ್ಯಾಯಗಳನ್ನು ಹುಡುಕಬೇಕಾಗಿದೆ. ಆ. ಡೇಟಾ ಸೆಂಟರ್‌ಗಳಲ್ಲಿನ ಜಾಗವನ್ನು ಮತ್ತು ಇವೆಲ್ಲವೂ ಇರುವ ಭೌತಿಕ ಸರ್ವರ್‌ಗಳನ್ನು ನಾವು ಹೇಗಾದರೂ ಉತ್ತಮವಾಗಿ ಬಳಸಿಕೊಳ್ಳುವ ಅಗತ್ಯವಿದೆ. ಮತ್ತು ನಮ್ಮ ಸಿಸ್ಟಮ್ ಎಂಜಿನಿಯರ್‌ಗಳು ದೊಡ್ಡ ಅಧ್ಯಯನವನ್ನು ಪ್ರಾರಂಭಿಸಿದರು, ಅದರಲ್ಲಿ ಅವರು ವಿಭಿನ್ನ ಆಯ್ಕೆಗಳ ಗುಂಪನ್ನು ಪರಿಶೀಲಿಸಿದರು. ಅವರು ಪಾಲಿಸೆಫ್ ಮತ್ತು ಲುಸ್ಟರ್‌ನಂತಹ ಕ್ಲಸ್ಟರ್ಡ್ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಸಹ ನೋಡಿದರು. ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳು ಮತ್ತು ಸಾಕಷ್ಟು ಕಷ್ಟಕರವಾದ ಕಾರ್ಯಾಚರಣೆಯಿದ್ದವು. ಅವರು ನಿರಾಕರಿಸಿದರು. ನಾವು ಅದನ್ನು ಹೇಗಾದರೂ ಹೆಚ್ಚಿಸುವ ಸಲುವಾಗಿ ಪ್ರತಿ ಕಾರ್‌ನಲ್ಲಿ NFS ಮೂಲಕ ಸಂಪೂರ್ಣ ಡೇಟಾಸೆಟ್ ಅನ್ನು ಆರೋಹಿಸಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ. ಓದುವಿಕೆ ಕೂಡ ಕಳಪೆಯಾಗಿ ಹೋಯಿತು, ನಾವು ವಿಭಿನ್ನ ಮಾರಾಟಗಾರರಿಂದ ವಿಭಿನ್ನ ಪರಿಹಾರಗಳನ್ನು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ.
ಮತ್ತು ಕೊನೆಯಲ್ಲಿ, ನಾವು ಸ್ಟೋರೇಜ್ ಏರಿಯಾ ನೆಟ್‌ವರ್ಕ್ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಬಳಕೆಯಲ್ಲಿ ನೆಲೆಸಿದ್ದೇವೆ.
ಇವುಗಳು ದೊಡ್ಡ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ನಿರ್ದಿಷ್ಟವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ದೊಡ್ಡ SHDಗಳಾಗಿವೆ. ಅವರು ಅಂತಿಮ ಆಪ್ಟಿಕಲ್ ಔಟ್ಪುಟ್ ಯಂತ್ರಗಳಲ್ಲಿ ಜೋಡಿಸಲಾದ ಡಿಸ್ಕ್ಗಳೊಂದಿಗೆ ಕಪಾಟಿನಲ್ಲಿದ್ದಾರೆ. ಅದು. ನಾವು ಕೆಲವು ರೀತಿಯ ಯಂತ್ರಗಳ ಪೂಲ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಸಾಕಷ್ಟು ಚಿಕ್ಕದಾಗಿದೆ ಮತ್ತು ಈ SHD ಗಳು ನಮ್ಮ ಕಳುಹಿಸುವ ತರ್ಕಕ್ಕೆ ಪಾರದರ್ಶಕವಾಗಿವೆ, ಅಂದರೆ. ಈ ಫೋಟೋಗಳಿಗಾಗಿ ವಿನಂತಿಗಳನ್ನು ನೀಡಲು ನಮ್ಮ nginx ಅಥವಾ ಬೇರೆ ಯಾರಿಗಾದರೂ.
ಈ ನಿರ್ಧಾರವು ಸ್ಪಷ್ಟ ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿತ್ತು. ಇದು SHD. ಇದು ಫೋಟೋಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಗುರಿಯನ್ನು ಹೊಂದಿದೆ. ಹಾರ್ಡ್ ಡ್ರೈವ್‌ಗಳೊಂದಿಗೆ ಯಂತ್ರಗಳನ್ನು ಸರಳವಾಗಿ ಸಜ್ಜುಗೊಳಿಸುವುದಕ್ಕಿಂತ ಇದು ಅಗ್ಗವಾಗಿದೆ.
ಎರಡನೇ ಪ್ಲಸ್.
ಇದು ಸಾಮರ್ಥ್ಯವು ಹೆಚ್ಚು ದೊಡ್ಡದಾಗಿದೆ, ಅಂದರೆ. ನಾವು ಹೆಚ್ಚು ಸಣ್ಣ ಪ್ರಮಾಣದಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಂಗ್ರಹಣೆಗೆ ಅವಕಾಶ ಕಲ್ಪಿಸಬಹುದು.
ಆದರೆ ಅನನುಕೂಲಗಳು ಸಹ ಬಹಳ ಬೇಗನೆ ಹೊರಹೊಮ್ಮಿದವು. ಈ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಬಳಕೆದಾರರ ಸಂಖ್ಯೆ ಮತ್ತು ಲೋಡ್ ಹೆಚ್ಚಾದಂತೆ, ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸಲು ಪ್ರಾರಂಭಿಸಿದವು. ಮತ್ತು ಇಲ್ಲಿ ಸಮಸ್ಯೆ ಸಾಕಷ್ಟು ಸ್ಪಷ್ಟವಾಗಿದೆ - ಸಣ್ಣ ಪರಿಮಾಣದಲ್ಲಿ ಅನೇಕ ಫೋಟೋಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಯಾವುದೇ SHD, ನಿಯಮದಂತೆ, ತೀವ್ರವಾದ ಓದುವಿಕೆಯಿಂದ ಬಳಲುತ್ತದೆ. ಯಾವುದೇ ಕ್ಲೌಡ್ ಸಂಗ್ರಹಣೆ ಅಥವಾ ಬೇರೆ ಯಾವುದಕ್ಕೂ ಇದು ನಿಜವಾಗಿದೆ. ಈಗ ನಾವು ಪರಿಪೂರ್ಣವಾದ ಸಂಗ್ರಹಣೆಯನ್ನು ಹೊಂದಿಲ್ಲ, ಅದು ಅನಂತವಾಗಿ ಸ್ಕೇಲೆಬಲ್ ಆಗಿರುತ್ತದೆ, ನೀವು ಅದರಲ್ಲಿ ಏನು ಬೇಕಾದರೂ ತುಂಬಿಸಬಹುದು ಮತ್ತು ಅದು ವಾಚನಗೋಷ್ಠಿಯನ್ನು ಚೆನ್ನಾಗಿ ಸಹಿಸಿಕೊಳ್ಳುತ್ತದೆ. ವಿಶೇಷವಾಗಿ ಸಾಂದರ್ಭಿಕ ವಾಚನಗೋಷ್ಠಿಗಳು.
ನಮ್ಮ ಫೋಟೋಗಳಂತೆಯೇ, ಫೋಟೋಗಳನ್ನು ಅಸಮಂಜಸವಾಗಿ ವಿನಂತಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಇದು ಅವರ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಹೆಚ್ಚು ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.
ಇಂದಿನ ಅಂಕಿಅಂಶಗಳ ಪ್ರಕಾರ, ಸಂಗ್ರಹಣೆಯನ್ನು ಸಂಪರ್ಕಿಸಿರುವ ಯಂತ್ರದಲ್ಲಿ ಫೋಟೋಗಳಿಗಾಗಿ ನಾವು ಎಲ್ಲೋ 500 RPS ಗಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಪಡೆದರೆ, ಸಮಸ್ಯೆಗಳು ಈಗಾಗಲೇ ಪ್ರಾರಂಭವಾಗುತ್ತವೆ. ಮತ್ತು ಇದು ನಮಗೆ ಸಾಕಷ್ಟು ಕೆಟ್ಟದಾಗಿತ್ತು, ಏಕೆಂದರೆ ಬಳಕೆದಾರರ ಸಂಖ್ಯೆಯು ಬೆಳೆಯುತ್ತಿದೆ, ವಿಷಯಗಳು ಮಾತ್ರ ಕೆಟ್ಟದಾಗಿ ಹೋಗುತ್ತವೆ. ಇದನ್ನು ಹೇಗಾದರೂ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಬೇಕಾಗಿದೆ.
ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲು, ನಾವು ಆ ಸಮಯದಲ್ಲಿ ನಿರ್ಧರಿಸಿದ್ದೇವೆ, ನಿಸ್ಸಂಶಯವಾಗಿ, ಲೋಡ್ ಪ್ರೊಫೈಲ್ ಅನ್ನು ನೋಡಲು - ಸಾಮಾನ್ಯವಾಗಿ ಏನು ನಡೆಯುತ್ತಿದೆ, ಏನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಬೇಕಾಗಿದೆ.
ಮತ್ತು ಇಲ್ಲಿ ಎಲ್ಲವೂ ನಮ್ಮ ಕೈಯಲ್ಲಿ ಆಡುತ್ತದೆ.
ನಾನು ಈಗಾಗಲೇ ಮೊದಲ ಸ್ಲೈಡ್‌ನಲ್ಲಿ ಹೇಳಿದ್ದೇನೆ: ನಾವು ದಿನಕ್ಕೆ 80 ಮಿಲಿಯನ್ ಅಪ್‌ಲೋಡ್‌ಗಳೊಂದಿಗೆ ಸೆಕೆಂಡಿಗೆ 3,5 ಸಾವಿರ ಓದುವ ವಿನಂತಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅಂದರೆ, ಇದು ಪರಿಮಾಣದ ಮೂರು ಕ್ರಮಗಳ ವ್ಯತ್ಯಾಸವಾಗಿದೆ. ಓದುವಿಕೆಯನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಬೇಕಾಗಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ ಮತ್ತು ಅದು ಹೇಗೆ ಎಂಬುದು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಸ್ಪಷ್ಟವಾಗಿದೆ.
ಇನ್ನೂ ಒಂದು ಸಣ್ಣ ಅಂಶವಿದೆ. ಸೇವೆಯ ನಿಶ್ಚಿತಗಳು ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ನೋಂದಾಯಿಸಿಕೊಳ್ಳುತ್ತಾನೆ, ಫೋಟೋವನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡುತ್ತಾನೆ, ನಂತರ ಇತರ ಜನರನ್ನು ಸಕ್ರಿಯವಾಗಿ ನೋಡಲು ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ, ಅವರಂತೆಯೇ, ಮತ್ತು ಇತರ ಜನರಿಗೆ ಸಕ್ರಿಯವಾಗಿ ತೋರಿಸಲಾಗುತ್ತದೆ. ನಂತರ ಅವನು ಸಂಗಾತಿಯನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತಾನೆ ಅಥವಾ ಸಂಗಾತಿಯನ್ನು ಕಂಡುಹಿಡಿಯುವುದಿಲ್ಲ, ಅದು ಹೇಗೆ ಹೊರಹೊಮ್ಮುತ್ತದೆ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ ಮತ್ತು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಸೇವೆಯನ್ನು ಬಳಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಈ ಕ್ಷಣದಲ್ಲಿ, ಅವನು ಅದನ್ನು ಬಳಸಿದಾಗ, ಅವನ ಫೋಟೋಗಳು ತುಂಬಾ ಬಿಸಿಯಾಗಿವೆ - ಅವು ಬೇಡಿಕೆಯಲ್ಲಿವೆ, ಬಹಳಷ್ಟು ಜನರು ಅವುಗಳನ್ನು ವೀಕ್ಷಿಸುತ್ತಾರೆ. ಅವನು ಇದನ್ನು ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿದ ತಕ್ಷಣ, ಅವನು ಮೊದಲಿನಂತೆ ಇತರ ಜನರಿಗೆ ಹೆಚ್ಚು ಒಡ್ಡಿಕೊಳ್ಳುವುದರಿಂದ ಬೇಗನೆ ಹೊರಬರುತ್ತಾನೆ ಮತ್ತು ಅವನ ಫೋಟೋಗಳನ್ನು ಎಂದಿಗೂ ವಿನಂತಿಸುವುದಿಲ್ಲ.
ಆ. ನಾವು ತುಂಬಾ ಚಿಕ್ಕ ಹಾಟ್ ಡೇಟಾಸೆಟ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಅವನಿಗೆ ಸಾಕಷ್ಟು ವಿನಂತಿಗಳಿವೆ. ಮತ್ತು ಇಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಪಷ್ಟವಾದ ಪರಿಹಾರವೆಂದರೆ ಸಂಗ್ರಹವನ್ನು ಸೇರಿಸುವುದು.
LRU ನೊಂದಿಗೆ ಸಂಗ್ರಹವು ನಮ್ಮ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ನಾವೇನು ಮಾಡುತ್ತಿದ್ದೇವೆ?
ಸಂಗ್ರಹಣೆಯೊಂದಿಗೆ ನಮ್ಮ ದೊಡ್ಡ ಕ್ಲಸ್ಟರ್‌ನ ಮುಂದೆ ನಾವು ತುಲನಾತ್ಮಕವಾಗಿ ಚಿಕ್ಕದನ್ನು ಸೇರಿಸುತ್ತೇವೆ, ಇದನ್ನು ಫೋಟೋಕ್ಯಾಶ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಇದು ಮೂಲಭೂತವಾಗಿ ಕೇವಲ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಪ್ರಾಕ್ಸಿ ಆಗಿದೆ.
ಒಳಗಿನಿಂದ ಅದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ? ಇಲ್ಲಿ ನಮ್ಮ ಬಳಕೆದಾರ, ಇಲ್ಲಿ ಸಂಗ್ರಹಣೆ ಇದೆ. ಎಲ್ಲವೂ ಮೊದಲಿನಂತೆಯೇ ಇದೆ. ನಾವು ನಡುವೆ ಏನು ಸೇರಿಸುತ್ತೇವೆ?
ಇದು ಕೇವಲ ಭೌತಿಕ ಸ್ಥಳೀಯ ಡಿಸ್ಕ್ ಹೊಂದಿರುವ ಯಂತ್ರವಾಗಿದೆ, ಅದು ವೇಗವಾಗಿರುತ್ತದೆ. ಇದು SSD ಯೊಂದಿಗೆ, ಉದಾಹರಣೆಗೆ. ಮತ್ತು ಕೆಲವು ರೀತಿಯ ಸ್ಥಳೀಯ ಸಂಗ್ರಹವನ್ನು ಈ ಡಿಸ್ಕ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ.
ಅದು ಯಾವುದರಂತೆ ಕಾಣಿಸುತ್ತದೆ? ಬಳಕೆದಾರರು ಫೋಟೋಗಾಗಿ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ. NGINX ಇದನ್ನು ಮೊದಲು ಸ್ಥಳೀಯ ಸಂಗ್ರಹದಲ್ಲಿ ಹುಡುಕುತ್ತದೆ. ಇಲ್ಲದಿದ್ದರೆ, ನಮ್ಮ ಸಂಗ್ರಹಣೆಗೆ ಪ್ರಾಕ್ಸಿ_ಪಾಸ್ ಮಾಡಿ, ಅಲ್ಲಿಂದ ಫೋಟೋವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಅದನ್ನು ಬಳಕೆದಾರರಿಗೆ ನೀಡಿ.
ಆದರೆ ಇದು ತುಂಬಾ ನೀರಸವಾಗಿದೆ ಮತ್ತು ಒಳಗೆ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದು ಅಸ್ಪಷ್ಟವಾಗಿದೆ. ಇದು ಈ ರೀತಿಯ ಕೆಲಸ ಮಾಡುತ್ತದೆ.
ಸಂಗ್ರಹವನ್ನು ತಾರ್ಕಿಕವಾಗಿ ಮೂರು ಪದರಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ. ನಾನು "ಮೂರು ಪದರಗಳು" ಎಂದು ಹೇಳಿದಾಗ, ಕೆಲವು ರೀತಿಯ ಸಂಕೀರ್ಣ ವ್ಯವಸ್ಥೆ ಇದೆ ಎಂದು ಇದರ ಅರ್ಥವಲ್ಲ. ಇಲ್ಲ, ಇವುಗಳು ಷರತ್ತುಬದ್ಧವಾಗಿ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಕೇವಲ ಮೂರು ಡೈರೆಕ್ಟರಿಗಳಾಗಿವೆ:
- ಪ್ರಾಕ್ಸಿಯಿಂದ ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ ಫೋಟೋಗಳು ಹೋಗುವ ಬಫರ್ ಇದಾಗಿದೆ.
- ಇದು ಪ್ರಸ್ತುತ ಸಕ್ರಿಯವಾಗಿ ವಿನಂತಿಸಿದ ಫೋಟೋಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಬಿಸಿ ಸಂಗ್ರಹವಾಗಿದೆ.
- ಮತ್ತು ಕೋಲ್ಡ್ ಕ್ಯಾಶ್, ಅಲ್ಲಿ ಕಡಿಮೆ ವಿನಂತಿಗಳು ಬಂದಾಗ ಫೋಟೋಗಳನ್ನು ಕ್ರಮೇಣ ಹಾಟ್ ಕ್ಯಾಶ್‌ನಿಂದ ಹೊರಹಾಕಲಾಗುತ್ತದೆ.
ಇದು ಕೆಲಸ ಮಾಡಲು, ನಾವು ಹೇಗಾದರೂ ಈ ಸಂಗ್ರಹವನ್ನು ನಿರ್ವಹಿಸಬೇಕಾಗಿದೆ, ನಾವು ಅದರಲ್ಲಿರುವ ಫೋಟೋಗಳನ್ನು ಮರುಹೊಂದಿಸಬೇಕಾಗಿದೆ, ಇತ್ಯಾದಿ. ಇದೂ ಕೂಡ ಅತ್ಯಂತ ಪ್ರಾಚೀನ ಪ್ರಕ್ರಿಯೆ.
ಪ್ರತಿ ವಿನಂತಿಗಾಗಿ Nginx ಸರಳವಾಗಿ RAMDisk access.log ಗೆ ಬರೆಯುತ್ತದೆ, ಇದರಲ್ಲಿ ಅದು ಪ್ರಸ್ತುತ ಸೇವೆ ಸಲ್ಲಿಸಿದ ಫೋಟೋಗೆ ಮಾರ್ಗವನ್ನು ಸೂಚಿಸುತ್ತದೆ (ಸಾಪೇಕ್ಷ ಮಾರ್ಗ, ಸಹಜವಾಗಿ), ಮತ್ತು ಅದನ್ನು ಯಾವ ವಿಭಾಗವನ್ನು ಒದಗಿಸಲಾಗಿದೆ. ಆ. ಇದು "ಫೋಟೋ 1" ಎಂದು ಹೇಳಬಹುದು ಮತ್ತು ನಂತರ ಬಫರ್, ಅಥವಾ ಹಾಟ್ ಕ್ಯಾಶ್, ಅಥವಾ ಕೋಲ್ಡ್ ಕ್ಯಾಶ್ ಅಥವಾ ಪ್ರಾಕ್ಸಿ.
ಇದನ್ನು ಅವಲಂಬಿಸಿ, ಫೋಟೋದೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕೆಂದು ನಾವು ಹೇಗಾದರೂ ನಿರ್ಧರಿಸಬೇಕು.
ನಾವು ಪ್ರತಿ ಗಣಕದಲ್ಲಿ ಸಣ್ಣ ಡೀಮನ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದು ನಿರಂತರವಾಗಿ ಈ ಲಾಗ್ ಅನ್ನು ಓದುತ್ತದೆ ಮತ್ತು ಅದರ ಸ್ಮರಣೆಯಲ್ಲಿ ಕೆಲವು ಛಾಯಾಚಿತ್ರಗಳ ಬಳಕೆಯ ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ.
ಅವನು ಅಲ್ಲಿ ಸರಳವಾಗಿ ಸಂಗ್ರಹಿಸುತ್ತಾನೆ, ಕೌಂಟರ್‌ಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತಾನೆ ಮತ್ತು ನಿಯತಕಾಲಿಕವಾಗಿ ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಮಾಡುತ್ತಾನೆ. ಅವರು ಸಕ್ರಿಯವಾಗಿ ವಿನಂತಿಸಿದ ಫೋಟೋಗಳನ್ನು ಚಲಿಸುತ್ತಾರೆ, ಇದಕ್ಕಾಗಿ ಹಲವು ವಿನಂತಿಗಳಿವೆ, ಅವರು ಎಲ್ಲಿದ್ದರೂ ಹಾಟ್ ಕ್ಯಾಶ್‌ಗೆ.
ಅಪರೂಪವಾಗಿ ವಿನಂತಿಸಲಾದ ಮತ್ತು ಕಡಿಮೆ ಬಾರಿ ವಿನಂತಿಸಲಾದ ಫೋಟೋಗಳನ್ನು ಕ್ರಮೇಣ ಹಾಟ್ ಕ್ಯಾಶ್‌ನಿಂದ ತಂಪಾದ ಒಂದಕ್ಕೆ ತಳ್ಳಲಾಗುತ್ತದೆ.
ಮತ್ತು ನಾವು ಸಂಗ್ರಹದಲ್ಲಿ ಸ್ಥಳಾವಕಾಶವನ್ನು ಕಳೆದುಕೊಂಡಾಗ, ನಾವು ಸರಳವಾಗಿ ಕೋಲ್ಡ್ ಕ್ಯಾಶ್‌ನಿಂದ ವಿವೇಚನೆಯಿಲ್ಲದೆ ಎಲ್ಲವನ್ನೂ ಅಳಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ಮತ್ತು ಮೂಲಕ, ಇದು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಫೋಟೋವನ್ನು ಬಫರ್‌ಗೆ ಪ್ರಾಕ್ಸಿ ಮಾಡುವಾಗ ಅದನ್ನು ತಕ್ಷಣವೇ ಉಳಿಸಲು, ನಾವು ಪ್ರಾಕ್ಸಿ_ಸ್ಟೋರ್ ನಿರ್ದೇಶನವನ್ನು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ಬಫರ್ ಸಹ RAMDisk ಆಗಿದೆ, ಅಂದರೆ. ಬಳಕೆದಾರರಿಗೆ ಇದು ಬೇಗನೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಇದು ಕ್ಯಾಶಿಂಗ್ ಸರ್ವರ್‌ನ ಆಂತರಿಕ ಅಂಶಗಳಿಗೆ ಸಂಬಂಧಿಸಿದೆ.
ಈ ಸರ್ವರ್‌ಗಳಾದ್ಯಂತ ವಿನಂತಿಗಳನ್ನು ಹೇಗೆ ವಿತರಿಸುವುದು ಎಂಬುದು ಉಳಿದಿರುವ ಪ್ರಶ್ನೆಯಾಗಿದೆ.
ಇಪ್ಪತ್ತು ಶೇಖರಣಾ ಯಂತ್ರಗಳು ಮತ್ತು ಮೂರು ಕ್ಯಾಶಿಂಗ್ ಸರ್ವರ್‌ಗಳ ಕ್ಲಸ್ಟರ್ ಇದೆ ಎಂದು ಹೇಳೋಣ (ಇದು ಹೇಗೆ ಸಂಭವಿಸಿತು).
ಯಾವ ಫೋಟೋಗಳಿಗಾಗಿ ಯಾವ ವಿನಂತಿಗಳು ಮತ್ತು ಅವುಗಳನ್ನು ಎಲ್ಲಿ ಇಳಿಸಬೇಕೆಂದು ನಾವು ಹೇಗಾದರೂ ನಿರ್ಧರಿಸಬೇಕು.
ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾದ ಆಯ್ಕೆಯೆಂದರೆ ರೌಂಡ್ ರಾಬಿನ್. ಅಥವಾ ಆಕಸ್ಮಿಕವಾಗಿ ಮಾಡುವುದೇ?
ಇದು ನಿಸ್ಸಂಶಯವಾಗಿ ಹಲವಾರು ಅನಾನುಕೂಲಗಳನ್ನು ಹೊಂದಿದೆ ಏಕೆಂದರೆ ಅಂತಹ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ನಾವು ಸಂಗ್ರಹವನ್ನು ಅತ್ಯಂತ ಅಸಮರ್ಥವಾಗಿ ಬಳಸುತ್ತೇವೆ. ವಿನಂತಿಗಳು ಕೆಲವು ಯಾದೃಚ್ಛಿಕ ಯಂತ್ರಗಳಲ್ಲಿ ಇಳಿಯುತ್ತವೆ: ಇಲ್ಲಿ ಅದನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ, ಆದರೆ ಮುಂದಿನದರಲ್ಲಿ ಅದು ಇನ್ನು ಮುಂದೆ ಇರುವುದಿಲ್ಲ. ಮತ್ತು ಇದೆಲ್ಲವೂ ಕೆಲಸ ಮಾಡಿದರೆ, ಅದು ತುಂಬಾ ಕೆಟ್ಟದಾಗಿರುತ್ತದೆ. ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ಯಂತ್ರಗಳಿದ್ದರೂ ಸಹ.
ಯಾವ ಸರ್ವರ್ ಯಾವ ವಿನಂತಿಯನ್ನು ಇಳಿಸಬೇಕೆಂದು ನಾವು ಹೇಗಾದರೂ ನಿಸ್ಸಂದಿಗ್ಧವಾಗಿ ನಿರ್ಧರಿಸಬೇಕು.
ನೀರಸ ಮಾರ್ಗವಿದೆ. ನಾವು URL ನಿಂದ ಹ್ಯಾಶ್ ಅಥವಾ URL ನಲ್ಲಿರುವ ನಮ್ಮ ಶಾರ್ಡಿಂಗ್ ಕೀಯಿಂದ ಹ್ಯಾಶ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಸರ್ವರ್‌ಗಳ ಸಂಖ್ಯೆಯಿಂದ ಭಾಗಿಸುತ್ತೇವೆ. ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ? ವಿಲ್.
ಆ. ನಾವು 2% ವಿನಂತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಉದಾಹರಣೆಗೆ, ಕೆಲವು "example_url" ಗಾಗಿ ಅದು ಯಾವಾಗಲೂ "XNUMX" ಸೂಚ್ಯಂಕದೊಂದಿಗೆ ಸರ್ವರ್‌ನಲ್ಲಿ ಇಳಿಯುತ್ತದೆ ಮತ್ತು ಸಂಗ್ರಹವನ್ನು ನಿರಂತರವಾಗಿ ಸಾಧ್ಯವಾದಷ್ಟು ಉತ್ತಮವಾಗಿ ವಿಲೇವಾರಿ ಮಾಡಲಾಗುತ್ತದೆ.
ಆದರೆ ಅಂತಹ ಯೋಜನೆಯಲ್ಲಿ ಮರುಹಂಚಿಕೆ ಮಾಡುವಲ್ಲಿ ಸಮಸ್ಯೆ ಇದೆ. ಮರುಹಂಚಿಕೆ - ಅಂದರೆ ಸರ್ವರ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಬದಲಾಯಿಸುವುದು.
ನಮ್ಮ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಕ್ಲಸ್ಟರ್ ಇನ್ನು ಮುಂದೆ ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಭಾವಿಸೋಣ ಮತ್ತು ನಾವು ಇನ್ನೊಂದು ಯಂತ್ರವನ್ನು ಸೇರಿಸಲು ನಿರ್ಧರಿಸುತ್ತೇವೆ.
ಸೇರಿಸೋಣ.
ಈಗ ಎಲ್ಲವನ್ನೂ ಮೂರರಿಂದ ಭಾಗಿಸಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ನಾಲ್ಕರಿಂದ ಭಾಗಿಸಬಹುದು. ಹೀಗಾಗಿ, ನಾವು ಹೊಂದಿದ್ದ ಬಹುತೇಕ ಎಲ್ಲಾ ಕೀಗಳು, ಬಹುತೇಕ ಎಲ್ಲಾ URL ಗಳು ಈಗ ಇತರ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ. ಸಂಪೂರ್ಣ ಸಂಗ್ರಹವನ್ನು ಒಂದು ಕ್ಷಣಕ್ಕೆ ಅಮಾನ್ಯಗೊಳಿಸಲಾಗಿದೆ. ಎಲ್ಲಾ ವಿನಂತಿಗಳು ನಮ್ಮ ಸಂಗ್ರಹಣೆ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಬಿದ್ದವು, ಅದು ಅಸ್ವಸ್ಥವಾಯಿತು, ಸೇವೆಯ ವೈಫಲ್ಯ ಮತ್ತು ಅತೃಪ್ತ ಬಳಕೆದಾರರು. ನಾನು ಹಾಗೆ ಮಾಡಲು ಬಯಸುವುದಿಲ್ಲ.
ಈ ಆಯ್ಕೆಯು ನಮಗೆ ಸರಿಹೊಂದುವುದಿಲ್ಲ.
ಅದು. ನಾವು ಏನು ಮಾಡಬೇಕು? ನಾವು ಹೇಗಾದರೂ ಸಂಗ್ರಹವನ್ನು ಸಮರ್ಥವಾಗಿ ಬಳಸಿಕೊಳ್ಳಬೇಕು, ಅದೇ ವಿನಂತಿಯನ್ನು ಮತ್ತೆ ಮತ್ತೆ ಅದೇ ಸರ್ವರ್‌ನಲ್ಲಿ ಇಳಿಸಬೇಕು, ಆದರೆ ಮರುಹಂಚಿಕೆಗೆ ನಿರೋಧಕವಾಗಿರಬೇಕು. ಮತ್ತು ಅಂತಹ ಪರಿಹಾರವಿದೆ, ಅದು ಸಂಕೀರ್ಣವಾಗಿಲ್ಲ. ಇದನ್ನು ಸ್ಥಿರವಾದ ಹ್ಯಾಶಿಂಗ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.
ಇದು ಯಾವ ರೀತಿ ಕಾಣುತ್ತದೆ?
ನಾವು ಶಾರ್ಡಿಂಗ್ ಕೀಲಿಯಿಂದ ಕೆಲವು ಕಾರ್ಯಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಅದರ ಎಲ್ಲಾ ಮೌಲ್ಯಗಳನ್ನು ವೃತ್ತದ ಮೇಲೆ ಹರಡುತ್ತೇವೆ. ಆ. ಪಾಯಿಂಟ್ 0 ನಲ್ಲಿ, ಅದರ ಕನಿಷ್ಠ ಮತ್ತು ಗರಿಷ್ಠ ಮೌಲ್ಯಗಳು ಒಮ್ಮುಖವಾಗುತ್ತವೆ. ಮುಂದೆ, ನಾವು ನಮ್ಮ ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳನ್ನು ಒಂದೇ ವಲಯದಲ್ಲಿ ಸರಿಸುಮಾರು ಈ ರೀತಿಯಲ್ಲಿ ಇರಿಸುತ್ತೇವೆ:
ಪ್ರತಿಯೊಂದು ಸರ್ವರ್ ಅನ್ನು ಒಂದು ಬಿಂದುವಿನಿಂದ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ ಮತ್ತು ಅದಕ್ಕೆ ಪ್ರದಕ್ಷಿಣಾಕಾರವಾಗಿ ಹೋಗುವ ಸೆಕ್ಟರ್ ಅನ್ನು ಈ ಹೋಸ್ಟ್ ಮೂಲಕ ನೀಡಲಾಗುತ್ತದೆ. ವಿನಂತಿಗಳು ನಮಗೆ ಬಂದಾಗ, ನಾವು ತಕ್ಷಣ ನೋಡುತ್ತೇವೆ, ಉದಾಹರಣೆಗೆ, ವಿನಂತಿಸಿ A - ಅದು ಅಲ್ಲಿ ಹ್ಯಾಶ್ ಅನ್ನು ಹೊಂದಿದೆ - ಮತ್ತು ಅದನ್ನು ಸರ್ವರ್ 2. ವಿನಂತಿ B - ಸರ್ವರ್ ಮೂಲಕ 3. ಹೀಗೆ.
ಮರುಹೊಂದಿಸುವ ಸಮಯದಲ್ಲಿ ಈ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಏನಾಗುತ್ತದೆ?
ನಾವು ಮೊದಲಿನಂತೆ ಸಂಪೂರ್ಣ ಸಂಗ್ರಹವನ್ನು ಅಮಾನ್ಯಗೊಳಿಸುವುದಿಲ್ಲ ಮತ್ತು ಎಲ್ಲಾ ಕೀಗಳನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ, ಆದರೆ ನಾವು ಪ್ರತಿ ವಲಯವನ್ನು ಸ್ವಲ್ಪ ದೂರಕ್ಕೆ ಬದಲಾಯಿಸುತ್ತೇವೆ ಆದ್ದರಿಂದ ತುಲನಾತ್ಮಕವಾಗಿ ಹೇಳುವುದಾದರೆ, ನಾವು ಸೇರಿಸಲು ಬಯಸುವ ನಮ್ಮ ಆರನೇ ಸರ್ವರ್, ಮುಕ್ತ ಜಾಗಕ್ಕೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ನಾವು ಅದನ್ನು ಅಲ್ಲಿ ಸೇರಿಸುತ್ತೇವೆ.
ಸಹಜವಾಗಿ, ಅಂತಹ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಕೀಲಿಗಳು ಸಹ ಹೊರಬರುತ್ತವೆ. ಆದರೆ ಅವರು ಮೊದಲಿಗಿಂತ ಹೆಚ್ಚು ದುರ್ಬಲವಾಗಿ ಹೊರಬರುತ್ತಾರೆ. ಮತ್ತು ನಮ್ಮ ಮೊದಲ ಎರಡು ಕೀಗಳು ಅವುಗಳ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಉಳಿದಿವೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ ಮತ್ತು ಕ್ಯಾಶಿಂಗ್ ಸರ್ವರ್ ಕೊನೆಯ ಕೀಲಿಗಾಗಿ ಮಾತ್ರ ಬದಲಾಗಿದೆ. ಇದು ಸಾಕಷ್ಟು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ನೀವು ಹೊಸ ಹೋಸ್ಟ್‌ಗಳನ್ನು ಹೆಚ್ಚುತ್ತಿರುವಂತೆ ಸೇರಿಸಿದರೆ, ಇಲ್ಲಿ ಯಾವುದೇ ದೊಡ್ಡ ಸಮಸ್ಯೆ ಇಲ್ಲ. ನೀವು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಸೇರಿಸಿ ಮತ್ತು ಸೇರಿಸಿ, ಸಂಗ್ರಹವು ಮತ್ತೆ ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಕಾಯಿರಿ ಮತ್ತು ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ನಿರಾಕರಣೆಯೊಂದಿಗೆ ಒಂದೇ ಪ್ರಶ್ನೆ ಉಳಿದಿದೆ. ಕೆಲವು ರೀತಿಯ ಕಾರು ಕ್ರಮಬದ್ಧವಾಗಿಲ್ಲ ಎಂದು ಭಾವಿಸೋಣ.
ಮತ್ತು ಈ ಕ್ಷಣದಲ್ಲಿ ಈ ನಕ್ಷೆಯನ್ನು ಪುನರುತ್ಪಾದಿಸಲು ನಾವು ನಿಜವಾಗಿಯೂ ಬಯಸುವುದಿಲ್ಲ, ಸಂಗ್ರಹದ ಭಾಗವನ್ನು ಅಮಾನ್ಯಗೊಳಿಸುತ್ತೇವೆ ಮತ್ತು ಹೀಗೆ, ಉದಾಹರಣೆಗೆ, ಯಂತ್ರವನ್ನು ರೀಬೂಟ್ ಮಾಡಿದ್ದರೆ ಮತ್ತು ನಾವು ಹೇಗಾದರೂ ಸೇವಾ ವಿನಂತಿಗಳನ್ನು ಮಾಡಬೇಕಾಗಿದೆ. ನಾವು ಪ್ರತಿ ಸೈಟ್‌ನಲ್ಲಿ ಒಂದು ಬ್ಯಾಕಪ್ ಫೋಟೋ ಸಂಗ್ರಹವನ್ನು ಸರಳವಾಗಿ ಇರಿಸುತ್ತೇವೆ, ಇದು ಪ್ರಸ್ತುತ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ಯಾವುದೇ ಯಂತ್ರಕ್ಕೆ ಬದಲಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಮತ್ತು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ನಮ್ಮ ಸರ್ವರ್‌ಗಳು ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ, ಟ್ರಾಫಿಕ್ ಅಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ನಾವು ಅಲ್ಲಿ ಯಾವುದೇ ಸಂಗ್ರಹವನ್ನು ಹೊಂದಿಲ್ಲ, ಅಂದರೆ. ಇದು ತಂಪಾಗಿದೆ, ಆದರೆ ಕನಿಷ್ಠ ಬಳಕೆದಾರರ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತಿದೆ. ಇದು ಒಂದು ಸಣ್ಣ ಮಧ್ಯಂತರವಾಗಿದ್ದರೆ, ನಾವು ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಶಾಂತವಾಗಿ ಅನುಭವಿಸುತ್ತೇವೆ. ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಕೇವಲ ಹೆಚ್ಚಿನ ಲೋಡ್ ಇದೆ. ಈ ಮಧ್ಯಂತರವು ದೀರ್ಘವಾಗಿದ್ದರೆ, ನಾವು ಈಗಾಗಲೇ ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು - ಈ ಸರ್ವರ್ ಅನ್ನು ನಕ್ಷೆಯಿಂದ ತೆಗೆದುಹಾಕಲು ಅಥವಾ ಇಲ್ಲ, ಅಥವಾ ಬಹುಶಃ ಅದನ್ನು ಇನ್ನೊಂದಕ್ಕೆ ಬದಲಾಯಿಸಿ.
ಇದು ಕ್ಯಾಶಿಂಗ್ ಸಿಸ್ಟಮ್ ಬಗ್ಗೆ. ಫಲಿತಾಂಶಗಳನ್ನು ನೋಡೋಣ.
ಇಲ್ಲಿ ಸಂಕೀರ್ಣವಾದ ಏನೂ ಇಲ್ಲ ಎಂದು ತೋರುತ್ತದೆ. ಆದರೆ ಸಂಗ್ರಹವನ್ನು ನಿರ್ವಹಿಸುವ ಈ ವಿಧಾನವು ನಮಗೆ ಸುಮಾರು 98% ಟ್ರಿಕ್ ದರವನ್ನು ನೀಡಿತು. ಆ. ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಈ 80 ಸಾವಿರ ವಿನಂತಿಗಳಲ್ಲಿ, ಕೇವಲ 1600 ಸಂಗ್ರಹಣೆಯನ್ನು ತಲುಪುತ್ತದೆ, ಮತ್ತು ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಸಾಮಾನ್ಯ ಹೊರೆಯಾಗಿದೆ, ಅವರು ಅದನ್ನು ಶಾಂತವಾಗಿ ಸಹಿಸಿಕೊಳ್ಳುತ್ತಾರೆ, ನಾವು ಯಾವಾಗಲೂ ಮೀಸಲು ಹೊಂದಿದ್ದೇವೆ.
ನಾವು ಈ ಸರ್ವರ್‌ಗಳನ್ನು ನಮ್ಮ ಮೂರು DC ಗಳಲ್ಲಿ ಇರಿಸಿದ್ದೇವೆ ಮತ್ತು ಪ್ರೇಗ್, ಮಿಯಾಮಿ ಮತ್ತು ಹಾಂಗ್ ಕಾಂಗ್ ಮೂರು ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ.
ಅದು. ಅವು ಹೆಚ್ಚು ಕಡಿಮೆ ಸ್ಥಳೀಯವಾಗಿ ನಮ್ಮ ಪ್ರತಿಯೊಂದು ಗುರಿ ಮಾರುಕಟ್ಟೆಗೆ ನೆಲೆಗೊಂಡಿವೆ.
ಮತ್ತು ಉತ್ತಮ ಬೋನಸ್ ಆಗಿ, ನಾವು ಈ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಪ್ರಾಕ್ಸಿಯನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ, ಅದರ ಮೇಲೆ CPU ನಿಜವಾಗಿ ನಿಷ್ಕ್ರಿಯವಾಗಿದೆ, ಏಕೆಂದರೆ ಇದು ವಿಷಯವನ್ನು ಪೂರೈಸಲು ಅಗತ್ಯವಿಲ್ಲ. ಮತ್ತು ಅಲ್ಲಿ, NGINX+ Lua ಬಳಸಿ, ನಾವು ಸಾಕಷ್ಟು ಉಪಯುಕ್ತವಾದ ತರ್ಕವನ್ನು ಅಳವಡಿಸಿದ್ದೇವೆ.
ಉದಾಹರಣೆಗೆ, ನಾವು webp ಅಥವಾ ಪ್ರಗತಿಶೀಲ jpeg ನೊಂದಿಗೆ ಪ್ರಯೋಗಿಸಬಹುದು (ಇವುಗಳು ಪರಿಣಾಮಕಾರಿ ಆಧುನಿಕ ಸ್ವರೂಪಗಳು), ಇದು ಸಂಚಾರದ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಿ, ಕೆಲವು ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು, ಕೆಲವು ದೇಶಗಳಿಗೆ ಅದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಇತ್ಯಾದಿ. ಫ್ಲೈನಲ್ಲಿ ಡೈನಾಮಿಕ್ ಮರುಗಾತ್ರಗೊಳಿಸಿ ಅಥವಾ ಫೋಟೋಗಳನ್ನು ಕ್ರಾಪ್ ಮಾಡಿ.
ಉದಾಹರಣೆಗೆ, ನೀವು ಫೋಟೋಗಳನ್ನು ಪ್ರದರ್ಶಿಸುವ ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೊಂದಿರುವಾಗ ಇದು ಉತ್ತಮ ಬಳಕೆಯ ಸಂದರ್ಭವಾಗಿದೆ ಮತ್ತು ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ ದೊಡ್ಡ ಫೋಟೋವನ್ನು ವಿನಂತಿಸಲು ಕ್ಲೈಂಟ್‌ನ CPU ಅನ್ನು ವ್ಯರ್ಥ ಮಾಡಲು ಬಯಸುವುದಿಲ್ಲ ಮತ್ತು ಅದನ್ನು ತಳ್ಳಲು ನಿರ್ದಿಷ್ಟ ಗಾತ್ರಕ್ಕೆ ಮರುಗಾತ್ರಗೊಳಿಸಲು ಬಯಸುವುದಿಲ್ಲ. ನೋಟ. ನಾವು UPport ಷರತ್ತುಬದ್ಧ URL ನಲ್ಲಿ ಕೆಲವು ನಿಯತಾಂಕಗಳನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಸರಳವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು ಮತ್ತು ಫೋಟೋ ಸಂಗ್ರಹವು ಫೋಟೋವನ್ನು ಮರುಗಾತ್ರಗೊಳಿಸುತ್ತದೆ. ನಿಯಮದಂತೆ, ಇದು ನಾವು ಡಿಸ್ಕ್ನಲ್ಲಿ ಭೌತಿಕವಾಗಿ ಹೊಂದಿರುವ ಗಾತ್ರವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ವಿನಂತಿಸಿದ ಒಂದಕ್ಕೆ ಸಾಧ್ಯವಾದಷ್ಟು ಹತ್ತಿರದಲ್ಲಿದೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ನಿರ್ದೇಶಾಂಕಗಳಲ್ಲಿ ಅದನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
ಅಂದಹಾಗೆ, ಹೈ-ಲೋಡ್ ಸಿಸ್ಟಮ್‌ಗಳ ಡೆವಲಪರ್‌ಗಳ ಸಮ್ಮೇಳನದ ಕಳೆದ ಐದು ವರ್ಷಗಳ ವೀಡಿಯೊ ರೆಕಾರ್ಡಿಂಗ್‌ಗಳನ್ನು ನಾವು ಸಾರ್ವಜನಿಕವಾಗಿ ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡಿದ್ದೇವೆ . ವೀಕ್ಷಿಸಿ, ಕಲಿಯಿರಿ, ಹಂಚಿಕೊಳ್ಳಿ ಮತ್ತು ಚಂದಾದಾರರಾಗಿ .
ನಾವು ಅಲ್ಲಿ ಸಾಕಷ್ಟು ಉತ್ಪನ್ನ ತರ್ಕವನ್ನು ಕೂಡ ಸೇರಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ನಾವು URL ನಿಯತಾಂಕಗಳನ್ನು ಬಳಸಿಕೊಂಡು ವಿವಿಧ ವಾಟರ್‌ಮಾರ್ಕ್‌ಗಳನ್ನು ಸೇರಿಸಬಹುದು, ನಾವು ಫೋಟೋಗಳನ್ನು ಮಸುಕುಗೊಳಿಸಬಹುದು, ಮಸುಕುಗೊಳಿಸಬಹುದು ಅಥವಾ ಪಿಕ್ಸೆಲೇಟ್ ಮಾಡಬಹುದು. ಇದು ನಾವು ವ್ಯಕ್ತಿಯ ಫೋಟೋವನ್ನು ತೋರಿಸಲು ಬಯಸಿದಾಗ, ಆದರೆ ನಾವು ಅವನ ಮುಖವನ್ನು ತೋರಿಸಲು ಬಯಸುವುದಿಲ್ಲ, ಇದು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಎಲ್ಲವನ್ನೂ ಇಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ.
ನಮಗೆ ಏನು ಸಿಕ್ಕಿತು? ನಾವು ಉಪಸ್ಥಿತಿಯ ಮೂರು ಅಂಕಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ, ಉತ್ತಮ ಟ್ರಿಕ್ ದರ, ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ನಾವು ಈ ಯಂತ್ರಗಳಲ್ಲಿ ಐಡಲ್ CPU ಅನ್ನು ಹೊಂದಿಲ್ಲ. ಅವನು ಈಗ ಮೊದಲಿಗಿಂತ ಹೆಚ್ಚು ಪ್ರಾಮುಖ್ಯತೆ ಪಡೆದಿದ್ದಾನೆ. ನಾವೇ ಬಲವಾದ ಕಾರುಗಳನ್ನು ನೀಡಬೇಕಾಗಿದೆ, ಆದರೆ ಅದು ಯೋಗ್ಯವಾಗಿದೆ.
ಇದು ಛಾಯಾಚಿತ್ರಗಳ ವಾಪಸಾತಿಗೆ ಸಂಬಂಧಿಸಿದೆ. ಇಲ್ಲಿ ಎಲ್ಲವೂ ಸಾಕಷ್ಟು ಸ್ಪಷ್ಟ ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿದೆ. ನಾನು ಅಮೇರಿಕಾವನ್ನು ಕಂಡುಹಿಡಿಯಲಿಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಯಾವುದೇ CDN ಈ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಮತ್ತು, ಹೆಚ್ಚಾಗಿ, ಅತ್ಯಾಧುನಿಕ ಕೇಳುಗರು ಪ್ರಶ್ನೆಯನ್ನು ಹೊಂದಿರಬಹುದು: ಎಲ್ಲವನ್ನೂ CDN ಗೆ ಏಕೆ ಬದಲಾಯಿಸಬಾರದು? ಇದು ಒಂದೇ ಆಗಿರುತ್ತದೆ; ಎಲ್ಲಾ ಆಧುನಿಕ CDN ಗಳು ಇದನ್ನು ಮಾಡಬಹುದು. ಮತ್ತು ಹಲವಾರು ಕಾರಣಗಳಿವೆ.
ಮೊದಲನೆಯದು ಛಾಯಾಚಿತ್ರಗಳು.
ಇದು ನಮ್ಮ ಮೂಲಸೌಕರ್ಯದ ಪ್ರಮುಖ ಅಂಶಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ ಮತ್ತು ಅದರ ಮೇಲೆ ನಮಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ನಿಯಂತ್ರಣ ಬೇಕು. ಇದು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಮಾರಾಟಗಾರರಿಂದ ಕೆಲವು ರೀತಿಯ ಪರಿಹಾರವಾಗಿದ್ದರೆ ಮತ್ತು ಅದರ ಮೇಲೆ ನಿಮಗೆ ಯಾವುದೇ ಅಧಿಕಾರವಿಲ್ಲದಿದ್ದರೆ, ನೀವು ದೊಡ್ಡ ಡೇಟಾಸೆಟ್ ಹೊಂದಿರುವಾಗ ಮತ್ತು ನೀವು ದೊಡ್ಡ ಹರಿವನ್ನು ಹೊಂದಿರುವಾಗ ಅದರೊಂದಿಗೆ ಬದುಕಲು ನಿಮಗೆ ತುಂಬಾ ಕಷ್ಟವಾಗುತ್ತದೆ. ಬಳಕೆದಾರರ ವಿನಂತಿಗಳು.
ಒಂದು ಉದಾಹರಣೆ ಕೊಡುತ್ತೇನೆ. ಈಗ, ನಮ್ಮ ಮೂಲಸೌಕರ್ಯದೊಂದಿಗೆ, ನಾವು, ಉದಾಹರಣೆಗೆ, ಕೆಲವು ಸಮಸ್ಯೆಗಳು ಅಥವಾ ಭೂಗತ ಬಡಿತಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಯಂತ್ರಕ್ಕೆ ಹೋಗಿ ಮತ್ತು ಅಲ್ಲಿ ಸುತ್ತಲೂ ಅವ್ಯವಸ್ಥೆ ಮಾಡಬಹುದು, ತುಲನಾತ್ಮಕವಾಗಿ ಹೇಳುವುದಾದರೆ. ನಮಗೆ ಅಗತ್ಯವಿರುವ ಕೆಲವು ಮೆಟ್ರಿಕ್‌ಗಳ ಸಂಗ್ರಹವನ್ನು ನಾವು ಸೇರಿಸಬಹುದು, ನಾವು ಹೇಗಾದರೂ ಪ್ರಯೋಗ ಮಾಡಬಹುದು, ಇದು ಗ್ರಾಫ್‌ಗಳ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಿ, ಇತ್ಯಾದಿ. ಈಗ ಈ ಕ್ಯಾಶಿಂಗ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸಾಕಷ್ಟು ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸಲಾಗುತ್ತಿದೆ. ಮತ್ತು ನಾವು ನಿಯತಕಾಲಿಕವಾಗಿ ಅದನ್ನು ನೋಡುತ್ತೇವೆ ಮತ್ತು ಕೆಲವು ವೈಪರೀತ್ಯಗಳನ್ನು ಅನ್ವೇಷಿಸಲು ದೀರ್ಘಕಾಲ ಕಳೆಯುತ್ತೇವೆ. ಇದು ಸಿಡಿಎನ್ ಬದಿಯಲ್ಲಿದ್ದರೆ, ಅದನ್ನು ನಿಯಂತ್ರಿಸಲು ಹೆಚ್ಚು ಕಷ್ಟವಾಗುತ್ತದೆ. ಅಥವಾ, ಉದಾಹರಣೆಗೆ, ಕೆಲವು ರೀತಿಯ ಅಪಘಾತ ಸಂಭವಿಸಿದಲ್ಲಿ, ಏನಾಯಿತು ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ, ಅದರೊಂದಿಗೆ ಹೇಗೆ ಬದುಕಬೇಕು ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ಜಯಿಸಬೇಕು ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ. ಇದು ಮೊದಲ ತೀರ್ಮಾನವಾಗಿದೆ.
ಎರಡನೆಯ ತೀರ್ಮಾನವು ಐತಿಹಾಸಿಕವಾಗಿದೆ, ಏಕೆಂದರೆ ವ್ಯವಸ್ಥೆಯು ದೀರ್ಘಕಾಲದವರೆಗೆ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಿದೆ ಮತ್ತು ವಿವಿಧ ಹಂತಗಳಲ್ಲಿ ಹಲವಾರು ವಿಭಿನ್ನ ವ್ಯವಹಾರ ಅವಶ್ಯಕತೆಗಳು ಇದ್ದವು ಮತ್ತು ಅವು ಯಾವಾಗಲೂ CDN ಪರಿಕಲ್ಪನೆಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.
ಮತ್ತು ಹಿಂದಿನದರಿಂದ ಅನುಸರಿಸುವ ಅಂಶವಾಗಿದೆ
ಏಕೆಂದರೆ ಫೋಟೋ ಕ್ಯಾಷ್‌ಗಳಲ್ಲಿ ನಾವು ಸಾಕಷ್ಟು ನಿರ್ದಿಷ್ಟ ತರ್ಕವನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದನ್ನು ಯಾವಾಗಲೂ ವಿನಂತಿಯ ಮೇರೆಗೆ ಸೇರಿಸಲಾಗುವುದಿಲ್ಲ. ನಿಮ್ಮ ಕೋರಿಕೆಯ ಮೇರೆಗೆ ಯಾವುದೇ CDN ನಿಮಗೆ ಕೆಲವು ಕಸ್ಟಮ್ ವಿಷಯಗಳನ್ನು ಸೇರಿಸುವುದು ಅಸಂಭವವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಕ್ಲೈಂಟ್ ಏನನ್ನಾದರೂ ಬದಲಾಯಿಸಲು ನೀವು ಬಯಸದಿದ್ದರೆ URL ಗಳನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡುವುದು. ನೀವು ಸರ್ವರ್‌ನಲ್ಲಿ URL ಅನ್ನು ಬದಲಾಯಿಸಲು ಮತ್ತು ಅದನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲು ಬಯಸುವಿರಾ, ತದನಂತರ ಕೆಲವು ಡೈನಾಮಿಕ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಇಲ್ಲಿಗೆ ಕಳುಹಿಸಿ.
ಇದು ಯಾವ ತೀರ್ಮಾನವನ್ನು ಸೂಚಿಸುತ್ತದೆ? ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, CDN ಉತ್ತಮ ಪರ್ಯಾಯವಲ್ಲ.
ಮತ್ತು ನಿಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಯಾವುದೇ ನಿರ್ದಿಷ್ಟ ವ್ಯವಹಾರದ ಅವಶ್ಯಕತೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನಾನು ನಿಮಗೆ ತೋರಿಸಿದ್ದನ್ನು ನೀವು ಸುಲಭವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ಮತ್ತು ಇದೇ ರೀತಿಯ ಲೋಡ್ ಪ್ರೊಫೈಲ್‌ನೊಂದಿಗೆ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಆದರೆ ನೀವು ಕೆಲವು ರೀತಿಯ ಸಾಮಾನ್ಯ ಪರಿಹಾರವನ್ನು ಹೊಂದಿದ್ದರೆ, ಮತ್ತು ಕಾರ್ಯವು ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾಗಿಲ್ಲದಿದ್ದರೆ, ನೀವು ಸಂಪೂರ್ಣವಾಗಿ ಸುರಕ್ಷಿತವಾಗಿ ಸಿಡಿಎನ್ ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಅಥವಾ ಸಮಯ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳು ನಿಮಗೆ ನಿಯಂತ್ರಣಕ್ಕಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿದ್ದರೆ.
ಮತ್ತು ಆಧುನಿಕ CDN ಗಳು ನಾನು ಈಗ ನಿಮಗೆ ಹೇಳಿದ ಎಲ್ಲವನ್ನೂ ಹೊಂದಿವೆ. ಪ್ಲಸ್ ಅಥವಾ ಮೈನಸ್ ಕೆಲವು ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೊರತುಪಡಿಸಿ.
ಇದು ಫೋಟೋಗಳನ್ನು ನೀಡುವ ಬಗ್ಗೆ.
ಈಗ ನಮ್ಮ ಹಿನ್ನೋಟದಲ್ಲಿ ಸ್ವಲ್ಪ ಮುಂದಕ್ಕೆ ಹೋಗೋಣ ಮತ್ತು ಸಂಗ್ರಹಣೆಯ ಬಗ್ಗೆ ಮಾತನಾಡೋಣ.
2013 ದಾಟುತ್ತಿತ್ತು.
ಕ್ಯಾಶಿಂಗ್ ಸರ್ವರ್‌ಗಳನ್ನು ಸೇರಿಸಲಾಗಿದೆ, ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳು ದೂರವಾದವು. ಎಲ್ಲವು ಚೆನ್ನಾಗಿದೆ. ಡೇಟಾಸೆಟ್ ಬೆಳೆಯುತ್ತಿದೆ. 2013 ರ ಹೊತ್ತಿಗೆ, ನಾವು ಸುಮಾರು 80 ಸರ್ವರ್‌ಗಳನ್ನು ಸಂಗ್ರಹಣೆಗೆ ಸಂಪರ್ಕಿಸಿದ್ದೇವೆ ಮತ್ತು ಪ್ರತಿ DC ಯಲ್ಲಿ ಸುಮಾರು 40 ಕ್ಯಾಶಿಂಗ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಇದು ಪ್ರತಿ DC ಯಲ್ಲಿ 560 ಟೆರಾಬೈಟ್ ಡೇಟಾ, ಅಂದರೆ. ಒಟ್ಟು ಒಂದು ಪೆಟಾಬೈಟ್.
ಮತ್ತು ಡೇಟಾಸೆಟ್‌ನ ಬೆಳವಣಿಗೆಯೊಂದಿಗೆ, ನಿರ್ವಹಣಾ ವೆಚ್ಚಗಳು ಗಮನಾರ್ಹವಾಗಿ ಏರಲು ಪ್ರಾರಂಭಿಸಿದವು. ಇದರ ಅರ್ಥವೇನು?
ಚಿತ್ರಿಸಲಾದ ಈ ರೇಖಾಚಿತ್ರದಲ್ಲಿ - SAN ನೊಂದಿಗೆ, ಯಂತ್ರಗಳು ಮತ್ತು ಕ್ಯಾಶ್‌ಗಳೊಂದಿಗೆ ಸಂಪರ್ಕಗೊಂಡಿದೆ - ಬಹಳಷ್ಟು ವೈಫಲ್ಯದ ಅಂಶಗಳಿವೆ. ಕ್ಯಾಶಿಂಗ್ ಸರ್ವರ್‌ಗಳ ವೈಫಲ್ಯವನ್ನು ನಾವು ಮೊದಲೇ ನಿಭಾಯಿಸಿದ್ದರೆ, ಎಲ್ಲವೂ ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಊಹಿಸಬಹುದಾದ ಮತ್ತು ಅರ್ಥವಾಗುವಂತಹದ್ದಾಗಿತ್ತು, ಆದರೆ ಶೇಖರಣಾ ಭಾಗದಲ್ಲಿ ಎಲ್ಲವೂ ಹೆಚ್ಚು ಕೆಟ್ಟದಾಗಿದೆ.
ಮೊದಲನೆಯದಾಗಿ, ಸ್ಟೋರೇಜ್ ಏರಿಯಾ ನೆಟ್‌ವರ್ಕ್ (SAN) ಸ್ವತಃ ವಿಫಲವಾಗಬಹುದು.
ಎರಡನೆಯದಾಗಿ, ಇದು ಅಂತಿಮ ಯಂತ್ರಗಳಿಗೆ ಆಪ್ಟಿಕ್ಸ್ ಮೂಲಕ ಸಂಪರ್ಕ ಹೊಂದಿದೆ. ಆಪ್ಟಿಕಲ್ ಕಾರ್ಡ್‌ಗಳು ಮತ್ತು ಸ್ಪಾರ್ಕ್ ಪ್ಲಗ್‌ಗಳಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿರಬಹುದು.
ಸಹಜವಾಗಿ, SAN ನಂತೆ ಅವುಗಳಲ್ಲಿ ಹಲವು ಇಲ್ಲ, ಆದರೆ, ಆದಾಗ್ಯೂ, ಇವುಗಳು ವೈಫಲ್ಯದ ಅಂಶಗಳಾಗಿವೆ.
ಮುಂದೆ ಯಂತ್ರವು ಸ್ವತಃ, ಇದು ಸಂಗ್ರಹಣೆಗೆ ಸಂಪರ್ಕ ಹೊಂದಿದೆ. ಇದು ವಿಫಲವಾಗಬಹುದು.
ಒಟ್ಟಾರೆಯಾಗಿ, ನಾವು ವೈಫಲ್ಯದ ಮೂರು ಅಂಶಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ಇದಲ್ಲದೆ, ವೈಫಲ್ಯದ ಬಿಂದುಗಳ ಜೊತೆಗೆ, ಸಂಗ್ರಹಣೆಯ ಭಾರೀ ನಿರ್ವಹಣೆ ಇದೆ.
ಇದು ಸಂಕೀರ್ಣ ಬಹು-ಘಟಕ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ ಮತ್ತು ಸಿಸ್ಟಮ್ ಎಂಜಿನಿಯರ್‌ಗಳು ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಕಷ್ಟವಾಗಬಹುದು.
ಮತ್ತು ಕೊನೆಯ, ಪ್ರಮುಖ ಅಂಶ. ಈ ಮೂರು ಬಿಂದುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ವೈಫಲ್ಯ ಸಂಭವಿಸಿದಲ್ಲಿ, ಫೈಲ್ ಸಿಸ್ಟಮ್ ಕ್ರ್ಯಾಶ್ ಆಗಬಹುದಾದ ಕಾರಣ ಬಳಕೆದಾರರ ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ಶೂನ್ಯವಲ್ಲದ ಅವಕಾಶವನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ.
ನಮ್ಮ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಕೆಟ್ಟುಹೋಗಿದೆ ಎಂದು ಹೇಳೋಣ. ಮೊದಲನೆಯದಾಗಿ, ಅದರ ಚೇತರಿಕೆಯು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ - ಇದು ದೊಡ್ಡ ಪ್ರಮಾಣದ ಡೇಟಾದೊಂದಿಗೆ ಒಂದು ವಾರ ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಮತ್ತು ಎರಡನೆಯದಾಗಿ, ಕೊನೆಯಲ್ಲಿ ನಾವು ಗ್ರಹಿಸಲಾಗದ ಫೈಲ್‌ಗಳ ಗುಂಪಿನೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತೇವೆ, ಅದನ್ನು ಹೇಗಾದರೂ ಬಳಕೆದಾರರ ಫೋಟೋಗಳಾಗಿ ಸಂಯೋಜಿಸಬೇಕಾಗುತ್ತದೆ. ಮತ್ತು ನಾವು ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ಅಪಾಯವಿದೆ. ಅಪಾಯವು ಸಾಕಷ್ಟು ಹೆಚ್ಚಾಗಿದೆ. ಮತ್ತು ಅಂತಹ ಸಂದರ್ಭಗಳು ಹೆಚ್ಚಾಗಿ ಸಂಭವಿಸುತ್ತವೆ, ಮತ್ತು ಈ ಸಂಪೂರ್ಣ ಸರಪಳಿಯಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸುತ್ತವೆ, ಈ ಅಪಾಯವು ಹೆಚ್ಚಾಗುತ್ತದೆ.
ಈ ಬಗ್ಗೆ ಏನಾದರೂ ಮಾಡಬೇಕಿತ್ತು. ಮತ್ತು ನಾವು ಡೇಟಾವನ್ನು ಬ್ಯಾಕಪ್ ಮಾಡಬೇಕಾಗಿದೆ ಎಂದು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಇದು ವಾಸ್ತವವಾಗಿ ಸ್ಪಷ್ಟ ಪರಿಹಾರವಾಗಿದೆ ಮತ್ತು ಉತ್ತಮವಾಗಿದೆ. ನಾವೇನು ಮಾಡಿದ್ದೇವೆ?
ನಮ್ಮ ಸರ್ವರ್ ಅನ್ನು ಮೊದಲು ಸಂಗ್ರಹಣೆಗೆ ಸಂಪರ್ಕಿಸಿದಾಗ ಇದು ಹೇಗಿತ್ತು. ಇದು ಒಂದು ಮುಖ್ಯ ವಿಭಾಗವಾಗಿದೆ, ಇದು ಕೇವಲ ಒಂದು ಬ್ಲಾಕ್ ಸಾಧನವಾಗಿದ್ದು ಅದು ದೃಗ್ವಿಜ್ಞಾನದ ಮೂಲಕ ದೂರಸ್ಥ ಸಂಗ್ರಹಣೆಗಾಗಿ ಆರೋಹಣವನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ.
ನಾವು ಎರಡನೇ ವಿಭಾಗವನ್ನು ಸೇರಿಸಿದ್ದೇವೆ.
ನಾವು ಅದರ ಪಕ್ಕದಲ್ಲಿ ಎರಡನೇ ಸಂಗ್ರಹಣೆಯನ್ನು ಇರಿಸಿದ್ದೇವೆ (ಅದೃಷ್ಟವಶಾತ್, ಹಣದ ವಿಷಯದಲ್ಲಿ ಅದು ದುಬಾರಿ ಅಲ್ಲ), ಮತ್ತು ಅದನ್ನು ಬ್ಯಾಕಪ್ ವಿಭಾಗ ಎಂದು ಕರೆದಿದೆ. ಇದು ಆಪ್ಟಿಕ್ಸ್ ಮೂಲಕ ಸಂಪರ್ಕ ಹೊಂದಿದೆ ಮತ್ತು ಅದೇ ಯಂತ್ರದಲ್ಲಿ ಇದೆ. ಆದರೆ ನಾವು ಅವುಗಳ ನಡುವೆ ಡೇಟಾವನ್ನು ಹೇಗಾದರೂ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಬೇಕಾಗಿದೆ.
ಇಲ್ಲಿ ನಾವು ಸರಳವಾಗಿ ಹತ್ತಿರದಲ್ಲಿ ಅಸಮಕಾಲಿಕ ಕ್ಯೂ ಅನ್ನು ಮಾಡುತ್ತೇವೆ.
ಅವಳು ತುಂಬಾ ಬ್ಯುಸಿ ಇಲ್ಲ. ನಮ್ಮ ಬಳಿ ಸಾಕಷ್ಟು ದಾಖಲೆಗಳಿಲ್ಲ ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ. ಸರತಿಯು MySQL ನಲ್ಲಿ ಕೇವಲ ಒಂದು ಟೇಬಲ್ ಆಗಿದ್ದು ಇದರಲ್ಲಿ "ನೀವು ಈ ಫೋಟೋವನ್ನು ಬ್ಯಾಕಪ್ ಮಾಡಬೇಕಾಗಿದೆ" ನಂತಹ ಸಾಲುಗಳನ್ನು ಬರೆಯಲಾಗಿದೆ. ಯಾವುದೇ ಬದಲಾವಣೆ ಅಥವಾ ಅಪ್ಲೋಡ್ನೊಂದಿಗೆ, ಅಸಮಕಾಲಿಕ ಅಥವಾ ಕೆಲವು ರೀತಿಯ ಹಿನ್ನೆಲೆ ಕೆಲಸಗಾರರನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಮುಖ್ಯ ವಿಭಾಗದಿಂದ ಬ್ಯಾಕಪ್‌ಗೆ ನಕಲಿಸುತ್ತೇವೆ.
ಮತ್ತು ಆದ್ದರಿಂದ ನಾವು ಯಾವಾಗಲೂ ಎರಡು ಸ್ಥಿರ ವಿಭಾಗಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಈ ವ್ಯವಸ್ಥೆಯ ಒಂದು ಭಾಗವು ವಿಫಲವಾದರೂ ಸಹ, ನಾವು ಯಾವಾಗಲೂ ಮುಖ್ಯ ವಿಭಾಗವನ್ನು ಬ್ಯಾಕ್ಅಪ್ನೊಂದಿಗೆ ಬದಲಾಯಿಸಬಹುದು, ಮತ್ತು ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡಲು ಮುಂದುವರಿಯುತ್ತದೆ.
ಆದರೆ ಈ ಕಾರಣದಿಂದಾಗಿ, ಓದುವ ಹೊರೆ ಬಹಳವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ, ಏಕೆಂದರೆ... ಮುಖ್ಯ ವಿಭಾಗದಿಂದ ಓದುವ ಕ್ಲೈಂಟ್‌ಗಳ ಜೊತೆಗೆ, ಅವರು ಮೊದಲು ಫೋಟೋವನ್ನು ನೋಡುತ್ತಾರೆ (ಅದು ಅಲ್ಲಿ ಇತ್ತೀಚಿನದು), ಮತ್ತು ನಂತರ ಅದನ್ನು ಬ್ಯಾಕ್‌ಅಪ್‌ನಲ್ಲಿ ನೋಡಿ, ಅವರು ಅದನ್ನು ಕಂಡುಹಿಡಿಯದಿದ್ದರೆ (ಆದರೆ NGINX ಇದನ್ನು ಮಾಡುತ್ತದೆ), ನಮ್ಮ ಸಿಸ್ಟಮ್ ಕೂಡ ಒಂದು ಪ್ಲಸ್ ಬ್ಯಾಕ್‌ಅಪ್ ಆಗಿದೆ, ಈಗ ಮುಖ್ಯ ವಿಭಾಗದಿಂದ ಓದಲಾಗುತ್ತದೆ. ಇದು ಅಡಚಣೆಯಾಗಿದೆ ಎಂದು ಅಲ್ಲ, ಆದರೆ ನಾನು ಲೋಡ್ ಅನ್ನು ಹೆಚ್ಚಿಸಲು ಬಯಸುವುದಿಲ್ಲ, ಮೂಲಭೂತವಾಗಿ, ಅದರಂತೆಯೇ.
ಮತ್ತು ನಾವು ಮೂರನೇ ಡಿಸ್ಕ್ ಅನ್ನು ಸೇರಿಸಿದ್ದೇವೆ, ಅದು ಸಣ್ಣ SSD ಆಗಿದೆ ಮತ್ತು ಅದನ್ನು ಬಫರ್ ಎಂದು ಕರೆದಿದೆ.
ಇದು ಈಗ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ.
ಬಳಕೆದಾರರು ಬಫರ್‌ಗೆ ಫೋಟೋವನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡುತ್ತಾರೆ, ನಂತರ ಈವೆಂಟ್ ಅನ್ನು ಎರಡು ವಿಭಾಗಗಳಾಗಿ ನಕಲು ಮಾಡಬೇಕೆಂದು ಸೂಚಿಸುವ ಸರದಿಯಲ್ಲಿ ಎಸೆಯಲಾಗುತ್ತದೆ. ಅದನ್ನು ನಕಲಿಸಲಾಗಿದೆ, ಮತ್ತು ಫೋಟೋ ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಬಫರ್‌ನಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ (ಹೇಳಿ, ಒಂದು ದಿನ), ಮತ್ತು ನಂತರ ಮಾತ್ರ ಅಲ್ಲಿಂದ ಶುದ್ಧೀಕರಿಸಲಾಗುತ್ತದೆ. ಇದು ಬಳಕೆದಾರರ ಅನುಭವವನ್ನು ಹೆಚ್ಚು ಸುಧಾರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಬಳಕೆದಾರರು ಫೋಟೋವನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡುತ್ತಾರೆ, ನಿಯಮದಂತೆ, ವಿನಂತಿಗಳು ತಕ್ಷಣವೇ ಅನುಸರಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ, ಅಥವಾ ಅವನು ಸ್ವತಃ ಪುಟವನ್ನು ನವೀಕರಿಸಿ ಮತ್ತು ಅದನ್ನು ರಿಫ್ರೆಶ್ ಮಾಡುತ್ತಾನೆ. ಆದರೆ ಇದು ಅಪ್ಲೋಡ್ ಮಾಡುವ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.
ಅಥವಾ, ಉದಾಹರಣೆಗೆ, ಅವನು ತನ್ನನ್ನು ತೋರಿಸಲು ಪ್ರಾರಂಭಿಸಿದ ಇತರ ಜನರು ಈ ಫೋಟೋದ ನಂತರ ತಕ್ಷಣವೇ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ. ಇದು ಇನ್ನೂ ಸಂಗ್ರಹದಲ್ಲಿಲ್ಲ; ಮೊದಲ ವಿನಂತಿಯು ಬಹಳ ಬೇಗನೆ ಸಂಭವಿಸುತ್ತದೆ. ಮೂಲಭೂತವಾಗಿ ಫೋಟೋ ಸಂಗ್ರಹದಂತೆಯೇ ಇರುತ್ತದೆ. ನಿಧಾನ ಸಂಗ್ರಹಣೆಯು ಇದರಲ್ಲಿ ಭಾಗಿಯಾಗಿಲ್ಲ. ಮತ್ತು ಒಂದು ದಿನದ ನಂತರ ಅದನ್ನು ಶುದ್ಧೀಕರಿಸಿದಾಗ, ಅದು ಈಗಾಗಲೇ ನಮ್ಮ ಕ್ಯಾಶಿಂಗ್ ಲೇಯರ್‌ನಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿದೆ, ಅಥವಾ, ಹೆಚ್ಚಾಗಿ, ಯಾರಿಗೂ ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲ. ಆ. ಇಂತಹ ಸರಳ ಕುಶಲತೆಗಳಿಂದಾಗಿ ಇಲ್ಲಿ ಬಳಕೆದಾರರ ಅನುಭವವು ಚೆನ್ನಾಗಿ ಬೆಳೆದಿದೆ.
ಒಳ್ಳೆಯದು, ಮತ್ತು ಮುಖ್ಯವಾಗಿ: ನಾವು ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದನ್ನು ನಿಲ್ಲಿಸಿದ್ದೇವೆ.
ನಾವು ನಿಲ್ಲಿಸಿದ್ದೇವೆ ಎಂದು ಹೇಳೋಣ ಸಮರ್ಥವಾಗಿ ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳಿ, ಏಕೆಂದರೆ ನಾವು ಅದನ್ನು ನಿಜವಾಗಿಯೂ ಕಳೆದುಕೊಳ್ಳಲಿಲ್ಲ. ಆದರೆ ಅಪಾಯವಿತ್ತು. ಈ ಪರಿಹಾರವು ಖಂಡಿತವಾಗಿಯೂ ಒಳ್ಳೆಯದು ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ, ಆದರೆ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಪರಿಹರಿಸುವ ಬದಲು ಸಮಸ್ಯೆಯ ಲಕ್ಷಣಗಳನ್ನು ಸುಗಮಗೊಳಿಸುವಂತಿದೆ. ಮತ್ತು ಕೆಲವು ಸಮಸ್ಯೆಗಳು ಇಲ್ಲಿ ಉಳಿದಿವೆ.
ಮೊದಲನೆಯದಾಗಿ, ಇದು ಭೌತಿಕ ಆತಿಥೇಯದ ರೂಪದಲ್ಲಿ ವೈಫಲ್ಯದ ಹಂತವಾಗಿದೆ, ಅದರ ಮೇಲೆ ಈ ಎಲ್ಲಾ ಯಂತ್ರಗಳು ಚಲಿಸುತ್ತವೆ; ಅದು ದೂರ ಹೋಗಿಲ್ಲ.
ಎರಡನೆಯದಾಗಿ, SAN ಗಳಲ್ಲಿ ಇನ್ನೂ ಸಮಸ್ಯೆಗಳಿವೆ, ಅವುಗಳ ಭಾರೀ ನಿರ್ವಹಣೆ ಇತ್ಯಾದಿಗಳು ಉಳಿದಿವೆ. ಇದು ನಿರ್ಣಾಯಕ ಅಂಶವಲ್ಲ, ಆದರೆ ಅದು ಇಲ್ಲದೆ ಹೇಗಾದರೂ ಬದುಕಲು ಪ್ರಯತ್ನಿಸಲು ನಾನು ಬಯಸುತ್ತೇನೆ.
ಮತ್ತು ನಾವು ಮೂರನೇ ಆವೃತ್ತಿಯನ್ನು ಮಾಡಿದ್ದೇವೆ (ವಾಸ್ತವವಾಗಿ, ಎರಡನೆಯದು ವಾಸ್ತವವಾಗಿ) - ಮೀಸಲಾತಿ ಆವೃತ್ತಿ. ಅದು ಹೇಗಿತ್ತು?
ಅದು ಹೀಗಿತ್ತು -
ಇದು ಭೌತಿಕ ಹೋಸ್ಟ್ ಎಂಬ ಅಂಶದೊಂದಿಗೆ ನಮ್ಮ ಮುಖ್ಯ ಸಮಸ್ಯೆಗಳು.
ಮೊದಲನೆಯದಾಗಿ, ನಾವು SAN ಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತಿದ್ದೇವೆ ಏಕೆಂದರೆ ನಾವು ಪ್ರಯೋಗ ಮಾಡಲು ಬಯಸುತ್ತೇವೆ, ನಾವು ಕೇವಲ ಸ್ಥಳೀಯ ಹಾರ್ಡ್ ಡ್ರೈವ್‌ಗಳನ್ನು ಪ್ರಯತ್ನಿಸಲು ಬಯಸುತ್ತೇವೆ.
ಇದು ಈಗಾಗಲೇ 2014-2015 ಆಗಿದೆ, ಮತ್ತು ಆ ಸಮಯದಲ್ಲಿ ಡಿಸ್ಕ್ಗಳೊಂದಿಗಿನ ಪರಿಸ್ಥಿತಿ ಮತ್ತು ಒಂದು ಹೋಸ್ಟ್ನಲ್ಲಿ ಅವುಗಳ ಸಾಮರ್ಥ್ಯವು ಹೆಚ್ಚು ಉತ್ತಮವಾಯಿತು. ಅದನ್ನು ಏಕೆ ಪ್ರಯತ್ನಿಸಬಾರದು ಎಂದು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.
ತದನಂತರ ನಾವು ನಮ್ಮ ಬ್ಯಾಕಪ್ ವಿಭಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಭೌತಿಕವಾಗಿ ಪ್ರತ್ಯೇಕ ಯಂತ್ರಕ್ಕೆ ವರ್ಗಾಯಿಸುತ್ತೇವೆ.
ಹೀಗಾಗಿ, ನಾವು ಈ ರೇಖಾಚಿತ್ರವನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಒಂದೇ ಡೇಟಾಸೆಟ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಎರಡು ಕಾರುಗಳನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ. ಅವರು ಪರಸ್ಪರ ಸಂಪೂರ್ಣವಾಗಿ ಬ್ಯಾಕಪ್ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅದೇ MySQL ನಲ್ಲಿ ಅಸಮಕಾಲಿಕ ಕ್ಯೂ ಮೂಲಕ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುತ್ತಾರೆ.
ನಮ್ಮಲ್ಲಿ ಕೆಲವು ದಾಖಲೆಗಳು ಇರುವುದರಿಂದ ಇದು ಏಕೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆ. ಬರವಣಿಗೆಯನ್ನು ಓದುವುದಕ್ಕೆ ಹೋಲಿಸಬಹುದಾದರೆ, ಬಹುಶಃ ನಾವು ಕೆಲವು ರೀತಿಯ ನೆಟ್‌ವರ್ಕ್ ಓವರ್‌ಹೆಡ್ ಮತ್ತು ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿರಬಹುದು. ಸ್ವಲ್ಪ ಬರವಣಿಗೆ ಇದೆ, ಬಹಳಷ್ಟು ಓದುವಿಕೆ ಇದೆ - ಈ ವಿಧಾನವು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಅಂದರೆ. ಈ ಎರಡು ಸರ್ವರ್‌ಗಳ ನಡುವೆ ನಾವು ಫೋಟೋಗಳನ್ನು ಅಪರೂಪವಾಗಿ ನಕಲಿಸುತ್ತೇವೆ.
ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ನೀವು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ವಿವರವಾಗಿ ನೋಡಿದರೆ.
ಅಪ್ಲೋಡ್ ಮಾಡಿ. ಬ್ಯಾಲೆನ್ಸರ್ ಸರಳವಾಗಿ ಜೋಡಿಯೊಂದಿಗೆ ಯಾದೃಚ್ಛಿಕ ಹೋಸ್ಟ್‌ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದಕ್ಕೆ ಅಪ್ಲೋಡ್ ಮಾಡುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಅವರು ಸ್ವಾಭಾವಿಕವಾಗಿ ಆರೋಗ್ಯ ತಪಾಸಣೆ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಕಾರು ಬೀಳದಂತೆ ನೋಡಿಕೊಳ್ಳುತ್ತಾರೆ. ಆ. ಅವನು ಫೋಟೋಗಳನ್ನು ಲೈವ್ ಸರ್ವರ್‌ಗೆ ಮಾತ್ರ ಅಪ್ಲೋಡ್ ಮಾಡುತ್ತಾನೆ ಮತ್ತು ನಂತರ ಅಸಮಕಾಲಿಕ ಸರದಿಯ ಮೂಲಕ ಎಲ್ಲವನ್ನೂ ಅವನ ನೆರೆಹೊರೆಯವರಿಗೆ ನಕಲಿಸಲಾಗುತ್ತದೆ. ಅಪ್ಲೋಡ್ನೊಂದಿಗೆ ಎಲ್ಲವೂ ತುಂಬಾ ಸರಳವಾಗಿದೆ.
ಕಾರ್ಯವು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿದೆ.
ಲುವಾ ಇಲ್ಲಿ ನಮಗೆ ಸಹಾಯ ಮಾಡಿದರು, ಏಕೆಂದರೆ ವೆನಿಲ್ಲಾ NGINX ನಲ್ಲಿ ಅಂತಹ ತರ್ಕವನ್ನು ಮಾಡಲು ಕಷ್ಟವಾಗುತ್ತದೆ. ನಾವು ಮೊದಲು ಮೊದಲ ಸರ್ವರ್‌ಗೆ ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತೇವೆ, ಫೋಟೋ ಇದೆಯೇ ಎಂದು ನೋಡಿ, ಏಕೆಂದರೆ ಸಂಭಾವ್ಯವಾಗಿ ಅದನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡಬಹುದು, ಉದಾಹರಣೆಗೆ, ನೆರೆಹೊರೆಯವರಿಗೆ, ಆದರೆ ಇನ್ನೂ ಇಲ್ಲಿಗೆ ಬಂದಿಲ್ಲ. ಫೋಟೋ ಇದ್ದರೆ ಒಳ್ಳೆಯದು. ನಾವು ತಕ್ಷಣ ಅದನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ನೀಡುತ್ತೇವೆ ಮತ್ತು ಪ್ರಾಯಶಃ ಅದನ್ನು ಕ್ಯಾಶ್ ಮಾಡುತ್ತೇವೆ.
ಅದು ಇಲ್ಲದಿದ್ದರೆ, ನಾವು ನಮ್ಮ ನೆರೆಹೊರೆಯವರಲ್ಲಿ ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಅಲ್ಲಿಂದ ಅದನ್ನು ಸ್ವೀಕರಿಸುವ ಭರವಸೆ ಇದೆ.
ಅದು. ಮತ್ತೊಮ್ಮೆ ನಾವು ಹೇಳಬಹುದು: ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿರಬಹುದು, ಏಕೆಂದರೆ ನಿರಂತರ ರೌಂಡ್ ಟ್ರಿಪ್‌ಗಳಿವೆ - ಫೋಟೋವನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡಲಾಗಿದೆ, ಅದು ಇಲ್ಲಿಲ್ಲ, ನಾವು ಒಂದರ ಬದಲಿಗೆ ಎರಡು ವಿನಂತಿಗಳನ್ನು ಮಾಡುತ್ತಿದ್ದೇವೆ, ಇದು ನಿಧಾನವಾಗಿ ಕೆಲಸ ಮಾಡಬೇಕು.
ನಮ್ಮ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಇದು ನಿಧಾನವಾಗಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.
ಈ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ನಾವು ಮೆಟ್ರಿಕ್‌ಗಳ ಗುಂಪನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಮತ್ತು ಅಂತಹ ಕಾರ್ಯವಿಧಾನದ ಷರತ್ತುಬದ್ಧ ಸ್ಮಾರ್ಟ್ ದರವು ಸುಮಾರು 95% ಆಗಿದೆ. ಆ. ಈ ಬ್ಯಾಕ್‌ಅಪ್‌ನ ವಿಳಂಬವು ಚಿಕ್ಕದಾಗಿದೆ ಮತ್ತು ಇದರಿಂದಾಗಿ ನಾವು ಬಹುತೇಕ ಖಾತರಿಪಡಿಸುತ್ತೇವೆ, ಫೋಟೋವನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡಿದ ನಂತರ, ನಾವು ಅದನ್ನು ಮೊದಲ ಬಾರಿಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಎರಡು ಬಾರಿ ಎಲ್ಲಿಯೂ ಹೋಗಬೇಕಾಗಿಲ್ಲ.
ಹಾಗಾದರೆ ನಿಜವಾಗಿಯೂ ತಂಪಾಗಿರುವ ಬೇರೆ ಯಾವುದನ್ನು ನಾವು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ?
ಹಿಂದೆ, ನಾವು ಮುಖ್ಯ ಬ್ಯಾಕಪ್ ವಿಭಾಗವನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಅವರಿಂದ ಅನುಕ್ರಮವಾಗಿ ಓದುತ್ತೇವೆ. ಆ. ನಾವು ಯಾವಾಗಲೂ ಮುಖ್ಯವಾದುದನ್ನು ಮೊದಲು ಹುಡುಕುತ್ತೇವೆ ಮತ್ತು ನಂತರ ಬ್ಯಾಕಪ್‌ನಲ್ಲಿ ಹುಡುಕುತ್ತೇವೆ. ಇದು ಒಂದು ನಡೆಯಾಗಿತ್ತು.
ಈಗ ನಾವು ಏಕಕಾಲದಲ್ಲಿ ಎರಡು ಯಂತ್ರಗಳಿಂದ ಓದುವಿಕೆಯನ್ನು ಬಳಸುತ್ತೇವೆ. ನಾವು ರೌಂಡ್ ರಾಬಿನ್ ಬಳಸಿ ವಿನಂತಿಗಳನ್ನು ವಿತರಿಸುತ್ತೇವೆ. ಸಣ್ಣ ಶೇಕಡಾವಾರು ಪ್ರಕರಣಗಳಲ್ಲಿ ನಾವು ಎರಡು ವಿನಂತಿಗಳನ್ನು ಮಾಡುತ್ತೇವೆ. ಆದರೆ ಒಟ್ಟಾರೆಯಾಗಿ ಹೇಳುವುದಾದರೆ, ಈಗ ನಾವು ಮೊದಲು ಹೊಂದಿದ್ದಕ್ಕಿಂತ ಎರಡು ಪಟ್ಟು ಹೆಚ್ಚು ಓದುವ ಸ್ಟಾಕ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು ಕಳುಹಿಸುವ ಯಂತ್ರಗಳ ಮೇಲೆ ಮತ್ತು ನೇರವಾಗಿ ಶೇಖರಣಾ ಯಂತ್ರಗಳ ಮೇಲೆ ಹೊರೆ ಬಹಳವಾಗಿ ಕಡಿಮೆಯಾಯಿತು, ಆ ಸಮಯದಲ್ಲಿ ನಾವು ಹೊಂದಿದ್ದೇವೆ.
ತಪ್ಪು ಸಹಿಷ್ಣುತೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ. ವಾಸ್ತವವಾಗಿ, ನಾವು ಮುಖ್ಯವಾಗಿ ಹೋರಾಡಿದ್ದು ಇದಕ್ಕಾಗಿಯೇ. ತಪ್ಪು ಸಹಿಷ್ಣುತೆಯೊಂದಿಗೆ, ಇಲ್ಲಿ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ.
ಒಂದು ಕಾರು ಕೆಟ್ಟು ನಿಂತಿದೆ.
ಯಾವ ತೊಂದರೆಯಿಲ್ಲ! ಸಿಸ್ಟಮ್ ಇಂಜಿನಿಯರ್ ರಾತ್ರಿಯಲ್ಲಿ ಎಚ್ಚರಗೊಳ್ಳದಿರಬಹುದು, ಅವನು ಬೆಳಿಗ್ಗೆ ತನಕ ಕಾಯುತ್ತಾನೆ, ಕೆಟ್ಟದ್ದೇನೂ ಆಗುವುದಿಲ್ಲ.
ಈ ಯಂತ್ರವು ವಿಫಲವಾದರೂ, ಸರತಿಯು ಸರಿಯಾಗಿಲ್ಲ, ಯಾವುದೇ ತೊಂದರೆಗಳಿಲ್ಲ, ಲಾಗ್ ಅನ್ನು ಮೊದಲು ಲಿವಿಂಗ್ ಮೆಷಿನ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಅದನ್ನು ಕ್ಯೂಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಕಾರಿಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ. ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ಕಾರ್ಯಾಚರಣೆಗೆ ಹೋಗಿ.
ನಿರ್ವಹಣೆಯೊಂದಿಗೆ ಅದೇ ವಿಷಯ. ನಾವು ಯಂತ್ರಗಳಲ್ಲಿ ಒಂದನ್ನು ಸರಳವಾಗಿ ಆಫ್ ಮಾಡುತ್ತೇವೆ, ಅದನ್ನು ಎಲ್ಲಾ ಪೂಲ್‌ಗಳಿಂದ ಹಸ್ತಚಾಲಿತವಾಗಿ ಹೊರತೆಗೆಯುತ್ತೇವೆ, ಅದು ದಟ್ಟಣೆಯನ್ನು ಪಡೆಯುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ನಾವು ಕೆಲವು ರೀತಿಯ ನಿರ್ವಹಣೆಯನ್ನು ಮಾಡುತ್ತೇವೆ, ನಾವು ಏನನ್ನಾದರೂ ಸಂಪಾದಿಸುತ್ತೇವೆ, ನಂತರ ನಾವು ಅದನ್ನು ಸೇವೆಗೆ ಹಿಂತಿರುಗಿಸುತ್ತೇವೆ ಮತ್ತು ಈ ಬ್ಯಾಕ್‌ಅಪ್ ತ್ವರಿತವಾಗಿ ಹಿಡಿಯುತ್ತದೆ. ಆ. ದಿನಕ್ಕೆ, ಒಂದು ಕಾರಿನ ಅಲಭ್ಯತೆಯು ಒಂದೆರಡು ನಿಮಿಷಗಳಲ್ಲಿ ಹಿಡಿಯುತ್ತದೆ. ಇದು ನಿಜವಾಗಿಯೂ ಬಹಳ ಕಡಿಮೆ. ತಪ್ಪು ಸಹಿಷ್ಣುತೆಯೊಂದಿಗೆ, ನಾನು ಮತ್ತೊಮ್ಮೆ ಹೇಳುತ್ತೇನೆ, ಇಲ್ಲಿ ಎಲ್ಲವೂ ತಂಪಾಗಿದೆ.
ಈ ಪುನರುಜ್ಜೀವನ ಯೋಜನೆಯಿಂದ ಯಾವ ತೀರ್ಮಾನಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು?
ನಮಗೆ ತಪ್ಪು ಸಹಿಷ್ಣುತೆ ಸಿಕ್ಕಿತು.
ಬಳಸಲು ಸುಲಭ. ಯಂತ್ರಗಳು ಸ್ಥಳೀಯ ಹಾರ್ಡ್ ಡ್ರೈವ್‌ಗಳನ್ನು ಹೊಂದಿರುವುದರಿಂದ, ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಎಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಕಾರ್ಯಾಚರಣೆಯ ದೃಷ್ಟಿಕೋನದಿಂದ ಇದು ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿದೆ.
ನಾವು ಎರಡು ಬಾರಿ ಓದುವ ಭತ್ಯೆಯನ್ನು ಪಡೆದಿದ್ದೇವೆ.
ತಪ್ಪು ಸಹಿಷ್ಣುತೆಯ ಜೊತೆಗೆ ಇದು ಉತ್ತಮ ಬೋನಸ್ ಆಗಿದೆ.
ಆದರೆ ಸಮಸ್ಯೆಗಳೂ ಇವೆ. ಈಗ ನಾವು ಇದಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಕೆಲವು ವೈಶಿಷ್ಟ್ಯಗಳ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಅಭಿವೃದ್ಧಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಏಕೆಂದರೆ ಸಿಸ್ಟಮ್ ಅಂತಿಮವಾಗಿ 100% ಸ್ಥಿರವಾಗಿದೆ.
ಕೆಲವು ಹಿನ್ನೆಲೆ ಕೆಲಸದಲ್ಲಿ ನಾವು ನಿರಂತರವಾಗಿ ಯೋಚಿಸಬೇಕು: "ನಾವು ಈಗ ಯಾವ ಸರ್ವರ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತಿದ್ದೇವೆ?", "ನಿಜವಾಗಿಯೂ ಇಲ್ಲಿ ಪ್ರಸ್ತುತ ಫೋಟೋ ಇದೆಯೇ?" ಇತ್ಯಾದಿ ಇದು ಸಹಜವಾಗಿ, ಎಲ್ಲವನ್ನೂ ಸುತ್ತುವರೆದಿದೆ ಮತ್ತು ವ್ಯವಹಾರ ತರ್ಕವನ್ನು ಬರೆಯುವ ಪ್ರೋಗ್ರಾಮರ್ಗೆ ಇದು ಪಾರದರ್ಶಕವಾಗಿರುತ್ತದೆ. ಆದರೆ, ಅದೇನೇ ಇದ್ದರೂ, ಈ ದೊಡ್ಡ ಸಂಕೀರ್ಣ ಪದರವು ಕಾಣಿಸಿಕೊಂಡಿದೆ. ಆದರೆ ಅದರಿಂದ ನಾವು ಪಡೆದ ಒಳ್ಳೆಯತನಕ್ಕೆ ಬದಲಾಗಿ ನಾವು ಇದನ್ನು ಸಹಿಸಿಕೊಳ್ಳಲು ಸಿದ್ಧರಿದ್ದೇವೆ.
ಮತ್ತು ಇಲ್ಲಿ ಮತ್ತೆ ಕೆಲವು ಸಂಘರ್ಷಗಳು ಉದ್ಭವಿಸುತ್ತವೆ.
ಸ್ಥಳೀಯ ಹಾರ್ಡ್ ಡ್ರೈವ್‌ಗಳಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ಸಂಗ್ರಹಿಸುವುದು ಕೆಟ್ಟದು ಎಂದು ನಾನು ಆರಂಭದಲ್ಲಿ ಹೇಳಿದೆ. ಮತ್ತು ಈಗ ನಾವು ಅದನ್ನು ಇಷ್ಟಪಟ್ಟಿದ್ದೇವೆ ಎಂದು ನಾನು ಹೇಳುತ್ತೇನೆ.
ಹೌದು, ವಾಸ್ತವವಾಗಿ, ಕಾಲಾನಂತರದಲ್ಲಿ ಪರಿಸ್ಥಿತಿಯು ಬಹಳಷ್ಟು ಬದಲಾಗಿದೆ, ಮತ್ತು ಈಗ ಈ ವಿಧಾನವು ಅನೇಕ ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿದೆ. ಮೊದಲನೆಯದಾಗಿ, ನಾವು ಹೆಚ್ಚು ಸರಳವಾದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪಡೆಯುತ್ತೇವೆ.
ಎರಡನೆಯದಾಗಿ, ಇದು ಹೆಚ್ಚು ಉತ್ಪಾದಕವಾಗಿದೆ, ಏಕೆಂದರೆ ನಾವು ಈ ಸ್ವಯಂಚಾಲಿತ ನಿಯಂತ್ರಕಗಳು ಅಥವಾ ಡಿಸ್ಕ್ ಕಪಾಟಿನಲ್ಲಿ ಸಂಪರ್ಕಗಳನ್ನು ಹೊಂದಿಲ್ಲ.
ಅಲ್ಲಿ ದೊಡ್ಡ ಪ್ರಮಾಣದ ಯಂತ್ರೋಪಕರಣಗಳಿವೆ, ಮತ್ತು ಇವುಗಳು ಕೇವಲ ಕೆಲವು ಡಿಸ್ಕ್‌ಗಳಾಗಿದ್ದು, ಇವುಗಳನ್ನು ಯಂತ್ರದ ಮೇಲೆ ದಾಳಿಯಾಗಿ ಇಲ್ಲಿ ಜೋಡಿಸಲಾಗಿದೆ.
ಆದರೆ ಅನಾನುಕೂಲಗಳೂ ಇವೆ.
ಇಂದಿನ ಬೆಲೆಗಳಲ್ಲಿಯೂ ಸಹ SAN ಗಳನ್ನು ಬಳಸುವುದಕ್ಕಿಂತ ಇದು ಸರಿಸುಮಾರು 1,5 ಪಟ್ಟು ಹೆಚ್ಚು ದುಬಾರಿಯಾಗಿದೆ. ಆದ್ದರಿಂದ, ನಮ್ಮ ಸಂಪೂರ್ಣ ದೊಡ್ಡ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸ್ಥಳೀಯ ಹಾರ್ಡ್ ಡ್ರೈವ್‌ಗಳೊಂದಿಗೆ ಕಾರುಗಳಾಗಿ ಪರಿವರ್ತಿಸದಿರಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು ಹೈಬ್ರಿಡ್ ಪರಿಹಾರವನ್ನು ಬಿಡಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.
ನಮ್ಮ ಅರ್ಧದಷ್ಟು ಯಂತ್ರಗಳು ಹಾರ್ಡ್ ಡ್ರೈವ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ (ಅಲ್ಲದೆ, ಅರ್ಧದಷ್ಟು ಅಲ್ಲ - ಬಹುಶಃ 30 ಪ್ರತಿಶತ). ಮತ್ತು ಉಳಿದವು ಮೊದಲ ಮೀಸಲಾತಿ ಯೋಜನೆಯನ್ನು ಹೊಂದಿದ್ದ ಹಳೆಯ ಕಾರುಗಳಾಗಿವೆ. ನಾವು ಅವುಗಳನ್ನು ಸರಳವಾಗಿ ಮರುಮೌಂಟ್ ಮಾಡಿದ್ದೇವೆ, ಏಕೆಂದರೆ ನಮಗೆ ಹೊಸ ಡೇಟಾ ಅಥವಾ ಬೇರೇನೂ ಅಗತ್ಯವಿಲ್ಲ, ನಾವು ಕೇವಲ ಒಂದು ಭೌತಿಕ ಹೋಸ್ಟ್‌ನಿಂದ ಎರಡಕ್ಕೆ ಮೌಂಟ್‌ಗಳನ್ನು ಸರಿಸಿದ್ದೇವೆ.
ಮತ್ತು ನಾವು ಈಗ ಓದುವ ದೊಡ್ಡ ಸಂಗ್ರಹವನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಅದನ್ನು ವಿಸ್ತರಿಸಿದ್ದೇವೆ. ಮೊದಲು ನಾವು ಒಂದು ಗಣಕದಲ್ಲಿ ಒಂದು ಸಂಗ್ರಹಣೆಯನ್ನು ಆರೋಹಿಸಿದ್ದರೆ, ಈಗ ನಾವು ನಾಲ್ಕು ಅನ್ನು ಆರೋಹಿಸುತ್ತೇವೆ, ಉದಾಹರಣೆಗೆ, ಒಂದು ಜೋಡಿಯಲ್ಲಿ. ಮತ್ತು ಇದು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ನಾವು ಏನನ್ನು ಸಾಧಿಸಿದ್ದೇವೆ, ಯಾವುದಕ್ಕಾಗಿ ಹೋರಾಡಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಯಶಸ್ವಿಯಾಗಿದ್ದೇವೆಯೇ ಎಂಬುದರ ಸಂಕ್ಷಿಪ್ತ ಸಾರಾಂಶವನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ.
ಫಲಿತಾಂಶಗಳು
ನಾವು ಬಳಕೆದಾರರನ್ನು ಹೊಂದಿದ್ದೇವೆ - ಸುಮಾರು 33 ಮಿಲಿಯನ್.
ನಾವು ಉಪಸ್ಥಿತಿಯ ಮೂರು ಅಂಶಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ - ಪ್ರೇಗ್, ಮಿಯಾಮಿ, ಹಾಂಗ್ ಕಾಂಗ್.
ಅವುಗಳು ಕ್ಯಾಶಿಂಗ್ ಲೇಯರ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ, ಇದು ವೇಗದ ಸ್ಥಳೀಯ ಡಿಸ್ಕ್ (SSD ಗಳು) ಹೊಂದಿರುವ ಕಾರುಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಅದರ ಮೇಲೆ NGINX ನಿಂದ ಸರಳವಾದ ಯಂತ್ರೋಪಕರಣಗಳು, ಅದರ ಪ್ರವೇಶ.ಲಾಗ್ ಮತ್ತು ಪೈಥಾನ್ ಡೀಮನ್‌ಗಳು ರನ್ ಆಗುತ್ತವೆ, ಇದು ಎಲ್ಲವನ್ನೂ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಸಂಗ್ರಹವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.
ನೀವು ಬಯಸಿದರೆ, ನೀವು ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿದ್ದೀರಿ, ಫೋಟೋಗಳು ನಮಗೆ ಇರುವಷ್ಟು ನಿರ್ಣಾಯಕವಾಗಿಲ್ಲದಿದ್ದರೆ ಅಥವಾ ವ್ಯಾಪಾರದ ನಿಯಂತ್ರಣ ಮತ್ತು ಅಭಿವೃದ್ಧಿ ವೇಗ ಮತ್ತು ಸಂಪನ್ಮೂಲ ವೆಚ್ಚಗಳು ನಿಮಗೆ ಇನ್ನೊಂದು ದಿಕ್ಕಿನಲ್ಲಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಬದಲಾಯಿಸಬಹುದು ಸಿಡಿಎನ್‌ನೊಂದಿಗೆ, ಆಧುನಿಕ ಸಿಡಿಎನ್‌ಗಳು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.
ಮುಂದೆ ಶೇಖರಣಾ ಪದರವು ಬರುತ್ತದೆ, ಅದರ ಮೇಲೆ ನಾವು ಪರಸ್ಪರ ಬ್ಯಾಕಪ್ ಮಾಡುವ ಜೋಡಿ ಯಂತ್ರಗಳ ಸಮೂಹಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಫೈಲ್‌ಗಳು ಬದಲಾದಾಗಲೆಲ್ಲಾ ಒಂದರಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಅಸಮಕಾಲಿಕವಾಗಿ ನಕಲಿಸಲ್ಪಡುತ್ತವೆ.
ಇದಲ್ಲದೆ, ಈ ಕೆಲವು ಯಂತ್ರಗಳು ಸ್ಥಳೀಯ ಹಾರ್ಡ್ ಡ್ರೈವ್‌ಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.
ಈ ಯಂತ್ರಗಳಲ್ಲಿ ಕೆಲವು SAN ಗಳಿಗೆ ಸಂಪರ್ಕ ಹೊಂದಿವೆ.
ಮತ್ತು, ಒಂದೆಡೆ, ಇದು ಬಳಸಲು ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿದೆ ಮತ್ತು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಉತ್ಪಾದಕವಾಗಿದೆ, ಮತ್ತೊಂದೆಡೆ, ಪ್ರತಿ ಗಿಗಾಬೈಟ್‌ಗೆ ಪ್ಲೇಸ್‌ಮೆಂಟ್ ಸಾಂದ್ರತೆ ಮತ್ತು ಬೆಲೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಇದು ಅನುಕೂಲಕರವಾಗಿದೆ.
ಇದು ನಮಗೆ ಏನು ಸಿಕ್ಕಿತು ಮತ್ತು ಅದು ಹೇಗೆ ಅಭಿವೃದ್ಧಿಗೊಂಡಿದೆ ಎಂಬುದರ ವಾಸ್ತುಶಿಲ್ಪದ ಸಂಕ್ಷಿಪ್ತ ಅವಲೋಕನವಾಗಿದೆ.
ಕ್ಯಾಪ್ಟನ್‌ನಿಂದ ಇನ್ನೂ ಕೆಲವು ಸಲಹೆಗಳು, ತುಂಬಾ ಸರಳವಾದವುಗಳು.
ಮೊದಲನೆಯದಾಗಿ, ನಿಮ್ಮ ಫೋಟೋ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ನೀವು ತುರ್ತಾಗಿ ಎಲ್ಲವನ್ನೂ ಸುಧಾರಿಸಬೇಕೆಂದು ನೀವು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ನಿರ್ಧರಿಸಿದರೆ, ಮೊದಲು ಅಳತೆ ಮಾಡಿ, ಏಕೆಂದರೆ ಬಹುಶಃ ಏನನ್ನೂ ಸುಧಾರಿಸಬೇಕಾಗಿಲ್ಲ.
ಒಂದು ಉದಾಹರಣೆ ಕೊಡುತ್ತೇನೆ. ಚಾಟ್‌ಗಳಲ್ಲಿ ಲಗತ್ತುಗಳಿಂದ ಫೋಟೋಗಳನ್ನು ಕಳುಹಿಸುವ ಯಂತ್ರಗಳ ಸಮೂಹವನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಯೋಜನೆಯು 2009 ರಿಂದ ಅಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಮತ್ತು ಯಾರೂ ಅದರಿಂದ ಬಳಲುತ್ತಿಲ್ಲ. ಎಲ್ಲರೂ ಚೆನ್ನಾಗಿದ್ದಾರೆ, ಎಲ್ಲರೂ ಎಲ್ಲವನ್ನೂ ಇಷ್ಟಪಡುತ್ತಾರೆ.
ಅಳತೆ ಮಾಡಲು, ಮೊದಲು ಮೆಟ್ರಿಕ್‌ಗಳ ಗುಂಪನ್ನು ಸ್ಥಗಿತಗೊಳಿಸಿ, ಅವುಗಳನ್ನು ನೋಡಿ, ತದನಂತರ ನೀವು ಯಾವುದರಲ್ಲಿ ಅತೃಪ್ತಿ ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ಯಾವುದನ್ನು ಸುಧಾರಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ. ಇದನ್ನು ಅಳೆಯಲು, ನಾವು ಪಿನ್ಬಾ ಎಂಬ ತಂಪಾದ ಸಾಧನವನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ಪ್ರತಿ ವಿನಂತಿ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಕೋಡ್‌ಗಳು ಮತ್ತು ಸಮಯದ ವಿತರಣೆಗಾಗಿ - ನಿಮಗೆ ಬೇಕಾದುದನ್ನು - NGINX ನಿಂದ ವಿವರವಾದ ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಇದು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಇದು ಎಲ್ಲಾ ರೀತಿಯ ವಿಭಿನ್ನ ವಿಶ್ಲೇಷಣಾ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಬೈಂಡಿಂಗ್‌ಗಳನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ನಂತರ ನೀವು ಎಲ್ಲವನ್ನೂ ಸುಂದರವಾಗಿ ನೋಡಬಹುದು.
ಮೊದಲು ನಾವು ಅದನ್ನು ಅಳೆಯುತ್ತೇವೆ, ನಂತರ ನಾವು ಅದನ್ನು ಸುಧಾರಿಸಿದ್ದೇವೆ.
ಮತ್ತಷ್ಟು. ನಾವು ಸಂಗ್ರಹದೊಂದಿಗೆ ಓದುವಿಕೆಯನ್ನು ಉತ್ತಮಗೊಳಿಸುತ್ತೇವೆ, ಶಾರ್ಡಿಂಗ್ನೊಂದಿಗೆ ಬರೆಯುತ್ತೇವೆ, ಆದರೆ ಇದು ಸ್ಪಷ್ಟವಾದ ಅಂಶವಾಗಿದೆ.
ಮತ್ತಷ್ಟು. ನೀವು ಇದೀಗ ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದರೆ, ಫೋಟೋಗಳನ್ನು ಬದಲಾಯಿಸಲಾಗದ ಫೈಲ್‌ಗಳಾಗಿ ಮಾಡುವುದು ಉತ್ತಮ. ಏಕೆಂದರೆ ಕ್ಯಾಶ್ ಅಮಾನ್ಯೀಕರಣದೊಂದಿಗೆ ನೀವು ತಕ್ಷಣವೇ ಸಂಪೂರ್ಣ ವರ್ಗದ ಸಮಸ್ಯೆಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ, ತರ್ಕವು ಫೋಟೋದ ಸರಿಯಾದ ಆವೃತ್ತಿಯನ್ನು ಹೇಗೆ ಕಂಡುಹಿಡಿಯಬೇಕು ಮತ್ತು ಹೀಗೆ.
ನೀವು ನೂರು ಅಪ್ಲೋಡ್ ಮಾಡಿ, ನಂತರ ಅದನ್ನು ತಿರುಗಿಸಿ, ಭೌತಿಕವಾಗಿ ವಿಭಿನ್ನ ಫೈಲ್ ಆಗುವಂತೆ ಮಾಡಿ ಎಂದು ಹೇಳೋಣ. ಆ. ಯೋಚಿಸುವ ಅಗತ್ಯವಿಲ್ಲ: ಈಗ ನಾನು ಸ್ವಲ್ಪ ಜಾಗವನ್ನು ಉಳಿಸುತ್ತೇನೆ, ಅದನ್ನು ಅದೇ ಫೈಲ್‌ಗೆ ಬರೆಯುತ್ತೇನೆ, ಆವೃತ್ತಿಯನ್ನು ಬದಲಾಯಿಸಿ. ಇದು ಯಾವಾಗಲೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ ಮತ್ತು ನಂತರ ಬಹಳಷ್ಟು ತಲೆನೋವುಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
ಮುಂದಿನ ಪಾಯಿಂಟ್. ಹಾರಾಡುತ್ತ ಮರುಗಾತ್ರಗೊಳಿಸುವ ಬಗ್ಗೆ.
ಹಿಂದೆ, ಬಳಕೆದಾರರು ಫೋಟೋವನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡಿದಾಗ, ನಾವು ತಕ್ಷಣವೇ ಎಲ್ಲಾ ಸಂದರ್ಭಗಳಲ್ಲಿ, ವಿಭಿನ್ನ ಕ್ಲೈಂಟ್‌ಗಳಿಗಾಗಿ ಗಾತ್ರಗಳ ಸಂಪೂರ್ಣ ಗುಂಪನ್ನು ಕತ್ತರಿಸಿದ್ದೇವೆ ಮತ್ತು ಅವೆಲ್ಲವೂ ಡಿಸ್ಕ್‌ನಲ್ಲಿದ್ದವು. ಈಗ ನಾವು ಇದನ್ನು ಕೈಬಿಟ್ಟಿದ್ದೇವೆ.
ನಾವು ಮೂರು ಮುಖ್ಯ ಗಾತ್ರಗಳನ್ನು ಮಾತ್ರ ಬಿಟ್ಟಿದ್ದೇವೆ: ಸಣ್ಣ, ಮಧ್ಯಮ ಮತ್ತು ದೊಡ್ಡದು. Uport ನಲ್ಲಿ ನಮಗೆ ಕೇಳಲಾದ ಗಾತ್ರದ ಹಿಂದೆ ಇರುವ ಗಾತ್ರದಿಂದ ನಾವು ಎಲ್ಲವನ್ನೂ ಕಡಿಮೆಗೊಳಿಸುತ್ತೇವೆ, ನಾವು ಸರಳವಾಗಿ ಡೌನ್‌ಸ್ಕೇಲ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಬಳಕೆದಾರರಿಗೆ ನೀಡುತ್ತೇವೆ.
ಇಲ್ಲಿ ಕ್ಯಾಶಿಂಗ್ ಲೇಯರ್‌ನ CPU ನಾವು ಪ್ರತಿ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ನಿರಂತರವಾಗಿ ಈ ಗಾತ್ರಗಳನ್ನು ಪುನರುತ್ಪಾದಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಅಗ್ಗವಾಗಿದೆ. ನಾವು ಹೊಸದನ್ನು ಸೇರಿಸಲು ಬಯಸುತ್ತೇವೆ ಎಂದು ಹೇಳೋಣ, ಇದು ಒಂದು ತಿಂಗಳು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ - ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನಾಶಪಡಿಸದೆ, ಎಲ್ಲವನ್ನೂ ಅಚ್ಚುಕಟ್ಟಾಗಿ ಮಾಡುವ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಎಲ್ಲೆಡೆ ರನ್ ಮಾಡಿ. ಆ. ಈಗ ಆಯ್ಕೆ ಮಾಡಲು ನಿಮಗೆ ಅವಕಾಶವಿದ್ದರೆ, ಸಾಧ್ಯವಾದಷ್ಟು ಕಡಿಮೆ ಭೌತಿಕ ಗಾತ್ರಗಳನ್ನು ಮಾಡುವುದು ಉತ್ತಮ, ಆದರೆ ಕನಿಷ್ಠ ಕೆಲವು ವಿತರಣೆಗಳು ಮೂರು ಎಂದು ಹೇಳಬಹುದು. ಮತ್ತು ರೆಡಿಮೇಡ್ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಫ್ಲೈನಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ಸರಳವಾಗಿ ಮರುಗಾತ್ರಗೊಳಿಸಬಹುದು. ಈಗ ಎಲ್ಲವೂ ತುಂಬಾ ಸುಲಭ ಮತ್ತು ಪ್ರವೇಶಿಸಬಹುದಾಗಿದೆ.
ಮತ್ತು ಹೆಚ್ಚುತ್ತಿರುವ ಅಸಮಕಾಲಿಕ ಬ್ಯಾಕಪ್ ಉತ್ತಮವಾಗಿದೆ.
ನಮ್ಮ ಅಭ್ಯಾಸವು ತೋರಿಸಿದಂತೆ, ಬದಲಾದ ಫೈಲ್‌ಗಳ ವಿಳಂಬವಾದ ನಕಲುಗಳೊಂದಿಗೆ ಈ ಯೋಜನೆಯು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಕೊನೆಯ ಅಂಶವೂ ಸ್ಪಷ್ಟವಾಗಿದೆ. ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯವು ಈಗ ಅಂತಹ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ಆದರೆ ಮುರಿಯಬಹುದಾದ ಏನಾದರೂ ಇದ್ದರೆ, ಅದು ಸ್ವಲ್ಪ ಹೆಚ್ಚಾದಾಗ ಅದು ಖಂಡಿತವಾಗಿಯೂ ಒಡೆಯುತ್ತದೆ. ಆದ್ದರಿಂದ, ಈ ಬಗ್ಗೆ ಮುಂಚಿತವಾಗಿ ಯೋಚಿಸುವುದು ಉತ್ತಮ ಮತ್ತು ಅದರೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳನ್ನು ಅನುಭವಿಸುವುದಿಲ್ಲ. ನಾನು ಹೇಳಲು ಬಯಸಿದ್ದು ಇಷ್ಟೇ.
ಸಂಪರ್ಕಗಳು
»
»
ಈ ವರದಿಯು ಹೈ-ಲೋಡ್ ಸಿಸ್ಟಮ್‌ಗಳ ಡೆವಲಪರ್‌ಗಳ ಸಮ್ಮೇಳನದಲ್ಲಿ ಅತ್ಯುತ್ತಮ ಭಾಷಣಗಳ ಪ್ರತಿಲೇಖನವಾಗಿದೆ . ಹೈಲೋಡ್++ 2017 ಸಮ್ಮೇಳನಕ್ಕೆ ಒಂದು ತಿಂಗಳಿಗಿಂತ ಕಡಿಮೆ ಸಮಯ ಉಳಿದಿದೆ.
ನಾವು ಈಗಾಗಲೇ ಅದನ್ನು ಸಿದ್ಧಪಡಿಸಿದ್ದೇವೆ , ವೇಳಾಪಟ್ಟಿಯನ್ನು ಈಗ ಸಕ್ರಿಯವಾಗಿ ರಚಿಸಲಾಗುತ್ತಿದೆ.
ಈ ವರ್ಷ ನಾವು ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳು ಮತ್ತು ಸ್ಕೇಲಿಂಗ್‌ನ ವಿಷಯವನ್ನು ಅನ್ವೇಷಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ:
- / ಇಗೊರ್ ವಾಸಿಲೀವ್
- / ಡಿಮಿಟ್ರಿ ಎಗೊರೊವ್
- / ಅನಾಟೊಲಿ ಪ್ಲಾಸ್ಕೋವ್ಸ್ಕಿ
- / ರೋಮನ್ ಶೆಕೊವ್ಟ್ಸೊವ್, ಅಲೆಕ್ಸಿ ಗ್ರೊಮಾಚಿಕೋವ್
- / ಫಿಲಿಪ್ ಡೆಲ್ಗಾಡೊ
ಹೆಚ್ಚಿನ ಲೋಡ್ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಕುರಿತು ನಮ್ಮ ಆನ್‌ಲೈನ್ ತರಬೇತಿ ಕೋರ್ಸ್‌ನಲ್ಲಿ ನಾವು ಈ ಕೆಲವು ವಸ್ತುಗಳನ್ನು ಸಹ ಬಳಸುತ್ತೇವೆ ವಿಶೇಷವಾಗಿ ಆಯ್ಕೆಮಾಡಿದ ಅಕ್ಷರಗಳು, ಲೇಖನಗಳು, ವಸ್ತುಗಳು, ವೀಡಿಯೊಗಳ ಸರಣಿಯಾಗಿದೆ. ನಮ್ಮ ಪಠ್ಯಪುಸ್ತಕವು ಈಗಾಗಲೇ 30 ಕ್ಕೂ ಹೆಚ್ಚು ಅನನ್ಯ ವಸ್ತುಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಸಂಪರ್ಕಿಸಿ!
ಮೂಲ: www.habr.com