ಹಲೋ, ಖಬ್ರೋವ್ಸ್ಕ್ ನಿವಾಸಿಗಳು. ಕೋರ್ಸ್‌ನ ಮೊದಲ ಗುಂಪಿನ ತರಗತಿಗಳು ಇಂದಿನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತವೆ . ಈ ನಿಟ್ಟಿನಲ್ಲಿ, ಈ ಕೋರ್ಸ್‌ನಲ್ಲಿ ತೆರೆದ ವೆಬ್ನಾರ್ ಹೇಗೆ ನಡೆಯಿತು ಎಂಬುದರ ಕುರಿತು ನಾವು ನಿಮಗೆ ಹೇಳಲು ಬಯಸುತ್ತೇವೆ.
В ಮೋಡಗಳು ಮತ್ತು ಕುಬರ್ನೆಟ್‌ಗಳ ಯುಗದಲ್ಲಿ SQL ಡೇಟಾಬೇಸ್‌ಗಳು ಎದುರಿಸುತ್ತಿರುವ ಸವಾಲುಗಳ ಕುರಿತು ನಾವು ಮಾತನಾಡಿದ್ದೇವೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಈ ಸವಾಲುಗಳ ಪ್ರಭಾವದ ಅಡಿಯಲ್ಲಿ SQL ಡೇಟಾಬೇಸ್‌ಗಳು ಹೇಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ರೂಪಾಂತರಗೊಳ್ಳುತ್ತವೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡಿದ್ದೇವೆ.
ವೆಬ್ನಾರ್ ನಡೆಯಿತು , EPAM ಸಿಸ್ಟಂಗಳಲ್ಲಿ Google ಕ್ಲೌಡ್ ಪ್ರಾಕ್ಟೀಸ್ ಡೆಲಿವರಿ ಮ್ಯಾನೇಜರ್.
ಮರಗಳು ಚಿಕ್ಕದಾಗಿದ್ದಾಗ ...
ಮೊದಲಿಗೆ, ಕಳೆದ ಶತಮಾನದ ಕೊನೆಯಲ್ಲಿ DBMS ನ ಆಯ್ಕೆಯು ಹೇಗೆ ಪ್ರಾರಂಭವಾಯಿತು ಎಂಬುದನ್ನು ನೆನಪಿಸೋಣ. ಆದಾಗ್ಯೂ, ಇದು ಕಷ್ಟವಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಆ ದಿನಗಳಲ್ಲಿ DBMS ಆಯ್ಕೆಯು ಪ್ರಾರಂಭವಾಯಿತು ಮತ್ತು ಕೊನೆಗೊಂಡಿತು ಒರಾಕಲ್.
90 ರ ದಶಕದ ಕೊನೆಯಲ್ಲಿ ಮತ್ತು 2 ರ ದಶಕದ ಆರಂಭದಲ್ಲಿ, ಕೈಗಾರಿಕಾ ಸ್ಕೇಲೆಬಲ್ ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಬಂದಾಗ ಮೂಲಭೂತವಾಗಿ ಯಾವುದೇ ಆಯ್ಕೆ ಇರಲಿಲ್ಲ. ಹೌದು, IBM DBXNUMX, Sybase ಮತ್ತು ಕೆಲವು ಇತರ ಡೇಟಾಬೇಸ್‌ಗಳು ಬಂದು ಹೋದವು, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಅವು ಒರಾಕಲ್‌ನ ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಅಷ್ಟೊಂದು ಗಮನಿಸುವುದಿಲ್ಲ. ಅಂತೆಯೇ, ಆ ಕಾಲದ ಎಂಜಿನಿಯರ್‌ಗಳ ಕೌಶಲ್ಯಗಳು ಹೇಗಾದರೂ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದ ಏಕೈಕ ಆಯ್ಕೆಗೆ ಸಂಬಂಧಿಸಿವೆ.
ಒರಾಕಲ್ DBA ಗೆ ಸಾಧ್ಯವಾಗಬೇಕಿತ್ತು:
- ವಿತರಣಾ ಕಿಟ್‌ನಿಂದ ಒರಾಕಲ್ ಸರ್ವರ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿ;
- ಒರಾಕಲ್ ಸರ್ವರ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ:
- init.ora;
- ಕೇಳುಗ.ಓರ;
- ರಚಿಸಿ:
- ಟೇಬಲ್ಸ್ಪೇಸ್ಗಳು;
- ಯೋಜನೆ;
- ಬಳಕೆದಾರರು;
- ಬ್ಯಾಕ್ಅಪ್ ಮಾಡಿ ಮತ್ತು ಮರುಸ್ಥಾಪಿಸಿ;
- ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಕೈಗೊಳ್ಳಿ;
- ಉಪಸೂಕ್ತ ವಿನಂತಿಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸು.
ಅದೇ ಸಮಯದಲ್ಲಿ, ಒರಾಕಲ್ DBA ನಿಂದ ಯಾವುದೇ ವಿಶೇಷ ಅವಶ್ಯಕತೆ ಇರಲಿಲ್ಲ:
- ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಸೂಕ್ತವಾದ DBMS ಅಥವಾ ಇತರ ತಂತ್ರಜ್ಞಾನವನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ;
- ಹೆಚ್ಚಿನ ಲಭ್ಯತೆ ಮತ್ತು ಸಮತಲ ಸ್ಕೇಲೆಬಿಲಿಟಿ ಒದಗಿಸಿ (ಇದು ಯಾವಾಗಲೂ DBA ಸಮಸ್ಯೆಯಾಗಿರಲಿಲ್ಲ);
- ವಿಷಯದ ಪ್ರದೇಶದ ಉತ್ತಮ ಜ್ಞಾನ, ಮೂಲಸೌಕರ್ಯ, ಅಪ್ಲಿಕೇಶನ್ ಆರ್ಕಿಟೆಕ್ಚರ್, ಓಎಸ್;
- ಡೇಟಾವನ್ನು ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಅನ್‌ಲೋಡ್ ಮಾಡಿ, ವಿಭಿನ್ನ DBMS ಗಳ ನಡುವೆ ಡೇಟಾವನ್ನು ಸ್ಥಳಾಂತರಿಸಿ.
ಸಾಮಾನ್ಯವಾಗಿ, ಆ ದಿನಗಳಲ್ಲಿ ನಾವು ಆಯ್ಕೆಯ ಬಗ್ಗೆ ಮಾತನಾಡಿದರೆ, ಇದು 80 ರ ದಶಕದ ಉತ್ತರಾರ್ಧದಲ್ಲಿ ಸೋವಿಯತ್ ಅಂಗಡಿಯಲ್ಲಿನ ಆಯ್ಕೆಯನ್ನು ಹೋಲುತ್ತದೆ:
ನಮ್ಮ ಸಮಯ
ಅಂದಿನಿಂದ, ಸಹಜವಾಗಿ, ಮರಗಳು ಬೆಳೆದವು, ಜಗತ್ತು ಬದಲಾಗಿದೆ ಮತ್ತು ಅದು ಹೀಗಿದೆ:
ಗಾರ್ಟ್ನರ್‌ನ ಇತ್ತೀಚಿನ ವರದಿಯಿಂದ ಸ್ಪಷ್ಟವಾಗಿ ನೋಡಬಹುದಾದಂತೆ DBMS ಮಾರುಕಟ್ಟೆಯು ಸಹ ಬದಲಾಗಿದೆ:
ಮತ್ತು ಇಲ್ಲಿ ಜನಪ್ರಿಯತೆ ಬೆಳೆಯುತ್ತಿರುವ ಮೋಡಗಳು ತಮ್ಮ ಸ್ಥಾನವನ್ನು ಆಕ್ರಮಿಸಿಕೊಂಡಿವೆ ಎಂದು ಗಮನಿಸಬೇಕು. ನಾವು ಅದೇ ಗಾರ್ಟ್ನರ್ ವರದಿಯನ್ನು ಓದಿದರೆ, ನಾವು ಈ ಕೆಳಗಿನ ತೀರ್ಮಾನಗಳನ್ನು ನೋಡುತ್ತೇವೆ:
- ಅನೇಕ ಗ್ರಾಹಕರು ಕ್ಲೌಡ್‌ಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಚಲಿಸುವ ಹಾದಿಯಲ್ಲಿದ್ದಾರೆ.
- ಹೊಸ ತಂತ್ರಜ್ಞಾನಗಳು ಮೊದಲು ಮೋಡದಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಅವು ಎಂದಿಗೂ ಕ್ಲೌಡ್ ಅಲ್ಲದ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಚಲಿಸುತ್ತವೆ ಎಂಬುದು ಸತ್ಯವಲ್ಲ.
- ನೀವು ಹೋದಂತೆ ಪಾವತಿಸುವ ಬೆಲೆ ಮಾದರಿಯು ಸಾಮಾನ್ಯವಾಗಿದೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ತಾವು ಬಳಸುವುದಕ್ಕೆ ಮಾತ್ರ ಪಾವತಿಸಲು ಬಯಸುತ್ತಾರೆ, ಮತ್ತು ಇದು ಪ್ರವೃತ್ತಿಯೂ ಅಲ್ಲ, ಆದರೆ ಕೇವಲ ಸತ್ಯದ ಹೇಳಿಕೆ.
ಈಗೇನು?
ಇಂದು ನಾವೆಲ್ಲರೂ ಮೋಡದಲ್ಲಿದ್ದೇವೆ. ಮತ್ತು ನಮಗೆ ಉದ್ಭವಿಸುವ ಪ್ರಶ್ನೆಗಳು ಆಯ್ಕೆಯ ಪ್ರಶ್ನೆಗಳಾಗಿವೆ. ಮತ್ತು ಇದು ದೊಡ್ಡದಾಗಿದೆ, ನಾವು ಆನ್-ಆವರಣದ ಸ್ವರೂಪದಲ್ಲಿ DBMS ತಂತ್ರಜ್ಞಾನಗಳ ಆಯ್ಕೆಯ ಬಗ್ಗೆ ಮಾತ್ರ ಮಾತನಾಡಿದರೂ ಸಹ. ನಾವು ಸೇವೆಗಳು ಮತ್ತು SaaS ಅನ್ನು ಸಹ ನಿರ್ವಹಿಸಿದ್ದೇವೆ. ಹೀಗಾಗಿ, ಆಯ್ಕೆಯು ಪ್ರತಿ ವರ್ಷ ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗುತ್ತದೆ.
ಆಯ್ಕೆಯ ಪ್ರಶ್ನೆಗಳ ಜೊತೆಗೆ, ಸಹ ಇವೆ ಸೀಮಿತಗೊಳಿಸುವ ಅಂಶಗಳು:
- ಬೆಲೆ. ಅನೇಕ ತಂತ್ರಜ್ಞಾನಗಳು ಇನ್ನೂ ಹಣವನ್ನು ವೆಚ್ಚ ಮಾಡುತ್ತವೆ;
- ಕೌಶಲ್ಯಗಳು. ನಾವು ಉಚಿತ ಸಾಫ್ಟ್‌ವೇರ್ ಕುರಿತು ಮಾತನಾಡುತ್ತಿದ್ದರೆ, ಕೌಶಲ್ಯಗಳ ಪ್ರಶ್ನೆಯು ಉದ್ಭವಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಉಚಿತ ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ ಅದನ್ನು ನಿಯೋಜಿಸುವ ಮತ್ತು ನಿರ್ವಹಿಸುವ ಜನರಿಂದ ಸಾಕಷ್ಟು ಸಾಮರ್ಥ್ಯ ಬೇಕಾಗುತ್ತದೆ;
- ಕ್ರಿಯಾತ್ಮಕ. ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಲಭ್ಯವಿರುವ ಮತ್ತು ನಿರ್ಮಿಸಲಾದ ಎಲ್ಲಾ ಸೇವೆಗಳು, ಅದೇ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಲ್ಲಿಯೂ ಸಹ, ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಆನ್-ಆವರಣದಂತೆಯೇ ಒಂದೇ ರೀತಿಯ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಇದು ತಿಳಿಯಬೇಕಾದ ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕಾದ ಅತ್ಯಗತ್ಯ ಅಂಶವಾಗಿದೆ. ಇದಲ್ಲದೆ, ಒಂದೇ DBMS ನ ಕೆಲವು ಗುಪ್ತ ಸಾಮರ್ಥ್ಯಗಳ ಜ್ಞಾನಕ್ಕಿಂತ ಈ ಅಂಶವು ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿದೆ.
DA/DE ಯಿಂದ ಈಗ ಏನನ್ನು ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ:
- ವಿಷಯದ ಪ್ರದೇಶ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಉತ್ತಮ ತಿಳುವಳಿಕೆ;
- ಸರಿಯಾದ DBMS ತಂತ್ರಜ್ಞಾನವನ್ನು ಸರಿಯಾಗಿ ಆಯ್ಕೆ ಮಾಡುವ ಸಾಮರ್ಥ್ಯ, ಕೈಯಲ್ಲಿ ಕಾರ್ಯವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು;
- ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮಿತಿಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಆಯ್ದ ತಂತ್ರಜ್ಞಾನವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸೂಕ್ತವಾದ ವಿಧಾನವನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಸಾಮರ್ಥ್ಯ;
- ಡೇಟಾ ವರ್ಗಾವಣೆ ಮತ್ತು ವಲಸೆಯನ್ನು ನಿರ್ವಹಿಸುವ ಸಾಮರ್ಥ್ಯ;
- ಆಯ್ದ ಪರಿಹಾರಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮತ್ತು ನಿರ್ವಹಿಸುವ ಸಾಮರ್ಥ್ಯ.
ಕೆಳಗಿನ ಉದಾಹರಣೆ GCP ಆಧರಿಸಿ ಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಒಂದು ಅಥವಾ ಇನ್ನೊಂದು ತಂತ್ರಜ್ಞಾನದ ಆಯ್ಕೆಯು ಅದರ ರಚನೆಯನ್ನು ಅವಲಂಬಿಸಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ:
PostgreSQL ಅನ್ನು ಸ್ಕೀಮಾದಲ್ಲಿ ಸೇರಿಸಲಾಗಿಲ್ಲ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ, ಮತ್ತು ಇದು ಪರಿಭಾಷೆಯ ಅಡಿಯಲ್ಲಿ ಮರೆಮಾಡಲಾಗಿದೆ ಮೇಘ SQL. ಮತ್ತು ನಾವು ಕ್ಲೌಡ್ SQL ಗೆ ಬಂದಾಗ, ನಾವು ಮತ್ತೊಮ್ಮೆ ಆಯ್ಕೆ ಮಾಡಬೇಕಾಗಿದೆ:
ಈ ಆಯ್ಕೆಯು ಯಾವಾಗಲೂ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ ಎಂದು ಗಮನಿಸಬೇಕು, ಆದ್ದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಡೆವಲಪರ್ಗಳು ಹೆಚ್ಚಾಗಿ ಅಂತಃಪ್ರಜ್ಞೆಯಿಂದ ಮಾರ್ಗದರ್ಶನ ನೀಡುತ್ತಾರೆ.
ಒಟ್ಟು:
- ನೀವು ಮುಂದೆ ಹೋದಂತೆ, ಆಯ್ಕೆಯ ಪ್ರಶ್ನೆಯು ಹೆಚ್ಚು ಒತ್ತುತ್ತದೆ. ಮತ್ತು ನೀವು GCP, ನಿರ್ವಹಿಸಿದ ಸೇವೆಗಳು ಮತ್ತು SaaS ಅನ್ನು ಮಾತ್ರ ನೋಡಿದರೂ ಸಹ, RDBMS ನ ಕೆಲವು ಉಲ್ಲೇಖವು 4 ನೇ ಹಂತದಲ್ಲಿ ಮಾತ್ರ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ (ಮತ್ತು ಅಲ್ಲಿ ಸ್ಪ್ಯಾನರ್ ಹತ್ತಿರದಲ್ಲಿದೆ). ಜೊತೆಗೆ, PostgreSQL ನ ಆಯ್ಕೆಯು 5 ನೇ ಹಂತದಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅದರ ಪಕ್ಕದಲ್ಲಿ MySQL ಮತ್ತು SQL ಸರ್ವರ್ ಕೂಡ ಇವೆ, ಅಂದರೆ ಎಲ್ಲವೂ ಬಹಳಷ್ಟು ಇದೆ, ಆದರೆ ನೀವು ಆಯ್ಕೆ ಮಾಡಬೇಕು.
- ಪ್ರಲೋಭನೆಗಳ ಹಿನ್ನೆಲೆಯಲ್ಲಿ ನಿರ್ಬಂಧಗಳ ಬಗ್ಗೆ ನಾವು ಮರೆಯಬಾರದು. ಮೂಲಭೂತವಾಗಿ ಪ್ರತಿಯೊಬ್ಬರೂ ಸ್ಪ್ಯಾನರ್ ಅನ್ನು ಬಯಸುತ್ತಾರೆ, ಆದರೆ ಇದು ದುಬಾರಿಯಾಗಿದೆ. ಪರಿಣಾಮವಾಗಿ, ಒಂದು ವಿಶಿಷ್ಟ ವಿನಂತಿಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ: "ದಯವಿಟ್ಟು ನಮ್ಮನ್ನು ಸ್ಪ್ಯಾನರ್ ಮಾಡಿ ಆದರೆ ಕ್ಲೌಡ್ SQL ನ ಬೆಲೆಗೆ, ನೀವು ವೃತ್ತಿಪರರು!"
ನಾನು ಏನು ಮಾಡಲಿ?
ಅಂತಿಮ ಸತ್ಯವೆಂದು ಹೇಳಿಕೊಳ್ಳದೆ, ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಹೇಳೋಣ:
ನಾವು ಕಲಿಕೆಯ ವಿಧಾನವನ್ನು ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ:
- DBA ಗಳನ್ನು ಮೊದಲು ಕಲಿಸಿದ ರೀತಿಯಲ್ಲಿ ಕಲಿಸುವುದರಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ;
- ಒಂದು ಉತ್ಪನ್ನದ ಜ್ಞಾನವು ಇನ್ನು ಮುಂದೆ ಸಾಕಾಗುವುದಿಲ್ಲ;
- ಆದರೆ ಒಂದರ ಮಟ್ಟದಲ್ಲಿ ಡಜನ್‌ಗಳನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು ಅಸಾಧ್ಯ.
ಉತ್ಪನ್ನವು ಎಷ್ಟು ಎಂದು ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕು ಮತ್ತು ಅಲ್ಲ, ಆದರೆ:
- ಅದರ ಅಪ್ಲಿಕೇಶನ್ ಬಳಕೆಯ ಸಂದರ್ಭದಲ್ಲಿ;
- ವಿವಿಧ ನಿಯೋಜನೆ ವಿಧಾನಗಳು;
- ಪ್ರತಿ ವಿಧಾನದ ಅನುಕೂಲಗಳು ಮತ್ತು ಅನಾನುಕೂಲಗಳು;
- ತಿಳುವಳಿಕೆಯುಳ್ಳ ಮತ್ತು ಸೂಕ್ತವಾದ ಆಯ್ಕೆಯನ್ನು ಮಾಡಲು ಇದೇ ಮತ್ತು ಪರ್ಯಾಯ ಉತ್ಪನ್ನಗಳು ಮತ್ತು ಯಾವಾಗಲೂ ಪರಿಚಿತ ಉತ್ಪನ್ನದ ಪರವಾಗಿರುವುದಿಲ್ಲ.
ನೀವು ಡೇಟಾವನ್ನು ಸ್ಥಳಾಂತರಿಸಲು ಮತ್ತು ETL ನೊಂದಿಗೆ ಏಕೀಕರಣದ ಮೂಲ ತತ್ವಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ನಿಜವಾದ ಪ್ರಕರಣ
ಇತ್ತೀಚಿನ ದಿನಗಳಲ್ಲಿ, ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಾಗಿ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ರಚಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು. ಅದರ ಮೇಲೆ ಕೆಲಸ ಪ್ರಾರಂಭವಾಗುವ ಹೊತ್ತಿಗೆ, ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಈಗಾಗಲೇ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ ಮತ್ತು ಅನುಷ್ಠಾನಕ್ಕೆ ಸಿದ್ಧವಾಗಿದೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿ ತಂಡವು ಈ ಯೋಜನೆಯಲ್ಲಿ ಸುಮಾರು ಎರಡು ವರ್ಷಗಳನ್ನು ಕಳೆದಿದೆ. ಕೆಳಗಿನ ಕಾರ್ಯಗಳನ್ನು ಹೊಂದಿಸಲಾಗಿದೆ:
- CI/CD ನಿರ್ಮಿಸಿ;
- ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಪರಿಶೀಲಿಸಿ;
- ಎಲ್ಲವನ್ನೂ ಕಾರ್ಯರೂಪಕ್ಕೆ ತಂದರು.
ಅಪ್ಲಿಕೇಶನ್ ಸ್ವತಃ ಮೈಕ್ರೋಸರ್ವಿಸ್ ಆಗಿತ್ತು, ಮತ್ತು ಪೈಥಾನ್/ಜಾಂಗೊ ಕೋಡ್ ಅನ್ನು ಮೊದಲಿನಿಂದ ಮತ್ತು ನೇರವಾಗಿ GCP ಯಲ್ಲಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ. ಗುರಿ ಪ್ರೇಕ್ಷಕರಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಯುಎಸ್ ಮತ್ತು ಇಯು ಎಂಬ ಎರಡು ಪ್ರದೇಶಗಳು ಇರುತ್ತವೆ ಎಂದು ಭಾವಿಸಲಾಗಿದೆ ಮತ್ತು ಗ್ಲೋಬಲ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಮೂಲಕ ಸಂಚಾರವನ್ನು ವಿತರಿಸಲಾಯಿತು. ಎಲ್ಲಾ ವರ್ಕ್‌ಲೋಡ್‌ಗಳು ಮತ್ತು ಕಂಪ್ಯೂಟ್ ವರ್ಕ್‌ಲೋಡ್‌ಗಳು Google Kubernetes ಎಂಜಿನ್‌ನಲ್ಲಿ ರನ್ ಆಗಿವೆ.
ಡೇಟಾಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ, 3 ರಚನೆಗಳಿವೆ:
- ಮೇಘ ಸಂಗ್ರಹಣೆ;
- ಡೇಟಾ ಸ್ಟೋರ್;
- ಮೇಘ SQL (PostgreSQL).
ಕ್ಲೌಡ್ SQL ಅನ್ನು ಏಕೆ ಆಯ್ಕೆ ಮಾಡಲಾಗಿದೆ ಎಂದು ಒಬ್ಬರು ಆಶ್ಚರ್ಯಪಡಬಹುದು? ಸತ್ಯವನ್ನು ಹೇಳಲು, ಇತ್ತೀಚಿನ ವರ್ಷಗಳಲ್ಲಿ ಅಂತಹ ಪ್ರಶ್ನೆಯು ಕೆಲವು ರೀತಿಯ ವಿಚಿತ್ರವಾದ ವಿರಾಮವನ್ನು ಉಂಟುಮಾಡಿದೆ - ಜನರು ಸಂಬಂಧಿತ ಡೇಟಾಬೇಸ್‌ಗಳ ಬಗ್ಗೆ ನಾಚಿಕೆಪಡುತ್ತಾರೆ ಎಂಬ ಭಾವನೆ ಇದೆ, ಆದರೆ ಅದೇನೇ ಇದ್ದರೂ ಅವರು ಅವುಗಳನ್ನು ಸಕ್ರಿಯವಾಗಿ ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾರೆ ;-).
ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಕ್ಲೌಡ್ SQL ಅನ್ನು ಈ ಕೆಳಗಿನ ಕಾರಣಗಳಿಗಾಗಿ ಆಯ್ಕೆ ಮಾಡಲಾಗಿದೆ:
- ಹೇಳಿದಂತೆ, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಜಾಂಗೊ ಬಳಸಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ ಮತ್ತು ಇದು SQL ಡೇಟಾಬೇಸ್‌ನಿಂದ ಪೈಥಾನ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಿಗೆ (ಜಾಂಗೊ ORM) ನಿರಂತರ ಡೇಟಾವನ್ನು ಮ್ಯಾಪಿಂಗ್ ಮಾಡುವ ಮಾದರಿಯನ್ನು ಹೊಂದಿದೆ.
- ಫ್ರೇಮ್ವರ್ಕ್ ಸ್ವತಃ DBMS ಗಳ ಸಾಕಷ್ಟು ಸೀಮಿತ ಪಟ್ಟಿಯನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ:
- PostgreSQL;
- ಮರಿಯಾಡಿಬಿ;
- MySQL;
- ಒರಾಕಲ್;
- SQLite.
ಅಂತೆಯೇ, PostgreSQL ಅನ್ನು ಈ ಪಟ್ಟಿಯಿಂದ ಅರ್ಥಗರ್ಭಿತವಾಗಿ ಆಯ್ಕೆ ಮಾಡಲಾಗಿದೆ (ಅಲ್ಲದೆ, ಆಯ್ಕೆ ಮಾಡಲು ಇದು ಒರಾಕಲ್ ಅಲ್ಲ, ನಿಜವಾಗಿಯೂ).
ಏನು ಕಾಣೆಯಾಗಿದೆ:
- ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು 2 ಪ್ರದೇಶಗಳಲ್ಲಿ ಮಾತ್ರ ನಿಯೋಜಿಸಲಾಗಿದೆ ಮತ್ತು 3 ನೇ ಒಂದು ಯೋಜನೆಗಳಲ್ಲಿ (ಏಷ್ಯಾ) ಕಾಣಿಸಿಕೊಂಡಿದೆ;
- ದತ್ತಸಂಚಯವು ಉತ್ತರ ಅಮೆರಿಕಾದ ಪ್ರದೇಶದಲ್ಲಿ (ಅಯೋವಾ) ನೆಲೆಗೊಂಡಿದೆ;
- ಗ್ರಾಹಕರ ಕಡೆಯಿಂದ ಸಂಭವನೀಯತೆಯ ಬಗ್ಗೆ ಕಾಳಜಿ ಇತ್ತು ಪ್ರವೇಶ ವಿಳಂಬಗಳು ಯುರೋಪ್ ಮತ್ತು ಏಷ್ಯಾದಿಂದ ಮತ್ತು ಅಡಚಣೆಗಳು ಸೇವೆಯಲ್ಲಿ DBMS ಅಲಭ್ಯತೆಯ ಸಂದರ್ಭದಲ್ಲಿ.
ಜಾಂಗೊ ಸ್ವತಃ ಹಲವಾರು ಡೇಟಾಬೇಸ್‌ಗಳೊಂದಿಗೆ ಸಮಾನಾಂತರವಾಗಿ ಕೆಲಸ ಮಾಡಬಹುದು ಮತ್ತು ಅವುಗಳನ್ನು ಓದುವಿಕೆ ಮತ್ತು ಬರವಣಿಗೆಗೆ ವಿಭಜಿಸಬಹುದು ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ, ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಹೆಚ್ಚು ಬರವಣಿಗೆ ಇರಲಿಲ್ಲ (90% ಕ್ಕಿಂತ ಹೆಚ್ಚು ಓದುತ್ತಿದೆ). ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ, ಅದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಾದರೆ ಓದು-ಯುರೋಪ್ ಮತ್ತು ಏಷ್ಯಾದ ಮುಖ್ಯ ನೆಲೆಯ ಪ್ರತಿಕೃತಿ, ಇದು ರಾಜಿ ಪರಿಹಾರವಾಗಿದೆ. ಸರಿ, ಅದರಲ್ಲಿ ಏನು ಸಂಕೀರ್ಣವಾಗಿದೆ?
ಕಷ್ಟವೆಂದರೆ ಗ್ರಾಹಕರು ನಿರ್ವಹಿಸಿದ ಸೇವೆಗಳು ಮತ್ತು ಕ್ಲೌಡ್ SQL ಬಳಸುವುದನ್ನು ಬಿಟ್ಟುಕೊಡಲು ಬಯಸುವುದಿಲ್ಲ. ಮತ್ತು ಕ್ಲೌಡ್ SQL ನ ಸಾಮರ್ಥ್ಯಗಳು ಪ್ರಸ್ತುತ ಸೀಮಿತವಾಗಿವೆ. ಕ್ಲೌಡ್ SQL ಹೆಚ್ಚಿನ ಲಭ್ಯತೆ (HA) ಮತ್ತು ರೀಡ್ ರೆಪ್ಲಿಕಾ (RR) ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ, ಆದರೆ ಅದೇ RR ಅನ್ನು ಒಂದು ಪ್ರದೇಶದಲ್ಲಿ ಮಾತ್ರ ಬೆಂಬಲಿಸಲಾಗುತ್ತದೆ. ಅಮೇರಿಕನ್ ಪ್ರದೇಶದಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ರಚಿಸಿದ ನಂತರ, ಕ್ಲೌಡ್ SQL ಅನ್ನು ಬಳಸಿಕೊಂಡು ಯುರೋಪಿಯನ್ ಪ್ರದೇಶದಲ್ಲಿ ನೀವು ಓದುವ ಪ್ರತಿಕೃತಿಯನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದಾಗ್ಯೂ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಸ್ವತಃ ಇದನ್ನು ಮಾಡುವುದನ್ನು ತಡೆಯುವುದಿಲ್ಲ. Google ಉದ್ಯೋಗಿಗಳೊಂದಿಗಿನ ಪತ್ರವ್ಯವಹಾರವು ಎಲ್ಲಿಯೂ ನಡೆಯಲಿಲ್ಲ ಮತ್ತು "ನಮಗೆ ಸಮಸ್ಯೆ ತಿಳಿದಿದೆ ಮತ್ತು ಅದರ ಮೇಲೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ, ಒಂದು ದಿನ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲಾಗುವುದು" ಎಂಬ ಶೈಲಿಯಲ್ಲಿ ಭರವಸೆಗಳೊಂದಿಗೆ ಕೊನೆಗೊಂಡಿತು.
ನಾವು ಕ್ಲೌಡ್ SQL ನ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಪಟ್ಟಿ ಮಾಡಿದರೆ, ಅದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
1. ಹೆಚ್ಚಿನ ಲಭ್ಯತೆ (HA):
- ಒಂದು ಪ್ರದೇಶದೊಳಗೆ;
- ಡಿಸ್ಕ್ ಪುನರಾವರ್ತನೆಯ ಮೂಲಕ;
- PostgreSQL ಎಂಜಿನ್‌ಗಳನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ;
- ಸ್ವಯಂಚಾಲಿತ ಮತ್ತು ಹಸ್ತಚಾಲಿತ ನಿಯಂತ್ರಣ ಸಾಧ್ಯ - ವೈಫಲ್ಯ / ವೈಫಲ್ಯ;
- ಬದಲಾಯಿಸುವಾಗ, DBMS ಹಲವಾರು ನಿಮಿಷಗಳವರೆಗೆ ಲಭ್ಯವಿರುವುದಿಲ್ಲ.
2. ಪ್ರತಿಕೃತಿ (RR) ಓದಿ:
- ಒಂದು ಪ್ರದೇಶದೊಳಗೆ;
- ಬಿಸಿ ಸ್ಟ್ಯಾಂಡ್ಬೈ;
- PostgreSQL ಸ್ಟ್ರೀಮಿಂಗ್ ಪ್ರತಿಕೃತಿ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ವಾಡಿಕೆಯಂತೆ, ತಂತ್ರಜ್ಞಾನವನ್ನು ಆಯ್ಕೆಮಾಡುವಾಗ ನೀವು ಯಾವಾಗಲೂ ಕೆಲವನ್ನು ಎದುರಿಸುತ್ತೀರಿ ನಿರ್ಬಂಧಗಳು:
- GKE ಮೂಲಕ ಹೊರತುಪಡಿಸಿ, ಗ್ರಾಹಕರು ಘಟಕಗಳನ್ನು ರಚಿಸಲು ಮತ್ತು IaaS ಅನ್ನು ಬಳಸಲು ಬಯಸುವುದಿಲ್ಲ;
- ಗ್ರಾಹಕರು ಸ್ವಯಂ ಸೇವೆ PostgreSQL/MySQL ಅನ್ನು ನಿಯೋಜಿಸಲು ಬಯಸುವುದಿಲ್ಲ;
- ಒಳ್ಳೆಯದು, ಸಾಮಾನ್ಯವಾಗಿ, ಗೂಗಲ್ ಸ್ಪ್ಯಾನರ್ ಅದರ ಬೆಲೆಗೆ ಇಲ್ಲದಿದ್ದರೆ ಸಾಕಷ್ಟು ಸೂಕ್ತವಾಗಿದೆ, ಆದಾಗ್ಯೂ, ಜಾಂಗೊ ORM ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದರೆ ಇದು ಒಳ್ಳೆಯದು.
ಪರಿಸ್ಥಿತಿಯನ್ನು ಪರಿಗಣಿಸಿ, ಗ್ರಾಹಕರು ಮುಂದಿನ ಪ್ರಶ್ನೆಯನ್ನು ಸ್ವೀಕರಿಸಿದರು: "ನೀವು ಇದೇ ರೀತಿಯದ್ದನ್ನು ಮಾಡಬಹುದೇ ಆದ್ದರಿಂದ ಅದು ಗೂಗಲ್ ಸ್ಪ್ಯಾನರ್‌ನಂತೆ, ಆದರೆ ಜಾಂಗೊ ORM ನೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆಯೇ?"
ಪರಿಹಾರ ಆಯ್ಕೆ ಸಂಖ್ಯೆ. 0
ಮನಸ್ಸಿಗೆ ಬಂದ ಮೊದಲ ವಿಷಯ:
- CloudSQL ನಲ್ಲಿ ಉಳಿಯಿರಿ;
- ಯಾವುದೇ ರೂಪದಲ್ಲಿ ಪ್ರದೇಶಗಳ ನಡುವೆ ಅಂತರ್ನಿರ್ಮಿತ ಪ್ರತಿಕೃತಿ ಇರುವುದಿಲ್ಲ;
- PostgreSQL ಮೂಲಕ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕ್ಲೌಡ್ SQL ಗೆ ಪ್ರತಿಕೃತಿಯನ್ನು ಲಗತ್ತಿಸಲು ಪ್ರಯತ್ನಿಸಿ;
- ಎಲ್ಲೋ ಮತ್ತು ಹೇಗಾದರೂ ಒಂದು PostgreSQL ನಿದರ್ಶನವನ್ನು ಪ್ರಾರಂಭಿಸಿ, ಆದರೆ ಕನಿಷ್ಠ ಮಾಸ್ಟರ್ ಅನ್ನು ಮುಟ್ಟಬೇಡಿ.
ಅಯ್ಯೋ, ಇದನ್ನು ಮಾಡಲಾಗುವುದಿಲ್ಲ ಎಂದು ಅದು ಬದಲಾಯಿತು, ಏಕೆಂದರೆ ಹೋಸ್ಟ್ಗೆ ಯಾವುದೇ ಪ್ರವೇಶವಿಲ್ಲ (ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆ ಯೋಜನೆಯಲ್ಲಿದೆ) - pg_hba ಮತ್ತು ಹೀಗೆ, ಮತ್ತು ಸೂಪರ್ಯೂಸರ್ ಅಡಿಯಲ್ಲಿ ಯಾವುದೇ ಪ್ರವೇಶವಿಲ್ಲ.
ಪರಿಹಾರ ಆಯ್ಕೆ ಸಂಖ್ಯೆ. 1
ಹೆಚ್ಚಿನ ಪ್ರತಿಬಿಂಬದ ನಂತರ ಮತ್ತು ಹಿಂದಿನ ಸಂದರ್ಭಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡ ನಂತರ, ಚಿಂತನೆಯ ರೈಲು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಬದಲಾಯಿತು:
- ನಾವು ಇನ್ನೂ CloudSQL ನಲ್ಲಿ ಉಳಿಯಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ, ಆದರೆ ನಾವು MySQL ಗೆ ಬದಲಾಯಿಸುತ್ತಿದ್ದೇವೆ, ಏಕೆಂದರೆ MySQL ನಿಂದ ಕ್ಲೌಡ್ SQL ಬಾಹ್ಯ ಮಾಸ್ಟರ್ ಅನ್ನು ಹೊಂದಿದೆ, ಅದು:
- ಬಾಹ್ಯ MySQL ಗಾಗಿ ಪ್ರಾಕ್ಸಿ ಆಗಿದೆ;
- MySQL ನಿದರ್ಶನದಂತೆ ಕಾಣುತ್ತದೆ;
- ಇತರ ಮೋಡಗಳಿಂದ ಅಥವಾ ಆನ್-ಆವರಣದಿಂದ ಡೇಟಾವನ್ನು ಸ್ಥಳಾಂತರಿಸಲು ಕಂಡುಹಿಡಿಯಲಾಗಿದೆ.
MySQL ಪ್ರತಿಕೃತಿಯನ್ನು ಹೊಂದಿಸುವುದರಿಂದ ಹೋಸ್ಟ್ಗೆ ಪ್ರವೇಶ ಅಗತ್ಯವಿಲ್ಲ, ತಾತ್ವಿಕವಾಗಿ ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡಿದೆ, ಆದರೆ ಇದು ತುಂಬಾ ಅಸ್ಥಿರ ಮತ್ತು ಅನಾನುಕೂಲವಾಗಿದೆ. ಮತ್ತು ನಾವು ಮುಂದೆ ಹೋದಾಗ, ಅದು ಸಂಪೂರ್ಣವಾಗಿ ಭಯಾನಕವಾಯಿತು, ಏಕೆಂದರೆ ನಾವು ಸಂಪೂರ್ಣ ರಚನೆಯನ್ನು ಟೆರಾಫಾರ್ಮ್ನೊಂದಿಗೆ ನಿಯೋಜಿಸಿದ್ದೇವೆ ಮತ್ತು ಬಾಹ್ಯ ಮಾಸ್ಟರ್ ಅನ್ನು ಟೆರಾಫಾರ್ಮ್ನಿಂದ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ ಎಂದು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಅದು ಬದಲಾಯಿತು. ಹೌದು, Google CLI ಅನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ಕೆಲವು ಕಾರಣಗಳಿಂದಾಗಿ ಪ್ರತಿಯೊಂದೂ ಇಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ - ಕೆಲವೊಮ್ಮೆ ಇದನ್ನು ರಚಿಸಲಾಗಿದೆ, ಕೆಲವೊಮ್ಮೆ ಅದನ್ನು ರಚಿಸಲಾಗಿಲ್ಲ. ಬಹುಶಃ CLI ಅನ್ನು ಬಾಹ್ಯ ಡೇಟಾ ವಲಸೆಗಾಗಿ ಕಂಡುಹಿಡಿಯಲಾಗಿದೆ ಮತ್ತು ಪ್ರತಿಕೃತಿಗಳಿಗಾಗಿ ಅಲ್ಲ.
ವಾಸ್ತವವಾಗಿ, ಈ ಹಂತದಲ್ಲಿ ಕ್ಲೌಡ್ SQL ಸೂಕ್ತವಲ್ಲ ಎಂದು ಸ್ಪಷ್ಟವಾಯಿತು. ಅವರು ಹೇಳಿದಂತೆ, ನಾವು ಎಲ್ಲವನ್ನೂ ಮಾಡಿದ್ದೇವೆ.
ಪರಿಹಾರ ಆಯ್ಕೆ ಸಂಖ್ಯೆ. 2
ಕ್ಲೌಡ್ SQL ಚೌಕಟ್ಟಿನೊಳಗೆ ಉಳಿಯಲು ಸಾಧ್ಯವಾಗದ ಕಾರಣ, ನಾವು ರಾಜಿ ಪರಿಹಾರಕ್ಕಾಗಿ ಅವಶ್ಯಕತೆಗಳನ್ನು ರೂಪಿಸಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ. ಅವಶ್ಯಕತೆಗಳು ಈ ಕೆಳಗಿನಂತಿವೆ:
- ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಕೆಲಸ, ಸಂಪನ್ಮೂಲಗಳ ಗರಿಷ್ಠ ಬಳಕೆ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ (DCS, ...) ಮತ್ತು GCP (LB, ...) ಸಾಮರ್ಥ್ಯಗಳು;
- HA ಪ್ರಾಕ್ಸಿಯಂತಹ ಮೋಡದಲ್ಲಿನ ಅನಗತ್ಯ ವಸ್ತುಗಳ ಗುಂಪಿನಿಂದ ನಿಲುಭಾರದ ಕೊರತೆ;
- ಮುಖ್ಯ HA ಪ್ರದೇಶದಲ್ಲಿ PostgreSQL ಅಥವಾ MySQL ಅನ್ನು ಚಲಾಯಿಸುವ ಸಾಮರ್ಥ್ಯ; ಇತರ ಪ್ರದೇಶಗಳಲ್ಲಿ - ಮುಖ್ಯ ಪ್ರದೇಶದ RR ನಿಂದ HA ಜೊತೆಗೆ ಅದರ ನಕಲು (ವಿಶ್ವಾಸಾರ್ಹತೆಗಾಗಿ);
- ಬಹು ಮಾಸ್ಟರ್ (ನಾನು ಅವರನ್ನು ಸಂಪರ್ಕಿಸಲು ಬಯಸಲಿಲ್ಲ, ಆದರೆ ಅದು ತುಂಬಾ ಮುಖ್ಯವಾಗಿರಲಿಲ್ಲ)
.
ಈ ಬೇಡಿಕೆಗಳ ಪರಿಣಾಮವಾಗಿ, ಪಿಸೂಕ್ತವಾದ DBMS ಮತ್ತು ಬೈಂಡಿಂಗ್ ಆಯ್ಕೆಗಳು:
- MySQL ಗಲೇರಾ;
- ಜಿರಳೆ ಡಿಬಿ;
- PostgreSQL ಪರಿಕರಗಳು
:
- ಪಿಜಿಪೂಲ್-II;
- ಪತ್ರೋನಿ.
MySQL ಗಲೇರಾ
MySQL Galera ತಂತ್ರಜ್ಞಾನವನ್ನು ಕೋಡರ್‌ಶಿಪ್ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದೆ ಮತ್ತು ಇದು InnoDB ಗಾಗಿ ಪ್ಲಗಿನ್ ಆಗಿದೆ. ವಿಶೇಷತೆಗಳು:
- ಬಹು ಮಾಸ್ಟರ್;
- ಸಿಂಕ್ರೊನಸ್ ಪ್ರತಿಕೃತಿ;
- ಯಾವುದೇ ನೋಡ್ನಿಂದ ಓದುವುದು;
- ಯಾವುದೇ ನೋಡ್ಗೆ ರೆಕಾರ್ಡಿಂಗ್;
- ಅಂತರ್ನಿರ್ಮಿತ HA ಯಾಂತ್ರಿಕತೆ;
- ಬಿಟ್ನಾಮಿಯಿಂದ ಹೆಲ್ಮ್ ಚಾರ್ಟ್ ಇದೆ.
ಜಿರಳೆ ಡಿಬಿ
ವಿವರಣೆಯ ಪ್ರಕಾರ, ವಿಷಯವು ಸಂಪೂರ್ಣವಾಗಿ ಬಾಂಬ್ ಆಗಿದೆ ಮತ್ತು ಗೋದಲ್ಲಿ ಬರೆಯಲಾದ ಮುಕ್ತ ಮೂಲ ಯೋಜನೆಯಾಗಿದೆ. ಮುಖ್ಯ ಭಾಗವಹಿಸುವವರು ಜಿರಳೆ ಲ್ಯಾಬ್ಸ್ (Google ನಿಂದ ಜನರು ಸ್ಥಾಪಿಸಿದ್ದಾರೆ). ಈ ಸಂಬಂಧಿತ DBMS ಅನ್ನು ಮೂಲತಃ ವಿತರಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ (ಬಾಕ್ಸ್‌ನಿಂದ ಸಮತಲವಾದ ಸ್ಕೇಲಿಂಗ್‌ನೊಂದಿಗೆ) ಮತ್ತು ದೋಷ-ಸಹಿಷ್ಣುತೆ. ಕಂಪನಿಯ ಅದರ ಲೇಖಕರು "SQL ಕ್ರಿಯಾತ್ಮಕತೆಯ ಶ್ರೀಮಂತಿಕೆಯನ್ನು NoSQL ಪರಿಹಾರಗಳಿಗೆ ಪರಿಚಿತವಾಗಿರುವ ಸಮತಲ ಪ್ರವೇಶದೊಂದಿಗೆ ಸಂಯೋಜಿಸುವ" ಗುರಿಯನ್ನು ವಿವರಿಸಿದ್ದಾರೆ.
ಉತ್ತಮ ಬೋನಸ್ ಪೋಸ್ಟ್-ಗ್ರೆಸ್ ಸಂಪರ್ಕ ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ಬೆಂಬಲವಾಗಿದೆ.
ಪಿಜಿಪೂಲ್
ಇದು PostgreSQL ಗೆ ಆಡ್-ಆನ್ ಆಗಿದೆ, ವಾಸ್ತವವಾಗಿ, ಎಲ್ಲಾ ಸಂಪರ್ಕಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಮತ್ತು ಅವುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಹೊಸ ಘಟಕವಾಗಿದೆ. ಇದು ತನ್ನದೇ ಆದ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಮತ್ತು ಪಾರ್ಸರ್ ಅನ್ನು ಹೊಂದಿದೆ, BSD ಪರವಾನಗಿ ಅಡಿಯಲ್ಲಿ ಪರವಾನಗಿ ಪಡೆದಿದೆ. ಇದು ಸಾಕಷ್ಟು ಅವಕಾಶಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ, ಆದರೆ ಸ್ವಲ್ಪ ಭಯಾನಕವಾಗಿ ಕಾಣುತ್ತದೆ, ಏಕೆಂದರೆ ಹೊಸ ಘಟಕದ ಉಪಸ್ಥಿತಿಯು ಕೆಲವು ಹೆಚ್ಚುವರಿ ಸಾಹಸಗಳ ಮೂಲವಾಗಬಹುದು.
ಪತ್ರೋನಿ
ಇದು ನನ್ನ ಕಣ್ಣುಗಳ ಮೇಲೆ ಬಿದ್ದ ಕೊನೆಯ ವಿಷಯ, ಮತ್ತು ಅದು ಬದಲಾದಂತೆ, ವ್ಯರ್ಥವಾಗಿಲ್ಲ. Patroni ಒಂದು ಮುಕ್ತ ಮೂಲ ಉಪಯುಕ್ತತೆಯಾಗಿದೆ, ಇದು ಮೂಲಭೂತವಾಗಿ ಪೈಥಾನ್ ಡೀಮನ್ ಆಗಿದ್ದು ಅದು ವಿವಿಧ ರೀತಿಯ ಪ್ರತಿಕೃತಿ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ ಪಾತ್ರ ಸ್ವಿಚಿಂಗ್‌ನೊಂದಿಗೆ PostgreSQL ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿರ್ವಹಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ವಿಷಯವು ತುಂಬಾ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ, ಏಕೆಂದರೆ ಇದು ಕ್ಯೂಬರ್‌ನೊಂದಿಗೆ ಉತ್ತಮವಾಗಿ ಸಂಯೋಜಿಸುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ಹೊಸ ಘಟಕಗಳನ್ನು ಪರಿಚಯಿಸುವುದಿಲ್ಲ.
ಕೊನೆಯಲ್ಲಿ ನೀವು ಏನನ್ನು ಆರಿಸಿದ್ದೀರಿ?
ಆಯ್ಕೆಯು ಸುಲಭವಲ್ಲ:
- ಜಿರಳೆ ಡಿಬಿ - ಬೆಂಕಿ, ಆದರೆ ಕತ್ತಲೆ;
- MySQL ಗಲೇರಾ - ಸಹ ಕೆಟ್ಟದ್ದಲ್ಲ, ಇದನ್ನು ಅನೇಕ ಸ್ಥಳಗಳಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ, ಆದರೆ MySQL;
- ಪಿಜಿಪೂಲ್ - ಬಹಳಷ್ಟು ಅನಗತ್ಯ ಘಟಕಗಳು, ಆದ್ದರಿಂದ ಕ್ಲೌಡ್ ಮತ್ತು K8 ಗಳೊಂದಿಗೆ ಏಕೀಕರಣ;
- ಪತ್ರೋನಿ - K8s ನೊಂದಿಗೆ ಅತ್ಯುತ್ತಮ ಏಕೀಕರಣ, ಯಾವುದೇ ಅನಗತ್ಯ ಘಟಕಗಳಿಲ್ಲ, GCP LB ಯೊಂದಿಗೆ ಉತ್ತಮವಾಗಿ ಸಂಯೋಜಿಸುತ್ತದೆ.
ಹೀಗಾಗಿ, ಆಯ್ಕೆಯು ಪತ್ರೋನಿಯ ಮೇಲೆ ಬಿದ್ದಿತು.
ಸಂಶೋಧನೆಗಳು
ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳಲು ಇದು ಸಮಯ. ಹೌದು, ಐಟಿ ಮೂಲಸೌಕರ್ಯದ ಪ್ರಪಂಚವು ಗಮನಾರ್ಹವಾಗಿ ಬದಲಾಗಿದೆ ಮತ್ತು ಇದು ಕೇವಲ ಪ್ರಾರಂಭವಾಗಿದೆ. ಮತ್ತು ಮೊದಲು ಮೋಡಗಳು ಮತ್ತೊಂದು ರೀತಿಯ ಮೂಲಸೌಕರ್ಯವಾಗಿದ್ದರೆ, ಈಗ ಎಲ್ಲವೂ ವಿಭಿನ್ನವಾಗಿದೆ. ಇದಲ್ಲದೆ, ಮೋಡಗಳಲ್ಲಿನ ನಾವೀನ್ಯತೆಗಳು ನಿರಂತರವಾಗಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ, ಅವು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಬಹುಶಃ, ಅವು ಮೋಡಗಳಲ್ಲಿ ಮಾತ್ರ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ನಂತರ ಮಾತ್ರ, ಪ್ರಾರಂಭದ ಪ್ರಯತ್ನಗಳಿಂದ, ಅವುಗಳನ್ನು ಆನ್-ಆವರಣಕ್ಕೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ.
SQL ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, SQL ಜೀವಿಸುತ್ತದೆ. ಇದರರ್ಥ ನೀವು PostgreSQL ಮತ್ತು MySQL ಅನ್ನು ತಿಳಿದುಕೊಳ್ಳಬೇಕು ಮತ್ತು ಅವರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಆದರೆ ಅವುಗಳನ್ನು ಸರಿಯಾಗಿ ಬಳಸುವುದು ಇನ್ನೂ ಮುಖ್ಯವಾಗಿದೆ.
ಮೂಲ: www.habr.com