NewSQL = NoSQL+ACID

ಇತ್ತೀಚಿನವರೆಗೂ, Odnoklassniki SQL ಸರ್ವರ್‌ನಲ್ಲಿ ನೈಜ ಸಮಯದಲ್ಲಿ ಸಂಸ್ಕರಿಸಿದ ಸುಮಾರು 50 TB ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿದೆ. ಅಂತಹ ಪರಿಮಾಣಕ್ಕಾಗಿ, SQL DBMS ಅನ್ನು ಬಳಸಿಕೊಂಡು ವೇಗವಾದ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹ ಮತ್ತು ಡೇಟಾ ಸೆಂಟರ್ ವೈಫಲ್ಯ-ಸಹಿಷ್ಣು ಪ್ರವೇಶವನ್ನು ಒದಗಿಸುವುದು ಅಸಾಧ್ಯವಾಗಿದೆ. ವಿಶಿಷ್ಟವಾಗಿ, ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ, NoSQL ಸಂಗ್ರಹಣೆಗಳಲ್ಲಿ ಒಂದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಆದರೆ ಎಲ್ಲವನ್ನೂ NoSQL ಗೆ ವರ್ಗಾಯಿಸಲಾಗುವುದಿಲ್ಲ: ಕೆಲವು ಘಟಕಗಳಿಗೆ ACID ವಹಿವಾಟು ಖಾತರಿಗಳು ಬೇಕಾಗುತ್ತವೆ.

ಇದು ನಮಗೆ NewSQL ಸಂಗ್ರಹಣೆಯ ಬಳಕೆಗೆ ಕಾರಣವಾಯಿತು, ಅಂದರೆ, NoSQL ಸಿಸ್ಟಮ್‌ಗಳ ದೋಷ ಸಹಿಷ್ಣುತೆ, ಸ್ಕೇಲೆಬಿಲಿಟಿ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಒದಗಿಸುವ DBMS, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಶಾಸ್ತ್ರೀಯ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಪರಿಚಿತವಾಗಿರುವ ACID ಗ್ಯಾರಂಟಿಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು. ಈ ಹೊಸ ವರ್ಗದ ಕೆಲವು ಕೆಲಸ ಮಾಡುವ ಕೈಗಾರಿಕಾ ವ್ಯವಸ್ಥೆಗಳಿವೆ, ಆದ್ದರಿಂದ ನಾವು ಅಂತಹ ವ್ಯವಸ್ಥೆಯನ್ನು ನಾವೇ ಜಾರಿಗೆ ತಂದಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ವಾಣಿಜ್ಯ ಕಾರ್ಯಾಚರಣೆಗೆ ಒಳಪಡಿಸಿದ್ದೇವೆ.

ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಏನಾಯಿತು - ಕಟ್ ಅಡಿಯಲ್ಲಿ ಓದಿ.

ಇಂದು, ಓಡ್ನೋಕ್ಲಾಸ್ನಿಕಿಯ ಮಾಸಿಕ ಪ್ರೇಕ್ಷಕರು 70 ಮಿಲಿಯನ್‌ಗಿಂತಲೂ ಹೆಚ್ಚು ಅನನ್ಯ ಸಂದರ್ಶಕರಾಗಿದ್ದಾರೆ. ನಾವು ನಾವು ಮೊದಲ ಐದರಲ್ಲಿದ್ದೇವೆ ವಿಶ್ವದ ಅತಿದೊಡ್ಡ ಸಾಮಾಜಿಕ ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಮತ್ತು ಬಳಕೆದಾರರು ಹೆಚ್ಚು ಸಮಯವನ್ನು ಕಳೆಯುವ ಇಪ್ಪತ್ತು ಸೈಟ್‌ಗಳಲ್ಲಿ. ಸರಿ ಮೂಲಸೌಕರ್ಯವು ಹೆಚ್ಚಿನ ಲೋಡ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ: ಪ್ರತಿ ಮುಂಭಾಗಕ್ಕೆ ಮಿಲಿಯನ್‌ಗಿಂತಲೂ ಹೆಚ್ಚು HTTP ವಿನಂತಿಗಳು/ಸೆಕೆಂಡು. 8000 ಕ್ಕಿಂತ ಹೆಚ್ಚು ತುಣುಕುಗಳ ಸರ್ವರ್ ಫ್ಲೀಟ್‌ನ ಭಾಗಗಳು ಪರಸ್ಪರ ಹತ್ತಿರದಲ್ಲಿವೆ - ನಾಲ್ಕು ಮಾಸ್ಕೋ ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ, ಅವುಗಳ ನಡುವೆ 1 ms ಗಿಂತ ಕಡಿಮೆ ನೆಟ್‌ವರ್ಕ್ ಲೇಟೆನ್ಸಿಯನ್ನು ಅನುಮತಿಸುತ್ತದೆ.

ನಾವು 2010 ರಿಂದ ಕಸ್ಸಂದ್ರವನ್ನು ಬಳಸುತ್ತಿದ್ದೇವೆ, ಆವೃತ್ತಿ 0.6 ರಿಂದ ಪ್ರಾರಂಭಿಸಿ. ಇಂದು ಹಲವಾರು ಡಜನ್ ಕ್ಲಸ್ಟರ್‌ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿವೆ. ವೇಗವಾದ ಕ್ಲಸ್ಟರ್ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 4 ಮಿಲಿಯನ್ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ದೊಡ್ಡದು 260 TB ಅನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ.

ಆದಾಗ್ಯೂ, ಇವೆಲ್ಲವೂ ಶೇಖರಣೆಗಾಗಿ ಬಳಸಲಾಗುವ ಸಾಮಾನ್ಯ NoSQL ಕ್ಲಸ್ಟರ್‌ಗಳಾಗಿವೆ ದುರ್ಬಲವಾಗಿ ಸಂಘಟಿತವಾಗಿದೆ ಡೇಟಾ. Odnoklassniki ಸ್ಥಾಪನೆಯಾದಾಗಿನಿಂದ ಬಳಸಲಾಗುತ್ತಿರುವ ಮೈಕ್ರೋಸಾಫ್ಟ್ SQL ಸರ್ವರ್ ಎಂಬ ಮುಖ್ಯ ಸ್ಥಿರವಾದ ಸಂಗ್ರಹಣೆಯನ್ನು ಬದಲಾಯಿಸಲು ನಾವು ಬಯಸಿದ್ದೇವೆ. ಸಂಗ್ರಹಣೆಯು 300 ಕ್ಕೂ ಹೆಚ್ಚು SQL ಸರ್ವರ್ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಆವೃತ್ತಿ ಯಂತ್ರಗಳನ್ನು ಒಳಗೊಂಡಿತ್ತು, ಇದು 50 TB ಡೇಟಾವನ್ನು ಒಳಗೊಂಡಿತ್ತು - ವ್ಯಾಪಾರ ಘಟಕಗಳು. ಈ ಡೇಟಾವನ್ನು ACID ವಹಿವಾಟಿನ ಭಾಗವಾಗಿ ಮಾರ್ಪಡಿಸಲಾಗಿದೆ ಮತ್ತು ಅಗತ್ಯವಿದೆ ಹೆಚ್ಚಿನ ಸ್ಥಿರತೆ.

SQL ಸರ್ವರ್ ನೋಡ್‌ಗಳಾದ್ಯಂತ ಡೇಟಾವನ್ನು ವಿತರಿಸಲು, ನಾವು ಲಂಬ ಮತ್ತು ಅಡ್ಡ ಎರಡನ್ನೂ ಬಳಸಿದ್ದೇವೆ ವಿಭಜನೆ (ಶರ್ಡಿಂಗ್). ಐತಿಹಾಸಿಕವಾಗಿ, ನಾವು ಸರಳವಾದ ಡೇಟಾ ಹಂಚಿಕೆ ಯೋಜನೆಯನ್ನು ಬಳಸಿದ್ದೇವೆ: ಪ್ರತಿ ಘಟಕವು ಟೋಕನ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಲ್ಪಟ್ಟಿದೆ - ಘಟಕದ ID ಯ ಕಾರ್ಯ. ಅದೇ ಟೋಕನ್ ಹೊಂದಿರುವ ಘಟಕಗಳನ್ನು ಅದೇ SQL ಸರ್ವರ್‌ನಲ್ಲಿ ಇರಿಸಲಾಗಿದೆ. ಮುಖ್ಯ ಮತ್ತು ಮಕ್ಕಳ ದಾಖಲೆಗಳ ಟೋಕನ್‌ಗಳು ಯಾವಾಗಲೂ ಹೊಂದಾಣಿಕೆಯಾಗುವಂತೆ ಮತ್ತು ಒಂದೇ ಸರ್ವರ್‌ನಲ್ಲಿ ಇರುವಂತೆ ಮಾಸ್ಟರ್-ವಿವರ ಸಂಬಂಧವನ್ನು ಅಳವಡಿಸಲಾಗಿದೆ. ಸಾಮಾಜಿಕ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ, ಬಹುತೇಕ ಎಲ್ಲಾ ದಾಖಲೆಗಳನ್ನು ಬಳಕೆದಾರರ ಪರವಾಗಿ ರಚಿಸಲಾಗುತ್ತದೆ - ಅಂದರೆ ಒಂದು ಕ್ರಿಯಾತ್ಮಕ ಉಪವ್ಯವಸ್ಥೆಯೊಳಗಿನ ಎಲ್ಲಾ ಬಳಕೆದಾರರ ಡೇಟಾವನ್ನು ಒಂದು ಸರ್ವರ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಅಂದರೆ, ವ್ಯಾಪಾರ ವಹಿವಾಟು ಯಾವಾಗಲೂ ಒಂದು SQL ಸರ್ವರ್‌ನಿಂದ ಕೋಷ್ಟಕಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಇದು ಬಳಸದೆಯೇ ಸ್ಥಳೀಯ ACID ವಹಿವಾಟುಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಡೇಟಾ ಸ್ಥಿರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗಿಸಿತು. ನಿಧಾನ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲ ACID ವಹಿವಾಟುಗಳನ್ನು ವಿತರಿಸಲಾಗಿದೆ.

ಶಾರ್ಡಿಂಗ್ ಮತ್ತು SQL ಅನ್ನು ವೇಗಗೊಳಿಸಲು ಧನ್ಯವಾದಗಳು:

• ನಾವು ವಿದೇಶಿ ಕೀ ನಿರ್ಬಂಧಗಳನ್ನು ಬಳಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಶಾರ್ಡಿಂಗ್ ಮಾಡುವಾಗ ಘಟಕದ ID ಮತ್ತೊಂದು ಸರ್ವರ್‌ನಲ್ಲಿರಬಹುದು.
• DBMS CPU ನಲ್ಲಿನ ಹೆಚ್ಚುವರಿ ಲೋಡ್‌ನಿಂದಾಗಿ ನಾವು ಸಂಗ್ರಹಿಸಿದ ಕಾರ್ಯವಿಧಾನಗಳು ಮತ್ತು ಟ್ರಿಗ್ಗರ್‌ಗಳನ್ನು ಬಳಸುವುದಿಲ್ಲ.
• ಮೇಲಿನ ಎಲ್ಲಾ ಮತ್ತು ಡಿಸ್ಕ್‌ನಿಂದ ಸಾಕಷ್ಟು ಯಾದೃಚ್ಛಿಕ ಓದುವಿಕೆಗಳಿಂದಾಗಿ ನಾವು JOIN ಗಳನ್ನು ಬಳಸುವುದಿಲ್ಲ.
• ವಹಿವಾಟಿನ ಹೊರಗೆ, ಡೆಡ್‌ಲಾಕ್‌ಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಾವು ರೀಡ್ ಅನ್ ಕಮಿಟೆಡ್ ಐಸೋಲೇಶನ್ ಮಟ್ಟವನ್ನು ಬಳಸುತ್ತೇವೆ.
• ನಾವು ಸಣ್ಣ ವಹಿವಾಟುಗಳನ್ನು ಮಾತ್ರ ನಿರ್ವಹಿಸುತ್ತೇವೆ (ಸರಾಸರಿ 100 ಎಂಎಸ್‌ಗಿಂತ ಕಡಿಮೆ).
• ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಡೆಡ್‌ಲಾಕ್‌ಗಳ ಕಾರಣದಿಂದಾಗಿ ನಾವು ಬಹು-ಸಾಲು ಅಪ್‌ಡೇಟ್ ಮತ್ತು ಅಳಿಸುವಿಕೆಯನ್ನು ಬಳಸುವುದಿಲ್ಲ - ನಾವು ಒಂದು ಸಮಯದಲ್ಲಿ ಕೇವಲ ಒಂದು ದಾಖಲೆಯನ್ನು ಮಾತ್ರ ನವೀಕರಿಸುತ್ತೇವೆ.
• ನಾವು ಯಾವಾಗಲೂ ಇಂಡೆಕ್ಸ್‌ಗಳಲ್ಲಿ ಮಾತ್ರ ಪ್ರಶ್ನೆಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತೇವೆ - ನಮಗೆ ಪೂರ್ಣ ಟೇಬಲ್ ಸ್ಕ್ಯಾನ್ ಯೋಜನೆಯನ್ನು ಹೊಂದಿರುವ ಪ್ರಶ್ನೆ ಎಂದರೆ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಓವರ್‌ಲೋಡ್ ಮಾಡುವುದು ಮತ್ತು ಅದು ವಿಫಲಗೊಳ್ಳಲು ಕಾರಣವಾಗುತ್ತದೆ.

SQL ಸರ್ವರ್‌ಗಳಿಂದ ಬಹುತೇಕ ಗರಿಷ್ಠ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹಿಂಡಲು ಈ ಹಂತಗಳು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟವು. ಆದಾಗ್ಯೂ, ಸಮಸ್ಯೆಗಳು ಹೆಚ್ಚು ಹೆಚ್ಚು ಹೆಚ್ಚಾದವು. ಅವುಗಳನ್ನು ನೋಡೋಣ.

SQL ನೊಂದಿಗೆ ತೊಂದರೆಗಳು

• ನಾವು ಸ್ವಯಂ-ಬರಹದ ಶರ್ಡಿಂಗ್ ಅನ್ನು ಬಳಸಿದ್ದರಿಂದ, ಹೊಸ ಚೂರುಗಳನ್ನು ಸೇರಿಸುವುದನ್ನು ನಿರ್ವಾಹಕರು ಹಸ್ತಚಾಲಿತವಾಗಿ ಮಾಡಿದ್ದಾರೆ. ಈ ಸಮಯದಲ್ಲಿ, ಸ್ಕೇಲೆಬಲ್ ಡೇಟಾ ಪ್ರತಿಕೃತಿಗಳು ವಿನಂತಿಗಳನ್ನು ಸಲ್ಲಿಸುತ್ತಿಲ್ಲ.
• ಕೋಷ್ಟಕದಲ್ಲಿನ ದಾಖಲೆಗಳ ಸಂಖ್ಯೆಯು ಬೆಳೆದಂತೆ, ಅಳವಡಿಕೆ ಮತ್ತು ಮಾರ್ಪಾಡುಗಳ ವೇಗವು ಕಡಿಮೆಯಾಗುತ್ತದೆ; ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕೋಷ್ಟಕಕ್ಕೆ ಸೂಚ್ಯಂಕಗಳನ್ನು ಸೇರಿಸುವಾಗ, ವೇಗವು ಒಂದು ಅಂಶದಿಂದ ಇಳಿಯುತ್ತದೆ; ಅಲಭ್ಯತೆಯೊಂದಿಗೆ ಸೂಚ್ಯಂಕಗಳ ರಚನೆ ಮತ್ತು ಮರು-ಸೃಷ್ಟಿ ಸಂಭವಿಸುತ್ತದೆ.
• ಉತ್ಪಾದನೆಯಲ್ಲಿ SQL ಸರ್ವರ್‌ಗಾಗಿ ಸಣ್ಣ ಪ್ರಮಾಣದ ವಿಂಡೋಸ್ ಅನ್ನು ಹೊಂದಿರುವುದು ಮೂಲಸೌಕರ್ಯ ನಿರ್ವಹಣೆಯನ್ನು ಕಷ್ಟಕರವಾಗಿಸುತ್ತದೆ

ಆದರೆ ಮುಖ್ಯ ಸಮಸ್ಯೆ

ದೋಷಸಹಿಷ್ಣುತೆ

ಕ್ಲಾಸಿಕ್ SQL ಸರ್ವರ್ ಕಳಪೆ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಹೊಂದಿದೆ. ನೀವು ಕೇವಲ ಒಂದು ಡೇಟಾಬೇಸ್ ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ಹೇಳೋಣ ಮತ್ತು ಇದು ಪ್ರತಿ ಮೂರು ವರ್ಷಗಳಿಗೊಮ್ಮೆ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ. ಈ ಸಮಯದಲ್ಲಿ ಸೈಟ್ 20 ನಿಮಿಷಗಳ ಕಾಲ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ, ಇದು ಸ್ವೀಕಾರಾರ್ಹವಾಗಿದೆ. ನೀವು 64 ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಪ್ರತಿ ಮೂರು ವಾರಗಳಿಗೊಮ್ಮೆ ಸೈಟ್ ಡೌನ್ ಆಗಿರುತ್ತದೆ. ಮತ್ತು ನೀವು 200 ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಸೈಟ್ ಪ್ರತಿ ವಾರವೂ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಇದು ಸಮಸ್ಯೆ.

SQL ಸರ್ವರ್‌ನ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಸುಧಾರಿಸಲು ಏನು ಮಾಡಬಹುದು? ನಿರ್ಮಿಸಲು ವಿಕಿಪೀಡಿಯಾ ನಮ್ಮನ್ನು ಆಹ್ವಾನಿಸುತ್ತದೆ ಹೆಚ್ಚು ಲಭ್ಯವಿರುವ ಕ್ಲಸ್ಟರ್: ಯಾವುದೇ ಘಟಕಗಳ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಒಂದು ಬ್ಯಾಕ್ಅಪ್ ಇರುತ್ತದೆ.

ಇದಕ್ಕೆ ದುಬಾರಿ ಸಲಕರಣೆಗಳ ಸಮೂಹದ ಅಗತ್ಯವಿದೆ: ಹಲವಾರು ನಕಲುಗಳು, ಆಪ್ಟಿಕಲ್ ಫೈಬರ್, ಹಂಚಿಕೆಯ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಮೀಸಲು ಸೇರ್ಪಡೆಯು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ: ಸುಮಾರು 10% ಸ್ವಿಚಿಂಗ್‌ಗಳು ಮುಖ್ಯ ನೋಡ್‌ನ ಹಿಂದೆ ರೈಲಿನಂತೆ ಬ್ಯಾಕಪ್ ನೋಡ್‌ನ ವೈಫಲ್ಯದೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ.

ಆದರೆ ಅಂತಹ ಹೆಚ್ಚು ಲಭ್ಯವಿರುವ ಕ್ಲಸ್ಟರ್‌ನ ಮುಖ್ಯ ಅನನುಕೂಲವೆಂದರೆ ಅದು ಇರುವ ಡೇಟಾ ಸೆಂಟರ್ ವಿಫಲವಾದರೆ ಶೂನ್ಯ ಲಭ್ಯತೆ. Odnoklassniki ನಾಲ್ಕು ಡೇಟಾ ಕೇಂದ್ರಗಳನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಸಂಪೂರ್ಣ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು.

ಇದಕ್ಕಾಗಿ ನಾವು ಬಳಸಬಹುದು ಬಹು-ಮಾಸ್ಟರ್ ಪ್ರತಿಕೃತಿಯನ್ನು SQL ಸರ್ವರ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾಗಿದೆ. ಸಾಫ್ಟ್‌ವೇರ್‌ನ ವೆಚ್ಚದಿಂದಾಗಿ ಈ ಪರಿಹಾರವು ಹೆಚ್ಚು ದುಬಾರಿಯಾಗಿದೆ ಮತ್ತು ಪುನರಾವರ್ತನೆಯೊಂದಿಗಿನ ಪ್ರಸಿದ್ಧ ಸಮಸ್ಯೆಗಳಿಂದ ಬಳಲುತ್ತಿದೆ - ಸಿಂಕ್ರೊನಸ್ ಪುನರಾವರ್ತನೆಯೊಂದಿಗೆ ಅನಿರೀಕ್ಷಿತ ವಹಿವಾಟು ವಿಳಂಬಗಳು ಮತ್ತು ಅಸಮಕಾಲಿಕ ಪ್ರತಿಕೃತಿಯೊಂದಿಗೆ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಅನ್ವಯಿಸುವಲ್ಲಿ ವಿಳಂಬಗಳು (ಮತ್ತು, ಪರಿಣಾಮವಾಗಿ, ಮಾರ್ಪಾಡುಗಳು ಕಳೆದುಹೋಗಿವೆ). ಸೂಚಿಸಲಾಗಿದೆ ಹಸ್ತಚಾಲಿತ ಸಂಘರ್ಷ ಪರಿಹಾರ ಈ ಆಯ್ಕೆಯು ನಮಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಅನ್ವಯಿಸುವುದಿಲ್ಲ.

ಈ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳಿಗೆ ಆಮೂಲಾಗ್ರ ಪರಿಹಾರದ ಅಗತ್ಯವಿದೆ, ಮತ್ತು ನಾವು ಅವುಗಳನ್ನು ವಿವರವಾಗಿ ವಿಶ್ಲೇಷಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಇಲ್ಲಿ ನಾವು SQL ಸರ್ವರ್ ಮುಖ್ಯವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ತಿಳಿದುಕೊಳ್ಳಬೇಕು - ವಹಿವಾಟುಗಳು.

ಸರಳ ವಹಿವಾಟು

ಅನ್ವಯಿಕ SQL ಪ್ರೋಗ್ರಾಮರ್‌ನ ದೃಷ್ಟಿಕೋನದಿಂದ ಸರಳವಾದ ವಹಿವಾಟನ್ನು ಪರಿಗಣಿಸೋಣ: ಆಲ್ಬಮ್‌ಗೆ ಫೋಟೋವನ್ನು ಸೇರಿಸುವುದು. ಆಲ್ಬಮ್‌ಗಳು ಮತ್ತು ಛಾಯಾಚಿತ್ರಗಳನ್ನು ವಿವಿಧ ಪ್ಲೇಟ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಆಲ್ಬಮ್ ಸಾರ್ವಜನಿಕ ಫೋಟೋ ಕೌಂಟರ್ ಅನ್ನು ಹೊಂದಿದೆ. ನಂತರ ಅಂತಹ ವ್ಯವಹಾರವನ್ನು ಈ ಕೆಳಗಿನ ಹಂತಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ:

1. ನಾವು ಕೀಲಿಯಿಂದ ಆಲ್ಬಮ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತೇವೆ.
2. ಫೋಟೋ ಕೋಷ್ಟಕದಲ್ಲಿ ನಮೂದನ್ನು ರಚಿಸಿ.
3. ಫೋಟೋ ಸಾರ್ವಜನಿಕ ಸ್ಥಿತಿಯನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ಆಲ್ಬಮ್‌ಗೆ ಸಾರ್ವಜನಿಕ ಫೋಟೋ ಕೌಂಟರ್ ಅನ್ನು ಸೇರಿಸಿ, ದಾಖಲೆಯನ್ನು ನವೀಕರಿಸಿ ಮತ್ತು ವಹಿವಾಟು ಮಾಡಿ.

ಅಥವಾ ಸೂಡೊಕೋಡ್‌ನಲ್ಲಿ:

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

ಡೇಟಾಬೇಸ್‌ನಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ನ ಮೆಮೊರಿಗೆ ಡೇಟಾವನ್ನು ಓದುವುದು, ಏನನ್ನಾದರೂ ಬದಲಾಯಿಸುವುದು ಮತ್ತು ಹೊಸ ಮೌಲ್ಯಗಳನ್ನು ಡೇಟಾಬೇಸ್‌ಗೆ ಉಳಿಸುವುದು ವ್ಯಾಪಾರ ವಹಿವಾಟಿನ ಸಾಮಾನ್ಯ ಸನ್ನಿವೇಶವಾಗಿದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ. ಸಾಮಾನ್ಯವಾಗಿ ಅಂತಹ ವ್ಯವಹಾರದಲ್ಲಿ ನಾವು ಹಲವಾರು ಘಟಕಗಳನ್ನು, ಹಲವಾರು ಕೋಷ್ಟಕಗಳನ್ನು ನವೀಕರಿಸುತ್ತೇವೆ.

ವಹಿವಾಟನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ, ಇನ್ನೊಂದು ಸಿಸ್ಟಮ್‌ನಿಂದ ಅದೇ ಡೇಟಾದ ಏಕಕಾಲಿಕ ಮಾರ್ಪಾಡು ಸಂಭವಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ಬಳಕೆದಾರರು ಹೇಗಾದರೂ ಅನುಮಾನಾಸ್ಪದರಾಗಿದ್ದಾರೆ ಮತ್ತು ಆದ್ದರಿಂದ ಬಳಕೆದಾರರ ಎಲ್ಲಾ ಫೋಟೋಗಳು ಇನ್ನು ಮುಂದೆ ಸಾರ್ವಜನಿಕವಾಗಿರಬಾರದು ಎಂದು ಆಂಟಿಸ್ಪ್ಯಾಮ್ ನಿರ್ಧರಿಸಬಹುದು, ಅವುಗಳನ್ನು ಮಾಡರೇಶನ್‌ಗಾಗಿ ಕಳುಹಿಸಬೇಕಾಗುತ್ತದೆ, ಅಂದರೆ photo.status ಅನ್ನು ಬೇರೆ ಕೆಲವು ಮೌಲ್ಯಕ್ಕೆ ಬದಲಾಯಿಸುವುದು ಮತ್ತು ಅನುಗುಣವಾದ ಕೌಂಟರ್‌ಗಳನ್ನು ಆಫ್ ಮಾಡುವುದು. ನಿಸ್ಸಂಶಯವಾಗಿ, ಈ ಕಾರ್ಯಾಚರಣೆಯು ಅನ್ವಯದ ಪರಮಾಣು ಮತ್ತು ಸ್ಪರ್ಧಾತ್ಮಕ ಮಾರ್ಪಾಡುಗಳ ಪ್ರತ್ಯೇಕತೆಯ ಖಾತರಿಯಿಲ್ಲದೆ ಸಂಭವಿಸಿದಲ್ಲಿ ಎಸಿಐಡಿ, ನಂತರ ಫಲಿತಾಂಶವು ಅಗತ್ಯವಾಗಿರುವುದಿಲ್ಲ - ಫೋಟೋ ಕೌಂಟರ್ ತಪ್ಪಾದ ಮೌಲ್ಯವನ್ನು ತೋರಿಸುತ್ತದೆ, ಅಥವಾ ಎಲ್ಲಾ ಫೋಟೋಗಳನ್ನು ಮಾಡರೇಶನ್‌ಗಾಗಿ ಕಳುಹಿಸಲಾಗುವುದಿಲ್ಲ.

ಒಂದೇ ವಹಿವಾಟಿನೊಳಗೆ ವಿವಿಧ ವ್ಯಾಪಾರ ಘಟಕಗಳನ್ನು ಕುಶಲತೆಯಿಂದ ನಿರ್ವಹಿಸುವ ಬಹಳಷ್ಟು ರೀತಿಯ ಕೋಡ್ ಅನ್ನು ಓಡ್ನೋಕ್ಲಾಸ್ನಿಕಿಯ ಸಂಪೂರ್ಣ ಅಸ್ತಿತ್ವದ ಉದ್ದಕ್ಕೂ ಬರೆಯಲಾಗಿದೆ. ನಿಂದ NoSQL ಗೆ ವಲಸೆಯ ಅನುಭವದ ಆಧಾರದ ಮೇಲೆ ಅಂತಿಮ ಸ್ಥಿರತೆ ಡೇಟಾ ಸ್ಥಿರತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲು ಕೋಡ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದರಿಂದ ದೊಡ್ಡ ಸವಾಲು (ಮತ್ತು ಸಮಯದ ಹೂಡಿಕೆ) ಬರುತ್ತದೆ ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ. ಆದ್ದರಿಂದ, ಅಪ್ಲಿಕೇಶನ್ ತರ್ಕಕ್ಕಾಗಿ ನೈಜ ACID ವಹಿವಾಟುಗಳಿಗೆ ಹೊಸ ಸಂಗ್ರಹಣೆಯ ಮುಖ್ಯ ಅವಶ್ಯಕತೆಯನ್ನು ನಾವು ಪರಿಗಣಿಸಿದ್ದೇವೆ.

ಇತರ, ಕಡಿಮೆ ಪ್ರಾಮುಖ್ಯತೆ ಇಲ್ಲ, ಅವಶ್ಯಕತೆಗಳು:

• ಡೇಟಾ ಸೆಂಟರ್ ವಿಫಲವಾದರೆ, ಹೊಸ ಸಂಗ್ರಹಣೆಗೆ ಓದುವುದು ಮತ್ತು ಬರೆಯುವುದು ಎರಡೂ ಲಭ್ಯವಿರಬೇಕು.
• ಪ್ರಸ್ತುತ ಅಭಿವೃದ್ಧಿ ವೇಗವನ್ನು ನಿರ್ವಹಿಸುವುದು. ಅಂದರೆ, ಹೊಸ ರೆಪೊಸಿಟರಿಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ, ಕೋಡ್‌ನ ಪ್ರಮಾಣವು ಸರಿಸುಮಾರು ಒಂದೇ ಆಗಿರಬೇಕು; ರೆಪೊಸಿಟರಿಗೆ ಏನನ್ನೂ ಸೇರಿಸುವ ಅಗತ್ಯವಿಲ್ಲ, ಸಂಘರ್ಷಗಳನ್ನು ಪರಿಹರಿಸಲು ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದು, ದ್ವಿತೀಯ ಸೂಚ್ಯಂಕಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು ಇತ್ಯಾದಿ.
• ಡೇಟಾವನ್ನು ಓದುವಾಗ ಮತ್ತು ವಹಿವಾಟುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವಾಗ ಹೊಸ ಸಂಗ್ರಹಣೆಯ ವೇಗವು ಸಾಕಷ್ಟು ಹೆಚ್ಚಿರಬೇಕು, ಇದರರ್ಥ ಶೈಕ್ಷಣಿಕವಾಗಿ ಕಠಿಣ, ಸಾರ್ವತ್ರಿಕ, ಆದರೆ ನಿಧಾನಗತಿಯ ಪರಿಹಾರಗಳು, ಉದಾಹರಣೆಗೆ, ಅನ್ವಯಿಸುವುದಿಲ್ಲ ಎರಡು ಹಂತದ ಬದ್ಧತೆಗಳು.
• ಸ್ವಯಂಚಾಲಿತ ಆನ್-ದಿ-ಫ್ಲೈ ಸ್ಕೇಲಿಂಗ್.
• ವಿಲಕ್ಷಣ ಯಂತ್ರಾಂಶವನ್ನು ಖರೀದಿಸುವ ಅಗತ್ಯವಿಲ್ಲದೇ ನಿಯಮಿತ ಅಗ್ಗದ ಸರ್ವರ್‌ಗಳನ್ನು ಬಳಸುವುದು.
• ಕಂಪನಿ ಡೆವಲಪರ್‌ಗಳಿಂದ ಶೇಖರಣಾ ಅಭಿವೃದ್ಧಿಯ ಸಾಧ್ಯತೆ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಸ್ವಾಮ್ಯದ ಅಥವಾ ಮುಕ್ತ ಮೂಲ ಪರಿಹಾರಗಳಿಗೆ ಆದ್ಯತೆಯನ್ನು ನೀಡಲಾಗಿದೆ, ಮೇಲಾಗಿ ಜಾವಾದಲ್ಲಿ.

ನಿರ್ಧಾರಗಳು, ನಿರ್ಧಾರಗಳು

ಸಂಭವನೀಯ ಪರಿಹಾರಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಿ, ನಾವು ಎರಡು ಸಂಭವನೀಯ ವಾಸ್ತುಶಿಲ್ಪದ ಆಯ್ಕೆಗಳಿಗೆ ಬಂದಿದ್ದೇವೆ:

ಮೊದಲನೆಯದು ಯಾವುದೇ SQL ಸರ್ವರ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು ಮತ್ತು ಅಗತ್ಯವಿರುವ ದೋಷ ಸಹಿಷ್ಣುತೆ, ಸ್ಕೇಲಿಂಗ್ ಕಾರ್ಯವಿಧಾನ, ವೈಫಲ್ಯ ಕ್ಲಸ್ಟರ್, ಸಂಘರ್ಷ ಪರಿಹಾರ ಮತ್ತು ವಿತರಣೆ, ವಿಶ್ವಾಸಾರ್ಹ ಮತ್ತು ವೇಗದ ACID ವಹಿವಾಟುಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು. ನಾವು ಈ ಆಯ್ಕೆಯನ್ನು ಅತ್ಯಂತ ಕ್ಷುಲ್ಲಕ ಮತ್ತು ಶ್ರಮ-ತೀವ್ರ ಎಂದು ರೇಟ್ ಮಾಡಿದ್ದೇವೆ.

ಎರಡನೆಯ ಆಯ್ಕೆಯು ಕಾರ್ಯಗತಗೊಳಿಸಿದ ಸ್ಕೇಲಿಂಗ್, ವೈಫಲ್ಯದ ಕ್ಲಸ್ಟರ್, ಸಂಘರ್ಷ ಪರಿಹಾರದೊಂದಿಗೆ ಸಿದ್ಧ-ನಿರ್ಮಿತ NoSQL ಸಂಗ್ರಹಣೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು ಮತ್ತು ವಹಿವಾಟುಗಳನ್ನು ಮತ್ತು SQL ಅನ್ನು ನೀವೇ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು. ಮೊದಲ ನೋಟದಲ್ಲಿ, ACID ವಹಿವಾಟುಗಳನ್ನು ಉಲ್ಲೇಖಿಸದೆ SQL ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಕಾರ್ಯವು ವರ್ಷಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಕಾರ್ಯದಂತೆ ಕಾಣುತ್ತದೆ. ಆದರೆ ನಾವು ಆಚರಣೆಯಲ್ಲಿ ಬಳಸುವ SQL ವೈಶಿಷ್ಟ್ಯದ ಸೆಟ್ ANSI SQL ನಿಂದ ದೂರವಿದೆ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡೆವು ಕಸ್ಸಂದ್ರ CQL ANSI SQL ನಿಂದ ದೂರ. CQL ಅನ್ನು ಇನ್ನೂ ಹತ್ತಿರದಿಂದ ನೋಡಿದಾಗ, ಅದು ನಮಗೆ ಬೇಕಾದುದಕ್ಕೆ ಹತ್ತಿರದಲ್ಲಿದೆ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡೆವು.

ಕಸ್ಸಂದ್ರ ಮತ್ತು CQL

ಆದ್ದರಿಂದ, ಕಸ್ಸಂದ್ರದ ಬಗ್ಗೆ ಏನು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ, ಅದು ಯಾವ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿದೆ?

ಮೊದಲನೆಯದಾಗಿ, ಇಲ್ಲಿ ನೀವು ವಿವಿಧ ಡೇಟಾ ಪ್ರಕಾರಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಕೋಷ್ಟಕಗಳನ್ನು ರಚಿಸಬಹುದು; ನೀವು ಪ್ರಾಥಮಿಕ ಕೀಲಿಯಲ್ಲಿ ಆಯ್ಕೆಮಾಡಿ ಅಥವಾ ನವೀಕರಿಸಬಹುದು.

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

ಪ್ರತಿಕೃತಿ ಡೇಟಾ ಸ್ಥಿರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ಕಸ್ಸಂದ್ರ ಬಳಸುತ್ತದೆ ಕೋರಂ ವಿಧಾನ. ಸರಳವಾದ ಸಂದರ್ಭದಲ್ಲಿ, ಒಂದೇ ಸಾಲಿನ ಮೂರು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಕ್ಲಸ್ಟರ್‌ನ ವಿವಿಧ ನೋಡ್‌ಗಳಲ್ಲಿ ಇರಿಸಿದಾಗ, ಬಹುಪಾಲು ನೋಡ್‌ಗಳು (ಅಂದರೆ, ಮೂರರಲ್ಲಿ ಎರಡು) ಈ ಬರವಣಿಗೆಯ ಕಾರ್ಯಾಚರಣೆಯ ಯಶಸ್ಸನ್ನು ದೃಢಪಡಿಸಿದರೆ ಬರವಣಿಗೆ ಯಶಸ್ವಿಯಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. . ಓದುವಾಗ, ಬಹುಪಾಲು ನೋಡ್‌ಗಳನ್ನು ಪೋಲ್ ಮಾಡಿದರೆ ಮತ್ತು ಅವುಗಳನ್ನು ದೃಢೀಕರಿಸಿದರೆ ಸಾಲು ಡೇಟಾವನ್ನು ಸ್ಥಿರವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಹೀಗಾಗಿ, ಮೂರು ಪ್ರತಿಕೃತಿಗಳೊಂದಿಗೆ, ಒಂದು ನೋಡ್ ವಿಫಲವಾದಲ್ಲಿ ಸಂಪೂರ್ಣ ಮತ್ತು ತ್ವರಿತ ಡೇಟಾ ಸ್ಥಿರತೆ ಖಾತರಿಪಡಿಸುತ್ತದೆ. ಈ ವಿಧಾನವು ಇನ್ನೂ ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹ ಯೋಜನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು: ಯಾವಾಗಲೂ ಎಲ್ಲಾ ಮೂರು ಪ್ರತಿಕೃತಿಗಳಿಗೆ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸಿ, ಎರಡು ವೇಗವಾದವುಗಳಿಂದ ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ ಕಾಯುತ್ತಿದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ಮೂರನೇ ಪ್ರತಿಕೃತಿಯ ತಡವಾದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ. ಪ್ರತಿಕ್ರಿಯಿಸುವಲ್ಲಿ ತಡವಾಗಿರುವ ನೋಡ್ ಗಂಭೀರ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿರಬಹುದು - ಬ್ರೇಕ್‌ಗಳು, JVM ನಲ್ಲಿ ಕಸ ಸಂಗ್ರಹಣೆ, ಲಿನಕ್ಸ್ ಕರ್ನಲ್‌ನಲ್ಲಿ ನೇರ ಮೆಮೊರಿ ಮರುಪಡೆಯುವಿಕೆ, ಹಾರ್ಡ್‌ವೇರ್ ವೈಫಲ್ಯ, ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಸಂಪರ್ಕ ಕಡಿತ. ಆದಾಗ್ಯೂ, ಇದು ಕ್ಲೈಂಟ್‌ನ ಕಾರ್ಯಾಚರಣೆಗಳು ಅಥವಾ ಡೇಟಾದ ಮೇಲೆ ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.

ನಾವು ಮೂರು ನೋಡ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸಿದಾಗ ಮತ್ತು ಎರಡರಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುವ ವಿಧಾನವನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ಊಹಾಪೋಹ: ಹೆಚ್ಚುವರಿ ಪ್ರತಿಕೃತಿಗಳಿಗಾಗಿ ವಿನಂತಿಯನ್ನು "ಬೀಳುವ" ಮುಂಚೆಯೇ ಕಳುಹಿಸಲಾಗುತ್ತದೆ.

ಕಸ್ಸಂದ್ರದ ಮತ್ತೊಂದು ಪ್ರಯೋಜನವೆಂದರೆ ಬ್ಯಾಚ್‌ಲಾಗ್, ನೀವು ಮಾಡುವ ಬದಲಾವಣೆಗಳ ಬ್ಯಾಚ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅನ್ವಯಿಸಲಾಗಿದೆ ಅಥವಾ ಅನ್ವಯಿಸುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವ ಕಾರ್ಯವಿಧಾನವಾಗಿದೆ. ಇದು ACID ನಲ್ಲಿ A ಅನ್ನು ಪರಿಹರಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ - ಪೆಟ್ಟಿಗೆಯ ಹೊರಗಿನ ಪರಮಾಣು.

ಕಸ್ಸಂದ್ರದಲ್ಲಿನ ವಹಿವಾಟುಗಳಿಗೆ ಹತ್ತಿರದ ವಿಷಯವೆಂದರೆ "ಹಗುರವಾದ ವಹಿವಾಟುಗಳು". ಆದರೆ ಅವರು "ನೈಜ" ACID ವಹಿವಾಟುಗಳಿಂದ ದೂರವಿರುತ್ತಾರೆ: ವಾಸ್ತವವಾಗಿ, ಇದು ಮಾಡಲು ಒಂದು ಅವಕಾಶ ಸಿಎಎಸ್ ಹೆವಿವೇಯ್ಟ್ ಪ್ಯಾಕ್ಸೋಸ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಒಮ್ಮತವನ್ನು ಬಳಸಿಕೊಂಡು ಕೇವಲ ಒಂದು ದಾಖಲೆಯಿಂದ ಡೇಟಾದ ಮೇಲೆ. ಆದ್ದರಿಂದ, ಅಂತಹ ವ್ಯವಹಾರಗಳ ವೇಗ ಕಡಿಮೆಯಾಗಿದೆ.

ಕಸ್ಸಂದ್ರದಲ್ಲಿ ನಾವು ಏನು ಕಳೆದುಕೊಂಡಿದ್ದೇವೆ

ಆದ್ದರಿಂದ, ನಾವು ಕಸ್ಸಂದ್ರದಲ್ಲಿ ನಿಜವಾದ ACID ವಹಿವಾಟುಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾಗಿತ್ತು. ಇದನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಕ್ಲಾಸಿಕ್ DBMS ನ ಇತರ ಎರಡು ಅನುಕೂಲಕರ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸುಲಭವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು: ಸ್ಥಿರವಾದ ವೇಗದ ಸೂಚಿಕೆಗಳು, ಇದು ಪ್ರಾಥಮಿಕ ಕೀಲಿಯಿಂದ ಡೇಟಾ ಆಯ್ಕೆಗಳನ್ನು ಮಾಡಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಏಕತಾನತೆಯ ಸ್ವಯಂ-ಹೆಚ್ಚಳಿಸುವ ID ಗಳ ಸಾಮಾನ್ಯ ಜನರೇಟರ್.

ಸಿ*ಒನ್

ಹೀಗೆ ಹೊಸ ಡಿಬಿಎಂಎಸ್ ಹುಟ್ಟಿಕೊಂಡಿತು ಸಿ*ಒನ್, ಮೂರು ರೀತಿಯ ಸರ್ವರ್ ನೋಡ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:

• ಸಂಗ್ರಹಣೆ - (ಬಹುತೇಕ) ಪ್ರಮಾಣಿತ ಕಸ್ಸಂದ್ರ ಸರ್ವರ್‌ಗಳು ಸ್ಥಳೀಯ ಡಿಸ್ಕ್‌ಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಜವಾಬ್ದಾರರಾಗಿರುತ್ತಾರೆ. ಡೇಟಾದ ಲೋಡ್ ಮತ್ತು ಪರಿಮಾಣವು ಬೆಳೆದಂತೆ, ಅವುಗಳ ಪ್ರಮಾಣವನ್ನು ಸುಲಭವಾಗಿ ಹತ್ತಾರು ಮತ್ತು ನೂರಾರುಗಳಿಗೆ ಅಳೆಯಬಹುದು.
• ವಹಿವಾಟು ಸಂಯೋಜಕರು - ವಹಿವಾಟುಗಳ ಮರಣದಂಡನೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
• ಗ್ರಾಹಕರು ವ್ಯವಹಾರ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮತ್ತು ವಹಿವಾಟುಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗಳು. ಅಂತಹ ಸಾವಿರಾರು ಗ್ರಾಹಕರು ಇರಬಹುದು.

ಎಲ್ಲಾ ರೀತಿಯ ಸರ್ವರ್‌ಗಳು ಸಾಮಾನ್ಯ ಕ್ಲಸ್ಟರ್‌ನ ಭಾಗವಾಗಿದೆ, ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸಲು ಆಂತರಿಕ ಕಸ್ಸಂದ್ರ ಸಂದೇಶ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಿ ಮತ್ತು ಗಾಸಿಪ್ ಕ್ಲಸ್ಟರ್ ಮಾಹಿತಿ ವಿನಿಮಯಕ್ಕಾಗಿ. ಹೃದಯ ಬಡಿತದೊಂದಿಗೆ, ಸರ್ವರ್‌ಗಳು ಪರಸ್ಪರ ವೈಫಲ್ಯಗಳ ಬಗ್ಗೆ ಕಲಿಯುತ್ತವೆ, ಒಂದೇ ಡೇಟಾ ಸ್ಕೀಮಾವನ್ನು ನಿರ್ವಹಿಸುತ್ತವೆ - ಕೋಷ್ಟಕಗಳು, ಅವುಗಳ ರಚನೆ ಮತ್ತು ಪ್ರತಿಕೃತಿ; ವಿಭಜನಾ ಯೋಜನೆ, ಕ್ಲಸ್ಟರ್ ಟೋಪೋಲಜಿ, ಇತ್ಯಾದಿ.

ಗ್ರಾಹಕರು

ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಡ್ರೈವರ್‌ಗಳ ಬದಲಿಗೆ, ಫ್ಯಾಟ್ ಕ್ಲೈಂಟ್ ಮೋಡ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಅಂತಹ ನೋಡ್ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವುದಿಲ್ಲ, ಆದರೆ ವಿನಂತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಂಯೋಜಕರಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು, ಅಂದರೆ, ಕ್ಲೈಂಟ್ ಸ್ವತಃ ಅದರ ವಿನಂತಿಗಳ ಸಂಯೋಜಕರಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ: ಇದು ಶೇಖರಣಾ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಪ್ರಶ್ನಿಸುತ್ತದೆ ಮತ್ತು ಸಂಘರ್ಷಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಇದು ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಡ್ರೈವರ್‌ಗಿಂತ ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹ ಮತ್ತು ವೇಗವಾಗಿರುತ್ತದೆ, ಇದು ರಿಮೋಟ್ ಸಂಯೋಜಕರೊಂದಿಗೆ ಸಂವಹನದ ಅಗತ್ಯವಿರುತ್ತದೆ, ಆದರೆ ವಿನಂತಿಗಳ ಪ್ರಸರಣವನ್ನು ನಿಯಂತ್ರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ತೆರೆದಿರುವ ವಹಿವಾಟಿನ ಹೊರಗೆ, ವಿನಂತಿಗಳನ್ನು ರೆಪೊಸಿಟರಿಗಳಿಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಕ್ಲೈಂಟ್ ವಹಿವಾಟನ್ನು ತೆರೆದಿದ್ದರೆ, ವಹಿವಾಟಿನೊಳಗಿನ ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ವಹಿವಾಟು ಸಂಯೋಜಕರಿಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ.

ಸಿ*ಒನ್ ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಕೋಆರ್ಡಿನೇಟರ್

ಸಂಯೋಜಕರು ನಾವು ಮೊದಲಿನಿಂದ C*Oನ್‌ಗಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೇವೆ. ವಹಿವಾಟುಗಳು, ಲಾಕ್‌ಗಳು ಮತ್ತು ವಹಿವಾಟುಗಳನ್ನು ಅನ್ವಯಿಸುವ ಕ್ರಮವನ್ನು ನಿರ್ವಹಿಸುವ ಜವಾಬ್ದಾರಿಯನ್ನು ಇದು ಹೊಂದಿದೆ.

ಪ್ರತಿ ಸೇವೆಯ ವಹಿವಾಟಿಗೆ, ಸಂಯೋಜಕರು ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ರಚಿಸುತ್ತಾರೆ: ಪ್ರತಿ ನಂತರದ ವಹಿವಾಟು ಹಿಂದಿನ ವಹಿವಾಟಿಗಿಂತ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ. ಕಸ್ಸಂದ್ರದ ಸಂಘರ್ಷ ಪರಿಹಾರ ವ್ಯವಸ್ಥೆಯು ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳನ್ನು ಆಧರಿಸಿರುವುದರಿಂದ (ಎರಡು ಸಂಘರ್ಷದ ದಾಖಲೆಗಳಲ್ಲಿ, ಇತ್ತೀಚಿನ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ಪ್ರಸ್ತುತವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ), ಸಂಘರ್ಷವನ್ನು ಯಾವಾಗಲೂ ನಂತರದ ವಹಿವಾಟಿನ ಪರವಾಗಿ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ. ಹೀಗಾಗಿ ಜಾರಿಗೆ ತಂದಿದ್ದೇವೆ ಲ್ಯಾಂಪ್ಪೋರ್ಟ್ ವಾಚ್ - ವಿತರಿಸಿದ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಸಂಘರ್ಷಗಳನ್ನು ಪರಿಹರಿಸಲು ಅಗ್ಗದ ಮಾರ್ಗ.

ಬೀಗಗಳು

ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ನಾವು ಸರಳವಾದ ವಿಧಾನವನ್ನು ಬಳಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ - ದಾಖಲೆಯ ಪ್ರಾಥಮಿಕ ಕೀಲಿಯನ್ನು ಆಧರಿಸಿ ನಿರಾಶಾವಾದಿ ಬೀಗಗಳು. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ವಹಿವಾಟಿನಲ್ಲಿ, ದಾಖಲೆಯನ್ನು ಮೊದಲು ಲಾಕ್ ಮಾಡಬೇಕು, ನಂತರ ಮಾತ್ರ ಓದಬೇಕು, ಮಾರ್ಪಡಿಸಬೇಕು ಮತ್ತು ಉಳಿಸಬೇಕು. ಯಶಸ್ವಿ ಬದ್ಧತೆಯ ನಂತರವೇ ರೆಕಾರ್ಡ್ ಅನ್ನು ಅನ್‌ಲಾಕ್ ಮಾಡಬಹುದು ಇದರಿಂದ ಸ್ಪರ್ಧಾತ್ಮಕ ವಹಿವಾಟುಗಳು ಅದನ್ನು ಬಳಸಬಹುದು.

ವಿತರಿಸದ ಪರಿಸರದಲ್ಲಿ ಅಂತಹ ಲಾಕ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಸರಳವಾಗಿದೆ. ವಿತರಣಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಎರಡು ಮುಖ್ಯ ಆಯ್ಕೆಗಳಿವೆ: ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ವಿತರಿಸಿದ ಲಾಕ್ ಅನ್ನು ಅಳವಡಿಸಿ ಅಥವಾ ವಹಿವಾಟುಗಳನ್ನು ವಿತರಿಸಿ ಇದರಿಂದ ಒಂದೇ ದಾಖಲೆಯನ್ನು ಒಳಗೊಂಡಿರುವ ವಹಿವಾಟುಗಳು ಯಾವಾಗಲೂ ಅದೇ ಸಂಯೋಜಕರಿಂದ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತವೆ.

ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಡೇಟಾವನ್ನು ಈಗಾಗಲೇ SQL ನಲ್ಲಿನ ಸ್ಥಳೀಯ ವಹಿವಾಟುಗಳ ಗುಂಪುಗಳಲ್ಲಿ ವಿತರಿಸಲಾಗಿರುವುದರಿಂದ, ಸ್ಥಳೀಯ ವಹಿವಾಟು ಗುಂಪುಗಳನ್ನು ಸಂಯೋಜಕರಿಗೆ ನಿಯೋಜಿಸಲು ನಿರ್ಧರಿಸಲಾಗಿದೆ: ಒಬ್ಬ ಸಂಯೋಜಕರು ಎಲ್ಲಾ ವಹಿವಾಟುಗಳನ್ನು 0 ರಿಂದ 9 ರವರೆಗಿನ ಟೋಕನ್‌ಗಳೊಂದಿಗೆ ನಿರ್ವಹಿಸುತ್ತಾರೆ, ಎರಡನೆಯದು - 10 ರಿಂದ 19 ರವರೆಗಿನ ಟೋಕನ್‌ಗಳೊಂದಿಗೆ, ಮತ್ತು ಇತ್ಯಾದಿ. ಪರಿಣಾಮವಾಗಿ, ಪ್ರತಿಯೊಂದು ಸಂಯೋಜಕ ನಿದರ್ಶನಗಳು ವಹಿವಾಟು ಗುಂಪಿನ ಮಾಸ್ಟರ್ ಆಗುತ್ತವೆ.

ನಂತರ ಸಂಯೋಜಕರ ಸ್ಮರಣೆಯಲ್ಲಿ ನೀರಸ ಹ್ಯಾಶ್‌ಮ್ಯಾಪ್ ರೂಪದಲ್ಲಿ ಲಾಕ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು.

ಸಂಯೋಜಕ ವೈಫಲ್ಯಗಳು

ಒಬ್ಬ ಸಂಯೋಜಕರು ಪ್ರತ್ಯೇಕವಾಗಿ ವಹಿವಾಟುಗಳ ಗುಂಪಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುವುದರಿಂದ, ಅದರ ವೈಫಲ್ಯದ ಸತ್ಯವನ್ನು ತ್ವರಿತವಾಗಿ ನಿರ್ಧರಿಸುವುದು ಬಹಳ ಮುಖ್ಯ, ಇದರಿಂದಾಗಿ ವಹಿವಾಟನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಎರಡನೇ ಪ್ರಯತ್ನವು ಸಮಯ ಮೀರುತ್ತದೆ. ಇದನ್ನು ವೇಗವಾಗಿ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿಸಲು, ನಾವು ಸಂಪೂರ್ಣ ಸಂಪರ್ಕಿತ ಕೋರಮ್ ಹಿಯರ್ ಬೀಟ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಿದ್ದೇವೆ:

ಪ್ರತಿ ಡೇಟಾ ಸೆಂಟರ್ ಕನಿಷ್ಠ ಎರಡು ಸಂಯೋಜಕ ನೋಡ್‌ಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡುತ್ತದೆ. ನಿಯತಕಾಲಿಕವಾಗಿ, ಪ್ರತಿ ಸಂಯೋಜಕರು ಇತರ ಸಂಯೋಜಕರಿಗೆ ಹೃದಯ ಬಡಿತದ ಸಂದೇಶವನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ ಮತ್ತು ಅದರ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಬಗ್ಗೆ ಅವರಿಗೆ ತಿಳಿಸುತ್ತಾರೆ, ಹಾಗೆಯೇ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಯಾವ ಸಂಯೋಜಕರಿಂದ ಕೊನೆಯ ಬಾರಿಗೆ ಯಾವ ಹೃದಯ ಬಡಿತ ಸಂದೇಶವನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ.

ತಮ್ಮ ಹೃದಯ ಬಡಿತದ ಸಂದೇಶಗಳ ಭಾಗವಾಗಿ ಇತರರಿಂದ ಇದೇ ರೀತಿಯ ಮಾಹಿತಿಯನ್ನು ಸ್ವೀಕರಿಸುವ ಮೂಲಕ, ಪ್ರತಿ ಸಂಯೋಜಕರು ಕೋರಮ್ ತತ್ವದಿಂದ ಮಾರ್ಗದರ್ಶಿಸಲ್ಪಟ್ಟ ಯಾವ ಕ್ಲಸ್ಟರ್ ನೋಡ್‌ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿವೆ ಮತ್ತು ಯಾವುದು ಅಲ್ಲ ಎಂಬುದನ್ನು ಸ್ವತಃ ನಿರ್ಧರಿಸುತ್ತಾರೆ: ನೋಡ್ ಎಕ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿನ ಹೆಚ್ಚಿನ ನೋಡ್‌ಗಳಿಂದ ಸಾಮಾನ್ಯ ಕುರಿತು ಮಾಹಿತಿಯನ್ನು ಪಡೆದಿದ್ದರೆ ನೋಡ್ Y ನಿಂದ ಸಂದೇಶಗಳ ಸ್ವೀಕೃತಿ, ನಂತರ , Y ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಮತ್ತು ಪ್ರತಿಯಾಗಿ, ಬಹುಪಾಲು ನೋಡ್ Y ನಿಂದ ಕಾಣೆಯಾದ ಸಂದೇಶಗಳನ್ನು ವರದಿ ಮಾಡಿದ ತಕ್ಷಣ, Y ನಿರಾಕರಿಸಿದೆ. ಕೋರಂ ನೋಡ್ X ಗೆ ಇನ್ನು ಮುಂದೆ ಅದರಿಂದ ಸಂದೇಶಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಿಲ್ಲ ಎಂದು ತಿಳಿಸಿದರೆ, ನೋಡ್ X ಸ್ವತಃ ವಿಫಲವಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆ ಎಂಬುದು ಕುತೂಹಲಕಾರಿಯಾಗಿದೆ.

ಹೃದಯ ಬಡಿತದ ಸಂದೇಶಗಳನ್ನು ಹೆಚ್ಚಿನ ಆವರ್ತನದೊಂದಿಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸುಮಾರು 20 ಬಾರಿ, 50 ms ಅವಧಿಯೊಂದಿಗೆ. ಜಾವಾದಲ್ಲಿ, ಕಸ ಸಂಗ್ರಾಹಕದಿಂದ ಉಂಟಾದ ವಿರಾಮಗಳ ಹೋಲಿಸಬಹುದಾದ ಉದ್ದದ ಕಾರಣದಿಂದಾಗಿ 50 ms ಒಳಗೆ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಖಾತರಿಪಡಿಸುವುದು ಕಷ್ಟ. G1 ಕಸ ಸಂಗ್ರಾಹಕವನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಈ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ಸಾಧಿಸಲು ಸಾಧ್ಯವಾಯಿತು, ಇದು GC ವಿರಾಮಗಳ ಅವಧಿಗೆ ಗುರಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಕೆಲವೊಮ್ಮೆ, ಸಾಕಷ್ಟು ವಿರಳವಾಗಿ, ಸಂಗ್ರಾಹಕ 50 ms ಮೀರುತ್ತದೆ, ಇದು ತಪ್ಪು ದೋಷ ಪತ್ತೆಗೆ ಕಾರಣವಾಗಬಹುದು. ಇದು ಸಂಭವಿಸುವುದನ್ನು ತಡೆಯಲು, ಸಂಯೋಜಕರು ರಿಮೋಟ್ ನೋಡ್‌ನಿಂದ ಮೊದಲ ಹೃದಯ ಬಡಿತ ಸಂದೇಶವು ಕಣ್ಮರೆಯಾದಾಗ ಅದರ ವೈಫಲ್ಯವನ್ನು ವರದಿ ಮಾಡುವುದಿಲ್ಲ, ಸತತವಾಗಿ ಹಲವಾರು ಕಣ್ಮರೆಯಾದಾಗ ಮಾತ್ರ. ms.

ಆದರೆ ಯಾವ ನೋಡ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದೆ ಎಂಬುದನ್ನು ತ್ವರಿತವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಕಾಗುವುದಿಲ್ಲ. ನಾವು ಈ ಬಗ್ಗೆ ಏನಾದರೂ ಮಾಡಬೇಕಾಗಿದೆ.

ಮೀಸಲಾತಿ

ಕ್ಲಾಸಿಕ್ ಸ್ಕೀಮ್ ಮಾಸ್ಟರ್ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ, ಒಂದನ್ನು ಬಳಸಿಕೊಂಡು ಹೊಸ ಚುನಾವಣೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಫ್ಯಾಶನ್ ಸಾರ್ವತ್ರಿಕ ಕ್ರಮಾವಳಿಗಳು. ಆದಾಗ್ಯೂ, ಅಂತಹ ಅಲ್ಗಾರಿದಮ್‌ಗಳು ಸಮಯ ಒಮ್ಮುಖ ಮತ್ತು ಚುನಾವಣಾ ಪ್ರಕ್ರಿಯೆಯ ಉದ್ದದೊಂದಿಗೆ ಸುಪರಿಚಿತ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿವೆ. ಸಂಪೂರ್ಣ ಸಂಪರ್ಕಿತ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಸಂಯೋಜಕ ಬದಲಿ ಯೋಜನೆಯನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಅಂತಹ ಹೆಚ್ಚುವರಿ ವಿಳಂಬಗಳನ್ನು ತಪ್ಪಿಸಲು ಸಾಧ್ಯವಾಯಿತು:

ನಾವು ಗುಂಪು 50 ರಲ್ಲಿ ವ್ಯವಹಾರವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಬಯಸುತ್ತೇವೆ ಎಂದು ಹೇಳೋಣ. ಬದಲಿ ಯೋಜನೆಯನ್ನು ಮುಂಚಿತವಾಗಿ ನಿರ್ಧರಿಸೋಣ, ಅಂದರೆ, ಮುಖ್ಯ ಸಂಯೋಜಕನ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಗುಂಪು 50 ರಲ್ಲಿ ಯಾವ ನೋಡ್ಗಳು ವಹಿವಾಟುಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತವೆ. ಡೇಟಾ ಸೆಂಟರ್ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಸಿಸ್ಟಮ್ ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸುವುದು ನಮ್ಮ ಗುರಿಯಾಗಿದೆ. ಮೊದಲ ಮೀಸಲು ಮತ್ತೊಂದು ಡೇಟಾ ಕೇಂದ್ರದಿಂದ ನೋಡ್ ಆಗಿರುತ್ತದೆ ಮತ್ತು ಎರಡನೇ ಮೀಸಲು ಮೂರನೇ ಒಂದು ನೋಡ್ ಆಗಿರುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸೋಣ. ಈ ಯೋಜನೆಯನ್ನು ಒಮ್ಮೆ ಆಯ್ಕೆಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್ನ ಟೋಪೋಲಜಿ ಬದಲಾಗುವವರೆಗೆ ಬದಲಾಗುವುದಿಲ್ಲ, ಅಂದರೆ, ಹೊಸ ನೋಡ್ಗಳು ಅದನ್ನು ಪ್ರವೇಶಿಸುವವರೆಗೆ (ಇದು ಬಹಳ ವಿರಳವಾಗಿ ಸಂಭವಿಸುತ್ತದೆ). ಹಳೆಯದು ವಿಫಲವಾದರೆ ಹೊಸ ಸಕ್ರಿಯ ಮಾಸ್ಟರ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ವಿಧಾನವು ಯಾವಾಗಲೂ ಈ ಕೆಳಗಿನಂತಿರುತ್ತದೆ: ಮೊದಲ ಮೀಸಲು ಸಕ್ರಿಯ ಮಾಸ್ಟರ್ ಆಗುತ್ತದೆ ಮತ್ತು ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದರೆ, ಎರಡನೇ ಮೀಸಲು ಸಕ್ರಿಯ ಮಾಸ್ಟರ್ ಆಗುತ್ತದೆ.

ಈ ಯೋಜನೆಯು ಸಾರ್ವತ್ರಿಕ ಅಲ್ಗಾರಿದಮ್ಗಿಂತ ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ, ಏಕೆಂದರೆ ಹೊಸ ಮಾಸ್ಟರ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು ಹಳೆಯದರ ವೈಫಲ್ಯವನ್ನು ನಿರ್ಧರಿಸಲು ಸಾಕು.

ಆದರೆ ಈಗ ಯಾವ ಮಾಸ್ಟರ್ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಗ್ರಾಹಕರು ಹೇಗೆ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ? 50 ms ನಲ್ಲಿ ಸಾವಿರಾರು ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಮಾಹಿತಿಯನ್ನು ಕಳುಹಿಸುವುದು ಅಸಾಧ್ಯ. ಕ್ಲೈಂಟ್ ವಹಿವಾಟನ್ನು ತೆರೆಯಲು ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿದಾಗ ಪರಿಸ್ಥಿತಿ ಸಾಧ್ಯ, ಈ ಮಾಸ್ಟರ್ ಇನ್ನು ಮುಂದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ ಎಂದು ಇನ್ನೂ ತಿಳಿದಿಲ್ಲ, ಮತ್ತು ವಿನಂತಿಯು ಸಮಯ ಮೀರುತ್ತದೆ. ಇದು ಸಂಭವಿಸುವುದನ್ನು ತಡೆಯಲು, ಕ್ಲೈಂಟ್‌ಗಳು ಊಹಾತ್ಮಕವಾಗಿ ಗುಂಪು ಮಾಸ್ಟರ್‌ಗೆ ಮತ್ತು ಅವರ ಎರಡೂ ಮೀಸಲುಗಳಿಗೆ ಒಮ್ಮೆಗೇ ವಹಿವಾಟು ತೆರೆಯಲು ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ, ಆದರೆ ಈ ಸಮಯದಲ್ಲಿ ಸಕ್ರಿಯ ಮಾಸ್ಟರ್ ಆಗಿರುವವರು ಮಾತ್ರ ಈ ವಿನಂತಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಾರೆ. ಕ್ಲೈಂಟ್ ವ್ಯವಹಾರದೊಳಗೆ ಎಲ್ಲಾ ನಂತರದ ಸಂವಹನವನ್ನು ಸಕ್ರಿಯ ಮಾಸ್ಟರ್ನೊಂದಿಗೆ ಮಾತ್ರ ಮಾಡುತ್ತಾರೆ.

ಬ್ಯಾಕಪ್ ಮಾಸ್ಟರ್‌ಗಳು ತಮ್ಮದಲ್ಲದ ವಹಿವಾಟುಗಳಿಗಾಗಿ ಸ್ವೀಕರಿಸಿದ ವಿನಂತಿಗಳನ್ನು ಹುಟ್ಟಲಿರುವ ವಹಿವಾಟುಗಳ ಸರದಿಯಲ್ಲಿ ಇರಿಸುತ್ತಾರೆ, ಅಲ್ಲಿ ಅವುಗಳನ್ನು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಸಕ್ರಿಯ ಮಾಸ್ಟರ್ ಸತ್ತರೆ, ಹೊಸ ಮಾಸ್ಟರ್ ತನ್ನ ಸರದಿಯಿಂದ ವಹಿವಾಟುಗಳನ್ನು ತೆರೆಯಲು ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಈಗಾಗಲೇ ಹಳೆಯ ಮಾಸ್ಟರ್ನೊಂದಿಗೆ ವ್ಯವಹಾರವನ್ನು ತೆರೆದಿದ್ದರೆ, ನಂತರ ಎರಡನೇ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸಲಾಗುತ್ತದೆ (ಮತ್ತು, ನಿಸ್ಸಂಶಯವಾಗಿ, ಅಂತಹ ವ್ಯವಹಾರವು ಪೂರ್ಣಗೊಳ್ಳುವುದಿಲ್ಲ ಮತ್ತು ಕ್ಲೈಂಟ್ನಿಂದ ಪುನರಾವರ್ತಿಸಲಾಗುತ್ತದೆ).

ವಹಿವಾಟು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ

ಅಂತಹ ಮತ್ತು ಅಂತಹ ಪ್ರಾಥಮಿಕ ಕೀಲಿಯೊಂದಿಗೆ ಅಂತಹ ಮತ್ತು ಅಂತಹ ಘಟಕಕ್ಕಾಗಿ ವಹಿವಾಟು ತೆರೆಯಲು ಕ್ಲೈಂಟ್ ಸಂಯೋಜಕರಿಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿದ್ದಾರೆ ಎಂದು ಹೇಳೋಣ. ಸಂಯೋಜಕರು ಈ ಘಟಕವನ್ನು ಲಾಕ್ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅದನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಲಾಕ್ ಟೇಬಲ್‌ನಲ್ಲಿ ಇರಿಸುತ್ತಾರೆ. ಅಗತ್ಯವಿದ್ದರೆ, ಸಂಯೋಜಕರು ಸಂಗ್ರಹಣೆಯಿಂದ ಈ ಘಟಕವನ್ನು ಓದುತ್ತಾರೆ ಮತ್ತು ಸಂಯೋಜಕನ ಸ್ಮರಣೆಯಲ್ಲಿ ವಹಿವಾಟಿನ ಸ್ಥಿತಿಯಲ್ಲಿ ಪರಿಣಾಮವಾಗಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತಾರೆ.

ಕ್ಲೈಂಟ್ ವಹಿವಾಟಿನಲ್ಲಿ ಡೇಟಾವನ್ನು ಬದಲಾಯಿಸಲು ಬಯಸಿದಾಗ, ಅದು ಘಟಕವನ್ನು ಮಾರ್ಪಡಿಸಲು ಸಂಯೋಜಕರಿಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ಸಂಯೋಜಕರು ಹೊಸ ಡೇಟಾವನ್ನು ವಹಿವಾಟಿನ ಸ್ಥಿತಿ ಕೋಷ್ಟಕದಲ್ಲಿ ಮೆಮೊರಿಯಲ್ಲಿ ಇರಿಸುತ್ತಾರೆ. ಇದು ರೆಕಾರ್ಡಿಂಗ್ ಅನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತದೆ - ಸಂಗ್ರಹಣೆಗೆ ಯಾವುದೇ ರೆಕಾರ್ಡಿಂಗ್ ಮಾಡಲಾಗಿಲ್ಲ.

ಸಕ್ರಿಯ ವಹಿವಾಟಿನ ಭಾಗವಾಗಿ ಕ್ಲೈಂಟ್ ತನ್ನದೇ ಆದ ಬದಲಾದ ಡೇಟಾವನ್ನು ವಿನಂತಿಸಿದಾಗ, ಸಂಯೋಜಕರು ಈ ಕೆಳಗಿನಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾರೆ:

• ID ಈಗಾಗಲೇ ವಹಿವಾಟಿನಲ್ಲಿದ್ದರೆ, ನಂತರ ಡೇಟಾವನ್ನು ಮೆಮೊರಿಯಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ;
• ಮೆಮೊರಿಯಲ್ಲಿ ಯಾವುದೇ ID ಇಲ್ಲದಿದ್ದರೆ, ಕಾಣೆಯಾದ ಡೇಟಾವನ್ನು ಶೇಖರಣಾ ನೋಡ್‌ಗಳಿಂದ ಓದಲಾಗುತ್ತದೆ, ಈಗಾಗಲೇ ಮೆಮೊರಿಯಲ್ಲಿರುವವುಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ನೀಡಲಾಗುತ್ತದೆ.

ಹೀಗಾಗಿ, ಕ್ಲೈಂಟ್ ತನ್ನದೇ ಆದ ಬದಲಾವಣೆಗಳನ್ನು ಓದಬಹುದು, ಆದರೆ ಇತರ ಗ್ರಾಹಕರು ಈ ಬದಲಾವಣೆಗಳನ್ನು ನೋಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅವುಗಳನ್ನು ಸಂಯೋಜಕನ ಸ್ಮರಣೆಯಲ್ಲಿ ಮಾತ್ರ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ; ಅವರು ಇನ್ನೂ ಕಸ್ಸಂದ್ರ ನೋಡ್ಗಳಲ್ಲಿಲ್ಲ.

ಕ್ಲೈಂಟ್ ಕಮಿಟ್ ಅನ್ನು ಕಳುಹಿಸಿದಾಗ, ಸೇವೆಯ ಸ್ಮರಣೆಯಲ್ಲಿರುವ ಸ್ಥಿತಿಯನ್ನು ಸಂಯೋಜಕರು ಲಾಗ್ ಮಾಡಿದ ಬ್ಯಾಚ್‌ನಲ್ಲಿ ಉಳಿಸುತ್ತಾರೆ ಮತ್ತು ಲಾಗ್ ಮಾಡಿದ ಬ್ಯಾಚ್‌ನಂತೆ ಕಸ್ಸಂದ್ರ ಸಂಗ್ರಹಣೆಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಈ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಪರಮಾಣುವಾಗಿ (ಸಂಪೂರ್ಣವಾಗಿ) ಅನ್ವಯಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಅಂಗಡಿಗಳು ಅಗತ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ ಮಾಡುತ್ತವೆ ಮತ್ತು ಸಂಯೋಜಕರಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ, ಅವರು ಲಾಕ್‌ಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗೆ ವಹಿವಾಟಿನ ಯಶಸ್ಸನ್ನು ಖಚಿತಪಡಿಸುತ್ತಾರೆ.

ಮತ್ತು ರೋಲ್‌ಬ್ಯಾಕ್ ಮಾಡಲು, ಸಂಯೋಜಕರು ವಹಿವಾಟಿನ ಸ್ಥಿತಿಯಿಂದ ಆಕ್ರಮಿಸಿಕೊಂಡಿರುವ ಮೆಮೊರಿಯನ್ನು ಮಾತ್ರ ಮುಕ್ತಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ.

ಮೇಲಿನ ಸುಧಾರಣೆಗಳ ಪರಿಣಾಮವಾಗಿ, ನಾವು ACID ತತ್ವಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೇವೆ:

• ಪರಮಾಣುತ್ವ. ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಯಾವುದೇ ವಹಿವಾಟು ಭಾಗಶಃ ದಾಖಲಾಗುವುದಿಲ್ಲ ಎಂಬುದಕ್ಕೆ ಇದು ಖಾತರಿಯಾಗಿದೆ; ಅದರ ಎಲ್ಲಾ ಉಪ ಕಾರ್ಯಾಚರಣೆಗಳು ಪೂರ್ಣಗೊಳ್ಳುತ್ತವೆ, ಅಥವಾ ಯಾವುದೂ ಪೂರ್ಣಗೊಳ್ಳುವುದಿಲ್ಲ. ಕಸ್ಸಂದ್ರದಲ್ಲಿ ಲಾಗ್ ಮಾಡಿದ ಬ್ಯಾಚ್ ಮೂಲಕ ನಾವು ಈ ತತ್ವಕ್ಕೆ ಬದ್ಧರಾಗಿದ್ದೇವೆ.
• ಸ್ಥಿರತೆ. ಪ್ರತಿ ಯಶಸ್ವಿ ವಹಿವಾಟು, ವ್ಯಾಖ್ಯಾನದಿಂದ, ಮಾನ್ಯ ಫಲಿತಾಂಶಗಳನ್ನು ಮಾತ್ರ ದಾಖಲಿಸುತ್ತದೆ. ವಹಿವಾಟನ್ನು ತೆರೆದ ನಂತರ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಗಳ ಭಾಗವನ್ನು ನಿರ್ವಹಿಸಿದ ನಂತರ, ಫಲಿತಾಂಶವು ಅಮಾನ್ಯವಾಗಿದೆ ಎಂದು ಪತ್ತೆಯಾದರೆ, ರೋಲ್ಬ್ಯಾಕ್ ಅನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ.
• ಪ್ರತ್ಯೇಕತೆ. ವ್ಯವಹಾರವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದಾಗ, ಏಕಕಾಲಿಕ ವಹಿವಾಟುಗಳು ಅದರ ಫಲಿತಾಂಶದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬಾರದು. ಸಂಯೋಜಕನ ಮೇಲೆ ನಿರಾಶಾವಾದಿ ಬೀಗಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸ್ಪರ್ಧಾತ್ಮಕ ವಹಿವಾಟುಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲಾಗುತ್ತದೆ. ವಹಿವಾಟಿನ ಹೊರಗಿನ ಓದುವಿಕೆಗಾಗಿ, ಓದು ಬದ್ಧತೆಯ ಮಟ್ಟದಲ್ಲಿ ಪ್ರತ್ಯೇಕತೆಯ ತತ್ವವನ್ನು ಗಮನಿಸಲಾಗುತ್ತದೆ.
• ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವ. ಕೆಳ ಹಂತದ ಸಮಸ್ಯೆಗಳ ಹೊರತಾಗಿ-ಸಿಸ್ಟಮ್ ಬ್ಲ್ಯಾಕೌಟ್, ಹಾರ್ಡ್‌ವೇರ್ ವೈಫಲ್ಯ-ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಂಡ ವಹಿವಾಟಿನಿಂದ ಮಾಡಿದ ಬದಲಾವಣೆಗಳು ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪುನರಾರಂಭಿಸಿದಾಗ ಸಂರಕ್ಷಿಸಲ್ಪಡಬೇಕು.

ಸೂಚ್ಯಂಕಗಳ ಮೂಲಕ ಓದುವುದು

ಸರಳವಾದ ಟೇಬಲ್ ತೆಗೆದುಕೊಳ್ಳೋಣ:

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

ಇದು ID (ಪ್ರಾಥಮಿಕ ಕೀ), ಮಾಲೀಕರು ಮತ್ತು ಮಾರ್ಪಾಡು ದಿನಾಂಕವನ್ನು ಹೊಂದಿದೆ. ನೀವು ತುಂಬಾ ಸರಳವಾದ ವಿನಂತಿಯನ್ನು ಮಾಡಬೇಕಾಗಿದೆ - "ಕೊನೆಯ ದಿನ" ಬದಲಾವಣೆ ದಿನಾಂಕದೊಂದಿಗೆ ಮಾಲೀಕರ ಡೇಟಾವನ್ನು ಆಯ್ಕೆಮಾಡಿ.

SELECT *
WHERE owner=?
AND modified>?

ಅಂತಹ ಪ್ರಶ್ನೆಯನ್ನು ತ್ವರಿತವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು, ಕ್ಲಾಸಿಕ್ SQL DBMS ನಲ್ಲಿ ನೀವು ಕಾಲಮ್‌ಗಳ ಮೂಲಕ ಸೂಚ್ಯಂಕವನ್ನು ನಿರ್ಮಿಸುವ ಅಗತ್ಯವಿದೆ (ಮಾಲೀಕರು, ಮಾರ್ಪಡಿಸಲಾಗಿದೆ). ನಾವು ಈಗ ACID ಗ್ಯಾರಂಟಿಗಳನ್ನು ಹೊಂದಿರುವುದರಿಂದ ನಾವು ಇದನ್ನು ಸುಲಭವಾಗಿ ಮಾಡಬಹುದು!

ಸಿ*ಒನ್‌ನಲ್ಲಿ ಸೂಚ್ಯಂಕಗಳು

ಛಾಯಾಚಿತ್ರಗಳೊಂದಿಗೆ ಮೂಲ ಕೋಷ್ಟಕವಿದೆ, ಅದರಲ್ಲಿ ರೆಕಾರ್ಡ್ ID ಪ್ರಾಥಮಿಕ ಕೀಲಿಯಾಗಿದೆ.

ಸೂಚ್ಯಂಕಕ್ಕಾಗಿ, ಸಿ*ಒನ್ ಹೊಸ ಟೇಬಲ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ ಅದು ಮೂಲ ಪ್ರತಿಯಾಗಿರುತ್ತದೆ. ಕೀಲಿಯು ಸೂಚ್ಯಂಕ ಅಭಿವ್ಯಕ್ತಿಯಂತೆಯೇ ಇರುತ್ತದೆ ಮತ್ತು ಇದು ಮೂಲ ಕೋಷ್ಟಕದಿಂದ ದಾಖಲೆಯ ಪ್ರಾಥಮಿಕ ಕೀಲಿಯನ್ನು ಸಹ ಒಳಗೊಂಡಿದೆ:

ಈಗ "ಕೊನೆಯ ದಿನದ ಮಾಲೀಕರು" ಗಾಗಿ ಪ್ರಶ್ನೆಯನ್ನು ಮತ್ತೊಂದು ಟೇಬಲ್‌ನಿಂದ ಆಯ್ಕೆಯಾಗಿ ಪುನಃ ಬರೆಯಬಹುದು:

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

ಮೂಲ ಕೋಷ್ಟಕದ ಫೋಟೋಗಳಲ್ಲಿನ ಡೇಟಾದ ಸ್ಥಿರತೆ ಮತ್ತು ಇಂಡೆಕ್ಸ್ ಟೇಬಲ್ i1 ಅನ್ನು ಸಂಯೋಜಕರು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿರ್ವಹಿಸುತ್ತಾರೆ. ಡೇಟಾ ಸ್ಕೀಮಾವನ್ನು ಆಧರಿಸಿ, ಬದಲಾವಣೆಯನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ, ಸಂಯೋಜಕರು ಮುಖ್ಯ ಕೋಷ್ಟಕದಲ್ಲಿ ಮಾತ್ರವಲ್ಲದೆ ಪ್ರತಿಗಳಲ್ಲಿಯೂ ಬದಲಾವಣೆಯನ್ನು ರಚಿಸುತ್ತಾರೆ ಮತ್ತು ಸಂಗ್ರಹಿಸುತ್ತಾರೆ. ಸೂಚ್ಯಂಕ ಕೋಷ್ಟಕದಲ್ಲಿ ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಕ್ರಿಯೆಗಳನ್ನು ನಡೆಸಲಾಗುವುದಿಲ್ಲ, ಲಾಗ್‌ಗಳನ್ನು ಓದಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಯಾವುದೇ ಲಾಕ್‌ಗಳನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ. ಅಂದರೆ, ಸೂಚ್ಯಂಕಗಳನ್ನು ಸೇರಿಸುವುದರಿಂದ ಯಾವುದೇ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುವುದಿಲ್ಲ ಮತ್ತು ಮಾರ್ಪಾಡುಗಳನ್ನು ಅನ್ವಯಿಸುವ ವೇಗದ ಮೇಲೆ ವಾಸ್ತವಿಕವಾಗಿ ಯಾವುದೇ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.

ACID ಬಳಸಿ, ನಾವು SQL ತರಹದ ಸೂಚಿಕೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ಅವು ಸ್ಥಿರವಾಗಿರುತ್ತವೆ, ಸ್ಕೇಲೆಬಲ್ ಆಗಿರುತ್ತವೆ, ವೇಗವಾಗಿರುತ್ತವೆ, ಸಂಯೋಜಿಸಬಹುದು ಮತ್ತು CQL ಪ್ರಶ್ನೆ ಭಾಷೆಯಲ್ಲಿ ನಿರ್ಮಿಸಲಾಗಿದೆ. ಸೂಚ್ಯಂಕಗಳನ್ನು ಬೆಂಬಲಿಸಲು ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್‌ಗೆ ಯಾವುದೇ ಬದಲಾವಣೆಗಳ ಅಗತ್ಯವಿಲ್ಲ. SQL ನಲ್ಲಿರುವಂತೆ ಎಲ್ಲವೂ ಸರಳವಾಗಿದೆ. ಮತ್ತು ಮುಖ್ಯವಾಗಿ, ಮೂಲ ವಹಿವಾಟು ಕೋಷ್ಟಕಕ್ಕೆ ಮಾರ್ಪಾಡುಗಳ ಮರಣದಂಡನೆಯ ವೇಗವನ್ನು ಸೂಚ್ಯಂಕಗಳು ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.

ಏನಾಯಿತು

ನಾವು ಮೂರು ವರ್ಷಗಳ ಹಿಂದೆ C*Oನ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ವಾಣಿಜ್ಯ ಕಾರ್ಯಾಚರಣೆಗೆ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ.

ಕೊನೆಯಲ್ಲಿ ನಮಗೆ ಏನು ಸಿಕ್ಕಿತು? ಸಾಮಾಜಿಕ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿನ ಪ್ರಮುಖ ಪ್ರಕಾರದ ಡೇಟಾಗಳಲ್ಲಿ ಒಂದಾದ ಫೋಟೋ ಸಂಸ್ಕರಣೆ ಮತ್ತು ಶೇಖರಣಾ ಉಪವ್ಯವಸ್ಥೆಯ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಇದನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡೋಣ. ನಾವು ಛಾಯಾಚಿತ್ರಗಳ ದೇಹಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿಲ್ಲ, ಆದರೆ ಎಲ್ಲಾ ರೀತಿಯ ಮೆಟಾ-ಮಾಹಿತಿಗಳ ಬಗ್ಗೆ. ಈಗ Odnoklassniki ಸುಮಾರು 20 ಬಿಲಿಯನ್ ಅಂತಹ ದಾಖಲೆಗಳನ್ನು ಹೊಂದಿದೆ, ಸಿಸ್ಟಮ್ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 80 ಸಾವಿರ ಓದುವ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ, ಡೇಟಾ ಮಾರ್ಪಾಡಿಗೆ ಸಂಬಂಧಿಸಿದ ಸೆಕೆಂಡಿಗೆ 8 ಸಾವಿರ ACID ವಹಿವಾಟುಗಳು.

ನಾವು ರೆಪ್ಲಿಕೇಶನ್ ಫ್ಯಾಕ್ಟರ್ = 1 ನೊಂದಿಗೆ SQL ಅನ್ನು ಬಳಸಿದಾಗ (ಆದರೆ RAID 10 ರಲ್ಲಿ), ಮೈಕ್ರೋಸಾಫ್ಟ್ SQL ಸರ್ವರ್ (ಜೊತೆಗೆ 32 ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳು) ಚಾಲನೆಯಲ್ಲಿರುವ 11 ಯಂತ್ರಗಳ ಹೆಚ್ಚು ಲಭ್ಯವಿರುವ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಫೋಟೋ ಮೆಟೈನ್‌ಫರ್ಮೇಶನ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ. ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು 10 ಸರ್ವರ್‌ಗಳನ್ನು ಸಹ ನಿಯೋಜಿಸಲಾಗಿದೆ. ಒಟ್ಟು 50 ದುಬಾರಿ ಕಾರುಗಳು. ಅದೇ ಸಮಯದಲ್ಲಿ, ವ್ಯವಸ್ಥೆಯು ಮೀಸಲು ಇಲ್ಲದೆ, ದರದ ಲೋಡ್ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಹೊಸ ಸಿಸ್ಟಮ್‌ಗೆ ಸ್ಥಳಾಂತರಗೊಂಡ ನಂತರ, ನಾವು ಪ್ರತಿ ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ ನಕಲು ಅಂಶ = 3 ಅನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ. ವ್ಯವಸ್ಥೆಯು 63 ಕಸ್ಸಂದ್ರ ಶೇಖರಣಾ ನೋಡ್‌ಗಳು ಮತ್ತು 6 ಸಂಯೋಜಕ ಯಂತ್ರಗಳನ್ನು ಒಳಗೊಂಡಿದೆ, ಒಟ್ಟು 69 ಸರ್ವರ್‌ಗಳಿಗೆ. ಆದರೆ ಈ ಯಂತ್ರಗಳು ಹೆಚ್ಚು ಅಗ್ಗವಾಗಿವೆ, ಅವುಗಳ ಒಟ್ಟು ವೆಚ್ಚವು SQL ವ್ಯವಸ್ಥೆಯ ವೆಚ್ಚದ ಸುಮಾರು 30% ಆಗಿದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಲೋಡ್ ಅನ್ನು 30% ನಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ.

C*Oನ್‌ನ ಪರಿಚಯದೊಂದಿಗೆ, ಸುಪ್ತತೆಯೂ ಕಡಿಮೆಯಾಯಿತು: SQL ನಲ್ಲಿ, ಬರೆಯುವ ಕಾರ್ಯಾಚರಣೆಯು ಸುಮಾರು 4,5 ms ತೆಗೆದುಕೊಂಡಿತು. C*Oನ್‌ನಲ್ಲಿ - ಸುಮಾರು 1,6 ms. ವಹಿವಾಟಿನ ಅವಧಿಯು ಸರಾಸರಿ 40 ms ಗಿಂತ ಕಡಿಮೆಯಿರುತ್ತದೆ, ಬದ್ಧತೆಯು 2 ms ನಲ್ಲಿ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ, ಓದುವ ಮತ್ತು ಬರೆಯುವ ಅವಧಿಯು ಸರಾಸರಿ 2 ms ಆಗಿದೆ. 99ನೇ ಪರ್ಸೆಂಟೈಲ್ - ಕೇವಲ 3-3,1 ಎಂಎಸ್, ಸಮಯ ಮೀರುವ ಸಂಖ್ಯೆಯು 100 ಪಟ್ಟು ಕಡಿಮೆಯಾಗಿದೆ - ಇವೆಲ್ಲವೂ ಊಹಾಪೋಹದ ವ್ಯಾಪಕ ಬಳಕೆಯಿಂದಾಗಿ.

ಇದೀಗ, ಹೆಚ್ಚಿನ SQL ಸರ್ವರ್ ನೋಡ್‌ಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ; ಹೊಸ ಉತ್ಪನ್ನಗಳನ್ನು ಸಿ*ಒನ್ ಬಳಸಿ ಮಾತ್ರ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗುತ್ತಿದೆ. ನಮ್ಮ ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ನಾವು C*Oನ್ ಅನ್ನು ಅಳವಡಿಸಿಕೊಂಡಿದ್ದೇವೆ ಒಂದು ಮೋಡ, ಇದು ಹೊಸ ಕ್ಲಸ್ಟರ್‌ಗಳ ನಿಯೋಜನೆಯನ್ನು ವೇಗಗೊಳಿಸಲು, ಸಂರಚನೆಯನ್ನು ಸರಳೀಕರಿಸಲು ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗಿಸಿತು. ಮೂಲ ಕೋಡ್ ಇಲ್ಲದೆ, ಇದನ್ನು ಮಾಡುವುದು ಹೆಚ್ಚು ಕಷ್ಟಕರ ಮತ್ತು ತೊಡಕಾಗಿರುತ್ತದೆ.

ಈಗ ನಾವು ನಮ್ಮ ಇತರ ಶೇಖರಣಾ ಸೌಲಭ್ಯಗಳನ್ನು ಕ್ಲೌಡ್‌ಗೆ ವರ್ಗಾಯಿಸಲು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ - ಆದರೆ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಕಥೆಯಾಗಿದೆ.

ಮೂಲ: www.habr.com