എജൈൽ DWH ഡിസൈൻ രീതികളുടെ അവലോകനം

ഒരു സംഭരണ ​​സൗകര്യം വികസിപ്പിക്കുക എന്നത് ദീർഘവും ഗൗരവമേറിയതുമായ ഒരു കാര്യമാണ്.

ഒരു പ്രോജക്റ്റിന്റെ ജീവിതത്തിൽ ഒബ്ജക്റ്റ് മോഡലും അടിസ്ഥാന ഘടനയും തുടക്കത്തിൽ എത്ര നന്നായി ചിന്തിച്ചു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.

സ്റ്റാർ സ്കീമിനെ മൂന്നാമത്തെ സാധാരണ രൂപവുമായി സംയോജിപ്പിക്കുന്നതിനുള്ള വിവിധ വകഭേദങ്ങളാണ് പൊതുവായി അംഗീകരിക്കപ്പെട്ട സമീപനം. ചട്ടം പോലെ, തത്വം അനുസരിച്ച്: പ്രാരംഭ ഡാറ്റ - 3NF, ഷോകേസുകൾ - നക്ഷത്രം. ഒരു വിശകലന ശേഖരം എങ്ങനെയായിരിക്കണം എന്നതിനെക്കുറിച്ച് ചിന്തിക്കുമ്പോൾ, പരിചയസമ്പന്നനായ ഒരു DWH സ്പെഷ്യലിസ്റ്റിന്റെ മനസ്സിൽ വരുന്ന ആദ്യത്തെ (ചിലപ്പോൾ മാത്രം) ഈ സമീപനം, സമയം-പരീക്ഷിച്ചതും ഒരു വലിയ അളവിലുള്ള ഗവേഷണം പിന്തുണയ്ക്കുന്നതുമാണ്.

മറുവശത്ത്, ബിസിനസ്സ് പൊതുവെയും ഉപഭോക്തൃ ആവശ്യകതകൾ പ്രത്യേകിച്ചും പെട്ടെന്ന് മാറുകയും ഡാറ്റ "ആഴത്തിലും" "വിശാലതയിലും" വളരുകയും ചെയ്യുന്നു. ഇവിടെയാണ് ഒരു നക്ഷത്രത്തിന്റെ പ്രധാന പോരായ്മ ദൃശ്യമാകുന്നത് - പരിമിതമാണ് വഴക്കം.

ഒരു DWH ഡെവലപ്പർ എന്ന നിലയിൽ നിങ്ങളുടെ ശാന്തവും സുഖപ്രദവുമായ ജീവിതത്തിൽ പെട്ടെന്ന്:

• "കുറഞ്ഞത് എന്തെങ്കിലും വേഗത്തിൽ ചെയ്യുക, എന്നിട്ട് നമുക്ക് കാണാം" എന്ന ചുമതല ഉയർന്നു.
• പുതിയ സ്രോതസ്സുകളുടെ കണക്ഷനും ആഴ്ചയിൽ ഒരിക്കലെങ്കിലും ബിസിനസ്സ് മോഡലിന്റെ പുനർനിർമ്മാണവും ഉപയോഗിച്ച് അതിവേഗം വികസിച്ചുകൊണ്ടിരിക്കുന്ന ഒരു പ്രോജക്റ്റ് പ്രത്യക്ഷപ്പെട്ടു;
• ഒരു ഉപഭോക്താവ് പ്രത്യക്ഷപ്പെട്ടു, സിസ്റ്റം എങ്ങനെയായിരിക്കണമെന്നും അത് ആത്യന്തികമായി അത് നിർവഹിക്കേണ്ട പ്രവർത്തനങ്ങൾ എന്താണെന്നും അറിയില്ല, എന്നാൽ സ്ഥിരമായി അതിനോട് അടുക്കുമ്പോൾ തന്നെ ആവശ്യമുള്ള ഫലം പരീക്ഷിക്കാനും സ്ഥിരമായി പരിഷ്കരിക്കാനും തയ്യാറാണ്;
• പ്രോജക്റ്റ് മാനേജർ സന്തോഷവാർത്തയുമായി ഇറങ്ങി: "ഇപ്പോൾ ഞങ്ങൾക്ക് ചടുലതയുണ്ട്!"

അല്ലെങ്കിൽ നിങ്ങൾക്ക് മറ്റെങ്ങനെ സ്റ്റോറേജ് സൗകര്യങ്ങൾ നിർമ്മിക്കാമെന്ന് കണ്ടെത്താൻ താൽപ്പര്യമുണ്ടെങ്കിൽ - കട്ടിലേക്ക് സ്വാഗതം!

"ഫ്ലെക്സിബിലിറ്റി" എന്താണ് അർത്ഥമാക്കുന്നത്?

ആദ്യം, "ഫ്ലെക്സിബിൾ" എന്ന് വിളിക്കുന്നതിന് ഒരു സിസ്റ്റത്തിന് എന്തെല്ലാം ഗുണങ്ങൾ ഉണ്ടായിരിക്കണമെന്ന് നമുക്ക് നിർവചിക്കാം.

പ്രത്യേകമായി, വിവരിച്ച പ്രോപ്പർട്ടികൾ പ്രത്യേകമായി ബന്ധപ്പെട്ടിരിക്കണം എന്നത് എടുത്തുപറയേണ്ടതാണ് സിസ്റ്റം, അല്ല പ്രക്രിയ അതിന്റെ വികസനം. അതിനാൽ, എജൈലിനെ ഒരു വികസന രീതി എന്ന നിലയിൽ വായിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, മറ്റ് ലേഖനങ്ങൾ വായിക്കുന്നതാണ് നല്ലത്. ഉദാഹരണത്തിന്, അവിടെ തന്നെ, ഹബ്രെയിൽ, രസകരമായ ധാരാളം മെറ്റീരിയലുകൾ ഉണ്ട് (ഇത് പോലെ അവലോകനം и പ്രായോഗികം, ഒപ്പം പ്രശ്നമുള്ളത്).

ഡാറ്റ വെയർഹൗസിന്റെ വികസന പ്രക്രിയയും ഘടനയും പൂർണ്ണമായും ബന്ധമില്ലാത്തതാണെന്ന് ഇതിനർത്ഥമില്ല. മൊത്തത്തിൽ, ഒരു എജൈൽ ആർക്കിടെക്ചറിനായി ഒരു എജൈൽ റിപ്പോസിറ്ററി വികസിപ്പിക്കുന്നത് വളരെ എളുപ്പമായിരിക്കണം. എന്നിരുന്നാലും, പ്രായോഗികമായി, ഒരു പ്രോജക്റ്റിൽ അതിന്റെ രണ്ട് രൂപങ്ങളിലുള്ള വഴക്കത്തിന്റെ സന്തോഷകരമായ യാദൃശ്ചികതകളേക്കാൾ, വെള്ളച്ചാട്ടമനുസരിച്ച് - കിംബാലിനും ഡാറ്റവോൾട്ടിനും അനുസൃതമായി ക്ലാസിക് DWH-ന്റെ ചടുലമായ വികസനത്തിന് പലപ്പോഴും ഓപ്ഷനുകൾ ഉണ്ട്.

അതിനാൽ, ഫ്ലെക്സിബിൾ സ്റ്റോറേജിന് എന്ത് കഴിവുകൾ ഉണ്ടായിരിക്കണം? ഇവിടെ മൂന്ന് പോയിന്റുകൾ ഉണ്ട്:

1. നേരത്തെയുള്ള ഡെലിവറി, വേഗത്തിലുള്ള വഴിത്തിരിവ് - ഇതിനർത്ഥം, ആദ്യത്തെ ബിസിനസ്സ് ഫലം (ഉദാഹരണത്തിന്, ആദ്യത്തെ പ്രവർത്തന റിപ്പോർട്ടുകൾ) കഴിയുന്നത്ര നേരത്തെ തന്നെ, അതായത്, മുഴുവൻ സിസ്റ്റവും പൂർണ്ണമായി രൂപകൽപ്പന ചെയ്ത് നടപ്പിലാക്കുന്നതിന് മുമ്പ് തന്നെ. മാത്രമല്ല, ഓരോ തുടർന്നുള്ള പുനരവലോകനത്തിനും കഴിയുന്നത്ര കുറച്ച് സമയമെടുക്കും.
2. ആവർത്തന ശുദ്ധീകരണം - ഇതിനർത്ഥം, തുടർന്നുള്ള ഓരോ മെച്ചപ്പെടുത്തലും ഇതിനകം പ്രവർത്തിക്കുന്ന പ്രവർത്തനത്തെ ബാധിക്കരുത് എന്നാണ്. ഈ നിമിഷമാണ് വലിയ പ്രോജക്റ്റുകളിലെ ഏറ്റവും വലിയ പേടിസ്വപ്നമായി മാറുന്നത് - താമസിയാതെ അല്ലെങ്കിൽ പിന്നീട്, വ്യക്തിഗത ഒബ്‌ജക്റ്റുകൾ വളരെയധികം കണക്ഷനുകൾ നേടാൻ തുടങ്ങുന്നു, നിലവിലുള്ള പട്ടികയിലേക്ക് ഒരു ഫീൽഡ് ചേർക്കുന്നതിനേക്കാൾ അടുത്തുള്ള ഒരു പകർപ്പിലെ യുക്തി പൂർണ്ണമായും ആവർത്തിക്കുന്നത് എളുപ്പമാകും. നിലവിലുള്ള ഒബ്‌ജക്‌റ്റുകളിലെ മെച്ചപ്പെടുത്തലുകളുടെ സ്വാധീനം വിശകലനം ചെയ്യുന്നതിന് മെച്ചപ്പെടുത്തലുകളേക്കാൾ കൂടുതൽ സമയമെടുക്കുമെന്ന് നിങ്ങൾ ആശ്ചര്യപ്പെടുന്നുവെങ്കിൽ, നിങ്ങൾ ബാങ്കിംഗിലോ ടെലികോമുകളിലോ വലിയ ഡാറ്റ വെയർഹൗസുകളിൽ ഇതുവരെ പ്രവർത്തിച്ചിട്ടില്ല.
3. മാറിക്കൊണ്ടിരിക്കുന്ന ബിസിനസ്സ് ആവശ്യകതകളുമായി നിരന്തരം പൊരുത്തപ്പെടുന്നു - മൊത്തത്തിലുള്ള ഒബ്ജക്റ്റ് ഘടന രൂപകൽപ്പന ചെയ്യേണ്ടത് സാധ്യമായ വിപുലീകരണം കണക്കിലെടുക്കുക മാത്രമല്ല, ഈ അടുത്ത വിപുലീകരണത്തിന്റെ ദിശ ഡിസൈൻ ഘട്ടത്തിൽ സ്വപ്നം കാണാൻ പോലും കഴിയില്ല എന്ന പ്രതീക്ഷയോടെയാണ്.

അതെ, ഈ ആവശ്യകതകളെല്ലാം ഒരു സിസ്റ്റത്തിൽ നിറവേറ്റുന്നത് സാധ്യമാണ് (തീർച്ചയായും, ചില കേസുകളിലും ചില റിസർവേഷനുകളിലും).

ഡാറ്റാ വെയർഹൗസുകൾക്കായുള്ള ഏറ്റവും ജനപ്രിയമായ രണ്ട് ഡിസൈൻ രീതികൾ ഞാൻ ചുവടെ പരിഗണിക്കും - ആങ്കർ മോഡൽ и ഡാറ്റ വോൾട്ട്. ബ്രാക്കറ്റുകളിൽ അവശേഷിക്കുന്നത് മികച്ച സാങ്കേതിക വിദ്യകളാണ്, ഉദാഹരണത്തിന്, EAV, 6NF (അതിന്റെ ശുദ്ധമായ രൂപത്തിൽ), NoSQL സൊല്യൂഷനുകളുമായി ബന്ധപ്പെട്ട എല്ലാം - അവ എങ്ങനെയെങ്കിലും മോശമായതുകൊണ്ടല്ല, ഈ സാഹചര്യത്തിൽ ലേഖനം ഏറ്റെടുക്കുമെന്ന് ഭീഷണിപ്പെടുത്തുന്നതുകൊണ്ടല്ല. ശരാശരി ഡിസറിന്റെ അളവ്. നിങ്ങളുടെ പ്രോജക്റ്റിന്റെ മൊത്തത്തിലുള്ള ആർക്കിടെക്ചർ (EAV പോലെയുള്ളത്) പരിഗണിക്കാതെ, അല്ലെങ്കിൽ ആഗോളതലത്തിലുള്ള മറ്റ് വിവര സംഭരണ ​​മാതൃകകൾ (ഗ്രാഫ് ഡാറ്റാബേസുകൾ പോലുള്ളവ) പരിഗണിക്കാതെ, പ്രത്യേക സന്ദർഭങ്ങളിൽ നിങ്ങൾക്ക് ഉപയോഗിക്കാനാകുന്ന സാങ്കേതിക വിദ്യകളോട് - ഇതെല്ലാം അല്പം വ്യത്യസ്തമായ ക്ലാസിന്റെ പരിഹാരങ്ങളുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു. മറ്റ് ഓപ്ഷനുകൾ NoSQL).

"ക്ലാസിക്കൽ" സമീപനത്തിന്റെ പ്രശ്നങ്ങളും വഴക്കമുള്ള രീതിശാസ്ത്രത്തിലെ അവയുടെ പരിഹാരങ്ങളും

"ക്ലാസിക്കൽ" സമീപനം എന്നതുകൊണ്ട് ഞാൻ ഉദ്ദേശിക്കുന്നത് നല്ല പഴയ നക്ഷത്രത്തെയാണ് (അടിസ്ഥാന പാളികളുടെ പ്രത്യേക നിർവ്വഹണം പരിഗണിക്കാതെ തന്നെ, കിംബോൾ, ഇൻമോൺ, സിഡിഎം എന്നിവയുടെ അനുയായികൾ എന്നോട് ക്ഷമിക്കട്ടെ).

1. കണക്ഷനുകളുടെ കർക്കശമായ കാർഡിനാലിറ്റി

ഈ മോഡൽ ഡാറ്റയുടെ വ്യക്തമായ വിഭജനത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് അളവ് и വസ്തുതകൾ. ഇത്, നാശം, യുക്തിസഹമാണ് - എല്ലാത്തിനുമുപരി, ഭൂരിഭാഗം കേസുകളിലെയും ഡാറ്റ വിശകലനം ചില വിഭാഗങ്ങളിലെ (മാനങ്ങൾ) ചില സംഖ്യാ സൂചകങ്ങളുടെ (വസ്തുതകൾ) വിശകലനത്തിലേക്ക് വരുന്നു.

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

ഇതിനർത്ഥം, ടേബിൾ ഡിസൈൻ ഘട്ടത്തിൽ, ഓരോ ജോഡി അനുബന്ധ ഒബ്‌ജക്റ്റുകൾക്കും അവയ്ക്ക് ഒന്നിൽ നിന്ന് പലതും അല്ലെങ്കിൽ 1-ൽ നിന്ന് പലതും, "ഏത് ദിശയിൽ" എന്നിവയുമായി ബന്ധപ്പെടുത്താനാകുമോ എന്ന് കൃത്യമായി നിർണ്ണയിക്കണം എന്നാണ്. ഏത് ടേബിളിലാണ് പ്രാഥമിക കീ ഉണ്ടായിരിക്കേണ്ടതെന്നും ഏത് വിദേശ കീ ഉണ്ടായിരിക്കുമെന്നും ഇത് നേരിട്ട് നിർണ്ണയിക്കുന്നു. പുതിയ ആവശ്യകതകൾ ലഭിക്കുമ്പോൾ ഈ മനോഭാവം മാറ്റുന്നത് അടിത്തറയുടെ പുനർനിർമ്മാണത്തിലേക്ക് നയിക്കും.

ഉദാഹരണത്തിന്, "പണ രസീത്" ഒബ്ജക്റ്റ് രൂപകൽപ്പന ചെയ്യുമ്പോൾ, നിങ്ങൾ, സെയിൽസ് ഡിപ്പാർട്ട്മെന്റിന്റെ സത്യവാങ്മൂലത്തെ ആശ്രയിച്ച്, നടപടിയുടെ സാധ്യത നിരത്തി. നിരവധി ചെക്ക് പൊസിഷനുകൾക്ക് ഒരു പ്രമോഷൻ (പക്ഷേ തിരിച്ചും അല്ല):

കുറച്ച് സമയത്തിന് ശേഷം, സഹപ്രവർത്തകർ ഒരു പുതിയ മാർക്കറ്റിംഗ് തന്ത്രം അവതരിപ്പിച്ചു, അതിൽ അവർക്ക് അതേ സ്ഥാനത്ത് പ്രവർത്തിക്കാൻ കഴിയും ഒരേ സമയം നിരവധി പ്രമോഷനുകൾ. ഇപ്പോൾ നിങ്ങൾ ബന്ധത്തെ ഒരു പ്രത്യേക ഒബ്ജക്റ്റായി വേർതിരിച്ചുകൊണ്ട് പട്ടികകൾ പരിഷ്കരിക്കേണ്ടതുണ്ട്.

(പ്രമോഷൻ ചെക്ക് ജോയിൻ ചെയ്തിട്ടുള്ള എല്ലാ ഡിറൈവ്ഡ് ഒബ്ജക്റ്റുകളും ഇപ്പോൾ മെച്ചപ്പെടുത്തേണ്ടതുണ്ട്).

ഡാറ്റ വോൾട്ടിലെയും ആങ്കർ മോഡലിലെയും ബന്ധങ്ങൾ

ഈ സാഹചര്യം ഒഴിവാക്കുന്നത് വളരെ ലളിതമാണ്: ഇത് ചെയ്യുന്നതിന് നിങ്ങൾ വിൽപ്പന വകുപ്പിനെ വിശ്വസിക്കേണ്ടതില്ല. എല്ലാ കണക്ഷനുകളും തുടക്കത്തിൽ പ്രത്യേക പട്ടികകളിൽ സൂക്ഷിക്കുന്നു കൂടാതെ പലതും പലതും ആയി പ്രോസസ്സ് ചെയ്യുക.

ഈ സമീപനം നിർദ്ദേശിച്ചു ഡാൻ ലിൻസ്റ്റഡ് മാതൃകയുടെ ഭാഗമായി ഡാറ്റ വോൾട്ട് പൂർണ്ണ പിന്തുണയും ലാർസ് റോൺബാക്ക് в ആങ്കർ മോഡൽ.

തൽഫലമായി, ഫ്ലെക്സിബിൾ മെത്തഡോളജികളുടെ ആദ്യത്തെ വ്യതിരിക്തമായ സവിശേഷത നമുക്ക് ലഭിക്കുന്നു:

ഒബ്‌ജക്‌റ്റുകൾ തമ്മിലുള്ള ബന്ധങ്ങൾ പാരന്റ് എന്റിറ്റികളുടെ ആട്രിബ്യൂട്ടുകളിൽ സംഭരിക്കപ്പെടുന്നില്ല, മറിച്ച് ഒരു പ്രത്യേക തരം ഒബ്‌ജക്റ്റാണ്.

В ഡാറ്റ വോൾട്ട് അത്തരം ലിങ്കിംഗ് പട്ടികകളെ വിളിക്കുന്നു ബന്ധം, ഒപ്പം ആങ്കർ മോഡൽ - ടൈ. ഒറ്റനോട്ടത്തിൽ, അവ വളരെ സമാനമാണ്, എന്നിരുന്നാലും അവരുടെ വ്യത്യാസങ്ങൾ പേരിൽ അവസാനിക്കുന്നില്ല (അത് ചുവടെ ചർച്ചചെയ്യും). രണ്ട് ആർക്കിടെക്ചറുകളിലും, ലിങ്ക് ടേബിളുകൾക്ക് ലിങ്ക് ചെയ്യാൻ കഴിയും എന്റിറ്റികളുടെ ഏതെങ്കിലും എണ്ണം (2 നിർബന്ധമല്ല).

ഈ ആവർത്തനം, ഒറ്റനോട്ടത്തിൽ, മാറ്റങ്ങൾക്ക് കാര്യമായ വഴക്കം നൽകുന്നു. അത്തരമൊരു ഘടന നിലവിലുള്ള ലിങ്കുകളുടെ കാർഡിനാലിറ്റിയിലെ മാറ്റങ്ങളോട് മാത്രമല്ല, പുതിയവ കൂട്ടിച്ചേർക്കുന്നതിലും സഹിഷ്ണുത കാണിക്കുന്നു - ഇപ്പോൾ ഒരു ചെക്ക് പൊസിഷനും അത് തകർത്ത കാഷ്യറുമായി ഒരു ലിങ്ക് ഉണ്ടെങ്കിൽ, അത്തരമൊരു ലിങ്കിന്റെ രൂപം വളരെ ലളിതമായിരിക്കും. നിലവിലുള്ള ഒബ്‌ജക്‌റ്റുകളെയും പ്രോസസ്സുകളെയും ബാധിക്കാതെ നിലവിലുള്ള ടേബിളുകളിൽ ഒരു ആഡ്-ഓൺ ആകുക.

2. ഡാറ്റ ഡ്യൂപ്ലിക്കേഷൻ

ഫ്ലെക്സിബിൾ ആർക്കിടെക്ചറുകളാൽ പരിഹരിച്ച രണ്ടാമത്തെ പ്രശ്നം വ്യക്തമല്ല, ഒന്നാമതായി അന്തർലീനമാണ്. SCD2 തരം അളവുകൾ (രണ്ടാം തരത്തിന്റെ അളവുകൾ പതുക്കെ മാറ്റുന്നു), അവ മാത്രമല്ല.

ഒരു ക്ലാസിക് വെയർഹൗസിൽ, ഡയമൻഷൻ എന്നത് സാധാരണയായി ഒരു സറോഗേറ്റ് കീയും (ഒരു പികെ ആയി) ഒരു കൂട്ടം ബിസിനസ് കീകളും പ്രത്യേക നിരകളിലെ ആട്രിബ്യൂട്ടുകളും അടങ്ങുന്ന ഒരു പട്ടികയാണ്.

ഒരു ഡൈമൻഷൻ പതിപ്പിംഗിനെ പിന്തുണയ്ക്കുന്നുവെങ്കിൽ, സ്റ്റാൻഡേർഡ് സെറ്റ് ഫീൽഡുകളിലേക്ക് പതിപ്പ് സാധുത പരിധികൾ ചേർക്കും, കൂടാതെ ഉറവിടത്തിലെ ഒരു വരിയിൽ, നിരവധി പതിപ്പുകൾ റിപ്പോസിറ്ററിയിൽ ദൃശ്യമാകും (പതിപ്പ് ചെയ്ത ആട്രിബ്യൂട്ടുകളിലെ ഓരോ മാറ്റത്തിനും ഒന്ന്).

ഒരു ഡയമൻഷനിൽ പതിവായി മാറിക്കൊണ്ടിരിക്കുന്ന ഒരു ആട്രിബ്യൂട്ടെങ്കിലും അടങ്ങിയിട്ടുണ്ടെങ്കിൽ, അത്തരം ഒരു മാനത്തിന്റെ പതിപ്പുകളുടെ എണ്ണം ശ്രദ്ധേയമായിരിക്കും (ബാക്കിയുള്ള ആട്രിബ്യൂട്ടുകൾ പതിപ്പ് ചെയ്തിട്ടില്ലെങ്കിലും അല്ലെങ്കിൽ ഒരിക്കലും മാറുന്നില്ലെങ്കിലും), അത്തരം നിരവധി ആട്രിബ്യൂട്ടുകൾ ഉണ്ടെങ്കിൽ, പതിപ്പുകളുടെ എണ്ണത്തിന് കഴിയും അവരുടെ സംഖ്യയിൽ നിന്ന് ക്രമാതീതമായി വളരുക. ഈ അളവിന് ഗണ്യമായ അളവിൽ ഡിസ്ക് സ്പേസ് എടുക്കാം, എന്നിരുന്നാലും ഇത് സംഭരിക്കുന്ന മിക്ക ഡാറ്റയും മറ്റ് വരികളിൽ നിന്നുള്ള മാറ്റമില്ലാത്ത ആട്രിബ്യൂട്ട് മൂല്യങ്ങളുടെ തനിപ്പകർപ്പാണ്.

അതേസമയം, ഇത് പലപ്പോഴും ഉപയോഗിക്കാറുണ്ട് ഡീനോർമലൈസേഷൻ — ചില ആട്രിബ്യൂട്ടുകൾ മനഃപൂർവം ഒരു മൂല്യമായി സംഭരിച്ചിരിക്കുന്നു, ഒരു റഫറൻസ് പുസ്തകത്തിലേക്കോ മറ്റൊരു മാനത്തിലേക്കോ ഉള്ള ലിങ്കായിട്ടല്ല. ഈ സമീപനം ഡാറ്റ ആക്സസ് വേഗത്തിലാക്കുന്നു, ഒരു അളവ് ആക്സസ് ചെയ്യുമ്പോൾ ചേരുന്നവരുടെ എണ്ണം കുറയ്ക്കുന്നു.

സാധാരണയായി ഇത് നയിക്കുന്നു ഒരേ വിവരങ്ങൾ പല സ്ഥലങ്ങളിലും ഒരേസമയം സംഭരിച്ചിരിക്കുന്നു. ഉദാഹരണത്തിന്, താമസിക്കുന്ന പ്രദേശത്തെയും ക്ലയന്റ് വിഭാഗത്തെയും കുറിച്ചുള്ള വിവരങ്ങൾ ഒരേസമയം “ക്ലയന്റ്” അളവുകളിലും “പർച്ചേസ്”, “ഡെലിവറി”, “കോൾ സെന്റർ കോളുകൾ” വസ്തുതകളിലും “ക്ലയന്റ് - ക്ലയന്റ് മാനേജരിലും” സംഭരിക്കാൻ കഴിയും. "ലിങ്ക് ടേബിൾ.

പൊതുവേ, മുകളിൽ വിവരിച്ചവ സാധാരണ (പതിപ്പ് ചെയ്യാത്ത) അളവുകൾക്ക് ബാധകമാണ്, എന്നാൽ പതിപ്പിൽ അവയ്ക്ക് വ്യത്യസ്ത സ്കെയിൽ ഉണ്ടായിരിക്കാം: ഒരു വസ്തുവിന്റെ ഒരു പുതിയ പതിപ്പിന്റെ രൂപം (പ്രത്യേകിച്ച് മുൻകാലഘട്ടത്തിൽ) ബന്ധപ്പെട്ട എല്ലാ കാര്യങ്ങളുടെയും അപ്ഡേറ്റിലേക്ക് മാത്രമല്ല നയിക്കുന്നത്. പട്ടികകൾ, എന്നാൽ അനുബന്ധ ഒബ്‌ജക്റ്റുകളുടെ പുതിയ പതിപ്പുകളുടെ കാസ്‌കേഡിംഗ് രൂപത്തിലേക്ക് - ടേബിൾ 1 നിർമ്മിക്കാൻ പട്ടിക 2 ഉപയോഗിക്കുമ്പോൾ, പട്ടിക 2 നിർമ്മിക്കാൻ പട്ടിക 3 ഉപയോഗിക്കുമ്പോൾ. ടേബിൾ 1 ന്റെ ഒരു ആട്രിബ്യൂട്ട് പോലും ടേബിൾ 3 ന്റെ നിർമ്മാണത്തിൽ ഉൾപ്പെട്ടിട്ടില്ലെങ്കിലും (മറ്റ് സ്രോതസ്സുകളിൽ നിന്ന് ലഭിച്ച ടേബിൾ 2 ന്റെ മറ്റ് ആട്രിബ്യൂട്ടുകളും ഉൾപ്പെടുന്നു), ഈ നിർമ്മാണം വേർഷൻ ചെയ്യുന്നത് കുറഞ്ഞത് അധിക ഓവർഹെഡിലേക്കും പരമാവധി അധികമായാലും പട്ടിക 3-ലെ പതിപ്പുകൾ. ഇതുമായി ഒരു ബന്ധവുമില്ല, കൂടാതെ ചെയിൻ താഴെയും.

3. പുനർനിർമ്മാണത്തിന്റെ രേഖീയമല്ലാത്ത സങ്കീർണ്ണത

അതേ സമയം, മറ്റൊന്നിന്റെ അടിസ്ഥാനത്തിൽ നിർമ്മിച്ച ഓരോ പുതിയ സ്റ്റോർഫ്രണ്ടും ETL-ൽ മാറ്റങ്ങൾ വരുത്തുമ്പോൾ ഡാറ്റ "വ്യതിചലിപ്പിക്കാൻ" കഴിയുന്ന സ്ഥലങ്ങളുടെ എണ്ണം വർദ്ധിപ്പിക്കുന്നു. ഇത്, ഓരോ തുടർന്നുള്ള പുനരവലോകനത്തിന്റെയും സങ്കീർണ്ണത (കാലാവധി) വർദ്ധിക്കുന്നതിലേക്ക് നയിക്കുന്നു.

അപൂർവ്വമായി പരിഷ്‌ക്കരിച്ച ETL പ്രക്രിയകളുള്ള സിസ്റ്റങ്ങളെയാണ് മുകളിൽ വിവരിക്കുന്നതെങ്കിൽ, നിങ്ങൾക്ക് അത്തരമൊരു മാതൃകയിൽ ജീവിക്കാൻ കഴിയും - എല്ലാ അനുബന്ധ ഒബ്‌ജക്റ്റുകളിലും പുതിയ പരിഷ്‌ക്കരണങ്ങൾ ശരിയായി വരുത്തിയിട്ടുണ്ടെന്ന് നിങ്ങൾ ഉറപ്പാക്കേണ്ടതുണ്ട്. പുനരവലോകനങ്ങൾ പതിവായി സംഭവിക്കുകയാണെങ്കിൽ, നിരവധി കണക്ഷനുകൾ ആകസ്മികമായി "നഷ്‌ടപ്പെടാനുള്ള" സാധ്യത ഗണ്യമായി വർദ്ധിക്കുന്നു.

കൂടാതെ, "പതിപ്പ് ചെയ്ത" ETL "നോൺ പതിപ്പ്" എന്നതിനേക്കാൾ വളരെ സങ്കീർണ്ണമാണെന്ന് ഞങ്ങൾ കണക്കിലെടുക്കുന്നുവെങ്കിൽ, ഈ മുഴുവൻ സൗകര്യവും പതിവായി അപ്ഡേറ്റ് ചെയ്യുമ്പോൾ തെറ്റുകൾ ഒഴിവാക്കുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്.

ഡാറ്റ വോൾട്ടിലും ആങ്കർ മോഡലിലും ഒബ്‌ജക്റ്റുകളും ആട്രിബ്യൂട്ടുകളും സംഭരിക്കുന്നു

ഫ്ലെക്സിബിൾ ആർക്കിടെക്ചറുകളുടെ രചയിതാക്കൾ നിർദ്ദേശിച്ച സമീപനം ഇനിപ്പറയുന്ന രീതിയിൽ രൂപപ്പെടുത്താം:

മാറ്റങ്ങളെ അതേപടി നിലനിൽക്കുന്നതിൽ നിന്ന് വേർതിരിക്കേണ്ടത് ആവശ്യമാണ്. അതായത്, ആട്രിബ്യൂട്ടുകളിൽ നിന്ന് പ്രത്യേകം കീകൾ സംഭരിക്കുക.

എന്നിരുന്നാലും, ഒരാൾ ആശയക്കുഴപ്പത്തിലാക്കരുത് പതിപ്പിച്ചിട്ടില്ല കൂടെ ആട്രിബ്യൂട്ട് മാറ്റമില്ല: ആദ്യത്തേത് അതിന്റെ മാറ്റങ്ങളുടെ ചരിത്രം സംഭരിക്കുന്നില്ല, പക്ഷേ മാറ്റാൻ കഴിയും (ഉദാഹരണത്തിന്, ഒരു ഇൻപുട്ട് പിശക് ശരിയാക്കുമ്പോഴോ പുതിയ ഡാറ്റ സ്വീകരിക്കുമ്പോഴോ); രണ്ടാമത്തേത് ഒരിക്കലും മാറില്ല.

ഡാറ്റ വോൾട്ടിലും ആങ്കർ മോഡലിലും മാറ്റമില്ലാത്തവയായി കണക്കാക്കാവുന്ന കാര്യങ്ങളിൽ കാഴ്ചപ്പാടുകൾ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു.

ഒരു വാസ്തുവിദ്യാ വീക്ഷണകോണിൽ നിന്ന് ഡാറ്റ വോൾട്ട്, മാറ്റമില്ലാതെ കണക്കാക്കാം കീകളുടെ മുഴുവൻ സെറ്റ് - സ്വാഭാവികം (ഓർഗനൈസേഷന്റെ TIN, ഉറവിട സിസ്റ്റത്തിലെ ഉൽപ്പന്ന കോഡ് മുതലായവ) കൂടാതെ സറോഗേറ്റ്. ഈ സാഹചര്യത്തിൽ, മാറ്റങ്ങളുടെ ഉറവിടം കൂടാതെ/അല്ലെങ്കിൽ ആവൃത്തി അനുസരിച്ച് ശേഷിക്കുന്ന ആട്രിബ്യൂട്ടുകളെ ഗ്രൂപ്പുകളായി തിരിക്കാം. ഓരോ ഗ്രൂപ്പിനും ഒരു പ്രത്യേക പട്ടിക സൂക്ഷിക്കുക ഒരു സ്വതന്ത്ര സെറ്റ് പതിപ്പുകൾക്കൊപ്പം.

മാതൃകയിൽ ആങ്കർ മോഡൽ മാറ്റമില്ലാതെ കണക്കാക്കുന്നു വാടക താക്കോൽ മാത്രം സാരാംശം. മറ്റെല്ലാം (സ്വാഭാവിക കീകൾ ഉൾപ്പെടെ) അതിന്റെ ആട്രിബ്യൂട്ടുകളുടെ ഒരു പ്രത്യേക കേസ് മാത്രമാണ്. അതിൽ എല്ലാ ആട്രിബ്യൂട്ടുകളും സ്ഥിരസ്ഥിതിയായി പരസ്പരം സ്വതന്ത്രമാണ്, അതിനാൽ ഓരോ ആട്രിബ്യൂട്ടിനും a പ്രത്യേക പട്ടിക.

В ഡാറ്റ വോൾട്ട് എന്റിറ്റി കീകൾ അടങ്ങിയ പട്ടികകളെ വിളിക്കുന്നു ഹുബാമി. ഹബുകളിൽ എല്ലായ്പ്പോഴും ഒരു നിശ്ചിത ഫീൽഡുകൾ അടങ്ങിയിരിക്കുന്നു:

• സ്വാഭാവിക എന്റിറ്റി കീകൾ
• സറോഗേറ്റ് കീ
• ഉറവിടത്തിലേക്കുള്ള ലിങ്ക്
• റെക്കോർഡ് ചേർക്കുന്ന സമയം

ഹബ്ബുകളിലെ പോസ്റ്റുകൾ ഒരിക്കലും മാറരുത്, പതിപ്പുകൾ ഇല്ല. ബാഹ്യമായി, സറോഗേറ്റുകൾ സൃഷ്ടിക്കാൻ ചില സിസ്റ്റങ്ങളിൽ ഉപയോഗിക്കുന്ന ഐഡി-മാപ്പ് ടൈപ്പ് ടേബിളുകളുമായി ഹബുകൾ വളരെ സാമ്യമുള്ളതാണ്, എന്നിരുന്നാലും, ഡാറ്റ വോൾട്ടിൽ ഒരു കൂട്ടം ബിസിനസ് കീകളിൽ നിന്നുള്ള ഹാഷ് സറോഗേറ്റുകളായി ഉപയോഗിക്കാൻ ശുപാർശ ചെയ്യുന്നു. ഈ സമീപനം സ്രോതസ്സുകളിൽ നിന്നുള്ള ബന്ധങ്ങളും ആട്രിബ്യൂട്ടുകളും ലോഡുചെയ്യുന്നത് ലളിതമാക്കുന്നു (സറോഗേറ്റ് ലഭിക്കുന്നതിന് ഹബിൽ ചേരേണ്ടതില്ല, ഒരു സ്വാഭാവിക കീയുടെ ഹാഷ് കണക്കാക്കിയാൽ മതി), എന്നാൽ മറ്റ് പ്രശ്നങ്ങൾക്ക് കാരണമാകാം (ഉദാഹരണത്തിന്, കൂട്ടിയിടികൾ, കേസ്, അച്ചടിക്കാനാവാത്തവ എന്നിവയുമായി ബന്ധപ്പെട്ടത് സ്ട്രിംഗ് കീകളിലെ പ്രതീകങ്ങൾ മുതലായവ. .p.), അതിനാൽ ഇത് പൊതുവെ അംഗീകരിക്കപ്പെടുന്നില്ല.

മറ്റെല്ലാ എന്റിറ്റി ആട്രിബ്യൂട്ടുകളും പ്രത്യേക പട്ടികകളിൽ സംഭരിച്ചിരിക്കുന്നു ഉപഗ്രഹങ്ങൾ. ഒരു ഹബ്ബിന് വ്യത്യസ്ത സെറ്റ് ആട്രിബ്യൂട്ടുകൾ സംഭരിക്കുന്ന നിരവധി ഉപഗ്രഹങ്ങൾ ഉണ്ടാകാം.

ഉപഗ്രഹങ്ങൾക്കിടയിൽ ആട്രിബ്യൂട്ടുകളുടെ വിതരണം തത്വമനുസരിച്ച് സംഭവിക്കുന്നു സംയുക്ത മാറ്റം — ഒരു ഉപഗ്രഹത്തിൽ നോൺ-വേർഷൻ ചെയ്യാത്ത ആട്രിബ്യൂട്ടുകൾ സൂക്ഷിക്കാൻ കഴിയും (ഉദാഹരണത്തിന്, ഒരു വ്യക്തിക്ക് ജനനത്തീയതിയും SNILS ഉം), മറ്റൊന്നിൽ - അപൂർവ്വമായി മാറ്റുന്ന പതിപ്പുകൾ (ഉദാഹരണത്തിന്, അവസാന നാമവും പാസ്‌പോർട്ട് നമ്പറും), മൂന്നാമത്തേത് - പതിവായി മാറുന്നവ (ഉദാഹരണത്തിന്, ഡെലിവറി വിലാസം, വിഭാഗം, അവസാന ഓർഡറിന്റെ തീയതി മുതലായവ). ഈ സാഹചര്യത്തിൽ, പതിപ്പിംഗ് നടത്തുന്നത് വ്യക്തിഗത ഉപഗ്രഹങ്ങളുടെ തലത്തിലാണ്, അല്ലാതെ എന്റിറ്റി മൊത്തത്തിൽ അല്ല, അതിനാൽ ആട്രിബ്യൂട്ടുകൾ വിതരണം ചെയ്യുന്നത് ഉചിതമാണ്, അതിനാൽ ഒരു ഉപഗ്രഹത്തിനുള്ളിലെ പതിപ്പുകളുടെ വിഭജനം വളരെ കുറവായിരിക്കും (ഇത് സംഭരിച്ചിരിക്കുന്ന മൊത്തം പതിപ്പുകളുടെ എണ്ണം കുറയ്ക്കുന്നു. ).

കൂടാതെ, ഡാറ്റ ലോഡിംഗ് പ്രക്രിയ ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിന്, വിവിധ ഉറവിടങ്ങളിൽ നിന്ന് ലഭിച്ച ആട്രിബ്യൂട്ടുകൾ പലപ്പോഴും വ്യക്തിഗത ഉപഗ്രഹങ്ങളിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്.

ഉപഗ്രഹങ്ങൾ ഹബ്ബുമായി ആശയവിനിമയം നടത്തുന്നു വിദേശ കീ (ഇത് 1 മുതൽ നിരവധി കാർഡിനാലിറ്റിയുമായി യോജിക്കുന്നു). ഇതിനർത്ഥം ഒന്നിലധികം ആട്രിബ്യൂട്ട് മൂല്യങ്ങൾ (ഉദാഹരണത്തിന്, ഒരു ക്ലയന്റിനായി ഒന്നിലധികം കോൺടാക്റ്റ് ഫോൺ നമ്പറുകൾ) ഈ "ഡിഫോൾട്ട്" ആർക്കിടെക്ചർ പിന്തുണയ്ക്കുന്നു എന്നാണ്.

В ആങ്കർ മോഡൽ കീകൾ സൂക്ഷിക്കുന്ന പട്ടികകളെ വിളിക്കുന്നു ആങ്കർമാർ. അവർ സൂക്ഷിക്കുന്നു:

• സറോഗേറ്റ് കീകൾ മാത്രം
• ഉറവിടത്തിലേക്കുള്ള ലിങ്ക്
• റെക്കോർഡ് ചേർക്കുന്ന സമയം

ആങ്കർ മോഡലിന്റെ വീക്ഷണകോണിൽ നിന്നുള്ള സ്വാഭാവിക കീകൾ പരിഗണിക്കപ്പെടുന്നു സാധാരണ ആട്രിബ്യൂട്ടുകൾ. ഈ ഓപ്ഷൻ മനസ്സിലാക്കാൻ കൂടുതൽ ബുദ്ധിമുട്ടാണെന്ന് തോന്നിയേക്കാം, എന്നാൽ ഇത് ഒബ്ജക്റ്റ് തിരിച്ചറിയുന്നതിന് കൂടുതൽ സാധ്യത നൽകുന്നു.

ഉദാഹരണത്തിന്, ഒരേ എന്റിറ്റിയെക്കുറിച്ചുള്ള ഡാറ്റ വ്യത്യസ്ത സിസ്റ്റങ്ങളിൽ നിന്ന് വരാൻ കഴിയുമെങ്കിൽ, ഓരോന്നിനും അതിന്റേതായ സ്വാഭാവിക കീ ഉപയോഗിക്കുന്നു. ഡാറ്റ വോൾട്ടിൽ, ഇത് നിരവധി ഹബുകളുടെ സങ്കീർണ്ണമായ ഘടനകളിലേക്ക് നയിച്ചേക്കാം (ഓരോ ഉറവിടത്തിനും ഒന്ന് + ഒരു ഏകീകൃത മാസ്റ്റർ പതിപ്പ്), അതേസമയം ആങ്കർ മോഡലിൽ, ഓരോ ഉറവിടത്തിന്റെയും സ്വാഭാവിക കീ അതിന്റേതായ ആട്രിബ്യൂട്ടിലേക്ക് വീഴുകയും സ്വതന്ത്രമായി ലോഡ് ചെയ്യുമ്പോൾ ഉപയോഗിക്കുകയും ചെയ്യാം. മറ്റുള്ളവരെല്ലാം.

എന്നാൽ ഇവിടെ ഒരു വഞ്ചനാപരമായ പോയിന്റും ഉണ്ട്: വ്യത്യസ്ത സിസ്റ്റങ്ങളിൽ നിന്നുള്ള ആട്രിബ്യൂട്ടുകൾ ഒരു എന്റിറ്റിയിൽ സംയോജിപ്പിച്ചാൽ, മിക്കവാറും ചിലത് ഉണ്ട് "ഒട്ടിക്കൽ" നിയമങ്ങൾ, വ്യത്യസ്‌ത സ്രോതസ്സുകളിൽ നിന്നുള്ള റെക്കോർഡുകൾ എന്റിറ്റിയുടെ ഒരു സംഭവവുമായി പൊരുത്തപ്പെടുന്നുവെന്ന് സിസ്റ്റം മനസ്സിലാക്കണം.

В ഡാറ്റ വോൾട്ട് ഈ നിയമങ്ങൾ മിക്കവാറും രൂപീകരണം നിർണ്ണയിക്കും മാസ്റ്റർ എന്റിറ്റിയുടെ "സറോഗേറ്റ് ഹബ്" സ്വാഭാവിക ഉറവിട കീകളും അവയുടെ യഥാർത്ഥ ആട്രിബ്യൂട്ടുകളും സംഭരിക്കുന്ന ഹബുകളെ ഒരു തരത്തിലും സ്വാധീനിക്കരുത്. ഏതെങ്കിലും ഘട്ടത്തിൽ ലയന നിയമങ്ങൾ മാറുകയാണെങ്കിൽ (അല്ലെങ്കിൽ അത് നടപ്പിലാക്കുന്ന ആട്രിബ്യൂട്ടുകൾ അപ്‌ഡേറ്റ് ചെയ്‌താൽ), സറോഗേറ്റ് ഹബുകൾ വീണ്ടും ഫോർമാറ്റ് ചെയ്യാൻ ഇത് മതിയാകും.

В ആങ്കർ മോഡൽ അത്തരമൊരു എന്റിറ്റി മിക്കവാറും സംഭരിക്കപ്പെടും ഒരേയൊരു ആങ്കർ. ഇതിനർത്ഥം, എല്ലാ ആട്രിബ്യൂട്ടുകളും, അവ ഏത് ഉറവിടത്തിൽ നിന്ന് വന്നാലും, ഒരേ സറോഗേറ്റിലേക്ക് ബന്ധിക്കപ്പെടും എന്നാണ്. തെറ്റായി ലയിപ്പിച്ച രേഖകൾ വേർതിരിക്കുന്നത്, പൊതുവേ, അത്തരമൊരു സിസ്റ്റത്തിൽ ലയിപ്പിക്കുന്നതിന്റെ പ്രസക്തി നിരീക്ഷിക്കുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്, പ്രത്യേകിച്ചും നിയമങ്ങൾ വളരെ സങ്കീർണ്ണവും ഇടയ്ക്കിടെ മാറുന്നതും, ഒരേ ആട്രിബ്യൂട്ട് വ്യത്യസ്ത ഉറവിടങ്ങളിൽ നിന്ന് ലഭിക്കും (അത് തീർച്ചയായും ആണെങ്കിലും. സാധ്യമാണ്, കാരണം ഓരോ ആട്രിബ്യൂട്ട് പതിപ്പും അതിന്റെ ഉറവിടത്തിലേക്കുള്ള ഒരു ലിങ്ക് നിലനിർത്തുന്നു).

ഏത് സാഹചര്യത്തിലും, നിങ്ങളുടെ സിസ്റ്റം പ്രവർത്തനക്ഷമത നടപ്പിലാക്കേണ്ടതുണ്ടെങ്കിൽ ഡ്യൂപ്ലിക്കേഷൻ, രേഖകൾ ലയിപ്പിക്കൽ, മറ്റ് MDM ഘടകങ്ങൾ, ചടുലമായ രീതിശാസ്ത്രത്തിൽ സ്വാഭാവിക കീകൾ സംഭരിക്കുന്നതിന്റെ വശങ്ങൾ പ്രത്യേകം ശ്രദ്ധിക്കേണ്ടതാണ്. ലയന പിശകുകളുടെ കാര്യത്തിൽ, ബൾക്കിയർ ഡാറ്റ വോൾട്ട് ഡിസൈൻ പെട്ടെന്ന് സുരക്ഷിതമാകാൻ സാധ്യതയുണ്ട്.

ആങ്കർ മോഡൽ എന്ന ഒരു അധിക ഒബ്ജക്റ്റ് തരവും നൽകുന്നു കെട്ട് അത് പ്രധാനമായും സവിശേഷമാണ് ഡീജനറേറ്റ് തരം ആങ്കർ, ഇതിൽ ഒരു ആട്രിബ്യൂട്ട് മാത്രമേ ഉൾക്കൊള്ളാൻ കഴിയൂ. ഫ്ലാറ്റ് ഡയറക്ടറികൾ (ഉദാഹരണത്തിന്, ലിംഗഭേദം, വൈവാഹിക നില, ഉപഭോക്തൃ സേവന വിഭാഗം മുതലായവ) സംഭരിക്കുന്നതിന് നോഡുകൾ ഉപയോഗിക്കേണ്ടതാണ്. ആങ്കറിൽ നിന്ന് വ്യത്യസ്തമായി, കെട്ട് അനുബന്ധ ആട്രിബ്യൂട്ട് പട്ടികകളൊന്നുമില്ല, കൂടാതെ അതിന്റെ ഒരേയൊരു ആട്രിബ്യൂട്ട് (പേര്) എല്ലായ്പ്പോഴും കീ ഉപയോഗിച്ച് ഒരേ പട്ടികയിൽ സൂക്ഷിക്കുന്നു. ആങ്കറുകൾ പരസ്പരം ബന്ധിപ്പിച്ചിരിക്കുന്നതുപോലെ തന്നെ ടൈ ടേബിളുകൾ (ടൈ) വഴി ആങ്കറുകളുമായി നോഡുകൾ ബന്ധിപ്പിച്ചിരിക്കുന്നു.

നോഡുകളുടെ ഉപയോഗത്തെക്കുറിച്ച് വ്യക്തമായ അഭിപ്രായമില്ല. ഉദാഹരണത്തിന്, നിക്കോളായ് ഗോലോവ്, റഷ്യയിൽ ആങ്കർ മോഡലിന്റെ ഉപയോഗം സജീവമായി പ്രോത്സാഹിപ്പിക്കുന്ന, ഒരു റഫറൻസ് പുസ്തകത്തിന് പോലും അത് ഉറപ്പിച്ചു പറയാനാകില്ലെന്ന് (അന്യായമായി അല്ല) വിശ്വസിക്കുന്നു. എപ്പോഴും സ്റ്റാറ്റിക്, സിംഗിൾ-ലെവൽ ആയിരിക്കും, അതിനാൽ എല്ലാ ഒബ്ജക്റ്റുകൾക്കും ഉടനടി ഒരു പൂർണ്ണമായ ആങ്കർ ഉപയോഗിക്കുന്നതാണ് നല്ലത്.

ഡാറ്റ വോൾട്ടും ആങ്കർ മോഡലും തമ്മിലുള്ള മറ്റൊരു പ്രധാന വ്യത്യാസം ലഭ്യതയാണ് കണക്ഷനുകളുടെ ആട്രിബ്യൂട്ടുകൾ:

В ഡാറ്റ വോൾട്ട് ലിങ്കുകൾ ഹബുകളുടെ അതേ പൂർണ്ണമായ ഒബ്‌ജക്‌റ്റുകളാണ്, അവയ്‌ക്ക് ഉണ്ടായിരിക്കാനും കഴിയും സ്വന്തം ആട്രിബ്യൂട്ടുകൾ. ദി ആങ്കർ മോഡൽ ആങ്കറുകളെ ബന്ധിപ്പിക്കുന്നതിന് മാത്രമാണ് ലിങ്കുകൾ ഉപയോഗിക്കുന്നത് സ്വന്തം ആട്രിബ്യൂട്ടുകൾ ഉണ്ടായിരിക്കാൻ കഴിയില്ല. ഈ വ്യത്യാസം വളരെ വ്യത്യസ്തമായ മോഡലിംഗ് സമീപനങ്ങളിൽ കലാശിക്കുന്നു വസ്തുതകൾ, അത് കൂടുതൽ ചർച്ച ചെയ്യും.

വസ്തുത സംഭരണം

ഇതിന് മുമ്പ്, ഞങ്ങൾ പ്രധാനമായും മെഷർമെന്റ് മോഡലിംഗിനെക്കുറിച്ചാണ് സംസാരിച്ചത്. വസ്തുതകൾ കുറച്ചുകൂടി വ്യക്തമല്ല.

В ഡാറ്റ വോൾട്ട് വസ്തുതകൾ സൂക്ഷിക്കുന്നതിനുള്ള ഒരു സാധാരണ വസ്തുവാണ് ലിങ്ക്, ആരുടെ ഉപഗ്രഹങ്ങളിൽ യഥാർത്ഥ സൂചകങ്ങൾ ചേർത്തിരിക്കുന്നു.

ഈ സമീപനം അവബോധജന്യമായി തോന്നുന്നു. ഇത് വിശകലനം ചെയ്‌ത സൂചകങ്ങളിലേക്ക് എളുപ്പത്തിൽ ആക്‌സസ്സ് നൽകുന്നു, സാധാരണയായി ഒരു പരമ്പരാഗത വസ്‌തുത പട്ടികയ്‌ക്ക് സമാനമാണ് (സൂചകങ്ങൾ മാത്രമേ പട്ടികയിലല്ല, “അയൽപക്ക” പട്ടികയിൽ സംഭരിച്ചിട്ടുള്ളൂ). എന്നാൽ അപകടങ്ങളും ഉണ്ട്: മോഡലിന്റെ സാധാരണ പരിഷ്ക്കരണങ്ങളിലൊന്ന് - വസ്തുത കീയുടെ വിപുലീകരണം - ആവശ്യമാണ് ലിങ്കിലേക്ക് ഒരു പുതിയ വിദേശ കീ ചേർക്കുന്നു. ഇത് മോഡുലാരിറ്റിയെ "തകർക്കുന്നു" കൂടാതെ മറ്റ് ഒബ്‌ജക്റ്റുകളിൽ മാറ്റങ്ങൾ വരുത്തേണ്ടതിന്റെ ആവശ്യകതയ്ക്ക് കാരണമാകും.

В ആങ്കർ മോഡൽ ഒരു കണക്ഷന് അതിന്റേതായ ആട്രിബ്യൂട്ടുകൾ ഉണ്ടായിരിക്കില്ല, അതിനാൽ ഈ സമീപനം പ്രവർത്തിക്കില്ല - തീർച്ചയായും എല്ലാ ആട്രിബ്യൂട്ടുകളും സൂചകങ്ങളും ഒരു നിർദ്ദിഷ്ട ആങ്കറുമായി ബന്ധിപ്പിച്ചിരിക്കണം. ഇതിൽ നിന്നുള്ള നിഗമനം ലളിതമാണ് - ഓരോ വസ്തുതയ്ക്കും അതിന്റേതായ ആങ്കർ ആവശ്യമാണ്. വസ്‌തുതകളായി നാം മനസ്സിലാക്കുന്ന ചില കാര്യങ്ങളിൽ, ഇത് സ്വാഭാവികമായി തോന്നാം - ഉദാഹരണത്തിന്, ഒരു വാങ്ങലിന്റെ വസ്തുത “ഓർഡർ” അല്ലെങ്കിൽ “രസീത്” എന്ന ഒബ്‌ജക്റ്റിലേക്ക് പൂർണ്ണമായും ചുരുക്കാം, ഒരു സെഷനിലേക്ക് ഒരു സൈറ്റ് സന്ദർശിക്കുക തുടങ്ങിയവ. എന്നാൽ അത്തരമൊരു സ്വാഭാവിക “കാരിയർ ഒബ്‌ജക്റ്റ്” കണ്ടെത്തുന്നത് അത്ര എളുപ്പമല്ലാത്ത വസ്തുതകളും ഉണ്ട് - ഉദാഹരണത്തിന്, ഓരോ ദിവസത്തിന്റെയും തുടക്കത്തിൽ വെയർഹൗസുകളിലെ സാധനങ്ങളുടെ അവശിഷ്ടങ്ങൾ.

അതനുസരിച്ച്, ആങ്കർ മോഡലിൽ ഒരു ഫാക്റ്റ് കീ വികസിപ്പിക്കുമ്പോൾ മോഡുലാരിറ്റിയുമായി ബന്ധപ്പെട്ട പ്രശ്നങ്ങൾ ഉണ്ടാകില്ല (അനുബന്ധ ആങ്കറിലേക്ക് ഒരു പുതിയ ബന്ധം ചേർത്താൽ മതി), എന്നാൽ വസ്തുതകൾ പ്രദർശിപ്പിക്കുന്നതിന് ഒരു മോഡൽ രൂപകൽപ്പന ചെയ്യുന്നത് അവ്യക്തമാണ്; "കൃത്രിമ" ആങ്കറുകൾ പ്രത്യക്ഷപ്പെടാം. ബിസിനസ്സ് ഒബ്ജക്റ്റ് മോഡൽ അവ്യക്തമായ രീതിയിൽ പ്രദർശിപ്പിക്കുന്നു.

എങ്ങനെയാണ് വഴക്കം കൈവരിക്കുന്നത്

രണ്ട് കേസുകളിലും തത്ഫലമായുണ്ടാകുന്ന നിർമ്മാണത്തിൽ അടങ്ങിയിരിക്കുന്നു ഗണ്യമായി കൂടുതൽ പട്ടികകൾപരമ്പരാഗത അളവുകളേക്കാൾ. പക്ഷേ അത് എടുത്തേക്കാം ഡിസ്ക് സ്പേസ് ഗണ്യമായി കുറവാണ് പരമ്പരാഗത അളവിലുള്ള അതേ പതിപ്പ് ആട്രിബ്യൂട്ടുകൾക്കൊപ്പം. സ്വാഭാവികമായും, ഇവിടെ മാന്ത്രികതയില്ല - ഇതെല്ലാം സാധാരണവൽക്കരണത്തെക്കുറിച്ചാണ്. ഉപഗ്രഹങ്ങളിൽ (ഡാറ്റ വോൾട്ടിൽ) അല്ലെങ്കിൽ വ്യക്തിഗത പട്ടികകളിൽ (ആങ്കർ മോഡൽ) ഉടനീളം ആട്രിബ്യൂട്ടുകൾ വിതരണം ചെയ്യുന്നതിലൂടെ, ഞങ്ങൾ കുറയ്ക്കുന്നു (അല്ലെങ്കിൽ പൂർണ്ണമായും ഇല്ലാതാക്കുന്നു) മറ്റുള്ളവ മാറ്റുമ്പോൾ ചില ആട്രിബ്യൂട്ടുകളുടെ മൂല്യങ്ങളുടെ തനിപ്പകർപ്പ്.

വേണ്ടി ഡാറ്റ വോൾട്ട് വിജയങ്ങൾ ഉപഗ്രഹങ്ങൾക്കിടയിലുള്ള ആട്രിബ്യൂട്ടുകളുടെ വിതരണത്തെ ആശ്രയിച്ചിരിക്കും ആങ്കർ മോഡൽ - ഒരു മെഷർമെന്റ് ഒബ്‌ജക്‌റ്റിന്റെ ശരാശരി പതിപ്പുകളുടെ എണ്ണത്തിന് ഏതാണ്ട് നേരിട്ട് ആനുപാതികമാണ്.

എന്നിരുന്നാലും, ആട്രിബ്യൂട്ടുകൾ വെവ്വേറെ സംഭരിക്കുന്നതിനുള്ള ഒരു പ്രധാന നേട്ടമാണ്, എന്നാൽ പ്രധാനമല്ല, സ്പേസ് സേവിംഗ്സ്. ബന്ധങ്ങളുടെ പ്രത്യേക സംഭരണത്തോടൊപ്പം, ഈ സമീപനം സ്റ്റോർ ഉണ്ടാക്കുന്നു മോഡുലാർ ഡിസൈൻ. അത്തരമൊരു മാതൃകയിൽ വ്യക്തിഗത ആട്രിബ്യൂട്ടുകളും മുഴുവൻ പുതിയ വിഷയ മേഖലകളും ചേർക്കുന്നത് ഇതുപോലെ കാണപ്പെടുന്നു എന്നാണ് ഇതിനർത്ഥം മേൽപ്പാലം നിലവിലുള്ള ഒരു കൂട്ടം ഒബ്‌ജക്‌റ്റുകൾ മാറ്റാതെ തന്നെ. വിവരിച്ച രീതിശാസ്ത്രങ്ങളെ വഴക്കമുള്ളതാക്കുന്നത് ഇതാണ്.

ഇത് കഷണം ഉൽപ്പാദനത്തിൽ നിന്ന് വൻതോതിലുള്ള ഉൽപാദനത്തിലേക്കുള്ള പരിവർത്തനത്തെ സാമ്യപ്പെടുത്തുന്നു - പരമ്പരാഗത സമീപനത്തിൽ മോഡലിന്റെ ഓരോ പട്ടികയും അദ്വിതീയവും പ്രത്യേക ശ്രദ്ധ ആവശ്യമാണെങ്കിൽ, വഴക്കമുള്ള രീതികളിൽ ഇത് ഇതിനകം തന്നെ സ്റ്റാൻഡേർഡ് “ഭാഗങ്ങളുടെ” ഒരു കൂട്ടമാണ്. ഒരു വശത്ത്, കൂടുതൽ പട്ടികകൾ ഉണ്ട്, ഡാറ്റ ലോഡുചെയ്യുന്നതിനും വീണ്ടെടുക്കുന്നതിനുമുള്ള പ്രക്രിയകൾ കൂടുതൽ സങ്കീർണ്ണമായി കാണപ്പെടും. മറുവശത്ത്, അവർ മാറുന്നു സാധാരണ. അതിനർത്ഥം ഉണ്ടായിരിക്കാം ഓട്ടോമേറ്റഡ്, മെറ്റാഡാറ്റ ഡ്രൈവ്. “ഞങ്ങൾ ഇത് എങ്ങനെ സ്ഥാപിക്കും?” എന്ന ചോദ്യം, മെച്ചപ്പെടുത്തലുകൾ രൂപകൽപ്പന ചെയ്യുന്നതിനുള്ള ജോലിയുടെ ഒരു പ്രധാന ഭാഗം ഏറ്റെടുക്കാൻ കഴിയുന്ന ഉത്തരം, ഇപ്പോൾ അത് വിലമതിക്കുന്നില്ല (അതുപോലെ തന്നെ പ്രവർത്തന പ്രക്രിയകളിൽ മോഡൽ മാറ്റുന്നതിന്റെ സ്വാധീനത്തെക്കുറിച്ചുള്ള ചോദ്യവും. ).

അത്തരമൊരു സിസ്റ്റത്തിൽ അനലിസ്റ്റുകൾ ആവശ്യമില്ലെന്ന് ഇതിനർത്ഥമില്ല - ആരെങ്കിലും ഇപ്പോഴും ആട്രിബ്യൂട്ടുകളുള്ള ഒബ്‌ജക്റ്റുകളുടെ കൂട്ടത്തിലൂടെ പ്രവർത്തിക്കുകയും എല്ലാം എവിടെ, എങ്ങനെ ലോഡ് ചെയ്യണമെന്ന് കണ്ടെത്തുകയും ചെയ്യേണ്ടതുണ്ട്. എന്നാൽ ജോലിയുടെ അളവും ഒരു പിശകിന്റെ സാധ്യതയും വിലയും ഗണ്യമായി കുറയുന്നു. വിശകലന ഘട്ടത്തിലും ETL-ന്റെ വികസന സമയത്തും, ഇത് മെറ്റാഡാറ്റ എഡിറ്റുചെയ്യുന്നതിലേക്ക് ഗണ്യമായി ചുരുക്കാം.

ഇരുണ്ട വശം

മുകളിൽ പറഞ്ഞവയെല്ലാം രണ്ട് സമീപനങ്ങളെയും ശരിക്കും വഴക്കമുള്ളതും സാങ്കേതികമായി പുരോഗമിച്ചതും ആവർത്തന മെച്ചപ്പെടുത്തലിന് അനുയോജ്യവുമാക്കുന്നു. തീർച്ചയായും, ഒരു "തൈലത്തിൽ ബാരൽ" ഉണ്ട്, നിങ്ങൾക്ക് ഇതിനകം ഊഹിക്കാൻ കഴിയുമെന്ന് ഞാൻ കരുതുന്നു.

ഫ്ലെക്സിബിൾ ആർക്കിടെക്ചറുകളുടെ മോഡുലാരിറ്റിക്ക് അടിവരയിടുന്ന ഡാറ്റ വിഘടനം, പട്ടികകളുടെ എണ്ണത്തിൽ വർദ്ധനവിന് കാരണമാകുന്നു, അതനുസരിച്ച്, ഓവർഹെഡ് സാമ്പിൾ ചെയ്യുമ്പോൾ ചേരാൻ. ഒരു മാനത്തിന്റെ എല്ലാ ആട്രിബ്യൂട്ടുകളും ലളിതമായി ലഭിക്കുന്നതിന്, ഒരു ക്ലാസിക് സ്റ്റോറിൽ ഒരു തിരഞ്ഞെടുത്തത് മതിയാകും, എന്നാൽ ഒരു ഫ്ലെക്സിബിൾ ആർക്കിടെക്ചറിന് ജോയിംഗുകളുടെ മുഴുവൻ ശ്രേണിയും ആവശ്യമാണ്. മാത്രമല്ല, റിപ്പോർട്ടുകൾക്കായി ഇവയെല്ലാം ചേരുന്നത് മുൻകൂട്ടി എഴുതാൻ കഴിയുമെങ്കിൽ, SQL കൈകൊണ്ട് എഴുതാൻ ശീലിച്ച വിശകലന വിദഗ്ധർക്ക് ഇരട്ടി ദുരിതമാകും.

ഈ സാഹചര്യം എളുപ്പമാക്കുന്ന നിരവധി വസ്തുതകൾ ഉണ്ട്:

വലിയ അളവുകൾ ഉപയോഗിച്ച് പ്രവർത്തിക്കുമ്പോൾ, അതിന്റെ എല്ലാ ആട്രിബ്യൂട്ടുകളും ഏതാണ്ട് ഒരേസമയം ഉപയോഗിക്കില്ല. മോഡലിൽ ഒറ്റനോട്ടത്തിൽ തോന്നുന്നതിനേക്കാൾ കുറച്ച് ജോയിംഗുകൾ ഉണ്ടാകാം എന്നാണ് ഇതിനർത്ഥം. ഉപഗ്രഹങ്ങൾക്ക് ആട്രിബ്യൂട്ടുകൾ അനുവദിക്കുമ്പോൾ പങ്കിടുന്നതിന്റെ പ്രതീക്ഷിക്കുന്ന ആവൃത്തിയും ഡാറ്റ വോൾട്ടിന് കണക്കിലെടുക്കാം. അതേ സമയം, ലോഡിംഗ് ഘട്ടത്തിൽ സറോഗേറ്റുകൾ സൃഷ്ടിക്കുന്നതിനും മാപ്പിംഗ് ചെയ്യുന്നതിനും പ്രാഥമികമായി ഹബുകൾ അല്ലെങ്കിൽ ആങ്കറുകൾ ആവശ്യമാണ്, കൂടാതെ ചോദ്യങ്ങളിൽ ഇത് വളരെ അപൂർവമായി മാത്രമേ ഉപയോഗിക്കൂ (ഇത് ആങ്കറുകൾക്ക് പ്രത്യേകിച്ചും സത്യമാണ്).

എല്ലാ ചേരലുകളും കീ വഴിയാണ്. കൂടാതെ, ഡാറ്റ സംഭരിക്കുന്നതിനുള്ള കൂടുതൽ "കംപ്രസ് ചെയ്ത" മാർഗം ആവശ്യമുള്ളിടത്ത് സ്കാനിംഗ് ടേബിളുകളുടെ ഓവർഹെഡ് കുറയ്ക്കുന്നു (ഉദാഹരണത്തിന്, ആട്രിബ്യൂട്ട് മൂല്യം അനുസരിച്ച് ഫിൽട്ടർ ചെയ്യുമ്പോൾ). ഒരു കൂട്ടം ചേരലുകളുള്ള ഒരു നോർമലൈസ്ഡ് ഡാറ്റാബേസിൽ നിന്നുള്ള സാമ്പിൾ ഓരോ വരിയിലും നിരവധി പതിപ്പുകളുള്ള ഒരു കനത്ത അളവ് സ്കാൻ ചെയ്യുന്നതിനേക്കാൾ വേഗത്തിലായിരിക്കും എന്ന വസ്തുതയിലേക്ക് ഇത് നയിച്ചേക്കാം.

ഉദാഹരണത്തിന്, ഇവിടെ ഇത് ഒരു പട്ടികയിൽ നിന്നുള്ള സാമ്പിൾ ഉപയോഗിച്ച് ആങ്കർ മോഡലിന്റെ പ്രകടനത്തിന്റെ വിശദമായ താരതമ്യ പരിശോധന ലേഖനത്തിൽ അടങ്ങിയിരിക്കുന്നു.

ഒരുപാട് എഞ്ചിനെ ആശ്രയിച്ചിരിക്കുന്നു. പല ആധുനിക പ്ലാറ്റ്‌ഫോമുകളിലും ഇന്റേണൽ ജോയിൻ ഒപ്റ്റിമൈസേഷൻ സംവിധാനങ്ങളുണ്ട്. ഉദാഹരണത്തിന്, MS SQL, Oracle എന്നിവയ്ക്ക് അവരുടെ ഡാറ്റ മറ്റ് ജോയിനുകൾ ഒഴികെ മറ്റെവിടെയും ഉപയോഗിക്കുന്നില്ലെങ്കിൽ അന്തിമ തിരഞ്ഞെടുപ്പിനെയും (ടേബിൾ/ജോയിൻ എലിമിനേഷൻ) MPP വെർട്ടിക്കയെയും ബാധിക്കുന്നില്ലെങ്കിൽ പട്ടികകളിലേക്ക് ചേരുന്നത് "ഒറക്കിളിന്" ഒഴിവാക്കാനാകും. Avito ൽ നിന്നുള്ള സഹപ്രവർത്തകരുടെ അനുഭവം, ക്വറി പ്ലാനിന്റെ ചില മാനുവൽ ഒപ്റ്റിമൈസേഷൻ നൽകിക്കൊണ്ട് ആങ്കർ മോഡലിന് മികച്ച എഞ്ചിനാണെന്ന് തെളിയിക്കപ്പെട്ടിട്ടുണ്ട്. മറുവശത്ത്, ആങ്കർ മോഡൽ സംഭരിക്കുന്നത്, ഉദാഹരണത്തിന്, പരിമിതമായ ജോയിൻ സപ്പോർട്ട് ഉള്ള ക്ലിക്ക് ഹൗസിൽ, ഇതുവരെ വളരെ നല്ല ആശയമായി തോന്നുന്നില്ല.

കൂടാതെ, രണ്ട് വാസ്തുവിദ്യകൾക്കും ഉണ്ട് പ്രത്യേക നീക്കങ്ങൾ, ഡാറ്റ ആക്സസ് എളുപ്പമാക്കുന്നു (ഒരു അന്വേഷണ പ്രകടന കാഴ്ചപ്പാടിൽ നിന്നും അന്തിമ ഉപയോക്താക്കൾക്കും). ഉദാഹരണത്തിന്, പോയിന്റ്-ഇൻ-ടൈം ടേബിളുകൾ ഡാറ്റ വോൾട്ടിൽ അല്ലെങ്കിൽ പ്രത്യേക പട്ടിക പ്രവർത്തനങ്ങൾ ആങ്കർ മോഡലിൽ.

ആകെ

പരിഗണിക്കപ്പെടുന്ന ഫ്ലെക്സിബിൾ ആർക്കിടെക്ചറുകളുടെ പ്രധാന സാരാംശം അവയുടെ "ഡിസൈൻ" എന്ന മോഡുലാരിറ്റിയാണ്.

ഈ പ്രോപ്പർട്ടി അനുവദിക്കുന്നു:

• മെറ്റാഡാറ്റ വിന്യാസവുമായി ബന്ധപ്പെട്ട ചില പ്രാഥമിക തയ്യാറെടുപ്പുകൾക്കും അടിസ്ഥാന ETL അൽഗോരിതങ്ങൾ എഴുതുന്നതിനും ശേഷം, ഉപഭോക്താവിന് ആദ്യ ഫലം വേഗത്തിൽ നൽകുക കുറച്ച് ഉറവിട ഒബ്‌ജക്റ്റുകളിൽ നിന്നുള്ള ഡാറ്റ അടങ്ങുന്ന രണ്ട് റിപ്പോർട്ടുകളുടെ രൂപത്തിൽ. മുഴുവൻ ഒബ്ജക്റ്റ് മോഡലിലൂടെയും (മുകളിലെ തലത്തിൽ പോലും) പൂർണ്ണമായി ചിന്തിക്കേണ്ട ആവശ്യമില്ല.
• ഒരു ഡാറ്റ മോഡലിന് 2-3 ഒബ്‌ജക്‌റ്റുകൾ ഉപയോഗിച്ച് പ്രവർത്തിക്കാൻ തുടങ്ങാം (ഉപയോഗപ്രദമാകും), തുടർന്ന് ക്രമേണ വളരുക (ആങ്കർ മോഡൽ നിക്കോളായ് സംബന്ധിച്ച് അപേക്ഷിച്ചു മൈസീലിയവുമായുള്ള നല്ല താരതമ്യം).
• വിഷയ മേഖല വികസിപ്പിക്കുന്നതും പുതിയ ഉറവിടങ്ങൾ ചേർക്കുന്നതും ഉൾപ്പെടെയുള്ള മിക്ക മെച്ചപ്പെടുത്തലുകളും നിലവിലുള്ള പ്രവർത്തനത്തെ ബാധിക്കില്ല, ഇതിനകം പ്രവർത്തിക്കുന്ന എന്തെങ്കിലും തകർക്കാനുള്ള സാധ്യതയുമില്ല.
• സ്റ്റാൻഡേർഡ് ഘടകങ്ങളിലേക്ക് വിഘടിപ്പിച്ചതിന് നന്ദി, അത്തരം സിസ്റ്റങ്ങളിലെ ETL പ്രക്രിയകൾ ഒരുപോലെ കാണപ്പെടുന്നു, അവയുടെ എഴുത്ത് അൽഗോരിതമൈസേഷനും ആത്യന്തികമായി, ഓട്ടോമേഷൻ.

ഈ ഫ്ലെക്സിബിലിറ്റിയുടെ വില പ്രകടനം. അത്തരം മോഡലുകളിൽ സ്വീകാര്യമായ പ്രകടനം നേടുന്നത് അസാധ്യമാണെന്ന് ഇതിനർത്ഥമില്ല. പലപ്പോഴും, നിങ്ങൾ ആഗ്രഹിക്കുന്ന അളവുകൾ നേടുന്നതിന് കൂടുതൽ പരിശ്രമവും ശ്രദ്ധയും ആവശ്യമായി വന്നേക്കാം.

അപ്ലിക്കേഷനുകൾ

എന്റിറ്റി തരങ്ങൾ ഡാറ്റ വോൾട്ട്

ഡാറ്റ വോൾട്ടിനെക്കുറിച്ചുള്ള കൂടുതൽ വിവരങ്ങൾ:
ഡാൻ ലിസ്റ്റാഡിന്റെ വെബ്സൈറ്റ്
റഷ്യൻ ഭാഷയിൽ ഡാറ്റ വോൾട്ടിനെക്കുറിച്ച് എല്ലാം
ഹബ്രെയിലെ ഡാറ്റ വോൾട്ടിനെക്കുറിച്ച്

എന്റിറ്റി തരങ്ങൾ ആങ്കർ മോഡൽ

ആങ്കർ മോഡലിനെക്കുറിച്ചുള്ള കൂടുതൽ വിശദാംശങ്ങൾ:

ആങ്കർ മോഡലിന്റെ സ്രഷ്‌ടാക്കളുടെ വെബ്‌സൈറ്റ്
Avito ൽ ആങ്കർ മോഡൽ നടപ്പിലാക്കിയ അനുഭവത്തെക്കുറിച്ചുള്ള ലേഖനം

പരിഗണിക്കുന്ന സമീപനങ്ങളുടെ പൊതുവായ സവിശേഷതകളും വ്യത്യാസങ്ങളും ഉള്ള സംഗ്രഹ പട്ടിക:

അവലംബം: www.habr.com