ಎಲ್ಲರಿಗು ನಮಸ್ಖರ! ನನ್ನ ಹೆಸರು ಗೊಲೊವ್ ನಿಕೊಲಾಯ್. ಹಿಂದೆ, ನಾನು Avito ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ್ದೇನೆ ಮತ್ತು ಆರು ವರ್ಷಗಳ ಕಾಲ ಡೇಟಾ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೆ, ಅಂದರೆ, ನಾನು ಎಲ್ಲಾ ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ್ದೇನೆ: ವಿಶ್ಲೇಷಣಾತ್ಮಕ (ವರ್ಟಿಕಾ, ಕ್ಲಿಕ್‌ಹೌಸ್), ಸ್ಟ್ರೀಮಿಂಗ್ ಮತ್ತು OLTP (ರೆಡಿಸ್, ಟರಾಂಟೂಲ್, ವೋಲ್ಟ್‌ಡಿಬಿ, ಮೊಂಗೋಡಿಬಿ, ಪೋಸ್ಟ್‌ಗ್ರೆಎಸ್‌ಕ್ಯುಎಲ್). ಈ ಸಮಯದಲ್ಲಿ, ನಾನು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಡೇಟಾಬೇಸ್‌ಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸಿದ್ದೇನೆ - ತುಂಬಾ ವಿಭಿನ್ನ ಮತ್ತು ಅಸಾಮಾನ್ಯ, ಮತ್ತು ಅವುಗಳ ಬಳಕೆಯ ಪ್ರಮಾಣಿತವಲ್ಲದ ಪ್ರಕರಣಗಳೊಂದಿಗೆ.
ನಾನು ಪ್ರಸ್ತುತ ManyChat ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇನೆ. ಮೂಲಭೂತವಾಗಿ, ಇದು ಪ್ರಾರಂಭವಾಗಿದೆ - ಹೊಸ, ಮಹತ್ವಾಕಾಂಕ್ಷೆಯ ಮತ್ತು ವೇಗವಾಗಿ ಬೆಳೆಯುತ್ತಿದೆ. ಮತ್ತು ನಾನು ಮೊದಲು ಕಂಪನಿಗೆ ಸೇರಿದಾಗ, ಒಂದು ಕ್ಲಾಸಿಕ್ ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸಿತು: "ಯುವ ಸ್ಟಾರ್ಟ್ಅಪ್ ಈಗ DBMS ಮತ್ತು ಡೇಟಾಬೇಸ್ ಮಾರುಕಟ್ಟೆಯಿಂದ ಏನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು?"
ಈ ಲೇಖನದಲ್ಲಿ, ನನ್ನ ವರದಿಯನ್ನು ಆಧರಿಸಿ , ನಾನು ಈ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತೇನೆ. ವರದಿಯ ವೀಡಿಯೊ ಆವೃತ್ತಿ ಲಭ್ಯವಿದೆ .
ಸಾಮಾನ್ಯವಾಗಿ ತಿಳಿದಿರುವ ಡೇಟಾಬೇಸ್ 2020
ಇದು 2020, ನಾನು ಸುತ್ತಲೂ ನೋಡಿದೆ ಮತ್ತು ಮೂರು ರೀತಿಯ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ನೋಡಿದೆ.
ಮೊದಲ ವಿಧ - ಕ್ಲಾಸಿಕ್ OLTP ಡೇಟಾಬೇಸ್‌ಗಳು: PostgreSQL, SQL ಸರ್ವರ್, ಒರಾಕಲ್, MySQL. ಅವುಗಳನ್ನು ಬಹಳ ಹಿಂದೆಯೇ ಬರೆಯಲಾಗಿದೆ, ಆದರೆ ಡೆವಲಪರ್ ಸಮುದಾಯಕ್ಕೆ ಅವು ತುಂಬಾ ಪರಿಚಿತವಾಗಿರುವ ಕಾರಣ ಇನ್ನೂ ಪ್ರಸ್ತುತವಾಗಿವೆ.
ಎರಡನೆಯ ವಿಧವಾಗಿದೆ "ಶೂನ್ಯ" ದಿಂದ ಆಧಾರಗಳು. ಅವರು ಅಂತರ್ನಿರ್ಮಿತ ಶಾರ್ಡಿಂಗ್ ಮತ್ತು ಇತರ ಆಕರ್ಷಕ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸೇರಿಸುವ ಮೂಲಕ SQL, ಸಾಂಪ್ರದಾಯಿಕ ರಚನೆಗಳು ಮತ್ತು ACID ಅನ್ನು ತ್ಯಜಿಸುವ ಮೂಲಕ ಕ್ಲಾಸಿಕ್ ಮಾದರಿಗಳಿಂದ ದೂರ ಸರಿಯಲು ಪ್ರಯತ್ನಿಸಿದರು. ಉದಾಹರಣೆಗೆ, ಇದು ಕಸ್ಸಂದ್ರ, ಮೊಂಗೋಡಿಬಿ, ರೆಡಿಸ್ ಅಥವಾ ಟ್ಯಾರಂಟೂಲ್. ಈ ಎಲ್ಲಾ ಪರಿಹಾರಗಳು ಮಾರುಕಟ್ಟೆಗೆ ಮೂಲಭೂತವಾಗಿ ಹೊಸದನ್ನು ನೀಡಲು ಬಯಸುತ್ತವೆ ಮತ್ತು ಅವುಗಳ ಸ್ಥಾನವನ್ನು ಆಕ್ರಮಿಸಿಕೊಂಡಿವೆ ಏಕೆಂದರೆ ಅವು ಕೆಲವು ಕಾರ್ಯಗಳಿಗೆ ಅತ್ಯಂತ ಅನುಕೂಲಕರವಾಗಿವೆ. ನಾನು ಈ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು NOSQL ಎಂಬ ಛತ್ರಿ ಪದದೊಂದಿಗೆ ಸೂಚಿಸುತ್ತೇನೆ.
“ಸೊನ್ನೆಗಳು” ಮುಗಿದಿವೆ, ನಾವು NOSQL ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಒಗ್ಗಿಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಪ್ರಪಂಚವು ನನ್ನ ದೃಷ್ಟಿಕೋನದಿಂದ ಮುಂದಿನ ಹಂತವನ್ನು ತೆಗೆದುಕೊಂಡಿತು - ಗೆ ನಿರ್ವಹಿಸಿದ ಡೇಟಾಬೇಸ್‌ಗಳು. ಈ ಡೇಟಾಬೇಸ್‌ಗಳು ಕ್ಲಾಸಿಕ್ OLTP ಡೇಟಾಬೇಸ್‌ಗಳು ಅಥವಾ ಹೊಸ NoSQL ಗಳಂತೆಯೇ ಕೋರ್ ಅನ್ನು ಹೊಂದಿವೆ. ಆದರೆ ಅವರಿಗೆ DBA ಮತ್ತು DevOps ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು ಕ್ಲೌಡ್‌ಗಳಲ್ಲಿ ನಿರ್ವಹಿಸಲಾದ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ರನ್ ಆಗುತ್ತದೆ. ಡೆವಲಪರ್‌ಗಾಗಿ, ಇದು ಎಲ್ಲೋ ಕೆಲಸ ಮಾಡುವ "ಕೇವಲ ಬೇಸ್" ಆಗಿದೆ, ಆದರೆ ಸರ್ವರ್‌ನಲ್ಲಿ ಅದನ್ನು ಹೇಗೆ ಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಯಾರು ಸರ್ವರ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದಾರೆ ಮತ್ತು ಅದನ್ನು ಯಾರು ನವೀಕರಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ಯಾರೂ ಕಾಳಜಿ ವಹಿಸುವುದಿಲ್ಲ.
ಅಂತಹ ಡೇಟಾಬೇಸ್‌ಗಳ ಉದಾಹರಣೆಗಳು:
- AWS RDS ಎನ್ನುವುದು PostgreSQL/MySQL ಗಾಗಿ ನಿರ್ವಹಿಸಲಾದ ಹೊದಿಕೆಯಾಗಿದೆ.
- DynamoDB ಎಂಬುದು ರೆಡಿಸ್ ಮತ್ತು ಮೊಂಗೋಡಿಬಿಯಂತೆಯೇ ಡಾಕ್ಯುಮೆಂಟ್ ಆಧಾರಿತ ಡೇಟಾಬೇಸ್‌ನ AWS ಅನಲಾಗ್ ಆಗಿದೆ.
- Amazon Redshift ಒಂದು ನಿರ್ವಹಿಸಲಾದ ವಿಶ್ಲೇಷಣಾತ್ಮಕ ಡೇಟಾಬೇಸ್ ಆಗಿದೆ.
ಇವುಗಳು ಮೂಲತಃ ಹಳೆಯ ಡೇಟಾಬೇಸ್‌ಗಳಾಗಿವೆ, ಆದರೆ ಹಾರ್ಡ್‌ವೇರ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲದೇ ನಿರ್ವಹಿಸಲಾದ ಪರಿಸರದಲ್ಲಿ ಬೆಳೆದವು.
ಸೂಚನೆ. ಉದಾಹರಣೆಗಳನ್ನು AWS ಪರಿಸರಕ್ಕೆ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ, ಆದರೆ ಅವುಗಳ ಅನಲಾಗ್‌ಗಳು Microsoft Azure, Google Cloud, ಅಥವಾ Yandex.Cloud ನಲ್ಲಿ ಸಹ ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ.
ಇದರಲ್ಲಿ ಹೊಸತೇನಿದೆ? 2020 ರಲ್ಲಿ, ಇದು ಯಾವುದೂ ಇಲ್ಲ.
ಸರ್ವರ್‌ಲೆಸ್ ಪರಿಕಲ್ಪನೆ
2020 ರಲ್ಲಿ ಮಾರುಕಟ್ಟೆಯಲ್ಲಿ ನಿಜವಾಗಿಯೂ ಹೊಸದೇನೆಂದರೆ ಸರ್ವರ್‌ಲೆಸ್ ಅಥವಾ ಸರ್ವರ್‌ಲೆಸ್ ಪರಿಹಾರಗಳು.
ಸಾಮಾನ್ಯ ಸೇವೆ ಅಥವಾ ಬ್ಯಾಕೆಂಡ್ ಅಪ್ಲಿಕೇಶನ್‌ನ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಇದರ ಅರ್ಥವನ್ನು ವಿವರಿಸಲು ನಾನು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ.
ನಿಯಮಿತ ಬ್ಯಾಕೆಂಡ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಯೋಜಿಸಲು, ನಾವು ಸರ್ವರ್ ಅನ್ನು ಖರೀದಿಸುತ್ತೇವೆ ಅಥವಾ ಬಾಡಿಗೆಗೆ ನೀಡುತ್ತೇವೆ, ಅದರ ಮೇಲೆ ಕೋಡ್ ಅನ್ನು ನಕಲಿಸುತ್ತೇವೆ, ಅಂತ್ಯಬಿಂದುವನ್ನು ಹೊರಗೆ ಪ್ರಕಟಿಸುತ್ತೇವೆ ಮತ್ತು ಬಾಡಿಗೆ, ವಿದ್ಯುತ್ ಮತ್ತು ಡೇಟಾ ಸೆಂಟರ್ ಸೇವೆಗಳಿಗೆ ನಿಯಮಿತವಾಗಿ ಪಾವತಿಸುತ್ತೇವೆ. ಇದು ಪ್ರಮಾಣಿತ ಯೋಜನೆಯಾಗಿದೆ.
ಬೇರೆ ದಾರಿ ಇದೆಯೇ? ಸರ್ವರ್‌ಲೆಸ್ ಸೇವೆಗಳೊಂದಿಗೆ ನೀವು ಮಾಡಬಹುದು.
ಈ ವಿಧಾನದ ಗಮನ ಏನು: ಯಾವುದೇ ಸರ್ವರ್ ಇಲ್ಲ, ಕ್ಲೌಡ್‌ನಲ್ಲಿ ವರ್ಚುವಲ್ ನಿದರ್ಶನವನ್ನು ಸಹ ಬಾಡಿಗೆಗೆ ನೀಡುವುದಿಲ್ಲ. ಸೇವೆಯನ್ನು ನಿಯೋಜಿಸಲು, ಕೋಡ್ (ಕಾರ್ಯಗಳು) ಅನ್ನು ರೆಪೊಸಿಟರಿಗೆ ನಕಲಿಸಿ ಮತ್ತು ಅದನ್ನು ಅಂತಿಮ ಬಿಂದುವಿಗೆ ಪ್ರಕಟಿಸಿ. ನಂತರ ನಾವು ಈ ಕಾರ್ಯಕ್ಕೆ ಪ್ರತಿ ಕರೆಗೆ ಸರಳವಾಗಿ ಪಾವತಿಸುತ್ತೇವೆ, ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಹಾರ್ಡ್‌ವೇರ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಲಕ್ಷಿಸುತ್ತೇವೆ.
ನಾನು ಈ ವಿಧಾನವನ್ನು ಚಿತ್ರಗಳೊಂದಿಗೆ ವಿವರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ.
ಕ್ಲಾಸಿಕ್ ನಿಯೋಜನೆ. ನಾವು ನಿರ್ದಿಷ್ಟ ಹೊರೆಯೊಂದಿಗೆ ಸೇವೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನಾವು ಎರಡು ನಿದರ್ಶನಗಳನ್ನು ಎತ್ತುತ್ತೇವೆ: ಭೌತಿಕ ಸರ್ವರ್ಗಳು ಅಥವಾ AWS ನಲ್ಲಿ ನಿದರ್ಶನಗಳು. ಬಾಹ್ಯ ವಿನಂತಿಗಳನ್ನು ಈ ನಿದರ್ಶನಗಳಿಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ.
ನೀವು ಚಿತ್ರದಲ್ಲಿ ನೋಡುವಂತೆ, ಸರ್ವರ್‌ಗಳನ್ನು ಸಮಾನವಾಗಿ ವಿಲೇವಾರಿ ಮಾಡಲಾಗುವುದಿಲ್ಲ. ಒಂದನ್ನು 100% ಬಳಸಲಾಗಿದೆ, ಎರಡು ವಿನಂತಿಗಳಿವೆ, ಮತ್ತು ಒಂದು ಕೇವಲ 50% - ಭಾಗಶಃ ನಿಷ್ಕ್ರಿಯವಾಗಿದೆ. ಮೂರು ವಿನಂತಿಗಳು ಬರದಿದ್ದರೆ, ಆದರೆ 30, ನಂತರ ಸಂಪೂರ್ಣ ಸಿಸ್ಟಮ್ ಲೋಡ್ ಅನ್ನು ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ ಮತ್ತು ನಿಧಾನವಾಗಲು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.
ಸರ್ವರ್‌ಲೆಸ್ ನಿಯೋಜನೆ. ಸರ್ವರ್‌ರಹಿತ ಪರಿಸರದಲ್ಲಿ, ಅಂತಹ ಸೇವೆಯು ನಿದರ್ಶನಗಳು ಅಥವಾ ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಬಿಸಿಯಾದ ಸಂಪನ್ಮೂಲಗಳ ಒಂದು ನಿರ್ದಿಷ್ಟ ಪೂಲ್ ಇದೆ - ನಿಯೋಜಿಸಲಾದ ಫಂಕ್ಷನ್ ಕೋಡ್‌ನೊಂದಿಗೆ ಸಣ್ಣ ಸಿದ್ಧಪಡಿಸಿದ ಡಾಕರ್ ಕಂಟೇನರ್‌ಗಳು. ಸಿಸ್ಟಮ್ ಬಾಹ್ಯ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಸರ್ವರ್‌ಲೆಸ್ ಫ್ರೇಮ್‌ವರ್ಕ್ ಕೋಡ್‌ನೊಂದಿಗೆ ಸಣ್ಣ ಧಾರಕವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ: ಇದು ಈ ನಿರ್ದಿಷ್ಟ ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಧಾರಕವನ್ನು ಕೊಲ್ಲುತ್ತದೆ.
ಒಂದು ವಿನಂತಿ - ಒಂದು ಕಂಟೇನರ್ ಏರಿಸಲಾಗಿದೆ, 1000 ವಿನಂತಿಗಳು - 1000 ಕಂಟೇನರ್‌ಗಳು. ಮತ್ತು ಹಾರ್ಡ್‌ವೇರ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ನಿಯೋಜನೆಯು ಈಗಾಗಲೇ ಕ್ಲೌಡ್ ಪ್ರೊವೈಡರ್‌ನ ಕೆಲಸವಾಗಿದೆ. ಇದು ಸರ್ವರ್‌ಲೆಸ್ ಫ್ರೇಮ್‌ವರ್ಕ್‌ನಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಮರೆಮಾಡಲ್ಪಟ್ಟಿದೆ. ಈ ಪರಿಕಲ್ಪನೆಯಲ್ಲಿ ನಾವು ಪ್ರತಿ ಕರೆಗೆ ಪಾವತಿಸುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, ದಿನಕ್ಕೆ ಒಂದು ಕರೆ ಬಂದಿತು - ನಾವು ಒಂದು ಕರೆಗೆ ಪಾವತಿಸಿದ್ದೇವೆ, ನಿಮಿಷಕ್ಕೆ ಮಿಲಿಯನ್ ಬಂದಿತು - ನಾವು ಮಿಲಿಯನ್‌ಗೆ ಪಾವತಿಸಿದ್ದೇವೆ. ಅಥವಾ ಒಂದು ಸೆಕೆಂಡಿನಲ್ಲಿ, ಇದು ಸಹ ಸಂಭವಿಸುತ್ತದೆ.
ಸರ್ವರ್‌ಲೆಸ್ ಕಾರ್ಯವನ್ನು ಪ್ರಕಟಿಸುವ ಪರಿಕಲ್ಪನೆಯು ಸ್ಥಿತಿಯಿಲ್ಲದ ಸೇವೆಗೆ ಸೂಕ್ತವಾಗಿದೆ. ಮತ್ತು ನಿಮಗೆ (ಸ್ಟೇಟ್) ಸ್ಟೇಟ್ಫುಲ್ ಸೇವೆಯ ಅಗತ್ಯವಿದ್ದರೆ, ನಾವು ಸೇವೆಗೆ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸೇರಿಸುತ್ತೇವೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ರಾಜ್ಯದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಬಂದಾಗ, ಪ್ರತಿ ಸ್ಟೇಟ್ಫುಲ್ ಕಾರ್ಯವು ಡೇಟಾಬೇಸ್‌ನಿಂದ ಸರಳವಾಗಿ ಬರೆಯುತ್ತದೆ ಮತ್ತು ಓದುತ್ತದೆ. ಇದಲ್ಲದೆ, ಲೇಖನದ ಆರಂಭದಲ್ಲಿ ವಿವರಿಸಿದ ಯಾವುದೇ ಮೂರು ಪ್ರಕಾರಗಳ ಡೇಟಾಬೇಸ್‌ನಿಂದ.
ಈ ಎಲ್ಲಾ ಡೇಟಾಬೇಸ್‌ಗಳ ಸಾಮಾನ್ಯ ಮಿತಿ ಏನು? ಇವು ನಿರಂತರವಾಗಿ ಬಳಸುವ ಕ್ಲೌಡ್ ಅಥವಾ ಹಾರ್ಡ್‌ವೇರ್ ಸರ್ವರ್‌ನ (ಅಥವಾ ಹಲವಾರು ಸರ್ವರ್ಗಳು) ವೆಚ್ಚಗಳಾಗಿವೆ. ನಾವು ಕ್ಲಾಸಿಕ್ ಅಥವಾ ಮ್ಯಾನೇಜ್ ಮಾಡಲಾದ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆಯೇ, ನಾವು Devops ಮತ್ತು ನಿರ್ವಾಹಕರನ್ನು ಹೊಂದಿದ್ದೇವೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದು ಮುಖ್ಯವಲ್ಲ, ನಾವು ಹಾರ್ಡ್‌ವೇರ್, ವಿದ್ಯುತ್ ಮತ್ತು ಡೇಟಾ ಸೆಂಟರ್ ಬಾಡಿಗೆಗೆ 24/7 ಪಾವತಿಸುತ್ತೇವೆ. ನಾವು ಕ್ಲಾಸಿಕ್ ಬೇಸ್ ಹೊಂದಿದ್ದರೆ, ನಾವು ಮಾಸ್ಟರ್ ಮತ್ತು ಗುಲಾಮರಿಗೆ ಪಾವತಿಸುತ್ತೇವೆ. ಇದು ಹೆಚ್ಚು ಲೋಡ್ ಮಾಡಲಾದ ಚೂರು ಡೇಟಾಬೇಸ್ ಆಗಿದ್ದರೆ, ನಾವು 10, 20 ಅಥವಾ 30 ಸರ್ವರ್‌ಗಳಿಗೆ ಪಾವತಿಸುತ್ತೇವೆ ಮತ್ತು ನಾವು ನಿರಂತರವಾಗಿ ಪಾವತಿಸುತ್ತೇವೆ.
ವೆಚ್ಚದ ರಚನೆಯಲ್ಲಿ ಶಾಶ್ವತವಾಗಿ ಕಾಯ್ದಿರಿಸಿದ ಸರ್ವರ್‌ಗಳ ಉಪಸ್ಥಿತಿಯು ಹಿಂದೆ ಅಗತ್ಯವಾದ ದುಷ್ಟ ಎಂದು ಗ್ರಹಿಸಲಾಗಿತ್ತು. ಸಾಂಪ್ರದಾಯಿಕ ಡೇಟಾಬೇಸ್‌ಗಳು ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆಯ ಮೇಲಿನ ಮಿತಿಗಳು, ಸ್ಕೇಲಿಂಗ್ ನಿರ್ಬಂಧಗಳು, ಜಿಯೋ-ವಿತರಣೆಯ ಒಮ್ಮತದಂತಹ ಇತರ ತೊಂದರೆಗಳನ್ನು ಸಹ ಹೊಂದಿವೆ - ಅವುಗಳನ್ನು ಹೇಗಾದರೂ ಕೆಲವು ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ ಪರಿಹರಿಸಬಹುದು, ಆದರೆ ಎಲ್ಲವನ್ನೂ ಒಂದೇ ಬಾರಿಗೆ ಅಲ್ಲ ಮತ್ತು ಆದರ್ಶಪ್ರಾಯವಲ್ಲ.
ಸರ್ವರ್‌ಲೆಸ್ ಡೇಟಾಬೇಸ್ - ಸಿದ್ಧಾಂತ
2020 ರ ಪ್ರಶ್ನೆ: ಡೇಟಾಬೇಸ್ ಸರ್ವರ್‌ಲೆಸ್ ಮಾಡಲು ಸಾಧ್ಯವೇ? ಸರ್ವರ್‌ಲೆಸ್ ಬ್ಯಾಕೆಂಡ್ ಬಗ್ಗೆ ಎಲ್ಲರೂ ಕೇಳಿದ್ದಾರೆ... ಡೇಟಾಬೇಸ್ ಸರ್ವರ್‌ಲೆಸ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸೋಣವೇ?
ಇದು ವಿಚಿತ್ರವೆನಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಡೇಟಾಬೇಸ್ ಸ್ಟೇಟ್ಫುಲ್ ಸೇವೆಯಾಗಿದೆ, ಸರ್ವರ್‌ಲೆಸ್ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಹೆಚ್ಚು ಸೂಕ್ತವಲ್ಲ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಡೇಟಾಬೇಸ್‌ನ ಸ್ಥಿತಿಯು ತುಂಬಾ ದೊಡ್ಡದಾಗಿದೆ: ಗಿಗಾಬೈಟ್‌ಗಳು, ಟೆರಾಬೈಟ್‌ಗಳು ಮತ್ತು ವಿಶ್ಲೇಷಣಾತ್ಮಕ ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ ಪೆಟಾಬೈಟ್‌ಗಳು ಸಹ. ಹಗುರವಾದ ಡಾಕರ್ ಕಂಟೈನರ್‌ಗಳಲ್ಲಿ ಅದನ್ನು ಬೆಳೆಸುವುದು ಅಷ್ಟು ಸುಲಭವಲ್ಲ.
ಮತ್ತೊಂದೆಡೆ, ಬಹುತೇಕ ಎಲ್ಲಾ ಆಧುನಿಕ ಡೇಟಾಬೇಸ್‌ಗಳು ದೊಡ್ಡ ಪ್ರಮಾಣದ ತರ್ಕ ಮತ್ತು ಘಟಕಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ: ವಹಿವಾಟುಗಳು, ಸಮಗ್ರತೆಯ ಸಮನ್ವಯ, ಕಾರ್ಯವಿಧಾನಗಳು, ಸಂಬಂಧಿತ ಅವಲಂಬನೆಗಳು ಮತ್ತು ಬಹಳಷ್ಟು ತರ್ಕಗಳು. ಸಾಕಷ್ಟು ಡೇಟಾಬೇಸ್ ತರ್ಕಕ್ಕಾಗಿ, ಒಂದು ಸಣ್ಣ ಸ್ಥಿತಿ ಸಾಕು. ಗಿಗಾಬೈಟ್‌ಗಳು ಮತ್ತು ಟೆರಾಬೈಟ್‌ಗಳನ್ನು ನೇರವಾಗಿ ಪ್ರಶ್ನೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಲ್ಲಿ ಒಳಗೊಂಡಿರುವ ಡೇಟಾಬೇಸ್ ಲಾಜಿಕ್‌ನ ಒಂದು ಸಣ್ಣ ಭಾಗದಿಂದ ನೇರವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.
ಅಂತೆಯೇ, ಕಲ್ಪನೆಯು: ತರ್ಕದ ಭಾಗವು ಸ್ಥಿತಿಯಿಲ್ಲದ ಮರಣದಂಡನೆಯನ್ನು ಅನುಮತಿಸಿದರೆ, ಬೇಸ್ ಅನ್ನು ಸ್ಟೇಟ್ಫುಲ್ ಮತ್ತು ಸ್ಟೇಟ್ಲೆಸ್ ಭಾಗಗಳಾಗಿ ಏಕೆ ವಿಭಜಿಸಬಾರದು.
OLAP ಪರಿಹಾರಗಳಿಗಾಗಿ ಸರ್ವರ್‌ಲೆಸ್
ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸ್ಟೇಟ್ಫುಲ್ ಮತ್ತು ಸ್ಟೇಟ್ಲೆಸ್ ಭಾಗಗಳಾಗಿ ಕತ್ತರಿಸುವುದು ಹೇಗೆ ಎಂದು ನೋಡೋಣ.
ಉದಾಹರಣೆಗೆ, ನಾವು ವಿಶ್ಲೇಷಣಾತ್ಮಕ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ: ಬಾಹ್ಯ ಡೇಟಾ (ಎಡಭಾಗದಲ್ಲಿ ಕೆಂಪು ಸಿಲಿಂಡರ್), ಡೇಟಾಬೇಸ್‌ಗೆ ಡೇಟಾವನ್ನು ಲೋಡ್ ಮಾಡುವ ETL ಪ್ರಕ್ರಿಯೆ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗೆ SQL ಪ್ರಶ್ನೆಗಳನ್ನು ಕಳುಹಿಸುವ ವಿಶ್ಲೇಷಕ. ಇದು ಕ್ಲಾಸಿಕ್ ಡೇಟಾ ಗೋದಾಮಿನ ಕಾರ್ಯಾಚರಣೆ ಯೋಜನೆಯಾಗಿದೆ.
ಈ ಯೋಜನೆಯಲ್ಲಿ, ETL ಅನ್ನು ಒಮ್ಮೆ ಷರತ್ತುಬದ್ಧವಾಗಿ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ. ನಂತರ ನೀವು ETL ತುಂಬಿದ ಡೇಟಾದೊಂದಿಗೆ ಡೇಟಾಬೇಸ್ ರನ್ ಆಗುವ ಸರ್ವರ್‌ಗಳಿಗೆ ನಿರಂತರವಾಗಿ ಪಾವತಿಸಬೇಕಾಗುತ್ತದೆ, ಇದರಿಂದಾಗಿ ಪ್ರಶ್ನೆಗಳನ್ನು ಕಳುಹಿಸಲು ಏನಾದರೂ ಇರುತ್ತದೆ.
AWS Athena Serverless ನಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿರುವ ಪರ್ಯಾಯ ವಿಧಾನವನ್ನು ನೋಡೋಣ. ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವ ಶಾಶ್ವತವಾಗಿ ಮೀಸಲಾದ ಹಾರ್ಡ್‌ವೇರ್ ಇಲ್ಲ. ಇದರ ಬದಲಾಗಿ:
- ಬಳಕೆದಾರರು ಅಥೇನಾಗೆ SQL ಪ್ರಶ್ನೆಯನ್ನು ಸಲ್ಲಿಸುತ್ತಾರೆ. ಅಥೇನಾ ಆಪ್ಟಿಮೈಜರ್ SQL ಪ್ರಶ್ನೆಯನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರಶ್ನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಅಗತ್ಯವಿರುವ ನಿರ್ದಿಷ್ಟ ಡೇಟಾಕ್ಕಾಗಿ ಮೆಟಾಡೇಟಾ ಸ್ಟೋರ್ (ಮೆಟಾಡೇಟಾ) ಅನ್ನು ಹುಡುಕುತ್ತದೆ.
- ಆಪ್ಟಿಮೈಜರ್, ಸಂಗ್ರಹಿಸಿದ ಡೇಟಾವನ್ನು ಆಧರಿಸಿ, ಅಗತ್ಯ ಡೇಟಾವನ್ನು ಬಾಹ್ಯ ಮೂಲಗಳಿಂದ ತಾತ್ಕಾಲಿಕ ಸಂಗ್ರಹಣೆಗೆ (ತಾತ್ಕಾಲಿಕ ಡೇಟಾಬೇಸ್) ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ.
- ಬಳಕೆದಾರರಿಂದ SQL ಪ್ರಶ್ನೆಯನ್ನು ತಾತ್ಕಾಲಿಕ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಬಳಕೆದಾರರಿಗೆ ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ.
- ತಾತ್ಕಾಲಿಕ ಸಂಗ್ರಹಣೆಯನ್ನು ತೆರವುಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲಾಗಿದೆ.
ಈ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ, ವಿನಂತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಪ್ರಕ್ರಿಯೆಗೆ ಮಾತ್ರ ನಾವು ಪಾವತಿಸುತ್ತೇವೆ. ಯಾವುದೇ ವಿನಂತಿಗಳಿಲ್ಲ - ಯಾವುದೇ ವೆಚ್ಚವಿಲ್ಲ.
ಇದು ಕಾರ್ಯ ವಿಧಾನವಾಗಿದೆ ಮತ್ತು ಅಥೇನಾ ಸರ್ವರ್‌ಲೆಸ್‌ನಲ್ಲಿ ಮಾತ್ರವಲ್ಲದೆ ರೆಡ್‌ಶಿಫ್ಟ್ ಸ್ಪೆಕ್ಟ್ರಮ್‌ನಲ್ಲಿಯೂ (AWS ನಲ್ಲಿ) ಅಳವಡಿಸಲಾಗಿದೆ.
ಹತ್ತಾರು ಮತ್ತು ನೂರಾರು ಟೆರಾಬೈಟ್‌ಗಳ ಡೇಟಾದೊಂದಿಗೆ ಸರ್ವರ್‌ಲೆಸ್ ಡೇಟಾಬೇಸ್ ನೈಜ ಪ್ರಶ್ನೆಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಅಥೇನಾ ಉದಾಹರಣೆ ತೋರಿಸುತ್ತದೆ. ನೂರಾರು ಟೆರಾಬೈಟ್‌ಗಳಿಗೆ ನೂರಾರು ಸರ್ವರ್ಗಳು ಬೇಕಾಗುತ್ತವೆ, ಆದರೆ ನಾವು ಅವುಗಳನ್ನು ಪಾವತಿಸಬೇಕಾಗಿಲ್ಲ - ನಾವು ವಿನಂತಿಗಳಿಗೆ ಪಾವತಿಸುತ್ತೇವೆ. ವರ್ಟಿಕಾದಂತಹ ವಿಶೇಷ ವಿಶ್ಲೇಷಣಾತ್ಮಕ ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಹೋಲಿಸಿದರೆ ಪ್ರತಿ ವಿನಂತಿಯ ವೇಗವು (ತುಂಬಾ) ಕಡಿಮೆಯಾಗಿದೆ, ಆದರೆ ನಾವು ಅಲಭ್ಯತೆಯ ಅವಧಿಗಳಿಗೆ ಪಾವತಿಸುವುದಿಲ್ಲ.
ಅಂತಹ ಡೇಟಾಬೇಸ್ ಅಪರೂಪದ ವಿಶ್ಲೇಷಣಾತ್ಮಕ ತಾತ್ಕಾಲಿಕ ಪ್ರಶ್ನೆಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ನಾವು ಸ್ವಯಂಪ್ರೇರಿತವಾಗಿ ಕೆಲವು ದೈತ್ಯಾಕಾರದ ಡೇಟಾದ ಮೇಲೆ ಊಹೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ನಿರ್ಧರಿಸಿದಾಗ. ಈ ಸಂದರ್ಭಗಳಲ್ಲಿ ಅಥೇನಾ ಪರಿಪೂರ್ಣವಾಗಿದೆ. ನಿಯಮಿತ ವಿನಂತಿಗಳಿಗಾಗಿ, ಅಂತಹ ವ್ಯವಸ್ಥೆಯು ದುಬಾರಿಯಾಗಿದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಕೆಲವು ವಿಶೇಷ ಪರಿಹಾರಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿ.
OLTP ಪರಿಹಾರಗಳಿಗಾಗಿ ಸರ್ವರ್‌ಲೆಸ್
ಹಿಂದಿನ ಉದಾಹರಣೆಯು OLAP (ವಿಶ್ಲೇಷಣಾತ್ಮಕ) ಕಾರ್ಯಗಳನ್ನು ನೋಡಿದೆ. ಈಗ OLTP ಕಾರ್ಯಗಳನ್ನು ನೋಡೋಣ.
ಸ್ಕೇಲೆಬಲ್ PostgreSQL ಅಥವಾ MySQL ಅನ್ನು ಊಹಿಸೋಣ. ಕನಿಷ್ಠ ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ನಿಯಮಿತ ನಿರ್ವಹಣೆಯ ನಿದರ್ಶನವನ್ನು PostgreSQL ಅಥವಾ MySQL ಅನ್ನು ಹೆಚ್ಚಿಸೋಣ. ನಿದರ್ಶನವು ಹೆಚ್ಚಿನ ಲೋಡ್ ಅನ್ನು ಪಡೆದಾಗ, ನಾವು ಓದುವ ಹೊರೆಯ ಭಾಗವನ್ನು ವಿತರಿಸುವ ಹೆಚ್ಚುವರಿ ಪ್ರತಿಕೃತಿಗಳನ್ನು ನಾವು ಸಂಪರ್ಕಿಸುತ್ತೇವೆ. ಯಾವುದೇ ವಿನಂತಿಗಳು ಅಥವಾ ಲೋಡ್ ಇಲ್ಲದಿದ್ದರೆ, ನಾವು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಆಫ್ ಮಾಡುತ್ತೇವೆ. ಮೊದಲ ನಿದರ್ಶನವು ಮಾಸ್ಟರ್, ಮತ್ತು ಉಳಿದವು ಪ್ರತಿಕೃತಿಗಳಾಗಿವೆ.
ಈ ಕಲ್ಪನೆಯನ್ನು ಅರೋರಾ ಸರ್ವರ್‌ಲೆಸ್ AWS ಎಂಬ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ. ತತ್ವ ಸರಳವಾಗಿದೆ: ಬಾಹ್ಯ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಂದ ವಿನಂತಿಗಳನ್ನು ಪ್ರಾಕ್ಸಿ ಫ್ಲೀಟ್ ಸ್ವೀಕರಿಸುತ್ತದೆ. ಲೋಡ್ ಹೆಚ್ಚಳವನ್ನು ನೋಡಿ, ಇದು ಪೂರ್ವ-ಬೆಚ್ಚಗಾಗುವ ಕನಿಷ್ಠ ನಿದರ್ಶನಗಳಿಂದ ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ - ಸಂಪರ್ಕವನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಮಾಡಲಾಗುತ್ತದೆ. ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ನಿದರ್ಶನಗಳು ಅದೇ ರೀತಿಯಲ್ಲಿ ಸಂಭವಿಸುತ್ತವೆ.
ಅರೋರಾದಲ್ಲಿ ಅರೋರಾ ಕೆಪಾಸಿಟಿ ಯುನಿಟ್, ಎಸಿಯು ಪರಿಕಲ್ಪನೆ ಇದೆ. ಇದು (ಷರತ್ತುಬದ್ಧವಾಗಿ) ಒಂದು ನಿದರ್ಶನ (ಸರ್ವರ್). ಪ್ರತಿಯೊಂದು ನಿರ್ದಿಷ್ಟ ACU ಮಾಸ್ಟರ್ ಅಥವಾ ಗುಲಾಮರಾಗಿರಬಹುದು. ಪ್ರತಿಯೊಂದು ಸಾಮರ್ಥ್ಯದ ಘಟಕವು ತನ್ನದೇ ಆದ RAM, ಪ್ರೊಸೆಸರ್ ಮತ್ತು ಕನಿಷ್ಠ ಡಿಸ್ಕ್ ಅನ್ನು ಹೊಂದಿದೆ. ಅದರಂತೆ, ಒಬ್ಬರು ಮಾಸ್ಟರ್, ಉಳಿದವರು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಮಾತ್ರ ಓದುತ್ತಾರೆ.
ಚಾಲನೆಯಲ್ಲಿರುವ ಈ ಅರೋರಾ ಸಾಮರ್ಥ್ಯದ ಘಟಕಗಳ ಸಂಖ್ಯೆಯು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದಾದ ನಿಯತಾಂಕವಾಗಿದೆ. ಕನಿಷ್ಠ ಪ್ರಮಾಣವು ಒಂದು ಅಥವಾ ಶೂನ್ಯವಾಗಿರಬಹುದು (ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಯಾವುದೇ ವಿನಂತಿಗಳಿಲ್ಲದಿದ್ದರೆ ಡೇಟಾಬೇಸ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ).
ಬೇಸ್ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ, ಪ್ರಾಕ್ಸಿ ಫ್ಲೀಟ್ ಅರೋರಾ ಕೆಪಾಸಿಟಿಯುನಿಟ್‌ಗಳನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ, ಸಿಸ್ಟಮ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೆಚ್ಚಿಸುವ ಮತ್ತು ಕಡಿಮೆ ಮಾಡುವ ಸಾಮರ್ಥ್ಯವು ಸಿಸ್ಟಮ್‌ಗೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು " ಕಣ್ಕಟ್ಟು" ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ: ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪ್ರತ್ಯೇಕ ACU ಗಳನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ (ಅವುಗಳನ್ನು ಹೊಸದರೊಂದಿಗೆ ಬದಲಾಯಿಸುವುದು) ಮತ್ತು ಹಿಂತೆಗೆದುಕೊಂಡ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಎಲ್ಲಾ ಪ್ರಸ್ತುತ ನವೀಕರಣಗಳನ್ನು ಹೊರತರುತ್ತದೆ.
ಅರೋರಾ ಸರ್ವರ್‌ಲೆಸ್ ಬೇಸ್ ಓದುವ ಲೋಡ್ ಅನ್ನು ಅಳೆಯಬಹುದು. ಆದರೆ ದಾಖಲೆಗಳು ಇದನ್ನು ನೇರವಾಗಿ ಹೇಳುವುದಿಲ್ಲ. ಅವರು ಬಹು-ಮಾಸ್ಟರ್ ಅನ್ನು ಎತ್ತಬಹುದು ಎಂದು ಅನಿಸಬಹುದು. ಮ್ಯಾಜಿಕ್ ಇಲ್ಲ.
ಈ ಡೇಟಾಬೇಸ್ ಅನಿರೀಕ್ಷಿತ ಪ್ರವೇಶದೊಂದಿಗೆ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ದೊಡ್ಡ ಪ್ರಮಾಣದ ಹಣವನ್ನು ಖರ್ಚು ಮಾಡುವುದನ್ನು ತಪ್ಪಿಸಲು ಸೂಕ್ತವಾಗಿರುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, MVP ರಚಿಸುವಾಗ ಅಥವಾ ವ್ಯಾಪಾರ ಕಾರ್ಡ್ ಸೈಟ್‌ಗಳನ್ನು ಮಾರ್ಕೆಟಿಂಗ್ ಮಾಡುವಾಗ, ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಸ್ಥಿರವಾದ ಲೋಡ್ ಅನ್ನು ನಿರೀಕ್ಷಿಸುವುದಿಲ್ಲ. ಅಂತೆಯೇ, ಯಾವುದೇ ಪ್ರವೇಶವಿಲ್ಲದಿದ್ದರೆ, ನಾವು ನಿದರ್ಶನಗಳಿಗೆ ಪಾವತಿಸುವುದಿಲ್ಲ. ಅನಿರೀಕ್ಷಿತ ಲೋಡ್ ಸಂಭವಿಸಿದಾಗ, ಉದಾಹರಣೆಗೆ ಸಮ್ಮೇಳನ ಅಥವಾ ಜಾಹೀರಾತು ಪ್ರಚಾರದ ನಂತರ, ಜನಸಂದಣಿಯು ಸೈಟ್‌ಗೆ ಭೇಟಿ ನೀಡುತ್ತಾರೆ ಮತ್ತು ಲೋಡ್ ನಾಟಕೀಯವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ, ಅರೋರಾ ಸರ್ವರ್‌ಲೆಸ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಈ ಲೋಡ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಕಾಣೆಯಾದ ಸಂಪನ್ಮೂಲಗಳನ್ನು (ACU) ತ್ವರಿತವಾಗಿ ಸಂಪರ್ಕಿಸುತ್ತದೆ. ನಂತರ ಸಮ್ಮೇಳನವು ಹಾದುಹೋಗುತ್ತದೆ, ಪ್ರತಿಯೊಬ್ಬರೂ ಮೂಲಮಾದರಿಯ ಬಗ್ಗೆ ಮರೆತುಬಿಡುತ್ತಾರೆ, ಸರ್ವರ್ಗಳು (ACU) ಡಾರ್ಕ್ ಆಗುತ್ತವೆ ಮತ್ತು ವೆಚ್ಚಗಳು ಶೂನ್ಯಕ್ಕೆ ಇಳಿಯುತ್ತವೆ - ಅನುಕೂಲಕರ.
ಈ ಪರಿಹಾರವು ಸ್ಥಿರವಾದ ಹೈಲೋಡ್‌ಗೆ ಸೂಕ್ತವಲ್ಲ ಏಕೆಂದರೆ ಇದು ಬರವಣಿಗೆಯ ಲೋಡ್ ಅನ್ನು ಅಳೆಯುವುದಿಲ್ಲ. ಈ ಎಲ್ಲಾ ಸಂಪರ್ಕಗಳು ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳ ಸಂಪರ್ಕ ಕಡಿತಗಳು "ಸ್ಕೇಲ್ ಪಾಯಿಂಟ್" ಎಂದು ಕರೆಯಲ್ಪಡುವ ಸಮಯದಲ್ಲಿ ಸಂಭವಿಸುತ್ತವೆ - ಡೇಟಾಬೇಸ್ ವಹಿವಾಟು ಅಥವಾ ತಾತ್ಕಾಲಿಕ ಕೋಷ್ಟಕಗಳಿಂದ ಬೆಂಬಲಿತವಾಗಿಲ್ಲದ ಸಮಯದಲ್ಲಿ. ಉದಾಹರಣೆಗೆ, ಒಂದು ವಾರದೊಳಗೆ ಸ್ಕೇಲ್ ಪಾಯಿಂಟ್ ಸಂಭವಿಸದೇ ಇರಬಹುದು, ಮತ್ತು ಮೂಲವು ಅದೇ ಸಂಪನ್ಮೂಲಗಳ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಸರಳವಾಗಿ ವಿಸ್ತರಿಸಲು ಅಥವಾ ಸಂಕುಚಿತಗೊಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಯಾವುದೇ ಮ್ಯಾಜಿಕ್ ಇಲ್ಲ - ಇದು ಸಾಮಾನ್ಯ PostgreSQL. ಆದರೆ ಯಂತ್ರಗಳನ್ನು ಸೇರಿಸುವ ಮತ್ತು ಅವುಗಳ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸುವ ಪ್ರಕ್ರಿಯೆಯು ಭಾಗಶಃ ಸ್ವಯಂಚಾಲಿತವಾಗಿರುತ್ತದೆ.
ವಿನ್ಯಾಸದಿಂದ ಸರ್ವರ್‌ಲೆಸ್
ಅರೋರಾ ಸರ್ವರ್‌ಲೆಸ್ ಎಂಬುದು ಸರ್ವರ್‌ಲೆಸ್‌ನ ಕೆಲವು ಪ್ರಯೋಜನಗಳ ಲಾಭವನ್ನು ಪಡೆಯಲು ಕ್ಲೌಡ್‌ಗಾಗಿ ಪುನಃ ಬರೆಯಲಾದ ಹಳೆಯ ಡೇಟಾಬೇಸ್ ಆಗಿದೆ. ಮತ್ತು ಈಗ ನಾನು ನಿಮಗೆ ಬೇಸ್ ಬಗ್ಗೆ ಹೇಳುತ್ತೇನೆ, ಇದನ್ನು ಮೂಲತಃ ಕ್ಲೌಡ್‌ಗಾಗಿ ಬರೆಯಲಾಗಿದೆ, ಸರ್ವರ್‌ಲೆಸ್ ವಿಧಾನಕ್ಕಾಗಿ - ಸರ್ವರ್‌ಲೆಸ್-ಬೈ-ಡಿಸೈನ್. ಇದು ಭೌತಿಕ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬ ಊಹೆಯಿಲ್ಲದೆ ತಕ್ಷಣವೇ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಯಿತು.
ಈ ನೆಲೆಯನ್ನು ಸ್ನೋಫ್ಲೇಕ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಇದು ಮೂರು ಪ್ರಮುಖ ಬ್ಲಾಕ್ಗಳನ್ನು ಹೊಂದಿದೆ.
ಮೊದಲನೆಯದು ಮೆಟಾಡೇಟಾ ಬ್ಲಾಕ್ ಆಗಿದೆ. ಇದು ವೇಗದ ಇನ್-ಮೆಮೊರಿ ಸೇವೆಯಾಗಿದ್ದು, ಭದ್ರತೆ, ಮೆಟಾಡೇಟಾ, ವಹಿವಾಟುಗಳು ಮತ್ತು ಪ್ರಶ್ನೆ ಆಪ್ಟಿಮೈಸೇಶನ್‌ನೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ (ಎಡಭಾಗದಲ್ಲಿರುವ ವಿವರಣೆಯಲ್ಲಿ ತೋರಿಸಲಾಗಿದೆ).
ಎರಡನೇ ಬ್ಲಾಕ್ ಲೆಕ್ಕಾಚಾರಗಳಿಗಾಗಿ ವರ್ಚುವಲ್ ಕಂಪ್ಯೂಟಿಂಗ್ ಕ್ಲಸ್ಟರ್‌ಗಳ ಗುಂಪಾಗಿದೆ (ಚಿತ್ರದಲ್ಲಿ ನೀಲಿ ವಲಯಗಳ ಒಂದು ಸೆಟ್ ಇದೆ).
ಮೂರನೇ ಬ್ಲಾಕ್ S3 ಆಧಾರಿತ ಡೇಟಾ ಸಂಗ್ರಹ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ. S3 ಎಂಬುದು AWS ನಲ್ಲಿ ಆಯಾಮವಿಲ್ಲದ ವಸ್ತು ಸಂಗ್ರಹಣೆಯಾಗಿದೆ, ವ್ಯವಹಾರಕ್ಕಾಗಿ ಆಯಾಮವಿಲ್ಲದ ಡ್ರಾಪ್‌ಬಾಕ್ಸ್‌ನಂತೆ.
ಸ್ನೋಫ್ಲೇಕ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ, ಕೋಲ್ಡ್ ಸ್ಟಾರ್ಟ್ ಅನ್ನು ಊಹಿಸಿ. ಅಂದರೆ, ಡೇಟಾಬೇಸ್ ಇದೆ, ಡೇಟಾವನ್ನು ಅದರಲ್ಲಿ ಲೋಡ್ ಮಾಡಲಾಗಿದೆ, ಯಾವುದೇ ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಶ್ನೆಗಳಿಲ್ಲ. ಅಂತೆಯೇ, ಡೇಟಾಬೇಸ್‌ಗೆ ಯಾವುದೇ ವಿನಂತಿಗಳಿಲ್ಲದಿದ್ದರೆ, ನಾವು ವೇಗದ ಇನ್-ಮೆಮೊರಿ ಮೆಟಾಡೇಟಾ ಸೇವೆಯನ್ನು (ಮೊದಲ ಬ್ಲಾಕ್) ಹೆಚ್ಚಿಸಿದ್ದೇವೆ. ಮತ್ತು ನಾವು S3 ಸಂಗ್ರಹಣೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅಲ್ಲಿ ಟೇಬಲ್ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, ಇದನ್ನು ಮೈಕ್ರೊಪಾರ್ಟಿಷನ್ ಎಂದು ವಿಂಗಡಿಸಲಾಗಿದೆ. ಸರಳತೆಗಾಗಿ: ಟೇಬಲ್ ವಹಿವಾಟುಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಮೈಕ್ರೋಪಾರ್ಟಿಷನ್ಗಳು ವಹಿವಾಟಿನ ದಿನಗಳಾಗಿವೆ. ಪ್ರತಿದಿನವೂ ಪ್ರತ್ಯೇಕ ಮೈಕ್ರೊಪಾರ್ಟಿಷನ್, ಪ್ರತ್ಯೇಕ ಫೈಲ್. ಮತ್ತು ಡೇಟಾಬೇಸ್ ಈ ಕ್ರಮದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿದಾಗ, ಡೇಟಾ ಆಕ್ರಮಿಸಿಕೊಂಡಿರುವ ಜಾಗಕ್ಕೆ ಮಾತ್ರ ನೀವು ಪಾವತಿಸುತ್ತೀರಿ. ಇದಲ್ಲದೆ, ಪ್ರತಿ ಸೀಟಿನ ದರವು ತುಂಬಾ ಕಡಿಮೆಯಾಗಿದೆ (ವಿಶೇಷವಾಗಿ ಗಮನಾರ್ಹವಾದ ಸಂಕೋಚನವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ). ಮೆಟಾಡೇಟಾ ಸೇವೆಯು ನಿರಂತರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಪ್ರಶ್ನೆಗಳನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ನಿಮಗೆ ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲಗಳ ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು ಸೇವೆಯನ್ನು ಶೇರ್‌ವೇರ್ ಎಂದು ಪರಿಗಣಿಸಬಹುದು.
ಈಗ ಬಳಕೆದಾರರು ನಮ್ಮ ಡೇಟಾಬೇಸ್‌ಗೆ ಬಂದು SQL ಪ್ರಶ್ನೆಯನ್ನು ಕಳುಹಿಸಿದ್ದಾರೆ ಎಂದು ಊಹಿಸೋಣ. ಪ್ರಕ್ರಿಯೆಗಾಗಿ SQL ಪ್ರಶ್ನೆಯನ್ನು ತಕ್ಷಣವೇ ಮೆಟಾಡೇಟಾ ಸೇವೆಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಅಂತೆಯೇ, ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ, ಈ ಸೇವೆಯು ವಿನಂತಿ, ಲಭ್ಯವಿರುವ ಡೇಟಾ, ಬಳಕೆದಾರರ ಅನುಮತಿಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತದೆ ಮತ್ತು ಎಲ್ಲವೂ ಸರಿಯಾಗಿದ್ದರೆ, ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಯೋಜನೆಯನ್ನು ರೂಪಿಸುತ್ತದೆ.
ಮುಂದೆ, ಸೇವೆಯು ಕಂಪ್ಯೂಟಿಂಗ್ ಕ್ಲಸ್ಟರ್ನ ಪ್ರಾರಂಭವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಕಂಪ್ಯೂಟಿಂಗ್ ಕ್ಲಸ್ಟರ್ ಎನ್ನುವುದು ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಸರ್ವರ್‌ಗಳ ಸಮೂಹವಾಗಿದೆ. ಅಂದರೆ, ಇದು 1 ಸರ್ವರ್, 2 ಸರ್ವರ್ಗಳು, 4, 8, 16, 32 - ನಿಮಗೆ ಬೇಕಾದಷ್ಟು ಒಳಗೊಂಡಿರುವ ಕ್ಲಸ್ಟರ್ ಆಗಿದೆ. ನೀವು ವಿನಂತಿಯನ್ನು ಎಸೆಯಿರಿ ಮತ್ತು ಈ ಕ್ಲಸ್ಟರ್ನ ಉಡಾವಣೆ ತಕ್ಷಣವೇ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಇದು ನಿಜವಾಗಿಯೂ ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಮುಂದೆ, ಕ್ಲಸ್ಟರ್ ಪ್ರಾರಂಭವಾದ ನಂತರ, ನಿಮ್ಮ ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಅಗತ್ಯವಿರುವ ಮೈಕ್ರೊಪಾರ್ಟಿಷನ್‌ಗಳನ್ನು S3 ನಿಂದ ಕ್ಲಸ್ಟರ್‌ಗೆ ನಕಲಿಸಲು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಅಂದರೆ, SQL ಪ್ರಶ್ನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಿಮಗೆ ಒಂದು ಟೇಬಲ್‌ನಿಂದ ಎರಡು ವಿಭಾಗಗಳು ಮತ್ತು ಎರಡನೆಯಿಂದ ಒಂದು ವಿಭಾಗಗಳು ಬೇಕಾಗುತ್ತವೆ ಎಂದು ಊಹಿಸೋಣ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಅಗತ್ಯವಿರುವ ಮೂರು ವಿಭಾಗಗಳನ್ನು ಮಾತ್ರ ಕ್ಲಸ್ಟರ್‌ಗೆ ನಕಲಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಾ ಕೋಷ್ಟಕಗಳು ಸಂಪೂರ್ಣವಾಗಿ ಅಲ್ಲ. ಅದಕ್ಕಾಗಿಯೇ, ಮತ್ತು ನಿಖರವಾಗಿ ಎಲ್ಲವೂ ಒಂದೇ ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿದೆ ಮತ್ತು ಅತ್ಯಂತ ವೇಗದ ಚಾನಲ್‌ಗಳಿಂದ ಸಂಪರ್ಕಗೊಂಡಿರುವುದರಿಂದ, ಸಂಪೂರ್ಣ ವರ್ಗಾವಣೆ ಪ್ರಕ್ರಿಯೆಯು ಬಹಳ ಬೇಗನೆ ಸಂಭವಿಸುತ್ತದೆ: ಸೆಕೆಂಡುಗಳಲ್ಲಿ, ಬಹಳ ವಿರಳವಾಗಿ ನಿಮಿಷಗಳಲ್ಲಿ, ನಾವು ಕೆಲವು ದೈತ್ಯಾಕಾರದ ವಿನಂತಿಗಳ ಬಗ್ಗೆ ಮಾತನಾಡದಿದ್ದರೆ . ಅಂತೆಯೇ, ಮೈಕ್ರೊಪಾರ್ಟಿಷನ್‌ಗಳನ್ನು ಕಂಪ್ಯೂಟಿಂಗ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ನಕಲಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಪೂರ್ಣಗೊಂಡ ನಂತರ, ಈ ಕಂಪ್ಯೂಟಿಂಗ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ SQL ಪ್ರಶ್ನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ. ಈ ವಿನಂತಿಯ ಫಲಿತಾಂಶವು ಒಂದು ಸಾಲು, ಹಲವಾರು ಸಾಲುಗಳು ಅಥವಾ ಟೇಬಲ್ ಆಗಿರಬಹುದು - ಅವುಗಳನ್ನು ಬಳಕೆದಾರರಿಗೆ ಬಾಹ್ಯವಾಗಿ ಕಳುಹಿಸಲಾಗುತ್ತದೆ ಇದರಿಂದ ಅವರು ಅದನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಬಹುದು, ಅವರ BI ಉಪಕರಣದಲ್ಲಿ ಪ್ರದರ್ಶಿಸಬಹುದು ಅಥವಾ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಬಳಸಬಹುದು.
ಪ್ರತಿಯೊಂದು SQL ಪ್ರಶ್ನೆಯು ಹಿಂದೆ ಲೋಡ್ ಮಾಡಲಾದ ಡೇಟಾದಿಂದ ಒಟ್ಟುಗಳನ್ನು ಓದಲು ಮಾತ್ರವಲ್ಲದೆ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಹೊಸ ಡೇಟಾವನ್ನು ಲೋಡ್ ಮಾಡಲು/ರಚಿಸಲು ಸಹ ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಅಂದರೆ, ಇದು ಒಂದು ಪ್ರಶ್ನೆಯಾಗಿರಬಹುದು, ಉದಾಹರಣೆಗೆ, ಮತ್ತೊಂದು ಟೇಬಲ್‌ಗೆ ಹೊಸ ದಾಖಲೆಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ, ಇದು ಕಂಪ್ಯೂಟಿಂಗ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಹೊಸ ವಿಭಾಗದ ಗೋಚರಿಸುವಿಕೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ, ಇದು ಒಂದೇ S3 ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಉಳಿಸಲ್ಪಡುತ್ತದೆ.
ಮೇಲೆ ವಿವರಿಸಿದ ಸನ್ನಿವೇಶದಲ್ಲಿ, ಬಳಕೆದಾರರ ಆಗಮನದಿಂದ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೆಚ್ಚಿಸುವುದು, ಡೇಟಾವನ್ನು ಲೋಡ್ ಮಾಡುವುದು, ಪ್ರಶ್ನೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು, ಫಲಿತಾಂಶಗಳನ್ನು ಪಡೆಯುವುದು, ವರ್ಚುವಲ್ ಕಂಪ್ಯೂಟಿಂಗ್ ಕ್ಲಸ್ಟರ್, ವರ್ಚುವಲ್ ವೇರ್ಹೌಸ್ ಅನ್ನು ಬಳಸುವ ನಿಮಿಷಗಳ ದರದಲ್ಲಿ ಪಾವತಿಸಲಾಗುತ್ತದೆ. AWS ವಲಯ ಮತ್ತು ಕ್ಲಸ್ಟರ್ ಗಾತ್ರವನ್ನು ಅವಲಂಬಿಸಿ ದರವು ಬದಲಾಗುತ್ತದೆ, ಆದರೆ ಸರಾಸರಿ ಇದು ಪ್ರತಿ ಗಂಟೆಗೆ ಕೆಲವು ಡಾಲರ್ ಆಗಿದೆ. ನಾಲ್ಕು ಯಂತ್ರಗಳ ಕ್ಲಸ್ಟರ್ ಎರಡು ಯಂತ್ರಗಳ ಕ್ಲಸ್ಟರ್‌ಗಿಂತ ಎರಡು ಪಟ್ಟು ದುಬಾರಿಯಾಗಿದೆ ಮತ್ತು ಎಂಟು ಯಂತ್ರಗಳ ಕ್ಲಸ್ಟರ್ ಇನ್ನೂ ಎರಡು ಪಟ್ಟು ದುಬಾರಿಯಾಗಿದೆ. ವಿನಂತಿಗಳ ಸಂಕೀರ್ಣತೆಗೆ ಅನುಗುಣವಾಗಿ 16, 32 ಯಂತ್ರಗಳ ಆಯ್ಕೆಗಳು ಲಭ್ಯವಿದೆ. ಆದರೆ ಕ್ಲಸ್ಟರ್ ನಿಜವಾಗಿಯೂ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ನೀವು ಆ ನಿಮಿಷಗಳಿಗೆ ಮಾತ್ರ ಪಾವತಿಸುತ್ತೀರಿ, ಏಕೆಂದರೆ ಯಾವುದೇ ವಿನಂತಿಗಳಿಲ್ಲದಿದ್ದಾಗ, ನೀವು ನಿಮ್ಮ ಕೈಗಳನ್ನು ತೆಗೆಯುತ್ತೀರಿ ಮತ್ತು 5-10 ನಿಮಿಷಗಳ ಕಾಯುವಿಕೆಯ ನಂತರ (ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದಾದ ಪ್ಯಾರಾಮೀಟರ್) ಅದು ತನ್ನದೇ ಆದ ಮೇಲೆ ಹೋಗುತ್ತದೆ, ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮುಕ್ತಗೊಳಿಸಿ ಮತ್ತು ಮುಕ್ತರಾಗಿ.
ಸಂಪೂರ್ಣ ವಾಸ್ತವಿಕ ಸನ್ನಿವೇಶವೆಂದರೆ ನೀವು ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿದಾಗ, ಕ್ಲಸ್ಟರ್ ಪಾಪ್ ಅಪ್ ಆಗುತ್ತದೆ, ತುಲನಾತ್ಮಕವಾಗಿ ಹೇಳುವುದಾದರೆ, ಒಂದು ನಿಮಿಷದಲ್ಲಿ, ಅದು ಇನ್ನೊಂದು ನಿಮಿಷವನ್ನು ಎಣಿಸುತ್ತದೆ, ನಂತರ ಐದು ನಿಮಿಷಗಳು ಸ್ಥಗಿತಗೊಳ್ಳಲು, ಮತ್ತು ನೀವು ಈ ಕ್ಲಸ್ಟರ್ನ ಏಳು ನಿಮಿಷಗಳ ಕಾರ್ಯಾಚರಣೆಗೆ ಪಾವತಿಸುವಿರಿ, ಮತ್ತು ತಿಂಗಳುಗಳು ಮತ್ತು ವರ್ಷಗಳವರೆಗೆ ಅಲ್ಲ.
ಏಕ-ಬಳಕೆದಾರರ ಸೆಟ್ಟಿಂಗ್‌ನಲ್ಲಿ ಸ್ನೋಫ್ಲೇಕ್ ಅನ್ನು ಬಳಸುವ ಮೊದಲ ಸನ್ನಿವೇಶವನ್ನು ವಿವರಿಸಲಾಗಿದೆ. ಈಗ ಅನೇಕ ಬಳಕೆದಾರರಿದ್ದಾರೆ ಎಂದು ಊಹಿಸೋಣ, ಇದು ನೈಜ ಸನ್ನಿವೇಶಕ್ಕೆ ಹತ್ತಿರದಲ್ಲಿದೆ.
ನಮ್ಮ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸರಳ ವಿಶ್ಲೇಷಣಾತ್ಮಕ SQL ಪ್ರಶ್ನೆಗಳೊಂದಿಗೆ ನಿರಂತರವಾಗಿ ಬಾಂಬ್ ಸ್ಫೋಟಿಸುವ ಬಹಳಷ್ಟು ವಿಶ್ಲೇಷಕರು ಮತ್ತು ಟೇಬಲ್‌ಯು ವರದಿಗಳನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಹೇಳೋಣ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಡೇಟಾದೊಂದಿಗೆ ದೈತ್ಯಾಕಾರದ ಕೆಲಸಗಳನ್ನು ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ, ಹತ್ತಾರು ಟೆರಾಬೈಟ್‌ಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು, ಶತಕೋಟಿ ಮತ್ತು ಟ್ರಿಲಿಯನ್‌ಗಟ್ಟಲೆ ಸಾಲುಗಳ ಡೇಟಾವನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಸೃಜನಶೀಲ ಡೇಟಾ ವಿಜ್ಞಾನಿಗಳನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಹೇಳೋಣ.
ಮೇಲೆ ವಿವರಿಸಿದ ಎರಡು ವಿಧದ ಕೆಲಸದ ಹೊರೆಗಾಗಿ, ವಿವಿಧ ಸಾಮರ್ಥ್ಯಗಳ ಹಲವಾರು ಸ್ವತಂತ್ರ ಕಂಪ್ಯೂಟಿಂಗ್ ಕ್ಲಸ್ಟರ್ಗಳನ್ನು ಹೆಚ್ಚಿಸಲು ಸ್ನೋಫ್ಲೇಕ್ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಇದಲ್ಲದೆ, ಈ ಕಂಪ್ಯೂಟಿಂಗ್ ಕ್ಲಸ್ಟರ್‌ಗಳು ಸ್ವತಂತ್ರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಆದರೆ ಸಾಮಾನ್ಯ ಸ್ಥಿರವಾದ ಡೇಟಾದೊಂದಿಗೆ.
ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಬೆಳಕಿನ ಪ್ರಶ್ನೆಗಳಿಗಾಗಿ, ನೀವು 2-3 ಸಣ್ಣ ಸಮೂಹಗಳನ್ನು, ಸರಿಸುಮಾರು 2 ಯಂತ್ರಗಳನ್ನು ಪ್ರತಿಯೊಂದನ್ನು ಹೆಚ್ಚಿಸಬಹುದು. ಈ ನಡವಳಿಕೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ಆದ್ದರಿಂದ ನೀವು ಹೇಳುತ್ತೀರಿ, “ಸ್ನೋಫ್ಲೇಕ್, ಸಣ್ಣ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೆಚ್ಚಿಸಿ. ಅದರ ಮೇಲಿನ ಹೊರೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ನಿಯತಾಂಕಕ್ಕಿಂತ ಹೆಚ್ಚಾದರೆ, ಇದೇ ರೀತಿಯ ಎರಡನೇ, ಮೂರನೆಯದನ್ನು ಹೆಚ್ಚಿಸಿ. ಹೊರೆ ಕಡಿಮೆಯಾಗಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಹೆಚ್ಚುವರಿವನ್ನು ನಂದಿಸಿ. ಆದ್ದರಿಂದ ಎಷ್ಟು ವಿಶ್ಲೇಷಕರು ಬಂದು ವರದಿಗಳನ್ನು ನೋಡಲು ಪ್ರಾರಂಭಿಸಿದರೂ, ಎಲ್ಲರಿಗೂ ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳಿವೆ.
ಅದೇ ಸಮಯದಲ್ಲಿ, ವಿಶ್ಲೇಷಕರು ನಿದ್ರಿಸುತ್ತಿದ್ದರೆ ಮತ್ತು ಯಾರೂ ವರದಿಗಳನ್ನು ನೋಡದಿದ್ದರೆ, ಸಮೂಹಗಳು ಸಂಪೂರ್ಣವಾಗಿ ಕತ್ತಲೆಯಾಗಬಹುದು, ಮತ್ತು ನೀವು ಅವರಿಗೆ ಪಾವತಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತೀರಿ.
ಅದೇ ಸಮಯದಲ್ಲಿ, ಭಾರೀ ಪ್ರಶ್ನೆಗಳಿಗಾಗಿ (ಡೇಟಾ ವಿಜ್ಞಾನಿಗಳಿಂದ), ನೀವು 32 ಯಂತ್ರಗಳಿಗೆ ಒಂದು ದೊಡ್ಡ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು. ನಿಮ್ಮ ದೈತ್ಯ ವಿನಂತಿಯು ಅಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ಆ ನಿಮಿಷಗಳು ಮತ್ತು ಗಂಟೆಗಳವರೆಗೆ ಮಾತ್ರ ಈ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪಾವತಿಸಲಾಗುತ್ತದೆ.
ಮೇಲೆ ವಿವರಿಸಿದ ಅವಕಾಶವು ನಿಮಗೆ 2 ಅನ್ನು ಮಾತ್ರ ವಿಭಜಿಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಆದರೆ ಹೆಚ್ಚಿನ ರೀತಿಯ ಕೆಲಸದ ಹೊರೆಗಳನ್ನು ಕ್ಲಸ್ಟರ್ಗಳಾಗಿ ವಿಂಗಡಿಸುತ್ತದೆ (ETL, ಮಾನಿಟರಿಂಗ್, ವರದಿ ವಸ್ತುೀಕರಣ,...).
ಸ್ನೋಫ್ಲೇಕ್ ಅನ್ನು ಸಂಕ್ಷಿಪ್ತಗೊಳಿಸೋಣ. ಬೇಸ್ ಸುಂದರವಾದ ಕಲ್ಪನೆ ಮತ್ತು ಕಾರ್ಯಸಾಧ್ಯವಾದ ಅನುಷ್ಠಾನವನ್ನು ಸಂಯೋಜಿಸುತ್ತದೆ. ManyChat ನಲ್ಲಿ, ನಾವು ಹೊಂದಿರುವ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ವಿಶ್ಲೇಷಿಸಲು ನಾವು ಸ್ನೋಫ್ಲೇಕ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ನಾವು ಉದಾಹರಣೆಯಲ್ಲಿರುವಂತೆ ಮೂರು ಕ್ಲಸ್ಟರ್ಗಳನ್ನು ಹೊಂದಿಲ್ಲ, ಆದರೆ 5 ರಿಂದ 9 ರವರೆಗೆ ವಿಭಿನ್ನ ಗಾತ್ರದ. ಕೆಲವು ಕಾರ್ಯಗಳಿಗಾಗಿ ನಾವು ಸಾಂಪ್ರದಾಯಿಕ 16-ಯಂತ್ರ, 2-ಯಂತ್ರ ಮತ್ತು ಅತಿ ಚಿಕ್ಕ 1-ಯಂತ್ರವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅವರು ಯಶಸ್ವಿಯಾಗಿ ಲೋಡ್ ಅನ್ನು ವಿತರಿಸುತ್ತಾರೆ ಮತ್ತು ನಮಗೆ ಬಹಳಷ್ಟು ಉಳಿಸಲು ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತಾರೆ.
ಡೇಟಾಬೇಸ್ ಓದುವ ಮತ್ತು ಬರೆಯುವ ಲೋಡ್ ಅನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಅಳೆಯುತ್ತದೆ. ಇದು ಒಂದು ದೊಡ್ಡ ವ್ಯತ್ಯಾಸ ಮತ್ತು ಅದೇ "ಅರೋರಾ" ಗೆ ಹೋಲಿಸಿದರೆ ಒಂದು ದೊಡ್ಡ ಪ್ರಗತಿಯಾಗಿದೆ, ಇದು ಓದುವ ಹೊರೆಯನ್ನು ಮಾತ್ರ ಹೊತ್ತಿದೆ. ಈ ಕಂಪ್ಯೂಟಿಂಗ್ ಕ್ಲಸ್ಟರ್‌ಗಳೊಂದಿಗೆ ನಿಮ್ಮ ಬರವಣಿಗೆಯ ಕೆಲಸದ ಹೊರೆಯನ್ನು ಅಳೆಯಲು ಸ್ನೋಫ್ಲೇಕ್ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಅಂದರೆ, ನಾನು ಹೇಳಿದಂತೆ, ನಾವು ManyChat ನಲ್ಲಿ ಹಲವಾರು ಕ್ಲಸ್ಟರ್ಗಳನ್ನು ಬಳಸುತ್ತೇವೆ, ಸಣ್ಣ ಮತ್ತು ಸೂಪರ್-ಸಣ್ಣ ಕ್ಲಸ್ಟರ್ಗಳನ್ನು ಮುಖ್ಯವಾಗಿ ETL ಗಾಗಿ ಡೇಟಾ ಲೋಡ್ ಮಾಡಲು ಬಳಸಲಾಗುತ್ತದೆ. ಮತ್ತು ವಿಶ್ಲೇಷಕರು ಈಗಾಗಲೇ ಮಧ್ಯಮ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ವಾಸಿಸುತ್ತಿದ್ದಾರೆ, ಇದು ಇಟಿಎಲ್ ಲೋಡ್‌ನಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅವರು ಬೇಗನೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ.
ಅಂತೆಯೇ, ಡೇಟಾಬೇಸ್ OLAP ಕಾರ್ಯಗಳಿಗೆ ಸೂಕ್ತವಾಗಿರುತ್ತದೆ. ಆದಾಗ್ಯೂ, ದುರದೃಷ್ಟವಶಾತ್, ಇದು OLTP ಕೆಲಸದ ಹೊರೆಗಳಿಗೆ ಇನ್ನೂ ಅನ್ವಯಿಸುವುದಿಲ್ಲ. ಮೊದಲನೆಯದಾಗಿ, ಈ ಡೇಟಾಬೇಸ್ ಸ್ತಂಭಾಕಾರದ, ನಂತರದ ಎಲ್ಲಾ ಪರಿಣಾಮಗಳೊಂದಿಗೆ. ಎರಡನೆಯದಾಗಿ, ಪ್ರತಿ ವಿನಂತಿಗಾಗಿ, ಅಗತ್ಯವಿದ್ದಲ್ಲಿ, ನೀವು ಕಂಪ್ಯೂಟಿಂಗ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೆಚ್ಚಿಸಿದಾಗ ಮತ್ತು ಡೇಟಾದೊಂದಿಗೆ ಅದನ್ನು ತುಂಬಿಸಿದಾಗ, ದುರದೃಷ್ಟವಶಾತ್, OLTP ಲೋಡ್‌ಗಳಿಗೆ ಇನ್ನೂ ಸಾಕಷ್ಟು ವೇಗವಾಗಿಲ್ಲ. OLAP ಕಾರ್ಯಗಳಿಗಾಗಿ ಸೆಕೆಂಡುಗಳ ಕಾಲ ಕಾಯುವುದು ಸಾಮಾನ್ಯವಾಗಿದೆ, ಆದರೆ OLTP ಕಾರ್ಯಗಳಿಗೆ ಇದು ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲ; 100 ms ಉತ್ತಮವಾಗಿರುತ್ತದೆ ಅಥವಾ 10 ms ಇನ್ನೂ ಉತ್ತಮವಾಗಿರುತ್ತದೆ.
ಫಲಿತಾಂಶ
ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸ್ಟೇಟ್ಲೆಸ್ ಮತ್ತು ಸ್ಟೇಟ್ಫುಲ್ ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸುವ ಮೂಲಕ ಸರ್ವರ್‌ಲೆಸ್ ಡೇಟಾಬೇಸ್ ಸಾಧ್ಯ. ಮೇಲಿನ ಎಲ್ಲಾ ಉದಾಹರಣೆಗಳಲ್ಲಿ, ಸ್ಟೇಟ್ಫುಲ್ ಭಾಗವು, ತುಲನಾತ್ಮಕವಾಗಿ ಹೇಳುವುದಾದರೆ, S3 ನಲ್ಲಿ ಮೈಕ್ರೋ-ವಿಭಾಗಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಸ್ಟೇಟ್ಲೆಸ್ ಆಪ್ಟಿಮೈಜರ್ ಆಗಿದೆ, ಮೆಟಾಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಸ್ವತಂತ್ರ ಹಗುರವಾದ ಸ್ಟೇಟ್ಲೆಸ್ ಸೇವೆಗಳಾಗಿ ರಚಿಸಬಹುದಾದ ಭದ್ರತಾ ಸಮಸ್ಯೆಗಳನ್ನು ನಿಭಾಯಿಸುತ್ತದೆ.
SQL ಪ್ರಶ್ನೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದನ್ನು ಸ್ನೋಫ್ಲೇಕ್ ಕಂಪ್ಯೂಟಿಂಗ್ ಕ್ಲಸ್ಟರ್‌ಗಳಂತಹ ಸರ್ವರ್‌ಲೆಸ್ ಮೋಡ್‌ನಲ್ಲಿ ಪಾಪ್ ಅಪ್ ಮಾಡಬಹುದಾದ ಲೈಟ್-ಸ್ಟೇಟ್ ಸೇವೆಗಳು ಎಂದು ಗ್ರಹಿಸಬಹುದು, ಅಗತ್ಯ ಡೇಟಾವನ್ನು ಮಾತ್ರ ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ, ಪ್ರಶ್ನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ ಮತ್ತು "ಹೊರಹೋಗಿ."
ಸರ್ವರ್‌ಲೆಸ್ ಉತ್ಪಾದನಾ ಮಟ್ಟದ ಡೇಟಾಬೇಸ್‌ಗಳು ಈಗಾಗಲೇ ಬಳಕೆಗೆ ಲಭ್ಯವಿವೆ, ಅವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿವೆ. ಈ ಸರ್ವರ್‌ಲೆಸ್ ಡೇಟಾಬೇಸ್‌ಗಳು ಈಗಾಗಲೇ OLAP ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಸಿದ್ಧವಾಗಿವೆ. ದುರದೃಷ್ಟವಶಾತ್, OLTP ಕಾರ್ಯಗಳಿಗಾಗಿ ಅವುಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ ... ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳೊಂದಿಗೆ, ಮಿತಿಗಳಿವೆ. ಒಂದೆಡೆ, ಇದು ಮೈನಸ್ ಆಗಿದೆ. ಆದರೆ, ಮತ್ತೊಂದೆಡೆ, ಇದು ಒಂದು ಅವಕಾಶ. ಬಹುಶಃ ಓದುಗರಲ್ಲಿ ಒಬ್ಬರು ಅರೋರಾದ ಮಿತಿಗಳಿಲ್ಲದೆ OLTP ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸರ್ವರ್‌ಲೆಸ್ ಮಾಡಲು ಒಂದು ಮಾರ್ಗವನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತಾರೆ.
ನೀವು ಅದನ್ನು ಆಸಕ್ತಿದಾಯಕವಾಗಿ ಕಂಡುಕೊಂಡಿದ್ದೀರಿ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಸರ್ವರ್‌ಲೆಸ್ ಭವಿಷ್ಯ :)
ಮೂಲ: www.habr.com