ಎಲ್ಲರಿಗು ನಮಸ್ಖರ! ನಮಗೆ ಉತ್ತಮ ಸುದ್ದಿ ಇದೆ, OTUS ಮತ್ತೆ ಜೂನ್‌ನಲ್ಲಿ ಕೋರ್ಸ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಿದೆ , ಇದಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ ನಾವು ಸಾಂಪ್ರದಾಯಿಕವಾಗಿ ನಿಮ್ಮೊಂದಿಗೆ ಉಪಯುಕ್ತ ವಸ್ತುಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತೇವೆ.
ಯಾವುದೇ ಸಂದರ್ಭವಿಲ್ಲದೆ ನೀವು ಈ ಸಂಪೂರ್ಣ ಮೈಕ್ರೊ ಸರ್ವೀಸಸ್ ವಿಷಯವನ್ನು ಕಂಡರೆ, ಇದು ಸ್ವಲ್ಪ ವಿಚಿತ್ರವಾಗಿದೆ ಎಂದು ಭಾವಿಸಿದ್ದಕ್ಕಾಗಿ ನೀವು ಕ್ಷಮಿಸಲ್ಪಡುತ್ತೀರಿ. ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಸಂಪರ್ಕಗೊಂಡಿರುವ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ತುಣುಕುಗಳಾಗಿ ವಿಭಜಿಸುವುದು ಎಂದರೆ ಪರಿಣಾಮವಾಗಿ ವಿತರಿಸಿದ ಸಿಸ್ಟಮ್‌ಗೆ ಸಂಕೀರ್ಣ ದೋಷ ಸಹಿಷ್ಣು ವಿಧಾನಗಳನ್ನು ಸೇರಿಸುವುದು ಎಂದರ್ಥ.
ಈ ವಿಧಾನವು ಅನೇಕ ಸ್ವತಂತ್ರ ಸೇವೆಗಳಾಗಿ ವಿಭಜಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆಯಾದರೂ, ಅಂತಿಮ ಗುರಿಯು ಆ ಸೇವೆಗಳನ್ನು ವಿಭಿನ್ನ ಯಂತ್ರಗಳಲ್ಲಿ ಚಾಲನೆ ಮಾಡುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನದಾಗಿದೆ. ನಾವು ಇಲ್ಲಿ ಹೊರಗಿನ ಪ್ರಪಂಚದೊಂದಿಗೆ ಸಂವಹನದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ, ಅದು ಅದರ ಸಾರದಲ್ಲಿಯೂ ಸಹ ವಿತರಿಸಲ್ಪಡುತ್ತದೆ. ತಾಂತ್ರಿಕ ಅರ್ಥದಲ್ಲಿ ಅಲ್ಲ, ಬದಲಿಗೆ ಅನೇಕ ಜನರು, ತಂಡಗಳು, ಕಾರ್ಯಕ್ರಮಗಳು ಮತ್ತು ಈ ಪ್ರತಿಯೊಂದು ಭಾಗಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯ ಅರ್ಥದಲ್ಲಿ ಹೇಗಾದರೂ ತನ್ನ ಕೆಲಸವನ್ನು ಮಾಡಬೇಕಾಗಿದೆ.
ಕಂಪನಿಗಳು, ಉದಾಹರಣೆಗೆ, ಕೆಲವು ಗುರಿಯ ಸಾಧನೆಗೆ ಸಾಮೂಹಿಕವಾಗಿ ಕೊಡುಗೆ ನೀಡುವ ವಿತರಿಸಿದ ವ್ಯವಸ್ಥೆಗಳ ಸಂಗ್ರಹವಾಗಿದೆ. ನಾವು ದಶಕಗಳಿಂದ ಈ ಸತ್ಯವನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದ್ದೇವೆ, FTPing ಫೈಲ್‌ಗಳ ಮೂಲಕ ಏಕೀಕರಣವನ್ನು ಸಾಧಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ ಅಥವಾ ನಮ್ಮದೇ ಆದ ಪ್ರತ್ಯೇಕ ಗುರಿಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುವಾಗ ಎಂಟರ್‌ಪ್ರೈಸ್ ಏಕೀಕರಣ ಸಾಧನಗಳನ್ನು ಬಳಸುತ್ತೇವೆ. ಆದರೆ ಸೇವೆಗಳ ಆಗಮನದೊಂದಿಗೆ, ಎಲ್ಲವೂ ಬದಲಾಗಿದೆ. ಸೇವೆಗಳು ನಮಗೆ ಹಾರಿಜಾನ್‌ನಿಂದ ಆಚೆಗೆ ನೋಡಲು ಮತ್ತು ಒಟ್ಟಿಗೆ ಕೆಲಸ ಮಾಡುವ ಪರಸ್ಪರ ಅವಲಂಬಿತ ಕಾರ್ಯಕ್ರಮಗಳ ಜಗತ್ತನ್ನು ನೋಡಲು ನಮಗೆ ಸಹಾಯ ಮಾಡಿದೆ. ಆದಾಗ್ಯೂ, ಯಶಸ್ವಿಯಾಗಿ ಕೆಲಸ ಮಾಡಲು, ಎರಡು ಮೂಲಭೂತವಾಗಿ ವಿಭಿನ್ನ ಪ್ರಪಂಚಗಳನ್ನು ಗುರುತಿಸುವುದು ಮತ್ತು ವಿನ್ಯಾಸಗೊಳಿಸುವುದು ಅವಶ್ಯಕ: ಬಾಹ್ಯ ಪ್ರಪಂಚ, ನಾವು ಅನೇಕ ಇತರ ಸೇವೆಗಳ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ವಾಸಿಸುತ್ತೇವೆ ಮತ್ತು ನಮ್ಮ ವೈಯಕ್ತಿಕ, ಆಂತರಿಕ ಜಗತ್ತು, ಅಲ್ಲಿ ನಾವು ಏಕಾಂಗಿಯಾಗಿ ಆಳುತ್ತೇವೆ.
ಈ ವಿತರಣಾ ಪ್ರಪಂಚವು ನಾವು ಬೆಳೆದು ಒಗ್ಗಿಕೊಂಡಿರುವ ಪ್ರಪಂಚಕ್ಕಿಂತ ಭಿನ್ನವಾಗಿದೆ. ಸಾಂಪ್ರದಾಯಿಕ ಏಕಶಿಲೆಯ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ನಿರ್ಮಿಸುವ ತತ್ವಗಳು ಟೀಕೆಗೆ ನಿಲ್ಲುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ಈ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಸರಿಯಾಗಿ ಪಡೆಯುವುದು ತಂಪಾದ ವೈಟ್‌ಬೋರ್ಡ್ ರೇಖಾಚಿತ್ರ ಅಥವಾ ಪರಿಕಲ್ಪನೆಯ ತಂಪಾದ ಪುರಾವೆಯನ್ನು ರಚಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನದಾಗಿದೆ. ಅಂತಹ ವ್ಯವಸ್ಥೆಯು ದೀರ್ಘಕಾಲದವರೆಗೆ ಯಶಸ್ವಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಮುಖ್ಯ ವಿಷಯವಾಗಿದೆ. ಅದೃಷ್ಟವಶಾತ್, ಸೇವೆಗಳು ವಿಭಿನ್ನವಾಗಿ ಕಾಣುತ್ತಿದ್ದರೂ ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಇವೆ. ಇನ್ನೂ ಪ್ರಸ್ತುತವಾಗಿವೆ, ಡಾಕರ್, ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಸ್ವಲ್ಪ ಕಳಪೆ ಹಿಪ್ಸ್ಟರ್ ಗಡ್ಡಗಳೊಂದಿಗೆ ಸಹ ಮಸಾಲೆ ಹಾಕಲಾಗುತ್ತದೆ.
ಆದ್ದರಿಂದ ಇಂದು ನಾವು ನಿಯಮಗಳು ಹೇಗೆ ಬದಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ, ನಾವು ಸೇವೆಗಳನ್ನು ಸಂಪರ್ಕಿಸುವ ವಿಧಾನ ಮತ್ತು ಅವುಗಳು ಪರಸ್ಪರ ರವಾನಿಸುವ ಡೇಟಾವನ್ನು ಏಕೆ ಮರುಪರಿಶೀಲಿಸಬೇಕು ಮತ್ತು ಅದನ್ನು ಮಾಡಲು ನಮಗೆ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಸಾಧನಗಳು ಏಕೆ ಬೇಕು.
ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಯಾವಾಗಲೂ ನಿಮ್ಮ ಸ್ನೇಹಿತನಾಗಿರುವುದಿಲ್ಲ
ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳು ಪರಸ್ಪರ ಸ್ವತಂತ್ರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು. ಈ ಆಸ್ತಿಯೇ ಅವರಿಗೆ ಹೆಚ್ಚಿನ ಮೌಲ್ಯವನ್ನು ನೀಡುತ್ತದೆ. ಇದೇ ಆಸ್ತಿಯು ಸೇವೆಗಳನ್ನು ಅಳೆಯಲು ಮತ್ತು ಬೆಳೆಯಲು ಅನುಮತಿಸುತ್ತದೆ. ಕ್ವಾಡ್ರಿಲಿಯನ್‌ಗಟ್ಟಲೆ ಬಳಕೆದಾರರಿಗೆ ಅಥವಾ ಪೆಟಾಬೈಟ್‌ಗಳ ಡೇಟಾಗೆ ಸ್ಕೇಲಿಂಗ್ ಮಾಡುವ ಅರ್ಥದಲ್ಲಿ (ಅವುಗಳು ಅಲ್ಲಿಯೂ ಸಹ ಸಹಾಯ ಮಾಡಬಹುದು), ಆದರೆ ತಂಡಗಳು ಮತ್ತು ಸಂಸ್ಥೆಗಳು ನಿರಂತರವಾಗಿ ಬೆಳೆಯುತ್ತಿರುವಾಗ ಜನರ ವಿಷಯದಲ್ಲಿ ಸ್ಕೇಲಿಂಗ್ ಅರ್ಥದಲ್ಲಿ.
ಆದಾಗ್ಯೂ, ಸ್ವಾತಂತ್ರ್ಯವು ಎರಡು ಅಲುಗಿನ ಕತ್ತಿಯಾಗಿದೆ. ಅಂದರೆ, ಸೇವೆಯು ಸುಲಭವಾಗಿ ಮತ್ತು ನೈಸರ್ಗಿಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆದರೆ ಇನ್ನೊಂದು ಸೇವೆಯ ಬಳಕೆಯ ಅಗತ್ಯವಿರುವ ಸೇವೆಯೊಳಗೆ ಕಾರ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದರೆ, ನಂತರ ನಾವು ಎರಡೂ ಸೇವೆಗಳಿಗೆ ಬಹುತೇಕ ಏಕಕಾಲದಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಬೇಕಾಗಬಹುದು. ಏಕಶಿಲೆಯಲ್ಲಿ ಇದನ್ನು ಮಾಡಲು ಸುಲಭವಾಗಿದೆ, ನೀವು ಬದಲಾವಣೆಯನ್ನು ಮಾಡಿ ಮತ್ತು ಅದನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು ಕಳುಹಿಸಿ, ಆದರೆ ಸ್ವತಂತ್ರ ಸೇವೆಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುವ ಸಂದರ್ಭದಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳಿರುತ್ತವೆ. ತಂಡಗಳು ಮತ್ತು ಬಿಡುಗಡೆ ಚಕ್ರಗಳ ನಡುವಿನ ಸಮನ್ವಯವು ಚುರುಕುತನವನ್ನು ನಾಶಪಡಿಸುತ್ತದೆ.
ಪ್ರಮಾಣಿತ ವಿಧಾನದ ಭಾಗವಾಗಿ, ಅವರು ಸರಳವಾಗಿ ಕಿರಿಕಿರಿಗೊಳಿಸುವ ಅಂತ್ಯದಿಂದ ಅಂತ್ಯದ ಬದಲಾವಣೆಗಳನ್ನು ತಪ್ಪಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ, ಸೇವೆಗಳ ನಡುವೆ ಕ್ರಿಯಾತ್ಮಕತೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವಿಭಜಿಸುತ್ತಾರೆ. ಏಕ ಸೈನ್-ಆನ್ ಸೇವೆಯು ಇಲ್ಲಿ ಉತ್ತಮ ಉದಾಹರಣೆಯಾಗಿದೆ. ಇದು ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಪಾತ್ರವನ್ನು ಹೊಂದಿದೆ ಅದು ಅದನ್ನು ಇತರ ಸೇವೆಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ. ಈ ಸ್ಪಷ್ಟವಾದ ಪ್ರತ್ಯೇಕತೆಯು ಅದರ ಸುತ್ತಲಿನ ಸೇವೆಗಳ ಮೇಲೆ ವೇಗವಾಗಿ ಬದಲಾಗುತ್ತಿರುವ ಬೇಡಿಕೆಗಳ ಜಗತ್ತಿನಲ್ಲಿ, ಏಕ ಸೈನ್-ಆನ್ ಸೇವೆಯು ಬದಲಾಗುವ ಸಾಧ್ಯತೆಯಿಲ್ಲ. ಇದು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಸೀಮಿತ ಸನ್ನಿವೇಶದಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ.
ಸಮಸ್ಯೆಯೆಂದರೆ, ನೈಜ ಜಗತ್ತಿನಲ್ಲಿ, ವ್ಯಾಪಾರ ಸೇವೆಗಳು ಎಲ್ಲಾ ಸಮಯದಲ್ಲೂ ಒಂದೇ ರೀತಿಯ ಪಾತ್ರಗಳ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಅದೇ ವ್ಯಾಪಾರ ಸೇವೆಗಳು ಇತರ ರೀತಿಯ ಸೇವೆಗಳಿಂದ ಬರುವ ಡೇಟಾದೊಂದಿಗೆ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ನೀವು ಆನ್‌ಲೈನ್ ಚಿಲ್ಲರೆ ವ್ಯಾಪಾರದಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದರೆ, ಆರ್ಡರ್ ಹರಿವು, ಉತ್ಪನ್ನ ಕ್ಯಾಟಲಾಗ್ ಅಥವಾ ಬಳಕೆದಾರರ ಮಾಹಿತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದು ನಿಮ್ಮ ಅನೇಕ ಸೇವೆಗಳಿಗೆ ಅಗತ್ಯವಾಗುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಸೇವೆಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಈ ಡೇಟಾಗೆ ಪ್ರವೇಶದ ಅಗತ್ಯವಿದೆ.
ಹೆಚ್ಚಿನ ವ್ಯಾಪಾರ ಸೇವೆಗಳು ಒಂದೇ ಡೇಟಾ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಅವರ ಕೆಲಸವು ಏಕರೂಪವಾಗಿ ಹೆಣೆದುಕೊಂಡಿದೆ.
ಆದ್ದರಿಂದ ನಾವು ಮಾತನಾಡಲು ಯೋಗ್ಯವಾದ ಒಂದು ಪ್ರಮುಖ ಅಂಶಕ್ಕೆ ಬರುತ್ತೇವೆ. ಪ್ರತ್ಯೇಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮೂಲಸೌಕರ್ಯ ಘಟಕಗಳಿಗೆ ಸೇವೆಗಳು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದರೂ, ಹೆಚ್ಚಿನ ವ್ಯಾಪಾರ ಸೇವೆಗಳು ಹೆಚ್ಚು ನಿಕಟವಾಗಿ ಹೆಣೆದುಕೊಂಡಿವೆ.
ಡೇಟಾ ದ್ವಿಗುಣ
ಸೇವೆ-ಆಧಾರಿತ ವಿಧಾನಗಳು ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರಬಹುದು, ಆದರೆ ಸೇವೆಗಳ ನಡುವೆ ದೊಡ್ಡ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಹೇಗೆ ಹಂಚಿಕೊಳ್ಳುವುದು ಎಂಬುದರ ಕುರಿತು ಅವುಗಳು ಇನ್ನೂ ಒಳನೋಟವನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ.
ಡೇಟಾ ಮತ್ತು ಸೇವೆಗಳು ಬೇರ್ಪಡಿಸಲಾಗದವು ಎಂಬುದು ಮುಖ್ಯ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಒಂದೆಡೆ, ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ನಮ್ಮನ್ನು ಡೇಟಾವನ್ನು ಮರೆಮಾಡಲು ಪ್ರೋತ್ಸಾಹಿಸುತ್ತದೆ ಇದರಿಂದ ಸೇವೆಗಳು ಪರಸ್ಪರ ಬೇರ್ಪಡಿಸಬಹುದು ಮತ್ತು ಅವುಗಳ ಬೆಳವಣಿಗೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಬದಲಾವಣೆಗಳಿಗೆ ಅನುಕೂಲವಾಗುತ್ತದೆ. ಮತ್ತೊಂದೆಡೆ, ನಾವು ಯಾವುದೇ ಇತರ ಡೇಟಾದಂತೆಯೇ ಹಂಚಿಕೊಂಡ ಡೇಟಾವನ್ನು ಮುಕ್ತವಾಗಿ ವಿಭಜಿಸಲು ಮತ್ತು ವಶಪಡಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಯಾವುದೇ ಇತರ ಮಾಹಿತಿ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಮುಕ್ತವಾಗಿ ಕೆಲಸ ಮಾಡಲು ತಕ್ಷಣವೇ ಪ್ರಾರಂಭಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಆದಾಗ್ಯೂ, ಮಾಹಿತಿ ವ್ಯವಸ್ಥೆಗಳು ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಷನ್‌ನೊಂದಿಗೆ ಸ್ವಲ್ಪ ಸಂಬಂಧವನ್ನು ಹೊಂದಿವೆ. ವಾಸ್ತವವಾಗಿ, ಇದು ಸಾಕಷ್ಟು ವಿರುದ್ಧವಾಗಿದೆ. ಡೇಟಾಬೇಸ್‌ಗಳು ತಾವು ಸಂಗ್ರಹಿಸುವ ಡೇಟಾಗೆ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸಲು ಅವರು ಮಾಡಬಹುದಾದ ಎಲ್ಲವನ್ನೂ ಮಾಡುತ್ತವೆ. ಅವರು ನಿಮಗೆ ಅಗತ್ಯವಿರುವಂತೆ ಡೇಟಾವನ್ನು ಮಾರ್ಪಡಿಸಲು ಅನುಮತಿಸುವ ಪ್ರಬಲ ಡಿಕ್ಲೇರೇಟಿವ್ ಇಂಟರ್ಫೇಸ್ನೊಂದಿಗೆ ಬರುತ್ತಾರೆ. ಪ್ರಾಥಮಿಕ ಸಂಶೋಧನಾ ಹಂತದಲ್ಲಿ ಇಂತಹ ಕಾರ್ಯಚಟುವಟಿಕೆಯು ಮುಖ್ಯವಾಗಿದೆ, ಆದರೆ ನಿರಂತರವಾಗಿ ವಿಕಸನಗೊಳ್ಳುತ್ತಿರುವ ಸೇವೆಯ ಬೆಳೆಯುತ್ತಿರುವ ಸಂಕೀರ್ಣತೆಯನ್ನು ನಿರ್ವಹಿಸಲು ಅಲ್ಲ.
ಮತ್ತು ಇಲ್ಲಿ ಒಂದು ಸಂದಿಗ್ಧತೆ ಉದ್ಭವಿಸುತ್ತದೆ. ವಿರೋಧಾಭಾಸ. ಇಬ್ಭಾಗ. ಎಲ್ಲಾ ನಂತರ, ಮಾಹಿತಿ ವ್ಯವಸ್ಥೆಗಳು ಡೇಟಾವನ್ನು ಒದಗಿಸುವ ಬಗ್ಗೆ, ಮತ್ತು ಸೇವೆಗಳು ಮರೆಮಾಚುವ ಬಗ್ಗೆ.
ಈ ಎರಡು ಶಕ್ತಿಗಳು ಮೂಲಭೂತವಾಗಿವೆ. ಅವರು ನಮ್ಮ ಹೆಚ್ಚಿನ ಕೆಲಸವನ್ನು ಬೆಂಬಲಿಸುತ್ತಾರೆ, ನಾವು ನಿರ್ಮಿಸುವ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಶ್ರೇಷ್ಠತೆಗಾಗಿ ನಿರಂತರವಾಗಿ ಹೋರಾಡುತ್ತಾರೆ.
ಸೇವಾ ವ್ಯವಸ್ಥೆಗಳು ಬೆಳೆದಂತೆ ಮತ್ತು ವಿಕಸನಗೊಳ್ಳುತ್ತಿದ್ದಂತೆ, ಡೇಟಾ ದ್ವಿಗುಣದ ಪರಿಣಾಮಗಳನ್ನು ನಾವು ಅನೇಕ ರೀತಿಯಲ್ಲಿ ನೋಡುತ್ತೇವೆ. ಒಂದೋ ಸೇವಾ ಇಂಟರ್ಫೇಸ್ ಬೆಳೆಯುತ್ತದೆ, ನಿರಂತರವಾಗಿ ಹೆಚ್ಚುತ್ತಿರುವ ಕಾರ್ಯವನ್ನು ಒದಗಿಸುತ್ತದೆ ಮತ್ತು ತುಂಬಾ ಅಲಂಕಾರಿಕ ಸ್ವದೇಶಿ ಡೇಟಾಬೇಸ್‌ನಂತೆ ಕಾಣಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಅಥವಾ ನಾವು ನಿರಾಶೆಗೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಸೇವೆಯಿಂದ ಸೇವೆಗೆ ಸಂಪೂರ್ಣ ಡೇಟಾ ಸೆಟ್‌ಗಳನ್ನು ಹಿಂಪಡೆಯಲು ಅಥವಾ ಸರಿಸಲು ಕೆಲವು ಮಾರ್ಗವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತೇವೆ.
ಪ್ರತಿಯಾಗಿ, ಅಲಂಕಾರಿಕ ಸ್ವದೇಶಿ ಡೇಟಾಬೇಸ್‌ನಂತೆ ಕಾಣುವಂತಹದನ್ನು ರಚಿಸುವುದು ಸಮಸ್ಯೆಗಳ ಸಂಪೂರ್ಣ ಹೋಸ್ಟ್‌ಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಇದು ಏಕೆ ಅಪಾಯಕಾರಿ ಎಂಬುದರ ಕುರಿತು ನಾವು ವಿವರಗಳಿಗೆ ಹೋಗುವುದಿಲ್ಲ ಹಂಚಿದ ಡೇಟಾಬೇಸ್, ಇದು ಗಮನಾರ್ಹವಾದ ದುಬಾರಿ ಎಂಜಿನಿಯರಿಂಗ್ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ ಎಂದು ಹೇಳೋಣ ಅದನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಕಂಪನಿಗೆ.
ಡೇಟಾ ವಾಲ್ಯೂಮ್‌ಗಳು ಸೇವಾ ಗಡಿ ಸಮಸ್ಯೆಗಳನ್ನು ವರ್ಧಿಸುತ್ತವೆ ಎಂಬುದು ಕೆಟ್ಟದಾಗಿದೆ. ಸೇವೆಯೊಳಗೆ ಹೆಚ್ಚು ಹಂಚಿಕೊಂಡ ಡೇಟಾ ಇರುತ್ತದೆ, ಇಂಟರ್ಫೇಸ್ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗುತ್ತದೆ ಮತ್ತು ವಿಭಿನ್ನ ಸೇವೆಗಳಿಂದ ಬರುವ ಡೇಟಾ ಸೆಟ್‌ಗಳನ್ನು ಸಂಯೋಜಿಸುವುದು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ.
ಸಂಪೂರ್ಣ ಡೇಟಾ ಸೆಟ್‌ಗಳನ್ನು ಹೊರತೆಗೆಯುವ ಮತ್ತು ಚಲಿಸುವ ಪರ್ಯಾಯ ವಿಧಾನವು ಅದರ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದೆ. ಈ ಪ್ರಶ್ನೆಗೆ ಸಾಮಾನ್ಯವಾದ ವಿಧಾನವು ಸಂಪೂರ್ಣ ಡೇಟಾಸೆಟ್ ಅನ್ನು ಹಿಂಪಡೆಯುವುದು ಮತ್ತು ಸಂಗ್ರಹಿಸುವುದು ಮತ್ತು ನಂತರ ಅದನ್ನು ಪ್ರತಿ ಸೇವಿಸುವ ಸೇವೆಯಲ್ಲಿ ಸ್ಥಳೀಯವಾಗಿ ಸಂಗ್ರಹಿಸುವುದು.
ವಿಭಿನ್ನ ಸೇವೆಗಳು ಅವರು ಸೇವಿಸುವ ಡೇಟಾವನ್ನು ವಿಭಿನ್ನವಾಗಿ ಅರ್ಥೈಸಿಕೊಳ್ಳುವುದು ಸಮಸ್ಯೆಯಾಗಿದೆ. ಈ ಡೇಟಾ ಯಾವಾಗಲೂ ಕೈಯಲ್ಲಿದೆ. ಅವುಗಳನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಮಾರ್ಪಡಿಸಲಾಗಿದೆ ಮತ್ತು ಸಂಸ್ಕರಿಸಲಾಗುತ್ತದೆ. ಅವರು ಮೂಲದಲ್ಲಿರುವ ಡೇಟಾದೊಂದಿಗೆ ಸಾಮಾನ್ಯವಾದ ಯಾವುದನ್ನಾದರೂ ಹೊಂದುವುದನ್ನು ತ್ವರಿತವಾಗಿ ನಿಲ್ಲಿಸುತ್ತಾರೆ.
ಹೆಚ್ಚು ರೂಪಾಂತರಗೊಳ್ಳುವ ಪ್ರತಿಗಳು, ಹೆಚ್ಚು ಡೇಟಾವು ಕಾಲಾನಂತರದಲ್ಲಿ ಬದಲಾಗುತ್ತದೆ.
ವಿಷಯಗಳನ್ನು ಇನ್ನಷ್ಟು ಹದಗೆಡಿಸಲು, ಅಂತಹ ಡೇಟಾವನ್ನು ಸಿಂಹಾವಲೋಕನದಲ್ಲಿ ಸರಿಪಡಿಸಲು ಕಷ್ಟವಾಗುತ್ತದೆ ( ಇಲ್ಲಿಯೇ ಅದು ನಿಜವಾಗಿಯೂ ರಕ್ಷಣೆಗೆ ಬರಬಹುದು). ವಾಸ್ತವವಾಗಿ, ವ್ಯವಹಾರಗಳು ಎದುರಿಸುತ್ತಿರುವ ಕೆಲವು ಪರಿಹರಿಸಲಾಗದ ತಂತ್ರಜ್ಞಾನದ ಸಮಸ್ಯೆಗಳು ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಗುಣಿಸುವ ವಿಭಿನ್ನ ಡೇಟಾದಿಂದ ಉದ್ಭವಿಸುತ್ತವೆ.
ಈ ಸಮಸ್ಯೆಗೆ ಪರಿಹಾರವನ್ನು ಕಂಡುಹಿಡಿಯಲು, ಹಂಚಿಕೊಂಡ ಡೇಟಾದ ಬಗ್ಗೆ ನಾವು ವಿಭಿನ್ನವಾಗಿ ಯೋಚಿಸಬೇಕು. ನಾವು ನಿರ್ಮಿಸುವ ವಾಸ್ತುಶಿಲ್ಪದಲ್ಲಿ ಅವು ಮೊದಲ ದರ್ಜೆಯ ವಸ್ತುಗಳಾಗಬೇಕು. ಅಂತಹ ಡೇಟಾವನ್ನು "ಬಾಹ್ಯ" ಎಂದು ಕರೆಯುತ್ತದೆ, ಮತ್ತು ಇದು ಬಹಳ ಮುಖ್ಯವಾದ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ. ನಮಗೆ ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಅಗತ್ಯವಿದೆ ಆದ್ದರಿಂದ ನಾವು ಸೇವೆಯ ಒಳಗಿನ ಕಾರ್ಯಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುವುದಿಲ್ಲ, ಆದರೆ ಸೇವೆಗಳಿಗೆ ಹಂಚಿದ ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸಲು ನಾವು ಸುಲಭಗೊಳಿಸಬೇಕಾಗಿದೆ ಆದ್ದರಿಂದ ಅವರು ತಮ್ಮ ಕೆಲಸಗಳನ್ನು ಸರಿಯಾಗಿ ಮಾಡಬಹುದು.
ಸಮಸ್ಯೆಯೆಂದರೆ ಯಾವುದೇ ವಿಧಾನವು ಇಂದು ಪ್ರಸ್ತುತವಾಗಿಲ್ಲ, ಏಕೆಂದರೆ ಸೇವಾ ಇಂಟರ್ಫೇಸ್‌ಗಳು ಅಥವಾ ಸಂದೇಶ ಕಳುಹಿಸುವಿಕೆ ಅಥವಾ ಹಂಚಿಕೆಯ ಡೇಟಾಬೇಸ್ ಬಾಹ್ಯ ಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಉತ್ತಮ ಪರಿಹಾರವನ್ನು ನೀಡುವುದಿಲ್ಲ. ಯಾವುದೇ ಪ್ರಮಾಣದಲ್ಲಿ ಡೇಟಾ ವಿನಿಮಯಕ್ಕೆ ಸೇವಾ ಇಂಟರ್ಫೇಸ್‌ಗಳು ಸರಿಯಾಗಿ ಸೂಕ್ತವಲ್ಲ. ಸಂದೇಶ ಕಳುಹಿಸುವಿಕೆಯು ಡೇಟಾವನ್ನು ಚಲಿಸುತ್ತದೆ ಆದರೆ ಅದರ ಇತಿಹಾಸವನ್ನು ಸಂಗ್ರಹಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಡೇಟಾ ಕಾಲಾನಂತರದಲ್ಲಿ ದೋಷಪೂರಿತವಾಗುತ್ತದೆ. ಹಂಚಿಕೆಯ ಡೇಟಾಬೇಸ್‌ಗಳು ಒಂದು ಹಂತದಲ್ಲಿ ಹೆಚ್ಚು ಗಮನಹರಿಸುತ್ತವೆ, ಅದು ಪ್ರಗತಿಯನ್ನು ತಡೆಹಿಡಿಯುತ್ತದೆ. ಡೇಟಾ ವೈಫಲ್ಯದ ಚಕ್ರದಲ್ಲಿ ನಾವು ಅನಿವಾರ್ಯವಾಗಿ ಸಿಲುಕಿಕೊಳ್ಳುತ್ತೇವೆ:
ಡೇಟಾ ವೈಫಲ್ಯದ ಚಕ್ರ
ಸ್ಟ್ರೀಮ್‌ಗಳು: ಡೇಟಾ ಮತ್ತು ಸೇವೆಗಳಿಗೆ ವಿಕೇಂದ್ರೀಕೃತ ವಿಧಾನ
ತಾತ್ತ್ವಿಕವಾಗಿ, ಹಂಚಿದ ಡೇಟಾದೊಂದಿಗೆ ಸೇವೆಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ವಿಧಾನವನ್ನು ನಾವು ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ. ಈ ಹಂತದಲ್ಲಿ, ಎರಡೂ ವಿಧಾನವು ಮೇಲೆ ತಿಳಿಸಲಾದ ದ್ವಿಗುಣವನ್ನು ಎದುರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಅದು ಕಣ್ಮರೆಯಾಗುವಂತೆ ಅದರ ಮೇಲೆ ಚಿಮುಕಿಸಬಹುದಾದ ಯಾವುದೇ ಮಾಯಾ ಧೂಳಿಲ್ಲ. ಆದಾಗ್ಯೂ, ನಾವು ಸಮಸ್ಯೆಯನ್ನು ಪುನರ್ವಿಮರ್ಶಿಸಬಹುದು ಮತ್ತು ರಾಜಿ ಮಾಡಿಕೊಳ್ಳಬಹುದು.
ಈ ರಾಜಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ಮಟ್ಟದ ಕೇಂದ್ರೀಕರಣವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ನಾವು ವಿತರಿಸಲಾದ ಲಾಗ್ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸಬಹುದು ಏಕೆಂದರೆ ಇದು ವಿಶ್ವಾಸಾರ್ಹ, ಸ್ಕೇಲೆಬಲ್ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಈ ಹಂಚಿದ ಥ್ರೆಡ್‌ಗಳಲ್ಲಿ ಸೇವೆಗಳು ಸೇರಲು ಮತ್ತು ಕಾರ್ಯನಿರ್ವಹಿಸಲು ನಾವು ಈಗ ಬಯಸುತ್ತೇವೆ, ಆದರೆ ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮಾಡುವ ಸಂಕೀರ್ಣ ಕೇಂದ್ರೀಕೃತ ದೇವರ ಸೇವೆಗಳನ್ನು ತಪ್ಪಿಸಲು ನಾವು ಬಯಸುತ್ತೇವೆ. ಆದ್ದರಿಂದ, ಪ್ರತಿ ಗ್ರಾಹಕ ಸೇವೆಯಲ್ಲಿ ಸ್ಟ್ರೀಮ್ ಸಂಸ್ಕರಣೆಯನ್ನು ನಿರ್ಮಿಸುವುದು ಉತ್ತಮ ಆಯ್ಕೆಯಾಗಿದೆ. ಈ ರೀತಿಯಾಗಿ, ಸೇವೆಗಳು ವಿವಿಧ ಮೂಲಗಳಿಂದ ಡೇಟಾ ಸೆಟ್‌ಗಳನ್ನು ಸಂಯೋಜಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಮತ್ತು ಅವುಗಳಿಗೆ ಅಗತ್ಯವಿರುವ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.
ಈ ವಿಧಾನವನ್ನು ಸಾಧಿಸಲು ಒಂದು ಮಾರ್ಗವೆಂದರೆ ಸ್ಟ್ರೀಮಿಂಗ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ಬಳಸುವುದು. ಹಲವು ಆಯ್ಕೆಗಳಿವೆ, ಆದರೆ ಇಂದು ನಾವು ಕಾಫ್ಕಾವನ್ನು ನೋಡುತ್ತೇವೆ, ಏಕೆಂದರೆ ಅದರ ಸ್ಟೇಟ್‌ಫುಲ್ ಸ್ಟ್ರೀಮ್ ಪ್ರೊಸೆಸಿಂಗ್ ಬಳಕೆಯು ಪ್ರಸ್ತುತಪಡಿಸಿದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಪರಿಹರಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ವಿತರಿಸಿದ ಲಾಗಿಂಗ್ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸುವುದರಿಂದ ನಾವು ಚೆನ್ನಾಗಿ ಹೆಜ್ಜೆಯಿರುವ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸಲು ಮತ್ತು ಕೆಲಸ ಮಾಡಲು ಸಂದೇಶವನ್ನು ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ . ಈ ವಿಧಾನವು ವಿನಂತಿ-ಪ್ರತಿಕ್ರಿಯೆಯ ಕಾರ್ಯವಿಧಾನಕ್ಕಿಂತ ಉತ್ತಮವಾದ ಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ವಿಭಜನೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ಕಳುಹಿಸುವವರ ಬದಲಿಗೆ ಸ್ವೀಕರಿಸುವವರಿಗೆ ಹರಿವಿನ ನಿಯಂತ್ರಣವನ್ನು ನೀಡುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಈ ಜೀವನದಲ್ಲಿ ಪ್ರತಿಯೊಂದಕ್ಕೂ ನೀವು ಪಾವತಿಸಬೇಕಾಗುತ್ತದೆ, ಮತ್ತು ಇಲ್ಲಿ ನಿಮಗೆ ಬ್ರೋಕರ್ ಅಗತ್ಯವಿದೆ. ಆದರೆ ದೊಡ್ಡ ವ್ಯವಸ್ಥೆಗಳಿಗೆ, ಟ್ರೇಡ್-ಆಫ್ ಮೌಲ್ಯಯುತವಾಗಿದೆ (ಇದು ನಿಮ್ಮ ಸರಾಸರಿ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಇರಬಹುದು).
ಸಾಂಪ್ರದಾಯಿಕ ಸಂದೇಶ ಕಳುಹಿಸುವಿಕೆಯ ವ್ಯವಸ್ಥೆಗಿಂತ ಹೆಚ್ಚಾಗಿ ವಿತರಿಸಿದ ಲಾಗಿಂಗ್‌ಗೆ ಬ್ರೋಕರ್ ಜವಾಬ್ದಾರನಾಗಿದ್ದರೆ, ನೀವು ಹೆಚ್ಚುವರಿ ವೈಶಿಷ್ಟ್ಯಗಳ ಲಾಭವನ್ನು ಪಡೆಯಬಹುದು. ಸಾರಿಗೆಯು ರೇಖೀಯವಾಗಿ ಬಹುತೇಕ ಹಾಗೆಯೇ ವಿತರಿಸಿದ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಅಳೆಯಬಹುದು. ಡೇಟಾವನ್ನು ಲಾಗ್‌ಗಳಲ್ಲಿ ದೀರ್ಘಕಾಲ ಸಂಗ್ರಹಿಸಬಹುದು, ಆದ್ದರಿಂದ ನಾವು ಸಂದೇಶ ವಿನಿಮಯವನ್ನು ಮಾತ್ರವಲ್ಲದೆ ಮಾಹಿತಿ ಸಂಗ್ರಹಣೆಯನ್ನೂ ಸಹ ಪಡೆಯುತ್ತೇವೆ. ಬದಲಾಯಿಸಬಹುದಾದ ಹಂಚಿಕೆಯ ಸ್ಥಿತಿಯ ಭಯವಿಲ್ಲದೆ ಸ್ಕೇಲೆಬಲ್ ಸಂಗ್ರಹಣೆ.
ಸೇವಿಸುವ ಸೇವೆಗಳಿಗೆ ಡಿಕ್ಲೇರೇಟಿವ್ ಡೇಟಾಬೇಸ್ ಪರಿಕರಗಳನ್ನು ಸೇರಿಸಲು ನೀವು ನಂತರ ಸ್ಟೇಟ್‌ಫುಲ್ ಸ್ಟ್ರೀಮ್ ಪ್ರೊಸೆಸಿಂಗ್ ಅನ್ನು ಬಳಸಬಹುದು. ಇದು ಬಹಳ ಮುಖ್ಯವಾದ ವಿಚಾರ. ಎಲ್ಲಾ ಸೇವೆಗಳು ಪ್ರವೇಶಿಸಬಹುದಾದ ಹಂಚಿದ ಸ್ಟ್ರೀಮ್‌ಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿದಾಗ, ಸೇವೆಯು ಮಾಡುವ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯು ಖಾಸಗಿಯಾಗಿರುತ್ತದೆ. ಅವರು ತಮ್ಮನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಸೀಮಿತ ಸನ್ನಿವೇಶದಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಕಂಡುಕೊಳ್ಳುತ್ತಾರೆ.
ಬದಲಾಗದ ಸ್ಥಿತಿಯ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಬೇರ್ಪಡಿಸುವ ಮೂಲಕ ಡೇಟಾ ದ್ವಿಗುಣವನ್ನು ನಿವಾರಿಸಿ. ನಂತರ ಸ್ಟೇಟ್‌ಫುಲ್ ಸ್ಟ್ರೀಮ್ ಪ್ರೊಸೆಸಿಂಗ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರತಿಯೊಂದು ಸೇವೆಗೆ ಈ ಕಾರ್ಯವನ್ನು ಸೇರಿಸಿ.
ಹೀಗಾಗಿ, ನಿಮ್ಮ ಸೇವೆಯು ಆದೇಶಗಳು, ಉತ್ಪನ್ನ ಕ್ಯಾಟಲಾಗ್, ಗೋದಾಮಿನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬೇಕಾದರೆ, ಅದು ಸಂಪೂರ್ಣ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರುತ್ತದೆ: ಯಾವ ಡೇಟಾವನ್ನು ಸಂಯೋಜಿಸಬೇಕು, ಎಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕು ಮತ್ತು ಕಾಲಾನಂತರದಲ್ಲಿ ಅದು ಹೇಗೆ ಬದಲಾಗಬೇಕು ಎಂಬುದನ್ನು ನೀವು ಮಾತ್ರ ನಿರ್ಧರಿಸುತ್ತೀರಿ. ಡೇಟಾವನ್ನು ಹಂಚಿಕೊಳ್ಳಲಾಗಿದೆ ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ, ಅದರೊಂದಿಗೆ ಕೆಲಸವು ಸಂಪೂರ್ಣವಾಗಿ ವಿಕೇಂದ್ರೀಕೃತವಾಗಿದೆ. ನಿಮ್ಮ ನಿಯಮಗಳ ಪ್ರಕಾರ ಎಲ್ಲವೂ ನಡೆಯುವ ಜಗತ್ತಿನಲ್ಲಿ ಪ್ರತಿ ಸೇವೆಯೊಳಗೆ ಇದನ್ನು ಉತ್ಪಾದಿಸಲಾಗುತ್ತದೆ.
ಅದರ ಸಮಗ್ರತೆಗೆ ಧಕ್ಕೆಯಾಗದಂತೆ ಡೇಟಾವನ್ನು ಹಂಚಿಕೊಳ್ಳಿ. ಅಗತ್ಯವಿರುವ ಪ್ರತಿಯೊಂದು ಸೇವೆಯಲ್ಲಿ ಕಾರ್ಯವನ್ನು ಎನ್ಕ್ಯಾಪ್ಸುಲೇಟ್ ಮಾಡಿ, ಮೂಲವಲ್ಲ.
ಡೇಟಾವನ್ನು ಸಾಮೂಹಿಕವಾಗಿ ಸರಿಸಬೇಕಾಗಿದೆ ಎಂದು ಅದು ಸಂಭವಿಸುತ್ತದೆ. ಕೆಲವೊಮ್ಮೆ ಸೇವೆಗೆ ಆಯ್ದ ಡೇಟಾಬೇಸ್ ಎಂಜಿನ್‌ನಲ್ಲಿ ಸ್ಥಳೀಯ ಐತಿಹಾಸಿಕ ಡೇಟಾಸೆಟ್ ಅಗತ್ಯವಿರುತ್ತದೆ. ಟ್ರಿಕ್ ಏನೆಂದರೆ, ಅಗತ್ಯವಿದ್ದರೆ, ವಿತರಿಸಲಾದ ಲಾಗಿಂಗ್ ಕಾರ್ಯವಿಧಾನವನ್ನು ಪ್ರವೇಶಿಸುವ ಮೂಲಕ ಮೂಲದಿಂದ ನಕಲನ್ನು ಮರುಸ್ಥಾಪಿಸಬಹುದು ಎಂದು ನೀವು ಖಾತರಿಪಡಿಸಬಹುದು. ಕಾಫ್ಕಾದಲ್ಲಿನ ಕನೆಕ್ಟರ್‌ಗಳು ಇದರ ಉತ್ತಮ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತವೆ.
ಆದ್ದರಿಂದ, ಇಂದು ಚರ್ಚಿಸಿದ ವಿಧಾನವು ಹಲವಾರು ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿದೆ:
- ಡೇಟಾವನ್ನು ಸಾಮಾನ್ಯ ಸ್ಟ್ರೀಮ್‌ಗಳ ರೂಪದಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ, ಅದನ್ನು ಲಾಗ್‌ಗಳಲ್ಲಿ ದೀರ್ಘಕಾಲ ಸಂಗ್ರಹಿಸಬಹುದು ಮತ್ತು ಸಾಮಾನ್ಯ ಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಕಾರ್ಯವಿಧಾನವು ಪ್ರತಿಯೊಂದು ಸಂದರ್ಭದಲ್ಲೂ ಹಾರ್ಡ್‌ವೈರ್ ಆಗಿರುತ್ತದೆ, ಇದು ಸೇವೆಗಳು ಸುಲಭವಾಗಿ ಮತ್ತು ತ್ವರಿತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಈ ರೀತಿಯಾಗಿ, ಡೇಟಾದ ದ್ವಿಗುಣವನ್ನು ಸಮತೋಲನಗೊಳಿಸಬಹುದು.
- ವಿವಿಧ ಸೇವೆಗಳಿಂದ ಬರುವ ಡೇಟಾವನ್ನು ಸುಲಭವಾಗಿ ಸೆಟ್‌ಗಳಾಗಿ ಸಂಯೋಜಿಸಬಹುದು. ಇದು ಹಂಚಿದ ಡೇಟಾದೊಂದಿಗೆ ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸ್ಥಳೀಯ ಡೇಟಾಸೆಟ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಅಗತ್ಯವನ್ನು ನಿವಾರಿಸುತ್ತದೆ.
- ಸ್ಟೇಟ್‌ಫುಲ್ ಸ್ಟ್ರೀಮ್ ಸಂಸ್ಕರಣೆಯು ಡೇಟಾವನ್ನು ಮಾತ್ರ ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಸತ್ಯದ ಮೂಲವು ಸಾಮಾನ್ಯ ಲಾಗ್‌ಗಳಾಗಿ ಉಳಿದಿದೆ, ಆದ್ದರಿಂದ ಕಾಲಾನಂತರದಲ್ಲಿ ಡೇಟಾ ಭ್ರಷ್ಟಾಚಾರದ ಸಮಸ್ಯೆಯು ತುಂಬಾ ತೀವ್ರವಾಗಿರುವುದಿಲ್ಲ.
- ಅವುಗಳ ಮಧ್ಯಭಾಗದಲ್ಲಿ, ಸೇವೆಗಳು ಡೇಟಾ-ಚಾಲಿತವಾಗಿವೆ, ಅಂದರೆ ಡೇಟಾದ ಹೆಚ್ಚುತ್ತಿರುವ ಪರಿಮಾಣಗಳ ಹೊರತಾಗಿಯೂ, ಸೇವೆಗಳು ಇನ್ನೂ ವ್ಯಾಪಾರ ಘಟನೆಗಳಿಗೆ ತ್ವರಿತವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಬಹುದು.
- ಸ್ಕೇಲೆಬಿಲಿಟಿ ಸಮಸ್ಯೆಗಳು ಬ್ರೋಕರ್ ಮೇಲೆ ಬೀಳುತ್ತವೆ, ಸೇವೆಗಳಲ್ಲ. ಸ್ಕೇಲೆಬಿಲಿಟಿ ಬಗ್ಗೆ ಯೋಚಿಸುವ ಅಗತ್ಯವಿಲ್ಲದ ಕಾರಣ ಇದು ಬರವಣಿಗೆಯ ಸೇವೆಗಳ ಸಂಕೀರ್ಣತೆಯನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
- ಹೊಸ ಸೇವೆಗಳನ್ನು ಸೇರಿಸಲು ಹಳೆಯದನ್ನು ಬದಲಾಯಿಸುವ ಅಗತ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಹೊಸ ಸೇವೆಗಳನ್ನು ಸಂಪರ್ಕಿಸುವುದು ಸುಲಭವಾಗುತ್ತದೆ.
ನೀವು ನೋಡುವಂತೆ, ಇದು ಕೇವಲ REST ಗಿಂತ ಹೆಚ್ಚು. ಹಂಚಿದ ಡೇಟಾದೊಂದಿಗೆ ವಿಕೇಂದ್ರೀಕೃತ ರೀತಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಪರಿಕರಗಳ ಗುಂಪನ್ನು ನಾವು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ.
ಇಂದಿನ ಲೇಖನದಲ್ಲಿ ಎಲ್ಲಾ ಅಂಶಗಳನ್ನು ಒಳಗೊಂಡಿಲ್ಲ. ವಿನಂತಿ-ಪ್ರತಿಕ್ರಿಯೆ ಮಾದರಿ ಮತ್ತು ಈವೆಂಟ್-ಚಾಲಿತ ಮಾದರಿಯ ನಡುವೆ ಹೇಗೆ ಸಮತೋಲನಗೊಳಿಸಬೇಕು ಎಂಬುದನ್ನು ನಾವು ಇನ್ನೂ ಲೆಕ್ಕಾಚಾರ ಮಾಡಬೇಕಾಗಿದೆ. ಆದರೆ ಮುಂದಿನ ಬಾರಿ ನಾವು ಇದನ್ನು ನಿಭಾಯಿಸುತ್ತೇವೆ. ನೀವು ಚೆನ್ನಾಗಿ ತಿಳಿದುಕೊಳ್ಳಬೇಕಾದ ವಿಷಯಗಳಿವೆ, ಉದಾಹರಣೆಗೆ, ಸ್ಟೇಟ್‌ಫುಲ್ ಸ್ಟ್ರೀಮ್ ಪ್ರೊಸೆಸಿಂಗ್ ಏಕೆ ಉತ್ತಮವಾಗಿದೆ. ನಾವು ಮೂರನೇ ಲೇಖನದಲ್ಲಿ ಇದರ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ. ಮತ್ತು ನಾವು ಅವುಗಳನ್ನು ಆಶ್ರಯಿಸಿದರೆ ನಾವು ಪ್ರಯೋಜನವನ್ನು ಪಡೆದುಕೊಳ್ಳಬಹುದಾದ ಇತರ ಶಕ್ತಿಯುತ ರಚನೆಗಳಿವೆ, ಉದಾಹರಣೆಗೆ, . ವಿತರಿಸಿದ ವ್ಯಾಪಾರ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಇದು ಆಟದ ಬದಲಾವಣೆಯಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ವಹಿವಾಟಿನ ಗ್ಯಾರಂಟಿಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ ಸ್ಕೇಲೆಬಲ್ ರೂಪದಲ್ಲಿ. ಇದನ್ನು ನಾಲ್ಕನೇ ಲೇಖನದಲ್ಲಿ ಚರ್ಚಿಸಲಾಗುವುದು. ಅಂತಿಮವಾಗಿ, ನಾವು ಈ ತತ್ವಗಳ ಅನುಷ್ಠಾನದ ವಿವರಗಳ ಮೇಲೆ ಹೋಗಬೇಕಾಗುತ್ತದೆ.
ಆದರೆ ಇದೀಗ, ಇದನ್ನು ನೆನಪಿಡಿ: ವ್ಯಾಪಾರ ಸೇವೆಗಳನ್ನು ನಿರ್ಮಿಸುವಾಗ ಡೇಟಾ ದ್ವಿಗುಣವು ನಾವು ಎದುರಿಸುವ ಶಕ್ತಿಯಾಗಿದೆ. ಮತ್ತು ನಾವು ಇದನ್ನು ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳಬೇಕು. ಎಲ್ಲವನ್ನೂ ಅದರ ತಲೆಯ ಮೇಲೆ ತಿರುಗಿಸುವುದು ಮತ್ತು ಹಂಚಿದ ಡೇಟಾವನ್ನು ಪ್ರಥಮ ದರ್ಜೆಯ ವಸ್ತುಗಳಂತೆ ಪರಿಗಣಿಸುವುದು ಟ್ರಿಕ್ ಆಗಿದೆ. ಸ್ಟೇಟ್‌ಫುಲ್ ಸ್ಟ್ರೀಮ್ ಪ್ರೊಸೆಸಿಂಗ್ ಇದಕ್ಕೆ ವಿಶಿಷ್ಟವಾದ ರಾಜಿ ನೀಡುತ್ತದೆ. ಇದು ಪ್ರಗತಿಯನ್ನು ತಡೆಹಿಡಿಯುವ ಕೇಂದ್ರೀಕೃತ "ದೇವರ ಘಟಕಗಳನ್ನು" ತಪ್ಪಿಸುತ್ತದೆ. ಇದಲ್ಲದೆ, ಇದು ಡೇಟಾ ಸ್ಟ್ರೀಮಿಂಗ್ ಪೈಪ್‌ಲೈನ್‌ಗಳ ಚುರುಕುತನ, ಸ್ಕೇಲೆಬಿಲಿಟಿ ಮತ್ತು ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವವನ್ನು ಖಾತ್ರಿಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಪ್ರತಿ ಸೇವೆಗೆ ಸೇರಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ, ಯಾವುದೇ ಸೇವೆಯು ಅದರ ಡೇಟಾದೊಂದಿಗೆ ಸಂಪರ್ಕಿಸಲು ಮತ್ತು ಕೆಲಸ ಮಾಡುವ ಸಾಮಾನ್ಯ ಪ್ರಜ್ಞೆಯ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ನಾವು ಕೇಂದ್ರೀಕರಿಸಬಹುದು. ಇದು ಸೇವೆಗಳನ್ನು ಹೆಚ್ಚು ಸ್ಕೇಲೆಬಲ್, ಪರಸ್ಪರ ಬದಲಾಯಿಸಬಹುದಾದ ಮತ್ತು ಸ್ವಾಯತ್ತವಾಗಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ಅವರು ವೈಟ್‌ಬೋರ್ಡ್‌ಗಳು ಮತ್ತು ಊಹೆಯ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಕಾಣುವುದಿಲ್ಲ, ಆದರೆ ಅವರು ದಶಕಗಳವರೆಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ವಿಕಸನಗೊಳ್ಳುತ್ತಾರೆ.
ಮೂಲ: www.habr.com