നിങ്ങളുടെ ഡെൽറ്റ ഫീഡ് വൈകിയ കമിറ്റുകൾ നഷ്ടപ്പെടുത്തുന്നു: വിശ്വസനീയമായ കർസർ നിർമ്മിക്കുക

രണ്ട് വ്യത്യസ്ത എഞ്ചിനുകളിൽ രണ്ടുതവണ കണ്ട ഒരു പരാജയമാണ് ഇത്. ഒരു എക്സ്പോർട്ട് 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

ഡെലിവറി പാതിവഴിയിൽ പരാജയപ്പെട്ടാൽ പുതിയ ഉറവിട സ്ഥാനം കണ്ടുപിടിക്കാതെ അതേ ബാച്ച് ഒത്തുതീർപ്പാക്കുക. കൂടുതൽ പുതിയ ഉപരി പരിധിയോടെ വീണ്ടും വേർതിരിച്ചെടുക്കലാണ് ഭാഗിക പ്രയോഗത്തെ സ്ഥിരമായ വിടവാക്കി മാറ്റുന്ന വഴി. കണ്ണാടി നിയമം മറുവശത്തും ബാധകമാണ്: ലക്ഷ്യത്തിലെ ഇഡംപോട്ടന്റ് പ്രയോഗം പകർപ്പുകൾ തടയുന്നു, വേർതിരിച്ചെടുക്കൽ ഒരിക്കലും കണ്ടിട്ടില്ലാത്ത മാറ്റത്തിന് ഒന്നും ചെയ്യുന്നില്ല.

നീക്കലുകൾക്ക് രേഖകൾ വേണം, അനുമാനങ്ങളല്ല

ഇനിയും നിലനിൽക്കുന്ന വരികൾ താരതമ്യം ചെയ്ത് ഏത് കീകൾ അപ്രത്യക്ഷമായി എന്ന് ഉപഭോക്താവിനോട് പറയാനാകില്ല. നീക്കലുകൾ ഒരിക്കലും രേഖപ്പെടുത്താത്ത ഉറവിടം രണ്ട് അപൂർണ വഴികൾ വിടുന്നു: വ്യത്യാസത്തിനായി മതിയായ കാലം കീ ചരിത്രം സൂക്ഷിക്കുക, അല്ലെങ്കിൽ ഷെഡ്യൂൾ അനുസരിച്ച് വ്യക്തമായ പൂർണ ഒത്തുതീർപ്പ് നടത്തുക. രണ്ടും ചെലവുള്ള രൂപകൽപ്പന തീരുമാനങ്ങളാണ്, ആരും ഉടമസ്ഥത എടുക്കാത്തത് നിലനിൽക്കുന്നില്ല.

നിലനിർത്തലും അതേ തരം തീരുമാനമാണ്. പിന്തുണയുള്ള ഓരോ മാറ്റ ഫീഡിനും ഒരു ജാലകമുണ്ട്; അത് കരാറിൽ പ്രഖ്യാപിച്ച് ഉപഭോക്താവിന്റെ ചെക്ക്പോയിന്റ് അതിനടുത്തെത്തുമ്പോൾ മുന്നറിയിപ്പ് നൽകുക. രണ്ട് ആഴ്ചത്തെ തടസ്സത്തിന് ശേഷം ഉണരുന്ന ഉപഭോക്താവ് നിശ്ശബ്ദമായി ഭാഗിക ബാച്ച് സ്വീകരിക്കുന്നതിനുപകരം "പുനഃസ്ഥാപനം ആവശ്യമാണ്" എന്ന വ്യക്തമായ പിശക് വായിക്കണം.

പിന്നീട് ഡെൽറ്റ മൂല്യമുള്ളതായിരുന്നോ എന്ന് അളക്കുക

ഓരോ കീയും ഹാഷും താരതമ്യം ചെയ്യുന്നതിലേക്ക് തിരിച്ചുപോകുന്നത് ചിലപ്പോൾ ശരിയാണ്, അതിന്റെ ചെലവ് അറിയുന്നത് മൂല്യമുള്ളതാണ്. നിങ്ങൾ ഇപ്പോഴും ഓരോ വരിയെക്കുറിച്ചുള്ള വിവരങ്ങൾ കൈമാറുന്നു, ഹാഷുകൾ പട്ടികകൾക്കിടയിൽ സ്ഥിരതയുള്ള സ്നാപ്ഷോട്ട് നൽകുന്നില്ല, ഹാഷ് സ്കീം പ്രാതിനിധ്യത്തെയും കൂട്ടിയിടികളെയും കുറിച്ചുള്ള സ്വന്തം ചോദ്യങ്ങൾ കൊണ്ടുവരുന്നു. പരിശോധിക്കാവുന്ന അതിർത്തിയോടെ കുറഞ്ഞ ബൈറ്റുകളാണ് ലക്ഷ്യം; കമിറ്റ് ചെയ്ത മാറ്റം നിശ്ശബ്ദമായി വീഴ്ത്തുന്ന കുറഞ്ഞ ബൈറ്റുകൾ ഡെൽറ്റയേ അല്ല.

അവസാന-മാറ്റ കോളം ഒരു സൂചനയാണ്. വൈകിയ കമിറ്റ്, നീക്കൽ, നീണ്ട തടസ്സം എന്നിവ അതിജീവിക്കുന്ന കർസറാണ് കരാർ.