ನಿಮ್ಮ ಡೆಲ್ಟಾ ಫೀಡ್ ತಡವಾದ ಕಮಿಟ್‌ಗಳನ್ನು ತಪ್ಪಿಸುತ್ತದೆ: ನಂಬಲರ್ಹ ಕರ್ಸರ್ ನಿರ್ಮಿಸಿ

ಇಲ್ಲಿ ನಾನು ಎರಡು ಬಾರಿ ಕಂಡ ವೈಫಲ್ಯವಿದೆ, ಎರಡು ವಿಭಿನ್ನ ಎಂಜಿನ್‌ಗಳಲ್ಲಿ. ಒಂದು ಎಕ್ಸ್‌ಪೋರ್ಟ್ 10:00ಕ್ಕೆ ಚಲಿಸುತ್ತದೆ ಮತ್ತು ಕಂಡ ಅತ್ಯಧಿಕ ಕೊನೆಯ-ಮಾರ್ಪಾಡಿನ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ದಾಖಲಿಸುತ್ತದೆ. 09:58ಕ್ಕೆ ಪ್ರಾರಂಭವಾದ ಒಂದು ವಹಿವಾಟು ಇನ್ನೂ ತೆರೆದಿದೆ, 10:03ಕ್ಕೆ ಕಮಿಟ್ ಆಗುತ್ತದೆ ಮತ್ತು ತನ್ನ ಪ್ರಾರಂಭದ ಕ್ಷಣದ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಹೊಂದಿದೆ. ಮುಂದಿನ ಎಕ್ಸ್‌ಪೋರ್ಟ್ 10:00ಕ್ಕಿಂತ ಹೊಸ ಸಾಲುಗಳನ್ನು ಮಾತ್ರ ಕೇಳುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ. ವರ್ಗಾವಣೆ ಗಾತ್ರ ಅದ್ಭುತವಾಗಿತ್ತು ಮತ್ತು ಡೇಟಾ ತಪ್ಪಾಗಿತ್ತು.

ಒಂದು ಸಾಲನ್ನು ಕಳೆದುಕೊಂಡ ಎಕ್ಸ್‌ಪೋರ್ಟ್ ಅನ್ನು ಅನುಸರಿಸಿ

SQL ಅಲ್ಲ, ಘಟನೆಗಳ ಕ್ರಮವನ್ನು ಅನುಸರಿಸಿ. ಅಪ್ಲಿಕೇಶನ್ ಸಾಲಿನ ಮಾರ್ಪಾಡು ಸಮಯವನ್ನು ವಹಿವಾಟು ಪ್ರಾರಂಭವಾದಾಗ ಬರೆಯುತ್ತದೆ, ಕಮಿಟ್ ಆದಾಗ ಅಲ್ಲ. ಎಕ್ಸ್‌ಪೋರ್ಟರ್ ಗೋಡೆ-ಗಡಿಯಾರದ ವಾಟರ್‌ಮಾರ್ಕ್ ಓದುತ್ತದೆ ಆ ವಹಿವಾಟು ಇನ್ನೂ ತೆರೆದಿರುವಾಗ. ನಂತರ ವಹಿವಾಟು ಸಂಗ್ರಹಿಸಿದ ವಾಟರ್‌ಮಾರ್ಕ್‌ಗಿಂತ ಹಳೆಯ ಮಾರ್ಪಾಡು ಸಮಯದೊಂದಿಗೆ ಕಮಿಟ್ ಆಗುತ್ತದೆ. ಗ್ರಾಹಕನ ಮುಂದಿನ ಬ್ಯಾಚ್ ವಾಟರ್‌ಮಾರ್ಕ್ ನಂತರ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಾಲು ಕರ್ಸರ್‌ನ ಹಿಂದೆ ಉಳಿಯುತ್ತದೆ ಮತ್ತು ಮತ್ತೆಂದೂ ಆಯ್ಕೆಯಾಗುವುದಿಲ್ಲ.

ಯಾವುದೂ ದೋಷ ದಾಖಲಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಯಾವುದೂ ವಿಫಲವಾಗಿಲ್ಲ. ಇದೇ ಈ ವರ್ಗದ ಬಗ್ ಅನ್ನು ದುಬಾರಿಯಾಗಿಸುತ್ತದೆ: ಡೆಲ್ಟಾ ಫೀಡ್ ವೇಗವಾಗಿದೆ, ಸಾಲು ಎಣಿಕೆ ನಂಬಲರ್ಹವಾಗಿ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಕಾಣೆಯಾದ ಸಾಲು ವಾರಗಳ ನಂತರ ಯಾರೂ ಮತ್ತೆ ರಚಿಸಲಾಗದ ಸಮನ್ವಯ ಟಿಕೆಟ್ ಆಗಿ ಮೇಲೆ ಬರುತ್ತದೆ.

ಕ್ರಮ ಸಂಖ್ಯೆಗಳಿಗೆ ಬೇರೆ ಕಾರಣದಿಂದ ಅದೇ ಆಕಾರದ ದೋಷವಿದೆ. ಏಕರೂಪ ID ಮೌಲ್ಯಗಳನ್ನು ಹಂಚಿದ ಕ್ರಮವನ್ನು ಹೇಳುತ್ತದೆ, ವಹಿವಾಟುಗಳು ಕಮಿಟ್ ಆದ ಕ್ರಮವನ್ನಲ್ಲ. ಕಡಿಮೆ ಸಂಖ್ಯೆ ತೆಗೆದುಕೊಂಡ ವಹಿವಾಟು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆ ತೆಗೆದುಕೊಂಡದ್ದರ ನಂತರ ಕಮಿಟ್ ಆಗಬಹುದು, ಆದ್ದರಿಂದ ಹಂಚಿಕೆ ಕ್ರಮ ಆಧರಿತ ಕರ್ಸರ್ ಕೂಡ ರಂಧ್ರ ಬಿಡಬಹುದು.

ಫೀಡ್ ನೀಡಬೇಕಾದ ಐದು ಭರವಸೆಗಳು

ಸಾರಿಗೆ ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು ಮೂಲ ವ್ಯವಸ್ಥೆಯಿಂದ ಐದು ಷರತ್ತುಗಳ ಒಪ್ಪಂದ ಕೇಳಿ. ಯಾವುದೇ ಷರತ್ತು ಕಾಣೆಯಾದರೆ ನಿಮ್ಮಲ್ಲಿ ಬದಲಾವಣೆ-ಫೀಡ್ ಅಲ್ಲ, ಊಹೆ ಇದೆ.

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

ಬೆಂಬಲಿತ ಕಾರ್ಯವಿಧಾನ ಐದನ್ನೂ ಪೂರೈಸಬಲ್ಲದು. SQL Server ನ ಬದಲಾವಣೆ-ಟ್ರ್ಯಾಕಿಂಗ್ ದಾಖಲೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಪ್ರಕಟಿತ ಉದಾಹರಣೆ: ಅದು ಕನಿಷ್ಠ ಮಾನ್ಯ ಆವೃತ್ತಿಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ಅಳಿಸುವಿಕೆಗಳನ್ನೂ ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಮಾನ್ಯತೆ, ಆವೃತ್ತಿ-ಸೆಳೆತ ಮತ್ತು ಸಂಬಂಧಿತ ಬದಲಾವಣೆ-ಪ್ರಶ್ನೆಗಳನ್ನು ಒಳಗೊಳ್ಳುವ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ವಹಿವಾಟನ್ನು ವಿವರಿಸುತ್ತದೆ. ಇದು ಮೂಲದಿಂದ ಏನನ್ನು ಬೇಡಬೇಕು ಎಂಬುದರ ಉದಾಹರಣೆ, ಬೇರೆ ಎಂಜಿನ್‌ಗೆ ಅಂಟಿಸಬಹುದಾದ ವಾಕ್ಯರಚನೆ ಅಲ್ಲ.

ಚೆಕ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಪೈಪ್‌ಲೈನ್‌ನ ಭಾಗವಾಗಿ ವಿನ್ಯಾಸ ಮಾಡಿ

ಗ್ರಾಹಕನ ಸಂಗ್ರಹಿತ ಸ್ಥಾನವೇ ನಿಜವಾದ ಸ್ಥಿತಿ ಯಂತ್ರ, ಆದ್ದರಿಂದ ಅದನ್ನು ಹಾಗೆಯೇ ಬರೆಯಿರಿ. ಕರ್ಸರ್ ಬ್ಯಾಚ್ ಅನ್ನು ಈಗಾಗಲೇ ಅನ್ವಯಿಸಿ ಗುರಿ ವಹಿವಾಟನ್ನು ಕಮಿಟ್ ಮಾಡಿದ ಕಾರ್ಯಹರಿವಿನ ಮೂಲಕವೇ ಮುಂದೆ ಸಾಗಬಹುದು.

cursor  = durable_checkpoint()          # last fully applied position
batch   = extract(cursor, upper_bound)  # one consistent batch
apply(batch)                            # idempotent at the target
commit()
checkpoint(batch.upper_bound)           # only now

ವಿತರಣೆ ಅರ್ಧದಾರಿಯಲ್ಲಿ ವಿಫಲವಾದರೆ ಹೊಸ ಮೂಲ ಸ್ಥಾನವನ್ನು ಕಲ್ಪಿಸುವ ಬದಲು ಅದೇ ಬ್ಯಾಚ್ ಅನ್ನು ಸಮನ್ವಯ ಮಾಡಿ. ಹೆಚ್ಚು ತಾಜಾ ಮೇಲಿನ ಗಡಿಯೊಂದಿಗೆ ಮತ್ತೆ ಹೊರತೆಗೆಯುವುದೇ ಭಾಗಶಃ ಅನ್ವಯವನ್ನು ಶಾಶ್ವತ ಕಂದಕವಾಗಿಸುವ ದಾರಿ. ಕನ್ನಡಿ ನಿಯಮ ಇನ್ನೊಂದು ಬದಿಯಲ್ಲೂ ಅನ್ವಯಿಸುತ್ತದೆ: ಗುರಿಯಲ್ಲಿ ಐಡೆಂಪೋಟೆಂಟ್ ಅನ್ವಯ ನಕಲುಗಳನ್ನು ತಡೆಯುತ್ತದೆ ಮತ್ತು ಹೊರತೆಗೆಯುವಿಕೆ ಎಂದೂ ಕಾಣದ ಬದಲಾವಣೆಗೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ.

ಅಳಿಸುವಿಕೆಗೆ ದಾಖಲೆ ಬೇಕು, ತೀರ್ಮಾನ ಅಲ್ಲ

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

ಧಾರಣೆಯೂ ಅದೇ ರೀತಿಯ ನಿರ್ಣಯ. ಪ್ರತಿ ಬೆಂಬಲಿತ ಬದಲಾವಣೆ-ಫೀಡ್‌ಗೆ ಒಂದು ಕಿಟಕಿ ಇರುತ್ತದೆ; ಅದನ್ನು ಒಪ್ಪಂದದಲ್ಲಿ ಘೋಷಿಸಿ ಮತ್ತು ಗ್ರಾಹಕನ ಚೆಕ್‌ಪಾಯಿಂಟ್ ಅದನ್ನು ಸಮೀಪಿಸಿದಾಗ ಎಚ್ಚರಿಸಿ. ಎರಡು ವಾರಗಳ ವಿರಾಮದ ನಂತರ ಎಚ್ಚರಗೊಳ್ಳುವ ಗ್ರಾಹಕ ಸದ್ದಿಲ್ಲದೆ ಭಾಗಶಃ ಬ್ಯಾಚ್ ಪಡೆಯುವ ಬದಲು ಸ್ಪಷ್ಟ "ಮರು-ಆರಂಭ ಅಗತ್ಯ" ದೋಷವನ್ನು ಓದಬೇಕು.

ನಂತರ ಡೆಲ್ಟಾ ಯೋಗ್ಯವಾಗಿತ್ತೇ ಎಂದು ಅಳೆಯಿರಿ

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

ಕೊನೆಯ-ಮಾರ್ಪಾಡಿನ ಕಾಲಂ ಒಂದು ಸುಳಿವು. ತಡವಾದ ಕಮಿಟ್, ಅಳಿಸುವಿಕೆ ಮತ್ತು ದೀರ್ಘ ವಿರಾಮವನ್ನು ದಾಟುವ ಕರ್ಸರ್ ಒಂದು ಒಪ್ಪಂದ.