ಸೂಚನೆ. ಅನುವಾದ.: ಜಾನಾ ಡೋಗನ್ ಅವರು Google ನಲ್ಲಿ ಅನುಭವಿ ಇಂಜಿನಿಯರ್ ಆಗಿದ್ದು, ಅವರು ಪ್ರಸ್ತುತ Go ನಲ್ಲಿ ಬರೆದ ಕಂಪನಿಯ ಉತ್ಪಾದನಾ ಸೇವೆಗಳ ವೀಕ್ಷಣೆಯ ಮೇಲೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾರೆ. ಇಂಗ್ಲಿಷ್-ಮಾತನಾಡುವ ಪ್ರೇಕ್ಷಕರಲ್ಲಿ ಹೆಚ್ಚಿನ ಜನಪ್ರಿಯತೆಯನ್ನು ಗಳಿಸಿದ ಈ ಲೇಖನದಲ್ಲಿ, DBMS ಗಳ (ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ವಿತರಿಸಿದ ವ್ಯವಸ್ಥೆಗಳು) ದೊಡ್ಡದಾದ / ಬೇಡಿಕೆಯಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಪರಿಗಣಿಸಲು ಉಪಯುಕ್ತವಾದ 17 ಅಂಶಗಳಲ್ಲಿ ಪ್ರಮುಖ ತಾಂತ್ರಿಕ ವಿವರಗಳನ್ನು ಅವರು ಸಂಗ್ರಹಿಸಿದ್ದಾರೆ.
ಬಹುಪಾಲು ಕಂಪ್ಯೂಟರ್ ಸಿಸ್ಟಮ್‌ಗಳು ತಮ್ಮ ಸ್ಥಿತಿಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತವೆ ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಕೆಲವು ರೀತಿಯ ಡೇಟಾ ಶೇಖರಣಾ ವ್ಯವಸ್ಥೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ. ನಾನು ದೀರ್ಘಕಾಲದವರೆಗೆ ಡೇಟಾಬೇಸ್‌ಗಳ ಬಗ್ಗೆ ಜ್ಞಾನವನ್ನು ಸಂಗ್ರಹಿಸಿದೆ, ವಿನ್ಯಾಸದ ತಪ್ಪುಗಳನ್ನು ಮಾಡುವ ಮೂಲಕ ಡೇಟಾ ನಷ್ಟ ಮತ್ತು ಸ್ಥಗಿತಗಳಿಗೆ ಕಾರಣವಾಯಿತು. ದೊಡ್ಡ ಪ್ರಮಾಣದ ಮಾಹಿತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ, ಡೇಟಾಬೇಸ್‌ಗಳು ಸಿಸ್ಟಮ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಹೃದಯಭಾಗದಲ್ಲಿರುತ್ತವೆ ಮತ್ತು ಸೂಕ್ತವಾದ ಪರಿಹಾರವನ್ನು ಆಯ್ಕೆಮಾಡುವಲ್ಲಿ ಪ್ರಮುಖ ಅಂಶವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಡೇಟಾಬೇಸ್‌ನ ಕೆಲಸಕ್ಕೆ ಹೆಚ್ಚಿನ ಗಮನವನ್ನು ನೀಡಲಾಗುತ್ತದೆ ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ, ಅಪ್ಲಿಕೇಶನ್ ಡೆವಲಪರ್‌ಗಳು ನಿರೀಕ್ಷಿಸಲು ಪ್ರಯತ್ನಿಸುವ ಸಮಸ್ಯೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಮಂಜುಗಡ್ಡೆಯ ತುದಿಯಾಗಿದೆ. ಈ ಲೇಖನಗಳ ಸರಣಿಯಲ್ಲಿ, ಈ ಕ್ಷೇತ್ರದಲ್ಲಿ ಪರಿಣತಿ ಹೊಂದಿರದ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಉಪಯುಕ್ತವಾದ ಕೆಲವು ವಿಚಾರಗಳನ್ನು ನಾನು ಹಂಚಿಕೊಳ್ಳುತ್ತೇನೆ.
- 99,999% ಸಮಯ ನೆಟ್ವರ್ಕ್ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗದಿದ್ದರೆ ನೀವು ಅದೃಷ್ಟವಂತರು.
- ACID ಎಂದರೆ ಹಲವು ವಿಭಿನ್ನ ವಿಷಯಗಳು.
- ಪ್ರತಿಯೊಂದು ಡೇಟಾಬೇಸ್ ಸ್ಥಿರತೆ ಮತ್ತು ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ತನ್ನದೇ ಆದ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಹೊಂದಿದೆ.
- ಸಾಮಾನ್ಯವಾದದನ್ನು ನಿರ್ವಹಿಸುವುದು ಕಷ್ಟಕರವಾದಾಗ ಆಶಾವಾದಿ ತಡೆಗಟ್ಟುವಿಕೆ ರಕ್ಷಣೆಗೆ ಬರುತ್ತದೆ.
- ಕೊಳಕು ಓದುವಿಕೆ ಮತ್ತು ಡೇಟಾ ನಷ್ಟದ ಜೊತೆಗೆ ಇತರ ವೈಪರೀತ್ಯಗಳಿವೆ.
- ಡೇಟಾಬೇಸ್ ಮತ್ತು ಬಳಕೆದಾರರು ಯಾವಾಗಲೂ ಕ್ರಿಯೆಯ ಕೋರ್ಸ್ ಅನ್ನು ಒಪ್ಪುವುದಿಲ್ಲ.
- ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದ ಶೇರ್ಡಿಂಗ್ ಅನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೊರಗೆ ಸರಿಸಬಹುದು.
- ಸ್ವಯಂ ಹೆಚ್ಚಳ ಅಪಾಯಕಾರಿ.
- ಹಳೆಯ ಡೇಟಾ ಉಪಯುಕ್ತವಾಗಬಹುದು ಮತ್ತು ಲಾಕ್ ಮಾಡಬೇಕಾಗಿಲ್ಲ.
- ಯಾವುದೇ ಸಮಯದ ಮೂಲಗಳಿಗೆ ವಿರೂಪಗಳು ವಿಶಿಷ್ಟವಾಗಿರುತ್ತವೆ.
- ವಿಳಂಬಕ್ಕೆ ಹಲವು ಅರ್ಥಗಳಿವೆ.
- ನಿರ್ದಿಷ್ಟ ವಹಿವಾಟಿಗೆ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅವಶ್ಯಕತೆಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬೇಕು.
- ನೆಸ್ಟೆಡ್ ವಹಿವಾಟುಗಳು ಅಪಾಯಕಾರಿಯಾಗಬಹುದು.
- ವ್ಯವಹಾರಗಳು ಅಪ್ಲಿಕೇಶನ್ ಸ್ಥಿತಿಗೆ ಸಂಬಂಧಿಸಬಾರದು.
- ಪ್ರಶ್ನೆ ಯೋಜಕರು ಡೇಟಾಬೇಸ್‌ಗಳ ಬಗ್ಗೆ ನಿಮಗೆ ಬಹಳಷ್ಟು ಹೇಳಬಹುದು.
- ಆನ್‌ಲೈನ್ ವಲಸೆ ಕಷ್ಟ, ಆದರೆ ಸಾಧ್ಯ.
- ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಗಮನಾರ್ಹ ಹೆಚ್ಚಳವು ಅನಿರೀಕ್ಷಿತತೆಯ ಹೆಚ್ಚಳಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಈ ಲೇಖನದ ಹಿಂದಿನ ಆವೃತ್ತಿಯ ಕುರಿತು ಅವರ ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ ನಾನು ಎಮ್ಯಾನುಯೆಲ್ ಒಡೆಕೆ, ರೀನ್ ಹೆನ್ರಿಚ್ಸ್ ಮತ್ತು ಇತರರಿಗೆ ಧನ್ಯವಾದ ಹೇಳಲು ಬಯಸುತ್ತೇನೆ.
99,999% ಸಮಯ ನೆಟ್ವರ್ಕ್ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗದಿದ್ದರೆ ನೀವು ಅದೃಷ್ಟವಂತರು.
ಆಧುನಿಕ ನೆಟ್ವರ್ಕ್ ತಂತ್ರಜ್ಞಾನಗಳು ಎಷ್ಟು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿವೆ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ವೈಫಲ್ಯಗಳಿಂದಾಗಿ ಸಿಸ್ಟಮ್‌ಗಳು ಎಷ್ಟು ಬಾರಿ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತವೆ ಎಂಬ ಪ್ರಶ್ನೆ ಉಳಿದಿದೆ. ಈ ವಿಷಯದ ಬಗ್ಗೆ ಮಾಹಿತಿಯು ವಿರಳವಾಗಿದೆ ಮತ್ತು ವಿಶೇಷ ನೆಟ್‌ವರ್ಕ್‌ಗಳು, ಉಪಕರಣಗಳು ಮತ್ತು ಸಿಬ್ಬಂದಿಯನ್ನು ಹೊಂದಿರುವ ದೊಡ್ಡ ಸಂಸ್ಥೆಗಳಿಂದ ಸಂಶೋಧನೆಯು ಹೆಚ್ಚಾಗಿ ಪ್ರಾಬಲ್ಯ ಹೊಂದಿದೆ.
ಸ್ಪ್ಯಾನರ್‌ಗೆ 99,999% ಲಭ್ಯತೆಯ ದರದೊಂದಿಗೆ (Google ನ ಜಾಗತಿಕವಾಗಿ ವಿತರಿಸಲಾದ ಡೇಟಾಬೇಸ್), Google ಹೇಳಿಕೊಳ್ಳುತ್ತದೆ ಸಮಸ್ಯೆಗಳು ನೆಟ್ವರ್ಕ್ಗೆ ಸಂಬಂಧಿಸಿವೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಕಂಪನಿಯು ತನ್ನ ವಿಶೇಷ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯ "ಮುಖ್ಯ ಸ್ತಂಭ" ಎಂದು ಕರೆಯುತ್ತದೆ. ಅಧ್ಯಯನ , 2014 ರಲ್ಲಿ ನಡೆಸಲಾಯಿತು, "", ಇದನ್ನು ಪೀಟರ್ ಡಾಯ್ಚ್ 1994 ರಲ್ಲಿ ರೂಪಿಸಿದರು. ನೆಟ್ವರ್ಕ್ ನಿಜವಾಗಿಯೂ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆಯೇ?
ದೈತ್ಯ ಕಂಪನಿಗಳ ಹೊರಗಿನ ಸಮಗ್ರ ಸಂಶೋಧನೆ, ವ್ಯಾಪಕ ಇಂಟರ್ನೆಟ್‌ಗಾಗಿ ನಡೆಸಲಾಗಿದೆ, ಸರಳವಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ. ತಮ್ಮ ಗ್ರಾಹಕರ ಸಮಸ್ಯೆಗಳ ಶೇಕಡಾವಾರು ನೆಟ್ವರ್ಕ್ಗೆ ಸಂಬಂಧಿಸಿದೆ ಎಂಬುದರ ಕುರಿತು ಪ್ರಮುಖ ಆಟಗಾರರಿಂದ ಸಾಕಷ್ಟು ಡೇಟಾ ಇಲ್ಲ. ದೊಡ್ಡ ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರ ನೆಟ್ವರ್ಕ್ ಸ್ಟಾಕ್‌ನಲ್ಲಿನ ಸ್ಥಗಿತಗಳ ಬಗ್ಗೆ ನಮಗೆ ಚೆನ್ನಾಗಿ ತಿಳಿದಿದೆ, ಅದು ಹಲವಾರು ಗಂಟೆಗಳವರೆಗೆ ಇಂಟರ್ನೆಟ್‌ನ ಸಂಪೂರ್ಣ ಭಾಗವನ್ನು ತೆಗೆದುಹಾಕಬಹುದು ಏಕೆಂದರೆ ಅವುಗಳು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಜನರು ಮತ್ತು ಕಂಪನಿಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಉನ್ನತ-ಪ್ರೊಫೈಲ್ ಈವೆಂಟ್‌ಗಳಾಗಿವೆ. ನೆಟ್ವರ್ಕ್ ಸ್ಥಗಿತಗಳು ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು, ಆ ಎಲ್ಲಾ ಪ್ರಕರಣಗಳು ಗಮನದಲ್ಲಿಲ್ಲದಿದ್ದರೂ ಸಹ. ಕ್ಲೌಡ್ ಸೇವೆಗಳ ಗ್ರಾಹಕರಿಗೆ ಸಮಸ್ಯೆಗಳ ಕಾರಣಗಳ ಬಗ್ಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲ. ವಿಫಲವಾದರೆ, ಸೇವಾ ಪೂರೈಕೆದಾರರ ಬದಿಯಲ್ಲಿರುವ ನೆಟ್ವರ್ಕ್ ದೋಷಕ್ಕೆ ಕಾರಣವೆಂದು ಹೇಳುವುದು ಅಸಾಧ್ಯ. ಅವರಿಗೆ, ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸೇವೆಗಳು ಕಪ್ಪು ಪೆಟ್ಟಿಗೆಗಳಾಗಿವೆ. ದೊಡ್ಡ ಸೇವಾ ಪೂರೈಕೆದಾರರಾಗದೆ ಪರಿಣಾಮವನ್ನು ನಿರ್ಣಯಿಸುವುದು ಅಸಾಧ್ಯ.
ದೊಡ್ಡ ಆಟಗಾರರು ತಮ್ಮ ಸಿಸ್ಟಂಗಳ ಬಗ್ಗೆ ಏನು ವರದಿ ಮಾಡುತ್ತಾರೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿದರೆ, ನೆಟ್ವರ್ಕ್ ತೊಂದರೆಗಳು ಕೇವಲ ಒಂದು ಸಣ್ಣ ಶೇಕಡಾವಾರು ಸಂಭಾವ್ಯ ಅಲಭ್ಯತೆಯ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗಿದ್ದರೆ ನೀವು ಅದೃಷ್ಟವಂತರು ಎಂದು ಹೇಳುವುದು ಸುರಕ್ಷಿತವಾಗಿದೆ. ಹಾರ್ಡ್‌ವೇರ್ ವೈಫಲ್ಯಗಳು, ಟೋಪೋಲಜಿ ಬದಲಾವಣೆಗಳು, ಆಡಳಿತಾತ್ಮಕ ಕಾನ್ಫಿಗರೇಶನ್ ಬದಲಾವಣೆಗಳು ಮತ್ತು ವಿದ್ಯುತ್ ಕಡಿತದಂತಹ ಪ್ರಾಪಂಚಿಕ ವಿಷಯಗಳಿಂದ ನೆಟ್ವರ್ಕ್ ಸಂವಹನಗಳು ಇನ್ನೂ ಬಳಲುತ್ತಿವೆ. ಇತ್ತೀಚೆಗೆ, ಸಂಭವನೀಯ ಸಮಸ್ಯೆಗಳ ಪಟ್ಟಿಯನ್ನು ಸೇರಿಸಲಾಗಿದೆ ಎಂದು ತಿಳಿದು ನನಗೆ ಆಶ್ಚರ್ಯವಾಯಿತು (ಹೌದು, ನೀವು ಸರಿಯಾಗಿ ಕೇಳಿದ್ದೀರಿ).
ACID ಎಂದರೆ ಬಹಳಷ್ಟು ವಿಭಿನ್ನ ವಿಷಯಗಳು
ACID ಎಂಬ ಸಂಕ್ಷಿಪ್ತ ರೂಪವು ಪರಮಾಣು, ಸ್ಥಿರತೆ, ಪ್ರತ್ಯೇಕತೆ, ವಿಶ್ವಾಸಾರ್ಹತೆ. ವಹಿವಾಟಿನ ಈ ಗುಣಲಕ್ಷಣಗಳು ವೈಫಲ್ಯಗಳು, ದೋಷಗಳು, ಹಾರ್ಡ್‌ವೇರ್ ವೈಫಲ್ಯಗಳು ಇತ್ಯಾದಿಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಅವುಗಳ ಸಿಂಧುತ್ವವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಉದ್ದೇಶಿಸಲಾಗಿದೆ. ACID ಅಥವಾ ಅಂತಹುದೇ ಸ್ಕೀಮ್‌ಗಳಿಲ್ಲದೆ, ಅಪ್ಲಿಕೇಶನ್ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅವರು ಜವಾಬ್ದಾರರು ಮತ್ತು ಡೇಟಾಬೇಸ್ ಯಾವುದಕ್ಕೆ ಜವಾಬ್ದಾರರು ಎಂಬುದರ ನಡುವೆ ವ್ಯತ್ಯಾಸವನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ. ಹೆಚ್ಚಿನ ಸಂಬಂಧಿತ ವಹಿವಾಟಿನ ಡೇಟಾಬೇಸ್‌ಗಳು ACID ಕಂಪ್ಲೈಂಟ್ ಆಗಲು ಪ್ರಯತ್ನಿಸುತ್ತವೆ, ಆದರೆ NoSQL ನಂತಹ ಹೊಸ ವಿಧಾನಗಳು ACID ವಹಿವಾಟುಗಳಿಲ್ಲದೆಯೇ ಅನೇಕ ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಕಾರಣವಾಗಿವೆ ಏಕೆಂದರೆ ಅವುಗಳು ಕಾರ್ಯಗತಗೊಳಿಸಲು ದುಬಾರಿಯಾಗಿದೆ.
ನಾನು ಮೊದಲು ಉದ್ಯಮಕ್ಕೆ ಪ್ರವೇಶಿಸಿದಾಗ, ನಮ್ಮ ತಾಂತ್ರಿಕ ನಾಯಕ ACID ಪರಿಕಲ್ಪನೆಯು ಎಷ್ಟು ಪ್ರಸ್ತುತವಾಗಿದೆ ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡಿದರು. ನ್ಯಾಯೋಚಿತವಾಗಿ, ACID ಅನ್ನು ಕಟ್ಟುನಿಟ್ಟಾದ ಅನುಷ್ಠಾನದ ಮಾನದಂಡಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಸ್ಥೂಲ ವಿವರಣೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಇಂದು ನಾನು ಇದನ್ನು ಹೆಚ್ಚಾಗಿ ಉಪಯುಕ್ತವೆಂದು ಭಾವಿಸುತ್ತೇನೆ ಏಕೆಂದರೆ ಇದು ನಿರ್ದಿಷ್ಟ ವರ್ಗದ ಸಮಸ್ಯೆಗಳನ್ನು ಹುಟ್ಟುಹಾಕುತ್ತದೆ (ಮತ್ತು ಸಂಭವನೀಯ ಪರಿಹಾರಗಳ ಶ್ರೇಣಿಯನ್ನು ಸೂಚಿಸುತ್ತದೆ).
ಪ್ರತಿ DBMS ACID ಕಂಪ್ಲೈಂಟ್ ಅಲ್ಲ; ಅದೇ ಸಮಯದಲ್ಲಿ, ACID ಅನ್ನು ಬೆಂಬಲಿಸುವ ಡೇಟಾಬೇಸ್ ಅಳವಡಿಕೆಗಳು ಅವಶ್ಯಕತೆಗಳ ಗುಂಪನ್ನು ವಿಭಿನ್ನವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತವೆ. ACID ಅಳವಡಿಕೆಗಳು ತೇಪೆಯಾಗಿರುವುದಕ್ಕೆ ಒಂದು ಕಾರಣವೆಂದರೆ ACID ಅವಶ್ಯಕತೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಮಾಡಬೇಕಾದ ಅನೇಕ ವ್ಯಾಪಾರ-ವಹಿವಾಟುಗಳು. ರಚನೆಕಾರರು ತಮ್ಮ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ACID-ಕಂಪ್ಲೈಂಟ್ ಆಗಿ ಪ್ರಸ್ತುತಪಡಿಸಬಹುದು, ಆದರೆ ಅಂಚಿನ ಪ್ರಕರಣಗಳ ವ್ಯಾಖ್ಯಾನವು ನಾಟಕೀಯವಾಗಿ ಬದಲಾಗಬಹುದು, ಹಾಗೆಯೇ "ಅಸಂಭವ" ಈವೆಂಟ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಕಾರ್ಯವಿಧಾನ. ಕನಿಷ್ಠ, ಅಭಿವರ್ಧಕರು ತಮ್ಮ ವಿಶೇಷ ನಡವಳಿಕೆ ಮತ್ತು ವಿನ್ಯಾಸ ವ್ಯಾಪಾರ-ವಹಿವಾಟುಗಳ ಸರಿಯಾದ ತಿಳುವಳಿಕೆಯನ್ನು ಪಡೆಯಲು ಬೇಸ್ ಅಳವಡಿಕೆಗಳ ಜಟಿಲತೆಗಳ ಉನ್ನತ ಮಟ್ಟದ ತಿಳುವಳಿಕೆಯನ್ನು ಪಡೆಯಬಹುದು.
MongoDB ACID ಅವಶ್ಯಕತೆಗಳನ್ನು ಅನುಸರಿಸುತ್ತದೆಯೇ ಎಂಬ ಚರ್ಚೆಯು ಆವೃತ್ತಿ 4 ರ ಬಿಡುಗಡೆಯ ನಂತರವೂ ಮುಂದುವರಿಯುತ್ತದೆ. ಮೊಂಗೋಡಿಬಿ ದೀರ್ಘಕಾಲದಿಂದ ಬೆಂಬಲಿತವಾಗಿಲ್ಲ , ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಡೇಟಾವು ಪ್ರತಿ 60 ಸೆಕೆಂಡಿಗೆ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಾರಿ ಡಿಸ್ಕ್ಗೆ ಬದ್ಧವಾಗಿದೆ. ಕೆಳಗಿನ ಸನ್ನಿವೇಶವನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ: ಅಪ್ಲಿಕೇಶನ್ ಎರಡು ಬರಹಗಳನ್ನು ಪೋಸ್ಟ್ ಮಾಡುತ್ತದೆ (w1 ಮತ್ತು w2). MongoDB ಯಶಸ್ವಿಯಾಗಿ w1 ಅನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಆದರೆ ಹಾರ್ಡ್‌ವೇರ್ ವೈಫಲ್ಯದಿಂದಾಗಿ w2 ಕಳೆದುಹೋಗಿದೆ.
ಸನ್ನಿವೇಶವನ್ನು ವಿವರಿಸುವ ರೇಖಾಚಿತ್ರ. MongoDB ಡಿಸ್ಕ್ಗೆ ಡೇಟಾವನ್ನು ಬರೆಯುವ ಮೊದಲು ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ
ಡಿಸ್ಕ್ಗೆ ಒಪ್ಪಿಸುವುದು ದುಬಾರಿ ಪ್ರಕ್ರಿಯೆ. ಆಗಾಗ್ಗೆ ಬದ್ಧತೆಗಳನ್ನು ತಪ್ಪಿಸುವ ಮೂಲಕ, ಡೆವಲಪರ್‌ಗಳು ವಿಶ್ವಾಸಾರ್ಹತೆಯ ವೆಚ್ಚದಲ್ಲಿ ರೆಕಾರ್ಡಿಂಗ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತಾರೆ. MongoDB ಪ್ರಸ್ತುತ ಲಾಗಿಂಗ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ, ಆದರೆ ಡೀಫಾಲ್ಟ್ ಆಗಿ ಪ್ರತಿ 100ms ಗೆ ಲಾಗ್‌ಗಳನ್ನು ಸೆರೆಹಿಡಿಯುವುದರಿಂದ ಕೊಳಕು ಬರಹಗಳು ಇನ್ನೂ ಡೇಟಾ ಸಮಗ್ರತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬಹುದು. ಅಂದರೆ, ಲಾಗ್‌ಗಳಿಗೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸಲಾದ ಬದಲಾವಣೆಗಳಿಗೆ ಇದೇ ರೀತಿಯ ಸನ್ನಿವೇಶವು ಇನ್ನೂ ಸಾಧ್ಯ, ಆದರೂ ಅಪಾಯವು ತುಂಬಾ ಕಡಿಮೆಯಾಗಿದೆ.
ಪ್ರತಿಯೊಂದು ಡೇಟಾಬೇಸ್ ತನ್ನದೇ ಆದ ಸ್ಥಿರತೆ ಮತ್ತು ಪ್ರತ್ಯೇಕತೆಯ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಹೊಂದಿದೆ
ACID ಅಗತ್ಯತೆಗಳಲ್ಲಿ, ಸ್ಥಿರತೆ ಮತ್ತು ಪ್ರತ್ಯೇಕತೆಯು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ವಿಭಿನ್ನ ಅನುಷ್ಠಾನಗಳನ್ನು ಹೊಂದಿದೆ ಏಕೆಂದರೆ ವ್ಯಾಪಾರ-ವಹಿವಾಟುಗಳ ವ್ಯಾಪ್ತಿಯು ವಿಸ್ತಾರವಾಗಿದೆ. ಸ್ಥಿರತೆ ಮತ್ತು ಪ್ರತ್ಯೇಕತೆಯು ಸಾಕಷ್ಟು ದುಬಾರಿ ಕಾರ್ಯಗಳಾಗಿವೆ ಎಂದು ಹೇಳಬೇಕು. ಅವರಿಗೆ ಸಮನ್ವಯ ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಡೇಟಾ ಸ್ಥಿರತೆಗಾಗಿ ಸ್ಪರ್ಧೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಬಹು ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ (ವಿಶೇಷವಾಗಿ ಅವು ವಿವಿಧ ಭೌಗೋಳಿಕ ಪ್ರದೇಶಗಳಲ್ಲಿ ನೆಲೆಗೊಂಡಿದ್ದರೆ) ಅಡ್ಡಲಾಗಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಅಳೆಯಲು ಅಗತ್ಯವಾದಾಗ ಸಮಸ್ಯೆಯ ಸಂಕೀರ್ಣತೆಯು ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ. ಉನ್ನತ ಮಟ್ಟದ ಸ್ಥಿರತೆಯನ್ನು ಸಾಧಿಸುವುದು ತುಂಬಾ ಕಷ್ಟ, ಏಕೆಂದರೆ ಇದು ಲಭ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ವಿಭಾಗವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಈ ವಿದ್ಯಮಾನದ ಹೆಚ್ಚು ಸಾಮಾನ್ಯ ವಿವರಣೆಗಾಗಿ, ನಾನು ನಿಮಗೆ ಉಲ್ಲೇಖಿಸಲು ಸಲಹೆ ನೀಡುತ್ತೇನೆ . ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಸಣ್ಣ ಪ್ರಮಾಣದ ಅಸಮಂಜಸತೆಯನ್ನು ನಿಭಾಯಿಸಬಲ್ಲವು ಮತ್ತು ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ಅದನ್ನು ನಿರ್ವಹಿಸಲು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಹೆಚ್ಚು ಅವಲಂಬಿಸದೆ ಅಸಂಗತತೆಯನ್ನು ನಿರ್ವಹಿಸಲು ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಹೆಚ್ಚುವರಿ ತರ್ಕವನ್ನು ಅಳವಡಿಸಲು ಸಾಕಷ್ಟು ಸಮಸ್ಯೆಯ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು ಎಂಬುದು ಗಮನಿಸಬೇಕಾದ ಸಂಗತಿ.
DBMSಗಳು ಸಾಮಾನ್ಯವಾಗಿ ವಿವಿಧ ಹಂತದ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಒದಗಿಸುತ್ತವೆ. ಅಪ್ಲಿಕೇಶನ್ ಡೆವಲಪರ್‌ಗಳು ತಮ್ಮ ಆದ್ಯತೆಗಳ ಆಧಾರದ ಮೇಲೆ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾದ ಒಂದನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು. ಕಡಿಮೆ ಪ್ರತ್ಯೇಕತೆಯು ವೇಗವನ್ನು ಹೆಚ್ಚಿಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಆದರೆ ಡೇಟಾ ಓಟದ ಅಪಾಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಹೆಚ್ಚಿನ ನಿರೋಧನವು ಈ ಸಂಭವನೀಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಆದರೆ ಕೆಲಸವನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಸ್ಪರ್ಧೆಗೆ ಕಾರಣವಾಗಬಹುದು, ಇದು ವೈಫಲ್ಯಗಳು ಪ್ರಾರಂಭವಾಗುವ ತಳದಲ್ಲಿ ಅಂತಹ ಬ್ರೇಕ್ಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಏಕಕಾಲಿಕ ಮಾದರಿಗಳು ಮತ್ತು ಅವುಗಳ ನಡುವಿನ ಸಂಬಂಧಗಳ ವಿಮರ್ಶೆ
SQL ಮಾನದಂಡವು ಕೇವಲ ನಾಲ್ಕು ಪ್ರತ್ಯೇಕತೆಯ ಹಂತಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಆದಾಗ್ಯೂ ಸಿದ್ಧಾಂತ ಮತ್ತು ಅಭ್ಯಾಸದಲ್ಲಿ ಇನ್ನೂ ಹಲವು ಇವೆ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಏಕಕಾಲಿಕ ಮಾದರಿಗಳ ಅತ್ಯುತ್ತಮ ಅವಲೋಕನವನ್ನು ನೀಡುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, Google Spanner ಗಡಿಯಾರದ ಸಿಂಕ್ರೊನೈಸೇಶನ್‌ನೊಂದಿಗೆ ಬಾಹ್ಯ ಧಾರಾವಾಹಿಯನ್ನು ಖಾತರಿಪಡಿಸುತ್ತದೆ ಮತ್ತು ಇದು ಕಟ್ಟುನಿಟ್ಟಾದ ಪ್ರತ್ಯೇಕತೆಯ ಪದರವಾಗಿದ್ದರೂ, ಇದನ್ನು ಪ್ರಮಾಣಿತ ಪ್ರತ್ಯೇಕ ಪದರಗಳಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿಲ್ಲ.
SQL ಮಾನದಂಡವು ಈ ಕೆಳಗಿನ ಪ್ರತ್ಯೇಕತೆಯ ಮಟ್ಟವನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತದೆ:
- ಧಾರಾವಾಹಿ (ಅತ್ಯಂತ ಕಟ್ಟುನಿಟ್ಟಾದ ಮತ್ತು ದುಬಾರಿ): ಕೆಲವು ಅನುಕ್ರಮ ವಹಿವಾಟು ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯಂತೆಯೇ ಸೀರಿಯಲ್ಲೈಸಬಲ್ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಅದೇ ಪರಿಣಾಮವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಅನುಕ್ರಮ ಮರಣದಂಡನೆ ಎಂದರೆ ಪ್ರತಿ ನಂತರದ ವಹಿವಾಟು ಹಿಂದಿನದು ಪೂರ್ಣಗೊಂಡ ನಂತರವೇ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಮಟ್ಟವನ್ನು ಗಮನಿಸಬೇಕು ಧಾರಾವಾಹಿ ಸಾಮಾನ್ಯವಾಗಿ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಐಸೋಲೇಶನ್ ಎಂದು ಕರೆಯಲ್ಪಡುವಂತೆ (ಉದಾಹರಣೆಗೆ, ಒರಾಕಲ್‌ನಲ್ಲಿ) ವ್ಯಾಖ್ಯಾನದಲ್ಲಿನ ವ್ಯತ್ಯಾಸಗಳಿಂದಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ, ಆದಾಗ್ಯೂ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಪ್ರತ್ಯೇಕತೆಯು ಸ್ವತಃ SQL ಮಾನದಂಡದಲ್ಲಿ ಪ್ರತಿನಿಧಿಸುವುದಿಲ್ಲ.
- ಪುನರಾವರ್ತಿತ ಓದುವಿಕೆ: ಪ್ರಸ್ತುತ ವಹಿವಾಟಿನಲ್ಲಿ ಬದ್ಧತೆಯಿಲ್ಲದ ದಾಖಲೆಗಳು ಪ್ರಸ್ತುತ ವಹಿವಾಟಿಗೆ ಲಭ್ಯವಿರುತ್ತವೆ, ಆದರೆ ಇತರ ವಹಿವಾಟುಗಳಿಂದ ಮಾಡಿದ ಬದಲಾವಣೆಗಳು (ಉದಾಹರಣೆಗೆ ಹೊಸ ಸಾಲುಗಳು) .
- ಬದ್ಧತೆಯನ್ನು ಓದಿ: ವಹಿವಾಟುಗಳಿಗೆ ಬದ್ಧತೆಯಿಲ್ಲದ ಡೇಟಾ ಲಭ್ಯವಿಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ವಹಿವಾಟುಗಳು ಬದ್ಧವಾದ ಡೇಟಾವನ್ನು ಮಾತ್ರ ನೋಡಬಹುದು ಮತ್ತು ಫ್ಯಾಂಟಮ್ ಓದುವಿಕೆಗಳು ಸಂಭವಿಸಬಹುದು. ವಹಿವಾಟು ಹೊಸ ಸಾಲುಗಳನ್ನು ಸೇರಿಸಿದರೆ ಮತ್ತು ಒಪ್ಪಿಸಿದರೆ, ಪ್ರಸ್ತುತ ವಹಿವಾಟು ಪ್ರಶ್ನಿಸಿದಾಗ ಅವುಗಳನ್ನು ನೋಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
- ಬದ್ಧತೆಯಿಲ್ಲದೆ ಓದಿ (ಕನಿಷ್ಠ ಕಟ್ಟುನಿಟ್ಟಾದ ಮತ್ತು ದುಬಾರಿ ಮಟ್ಟ): ಡರ್ಟಿ ರೀಡ್‌ಗಳನ್ನು ಅನುಮತಿಸಲಾಗಿದೆ, ವಹಿವಾಟುಗಳು ಇತರ ವಹಿವಾಟುಗಳಿಂದ ಮಾಡಿದ ಬದ್ಧತೆಯಿಲ್ಲದ ಬದಲಾವಣೆಗಳನ್ನು ನೋಡಬಹುದು. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಈ ಮಟ್ಟವು ಪ್ರಶ್ನೆಗಳಂತಹ ಸ್ಥೂಲ ಅಂದಾಜುಗಳಿಗೆ ಉಪಯುಕ್ತವಾಗಬಹುದು
COUNT(*)ಮೇಜಿನ ಮೇಲೆ.
ಮಟ್ಟದ ಧಾರಾವಾಹಿ ಡೇಟಾ ರೇಸ್‌ಗಳ ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಆದರೆ ಇದು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಅತ್ಯಂತ ದುಬಾರಿಯಾಗಿದೆ ಮತ್ತು ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಹೆಚ್ಚಿನ ಸ್ಪರ್ಧಾತ್ಮಕ ಹೊರೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಇತರ ಪ್ರತ್ಯೇಕತೆಯ ಹಂತಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸುಲಭವಾಗಿದೆ, ಆದರೆ ಡೇಟಾ ರೇಸ್‌ಗಳ ಸಾಧ್ಯತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಕೆಲವು DBMS ಗಳು ನಿಮಗೆ ಕಸ್ಟಮ್ ಪ್ರತ್ಯೇಕತೆಯ ಮಟ್ಟವನ್ನು ಹೊಂದಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತವೆ, ಇತರವುಗಳು ಬಲವಾದ ಆದ್ಯತೆಗಳನ್ನು ಹೊಂದಿವೆ ಮತ್ತು ಎಲ್ಲಾ ಹಂತಗಳನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ.
ಪ್ರತ್ಯೇಕತೆಯ ಮಟ್ಟಗಳಿಗೆ ಬೆಂಬಲವನ್ನು ನೀಡಲಾದ DBMS ನಲ್ಲಿ ಹೆಚ್ಚಾಗಿ ಪ್ರಚಾರ ಮಾಡಲಾಗುತ್ತದೆ, ಆದರೆ ಅದರ ನಡವಳಿಕೆಯ ಬಗ್ಗೆ ಎಚ್ಚರಿಕೆಯಿಂದ ಅಧ್ಯಯನ ಮಾಡಿದರೆ ಮಾತ್ರ ನಿಜವಾಗಿ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಬಹಿರಂಗಪಡಿಸಬಹುದು.
ವಿಭಿನ್ನ DBMS ಗಳಿಗಾಗಿ ವಿಭಿನ್ನ ಪ್ರತ್ಯೇಕ ಹಂತಗಳಲ್ಲಿ ಏಕಕಾಲಿಕ ವೈಪರೀತ್ಯಗಳ ವಿಮರ್ಶೆ
ಮಾರ್ಟಿನ್ ಕ್ಲೆಪ್ಮನ್ ಅವರ ಯೋಜನೆಯಲ್ಲಿ ವಿಭಿನ್ನ ಪ್ರತ್ಯೇಕತೆಯ ಹಂತಗಳನ್ನು ಹೋಲಿಸುತ್ತದೆ, ಏಕಕಾಲಿಕ ವೈಪರೀತ್ಯಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ ನಿರ್ದಿಷ್ಟ ಪ್ರತ್ಯೇಕತೆಯ ಮಟ್ಟಕ್ಕೆ ಅಂಟಿಕೊಳ್ಳುತ್ತದೆಯೇ. ಕ್ಲೆಪ್‌ಮನ್‌ರ ಸಂಶೋಧನೆಯು ಡೇಟಾಬೇಸ್ ಡೆವಲಪರ್‌ಗಳು ಪ್ರತ್ಯೇಕತೆಯ ಮಟ್ಟವನ್ನು ಹೇಗೆ ವಿಭಿನ್ನವಾಗಿ ಯೋಚಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.
ಸಾಮಾನ್ಯವಾದದನ್ನು ನಿರ್ವಹಿಸುವುದು ಕಷ್ಟಕರವಾದಾಗ ಆಶಾವಾದಿ ತಡೆಗಟ್ಟುವಿಕೆ ರಕ್ಷಣೆಗೆ ಬರುತ್ತದೆ.
ನಿರ್ಬಂಧಿಸುವಿಕೆಯು ತುಂಬಾ ದುಬಾರಿಯಾಗಬಹುದು, ಏಕೆಂದರೆ ಇದು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸ್ಪರ್ಧೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ, ಆದರೆ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗಳು ಡೇಟಾಬೇಸ್‌ಗೆ ನಿರಂತರವಾಗಿ ಸಂಪರ್ಕಗೊಳ್ಳುವ ಅಗತ್ಯವಿರುತ್ತದೆ. ನೆಟ್ವರ್ಕ್ ವಿಭಜನೆಯು ವಿಶೇಷವಾದ ಲಾಕ್ ಮಾಡುವ ಸಂದರ್ಭಗಳನ್ನು ಉಲ್ಬಣಗೊಳಿಸಬಹುದು ಮತ್ತು ಗುರುತಿಸಲು ಮತ್ತು ಪರಿಹರಿಸಲು ಕಷ್ಟಕರವಾದ ಡೆಡ್‌ಲಾಕ್‌ಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು. ವಿಶೇಷವಾದ ಲಾಕಿಂಗ್ ಸೂಕ್ತವಲ್ಲದ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಆಶಾವಾದಿ ಲಾಕಿಂಗ್ ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಓದುವಾಗ, ಅದರ ಆವೃತ್ತಿ, ಚೆಕ್ಸಮ್ ಅಥವಾ ಕೊನೆಯ ಮಾರ್ಪಾಡಿನ ಸಮಯವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವ ವಿಧಾನವಾಗಿದೆ. ನಮೂದನ್ನು ಬದಲಾಯಿಸುವ ಮೊದಲು ಯಾವುದೇ ಪರಮಾಣು ಆವೃತ್ತಿ ಬದಲಾವಣೆ ಇಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ:
UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1
ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಟೇಬಲ್ ಅನ್ನು ನವೀಕರಿಸಲಾಗುತ್ತಿದೆ products ಈ ಸಾಲಿಗೆ ಈ ಹಿಂದೆ ಮತ್ತೊಂದು ಕಾರ್ಯಾಚರಣೆಯು ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದರೆ ಅದನ್ನು ಕೈಗೊಳ್ಳಲಾಗುವುದಿಲ್ಲ. ಈ ಸಾಲಿನಲ್ಲಿ ಯಾವುದೇ ಇತರ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ವಹಿಸದಿದ್ದರೆ, ಒಂದು ಸಾಲಿನ ಬದಲಾವಣೆಯು ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ನವೀಕರಣವು ಯಶಸ್ವಿಯಾಗಿದೆ ಎಂದು ನಾವು ಹೇಳಬಹುದು.
ಕೊಳಕು ಓದುವಿಕೆ ಮತ್ತು ಡೇಟಾ ನಷ್ಟದ ಜೊತೆಗೆ ಇತರ ವೈಪರೀತ್ಯಗಳಿವೆ
ಡೇಟಾ ಸ್ಥಿರತೆಗೆ ಬಂದಾಗ, ಕೊಳಕು ಓದುವಿಕೆ ಮತ್ತು ಡೇಟಾ ನಷ್ಟಕ್ಕೆ ಕಾರಣವಾಗುವ ರೇಸ್ ಪರಿಸ್ಥಿತಿಗಳ ಸಂಭಾವ್ಯತೆಯ ಮೇಲೆ ಗಮನ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಡೇಟಾ ವೈಪರೀತ್ಯಗಳು ಅಲ್ಲಿ ನಿಲ್ಲುವುದಿಲ್ಲ.
ಅಂತಹ ವೈಪರೀತ್ಯಗಳ ಒಂದು ಉದಾಹರಣೆಯೆಂದರೆ ರೆಕಾರ್ಡಿಂಗ್ ಅಸ್ಪಷ್ಟತೆ (ಓರೆಗಳನ್ನು ಬರೆಯಿರಿ). ಅಸ್ಪಷ್ಟತೆಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಕಷ್ಟ ಏಕೆಂದರೆ ಅವುಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಸಕ್ರಿಯವಾಗಿ ಹುಡುಕಲಾಗುವುದಿಲ್ಲ. ಅವು ಕೊಳಕು ಓದುವಿಕೆ ಅಥವಾ ಡೇಟಾ ನಷ್ಟದಿಂದಾಗಿ ಅಲ್ಲ, ಆದರೆ ಡೇಟಾದ ಮೇಲೆ ಇರಿಸಲಾದ ತಾರ್ಕಿಕ ನಿರ್ಬಂಧಗಳ ಉಲ್ಲಂಘನೆಯಿಂದಾಗಿ.
ಉದಾಹರಣೆಗೆ, ಎಲ್ಲಾ ಸಮಯದಲ್ಲೂ ಒಬ್ಬ ಆಪರೇಟರ್ ಆನ್-ಕಾಲ್ ಆಗಿರುವ ಅಗತ್ಯವಿರುವ ಮೇಲ್ವಿಚಾರಣಾ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಾವು ಪರಿಗಣಿಸೋಣ:
BEGIN tx1; BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0 SELECT COUNT(*)
FROM operators
WHERE oncall = TRUE;
0
UPDATE operators UPDATE operators
SET oncall = TRUE SET oncall = TRUE
WHERE userId = 4; WHERE userId = 2;
COMMIT tx1; COMMIT tx2;ಮೇಲಿನ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಎರಡೂ ವಹಿವಾಟುಗಳು ಯಶಸ್ವಿಯಾಗಿ ಬದ್ಧವಾಗಿದ್ದರೆ ದಾಖಲೆಯ ಭ್ರಷ್ಟಾಚಾರ ಸಂಭವಿಸುತ್ತದೆ. ಯಾವುದೇ ಕೊಳಕು ಓದುವಿಕೆಗಳು ಅಥವಾ ಡೇಟಾ ನಷ್ಟವಾಗದಿದ್ದರೂ, ಡೇಟಾದ ಸಮಗ್ರತೆಯು ರಾಜಿಮಾಡಿಕೊಂಡಿದೆ: ಈಗ ಇಬ್ಬರು ಜನರನ್ನು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಆನ್-ಕಾಲ್ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.
ಸರಣಿಯ ಪ್ರತ್ಯೇಕತೆ, ಸ್ಕೀಮಾ ವಿನ್ಯಾಸ ಅಥವಾ ಡೇಟಾಬೇಸ್ ನಿರ್ಬಂಧಗಳು ಬರವಣಿಗೆಯ ಭ್ರಷ್ಟಾಚಾರವನ್ನು ತೊಡೆದುಹಾಕಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಉತ್ಪಾದನೆಯಲ್ಲಿ ಅವುಗಳನ್ನು ತಪ್ಪಿಸಲು ಡೆವಲಪರ್‌ಗಳು ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ ಅಂತಹ ವೈಪರೀತ್ಯಗಳನ್ನು ಗುರುತಿಸಲು ಶಕ್ತರಾಗಿರಬೇಕು. ಅದೇ ಸಮಯದಲ್ಲಿ, ರೆಕಾರ್ಡಿಂಗ್ ಅಸ್ಪಷ್ಟತೆಗಳನ್ನು ಕೋಡ್ ಬೇಸ್ನಲ್ಲಿ ನೋಡಲು ತುಂಬಾ ಕಷ್ಟ. ವಿಶೇಷವಾಗಿ ದೊಡ್ಡ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ, ವಿಭಿನ್ನ ಅಭಿವೃದ್ಧಿ ತಂಡಗಳು ಒಂದೇ ಕೋಷ್ಟಕಗಳ ಆಧಾರದ ಮೇಲೆ ಕಾರ್ಯಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಜವಾಬ್ದಾರರಾಗಿರುವಾಗ ಮತ್ತು ಡೇಟಾ ಪ್ರವೇಶದ ನಿಶ್ಚಿತಗಳನ್ನು ಒಪ್ಪುವುದಿಲ್ಲ.
ಡೇಟಾಬೇಸ್ ಮತ್ತು ಬಳಕೆದಾರರು ಯಾವಾಗಲೂ ಏನು ಮಾಡಬೇಕೆಂದು ಒಪ್ಪಿಕೊಳ್ಳುವುದಿಲ್ಲ
ಡೇಟಾಬೇಸ್‌ಗಳ ಪ್ರಮುಖ ಲಕ್ಷಣವೆಂದರೆ ಎಕ್ಸಿಕ್ಯೂಷನ್ ಆರ್ಡರ್‌ನ ಗ್ಯಾರಂಟಿ, ಆದರೆ ಈ ಆದೇಶವು ಸಾಫ್ಟ್‌ವೇರ್ ಡೆವಲಪರ್‌ಗೆ ಪಾರದರ್ಶಕವಾಗಿರುವುದಿಲ್ಲ. ಡೇಟಾಬೇಸ್‌ಗಳು ಅವರು ಸ್ವೀಕರಿಸಿದ ಕ್ರಮದಲ್ಲಿ ವಹಿವಾಟುಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತವೆ, ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ಉದ್ದೇಶಿಸಿರುವ ಕ್ರಮದಲ್ಲಿ ಅಲ್ಲ. ವಹಿವಾಟಿನ ಕ್ರಮವನ್ನು ಊಹಿಸಲು ಕಷ್ಟವಾಗುತ್ತದೆ, ವಿಶೇಷವಾಗಿ ಹೆಚ್ಚು ಲೋಡ್ ಮಾಡಲಾದ ಸಮಾನಾಂತರ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ.
ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ, ವಿಶೇಷವಾಗಿ ನಿರ್ಬಂಧಿಸದ ಗ್ರಂಥಾಲಯಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ, ಕಳಪೆ ಶೈಲಿ ಮತ್ತು ಕಡಿಮೆ ಓದುವಿಕೆ ವಹಿವಾಟುಗಳನ್ನು ಅನುಕ್ರಮವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ ಎಂದು ಬಳಕೆದಾರರು ನಂಬುವಂತೆ ಮಾಡುತ್ತದೆ, ವಾಸ್ತವವಾಗಿ ಅವರು ಯಾವುದೇ ಕ್ರಮದಲ್ಲಿ ಡೇಟಾಬೇಸ್‌ಗೆ ಬರಬಹುದು.
ಮೊದಲ ನೋಟದಲ್ಲಿ, ಕೆಳಗಿನ ಪ್ರೋಗ್ರಾಂನಲ್ಲಿ, T1 ಮತ್ತು T2 ಅನ್ನು ಅನುಕ್ರಮವಾಗಿ ಕರೆಯಲಾಗುತ್ತದೆ, ಆದರೆ ಈ ಕಾರ್ಯಗಳು ನಿರ್ಬಂಧಿಸದಿದ್ದರೆ ಮತ್ತು ತಕ್ಷಣವೇ ಫಲಿತಾಂಶವನ್ನು ರೂಪದಲ್ಲಿ ಹಿಂತಿರುಗಿಸಿ , ನಂತರ ಅವರು ಡೇಟಾಬೇಸ್ ಅನ್ನು ನಮೂದಿಸಿದ ಕ್ಷಣಗಳಿಂದ ಕರೆಗಳ ಕ್ರಮವನ್ನು ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ:
ಫಲಿತಾಂಶ1 = T1() // ನಿಜವಾದ ಫಲಿತಾಂಶಗಳು ಭರವಸೆಗಳಾಗಿವೆ
ಫಲಿತಾಂಶ2 = T2()
ಪರಮಾಣು ಅಗತ್ಯವಿದ್ದಲ್ಲಿ (ಅಂದರೆ, ಎಲ್ಲಾ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಬೇಕು ಅಥವಾ ಸ್ಥಗಿತಗೊಳಿಸಬೇಕು) ಮತ್ತು ಅನುಕ್ರಮವು ಮುಖ್ಯವಾಗಿರುತ್ತದೆ, ನಂತರ T1 ಮತ್ತು T2 ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಒಂದೇ ವಹಿವಾಟಿನೊಳಗೆ ನಿರ್ವಹಿಸಬೇಕು.
ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದ ಶೇರ್ಡಿಂಗ್ ಅನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೊರಗೆ ಸರಿಸಬಹುದು
ಶರ್ಡಿಂಗ್ ಎನ್ನುವುದು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಅಡ್ಡಲಾಗಿ ವಿಭಜಿಸುವ ವಿಧಾನವಾಗಿದೆ. ಕೆಲವು ಡೇಟಾಬೇಸ್‌ಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಡೇಟಾವನ್ನು ಅಡ್ಡಲಾಗಿ ವಿಭಜಿಸಬಹುದು, ಆದರೆ ಇತರವುಗಳು ಸಾಧ್ಯವಿಲ್ಲ ಅಥವಾ ಅದರಲ್ಲಿ ಉತ್ತಮವಾಗಿಲ್ಲ. ಡೇಟಾ ಆರ್ಕಿಟೆಕ್ಟ್‌ಗಳು/ಡೆವಲಪರ್‌ಗಳು ಡೇಟಾವನ್ನು ಹೇಗೆ ಪ್ರವೇಶಿಸಬಹುದು ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ಊಹಿಸಲು ಸಾಧ್ಯವಾದಾಗ, ಅವರು ಈ ಕೆಲಸವನ್ನು ಡೇಟಾಬೇಸ್‌ಗೆ ನಿಯೋಜಿಸುವ ಬದಲು ಬಳಕೆದಾರರ ಜಾಗದಲ್ಲಿ ಸಮತಲ ವಿಭಾಗಗಳನ್ನು ರಚಿಸಬಹುದು. ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು "ಅಪ್ಲಿಕೇಶನ್-ಮಟ್ಟದ ಶಾರ್ಡಿಂಗ್" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ (ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದ ಶೇರ್ಡಿಂಗ್).
ದುರದೃಷ್ಟವಶಾತ್, ಈ ಹೆಸರು ಸಾಮಾನ್ಯವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಸೇವೆಗಳಲ್ಲಿ ಶೇರ್ಡಿಂಗ್ ವಾಸಿಸುತ್ತದೆ ಎಂಬ ತಪ್ಪು ಕಲ್ಪನೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ವಾಸ್ತವವಾಗಿ, ಇದನ್ನು ಡೇಟಾಬೇಸ್ ಮುಂದೆ ಪ್ರತ್ಯೇಕ ಪದರವಾಗಿ ಅಳವಡಿಸಬಹುದು. ಡೇಟಾ ಬೆಳವಣಿಗೆ ಮತ್ತು ಸ್ಕೀಮಾ ಪುನರಾವರ್ತನೆಗಳ ಆಧಾರದ ಮೇಲೆ, ಷರ್ಡಿಂಗ್ ಅಗತ್ಯತೆಗಳು ಸಾಕಷ್ಟು ಸಂಕೀರ್ಣವಾಗಬಹುದು. ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗಳನ್ನು ಮರುಹಂಚಿಕೆ ಮಾಡದೆಯೇ ಪುನರಾವರ್ತಿಸುವ ಸಾಮರ್ಥ್ಯದಿಂದ ಕೆಲವು ತಂತ್ರಗಳು ಪ್ರಯೋಜನ ಪಡೆಯಬಹುದು.
ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗಳನ್ನು ಶಾರ್ಡಿಂಗ್ ಸೇವೆಯಿಂದ ಬೇರ್ಪಡಿಸಲಾಗಿರುವ ವಾಸ್ತುಶಿಲ್ಪದ ಉದಾಹರಣೆ
ಶಾರ್ಡಿಂಗ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಸೇವೆಗೆ ಸರಿಸುವುದರಿಂದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಮರುಹಂಚಿಕೆ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲದೇ ವಿಭಿನ್ನ ಶರ್ಡಿಂಗ್ ತಂತ್ರಗಳನ್ನು ಬಳಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ವಿಸ್ತರಿಸುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದಲ್ಲಿ ಇಂತಹ ಶಾರ್ಡಿಂಗ್ ಸಿಸ್ಟಮ್ನ ಉದಾಹರಣೆಯಾಗಿದೆ. Vitess MySQL ಗಾಗಿ ಸಮತಲವಾದ ಶಾರ್ಡಿಂಗ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ ಮತ್ತು MySQL ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಗ್ರಾಹಕರನ್ನು ಸಂಪರ್ಕಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಸಿಸ್ಟಮ್ ಡೇಟಾವನ್ನು ವಿಭಿನ್ನ MySQL ನೋಡ್‌ಗಳಾಗಿ ವಿಭಾಗಿಸುತ್ತದೆ, ಅದು ಪರಸ್ಪರರ ಬಗ್ಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲ.
ಸ್ವಯಂ ಹೆಚ್ಚಳ ಅಪಾಯಕಾರಿ
AUTOINCREMENT ಪ್ರಾಥಮಿಕ ಕೀಲಿಗಳನ್ನು ಉತ್ಪಾದಿಸುವ ಸಾಮಾನ್ಯ ಮಾರ್ಗವಾಗಿದೆ. ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ID ಜನರೇಟರ್‌ಗಳಾಗಿ ಬಳಸಿದಾಗ ಆಗಾಗ್ಗೆ ಪ್ರಕರಣಗಳಿವೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ರಚಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಕೋಷ್ಟಕಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಸ್ವಯಂ ಹೆಚ್ಚಳವನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರಾಥಮಿಕ ಕೀಲಿಗಳನ್ನು ರಚಿಸುವುದು ಆದರ್ಶದಿಂದ ದೂರವಿರಲು ಹಲವಾರು ಕಾರಣಗಳಿವೆ:
- ವಿತರಿಸಿದ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ, ಸ್ವಯಂ ಹೆಚ್ಚಳವು ಗಂಭೀರ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಐಡಿಯನ್ನು ರಚಿಸಲು, ಜಾಗತಿಕ ಲಾಕ್ ಅಗತ್ಯವಿದೆ. ಬದಲಾಗಿ, ನೀವು UUID ಅನ್ನು ರಚಿಸಬಹುದು: ಇದಕ್ಕೆ ವಿವಿಧ ಡೇಟಾಬೇಸ್ ನೋಡ್‌ಗಳ ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ. ಲಾಕ್‌ಗಳೊಂದಿಗೆ ಸ್ವಯಂ-ಹೆಚ್ಚಳುವಿಕೆಯು ವಿವಾದಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು ಮತ್ತು ವಿತರಿಸಿದ ಸಂದರ್ಭಗಳಲ್ಲಿ ಒಳಸೇರಿಸುವಿಕೆಯ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಕೆಲವು DBMS ಗಳಿಗೆ (ಉದಾಹರಣೆಗೆ, MySQL) ವಿಶೇಷ ಕಾನ್ಫಿಗರೇಶನ್ ಮತ್ತು ಮಾಸ್ಟರ್-ಮಾಸ್ಟರ್ ರೆಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸರಿಯಾಗಿ ಸಂಘಟಿಸಲು ಹೆಚ್ಚು ಎಚ್ಚರಿಕೆಯಿಂದ ಗಮನಹರಿಸಬಹುದು. ಮತ್ತು ಕಾನ್ಫಿಗರ್ ಮಾಡುವಾಗ ತಪ್ಪುಗಳನ್ನು ಮಾಡುವುದು ಸುಲಭ, ಇದು ರೆಕಾರ್ಡಿಂಗ್ ವೈಫಲ್ಯಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
- ಕೆಲವು ಡೇಟಾಬೇಸ್‌ಗಳು ಪ್ರಾಥಮಿಕ ಕೀಲಿಗಳ ಆಧಾರದ ಮೇಲೆ ವಿಭಜನಾ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಹೊಂದಿವೆ. ಅನುಕ್ರಮ ID ಗಳು ಅನಿರೀಕ್ಷಿತ ಹಾಟ್ ಸ್ಪಾಟ್‌ಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು ಮತ್ತು ಕೆಲವು ವಿಭಾಗಗಳಲ್ಲಿ ಹೆಚ್ಚಿನ ಲೋಡ್ ಆಗಬಹುದು ಆದರೆ ಇತರವು ನಿಷ್ಕ್ರಿಯವಾಗಿರುತ್ತವೆ.
- ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಾಲನ್ನು ಪ್ರವೇಶಿಸಲು ಪ್ರಾಥಮಿಕ ಕೀಲಿಯು ವೇಗವಾದ ಮಾರ್ಗವಾಗಿದೆ. ದಾಖಲೆಗಳನ್ನು ಗುರುತಿಸಲು ಉತ್ತಮ ಮಾರ್ಗಗಳೊಂದಿಗೆ, ಅನುಕ್ರಮ ID ಗಳು ಕೋಷ್ಟಕಗಳಲ್ಲಿನ ಪ್ರಮುಖ ಕಾಲಮ್ ಅನ್ನು ಅರ್ಥಹೀನ ಮೌಲ್ಯಗಳಿಂದ ತುಂಬಿದ ಅನುಪಯುಕ್ತ ಕಾಲಮ್ ಆಗಿ ಪರಿವರ್ತಿಸಬಹುದು. ಆದ್ದರಿಂದ, ಸಾಧ್ಯವಾದಾಗಲೆಲ್ಲಾ, ದಯವಿಟ್ಟು ಜಾಗತಿಕವಾಗಿ ಅನನ್ಯ ಮತ್ತು ನೈಸರ್ಗಿಕ ಪ್ರಾಥಮಿಕ ಕೀಲಿಯನ್ನು (ಉದಾಹರಣೆಗೆ ಬಳಕೆದಾರಹೆಸರು) ಆಯ್ಕೆಮಾಡಿ.
ವಿಧಾನವನ್ನು ನಿರ್ಧರಿಸುವ ಮೊದಲು, ಇಂಡೆಕ್ಸಿಂಗ್, ವಿಭಜನೆ ಮತ್ತು ಶಾರ್ಡಿಂಗ್ ಮೇಲೆ ಸ್ವಯಂ-ಹೆಚ್ಚಳಿಸುವ ಐಡಿಗಳು ಮತ್ತು UUID ಗಳ ಪ್ರಭಾವವನ್ನು ಪರಿಗಣಿಸಿ.
ಹಳೆಯ ಡೇಟಾ ಉಪಯುಕ್ತವಾಗಬಹುದು ಮತ್ತು ಲಾಕ್ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ
ಮಲ್ಟಿವರ್ಶನ್ ಕಾನ್ಕರೆನ್ಸಿ ಕಂಟ್ರೋಲ್ (MVCC) ಮೇಲೆ ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಚರ್ಚಿಸಲಾದ ಅನೇಕ ಸ್ಥಿರತೆಯ ಅಗತ್ಯತೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ಕೆಲವು ಡೇಟಾಬೇಸ್‌ಗಳು (ಉದಾಹರಣೆಗೆ, ಪೋಸ್ಟ್‌ಗ್ರೆಸ್, ಸ್ಪ್ಯಾನರ್) ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳೊಂದಿಗೆ ವಹಿವಾಟುಗಳನ್ನು "ಫೀಡ್" ಮಾಡಲು MVCC ಅನ್ನು ಬಳಸುತ್ತವೆ - ಡೇಟಾಬೇಸ್‌ನ ಹಳೆಯ ಆವೃತ್ತಿಗಳು. ಸ್ಥಿರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ವಹಿವಾಟುಗಳನ್ನು ಸಹ ಧಾರಾವಾಹಿ ಮಾಡಬಹುದು. ಹಳೆಯ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ನಿಂದ ಓದುವಾಗ, ಹಳೆಯ ಡೇಟಾವನ್ನು ಓದಲಾಗುತ್ತದೆ.
ಸ್ವಲ್ಪ ಹಳೆಯ ಡೇಟಾವನ್ನು ಓದುವುದು ಉಪಯುಕ್ತವಾಗಬಹುದು, ಉದಾಹರಣೆಗೆ, ಡೇಟಾದಿಂದ ವಿಶ್ಲೇಷಣೆಯನ್ನು ರಚಿಸುವಾಗ ಅಥವಾ ಅಂದಾಜು ಒಟ್ಟು ಮೌಲ್ಯಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವಾಗ.
ಲೆಗಸಿ ಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಮೊದಲ ಪ್ರಯೋಜನವೆಂದರೆ ಕಡಿಮೆ ಸುಪ್ತತೆ (ವಿಶೇಷವಾಗಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ವಿವಿಧ ಭೌಗೋಳಿಕತೆಗಳಲ್ಲಿ ವಿತರಿಸಿದರೆ). ಎರಡನೆಯದು ಓದಲು-ಮಾತ್ರ ವಹಿವಾಟುಗಳು ಲಾಕ್-ಫ್ರೀ ಆಗಿರುತ್ತವೆ. ಬಹಳಷ್ಟು ಓದುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಇದು ಗಮನಾರ್ಹ ಪ್ರಯೋಜನವಾಗಿದೆ, ಅವುಗಳು ಹಳೆಯ ಡೇಟಾವನ್ನು ನಿರ್ವಹಿಸುವವರೆಗೆ.
ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಯು ಪೆಸಿಫಿಕ್ ಸಾಗರದ ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ ಲಭ್ಯವಿದ್ದರೂ ಸಹ, ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಸ್ಥಳೀಯ ಪ್ರತಿಕೃತಿಯಿಂದ 5 ಸೆಕೆಂಡುಗಳಷ್ಟು ಹಳೆಯದಾದ ಡೇಟಾವನ್ನು ಓದುತ್ತದೆ
DBMS ಗಳು ಹಳೆಯ ಆವೃತ್ತಿಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಶುದ್ಧೀಕರಿಸುತ್ತವೆ ಮತ್ತು ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ, ವಿನಂತಿಯ ಮೇರೆಗೆ ಇದನ್ನು ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, Postgres ಬಳಕೆದಾರರಿಗೆ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ VACUUM ವಿನಂತಿಯ ಮೇರೆಗೆ, ಮತ್ತು ನಿಯತಕಾಲಿಕವಾಗಿ ಈ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ. ಒಂದು ಗಂಟೆಗಿಂತ ಹಳೆಯದಾದ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳನ್ನು ತೊಡೆದುಹಾಕಲು ಸ್ಪ್ಯಾನರ್ ಕಸ ಸಂಗ್ರಾಹಕವನ್ನು ನಡೆಸುತ್ತದೆ.
ಯಾವುದೇ ಸಮಯದ ಮೂಲಗಳು ವಿರೂಪಕ್ಕೆ ಒಳಪಟ್ಟಿರುತ್ತವೆ
ಎಲ್ಲಾ ಸಮಯ API ಗಳು ಸುಳ್ಳು ಎಂಬುದು ಕಂಪ್ಯೂಟರ್ ವಿಜ್ಞಾನದಲ್ಲಿ ಉತ್ತಮವಾದ ರಹಸ್ಯವಾಗಿದೆ. ವಾಸ್ತವವಾಗಿ, ನಮ್ಮ ಯಂತ್ರಗಳಿಗೆ ನಿಖರವಾದ ಪ್ರಸ್ತುತ ಸಮಯ ತಿಳಿದಿಲ್ಲ. ಕಂಪ್ಯೂಟರ್‌ಗಳು ಸ್ಫಟಿಕ ಶಿಲೆಯ ಸ್ಫಟಿಕಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ, ಅದು ಕಂಪನಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ಅದು ಸಮಯವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಲು ಬಳಸಲಾಗುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಅವು ಸಾಕಷ್ಟು ನಿಖರವಾಗಿಲ್ಲ ಮತ್ತು ನಿಖರವಾದ ಸಮಯಕ್ಕಿಂತ ಮುಂದಿರಬಹುದು/ಹಿಂದೆ ಇರಬಹುದು. ಶಿಫ್ಟ್ ದಿನಕ್ಕೆ 20 ಸೆಕೆಂಡುಗಳನ್ನು ತಲುಪಬಹುದು. ಆದ್ದರಿಂದ, ನಮ್ಮ ಕಂಪ್ಯೂಟರ್‌ಗಳಲ್ಲಿನ ಸಮಯವನ್ನು ನಿಯತಕಾಲಿಕವಾಗಿ ನೆಟ್ವರ್ಕ್ ಒಂದರೊಂದಿಗೆ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಬೇಕು.
NTP ಸರ್ವರ್‌ಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸೇಶನ್‌ಗಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ, ಆದರೆ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಪ್ರಕ್ರಿಯೆಯು ನೆಟ್ವರ್ಕ್ ವಿಳಂಬಗಳಿಗೆ ಒಳಪಟ್ಟಿರುತ್ತದೆ. ಅದೇ ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ NTP ಸರ್ವರ್‌ನೊಂದಿಗೆ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು ಸಹ ಸ್ವಲ್ಪ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಸಾರ್ವಜನಿಕ NTP ಸರ್ವರ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಇನ್ನೂ ಹೆಚ್ಚಿನ ಅಸ್ಪಷ್ಟತೆಗೆ ಕಾರಣವಾಗಬಹುದು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ.
ಪರಮಾಣು ಗಡಿಯಾರಗಳು ಮತ್ತು ಅವುಗಳ GPS ಕೌಂಟರ್ಪಾರ್ಟ್ಸ್ ಪ್ರಸ್ತುತ ಸಮಯವನ್ನು ನಿರ್ಧರಿಸಲು ಉತ್ತಮವಾಗಿದೆ, ಆದರೆ ಅವುಗಳು ದುಬಾರಿ ಮತ್ತು ಸಂಕೀರ್ಣ ಸೆಟಪ್ ಅಗತ್ಯವಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಅವುಗಳನ್ನು ಪ್ರತಿ ಕಾರಿನಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾಗುವುದಿಲ್ಲ. ಈ ಕಾರಣದಿಂದಾಗಿ, ಡೇಟಾ ಕೇಂದ್ರಗಳು ಶ್ರೇಣೀಕೃತ ವಿಧಾನವನ್ನು ಬಳಸುತ್ತವೆ. ಪರಮಾಣು ಮತ್ತು/ಅಥವಾ GPS ಗಡಿಯಾರಗಳು ನಿಖರವಾದ ಸಮಯವನ್ನು ತೋರಿಸುತ್ತವೆ, ನಂತರ ಅದನ್ನು ದ್ವಿತೀಯ ಸರ್ವರ್‌ಗಳ ಮೂಲಕ ಇತರ ಯಂತ್ರಗಳಿಗೆ ಪ್ರಸಾರ ಮಾಡಲಾಗುತ್ತದೆ. ಇದರರ್ಥ ಪ್ರತಿ ಯಂತ್ರವು ನಿಖರವಾದ ಸಮಯದಿಂದ ನಿರ್ದಿಷ್ಟ ಆಫ್‌ಸೆಟ್ ಅನ್ನು ಅನುಭವಿಸುತ್ತದೆ.
ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ವಿಭಿನ್ನ ಯಂತ್ರಗಳಲ್ಲಿ (ವಿಭಿನ್ನ ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಇಲ್ಲದಿದ್ದರೆ) ನೆಲೆಗೊಂಡಿವೆ ಎಂಬ ಅಂಶದಿಂದ ಪರಿಸ್ಥಿತಿಯು ಉಲ್ಬಣಗೊಳ್ಳುತ್ತದೆ. ಹೀಗಾಗಿ, ಸಮಯವು ವಿಭಿನ್ನ ಯಂತ್ರಗಳಲ್ಲಿ ವಿತರಿಸಲಾದ DB ನೋಡ್‌ಗಳಲ್ಲಿ ಮಾತ್ರ ಭಿನ್ನವಾಗಿರುತ್ತದೆ. ಇದು ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ನಲ್ಲಿಯೂ ವಿಭಿನ್ನವಾಗಿರುತ್ತದೆ.
Google TrueTime ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ವಿಧಾನವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಈ ದಿಕ್ಕಿನಲ್ಲಿ Google ನ ಪ್ರಗತಿಯು ಪರಮಾಣು ಮತ್ತು GPS ಗಡಿಯಾರಗಳಿಗೆ ನೀರಸ ಪರಿವರ್ತನೆಯಿಂದ ವಿವರಿಸಲ್ಪಟ್ಟಿದೆ ಎಂದು ಹೆಚ್ಚಿನ ಜನರು ನಂಬುತ್ತಾರೆ, ಆದರೆ ಇದು ದೊಡ್ಡ ಚಿತ್ರದ ಭಾಗವಾಗಿದೆ. TrueTime ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದು ಇಲ್ಲಿದೆ:
- TrueTime ಎರಡು ವಿಭಿನ್ನ ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತದೆ: GPS ಮತ್ತು ಪರಮಾಣು ಗಡಿಯಾರಗಳು. ಈ ಕೈಗಡಿಯಾರಗಳು ಪರಸ್ಪರ ಸಂಬಂಧವಿಲ್ಲದ ವೈಫಲ್ಯ ವಿಧಾನಗಳನ್ನು ಹೊಂದಿವೆ. [ವಿವರಗಳಿಗಾಗಿ ಪುಟ 5 ನೋಡಿ - ಅಂದಾಜು ಅನುವಾದ.), ಆದ್ದರಿಂದ ಅವರ ಜಂಟಿ ಬಳಕೆಯು ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.
- TrueTime ಅಸಾಮಾನ್ಯ API ಹೊಂದಿದೆ. ಇದು ಮಾಪನ ದೋಷ ಮತ್ತು ಅದರೊಳಗೆ ನಿರ್ಮಿಸಲಾದ ಅನಿಶ್ಚಿತತೆಯೊಂದಿಗೆ ಮಧ್ಯಂತರವಾಗಿ ಸಮಯವನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ. ಸಮಯದ ನಿಜವಾದ ಕ್ಷಣವು ಮಧ್ಯಂತರದ ಮೇಲಿನ ಮತ್ತು ಕೆಳಗಿನ ಗಡಿಗಳ ನಡುವೆ ಎಲ್ಲೋ ಇರುತ್ತದೆ. ಸ್ಪ್ಯಾನರ್, Google ನ ವಿತರಿಸಿದ ಡೇಟಾಬೇಸ್, ಪ್ರಸ್ತುತ ಸಮಯವು ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗಿದೆ ಎಂದು ಹೇಳಲು ಸುರಕ್ಷಿತವಾಗುವವರೆಗೆ ಕಾಯುತ್ತದೆ. ಈ ವಿಧಾನವು ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಕೆಲವು ಸುಪ್ತತೆಯನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ, ವಿಶೇಷವಾಗಿ ಮಾಸ್ಟರ್ಸ್ನಲ್ಲಿ ಅನಿಶ್ಚಿತತೆ ಹೆಚ್ಚಿದ್ದರೆ, ಆದರೆ ಜಾಗತಿಕವಾಗಿ ವಿತರಿಸಲಾದ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿಯೂ ಸಹ ಸರಿಯಾಗಿರುವುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ.
ಸ್ಪ್ಯಾನರ್ ಘಟಕಗಳು TrueTime ಅನ್ನು ಬಳಸುತ್ತವೆ, ಅಲ್ಲಿ TT.now() ಮಧ್ಯಂತರವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರಸ್ತುತ ಸಮಯವು ಒಂದು ನಿರ್ದಿಷ್ಟ ಹಂತವನ್ನು ದಾಟಿದೆ ಎಂದು ವಿಶ್ವಾಸ ಹೊಂದುವವರೆಗೆ ಸ್ಪ್ಯಾನರ್ ಸರಳವಾಗಿ ನಿದ್ರಿಸುತ್ತದೆ.
ಪ್ರಸ್ತುತ ಸಮಯವನ್ನು ನಿರ್ಧರಿಸುವಲ್ಲಿ ಕಡಿಮೆ ನಿಖರತೆ ಎಂದರೆ ಸ್ಪ್ಯಾನರ್ ಕಾರ್ಯಾಚರಣೆಗಳ ಅವಧಿಯ ಹೆಚ್ಚಳ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯ ಇಳಿಕೆ. ಅದಕ್ಕಾಗಿಯೇ ಸಂಪೂರ್ಣ ನಿಖರವಾದ ಗಡಿಯಾರವನ್ನು ಪಡೆಯುವುದು ಅಸಾಧ್ಯವಾದರೂ ಸಾಧ್ಯವಾದಷ್ಟು ಹೆಚ್ಚಿನ ನಿಖರತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳುವುದು ಮುಖ್ಯವಾಗಿದೆ.
ವಿಳಂಬಕ್ಕೆ ಹಲವು ಅರ್ಥಗಳಿವೆ
ವಿಳಂಬ ಎಂದರೇನು ಎಂದು ನೀವು ಹನ್ನೆರಡು ತಜ್ಞರನ್ನು ಕೇಳಿದರೆ, ನೀವು ಬಹುಶಃ ವಿಭಿನ್ನ ಉತ್ತರಗಳನ್ನು ಪಡೆಯುತ್ತೀರಿ. DBMS ನಲ್ಲಿ ಲೇಟೆನ್ಸಿಯನ್ನು ಸಾಮಾನ್ಯವಾಗಿ "ಡೇಟಾಬೇಸ್ ಲೇಟೆನ್ಸಿ" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಇದು ಕ್ಲೈಂಟ್‌ನಿಂದ ಗ್ರಹಿಸಲ್ಪಟ್ಟದ್ದಕ್ಕಿಂತ ಭಿನ್ನವಾಗಿರುತ್ತದೆ. ವಾಸ್ತವವಾಗಿ ಕ್ಲೈಂಟ್ ನೆಟ್ವರ್ಕ್ ವಿಳಂಬ ಮತ್ತು ಡೇಟಾಬೇಸ್ ವಿಳಂಬದ ಮೊತ್ತವನ್ನು ಗಮನಿಸುತ್ತದೆ. ಬೆಳೆಯುತ್ತಿರುವ ಸಮಸ್ಯೆಗಳನ್ನು ಡೀಬಗ್ ಮಾಡುವಾಗ ಲೇಟೆನ್ಸಿ ಪ್ರಕಾರವನ್ನು ಪ್ರತ್ಯೇಕಿಸುವ ಸಾಮರ್ಥ್ಯವು ನಿರ್ಣಾಯಕವಾಗಿದೆ. ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವಾಗ ಮತ್ತು ಪ್ರದರ್ಶಿಸುವಾಗ, ಯಾವಾಗಲೂ ಎರಡೂ ಪ್ರಕಾರಗಳ ಮೇಲೆ ಕಣ್ಣಿಡಲು ಪ್ರಯತ್ನಿಸಿ.
ನಿರ್ದಿಷ್ಟ ವಹಿವಾಟಿಗೆ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅವಶ್ಯಕತೆಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬೇಕು
ಕೆಲವೊಮ್ಮೆ DBMS ನ ಕಾರ್ಯಕ್ಷಮತೆಯ ಗುಣಲಕ್ಷಣಗಳು ಮತ್ತು ಅದರ ಮಿತಿಗಳನ್ನು ಬರೆಯುವ/ಓದುವ ಥ್ರೋಪುಟ್ ಮತ್ತು ಲೇಟೆನ್ಸಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗುತ್ತದೆ. ಇದು ಪ್ರಮುಖ ಸಿಸ್ಟಮ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳ ಸಾಮಾನ್ಯ ಅವಲೋಕನವನ್ನು ಒದಗಿಸುತ್ತದೆ, ಆದರೆ ಹೊಸ DBMS ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವಾಗ, ನಿರ್ಣಾಯಕ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು (ಪ್ರತಿ ಪ್ರಶ್ನೆ ಮತ್ತು/ಅಥವಾ ವಹಿವಾಟಿಗೆ) ಹೆಚ್ಚು ಸಮಗ್ರವಾದ ವಿಧಾನವಾಗಿದೆ. ಉದಾಹರಣೆಗಳು:
- ನಿರ್ದಿಷ್ಟ ನಿರ್ಬಂಧಗಳು ಮತ್ತು ಸಂಬಂಧಿತ ಕೋಷ್ಟಕಗಳಲ್ಲಿ ಸಾಲು ಪ್ಯಾಡಿಂಗ್‌ನೊಂದಿಗೆ ಹೊಸ ಸಾಲನ್ನು ಟೇಬಲ್ X ಗೆ (50 ಮಿಲಿಯನ್ ಸಾಲುಗಳೊಂದಿಗೆ) ಸೇರಿಸುವಾಗ ಥ್ರೋಪುಟ್ ಮತ್ತು ಲೇಟೆನ್ಸಿ ಬರೆಯಿರಿ.
- ಸರಾಸರಿ ಸ್ನೇಹಿತರ ಸಂಖ್ಯೆ 500 ಆಗಿರುವಾಗ ನಿರ್ದಿಷ್ಟ ಬಳಕೆದಾರರ ಸ್ನೇಹಿತರ ಸ್ನೇಹಿತರನ್ನು ಪ್ರದರ್ಶಿಸುವಲ್ಲಿ ವಿಳಂಬ.
- ಬಳಕೆದಾರರು ಗಂಟೆಗೆ X ನಮೂದುಗಳೊಂದಿಗೆ 100 ಇತರ ಬಳಕೆದಾರರನ್ನು ಅನುಸರಿಸಿದಾಗ ಬಳಕೆದಾರರ ಇತಿಹಾಸದಿಂದ ಟಾಪ್ 500 ನಮೂದುಗಳನ್ನು ಹಿಂಪಡೆಯುವಲ್ಲಿ ಸುಪ್ತತೆ.
ಡೇಟಾಬೇಸ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಗತ್ಯತೆಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ ಎಂದು ನೀವು ಭರವಸೆ ನೀಡುವವರೆಗೆ ಮೌಲ್ಯಮಾಪನ ಮತ್ತು ಪ್ರಯೋಗವು ಅಂತಹ ನಿರ್ಣಾಯಕ ಪ್ರಕರಣಗಳನ್ನು ಒಳಗೊಂಡಿರಬಹುದು. ಲೇಟೆನ್ಸಿ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವಾಗ ಮತ್ತು SLO ಗಳನ್ನು ನಿರ್ಧರಿಸುವಾಗ ಇದೇ ರೀತಿಯ ಹೆಬ್ಬೆರಳಿನ ನಿಯಮವು ಈ ಸ್ಥಗಿತವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಪ್ರತಿ ಕಾರ್ಯಾಚರಣೆಗೆ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವಾಗ ಹೆಚ್ಚಿನ ಕಾರ್ಡಿನಾಲಿಟಿ ಬಗ್ಗೆ ತಿಳಿದಿರಲಿ. ಹೆಚ್ಚಿನ ಶಕ್ತಿಯ ಡೀಬಗ್ ಮಾಡುವಿಕೆ ಡೇಟಾವನ್ನು ಪಡೆಯಲು ಲಾಗ್‌ಗಳು, ಈವೆಂಟ್ ಸಂಗ್ರಹಣೆ ಅಥವಾ ವಿತರಿಸಿದ ಟ್ರೇಸಿಂಗ್ ಅನ್ನು ಬಳಸಿ. ಲೇಖನದಲ್ಲಿ "» ವಿಳಂಬ ಡೀಬಗ್ ಮಾಡುವ ವಿಧಾನಗಳೊಂದಿಗೆ ನೀವೇ ಪರಿಚಿತರಾಗಬಹುದು.
ನೆಸ್ಟೆಡ್ ವಹಿವಾಟುಗಳು ಅಪಾಯಕಾರಿಯಾಗಬಹುದು
ಪ್ರತಿ DBMS ನೆಸ್ಟೆಡ್ ವಹಿವಾಟುಗಳನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ಆದರೆ ಅವರು ಮಾಡಿದಾಗ, ಅಂತಹ ವಹಿವಾಟುಗಳು ಅನಿರೀಕ್ಷಿತ ದೋಷಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು, ಅದು ಯಾವಾಗಲೂ ಪತ್ತೆಹಚ್ಚಲು ಸುಲಭವಲ್ಲ (ಅಂದರೆ, ಕೆಲವು ರೀತಿಯ ಅಸಂಗತತೆ ಇದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿರಬೇಕು).
ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನೆಸ್ಟೆಡ್ ವಹಿವಾಟುಗಳನ್ನು ಬಳಸುವುದನ್ನು ನೀವು ತಪ್ಪಿಸಬಹುದು ಅದು ಅವುಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಬಹುದು ಮತ್ತು ಬೈಪಾಸ್ ಮಾಡಬಹುದು. ನೆಸ್ಟೆಡ್ ವಹಿವಾಟುಗಳನ್ನು ತ್ಯಜಿಸಲಾಗದಿದ್ದರೆ, ನೆಸ್ಟೆಡ್ ವಹಿವಾಟುಗಳು ಆಕಸ್ಮಿಕವಾಗಿ ಸ್ಥಗಿತಗೊಳ್ಳುವ ಅನಿರೀಕ್ಷಿತ ಸಂದರ್ಭಗಳನ್ನು ತಪ್ಪಿಸಲು ಅವುಗಳ ಅನುಷ್ಠಾನದಲ್ಲಿ ವಿಶೇಷ ಕಾಳಜಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ.
ವಿವಿಧ ಲೇಯರ್‌ಗಳಲ್ಲಿ ವಹಿವಾಟುಗಳನ್ನು ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಟ್ ಮಾಡುವುದರಿಂದ ಅನಿರೀಕ್ಷಿತ ನೆಸ್ಟೆಡ್ ವಹಿವಾಟುಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು ಮತ್ತು ಕೋಡ್ ಓದುವಿಕೆ ದೃಷ್ಟಿಕೋನದಿಂದ, ಲೇಖಕರ ಉದ್ದೇಶಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಕಷ್ಟವಾಗುತ್ತದೆ. ಕೆಳಗಿನ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ನೋಡೋಣ:
with newTransaction():
Accounts.create("609-543-222")
with newTransaction():
Accounts.create("775-988-322")
throw Rollback();ಮೇಲಿನ ಕೋಡ್‌ನ ಔಟ್‌ಪುಟ್ ಏನಾಗಿರುತ್ತದೆ? ಇದು ಎರಡೂ ವಹಿವಾಟುಗಳನ್ನು ಹಿಮ್ಮೆಟ್ಟಿಸುತ್ತದೆಯೇ ಅಥವಾ ಒಳಗಿನ ವ್ಯವಹಾರವನ್ನು ಮಾತ್ರವೇ? ನಮಗಾಗಿ ವಹಿವಾಟುಗಳ ರಚನೆಯನ್ನು ಸುತ್ತುವರಿದ ಗ್ರಂಥಾಲಯಗಳ ಬಹು ಪದರಗಳನ್ನು ನಾವು ಅವಲಂಬಿಸಿದ್ದರೆ ಏನಾಗುತ್ತದೆ? ಅಂತಹ ಪ್ರಕರಣಗಳನ್ನು ಗುರುತಿಸಲು ಮತ್ತು ಸುಧಾರಿಸಲು ನಮಗೆ ಸಾಧ್ಯವಾಗುತ್ತದೆಯೇ?
ಬಹು ಕಾರ್ಯಾಚರಣೆಗಳೊಂದಿಗೆ ಡೇಟಾ ಲೇಯರ್ ಅನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ (ಉದಾ. newAccount) ಈಗಾಗಲೇ ತನ್ನದೇ ಆದ ವಹಿವಾಟುಗಳಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ. ಅದರ ಸ್ವಂತ ವಹಿವಾಟಿನೊಳಗೆ ನಡೆಯುವ ಉನ್ನತ ಮಟ್ಟದ ವ್ಯಾಪಾರ ತರ್ಕದ ಭಾಗವಾಗಿ ನೀವು ಅವುಗಳನ್ನು ಚಲಾಯಿಸಿದರೆ ಏನಾಗುತ್ತದೆ? ಈ ಸಂದರ್ಭದಲ್ಲಿ ಪ್ರತ್ಯೇಕತೆ ಮತ್ತು ಸ್ಥಿರತೆ ಏನು?
function newAccount(id string) {
with newTransaction():
Accounts.create(id)
}ಅಂತಹ ಅಂತ್ಯವಿಲ್ಲದ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಗಳನ್ನು ಹುಡುಕುವ ಬದಲು, ನೆಸ್ಟೆಡ್ ವಹಿವಾಟುಗಳನ್ನು ತಪ್ಪಿಸುವುದು ಉತ್ತಮ. ಎಲ್ಲಾ ನಂತರ, ನಿಮ್ಮ ಡೇಟಾ ಲೇಯರ್ ತನ್ನದೇ ಆದ ವಹಿವಾಟುಗಳನ್ನು ರಚಿಸದೆ ಉನ್ನತ ಮಟ್ಟದ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಸುಲಭವಾಗಿ ನಿರ್ವಹಿಸಬಹುದು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ವ್ಯವಹಾರದ ತರ್ಕವು ಸ್ವತಃ ವ್ಯವಹಾರವನ್ನು ಪ್ರಾರಂಭಿಸಲು, ಅದರ ಮೇಲೆ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು, ವಹಿವಾಟು ನಡೆಸಲು ಅಥವಾ ಸ್ಥಗಿತಗೊಳಿಸಲು ಸಮರ್ಥವಾಗಿದೆ.
function newAccount(id string) {
Accounts.create(id)
}
// In main application:
with newTransaction():
// Read some data from database for configuration.
// Generate an ID from the ID service.
Accounts.create(id)
Uploads.create(id) // create upload queue for the user.ವ್ಯವಹಾರಗಳು ಅಪ್ಲಿಕೇಶನ್ ಸ್ಥಿತಿಗೆ ಸಂಬಂಧಿಸಬಾರದು
ಕೆಲವೊಮ್ಮೆ ಕೆಲವು ಮೌಲ್ಯಗಳನ್ನು ಬದಲಾಯಿಸಲು ಅಥವಾ ಪ್ರಶ್ನೆ ನಿಯತಾಂಕಗಳನ್ನು ತಿರುಚಲು ವ್ಯವಹಾರಗಳಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಸ್ಥಿತಿಯನ್ನು ಬಳಸಲು ಪ್ರಲೋಭನಗೊಳಿಸುತ್ತದೆ. ಪರಿಗಣಿಸಬೇಕಾದ ನಿರ್ಣಾಯಕ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸವೆಂದರೆ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸರಿಯಾದ ವ್ಯಾಪ್ತಿ. ನೆಟ್ವರ್ಕ್ ಸಮಸ್ಯೆಗಳಿದ್ದಾಗ ಗ್ರಾಹಕರು ಸಾಮಾನ್ಯವಾಗಿ ವಹಿವಾಟುಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ವಹಿವಾಟು ಇತರ ಪ್ರಕ್ರಿಯೆಯಿಂದ ಬದಲಾಗುತ್ತಿರುವ ಸ್ಥಿತಿಯನ್ನು ಅವಲಂಬಿಸಿದ್ದರೆ, ಡೇಟಾ ರೇಸ್‌ನ ಸಾಧ್ಯತೆಯನ್ನು ಅವಲಂಬಿಸಿ ಅದು ತಪ್ಪು ಮೌಲ್ಯವನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು. ವ್ಯವಹಾರಗಳು ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಡೇಟಾ ರೇಸ್ ಪರಿಸ್ಥಿತಿಗಳ ಅಪಾಯವನ್ನು ಪರಿಗಣಿಸಬೇಕು.
var seq int64
with newTransaction():
newSeq := atomic.Increment(&seq)
Entries.query(newSeq)
// Other operations...ಮೇಲಿನ ವಹಿವಾಟು ಅಂತಿಮ ಫಲಿತಾಂಶವನ್ನು ಲೆಕ್ಕಿಸದೆ ಪ್ರತಿ ಬಾರಿ ಕಾರ್ಯಗತಗೊಳಿಸಿದಾಗ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ನೆಟ್ವರ್ಕ್ ಸಮಸ್ಯೆಗಳಿಂದಾಗಿ ಕಮಿಟ್ ವಿಫಲವಾದರೆ, ನೀವು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಿದಾಗ ವಿನಂತಿಯನ್ನು ಬೇರೆ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ.
ಪ್ರಶ್ನೆ ಯೋಜಕರು ಡೇಟಾಬೇಸ್ ಬಗ್ಗೆ ನಿಮಗೆ ಬಹಳಷ್ಟು ಹೇಳಬಹುದು
ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಪ್ರಶ್ನೆಯನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಪ್ರಶ್ನೆ ಯೋಜಕರು ನಿರ್ಧರಿಸುತ್ತಾರೆ. ಅವರು ವಿನಂತಿಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತಾರೆ ಮತ್ತು ಕಳುಹಿಸುವ ಮೊದಲು ಅವುಗಳನ್ನು ಉತ್ತಮಗೊಳಿಸುತ್ತಾರೆ. ಯೋಜಕರು ತಮ್ಮ ಇತ್ಯರ್ಥದಲ್ಲಿರುವ ಸಂಕೇತಗಳ ಆಧಾರದ ಮೇಲೆ ಕೆಲವು ಸಂಭವನೀಯ ಅಂದಾಜುಗಳನ್ನು ಮಾತ್ರ ಒದಗಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ಈ ಕೆಳಗಿನ ಪ್ರಶ್ನೆಗೆ ಉತ್ತಮ ಹುಡುಕಾಟ ವಿಧಾನ ಯಾವುದು?
SELECT * FROM articles where author = "rakyll" order by title;ಫಲಿತಾಂಶಗಳನ್ನು ಎರಡು ರೀತಿಯಲ್ಲಿ ಹಿಂಪಡೆಯಬಹುದು:
- ಪೂರ್ಣ ಟೇಬಲ್ ಸ್ಕ್ಯಾನ್: ನೀವು ಕೋಷ್ಟಕದಲ್ಲಿನ ಪ್ರತಿ ನಮೂದನ್ನು ನೋಡಬಹುದು ಮತ್ತು ಹೊಂದಾಣಿಕೆಯ ಲೇಖಕರ ಹೆಸರಿನೊಂದಿಗೆ ಲೇಖನಗಳನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು, ತದನಂತರ ಅವುಗಳನ್ನು ಆದೇಶಿಸಬಹುದು.
- ಸೂಚ್ಯಂಕ ಸ್ಕ್ಯಾನ್: ಹೊಂದಾಣಿಕೆಯ ID ಗಳನ್ನು ಹುಡುಕಲು, ಆ ಸಾಲುಗಳನ್ನು ಪಡೆಯಲು ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಆರ್ಡರ್ ಮಾಡಲು ನೀವು ಸೂಚ್ಯಂಕವನ್ನು ಬಳಸಬಹುದು.
ಪ್ರಶ್ನೆ ಯೋಜಕರ ಕೆಲಸವು ಯಾವ ತಂತ್ರವು ಉತ್ತಮವಾಗಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದು. ಪ್ರಶ್ನೆ ಯೋಜಕರು ಸೀಮಿತ ಮುನ್ಸೂಚಕ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಮಾತ್ರ ಹೊಂದಿದ್ದಾರೆ ಎಂದು ಪರಿಗಣಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ಇದು ಕೆಟ್ಟ ನಿರ್ಧಾರಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು. ಡಿಬಿಎಗಳು ಅಥವಾ ಡೆವಲಪರ್‌ಗಳು ಕಳಪೆ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಪ್ರಶ್ನೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಮತ್ತು ಉತ್ತಮಗೊಳಿಸಲು ಅವುಗಳನ್ನು ಬಳಸಬಹುದು. DBMS ನ ಹೊಸ ಆವೃತ್ತಿಗಳು ಪ್ರಶ್ನೆ ಯೋಜಕಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು ಮತ್ತು ಹೊಸ ಆವೃತ್ತಿಯು ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾದರೆ ಡೇಟಾಬೇಸ್ ಅನ್ನು ನವೀಕರಿಸುವಾಗ ಸ್ವಯಂ-ರೋಗನಿರ್ಣಯವು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ನಿಧಾನವಾದ ಪ್ರಶ್ನೆ ಲಾಗ್‌ಗಳು, ಲೇಟೆನ್ಸಿ ಸಮಸ್ಯೆಯ ವರದಿಗಳು ಅಥವಾ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಸಮಯದ ಅಂಕಿಅಂಶಗಳು ಆಪ್ಟಿಮೈಸೇಶನ್ ಅಗತ್ಯವಿರುವ ಪ್ರಶ್ನೆಗಳನ್ನು ಗುರುತಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ಪ್ರಶ್ನೆ ಯೋಜಕರು ಪ್ರಸ್ತುತಪಡಿಸಿದ ಕೆಲವು ಮೆಟ್ರಿಕ್‌ಗಳು ಶಬ್ದಕ್ಕೆ ಒಳಪಟ್ಟಿರಬಹುದು (ವಿಶೇಷವಾಗಿ ಲೇಟೆನ್ಸಿ ಅಥವಾ CPU ಸಮಯವನ್ನು ಅಂದಾಜು ಮಾಡುವಾಗ). ಶೆಡ್ಯೂಲರ್‌ಗಳಿಗೆ ಉತ್ತಮ ಸೇರ್ಪಡೆ ಎಂದರೆ ಮರಣದಂಡನೆ ಮಾರ್ಗವನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಮತ್ತು ಟ್ರ್ಯಾಕ್ ಮಾಡುವ ಸಾಧನಗಳಾಗಿವೆ. ಅಂತಹ ಸಮಸ್ಯೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಅವರು ನಿಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತಾರೆ (ಅಯ್ಯೋ, ಎಲ್ಲಾ DBMS ಗಳು ಅಂತಹ ಸಾಧನಗಳನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ).
ಆನ್‌ಲೈನ್ ವಲಸೆ ಕಷ್ಟ ಆದರೆ ಸಾಧ್ಯ
ಆನ್‌ಲೈನ್ ವಲಸೆ, ಲೈವ್ ವಲಸೆ ಅಥವಾ ನೈಜ-ಸಮಯದ ವಲಸೆ ಎಂದರೆ ಅಲಭ್ಯತೆ ಅಥವಾ ಡೇಟಾ ಭ್ರಷ್ಟಾಚಾರವಿಲ್ಲದೆ ಒಂದು ಡೇಟಾಬೇಸ್‌ನಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಚಲಿಸುವುದು. ಅದೇ DBMS/ಎಂಜಿನ್‌ನಲ್ಲಿ ಪರಿವರ್ತನೆಯು ಸಂಭವಿಸಿದಲ್ಲಿ ಲೈವ್ ವಲಸೆಯನ್ನು ಕೈಗೊಳ್ಳಲು ಸುಲಭವಾಗುತ್ತದೆ. ವಿಭಿನ್ನ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಸ್ಕೀಮಾ ಅವಶ್ಯಕತೆಗಳೊಂದಿಗೆ ಹೊಸ DBMS ಗೆ ಚಲಿಸಲು ಅಗತ್ಯವಾದಾಗ ಪರಿಸ್ಥಿತಿಯು ಹೆಚ್ಚು ಜಟಿಲವಾಗುತ್ತದೆ.
ವಿವಿಧ ಆನ್‌ಲೈನ್ ವಲಸೆ ಮಾದರಿಗಳಿವೆ. ಅವುಗಳಲ್ಲಿ ಒಂದು ಇಲ್ಲಿದೆ:
- ಎರಡೂ ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ ಡಬಲ್ ಎಂಟ್ರಿಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ. ಈ ಹಂತದಲ್ಲಿ ಹೊಸ ಡೇಟಾಬೇಸ್ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಹೊಂದಿಲ್ಲ, ಆದರೆ ಇತ್ತೀಚಿನ ಡೇಟಾವನ್ನು ಮಾತ್ರ ಸ್ವೀಕರಿಸುತ್ತದೆ. ಒಮ್ಮೆ ನೀವು ಇದನ್ನು ಖಚಿತಪಡಿಸಿದರೆ, ನೀವು ಮುಂದಿನ ಹಂತಕ್ಕೆ ಹೋಗಬಹುದು.
- ಎರಡೂ ಡೇಟಾಬೇಸ್‌ಗಳಿಂದ ಓದುವಿಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ.
- ಸಿಸ್ಟಮ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ ಇದರಿಂದ ಓದುವಿಕೆ ಮತ್ತು ಬರೆಯುವಿಕೆಯನ್ನು ಪ್ರಾಥಮಿಕವಾಗಿ ಹೊಸ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ.
- ಹಳೆಯ ಡೇಟಾಬೇಸ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಓದುವುದನ್ನು ಮುಂದುವರಿಸುವಾಗ ಅದಕ್ಕೆ ಬರೆಯುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಈ ಹಂತದಲ್ಲಿ, ಹೊಸ ಡೇಟಾಬೇಸ್ ಇನ್ನೂ ಕೆಲವು ಡೇಟಾವನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. ಅವುಗಳನ್ನು ಹಳೆಯ ಡೇಟಾಬೇಸ್‌ನಿಂದ ನಕಲಿಸಬೇಕು.
- ಹಳೆಯ ಡೇಟಾಬೇಸ್ ಓದಲು ಮಾತ್ರ. ಕಾಣೆಯಾದ ಡೇಟಾವನ್ನು ಹಳೆಯ ಡೇಟಾಬೇಸ್‌ನಿಂದ ಹೊಸದಕ್ಕೆ ನಕಲಿಸಿ. ವಲಸೆ ಪೂರ್ಣಗೊಂಡ ನಂತರ, ಹೊಸ ಡೇಟಾಬೇಸ್‌ಗೆ ಮಾರ್ಗಗಳನ್ನು ಬದಲಾಯಿಸಿ ಮತ್ತು ಹಳೆಯದನ್ನು ನಿಲ್ಲಿಸಿ ಮತ್ತು ಅದನ್ನು ಸಿಸ್ಟಮ್‌ನಿಂದ ಅಳಿಸಿ.
ಹೆಚ್ಚಿನ ಮಾಹಿತಿಗಾಗಿ, ಸಂಪರ್ಕಿಸಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ , ಇದು ಈ ಮಾದರಿಯನ್ನು ಆಧರಿಸಿ ಸ್ಟ್ರೈಪ್‌ನ ವಲಸೆ ತಂತ್ರವನ್ನು ವಿವರಿಸುತ್ತದೆ.
ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಗಮನಾರ್ಹ ಹೆಚ್ಚಳವು ಅನಿರೀಕ್ಷಿತತೆಯ ಹೆಚ್ಚಳಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ
ಡೇಟಾಬೇಸ್‌ನ ಬೆಳವಣಿಗೆಯು ಅದರ ಪ್ರಮಾಣಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಅನಿರೀಕ್ಷಿತ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಡೇಟಾಬೇಸ್‌ನ ಆಂತರಿಕ ರಚನೆಯ ಬಗ್ಗೆ ನಮಗೆ ಹೆಚ್ಚು ತಿಳಿದಿದೆ, ಅದು ಹೇಗೆ ಅಳೆಯುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಉತ್ತಮವಾಗಿ ಊಹಿಸಬಹುದು. ಆದಾಗ್ಯೂ, ಕೆಲವು ಕ್ಷಣಗಳನ್ನು ಊಹಿಸಲು ಇನ್ನೂ ಅಸಾಧ್ಯ.
ಬೇಸ್ ಬೆಳೆದಂತೆ, ಡೇಟಾ ವಾಲ್ಯೂಮ್ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಅವಶ್ಯಕತೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಹಿಂದಿನ ಊಹೆಗಳು ಮತ್ತು ನಿರೀಕ್ಷೆಗಳು ಹಳೆಯದಾಗಬಹುದು. ಸಂಭಾವ್ಯ ಸಮಸ್ಯೆಗಳನ್ನು ತಪ್ಪಿಸಲು ಪ್ರಮುಖ ವಿನ್ಯಾಸದ ಕೂಲಂಕುಷ ಪರೀಕ್ಷೆಗಳು, ದೊಡ್ಡ ಪ್ರಮಾಣದ ಕಾರ್ಯಾಚರಣೆಯ ಸುಧಾರಣೆಗಳು, ಮರುಚಿಂತನೆ ನಿಯೋಜನೆಗಳು ಅಥವಾ ಇತರ DBMS ಗಳಿಗೆ ವಲಸೆಯ ಪ್ರಶ್ನೆಯು ಉದ್ಭವಿಸಿದಾಗ ಇದು.
ಆದರೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಡೇಟಾಬೇಸ್‌ನ ಆಂತರಿಕ ರಚನೆಯ ಅತ್ಯುತ್ತಮ ಜ್ಞಾನವು ಅಗತ್ಯವಿರುವ ಏಕೈಕ ವಿಷಯ ಎಂದು ಯೋಚಿಸಬೇಡಿ. ಹೊಸ ಮಾಪಕಗಳು ಅವರೊಂದಿಗೆ ಹೊಸ ಅಪರಿಚಿತರನ್ನು ತರುತ್ತವೆ. ಅನಿರೀಕ್ಷಿತ ನೋವು ಅಂಕಗಳು, ಅಸಮವಾದ ಡೇಟಾ ವಿತರಣೆ, ಅನಿರೀಕ್ಷಿತ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಮತ್ತು ಹಾರ್ಡ್‌ವೇರ್ ಸಮಸ್ಯೆಗಳು, ನಿರಂತರವಾಗಿ ಹೆಚ್ಚುತ್ತಿರುವ ಟ್ರಾಫಿಕ್ ಮತ್ತು ಹೊಸ ನೆಟ್ವರ್ಕ್ ವಿಭಾಗಗಳು ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ವಿಧಾನ, ಡೇಟಾ ಮಾದರಿ, ನಿಯೋಜನೆ ಮಾದರಿ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಗಾತ್ರವನ್ನು ಮರುಪರಿಶೀಲಿಸಲು ನಿಮ್ಮನ್ನು ಒತ್ತಾಯಿಸುತ್ತದೆ.
...
ಈ ಲೇಖನವನ್ನು ಪ್ರಕಟಿಸುವ ಬಗ್ಗೆ ನಾನು ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ನನ್ನ ಮೂಲ ಪಟ್ಟಿಯಲ್ಲಿ ಈಗಾಗಲೇ ಐದು ಐಟಂಗಳು ಇದ್ದವು. ನಂತರ ದೊಡ್ಡ ಸಂಖ್ಯೆ ಬಂದಿತು ಇನ್ನೇನು ಆವರಿಸಬಹುದು ಎಂಬುದರ ಬಗ್ಗೆ. ಆದ್ದರಿಂದ, ಲೇಖನವು ಗರಿಷ್ಠ ಗಮನ ಅಗತ್ಯವಿರುವ ಕನಿಷ್ಠ ಸ್ಪಷ್ಟ ಸಮಸ್ಯೆಗಳ ಮೇಲೆ ಸ್ಪರ್ಶಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ವಿಷಯವು ದಣಿದಿದೆ ಎಂದು ಇದರ ಅರ್ಥವಲ್ಲ ಮತ್ತು ನನ್ನ ಭವಿಷ್ಯದ ವಸ್ತುಗಳಲ್ಲಿ ನಾನು ಇನ್ನು ಮುಂದೆ ಅದಕ್ಕೆ ಹಿಂತಿರುಗುವುದಿಲ್ಲ ಮತ್ತು ಪ್ರಸ್ತುತಕ್ಕೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವುದಿಲ್ಲ.
ಪಿಎಸ್
ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:
- «";
- «";
- «».
ಮೂಲ: www.habr.com