ಜೀವನದಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ಒಮ್ಮೆಯಾದರೂ ಪ್ರಯತ್ನಿಸಲು ಯೋಗ್ಯವಾಗಿದೆ ಎಂದು ಅವರು ಹೇಳುತ್ತಾರೆ. ಮತ್ತು ನೀವು ಸಂಬಂಧಿತ DBMS ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಬಳಸಿದರೆ, ಪ್ರಾಯೋಗಿಕವಾಗಿ NoSQL ನೊಂದಿಗೆ ಪರಿಚಯ ಮಾಡಿಕೊಳ್ಳುವುದು ಯೋಗ್ಯವಾಗಿದೆ, ಮೊದಲನೆಯದಾಗಿ, ಕನಿಷ್ಠ ಸಾಮಾನ್ಯ ಅಭಿವೃದ್ಧಿಗಾಗಿ. ಈಗ, ಈ ತಂತ್ರಜ್ಞಾನದ ಕ್ಷಿಪ್ರ ಅಭಿವೃದ್ಧಿಯಿಂದಾಗಿ, ಈ ವಿಷಯದ ಬಗ್ಗೆ ಸಾಕಷ್ಟು ಸಂಘರ್ಷದ ಅಭಿಪ್ರಾಯಗಳು ಮತ್ತು ಬಿಸಿ ಚರ್ಚೆಗಳು ನಡೆಯುತ್ತಿವೆ, ಇದು ವಿಶೇಷವಾಗಿ ಆಸಕ್ತಿಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.
ಈ ಎಲ್ಲಾ ವಿವಾದಗಳ ಸಾರವನ್ನು ನೀವು ಪರಿಶೀಲಿಸಿದರೆ, ಅವು ತಪ್ಪು ವಿಧಾನದಿಂದ ಉದ್ಭವಿಸುತ್ತವೆ ಎಂದು ನೀವು ನೋಡಬಹುದು. NoSQL ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಅಗತ್ಯವಿರುವಲ್ಲಿ ಬಳಸುವವರು ತೃಪ್ತರಾಗುತ್ತಾರೆ ಮತ್ತು ಈ ಪರಿಹಾರದಿಂದ ಎಲ್ಲಾ ಪ್ರಯೋಜನಗಳನ್ನು ಪಡೆಯುತ್ತಾರೆ. ಮತ್ತು ಇದು ಅನ್ವಯವಾಗದ ಈ ತಂತ್ರಜ್ಞಾನವನ್ನು ಸರ್ವರೋಗ ನಿವಾರಕವಾಗಿ ಅವಲಂಬಿಸಿರುವ ಪ್ರಯೋಗಕಾರರು ನಿರಾಶೆಗೊಂಡಿದ್ದಾರೆ, ಗಮನಾರ್ಹ ಪ್ರಯೋಜನಗಳನ್ನು ಪಡೆಯದೆ ಸಂಬಂಧಿತ ಡೇಟಾಬೇಸ್‌ಗಳ ಸಾಮರ್ಥ್ಯವನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದಾರೆ.
ಕಸ್ಸಾಂಡ್ರಾ ಡಿಬಿಎಂಎಸ್ ಆಧಾರಿತ ಪರಿಹಾರವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಲ್ಲಿ ನಮ್ಮ ಅನುಭವದ ಬಗ್ಗೆ ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ: ನಾವು ಏನು ಎದುರಿಸಬೇಕಾಗಿತ್ತು, ನಾವು ಕಷ್ಟಕರ ಸಂದರ್ಭಗಳಿಂದ ಹೇಗೆ ಹೊರಬಂದೆವು, NoSQL ಅನ್ನು ಬಳಸುವುದರಿಂದ ನಾವು ಲಾಭ ಪಡೆಯಲು ಸಾಧ್ಯವೇ ಮತ್ತು ನಾವು ಹೆಚ್ಚುವರಿ ಪ್ರಯತ್ನಗಳು/ನಿಧಿಯನ್ನು ಎಲ್ಲಿ ಹೂಡಿಕೆ ಮಾಡಬೇಕಾಗಿತ್ತು .
ಕೆಲವು ರೀತಿಯ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಕರೆಗಳನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡುವ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸುವುದು ಆರಂಭಿಕ ಕಾರ್ಯವಾಗಿದೆ.
ಸಿಸ್ಟಮ್ನ ಕಾರ್ಯಾಚರಣೆಯ ತತ್ವವು ಈ ಕೆಳಗಿನಂತಿರುತ್ತದೆ. ಇನ್‌ಪುಟ್ ನಿರ್ದಿಷ್ಟ ರಚನೆಯೊಂದಿಗೆ ಫೈಲ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಅದು ಕರೆಯ ರಚನೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ನಂತರ ಈ ರಚನೆಯನ್ನು ಸೂಕ್ತ ಕಾಲಮ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಭವಿಷ್ಯದಲ್ಲಿ, ಚಂದಾದಾರರಿಗೆ ಟ್ರಾಫಿಕ್ ಬಳಕೆಯ ಮಾಹಿತಿಯನ್ನು ಪ್ರದರ್ಶಿಸಲು ಉಳಿಸಿದ ಕರೆಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ (ಶುಲ್ಕಗಳು, ಕರೆಗಳು, ಸಮತೋಲನ ಇತಿಹಾಸ).
ಅವರು ಕಸ್ಸಂದ್ರವನ್ನು ಏಕೆ ಆರಿಸಿಕೊಂಡರು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ - ಅವಳು ಮೆಷಿನ್ ಗನ್‌ನಂತೆ ಬರೆಯುತ್ತಾಳೆ, ಸುಲಭವಾಗಿ ಸ್ಕೇಲೆಬಲ್ ಮತ್ತು ದೋಷ-ಸಹಿಷ್ಣು.
ಆದ್ದರಿಂದ, ಇದು ನಮಗೆ ಅನುಭವವನ್ನು ನೀಡಿದೆ
ಹೌದು, ವಿಫಲವಾದ ನೋಡ್ ದುರಂತವಲ್ಲ. ಇದು ಕಸ್ಸಂದ್ರ ಅವರ ತಪ್ಪು ಸಹಿಷ್ಣುತೆಯ ಸಾರವಾಗಿದೆ. ಆದರೆ ಒಂದು ನೋಡ್ ಜೀವಂತವಾಗಿರಬಹುದು ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ಬಳಲುತ್ತಿದ್ದಾರೆ. ಅದು ಬದಲಾದಂತೆ, ಇದು ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ತಕ್ಷಣವೇ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.
ಒರಾಕಲ್ ತನ್ನ ನಿರ್ಬಂಧಗಳೊಂದಿಗೆ ನಿಮ್ಮನ್ನು ಉಳಿಸಿದ ಸ್ಥಳದಲ್ಲಿ ಕಸ್ಸಂದ್ರ ನಿಮ್ಮನ್ನು ರಕ್ಷಿಸುವುದಿಲ್ಲ. ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನ ಲೇಖಕರು ಇದನ್ನು ಮೊದಲೇ ಅರ್ಥಮಾಡಿಕೊಳ್ಳದಿದ್ದರೆ, ಕಸ್ಸಂದ್ರಕ್ಕೆ ಬಂದ ಡಬಲ್ ಮೂಲಕ್ಕಿಂತ ಕೆಟ್ಟದ್ದಲ್ಲ. ಅದು ಬಂದ ನಂತರ, ನಾವು ಅದನ್ನು ಹಾಕುತ್ತೇವೆ.
IB ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಉಚಿತ ಕಸ್ಸಂದ್ರವನ್ನು ಬಲವಾಗಿ ಇಷ್ಟಪಡಲಿಲ್ಲ: ಬಳಕೆದಾರರ ಕ್ರಿಯೆಗಳ ಲಾಗಿಂಗ್ ಇಲ್ಲ, ಹಕ್ಕುಗಳ ವ್ಯತ್ಯಾಸವಿಲ್ಲ. ಕರೆಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ವೈಯಕ್ತಿಕ ಡೇಟಾ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ, ಇದರರ್ಥ ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ವಿನಂತಿಸಲು / ಬದಲಾಯಿಸಲು ಎಲ್ಲಾ ಪ್ರಯತ್ನಗಳು ನಂತರದ ಲೆಕ್ಕಪರಿಶೋಧನೆಯ ಸಾಧ್ಯತೆಯೊಂದಿಗೆ ಲಾಗ್ ಆಗಿರಬೇಕು. ಅಲ್ಲದೆ, ವಿಭಿನ್ನ ಬಳಕೆದಾರರಿಗೆ ವಿವಿಧ ಹಂತಗಳಲ್ಲಿ ಹಕ್ಕುಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುವ ಅಗತ್ಯವನ್ನು ನೀವು ತಿಳಿದಿರಬೇಕು. ಸಂಪೂರ್ಣ ಕೀಸ್ಪೇಸ್ ಅನ್ನು ಮುಕ್ತವಾಗಿ ಅಳಿಸಬಹುದಾದ ಸರಳ ಕಾರ್ಯಾಚರಣೆ ಎಂಜಿನಿಯರ್ ಮತ್ತು ಸೂಪರ್ ನಿರ್ವಾಹಕರು ವಿಭಿನ್ನ ಪಾತ್ರಗಳು, ವಿಭಿನ್ನ ಜವಾಬ್ದಾರಿಗಳು ಮತ್ತು ಸಾಮರ್ಥ್ಯಗಳು. ಪ್ರವೇಶ ಹಕ್ಕುಗಳ ಅಂತಹ ವ್ಯತ್ಯಾಸವಿಲ್ಲದೆ, ಡೇಟಾದ ಮೌಲ್ಯ ಮತ್ತು ಸಮಗ್ರತೆಯು ತಕ್ಷಣವೇ ಯಾವುದೇ ಸ್ಥಿರತೆಯ ಮಟ್ಟಕ್ಕಿಂತ ವೇಗವಾಗಿ ಪ್ರಶ್ನೆಗೆ ಬರುತ್ತದೆ.
ಕರೆಗಳಿಗೆ ಗಂಭೀರವಾದ ವಿಶ್ಲೇಷಣೆಗಳು ಮತ್ತು ವಿವಿಧ ಪರಿಸ್ಥಿತಿಗಳಿಗಾಗಿ ಆವರ್ತಕ ಮಾದರಿಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡಿಲ್ಲ. ಆಯ್ದ ದಾಖಲೆಗಳನ್ನು ನಂತರ ಅಳಿಸಿ ಮತ್ತು ಪುನಃ ಬರೆಯಬೇಕಾಗಿರುವುದರಿಂದ (ಕಾರ್ಯದ ಭಾಗವಾಗಿ, ಡೇಟಾವು ಆರಂಭದಲ್ಲಿ ನಮ್ಮ ಲೂಪ್ ಅನ್ನು ತಪ್ಪಾಗಿ ನಮೂದಿಸಿದಾಗ ಡೇಟಾವನ್ನು ನವೀಕರಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಾವು ಬೆಂಬಲಿಸಬೇಕು), ಕಸ್ಸಂದ್ರ ಇಲ್ಲಿ ನಮ್ಮ ಸ್ನೇಹಿತನಲ್ಲ. ಕಸ್ಸಂದ್ರವು ಪಿಗ್ಗಿ ಬ್ಯಾಂಕ್‌ನಂತಿದೆ - ವಸ್ತುಗಳನ್ನು ಹಾಕಲು ಇದು ಅನುಕೂಲಕರವಾಗಿದೆ, ಆದರೆ ನೀವು ಅದರಲ್ಲಿ ಎಣಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಪರೀಕ್ಷಾ ವಲಯಗಳಿಗೆ ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸುವಲ್ಲಿ ನಾವು ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಿದ್ದೇವೆ (ಪರೀಕ್ಷೆಯಲ್ಲಿ 5 ನೋಡ್‌ಗಳು ಮತ್ತು ಪ್ರಾಮ್‌ನಲ್ಲಿ 20). ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಡಂಪ್ ಅನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ.
ಕಸ್ಸಂದ್ರಕ್ಕೆ ಬರೆಯುವ ಅಪ್ಲಿಕೇಶನ್‌ನ ಡೇಟಾ ಸ್ಕೀಮಾವನ್ನು ನವೀಕರಿಸುವಲ್ಲಿ ಸಮಸ್ಯೆ. ಒಂದು ರೋಲ್ಬ್ಯಾಕ್ ಅನೇಕ ಸಮಾಧಿ ಕಲ್ಲುಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ಇದು ಅನಿರೀಕ್ಷಿತ ರೀತಿಯಲ್ಲಿ ಉತ್ಪಾದಕತೆಯ ನಷ್ಟಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು.. ಕಸ್ಸಂದ್ರವನ್ನು ರೆಕಾರ್ಡಿಂಗ್‌ಗಾಗಿ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಬರೆಯುವ ಮೊದಲು ಹೆಚ್ಚು ಯೋಚಿಸುವುದಿಲ್ಲ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಡೇಟಾದೊಂದಿಗೆ ಯಾವುದೇ ಕಾರ್ಯಾಚರಣೆಯು ಸಹ ರೆಕಾರ್ಡಿಂಗ್ ಆಗಿದೆ. ಅಂದರೆ, ಅನಗತ್ಯವನ್ನು ಅಳಿಸುವ ಮೂಲಕ, ನಾವು ಇನ್ನೂ ಹೆಚ್ಚಿನ ದಾಖಲೆಗಳನ್ನು ಸರಳವಾಗಿ ತಯಾರಿಸುತ್ತೇವೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಕೆಲವನ್ನು ಮಾತ್ರ ಸಮಾಧಿಯ ಕಲ್ಲುಗಳಿಂದ ಗುರುತಿಸಲಾಗುತ್ತದೆ.
ಸೇರಿಸುವಾಗ ಸಮಯ ಮೀರುತ್ತದೆ. ರೆಕಾರ್ಡಿಂಗ್ನಲ್ಲಿ ಕಸ್ಸಂದ್ರ ಸುಂದರವಾಗಿರುತ್ತದೆ, ಆದರೆ ಕೆಲವೊಮ್ಮೆ ಒಳಬರುವ ಹರಿವು ಅವಳನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಗೊಂದಲಗೊಳಿಸಬಹುದು. ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ಸೇರಿಸಲಾಗದ ಹಲವಾರು ದಾಖಲೆಗಳ ಸುತ್ತಲೂ ಅಪ್ಲಿಕೇಶನ್ ಚಕ್ರವನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ ಇದು ಸಂಭವಿಸುತ್ತದೆ. ಮತ್ತು ನಮಗೆ ನಿಜವಾದ DBA ಅಗತ್ಯವಿರುತ್ತದೆ ಅವರು gc.log, ಸಿಸ್ಟಮ್ ಮತ್ತು ಡೀಬಗ್ ಲಾಗ್‌ಗಳನ್ನು ನಿಧಾನವಾದ ಪ್ರಶ್ನೆಗಳಿಗೆ, ಸಂಕೋಚನ ಬಾಕಿ ಇರುವ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತಾರೆ.
ಒಂದು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಹಲವಾರು ಡೇಟಾ ಕೇಂದ್ರಗಳು. ಎಲ್ಲಿಂದ ಓದಬೇಕು ಮತ್ತು ಎಲ್ಲಿ ಬರೆಯಬೇಕು?
ಬಹುಶಃ ಓದುವುದು ಮತ್ತು ಬರೆಯುವುದು ಎಂದು ವಿಭಜಿಸಬಹುದೇ? ಮತ್ತು ಹಾಗಿದ್ದಲ್ಲಿ, ಬರೆಯಲು ಅಥವಾ ಓದಲು ಅರ್ಜಿಯ ಹತ್ತಿರ DC ಇರಬೇಕೇ? ಮತ್ತು ನಾವು ತಪ್ಪಾದ ಸ್ಥಿರತೆಯ ಮಟ್ಟವನ್ನು ಆರಿಸಿದರೆ ನಾವು ನಿಜವಾದ ವಿಭಜಿತ ಮೆದುಳಿನೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುವುದಿಲ್ಲವೇ? ಬಹಳಷ್ಟು ಪ್ರಶ್ನೆಗಳಿವೆ, ಬಹಳಷ್ಟು ಅಪರಿಚಿತ ಸೆಟ್ಟಿಂಗ್‌ಗಳು, ನೀವು ನಿಜವಾಗಿಯೂ ಟಿಂಕರ್ ಮಾಡಲು ಬಯಸುವ ಸಾಧ್ಯತೆಗಳಿವೆ.
ನಾವು ಹೇಗೆ ನಿರ್ಧರಿಸಿದ್ದೇವೆ
ನೋಡ್ ಮುಳುಗುವುದನ್ನು ತಡೆಯಲು, SWAP ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ. ಮತ್ತು ಈಗ, ಮೆಮೊರಿಯ ಕೊರತೆಯಿದ್ದರೆ, ನೋಡ್ ಕೆಳಗೆ ಹೋಗಬೇಕು ಮತ್ತು ದೊಡ್ಡ ಜಿಸಿ ವಿರಾಮಗಳನ್ನು ರಚಿಸಬಾರದು.
ಆದ್ದರಿಂದ, ನಾವು ಇನ್ನು ಮುಂದೆ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ತರ್ಕವನ್ನು ಅವಲಂಬಿಸುವುದಿಲ್ಲ. ಅಪ್ಲಿಕೇಶನ್ ಡೆವಲಪರ್‌ಗಳು ತಮ್ಮನ್ನು ಮರುತರಬೇತಿಗೊಳಿಸುತ್ತಿದ್ದಾರೆ ಮತ್ತು ತಮ್ಮದೇ ಕೋಡ್‌ನಲ್ಲಿ ಸಕ್ರಿಯವಾಗಿ ಮುನ್ನೆಚ್ಚರಿಕೆಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದಾರೆ. ಡೇಟಾ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಸಂಸ್ಕರಣೆಯ ಆದರ್ಶ ಸ್ಪಷ್ಟ ಪ್ರತ್ಯೇಕತೆ.
ನಾವು DataStax ನಿಂದ ಬೆಂಬಲವನ್ನು ಖರೀದಿಸಿದ್ದೇವೆ. ಪೆಟ್ಟಿಗೆಯ ಕಸ್ಸಂದ್ರದ ಅಭಿವೃದ್ಧಿಯು ಈಗಾಗಲೇ ಸ್ಥಗಿತಗೊಂಡಿದೆ (ಕೊನೆಯ ಕಮಿಟ್ ಫೆಬ್ರವರಿ 2018 ರಲ್ಲಿ). ಅದೇ ಸಮಯದಲ್ಲಿ, ಡೇಟಾಸ್ಟ್ಯಾಕ್ಸ್ ಅತ್ಯುತ್ತಮ ಸೇವೆಯನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ IP ಪರಿಹಾರಗಳಿಗಾಗಿ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಮಾರ್ಪಡಿಸಿದ ಮತ್ತು ಅಳವಡಿಸಿಕೊಂಡ ಪರಿಹಾರಗಳನ್ನು ನೀಡುತ್ತದೆ.
ಆಯ್ಕೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಕಸ್ಸಂದ್ರ ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿಲ್ಲ ಎಂದು ನಾನು ಗಮನಿಸಲು ಬಯಸುತ್ತೇನೆ. ಸಹಜವಾಗಿ, CQL ಬಳಕೆದಾರರಿಗೆ ಒಂದು ದೊಡ್ಡ ಹೆಜ್ಜೆಯಾಗಿದೆ (ಟ್ರಿಫ್ಟ್ಗೆ ಹೋಲಿಸಿದರೆ). ಆದರೆ ನೀವು ಅಂತಹ ಅನುಕೂಲಕರ ಸೇರ್ಪಡೆಗಳಿಗೆ ಒಗ್ಗಿಕೊಂಡಿರುವ ಸಂಪೂರ್ಣ ವಿಭಾಗಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಯಾವುದೇ ಕ್ಷೇತ್ರದಿಂದ ಉಚಿತ ಫಿಲ್ಟರಿಂಗ್ ಮತ್ತು ಆಪ್ಟಿಮೈಸೇಶನ್ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಪ್ರಶ್ನಿಸಿದರೆ ಮತ್ತು ಈ ಇಲಾಖೆಗಳು ದೂರುಗಳು ಮತ್ತು ಅಪಘಾತಗಳನ್ನು ಪರಿಹರಿಸಲು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ಕಸ್ಸಂಡ್ರಾದಲ್ಲಿನ ಪರಿಹಾರವು ಅವರಿಗೆ ಪ್ರತಿಕೂಲ ಮತ್ತು ಮೂರ್ಖತನವನ್ನು ತೋರುತ್ತದೆ. ಮತ್ತು ನಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳು ಮಾದರಿಗಳನ್ನು ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ನಾವು ನಿರ್ಧರಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ.
ನಾವು ಎರಡು ಆಯ್ಕೆಗಳನ್ನು ಪರಿಗಣಿಸಿದ್ದೇವೆ. ಮೊದಲ ಆಯ್ಕೆಯಲ್ಲಿ, ನಾವು C* ನಲ್ಲಿ ಮಾತ್ರವಲ್ಲದೆ ಆರ್ಕೈವ್ ಮಾಡಿದ Oracle ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿಯೂ ಕರೆಗಳನ್ನು ಬರೆಯುತ್ತೇವೆ. ಕೇವಲ, C* ಗಿಂತ ಭಿನ್ನವಾಗಿ, ಈ ಡೇಟಾಬೇಸ್ ಪ್ರಸ್ತುತ ತಿಂಗಳಿಗೆ ಮಾತ್ರ ಕರೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ (ರೀಚಾರ್ಜಿಂಗ್ ಪ್ರಕರಣಗಳಿಗೆ ಸಾಕಷ್ಟು ಕರೆ ಶೇಖರಣಾ ಆಳ). ಇಲ್ಲಿ ನಾವು ತಕ್ಷಣವೇ ಈ ಕೆಳಗಿನ ಸಮಸ್ಯೆಯನ್ನು ನೋಡಿದ್ದೇವೆ: ನಾವು ಸಿಂಕ್ರೊನಸ್ ಆಗಿ ಬರೆದರೆ, ವೇಗದ ಅಳವಡಿಕೆಗೆ ಸಂಬಂಧಿಸಿದ ಸಿ * ನ ಎಲ್ಲಾ ಪ್ರಯೋಜನಗಳನ್ನು ನಾವು ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ; ನಾವು ಅಸಮಕಾಲಿಕವಾಗಿ ಬರೆದರೆ, ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಕರೆಗಳು ಒರಾಕಲ್‌ಗೆ ಬರುತ್ತವೆ ಎಂಬುದಕ್ಕೆ ಯಾವುದೇ ಗ್ಯಾರಂಟಿ ಇಲ್ಲ. ಒಂದು ಪ್ಲಸ್ ಇತ್ತು, ಆದರೆ ದೊಡ್ಡದು: ಕಾರ್ಯಾಚರಣೆಗಾಗಿ ಅದೇ ಪರಿಚಿತ PL/SQL ಡೆವಲಪರ್ ಉಳಿದಿದೆ, ಅಂದರೆ ನಾವು ಪ್ರಾಯೋಗಿಕವಾಗಿ "ಮುಂಭಾಗ" ಮಾದರಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತೇವೆ. ಪರ್ಯಾಯ ಆಯ್ಕೆ. C* ನಿಂದ ಕರೆಗಳನ್ನು ಇಳಿಸುವ, ಒರಾಕಲ್‌ನಲ್ಲಿನ ಅನುಗುಣವಾದ ಕೋಷ್ಟಕಗಳಿಂದ ಪುಷ್ಟೀಕರಣಕ್ಕಾಗಿ ಕೆಲವು ಡೇಟಾವನ್ನು ಎಳೆಯುವ ಕಾರ್ಯವಿಧಾನವನ್ನು ನಾವು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತೇವೆ, ಫಲಿತಾಂಶದ ಮಾದರಿಗಳನ್ನು ಸೇರಿಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ನಮಗೆ ನೀಡುತ್ತೇವೆ, ಅದನ್ನು ನಾವು ಹೇಗಾದರೂ ಬಳಸುತ್ತೇವೆ (ಹಿಂತಿರುಗಿಸಿ, ಪುನರಾವರ್ತಿಸಿ, ವಿಶ್ಲೇಷಿಸಿ, ಮೆಚ್ಚಿಕೊಳ್ಳಿ). ಕಾನ್ಸ್: ಪ್ರಕ್ರಿಯೆಯು ಸಾಕಷ್ಟು ಬಹು-ಹಂತವಾಗಿದೆ, ಮತ್ತು ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕಾರ್ಯಾಚರಣೆಯ ಉದ್ಯೋಗಿಗಳಿಗೆ ಯಾವುದೇ ಇಂಟರ್ಫೇಸ್ ಇಲ್ಲ.
ಕೊನೆಯಲ್ಲಿ, ನಾವು ಎರಡನೇ ಆಯ್ಕೆಯಲ್ಲಿ ನೆಲೆಸಿದ್ದೇವೆ. ಅಪಾಚೆ ಸ್ಪಾರ್ಕ್ ಅನ್ನು ವಿವಿಧ ಜಾರ್‌ಗಳಿಂದ ಸ್ಯಾಂಪಲ್ ಮಾಡಲು ಬಳಸಲಾಗಿದೆ. ಯಾಂತ್ರಿಕತೆಯ ಸಾರವನ್ನು ಜಾವಾ ಕೋಡ್‌ಗೆ ಕಡಿಮೆ ಮಾಡಲಾಗಿದೆ, ಇದು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಕೀಗಳನ್ನು (ಚಂದಾದಾರರು, ಕರೆ ಸಮಯ - ವಿಭಾಗ ಕೀಗಳು) ಬಳಸಿ, ಸಿ * ನಿಂದ ಡೇಟಾವನ್ನು ಎಳೆಯುತ್ತದೆ, ಜೊತೆಗೆ ಯಾವುದೇ ಇತರ ಡೇಟಾಬೇಸ್‌ನಿಂದ ಪುಷ್ಟೀಕರಣಕ್ಕೆ ಅಗತ್ಯವಾದ ಡೇಟಾವನ್ನು ಎಳೆಯುತ್ತದೆ. ಅದರ ನಂತರ ಅದು ಅವುಗಳನ್ನು ತನ್ನ ಸ್ಮರಣೆಯಲ್ಲಿ ಸೇರಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಫಲಿತಾಂಶದ ಕೋಷ್ಟಕದಲ್ಲಿ ಫಲಿತಾಂಶವನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ. ನಾವು ಸ್ಪಾರ್ಕ್ ಮೇಲೆ ವೆಬ್ ಮುಖವನ್ನು ಚಿತ್ರಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದು ಸಾಕಷ್ಟು ಬಳಸಬಹುದಾಗಿದೆ.
ಕೈಗಾರಿಕಾ ಪರೀಕ್ಷಾ ಡೇಟಾವನ್ನು ನವೀಕರಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವಾಗ, ನಾವು ಮತ್ತೆ ಹಲವಾರು ಪರಿಹಾರಗಳನ್ನು ಪರಿಗಣಿಸಿದ್ದೇವೆ. Sstloader ಮೂಲಕ ವರ್ಗಾವಣೆ ಮತ್ತು ಪರೀಕ್ಷಾ ವಲಯದಲ್ಲಿನ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಎರಡು ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸುವ ಆಯ್ಕೆ, ಪ್ರತಿಯೊಂದೂ ಪ್ರಚಾರದ ಜೊತೆಗೆ ಅದೇ ಕ್ಲಸ್ಟರ್‌ಗೆ ಪರ್ಯಾಯವಾಗಿ ಸೇರಿದೆ, ಹೀಗಾಗಿ ಅದರ ಮೂಲಕ ಶಕ್ತಿಯನ್ನು ಪಡೆಯಲಾಗುತ್ತದೆ. ಪರೀಕ್ಷೆಯನ್ನು ನವೀಕರಿಸುವಾಗ, ಅವುಗಳನ್ನು ಸ್ವ್ಯಾಪ್ ಮಾಡಲು ಯೋಜಿಸಲಾಗಿದೆ: ಪರೀಕ್ಷೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ ಭಾಗವನ್ನು ತೆರವುಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಉತ್ಪಾದನೆಗೆ ಪ್ರವೇಶಿಸಲಾಗಿದೆ, ಮತ್ತು ಇತರವು ಪ್ರತ್ಯೇಕವಾಗಿ ಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಮತ್ತೊಮ್ಮೆ ಯೋಚಿಸಿದ ನಂತರ, ವರ್ಗಾವಣೆಗೆ ಯೋಗ್ಯವಾದ ಡೇಟಾವನ್ನು ನಾವು ಹೆಚ್ಚು ತರ್ಕಬದ್ಧವಾಗಿ ನಿರ್ಣಯಿಸಿದ್ದೇವೆ ಮತ್ತು ಕರೆಗಳು ಪರೀಕ್ಷೆಗಳಿಗೆ ಅಸಮಂಜಸವಾದ ಘಟಕವಾಗಿದೆ ಎಂದು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ, ಅಗತ್ಯವಿದ್ದರೆ ತ್ವರಿತವಾಗಿ ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ಇದು ಪ್ರಚಾರದ ಡೇಟಾ ಸೆಟ್ ಆಗಿದೆ. ಪರೀಕ್ಷೆ. ಚಲಿಸಲು ಯೋಗ್ಯವಾದ ಹಲವಾರು ಶೇಖರಣಾ ವಸ್ತುಗಳು ಇವೆ, ಆದರೆ ಇವು ಅಕ್ಷರಶಃ ಒಂದೆರಡು ಕೋಷ್ಟಕಗಳು ಮತ್ತು ತುಂಬಾ ಭಾರವಾದವುಗಳಲ್ಲ. ಆದ್ದರಿಂದ ನಾವು ಪರಿಹಾರವಾಗಿ, ಸ್ಪಾರ್ಕ್ ಮತ್ತೆ ರಕ್ಷಣೆಗೆ ಬಂದಿತು, ಅದರ ಸಹಾಯದಿಂದ ನಾವು ಬರೆದಿದ್ದೇವೆ ಮತ್ತು ಕೋಷ್ಟಕಗಳು, ಪ್ರಾಮ್-ಟೆಸ್ಟ್ ನಡುವೆ ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸಲು ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸಕ್ರಿಯವಾಗಿ ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ.
ನಮ್ಮ ಪ್ರಸ್ತುತ ನಿಯೋಜನೆ ನೀತಿಯು ರೋಲ್ಬ್ಯಾಕ್ ಇಲ್ಲದೆ ಕೆಲಸ ಮಾಡಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಪ್ರಚಾರದ ಮೊದಲು, ಕಡ್ಡಾಯ ಪರೀಕ್ಷಾ ರನ್ ಇದೆ, ಅಲ್ಲಿ ತಪ್ಪು ತುಂಬಾ ದುಬಾರಿ ಅಲ್ಲ. ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಯಾವಾಗಲೂ ಕೇಸ್‌ಸ್ಪೇಸ್ ಅನ್ನು ಬಿಡಬಹುದು ಮತ್ತು ಮೊದಲಿನಿಂದಲೂ ಸಂಪೂರ್ಣ ಸ್ಕೀಮ್ ಅನ್ನು ರೋಲ್ ಮಾಡಬಹುದು.
ಕಸ್ಸಂದ್ರದ ನಿರಂತರ ಲಭ್ಯತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ನಿಮಗೆ ಡಿಬಿಎ ಬೇಕು ಮತ್ತು ಅವನಿಗೆ ಮಾತ್ರವಲ್ಲ. ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಪ್ರತಿಯೊಬ್ಬರೂ ಪ್ರಸ್ತುತ ಪರಿಸ್ಥಿತಿಯನ್ನು ಎಲ್ಲಿ ಮತ್ತು ಹೇಗೆ ನೋಡಬೇಕು ಮತ್ತು ಸಕಾಲಿಕ ವಿಧಾನದಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ಹೇಗೆ ನಿವಾರಿಸಬೇಕು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಇದನ್ನು ಮಾಡಲು, ನಾವು ಸಕ್ರಿಯವಾಗಿ DataStax OpsCenter (ಕೆಲಸದ ಹೊರೆಗಳ ಆಡಳಿತ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ), ಕಸ್ಸಂದ್ರ ಡ್ರೈವರ್ ಸಿಸ್ಟಮ್ ಮೆಟ್ರಿಕ್ಸ್ (C* ಗೆ ಬರೆಯಲು ಸಮಯ ಮೀರುವ ಸಂಖ್ಯೆ, C* ನಿಂದ ಓದಲು ಸಮಯ ಮೀರುವ ಸಂಖ್ಯೆ, ಗರಿಷ್ಠ ಲೇಟೆನ್ಸಿ, ಇತ್ಯಾದಿ), ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೇವೆ. ಅಪ್ಲಿಕೇಶನ್ ಸ್ವತಃ, ಕಸ್ಸಂದ್ರ ಜೊತೆ ಕೆಲಸ.
ಹಿಂದಿನ ಪ್ರಶ್ನೆಯ ಬಗ್ಗೆ ನಾವು ಯೋಚಿಸಿದಾಗ, ನಮ್ಮ ಮುಖ್ಯ ಅಪಾಯ ಎಲ್ಲಿದೆ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡೆವು. ಇವುಗಳು ದತ್ತಾಂಶ ಪ್ರದರ್ಶನ ರೂಪಗಳಾಗಿದ್ದು, ಶೇಖರಣೆಗೆ ಹಲವಾರು ಸ್ವತಂತ್ರ ಪ್ರಶ್ನೆಗಳಿಂದ ಡೇಟಾವನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತವೆ. ಈ ರೀತಿಯಲ್ಲಿ ನಾವು ಸಾಕಷ್ಟು ಅಸಮಂಜಸ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಬಹುದು. ಆದರೆ ನಾವು ಕೇವಲ ಒಂದು ಡೇಟಾ ಸೆಂಟರ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದರೆ ಈ ಸಮಸ್ಯೆಯು ಪ್ರಸ್ತುತವಾಗಿರುತ್ತದೆ. ಆದ್ದರಿಂದ ಇಲ್ಲಿ ಅತ್ಯಂತ ಸಮಂಜಸವಾದ ವಿಷಯವೆಂದರೆ, ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಓದಲು ಬ್ಯಾಚ್ ಕಾರ್ಯವನ್ನು ರಚಿಸುವುದು, ಇದು ಒಂದೇ ಅವಧಿಯಲ್ಲಿ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಕಾರ್ಯಕ್ಷಮತೆಯ ದೃಷ್ಟಿಯಿಂದ ಓದುವಿಕೆ ಮತ್ತು ಬರವಣಿಗೆಗೆ ವಿಭಜನೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, DC ಗಳ ನಡುವಿನ ಕೆಲವು ಸಂಪರ್ಕದ ನಷ್ಟದೊಂದಿಗೆ, ನಾವು ಪರಸ್ಪರ ಸಂಪೂರ್ಣವಾಗಿ ಅಸಮಂಜಸವಾಗಿರುವ ಎರಡು ಕ್ಲಸ್ಟರ್‌ಗಳೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುವ ಅಪಾಯದಿಂದ ಇಲ್ಲಿ ನಾವು ನಿಲ್ಲಿಸಿದ್ದೇವೆ.
ಪರಿಣಾಮವಾಗಿ, ಸದ್ಯಕ್ಕೆ EACH_QUORUM ಬರೆಯಲು ಸ್ಥಿರತೆಯ ಮಟ್ಟದಲ್ಲಿ ನಿಲ್ಲಿಸಲಾಗಿದೆ, ಓದಲು - LOCAL_QUORUM
ಸಂಕ್ಷಿಪ್ತ ಅನಿಸಿಕೆಗಳು ಮತ್ತು ತೀರ್ಮಾನಗಳು
ಕಾರ್ಯಾಚರಣೆಯ ಬೆಂಬಲ ಮತ್ತು ಮುಂದಿನ ಅಭಿವೃದ್ಧಿಯ ನಿರೀಕ್ಷೆಗಳ ದೃಷ್ಟಿಕೋನದಿಂದ ಪರಿಣಾಮವಾಗಿ ಪರಿಹಾರವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು, ಅಂತಹ ಅಭಿವೃದ್ಧಿಯನ್ನು ಬೇರೆಲ್ಲಿ ಅನ್ವಯಿಸಬಹುದು ಎಂಬುದರ ಕುರಿತು ನಾವು ಯೋಚಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.
ಬ್ಯಾಟ್‌ನಿಂದಲೇ, ನಂತರ "ಅನುಕೂಲವಾದಾಗ ಪಾವತಿಸಿ" (ನಾವು ಮಾಹಿತಿಯನ್ನು ಸಿ* ಗೆ ಲೋಡ್ ಮಾಡುತ್ತೇವೆ, ಸ್ಪಾರ್ಕ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಲೆಕ್ಕಾಚಾರ), ಪ್ರದೇಶದ ಮೂಲಕ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಯೊಂದಿಗೆ ಕ್ಲೈಮ್‌ಗಳನ್ನು ಲೆಕ್ಕಹಾಕುವುದು, ಪಾತ್ರಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಮತ್ತು ಪಾತ್ರದ ಆಧಾರದ ಮೇಲೆ ಬಳಕೆದಾರರ ಪ್ರವೇಶ ಹಕ್ಕುಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವುದು ಮುಂತಾದ ಕಾರ್ಯಕ್ರಮಗಳಿಗೆ ಡೇಟಾ ಸ್ಕೋರಿಂಗ್ ಮ್ಯಾಟ್ರಿಕ್ಸ್.
ನೀವು ನೋಡುವಂತೆ, ಸಂಗ್ರಹವು ವಿಶಾಲ ಮತ್ತು ವೈವಿಧ್ಯಮಯವಾಗಿದೆ. ಮತ್ತು NoSQL ನ ಬೆಂಬಲಿಗರು/ವಿರೋಧಿಗಳ ಶಿಬಿರವನ್ನು ನಾವು ಆರಿಸಿಕೊಂಡರೆ, ನಾವು ನಮ್ಮ ಅನುಕೂಲಗಳನ್ನು ಪಡೆದಿರುವುದರಿಂದ ಮತ್ತು ನಾವು ನಿರೀಕ್ಷಿಸಿದ ಸ್ಥಳದಲ್ಲಿಯೇ ನಾವು ಬೆಂಬಲಿಗರನ್ನು ಸೇರುತ್ತೇವೆ.
ಪೆಟ್ಟಿಗೆಯಿಂದ ಹೊರಗಿರುವ ಕಸ್ಸಂದ್ರ ಆಯ್ಕೆಯು ನೈಜ ಸಮಯದಲ್ಲಿ ಸಮತಲ ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ಅನುಮತಿಸುತ್ತದೆ, ಸಿಸ್ಟಮ್ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಹೆಚ್ಚಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನೋವುರಹಿತವಾಗಿ ಪರಿಹರಿಸುತ್ತದೆ. ಕಸ್ಟಮ್ ಕೆಲಸಗಳು ಮತ್ತು ವಸ್ತುಗಳನ್ನು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿಯೇ ಬರೆಯುವ ಕೆಟ್ಟ ಅಭ್ಯಾಸವನ್ನು ತೊಡೆದುಹಾಕಲು, ಪ್ರತ್ಯೇಕ ಸರ್ಕ್ಯೂಟ್‌ಗೆ ಕರೆ ಸಮುಚ್ಚಯಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಸ್ಕೀಮಾ ಮತ್ತು ತರ್ಕವನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ನಾವು ಹೆಚ್ಚಿನ-ಲೋಡ್ ಕಾರ್ಯವಿಧಾನವನ್ನು ಸರಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ನಾವು ಆಯ್ಕೆ ಮಾಡಲು ಮತ್ತು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು, ವೇಗಗೊಳಿಸಲು, ಯಾವ DC ಗಳಲ್ಲಿ ನಾವು ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತೇವೆ ಮತ್ತು ಯಾವುದರಲ್ಲಿ ನಾವು ಡೇಟಾವನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡುತ್ತೇವೆ, ವೈಯಕ್ತಿಕ ನೋಡ್‌ಗಳು ಮತ್ತು ಒಟ್ಟಾರೆಯಾಗಿ DC ಎರಡರ ಕ್ರ್ಯಾಶ್‌ಗಳ ವಿರುದ್ಧ ನಾವೇ ವಿಮೆ ಮಾಡಿದ್ದೇವೆ.
ನಮ್ಮ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಹೊಸ ಯೋಜನೆಗಳಿಗೆ ಅನ್ವಯಿಸುವುದು ಮತ್ತು ಈಗಾಗಲೇ ಸ್ವಲ್ಪ ಅನುಭವವನ್ನು ಹೊಂದಿರುವುದರಿಂದ, ಮೇಲೆ ವಿವರಿಸಿದ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳನ್ನು ತಕ್ಷಣವೇ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಲು ಮತ್ತು ಕೆಲವು ತಪ್ಪುಗಳನ್ನು ತಡೆಯಲು, ಆರಂಭದಲ್ಲಿ ತಪ್ಪಿಸಲು ಸಾಧ್ಯವಾಗದ ಕೆಲವು ತೀಕ್ಷ್ಣವಾದ ಮೂಲೆಗಳನ್ನು ಸುಗಮಗೊಳಿಸಲು ನಾನು ಬಯಸುತ್ತೇನೆ.
ಉದಾಹರಣೆಗೆ, ಕಸ್ಸಂದ್ರದ ನವೀಕರಣಗಳನ್ನು ಸಮಯೋಚಿತವಾಗಿ ಟ್ರ್ಯಾಕ್ ಮಾಡಿಏಕೆಂದರೆ ನಮಗೆ ಸಿಕ್ಕಿರುವ ಕೆಲವು ಸಮಸ್ಯೆಗಳು ಈಗಾಗಲೇ ತಿಳಿದಿವೆ ಮತ್ತು ಪರಿಹರಿಸಲಾಗಿದೆ.
ಡೇಟಾಬೇಸ್ ಮತ್ತು ಸ್ಪಾರ್ಕ್ ಎರಡನ್ನೂ ಒಂದೇ ನೋಡ್‌ಗಳಲ್ಲಿ ಇರಿಸಬೇಡಿ (ಅಥವಾ ಅನುಮತಿಸುವ ಸಂಪನ್ಮೂಲ ಬಳಕೆಯ ಪ್ರಮಾಣದಿಂದ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಭಾಗಿಸಿ), ಏಕೆಂದರೆ ಸ್ಪಾರ್ಕ್ ನಿರೀಕ್ಷೆಗಿಂತ ಹೆಚ್ಚು OP ಅನ್ನು ತಿನ್ನಬಹುದು ಮತ್ತು ನಮ್ಮ ಪಟ್ಟಿಯಿಂದ ನಾವು ಸಮಸ್ಯೆ ಸಂಖ್ಯೆ 1 ಅನ್ನು ತ್ವರಿತವಾಗಿ ಪಡೆಯುತ್ತೇವೆ.
ಯೋಜನೆಯ ಪರೀಕ್ಷೆಯ ಹಂತದಲ್ಲಿ ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ಸಾಮರ್ಥ್ಯವನ್ನು ಸುಧಾರಿಸಿ. ಆರಂಭದಲ್ಲಿ, ನಮ್ಮ ಪರಿಹಾರದ ಎಲ್ಲಾ ಸಂಭಾವ್ಯ ಗ್ರಾಹಕರನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಿ, ಏಕೆಂದರೆ ಇದು ಡೇಟಾಬೇಸ್ ರಚನೆಯು ಅಂತಿಮವಾಗಿ ಅವಲಂಬಿಸಿರುತ್ತದೆ.
ಸಂಭವನೀಯ ಆಪ್ಟಿಮೈಸೇಶನ್ಗಾಗಿ ಪರಿಣಾಮವಾಗಿ ಸರ್ಕ್ಯೂಟ್ ಅನ್ನು ಹಲವಾರು ಬಾರಿ ತಿರುಗಿಸಿ. ಯಾವ ಕ್ಷೇತ್ರಗಳನ್ನು ಧಾರಾವಾಹಿ ಮಾಡಬಹುದೆಂದು ಆಯ್ಕೆಮಾಡಿ. ಹೆಚ್ಚು ಸರಿಯಾಗಿ ಮತ್ತು ಅತ್ಯುತ್ತಮವಾಗಿ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಲು ನಾವು ಯಾವ ಹೆಚ್ಚುವರಿ ಕೋಷ್ಟಕಗಳನ್ನು ಮಾಡಬೇಕು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ ಮತ್ತು ವಿನಂತಿಯ ಮೇರೆಗೆ ಅಗತ್ಯವಿರುವ ಮಾಹಿತಿಯನ್ನು ಒದಗಿಸಿ (ಉದಾಹರಣೆಗೆ, ನಾವು ಒಂದೇ ಡೇಟಾವನ್ನು ವಿಭಿನ್ನ ಕೋಷ್ಟಕಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಬಹುದು ಎಂದು ಭಾವಿಸುವ ಮೂಲಕ, ವಿಭಿನ್ನ ಸ್ಥಗಿತಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು ವಿಭಿನ್ನ ಮಾನದಂಡಗಳು, ಓದಲು ವಿನಂತಿಗಳಿಗಾಗಿ ನಾವು ಗಮನಾರ್ಹವಾಗಿ CPU ಸಮಯವನ್ನು ಉಳಿಸಬಹುದು).
ಕೆಟ್ಟದ್ದಲ್ಲ TTL ಅನ್ನು ಲಗತ್ತಿಸಲು ಮತ್ತು ಹಳೆಯ ಡೇಟಾವನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಲು ತಕ್ಷಣವೇ ಒದಗಿಸಿ.
ಕಸ್ಸಂದ್ರದಿಂದ ಡೇಟಾವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುವಾಗ ಅಪ್ಲಿಕೇಶನ್ ತರ್ಕವು FETCH ತತ್ವದ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು, ಆದ್ದರಿಂದ ಎಲ್ಲಾ ಸಾಲುಗಳನ್ನು ಒಮ್ಮೆ ಮೆಮೊರಿಗೆ ಲೋಡ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ಬ್ಯಾಚ್ಗಳಲ್ಲಿ ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ.
ವಿವರಿಸಿದ ಪರಿಹಾರಕ್ಕೆ ಯೋಜನೆಯನ್ನು ವರ್ಗಾಯಿಸುವ ಮೊದಲು ಸಲಹೆ ನೀಡಲಾಗುತ್ತದೆ ಕ್ರ್ಯಾಶ್ ಪರೀಕ್ಷೆಗಳ ಸರಣಿಯನ್ನು ನಡೆಸುವ ಮೂಲಕ ಸಿಸ್ಟಂನ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಒಂದು ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ ಡೇಟಾ ನಷ್ಟ, ನಿರ್ದಿಷ್ಟ ಅವಧಿಯಲ್ಲಿ ಹಾನಿಗೊಳಗಾದ ಡೇಟಾದ ಮರುಸ್ಥಾಪನೆ, ಡೇಟಾ ಕೇಂದ್ರಗಳ ನಡುವೆ ನೆಟ್ವರ್ಕ್ ಡ್ರಾಪ್ಔಟ್. ಅಂತಹ ಪರೀಕ್ಷೆಗಳು ಉದ್ದೇಶಿತ ವಾಸ್ತುಶಿಲ್ಪದ ಸಾಧಕ-ಬಾಧಕಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಮಾತ್ರ ಅನುಮತಿಸುವುದಿಲ್ಲ, ಆದರೆ ಅವುಗಳನ್ನು ನಡೆಸುವ ಎಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಉತ್ತಮ ಅಭ್ಯಾಸ ಅಭ್ಯಾಸವನ್ನು ಸಹ ನೀಡುತ್ತದೆ ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಸಿಸ್ಟಮ್ ವೈಫಲ್ಯಗಳನ್ನು ಪುನರುತ್ಪಾದಿಸಿದರೆ ಸ್ವಾಧೀನಪಡಿಸಿಕೊಂಡ ಕೌಶಲ್ಯವು ಅತಿಯಾಗಿರುವುದಿಲ್ಲ.
ನಾವು ನಿರ್ಣಾಯಕ ಮಾಹಿತಿಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದರೆ (ಬಿಲ್ಲಿಂಗ್ಗಾಗಿ ಡೇಟಾ, ಚಂದಾದಾರರ ಸಾಲದ ಲೆಕ್ಕಾಚಾರ), ನಂತರ DBMS ನ ವೈಶಿಷ್ಟ್ಯಗಳಿಂದ ಉಂಟಾಗುವ ಅಪಾಯಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಸಾಧನಗಳಿಗೆ ಗಮನ ಕೊಡುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ನೋಡ್‌ಸಿಂಕ್ ಉಪಯುಕ್ತತೆಯನ್ನು (ಡೇಟಾಸ್ಟ್ಯಾಕ್ಸ್) ಬಳಸಿ, ಅದರ ಬಳಕೆಗೆ ಸೂಕ್ತವಾದ ತಂತ್ರವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ನಂತರ ಸ್ಥಿರತೆಗಾಗಿ, ಕಸ್ಸಂದ್ರದ ಮೇಲೆ ಹೆಚ್ಚಿನ ಹೊರೆ ರಚಿಸಬೇಡಿ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಅವಧಿಯಲ್ಲಿ ಕೆಲವು ಕೋಷ್ಟಕಗಳಿಗೆ ಮಾತ್ರ ಇದನ್ನು ಬಳಸಿ.
ಆರು ತಿಂಗಳ ಜೀವನದ ನಂತರ ಕಸ್ಸಂಡ್ರಾಗೆ ಏನಾಗುತ್ತದೆ? ಸಾಮಾನ್ಯವಾಗಿ, ಪರಿಹರಿಸಲಾಗದ ಸಮಸ್ಯೆಗಳಿಲ್ಲ. ನಾವು ಯಾವುದೇ ಗಂಭೀರ ಅಪಘಾತಗಳು ಅಥವಾ ಡೇಟಾ ನಷ್ಟವನ್ನು ಸಹ ಅನುಮತಿಸಲಿಲ್ಲ. ಹೌದು, ಈ ಹಿಂದೆ ಉದ್ಭವಿಸದ ಕೆಲವು ಸಮಸ್ಯೆಗಳಿಗೆ ಸರಿದೂಗಿಸುವ ಬಗ್ಗೆ ನಾವು ಯೋಚಿಸಬೇಕಾಗಿತ್ತು, ಆದರೆ ಕೊನೆಯಲ್ಲಿ ಇದು ನಮ್ಮ ವಾಸ್ತುಶಿಲ್ಪದ ಪರಿಹಾರವನ್ನು ಹೆಚ್ಚು ಮರೆಮಾಡಲಿಲ್ಲ. ನೀವು ಬಯಸಿದರೆ ಮತ್ತು ಹೊಸದನ್ನು ಪ್ರಯತ್ನಿಸಲು ಭಯಪಡದಿದ್ದರೆ, ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ತುಂಬಾ ನಿರಾಶೆಗೊಳ್ಳಲು ಬಯಸದಿದ್ದರೆ, ಏನೂ ಉಚಿತವಲ್ಲ ಎಂಬ ಅಂಶಕ್ಕೆ ಸಿದ್ಧರಾಗಿ. ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು, ದಸ್ತಾವೇಜನ್ನು ಪರಿಶೀಲಿಸಬೇಕು ಮತ್ತು ಹಳೆಯ ಪರಂಪರೆಯ ಪರಿಹಾರಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ನಿಮ್ಮ ಸ್ವಂತ ವೈಯಕ್ತಿಕ ರೇಕ್ ಅನ್ನು ಜೋಡಿಸಬೇಕು ಮತ್ತು ಯಾವ ರೇಕ್ ನಿಮಗಾಗಿ ಕಾಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ಯಾವುದೇ ಸಿದ್ಧಾಂತವು ನಿಮಗೆ ಮುಂಚಿತವಾಗಿ ಹೇಳುವುದಿಲ್ಲ.
ಮೂಲ: www.habr.com