ಹೇಗಾದರೂ, ಐತಿಹಾಸಿಕವಾಗಿ, ಐಟಿ ಉದ್ಯಮವನ್ನು ಯಾವುದೇ ಕಾರಣಕ್ಕಾಗಿ ಎರಡು ಷರತ್ತುಬದ್ಧ ಶಿಬಿರಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ: "ಪರ" ಮತ್ತು "ವಿರುದ್ಧ". ಇದಲ್ಲದೆ, ವಿವಾದಗಳ ವಿಷಯವು ಸಂಪೂರ್ಣವಾಗಿ ನಿರಂಕುಶವಾಗಿರಬಹುದು. ಯಾವ ಓಎಸ್ ಉತ್ತಮವಾಗಿದೆ: ವಿನ್ ಅಥವಾ ಲಿನಕ್ಸ್? Android ಅಥವಾ iOS ಸ್ಮಾರ್ಟ್‌ಫೋನ್‌ನಲ್ಲಿ? ನೀವು ಎಲ್ಲವನ್ನೂ ಮೋಡಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಬೇಕೇ ಅಥವಾ ಕೋಲ್ಡ್ RAID ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಸ್ಕ್ರೂಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಇರಿಸಬೇಕೇ? PHP ಜನರಿಗೆ ಪ್ರೋಗ್ರಾಮರ್ ಎಂದು ಕರೆಯುವ ಹಕ್ಕಿದೆಯೇ? ಈ ವಿವಾದಗಳು, ಕೆಲವೊಮ್ಮೆ, ಪ್ರಕೃತಿಯಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಮತ್ತು ಕ್ರೀಡಾ ಆಸಕ್ತಿಯನ್ನು ಹೊರತುಪಡಿಸಿ ಯಾವುದೇ ಆಧಾರವನ್ನು ಹೊಂದಿಲ್ಲ.
ಕಂಟೇನರ್‌ಗಳ ಆಗಮನದೊಂದಿಗೆ ಮತ್ತು ಡಾಕರ್ ಮತ್ತು ಷರತ್ತುಬದ್ಧ ಕೆ 8 ಗಳೊಂದಿಗಿನ ಈ ಎಲ್ಲಾ ಪ್ರೀತಿಯ ಪಾಕಪದ್ಧತಿಯೊಂದಿಗೆ, ಬ್ಯಾಕೆಂಡ್‌ನ ವಿವಿಧ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಹೊಸ ಸಾಮರ್ಥ್ಯಗಳ ಬಳಕೆಗಾಗಿ "ಫಾರ್" ಮತ್ತು "ವಿರುದ್ಧ" ಚರ್ಚೆಗಳು ಪ್ರಾರಂಭವಾದವು. (ಈ ಚರ್ಚೆಯಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಹೆಚ್ಚಾಗಿ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಎಂದು ಸೂಚಿಸಲಾಗಿದ್ದರೂ, ಈ ನಿರ್ದಿಷ್ಟ ಉಪಕರಣದ ಆಯ್ಕೆಯು ಮೂಲಭೂತ ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ಹೊಂದಿಲ್ಲ ಎಂದು ಮುಂಚಿತವಾಗಿ ಕಾಯ್ದಿರಿಸೋಣ. ಬದಲಿಗೆ, ನಿಮಗೆ ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾದ ಮತ್ತು ಪರಿಚಿತವಾಗಿರುವ ಯಾವುದನ್ನಾದರೂ ನೀವು ಬದಲಿಸಬಹುದು .)
ಮತ್ತು, ಇದು ಒಂದೇ ನಾಣ್ಯದ ಎರಡು ಬದಿಗಳ ನಡುವಿನ ಸರಳ ವಿವಾದವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ. ವಿನ್ vs ಲಿನಕ್ಸ್ ನಡುವಿನ ಶಾಶ್ವತ ಮುಖಾಮುಖಿಯಂತೆ ಪ್ರಜ್ಞಾಶೂನ್ಯ ಮತ್ತು ಕರುಣೆಯಿಲ್ಲ, ಇದರಲ್ಲಿ ಮಧ್ಯದಲ್ಲಿ ಎಲ್ಲೋ ಸಾಕಷ್ಟು ಜನರು ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದಾರೆ. ಆದರೆ ಧಾರಕೀಕರಣದ ಸಂದರ್ಭದಲ್ಲಿ, ಎಲ್ಲವೂ ತುಂಬಾ ಸರಳವಲ್ಲ. ಸಾಮಾನ್ಯವಾಗಿ ಅಂತಹ ವಿವಾದಗಳಲ್ಲಿ ಯಾವುದೇ ಬಲಭಾಗವಿಲ್ಲ, ಆದರೆ ಡೇಟಾಬೇಸ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು "ಬಳಕೆ" ಅಥವಾ "ಬಳಸಬೇಡಿ" ಧಾರಕಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಎಲ್ಲವೂ ತಲೆಕೆಳಗಾಗಿ ತಿರುಗುತ್ತದೆ. ಏಕೆಂದರೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಅರ್ಥದಲ್ಲಿ, ಈ ವಿಧಾನದ ಬೆಂಬಲಿಗರು ಮತ್ತು ವಿರೋಧಿಗಳು ಇಬ್ಬರೂ ಸರಿ.
ಪ್ರಕಾಶಮಾನವಾದ ಭಾಗ
ಲೈಟ್ ಸೈಡ್ನ ವಾದವನ್ನು ಒಂದು ಪದಗುಚ್ಛದಲ್ಲಿ ಸಂಕ್ಷಿಪ್ತವಾಗಿ ವಿವರಿಸಬಹುದು: "ಹಲೋ, 2k19 ಕಿಟಕಿಯ ಹೊರಗಿದೆ!" ಸಹಜವಾಗಿ, ಇದು ಜನಪ್ರಿಯತೆಯಂತೆ ತೋರುತ್ತದೆ, ಆದರೆ ನೀವು ಪರಿಸ್ಥಿತಿಯನ್ನು ವಿವರವಾಗಿ ಪರಿಶೀಲಿಸಿದರೆ, ಅದು ಅದರ ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿದೆ. ಈಗ ಅವುಗಳನ್ನು ವಿಂಗಡಿಸೋಣ.
ನೀವು ದೊಡ್ಡ ವೆಬ್ ಪ್ರಾಜೆಕ್ಟ್ ಹೊಂದಿದ್ದೀರಿ ಎಂದು ಹೇಳೋಣ. ಇದನ್ನು ಆರಂಭದಲ್ಲಿ ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ವಿಧಾನದ ಆಧಾರದ ಮೇಲೆ ನಿರ್ಮಿಸಬಹುದಿತ್ತು, ಅಥವಾ ಕೆಲವು ಹಂತದಲ್ಲಿ ಅದು ವಿಕಸನೀಯ ಮಾರ್ಗದ ಮೂಲಕ ಬಂದಿತು - ಇದು ತುಂಬಾ ಮುಖ್ಯವಲ್ಲ, ವಾಸ್ತವವಾಗಿ. ನೀವು ನಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಮೈಕ್ರೋಸರ್ವಿಸ್‌ಗಳಾಗಿ ಹರಡಿದ್ದೀರಿ, ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಅನ್ನು ಹೊಂದಿಸಿ, ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಮತ್ತು ಸ್ಕೇಲಿಂಗ್. ಮತ್ತು ಈಗ, ಸ್ಪಷ್ಟ ಆತ್ಮಸಾಕ್ಷಿಯೊಂದಿಗೆ, ಬಿದ್ದ ಸರ್ವರ್‌ಗಳನ್ನು ಹೆಚ್ಚಿಸುವ ಬದಲು ಹಾಬ್ರಾ ಪರಿಣಾಮಗಳ ಸಮಯದಲ್ಲಿ ನೀವು ಆರಾಮದಲ್ಲಿ ಮೊಜಿಟೊವನ್ನು ಸಿಪ್ ಮಾಡಿ. ಆದರೆ ಎಲ್ಲಾ ಕ್ರಿಯೆಗಳಲ್ಲಿ ನೀವು ಸ್ಥಿರವಾಗಿರಬೇಕು. ಆಗಾಗ್ಗೆ, ಅಪ್ಲಿಕೇಶನ್ ಸ್ವತಃ - ಕೋಡ್ ಅನ್ನು ಮಾತ್ರ ಕಂಟೈನರೈಸ್ ಮಾಡಲಾಗುತ್ತದೆ. ಕೋಡ್ ಹೊರತುಪಡಿಸಿ ನಾವು ಬೇರೆ ಏನು ಹೊಂದಿದ್ದೇವೆ?
ಅದು ಸರಿ, ಡೇಟಾ. ಯಾವುದೇ ಪ್ರಾಜೆಕ್ಟ್‌ನ ಹೃದಯಭಾಗವು ಅದರ ಡೇಟಾ: ಇದು ವಿಶಿಷ್ಟವಾದ DBMS ಆಗಿರಬಹುದು - MySQL, Postgre, MongoDB, ಅಥವಾ ಹುಡುಕಾಟಕ್ಕಾಗಿ ಬಳಸಲಾಗುವ ಸಂಗ್ರಹಣೆ (ElasticSearch), ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಲು ಕೀ-ಮೌಲ್ಯ ಸಂಗ್ರಹಣೆ - ಉದಾಹರಣೆಗೆ, ರೆಡಿಸ್, ಇತ್ಯಾದಿ. ಪ್ರಸ್ತುತ ನಾವು ಅಲ್ಲ. ಕಳಪೆ ಲಿಖಿತ ಪ್ರಶ್ನೆಗಳಿಂದ ಡೇಟಾಬೇಸ್ ಕ್ರ್ಯಾಶ್ ಆದಾಗ ನಾವು ವಕ್ರ ಬ್ಯಾಕೆಂಡ್ ಅನುಷ್ಠಾನ ಆಯ್ಕೆಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ ಮತ್ತು ಬದಲಿಗೆ ಕ್ಲೈಂಟ್ ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಈ ಡೇಟಾಬೇಸ್ನ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವ ಬಗ್ಗೆ ನಾವು ಮಾತನಾಡುತ್ತೇವೆ. ಎಲ್ಲಾ ನಂತರ, ನಾವು ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕಂಟೈನರೈಸ್ ಮಾಡಿದಾಗ ಮತ್ತು ಯಾವುದೇ ಸಂಖ್ಯೆಯ ಒಳಬರುವ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಅದನ್ನು ಮುಕ್ತವಾಗಿ ಅಳೆಯಲು ಅನುಮತಿಸಿದಾಗ, ಇದು ಸ್ವಾಭಾವಿಕವಾಗಿ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಲೋಡ್ ಅನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.
ವಾಸ್ತವವಾಗಿ, ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪ್ರವೇಶಿಸುವ ಚಾನಲ್ ಮತ್ತು ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸರ್ವರ್ ನಮ್ಮ ಸುಂದರವಾದ ಕಂಟೈನರೈಸ್ಡ್ ಬ್ಯಾಕೆಂಡ್‌ನಲ್ಲಿ ಸೂಜಿಯ ಕಣ್ಣಾಗುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಕಂಟೇನರ್ ವರ್ಚುವಲೈಸೇಶನ್‌ನ ಮುಖ್ಯ ಉದ್ದೇಶವು ರಚನೆಯ ಚಲನಶೀಲತೆ ಮತ್ತು ನಮ್ಯತೆಯಾಗಿದೆ, ಇದು ನಮಗೆ ಲಭ್ಯವಿರುವ ಸಂಪೂರ್ಣ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಗರಿಷ್ಠ ಲೋಡ್‌ಗಳ ವಿತರಣೆಯನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಸಂಘಟಿಸಲು ನಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಅಂದರೆ, ನಾವು ಕ್ಲಸ್ಟರ್‌ನಾದ್ಯಂತ ಸಿಸ್ಟಮ್ನ ಎಲ್ಲಾ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಅಂಶಗಳನ್ನು ಕಂಟೈನರೈಸ್ ಮಾಡದಿದ್ದರೆ ಮತ್ತು ರೋಲ್ ಔಟ್ ಮಾಡದಿದ್ದರೆ, ನಾವು ತುಂಬಾ ಗಂಭೀರವಾದ ತಪ್ಪನ್ನು ಮಾಡುತ್ತಿದ್ದೇವೆ.
ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಮಾತ್ರವಲ್ಲದೆ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವ ಜವಾಬ್ದಾರಿಯುತ ಸೇವೆಗಳನ್ನು ಕ್ಲಸ್ಟರ್ ಮಾಡಲು ಇದು ಹೆಚ್ಚು ತಾರ್ಕಿಕವಾಗಿದೆ. ಸ್ವತಂತ್ರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮತ್ತು k8 ಗಳಲ್ಲಿ ತಮ್ಮ ನಡುವೆ ಲೋಡ್ ಅನ್ನು ವಿತರಿಸುವ ವೆಬ್ ಸರ್ವರ್‌ಗಳನ್ನು ಕ್ಲಸ್ಟರಿಂಗ್ ಮತ್ತು ನಿಯೋಜಿಸುವ ಮೂಲಕ, ನಾವು ಈಗಾಗಲೇ ಡೇಟಾ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತಿದ್ದೇವೆ - ಪೋಸ್ಟ್‌ಗಳಲ್ಲಿ ಅದೇ ಕಾಮೆಂಟ್‌ಗಳು, ನಾವು ಕೆಲವು ಮಾಧ್ಯಮ ಅಥವಾ ಬ್ಲಾಗ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ಉದಾಹರಣೆಯಾಗಿ ತೆಗೆದುಕೊಂಡರೆ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಬಾಹ್ಯ ಸೇವೆಯಾಗಿ ಡೇಟಾಬೇಸ್ನ ಅಂತರ್-ಕ್ಲಸ್ಟರ್, ವರ್ಚುವಲ್ ಪ್ರಾತಿನಿಧ್ಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಪ್ರಶ್ನೆಯೆಂದರೆ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಇನ್ನೂ ಕ್ಲಸ್ಟರ್ ಮಾಡಲಾಗಿಲ್ಲ - ಕ್ಯೂಬ್‌ನಲ್ಲಿ ನಿಯೋಜಿಸಲಾದ ವೆಬ್ ಸರ್ವರ್‌ಗಳು ನಮ್ಮ ಸ್ಥಿರ ಯುದ್ಧ ಡೇಟಾಬೇಸ್‌ನಿಂದ ಬದಲಾವಣೆಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ, ಅದು ಪ್ರತ್ಯೇಕವಾಗಿ ತಿರುಗುತ್ತದೆ.
ನೀವು ಕ್ಯಾಚ್ ಅನ್ನು ಅನುಭವಿಸುತ್ತೀರಾ? ಲೋಡ್ ಅನ್ನು ವಿತರಿಸಲು ಮತ್ತು ಮುಖ್ಯ ವೆಬ್ ಸರ್ವರ್ ಕ್ರ್ಯಾಶ್ ಆಗುವುದನ್ನು ತಪ್ಪಿಸಲು ನಾವು k8s ಅಥವಾ Swarm ಅನ್ನು ಬಳಸುತ್ತೇವೆ, ಆದರೆ ಡೇಟಾಬೇಸ್‌ಗಾಗಿ ನಾವು ಇದನ್ನು ಮಾಡುವುದಿಲ್ಲ. ಆದರೆ ಡೇಟಾಬೇಸ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ, ನಮ್ಮ ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್ಡ್ ಮೂಲಸೌಕರ್ಯವು ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ - ಡೇಟಾಬೇಸ್ ಪ್ರವೇಶ ದೋಷವನ್ನು ಹಿಂದಿರುಗಿಸುವ ಖಾಲಿ ವೆಬ್ ಪುಟಗಳು ಯಾವುವು?
ಅದಕ್ಕಾಗಿಯೇ ಸಾಮಾನ್ಯವಾಗಿ ಮಾಡುವಂತೆ ವೆಬ್ ಸರ್ವರ್‌ಗಳನ್ನು ಮಾತ್ರವಲ್ಲದೆ ಡೇಟಾಬೇಸ್ ಮೂಲಸೌಕರ್ಯವನ್ನೂ ಸಹ ಕ್ಲಸ್ಟರ್ ಮಾಡುವುದು ಅವಶ್ಯಕ. ಈ ರೀತಿಯಲ್ಲಿ ಮಾತ್ರ ನಾವು ಒಂದು ತಂಡದಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ರಚನೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಪರಸ್ಪರ ಸ್ವತಂತ್ರವಾಗಿರುತ್ತದೆ. ಇದಲ್ಲದೆ, ನಮ್ಮ ಬ್ಯಾಕೆಂಡ್‌ನ ಅರ್ಧದಷ್ಟು ಲೋಡ್‌ನಲ್ಲಿ "ಕುಸಿತವಾದರೂ", ಉಳಿದವು ಉಳಿಯುತ್ತದೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಡೇಟಾಬೇಸ್ಗಳನ್ನು ಪರಸ್ಪರ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುವ ವ್ಯವಸ್ಥೆ ಮತ್ತು ಹೊಸ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಅನಂತವಾಗಿ ಅಳೆಯುವ ಮತ್ತು ನಿಯೋಜಿಸುವ ಸಾಮರ್ಥ್ಯವು ಅಗತ್ಯವಿರುವ ಸಾಮರ್ಥ್ಯವನ್ನು ತ್ವರಿತವಾಗಿ ತಲುಪಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ - ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ ಚರಣಿಗೆಗಳು ಇದ್ದಲ್ಲಿ ಮಾತ್ರ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ವಿತರಿಸಲಾದ ಡೇಟಾಬೇಸ್ ಮಾದರಿಯು ಈ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಅಗತ್ಯವಿರುವ ಸ್ಥಳಕ್ಕೆ ತೆಗೆದುಕೊಳ್ಳಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ; ನಾವು ಜಾಗತಿಕ ಸೇವೆಯ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದರೆ, ಸ್ಯಾನ್ ಫ್ರಾನ್ಸಿಸ್ಕೋ ಪ್ರದೇಶದಲ್ಲಿ ಎಲ್ಲೋ ವೆಬ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸ್ಪಿನ್ ಮಾಡುವುದು ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಮಾಸ್ಕೋ ಪ್ರದೇಶದಲ್ಲಿ ಮತ್ತು ಹಿಂದಕ್ಕೆ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪ್ರವೇಶಿಸುವಾಗ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಕಳುಹಿಸುವುದು ಸಾಕಷ್ಟು ತರ್ಕಬದ್ಧವಲ್ಲ.
ಅಲ್ಲದೆ, ಡೇಟಾಬೇಸ್ನ ಕಂಟೈನರೈಸೇಶನ್ ಸಿಸ್ಟಮ್ನ ಎಲ್ಲಾ ಅಂಶಗಳನ್ನು ಅಮೂರ್ತತೆಯ ಅದೇ ಮಟ್ಟದಲ್ಲಿ ನಿರ್ಮಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಇದು ಪ್ರತಿಯಾಗಿ, ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ನೇರವಾಗಿ ಕೋಡ್‌ನಿಂದ ಡೆವಲಪರ್‌ಗಳಿಂದ ನಿರ್ವಾಹಕರ ಸಕ್ರಿಯ ಒಳಗೊಳ್ಳುವಿಕೆ ಇಲ್ಲದೆ ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ. ಹೊಸ ಉಪಯೋಜನೆಗೆ ಪ್ರತ್ಯೇಕ DBMS ಅಗತ್ಯವಿದೆ ಎಂದು ಡೆವಲಪರ್‌ಗಳು ಭಾವಿಸಿದ್ದಾರೆ - ಸುಲಭ! yaml ಫೈಲ್ ಅನ್ನು ಬರೆದರು, ಅದನ್ನು ಕ್ಲಸ್ಟರ್‌ಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ನೀವು ಮುಗಿಸಿದ್ದೀರಿ.
ಮತ್ತು ಸಹಜವಾಗಿ, ಆಂತರಿಕ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸಲಾಗಿದೆ. ಹೇಳಿ, ಹೊಸ ತಂಡದ ಸದಸ್ಯರು ಕೆಲಸಕ್ಕಾಗಿ ಯುದ್ಧ ಡೇಟಾಬೇಸ್‌ಗೆ ಕೈ ಹಾಕಿದಾಗ ನೀವು ಎಷ್ಟು ಬಾರಿ ನಿಮ್ಮ ಕಣ್ಣುಗಳನ್ನು ಮುಚ್ಚಿದ್ದೀರಿ? ವಾಸ್ತವವಾಗಿ, ನೀವು ಹೊಂದಿರುವ ಮತ್ತು ಇದೀಗ ತಿರುಗುತ್ತಿರುವ ಒಂದೇ ಒಂದು ಯಾವುದು? ಸಹಜವಾಗಿ, ನಾವೆಲ್ಲರೂ ಇಲ್ಲಿ ವಯಸ್ಕರಾಗಿದ್ದೇವೆ ಮತ್ತು ಎಲ್ಲೋ ನಾವು ತಾಜಾ ಬ್ಯಾಕಪ್ ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಇನ್ನೂ ದೂರದಲ್ಲಿ - ಅಜ್ಜಿಯ ಸೌತೆಕಾಯಿಗಳು ಮತ್ತು ಹಳೆಯ ಹಿಮಹಾವುಗೆಗಳೊಂದಿಗೆ ಶೆಲ್ಫ್ ಹಿಂದೆ - ಮತ್ತೊಂದು ಬ್ಯಾಕಪ್, ಬಹುಶಃ ಕೋಲ್ಡ್ ಸ್ಟೋರೇಜ್‌ನಲ್ಲಿಯೂ ಸಹ, ಏಕೆಂದರೆ ನಿಮ್ಮ ಕಚೇರಿಯಲ್ಲಿ ಈಗಾಗಲೇ ಒಮ್ಮೆ ಬೆಂಕಿ ಹೊತ್ತಿಕೊಂಡಿದೆ. ಆದರೆ ಒಂದೇ ರೀತಿ, ಯುದ್ಧ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರುವ ಹೊಸ ತಂಡದ ಸದಸ್ಯರ ಪ್ರತಿ ಪರಿಚಯ ಮತ್ತು ಯುದ್ಧ ಡೇಟಾಬೇಸ್‌ಗೆ ಸುತ್ತಮುತ್ತಲಿನ ಪ್ರತಿಯೊಬ್ಬರಿಗೂ ವ್ಯಾಲಿಡೋಲ್‌ನ ಬಕೆಟ್ ಆಗಿದೆ. ಸರಿ, ಅವನನ್ನು ಯಾರು ತಿಳಿದಿದ್ದಾರೆ, ಹೊಸಬರು, ಬಹುಶಃ ಅವರು ಅಡ್ಡ-ಹ್ಯಾಂಡ್ ಆಗಿರಬಹುದು? ಇದು ಭಯಾನಕವಾಗಿದೆ, ನೀವು ಒಪ್ಪುತ್ತೀರಿ.
ಕಂಟೈನರೈಸೇಶನ್ ಮತ್ತು, ವಾಸ್ತವವಾಗಿ, ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ನ ಡೇಟಾಬೇಸ್ನ ವಿತರಿಸಲಾದ ಭೌತಿಕ ಟೋಪೋಲಜಿಯು ಅಂತಹ ಮೌಲ್ಯೀಕರಿಸುವ ಕ್ಷಣಗಳನ್ನು ತಪ್ಪಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಹೊಸಬರನ್ನು ನಂಬುವುದಿಲ್ಲವೇ? ಸರಿ! ಇತರ ಕ್ಲಸ್ಟರ್‌ಗಳಿಂದ ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಮತ್ತು ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಲು ಅವನ ಸ್ವಂತ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನೀಡೋಣ - ಹಸ್ತಚಾಲಿತ ಪುಶ್ ಮತ್ತು ಎರಡು ಕೀಗಳ ಸಿಂಕ್ರೊನಸ್ ತಿರುಗುವಿಕೆಯಿಂದ ಮಾತ್ರ ಸಿಂಕ್ರೊನೈಸೇಶನ್ (ಒಂದು ತಂಡದ ನಾಯಕನಿಗೆ, ಇನ್ನೊಂದು ನಿರ್ವಾಹಕರಿಗೆ). ಮತ್ತು ಎಲ್ಲರೂ ಸಂತೋಷವಾಗಿದ್ದಾರೆ.
ಮತ್ತು ಈಗ ಡೇಟಾಬೇಸ್ ಕ್ಲಸ್ಟರಿಂಗ್‌ನ ವಿರೋಧಿಗಳಾಗಿ ಬದಲಾಗುವ ಸಮಯ.
ಡಾರ್ಕ್ ಸೈಡ್
ಡೇಟಾಬೇಸ್ ಅನ್ನು ಕಂಟೇನರೈಸ್ ಮಾಡುವುದು ಮತ್ತು ಅದನ್ನು ಒಂದು ಕೇಂದ್ರ ಸರ್ವರ್‌ನಲ್ಲಿ ಚಲಾಯಿಸುವುದನ್ನು ಮುಂದುವರಿಸುವುದು ಏಕೆ ಯೋಗ್ಯವಾಗಿಲ್ಲ ಎಂದು ವಾದಿಸುತ್ತಾ, ನಾವು ಸಾಂಪ್ರದಾಯಿಕತೆಯ ವಾಕ್ಚಾತುರ್ಯ ಮತ್ತು "ಅಜ್ಜರು ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಡೇಟಾಬೇಸ್ಗಳನ್ನು ನಡೆಸುತ್ತಿದ್ದರು, ಮತ್ತು ನಾವೂ ಸಹ!" ಬದಲಿಗೆ, ಕಂಟೈನರೈಸೇಶನ್ ವಾಸ್ತವವಾಗಿ ಸ್ಪಷ್ಟವಾದ ಲಾಭಾಂಶವನ್ನು ಪಾವತಿಸುವ ಪರಿಸ್ಥಿತಿಯೊಂದಿಗೆ ಬರಲು ಪ್ರಯತ್ನಿಸೋಣ.
ಒಪ್ಪಿಕೊಳ್ಳಿ, ಕಂಟೇನರ್‌ನಲ್ಲಿ ನಿಜವಾಗಿಯೂ ಬೇಸ್ ಅಗತ್ಯವಿರುವ ಯೋಜನೆಗಳನ್ನು ಅತ್ಯುತ್ತಮ ಮಿಲ್ಲಿಂಗ್ ಮೆಷಿನ್ ಆಪರೇಟರ್ ಅಲ್ಲದ ಮೂಲಕ ಒಂದು ಕೈಯ ಬೆರಳುಗಳ ಮೇಲೆ ಎಣಿಸಬಹುದು. ಬಹುಪಾಲು, k8s ಅಥವಾ ಡಾಕರ್ ಸಮೂಹದ ಬಳಕೆಯು ಸಹ ಅನಗತ್ಯವಾಗಿದೆ - ತಂತ್ರಜ್ಞಾನಗಳ ಸಾಮಾನ್ಯ ಪ್ರಚೋದನೆ ಮತ್ತು ಎಲ್ಲವನ್ನೂ ತಳ್ಳಲು ಲಿಂಗಗಳ ವ್ಯಕ್ತಿಯಲ್ಲಿರುವ “ಸರ್ವಶಕ್ತ” ವರ್ತನೆಗಳಿಂದಾಗಿ ಈ ಸಾಧನಗಳನ್ನು ಹೆಚ್ಚಾಗಿ ಆಶ್ರಯಿಸಲಾಗುತ್ತದೆ. ಮೋಡಗಳು ಮತ್ತು ಪಾತ್ರೆಗಳು. ಒಳ್ಳೆಯದು, ಏಕೆಂದರೆ ಈಗ ಅದು ಫ್ಯಾಶನ್ ಆಗಿದೆ ಮತ್ತು ಪ್ರತಿಯೊಬ್ಬರೂ ಅದನ್ನು ಮಾಡುತ್ತಾರೆ.
ಕನಿಷ್ಠ ಅರ್ಧದಷ್ಟು ಪ್ರಕರಣಗಳಲ್ಲಿ, ಯೋಜನೆಯಲ್ಲಿ ಕುಬರ್ನೆಟಿಸ್ ಅಥವಾ ಡಾಕರ್ ಅನ್ನು ಬಳಸುವುದು ಅನಗತ್ಯವಾಗಿರುತ್ತದೆ. ಸಮಸ್ಯೆಯೆಂದರೆ ಕ್ಲೈಂಟ್‌ನ ಮೂಲಸೌಕರ್ಯವನ್ನು ನಿರ್ವಹಿಸಲು ನೇಮಕಗೊಂಡ ಎಲ್ಲಾ ತಂಡಗಳು ಅಥವಾ ಹೊರಗುತ್ತಿಗೆ ಕಂಪನಿಗಳು ಇದರ ಬಗ್ಗೆ ತಿಳಿದಿರುವುದಿಲ್ಲ. ಧಾರಕಗಳನ್ನು ವಿಧಿಸಿದಾಗ ಅದು ಕೆಟ್ಟದಾಗಿದೆ, ಏಕೆಂದರೆ ಇದು ಕ್ಲೈಂಟ್ಗೆ ನಿರ್ದಿಷ್ಟ ಪ್ರಮಾಣದ ನಾಣ್ಯಗಳನ್ನು ವೆಚ್ಚ ಮಾಡುತ್ತದೆ.
ಸಾಮಾನ್ಯವಾಗಿ, ಈ ಮೂಲಸೌಕರ್ಯ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊರಗುತ್ತಿಗೆ ನೀಡುವ ಗ್ರಾಹಕರನ್ನು ಡಾಕರ್/ಕ್ಯೂಬ್ ಮಾಫಿಯಾ ಮೂರ್ಖತನದಿಂದ ಹತ್ತಿಕ್ಕುತ್ತಿದೆ ಎಂಬ ಅಭಿಪ್ರಾಯವಿದೆ. ಎಲ್ಲಾ ನಂತರ, ಕ್ಲಸ್ಟರ್ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು, ನಾವು ಇದನ್ನು ಸಮರ್ಥವಾಗಿರುವ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಅಳವಡಿಸಲಾದ ಪರಿಹಾರದ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಎಂಜಿನಿಯರ್ಗಳ ಅಗತ್ಯವಿದೆ. ರಿಪಬ್ಲಿಕ್ ಪ್ರಕಟಣೆಯೊಂದಿಗೆ ನಾವು ಒಮ್ಮೆ ನಮ್ಮ ಪ್ರಕರಣವನ್ನು ವಿವರಿಸಿದ್ದೇವೆ - ಅಲ್ಲಿ ನಾವು ಕ್ಲೈಂಟ್‌ನ ತಂಡವನ್ನು ಕುಬರ್ನೆಟಿಸ್‌ನ ನೈಜತೆಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ತರಬೇತಿ ನೀಡಿದ್ದೇವೆ ಮತ್ತು ಎಲ್ಲರೂ ತೃಪ್ತರಾಗಿದ್ದರು. ಮತ್ತು ಅದು ಯೋಗ್ಯವಾಗಿತ್ತು. ಆಗಾಗ್ಗೆ, k8s “ಅಳವಡಿಕೆದಾರರು” ಕ್ಲೈಂಟ್‌ನ ಮೂಲಸೌಕರ್ಯವನ್ನು ಒತ್ತೆಯಾಳಾಗಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆ - ಏಕೆಂದರೆ ಅಲ್ಲಿ ಎಲ್ಲವೂ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಈಗ ಅವರು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ; ಕ್ಲೈಂಟ್‌ನ ಬದಿಯಲ್ಲಿ ಯಾವುದೇ ತಜ್ಞರಿಲ್ಲ.
ಈಗ ಈ ರೀತಿಯಲ್ಲಿ ನಾವು ವೆಬ್ ಸರ್ವರ್ ಭಾಗವನ್ನು ಮಾತ್ರವಲ್ಲದೆ ಡೇಟಾಬೇಸ್ ನಿರ್ವಹಣೆಯನ್ನೂ ಹೊರಗುತ್ತಿಗೆ ನೀಡುತ್ತೇವೆ ಎಂದು ಊಹಿಸಿ. BD ಹೃದಯ ಎಂದು ನಾವು ಹೇಳಿದ್ದೇವೆ ಮತ್ತು ಹೃದಯದ ನಷ್ಟವು ಯಾವುದೇ ಜೀವಿಗಳಿಗೆ ಮಾರಕವಾಗಿದೆ. ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ಭವಿಷ್ಯವು ಉತ್ತಮವಾಗಿಲ್ಲ. ಆದ್ದರಿಂದ, ಹೈಪ್ ಕುಬರ್ನೆಟಿಸ್ ಬದಲಿಗೆ, ಅನೇಕ ಯೋಜನೆಗಳು AWS ಗಾಗಿ ಸಾಮಾನ್ಯ ಸುಂಕದೊಂದಿಗೆ ಸರಳವಾಗಿ ತಲೆಕೆಡಿಸಿಕೊಳ್ಳಬಾರದು, ಇದು ಅವರ ಸೈಟ್ / ಯೋಜನೆಯಲ್ಲಿನ ಲೋಡ್ನೊಂದಿಗೆ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಆದರೆ AWS ಇನ್ನು ಮುಂದೆ ಫ್ಯಾಶನ್ ಆಗಿಲ್ಲ, ಮತ್ತು ಶೋ-ಆಫ್‌ಗಳು ಹಣಕ್ಕಿಂತ ಹೆಚ್ಚು ಮೌಲ್ಯಯುತವಾಗಿವೆ - ದುರದೃಷ್ಟವಶಾತ್, IT ಪರಿಸರದಲ್ಲಿಯೂ ಸಹ.
ಸರಿ. ಬಹುಶಃ ಯೋಜನೆಗೆ ನಿಜವಾಗಿಯೂ ಕ್ಲಸ್ಟರಿಂಗ್ ಅಗತ್ಯವಿದೆ, ಆದರೆ ಸ್ಥಿತಿಯಿಲ್ಲದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳೊಂದಿಗೆ ಎಲ್ಲವೂ ಸ್ಪಷ್ಟವಾಗಿದ್ದರೆ, ಕ್ಲಸ್ಟರ್ಡ್ ಡೇಟಾಬೇಸ್‌ಗಾಗಿ ನಾವು ಯೋಗ್ಯವಾದ ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕವನ್ನು ಹೇಗೆ ಆಯೋಜಿಸಬಹುದು?
ನಾವು ತಡೆರಹಿತ ಎಂಜಿನಿಯರಿಂಗ್ ಪರಿಹಾರದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದರೆ, ಅದು k8s ಗೆ ಪರಿವರ್ತನೆಯಾಗಿದೆ, ಆಗ ನಮ್ಮ ಮುಖ್ಯ ತಲೆನೋವು ಕ್ಲಸ್ಟರ್ಡ್ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಡೇಟಾ ಪುನರಾವರ್ತನೆಯಾಗಿದೆ. ಕೆಲವು DBMS ಗಳು ತಮ್ಮ ವೈಯಕ್ತಿಕ ನಿದರ್ಶನಗಳ ನಡುವೆ ಡೇಟಾ ವಿತರಣೆಗೆ ಆರಂಭದಲ್ಲಿ ಸಾಕಷ್ಟು ನಿಷ್ಠಾವಂತವಾಗಿವೆ. ಇನ್ನೂ ಅನೇಕರು ಅಷ್ಟು ಸ್ವಾಗತಿಸುವುದಿಲ್ಲ. ಮತ್ತು ನಮ್ಮ ಯೋಜನೆಗಾಗಿ DBMS ಅನ್ನು ಆಯ್ಕೆಮಾಡುವಲ್ಲಿನ ಮುಖ್ಯ ವಾದವು ಕನಿಷ್ಟ ಸಂಪನ್ಮೂಲ ಮತ್ತು ಎಂಜಿನಿಯರಿಂಗ್ ವೆಚ್ಚಗಳೊಂದಿಗೆ ಪುನರಾವರ್ತಿಸುವ ಸಾಮರ್ಥ್ಯವಲ್ಲ. ವಿಶೇಷವಾಗಿ ಯೋಜನೆಯನ್ನು ಆರಂಭದಲ್ಲಿ ಮೈಕ್ರೋ ಸರ್ವಿಸ್ ಆಗಿ ಯೋಜಿಸದಿದ್ದರೆ, ಆದರೆ ಈ ದಿಕ್ಕಿನಲ್ಲಿ ಸರಳವಾಗಿ ವಿಕಸನಗೊಂಡಿತು.
ನೆಟ್ವರ್ಕ್ ಡ್ರೈವ್ಗಳ ವೇಗದ ಬಗ್ಗೆ ಮಾತನಾಡಲು ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ - ಅವುಗಳು ನಿಧಾನವಾಗಿರುತ್ತವೆ. ಆ. ನಮಗೆ ಇನ್ನೂ ನಿಜವಾದ ಅವಕಾಶವಿಲ್ಲ, ಏನಾದರೂ ಸಂಭವಿಸಿದಲ್ಲಿ, ಎಲ್ಲೋ ಹೆಚ್ಚು ಇರುವಲ್ಲಿ DBMS ನಿದರ್ಶನವನ್ನು ಮರುಪ್ರಾರಂಭಿಸಲು, ಉದಾಹರಣೆಗೆ, ಪ್ರೊಸೆಸರ್ ಪವರ್ ಅಥವಾ ಉಚಿತ RAM. ವರ್ಚುವಲೈಸ್ಡ್ ಡಿಸ್ಕ್ ಉಪವ್ಯವಸ್ಥೆಯ ಕಾರ್ಯಕ್ಷಮತೆಗೆ ನಾವು ಬೇಗನೆ ಓಡುತ್ತೇವೆ. ಅಂತೆಯೇ, DBMS ಅನ್ನು ಹತ್ತಿರದಲ್ಲಿರುವ ತನ್ನದೇ ಆದ ವೈಯಕ್ತಿಕ ಯಂತ್ರಗಳ ಸೆಟ್‌ಗೆ ಹೊಡೆಯಬೇಕು. ಅಥವಾ ಹೇಳಲಾದ ಮೀಸಲುಗಳಿಗಾಗಿ ಸಾಕಷ್ಟು ವೇಗದ ಡೇಟಾ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅನ್ನು ಹೇಗಾದರೂ ಪ್ರತ್ಯೇಕವಾಗಿ ತಂಪಾಗಿಸುವುದು ಅವಶ್ಯಕ.
ವರ್ಚುವಲ್ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗಳ ವಿಷಯವನ್ನು ಮುಂದುವರಿಸುವುದು: ಡಾಕರ್ ಸಂಪುಟಗಳು, ದುರದೃಷ್ಟವಶಾತ್, ಸಮಸ್ಯೆ-ಮುಕ್ತವಾಗಿಲ್ಲ. ಸಾಮಾನ್ಯವಾಗಿ, ದೀರ್ಘಾವಧಿಯ ವಿಶ್ವಾಸಾರ್ಹ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯಂತಹ ವಿಷಯದಲ್ಲಿ, ನಾನು ಅತ್ಯಂತ ತಾಂತ್ರಿಕವಾಗಿ ಸರಳವಾದ ಯೋಜನೆಗಳೊಂದಿಗೆ ಮಾಡಲು ಬಯಸುತ್ತೇನೆ. ಮತ್ತು ಕಂಟೇನರ್‌ನ ಎಫ್‌ಎಸ್‌ನಿಂದ ಪೋಷಕ ಹೋಸ್ಟ್‌ನ ಎಫ್‌ಎಸ್‌ಗೆ ಹೊಸ ಅಮೂರ್ತ ಪದರವನ್ನು ಸೇರಿಸುವುದು ಸ್ವತಃ ಅಪಾಯವಾಗಿದೆ. ಆದರೆ ಕಂಟೈನರೈಸೇಶನ್ ಬೆಂಬಲ ವ್ಯವಸ್ಥೆಯ ಕಾರ್ಯಾಚರಣೆಯು ಈ ಪದರಗಳ ನಡುವೆ ಡೇಟಾವನ್ನು ರವಾನಿಸುವಲ್ಲಿ ತೊಂದರೆಗಳನ್ನು ಎದುರಿಸಿದಾಗ, ಅದು ನಿಜವಾಗಿಯೂ ವಿಪತ್ತು. ಈ ಸಮಯದಲ್ಲಿ, ಪ್ರಗತಿಪರ ಮಾನವೀಯತೆಗೆ ತಿಳಿದಿರುವ ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳು ನಿರ್ಮೂಲನೆಯಾಗಿವೆ. ಆದರೆ ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೀರಿ, ಯಾಂತ್ರಿಕತೆಯು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ, ಅದು ಸುಲಭವಾಗಿ ಒಡೆಯುತ್ತದೆ.
ಈ ಎಲ್ಲಾ "ಸಾಹಸಗಳ" ಬೆಳಕಿನಲ್ಲಿ, ಡೇಟಾಬೇಸ್ ಅನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಇಡುವುದು ಹೆಚ್ಚು ಲಾಭದಾಯಕ ಮತ್ತು ಸುಲಭವಾಗಿದೆ, ಮತ್ತು ನೀವು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕಂಟೈನರೈಸ್ ಮಾಡಬೇಕಾಗಿದ್ದರೂ ಸಹ, ಅದು ತನ್ನದೇ ಆದ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲಿ ಮತ್ತು ವಿತರಣಾ ಗೇಟ್‌ವೇ ಮೂಲಕ ಏಕಕಾಲಿಕ ಸಂವಹನವನ್ನು ಪಡೆಯಲಿ ಡೇಟಾಬೇಸ್, ಇದನ್ನು ಒಮ್ಮೆ ಮಾತ್ರ ಓದಲಾಗುತ್ತದೆ ಮತ್ತು ಬರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ. ಈ ವಿಧಾನವು ದೋಷಗಳು ಮತ್ತು ಡಿಸಿಂಕ್ರೊನೈಸೇಶನ್ ಸಾಧ್ಯತೆಯನ್ನು ಕನಿಷ್ಠಕ್ಕೆ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
ನಾವು ಯಾವುದಕ್ಕೆ ಕಾರಣವಾಗುತ್ತಿದ್ದೇವೆ? ಇದಲ್ಲದೆ, ಡೇಟಾಬೇಸ್ ಕಂಟೈನರೈಸೇಶನ್ ನಿಜವಾದ ಅವಶ್ಯಕತೆಯಿರುವಲ್ಲಿ ಸೂಕ್ತವಾಗಿದೆ. ನೀವು ಪೂರ್ಣ-ಅಪ್ಲಿಕೇಶನ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ತುಂಬಲು ಸಾಧ್ಯವಿಲ್ಲ ಮತ್ತು ನೀವು ಎರಡು ಡಜನ್ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳನ್ನು ಹೊಂದಿರುವಂತೆ ಅದನ್ನು ತಿರುಗಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ - ಅದು ಆ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಮತ್ತು ಇದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.
.ಟ್‌ಪುಟ್‌ಗೆ ಬದಲಾಗಿ
"ಡೇಟಾಬೇಸ್ ಅನ್ನು ವರ್ಚುವಲೈಸ್ ಮಾಡಲು ಅಥವಾ ಇಲ್ಲವೇ" ಎಂಬ ಸ್ಪಷ್ಟ ತೀರ್ಮಾನಕ್ಕಾಗಿ ನೀವು ಕಾಯುತ್ತಿದ್ದರೆ, ನಾವು ನಿಮ್ಮನ್ನು ನಿರಾಶೆಗೊಳಿಸುತ್ತೇವೆ: ಅದು ಇಲ್ಲಿ ಇರುವುದಿಲ್ಲ. ಏಕೆಂದರೆ ಯಾವುದೇ ಮೂಲಸೌಕರ್ಯ ಪರಿಹಾರವನ್ನು ರಚಿಸುವಾಗ, ಒಬ್ಬರು ಮಾರ್ಗದರ್ಶನ ನೀಡಬೇಕು ಫ್ಯಾಷನ್ ಮತ್ತು ಪ್ರಗತಿಯಿಂದ ಅಲ್ಲ, ಆದರೆ, ಮೊದಲನೆಯದಾಗಿ, ಸಾಮಾನ್ಯ ಜ್ಞಾನದಿಂದ.
ಕುಬರ್ನೆಟಿಸ್‌ನೊಂದಿಗೆ ಬರುವ ತತ್ವಗಳು ಮತ್ತು ಸಾಧನಗಳು ಸಂಪೂರ್ಣವಾಗಿ ಹೊಂದಿಕೊಳ್ಳುವ ಯೋಜನೆಗಳಿವೆ ಮತ್ತು ಅಂತಹ ಯೋಜನೆಗಳಲ್ಲಿ ಕನಿಷ್ಠ ಬ್ಯಾಕೆಂಡ್ ಪ್ರದೇಶದಲ್ಲಿ ಶಾಂತಿ ಇರುತ್ತದೆ. ಮತ್ತು ಕಂಟೈನರೈಸೇಶನ್ ಅಗತ್ಯವಿಲ್ಲದ ಯೋಜನೆಗಳಿವೆ, ಆದರೆ ಸಾಮಾನ್ಯ ಸರ್ವರ್ ಮೂಲಸೌಕರ್ಯ, ಏಕೆಂದರೆ ಅವು ಮೂಲಭೂತವಾಗಿ ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಕ್ಲಸ್ಟರ್ ಮಾದರಿಗೆ ಮರುಹೊಂದಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಅವು ಬೀಳುತ್ತವೆ.
ಮೂಲ: www.habr.com