ഏതാണ് നല്ലത് - ഒറാക്കിൾ അല്ലെങ്കിൽ റെഡിസ് അല്ലെങ്കിൽ പ്ലാറ്റ്ഫോം തിരഞ്ഞെടുക്കുന്നതിനെ എങ്ങനെ ന്യായീകരിക്കാം

“ഇത് ആവശ്യമാണ്,” അവൾ ആരെയും അഭിസംബോധന ചെയ്യാതെ ഉറക്കെ പറഞ്ഞു. - ഇത് ആവശ്യമാണ്! ഇത് കൃത്യമായി പറയുന്നു: ഒരു കമ്പനിയുടെ പ്രധാന ദൗത്യം ഓഹരി ഉടമകളുടെ താൽപ്പര്യങ്ങൾക്കനുസൃതമായി ലാഭമുണ്ടാക്കുക എന്നതാണ്. ശരി, അതിനെക്കുറിച്ച് ചിന്തിക്കുക! അവർ ഒന്നിനെയും ഭയപ്പെടുന്നില്ല!

യൂലി ഡുബോവ്, "കുറവ് തിന്മ"

അത്തരമൊരു തലക്കെട്ട് കണ്ടിട്ട്, ലേഖനം മണ്ടത്തരമോ പ്രകോപനമോ ആണെന്ന് നിങ്ങൾ ഇതിനകം തീരുമാനിച്ചിരിക്കാം. എന്നാൽ നിഗമനങ്ങളിൽ എത്തിച്ചേരരുത്: വലിയ കോർപ്പറേഷനുകളിലെ ജീവനക്കാർ, പ്രത്യേകിച്ച് സംസ്ഥാന പങ്കാളിത്തമുള്ള കോർപ്പറേഷനുകൾ, തികച്ചും വ്യത്യസ്തമായവ ഉൾപ്പെടെ വ്യത്യസ്ത പ്ലാറ്റ്ഫോമുകൾ താരതമ്യം ചെയ്യേണ്ടതുണ്ട് - ഉദാഹരണത്തിന്, ശീർഷകത്തിലുള്ളവ.

തീർച്ചയായും, ആരും ഈ രീതിയിൽ DBMS-കളെ താരതമ്യം ചെയ്യുന്നില്ല, കാരണം അവയുടെ ശക്തിയും ബലഹീനതയും നന്നായി അറിയാം. ചട്ടം പോലെ, ചില ആപ്ലിക്കേഷൻ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്ന പ്ലാറ്റ്ഫോമുകൾ താരതമ്യത്തിന് വിധേയമാണ്. ഹബ്ർ വായനക്കാർക്ക് നേരിട്ട് പരിചിതമായ ഒരു വിഷയമായി ഡാറ്റാബേസുകളുടെ ഉദാഹരണം ഉപയോഗിച്ച്, ഈ കേസിൽ ഉപയോഗിക്കുന്ന രീതിശാസ്ത്രം ലേഖനത്തിൽ ഞാൻ കാണിക്കും. അതിനാൽ,

പ്രചോദനം

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

സ്വാഭാവികമായും, നിങ്ങൾ കുറച്ച് പണം നൽകാനും കൂടുതൽ നേടാനും ആഗ്രഹിക്കുന്നു. എന്നിരുന്നാലും, എന്താണ് കൂടുതൽ പ്രധാനമെന്ന് നിങ്ങൾ തീരുമാനിക്കേണ്ടതുണ്ട് - കുറച്ച് പണം നൽകുക അല്ലെങ്കിൽ കൂടുതൽ നേടുക, കൂടാതെ ഓരോ നോഡിനും ഒരു ഭാരം നൽകുക. വിലകുറഞ്ഞതിനേക്കാൾ ഉയർന്ന നിലവാരമുള്ള പരിഹാരം ഞങ്ങൾക്ക് പ്രധാനമാണെന്ന് നമുക്ക് അനുമാനിക്കാം, കൂടാതെ "കോസ്റ്റ്" നോഡിന് 40% ഭാരം ഞങ്ങൾ നൽകുകയും "അവസരങ്ങൾ" നോഡിന് 60% നൽകുകയും ചെയ്യുന്നു.

വലിയ കോർപ്പറേഷനുകളിൽ, സാധാരണയായി വിപരീതമാണ് ശരി - ചെലവ് ഭാരം 50% ൽ താഴെയാകില്ല, ഒരുപക്ഷേ 60% ൽ കൂടുതലായിരിക്കാം. മാതൃകാ ഉദാഹരണത്തിൽ, പ്രധാനപ്പെട്ടത് ഏതൊരു പാരന്റ് നോഡിന്റെയും ചൈൽഡ് നോഡുകളുടെ ആകെ ഭാരം 100% ആയിരിക്കണം എന്നതാണ്.

കട്ട് ഓഫ് വ്യവസ്ഥകൾ

വെബ്സൈറ്റ് db-engines.com ഏകദേശം 500 ഡാറ്റാബേസ് മാനേജ്മെന്റ് സിസ്റ്റങ്ങൾ അറിയപ്പെടുന്നു. സ്വാഭാവികമായും, നിങ്ങൾ നിരവധി ഓപ്‌ഷനുകളിൽ നിന്ന് ഒരു ടാർഗെറ്റ് പ്ലാറ്റ്‌ഫോം തിരഞ്ഞെടുക്കുകയാണെങ്കിൽ, നിങ്ങൾക്ക് ഒരു അവലോകന ലേഖനം നൽകാം, പക്ഷേ ഒരു വാണിജ്യ പ്രോജക്‌റ്റല്ല. തിരഞ്ഞെടുക്കാനുള്ള ഇടം കുറയ്ക്കുന്നതിന്, കട്ട്-ഓഫ് മാനദണ്ഡങ്ങൾ രൂപപ്പെടുത്തുന്നു, പ്ലാറ്റ്ഫോം ഈ മാനദണ്ഡങ്ങൾ പാലിക്കുന്നില്ലെങ്കിൽ, അത് പരിഗണിക്കില്ല.

കട്ട്-ഓഫ് മാനദണ്ഡങ്ങൾ സാങ്കേതിക സവിശേഷതകളുമായി ബന്ധപ്പെട്ടിരിക്കാം, ഉദാഹരണത്തിന്:

• ACID ഗ്യാരന്റി;
• റിലേഷണൽ ഡാറ്റ മോഡൽ;
• SQL ഭാഷാ പിന്തുണ (ശ്രദ്ധിക്കുക, ഇത് "റിലേഷണൽ മോഡൽ" പോലെയല്ല);
• തിരശ്ചീന സ്കെയിലിംഗിന്റെ സാധ്യത.

പൊതുവായ മാനദണ്ഡങ്ങൾ ഉണ്ടാകാം:

• റഷ്യയിൽ വാണിജ്യ പിന്തുണയുടെ ലഭ്യത;
• ഓപ്പൺ സോഴ്സ്;
• ടെലികോം, മാസ് കമ്മ്യൂണിക്കേഷൻസ് മന്ത്രാലയത്തിന്റെ രജിസ്റ്ററിൽ പ്ലാറ്റ്ഫോമിന്റെ ലഭ്യത;
• ചില റേറ്റിംഗിൽ പ്ലാറ്റ്‌ഫോമിന്റെ സാന്നിധ്യം (ഉദാഹരണത്തിന്, db-engines.com റേറ്റിംഗിന്റെ ആദ്യ നൂറിൽ);
• വിപണിയിലെ വിദഗ്ധരുടെ സാന്നിധ്യം (ഉദാഹരണത്തിന്, hh.ru എന്ന വെബ്‌സൈറ്റിലെ ഒരു റെസ്യൂമിൽ പ്ലാറ്റ്‌ഫോമിന്റെ പേര് തിരയുന്നതിന്റെ ഫലങ്ങൾ അടിസ്ഥാനമാക്കി).

എല്ലാത്തിനുമുപരി, എന്റർപ്രൈസ്-നിർദ്ദിഷ്ട മാനദണ്ഡങ്ങൾ ഉണ്ടായിരിക്കാം:

• സ്റ്റാഫിൽ സ്പെഷ്യലിസ്റ്റുകളുടെ ലഭ്യത;
• മോണിറ്ററിംഗ് സിസ്റ്റം X അല്ലെങ്കിൽ ബാക്കപ്പ് സിസ്റ്റം Y യുമായുള്ള അനുയോജ്യത, എല്ലാ പിന്തുണയും അടിസ്ഥാനമാക്കിയുള്ളതാണ്...

കട്ട് ഓഫ് മാനദണ്ഡങ്ങളുടെ ഒരു ലിസ്റ്റ് ഉണ്ട് എന്നതാണ് ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യം. അല്ലാത്തപക്ഷം, മാനേജ്‌മെന്റിൽ നിന്ന് പ്രത്യേക വിശ്വാസം ആസ്വദിക്കുന്ന ചില വിദഗ്ധർ (അല്ലെങ്കിൽ "വിദഗ്ദ്ധൻ") തീർച്ചയായും ഉണ്ടാകും, അവർ പറയും "എന്തുകൊണ്ട് നിങ്ങൾ പ്ലാറ്റ്‌ഫോം Z തിരഞ്ഞെടുത്തില്ല, അത് മികച്ചതാണെന്ന് എനിക്കറിയാം."

ചെലവ് കണക്കാക്കൽ

പരിഹാരത്തിന്റെ വില വ്യക്തമായും ലൈസൻസുകളുടെ വില, പിന്തുണയുടെ വില, ഉപകരണങ്ങളുടെ വില എന്നിവ ഉൾക്കൊള്ളുന്നു.

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

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

വ്യത്യസ്ത വെണ്ടർമാർക്ക് വ്യത്യസ്ത ലൈസൻസിംഗ് മെട്രിക്കുകൾ ഉണ്ടായിരിക്കാം: കോറുകളുടെ എണ്ണം, ഡാറ്റ വോളിയം അല്ലെങ്കിൽ നോഡുകളുടെ എണ്ണം. സ്റ്റാൻഡ്ബൈ ബേസ് സൗജന്യമായിരിക്കാം, അല്ലെങ്കിൽ പ്രധാനമായതിന് സമാനമായി ലൈസൻസ് നൽകാം. മെട്രിക്കുകളിൽ എന്തെങ്കിലും വ്യത്യാസങ്ങൾ കണ്ടെത്തിയാൽ, നിങ്ങൾ മോഡൽ സ്റ്റാൻഡിനെ വിശദമായി വിവരിക്കുകയും സ്റ്റാൻഡിനുള്ള ലൈസൻസുകളുടെ വില കണക്കാക്കുകയും വേണം.

ശരിയായ താരതമ്യത്തിനുള്ള ഒരു പ്രധാന കാര്യം അതേ പിന്തുണാ വ്യവസ്ഥകളാണ്. ഉദാഹരണത്തിന്, Oracle പിന്തുണയ്‌ക്ക് പ്രതിവർഷം ലൈസൻസ് വിലയുടെ 22% ചിലവാകും, എന്നാൽ PostgreSQL പിന്തുണയ്‌ക്കായി നിങ്ങൾ പണം നൽകേണ്ടതില്ല. ഇങ്ങനെ താരതമ്യം ചെയ്യുന്നത് ശരിയാണോ? ഇല്ല, കാരണം സ്വന്തമായി പരിഹരിക്കാൻ കഴിയാത്ത ഒരു പിശക് തികച്ചും വ്യത്യസ്തമായ പ്രത്യാഘാതങ്ങൾ ഉണ്ടാക്കുന്നു: ആദ്യ സന്ദർഭത്തിൽ, പിന്തുണാ സ്പെഷ്യലിസ്റ്റുകൾ അത് വേഗത്തിൽ പരിഹരിക്കാൻ നിങ്ങളെ സഹായിക്കും, എന്നാൽ രണ്ടാമത്തെ സാഹചര്യത്തിൽ, പൂർത്തിയായതിന്റെ പ്രോജക്റ്റ് വൈകുകയോ പ്രവർത്തനരഹിതമാക്കുകയോ ചെയ്യാനുള്ള സാധ്യതയുണ്ട്. അനിശ്ചിതകാലത്തേക്ക് സിസ്റ്റം.

നിങ്ങൾക്ക് മൂന്ന് തരത്തിൽ കണക്കുകൂട്ടൽ വ്യവസ്ഥകൾ തുല്യമാക്കാം:

1. പിന്തുണയില്ലാതെ ഒറാക്കിൾ ഉപയോഗിക്കുക (യഥാർത്ഥത്തിൽ ഇത് സംഭവിക്കുന്നില്ല).
2. PostgreSQL-ന് പിന്തുണ വാങ്ങുക - ഉദാഹരണത്തിന്, Postgres Professional-ൽ നിന്ന്.
3. പിന്തുണയുടെ അഭാവവുമായി ബന്ധപ്പെട്ട അപകടസാധ്യതകൾ കണക്കിലെടുക്കുക.

ഉദാഹരണത്തിന്, ഒരു റിസ്ക് കണക്കുകൂട്ടൽ ഇതുപോലെയായിരിക്കാം: ഒരു മാരകമായ ഡാറ്റാബേസ് പരാജയം സംഭവിച്ചാൽ, സിസ്റ്റം പ്രവർത്തനരഹിതമായ സമയം 1 പ്രവൃത്തി ദിവസമായിരിക്കും. ഈ സിസ്റ്റം ഉപയോഗിക്കുന്നതിലൂടെ പ്രതിവർഷം പ്രതീക്ഷിക്കുന്ന ലാഭം 40 ബില്യൺ MNT ആണ്, അപകട നിരക്ക് 1/400 ആണെന്ന് കണക്കാക്കപ്പെടുന്നു, അതിനാൽ പിന്തുണയുടെ അഭാവത്തിന്റെ അപകടസാധ്യത പ്രതിവർഷം ഏകദേശം 100 ദശലക്ഷം MNT ആയി കണക്കാക്കപ്പെടുന്നു. വ്യക്തമായും, “ആസൂത്രിത ലാഭം”, “കണക്കാക്കിയ അപകടങ്ങളുടെ ആവൃത്തി” എന്നിവ വെർച്വൽ മൂല്യങ്ങളാണ്, എന്നാൽ ഒന്നുമില്ലാത്തതിനേക്കാൾ അത്തരമൊരു മാതൃക ഉണ്ടായിരിക്കുന്നതാണ് നല്ലത്.

യഥാർത്ഥത്തിൽ, ദീർഘകാല പ്രവർത്തനരഹിതമായ സമയത്തിന്റെ പ്രശസ്തമായ ചിലവ് അസ്വീകാര്യമാകുന്നതിന് സിസ്റ്റം വളരെ പ്രധാനമായേക്കാം, അതിനാൽ പിന്തുണ ആവശ്യമായി വരും. പ്രവർത്തനരഹിതമായ സമയം അനുവദനീയമാണെങ്കിൽ, പിന്തുണ നിരസിക്കുന്നത് ചിലപ്പോൾ പണം ലാഭിക്കാനുള്ള ഒരു നല്ല മാർഗമായിരിക്കും.

എല്ലാ കണക്കുകൂട്ടലുകൾക്കും ശേഷം, 5 വർഷത്തേക്ക് ഓപ്പറേറ്റിംഗ് പ്ലാറ്റ്ഫോം A യുടെ ചെലവ് 800 ദശലക്ഷം MNT ആയി മാറുന്നു, ഓപ്പറേറ്റിംഗ് പ്ലാറ്റ്ഫോം B യുടെ ചെലവ് 650 ദശലക്ഷം MNT ആണ്, ഓപ്പറേറ്റിംഗ് പ്ലാറ്റ്ഫോം C യുടെ വില 600 ദശലക്ഷം MNT ആണ്. പ്ലാറ്റ്‌ഫോം C, വിജയി എന്ന നിലയിൽ, വിലയ്‌ക്ക് ഒരു പൂർണ്ണ പോയിന്റ് ലഭിക്കുന്നു, അതേസമയം A, B പ്ലാറ്റ്‌ഫോമുകൾക്ക് എത്ര മടങ്ങ് വില കൂടുതലാണ് എന്നതിന് ആനുപാതികമായി കുറച്ച് കുറച്ച് മാത്രമേ ലഭിക്കൂ. ഈ സാഹചര്യത്തിൽ - യഥാക്രമം 0.75, 0.92 പോയിന്റുകൾ.

അവസര വിലയിരുത്തൽ

അവസരങ്ങളുടെ വിലയിരുത്തൽ പല ഗ്രൂപ്പുകളായി തിരിച്ചിരിക്കുന്നു, അവയുടെ എണ്ണം വിലയിരുത്തൽ നടത്തുന്ന വ്യക്തിയുടെ ഭാവനയാൽ മാത്രം പരിമിതപ്പെടുത്തിയിരിക്കുന്നു. ഈ കഴിവുകൾ ഉപയോഗിക്കുന്ന ടീമുകളായി കഴിവുകളെ വിഭജിക്കുന്നതാണ് ഒപ്റ്റിമൽ ഓപ്ഷൻ എന്ന് തോന്നുന്നു; ഞങ്ങളുടെ ഉദാഹരണത്തിൽ, ഇവരാണ് ഡെവലപ്പർമാർ, അഡ്മിനിസ്ട്രേറ്റർമാർ, ഇൻഫർമേഷൻ സെക്യൂരിറ്റി ഓഫീസർമാർ. ഈ ഫംഗ്‌ഷനുകളുടെ ഭാരം 40:40:20 ആയി വിതരണം ചെയ്യപ്പെടുന്നുവെന്ന് നമുക്ക് അനുമാനിക്കാം.

വികസന പ്രവർത്തനങ്ങളിൽ ഇവ ഉൾപ്പെടുന്നു:

• ഡാറ്റ കൃത്രിമത്വം എളുപ്പം;
• സ്കെയിലിംഗ്;
• ദ്വിതീയ സൂചികകളുടെ സാന്നിധ്യം.

മാനദണ്ഡങ്ങളുടെ പട്ടികയും അവയുടെ തൂക്കവും വളരെ ആത്മനിഷ്ഠമാണ്. ഒരേ പ്രശ്നം പരിഹരിക്കുമ്പോൾ പോലും, നിങ്ങളുടെ ടീമിന്റെ ഘടനയെ ആശ്രയിച്ച് ഈ ലിസ്റ്റുകളും ഇനത്തിന്റെ തൂക്കവും ഉത്തരങ്ങളും ഗണ്യമായി വ്യത്യാസപ്പെടും. ഉദാഹരണത്തിന്, ഡാറ്റ സംഭരിക്കുന്നതിന് Facebook MySQL ഉപയോഗിക്കുന്നു, കൂടാതെ ഇൻസ്റ്റാഗ്രാം നിർമ്മിച്ചിരിക്കുന്നത് കസാന്ദ്രയിലാണ്. ഈ ആപ്ലിക്കേഷനുകളുടെ ഡെവലപ്പർമാർ അത്തരം പട്ടികകൾ പൂരിപ്പിച്ചിരിക്കാൻ സാധ്യതയില്ല. മാർക്ക് സക്കർബർഗ് ഒരു സമ്പൂർണ്ണ റിലേഷണൽ മോഡൽ തിരഞ്ഞെടുത്തുവെന്ന് ഊഹിക്കാവുന്നതേയുള്ളൂ, അപ്ലൈഡ് ഷാർഡിംഗിന്റെ ആവശ്യകതയോടെ അതിനായി പണം നൽകി, കെവിൻ സിസ്‌ട്രോം പ്ലാറ്റ്‌ഫോം ഉപയോഗിച്ച് സ്കെയിലിംഗ് നിർമ്മിച്ചു, ഡാറ്റയിലേക്കുള്ള ആക്‌സസ് ത്യജിച്ചു.

അഡ്മിനിസ്ട്രേഷൻ പ്രവർത്തനങ്ങളിൽ ഉൾപ്പെടുന്നു:

• ബാക്കപ്പ് സിസ്റ്റം കഴിവുകൾ;
• നിരീക്ഷണത്തിന്റെ ലാളിത്യം;
• ശേഷി മാനേജ്മെന്റിന്റെ എളുപ്പം - ഡിസ്കുകളും നോഡുകളും;
• ഡാറ്റ റെപ്ലിക്കേഷൻ കഴിവുകൾ.

ചോദ്യങ്ങൾ ഒരു ക്വാണ്ടിറ്റേറ്റീവ് രീതിയിൽ ആയിരിക്കണം എന്നത് ശ്രദ്ധിക്കുക. ഒരു പ്രത്യേക ഫംഗ്‌ഷൻ എങ്ങനെ വിലയിരുത്താം എന്നതുപോലും നിങ്ങൾക്ക് സമ്മതിക്കാം. ഉദാഹരണത്തിന്, Oracle DBMS-നൊപ്പം വിതരണം ചെയ്ത ഉപകരണങ്ങളുടെ ഉദാഹരണം ഉപയോഗിച്ച് ബാക്കപ്പ് ടൂളുകൾ റേറ്റ് ചെയ്യാൻ ശ്രമിക്കാം:

ഉപകരണം
അഭിപ്രായം
മൂല്യനിർണ്ണയത്തിൽ

imp/exp
ഡാറ്റ അപ്‌ലോഡ് ചെയ്യുകയും ലോഡുചെയ്യുകയും ചെയ്യുന്നു
0.1

ബാക്കപ്പ് ആരംഭിക്കുക/അവസാനം ചെയ്യുക
ഫയലുകൾ പകർത്തുന്നു
0.3

RMAN
വർദ്ധിപ്പിച്ച പകർപ്പ് ശേഷി
0.7

ZDLRA
വർദ്ധിച്ചുവരുന്ന പകർത്തൽ മാത്രം, പോയിന്റിലേക്ക് വേഗത്തിൽ വീണ്ടെടുക്കൽ
1.0

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

അവസാനമായി, ഞങ്ങൾ വിവര സുരക്ഷാ പ്രവർത്തനങ്ങൾ ലിസ്റ്റ് ചെയ്യുന്നു:

• പാസ്വേഡ് മാനേജ്മെന്റ് നയങ്ങളുടെ ലഭ്യത;
• ബാഹ്യ പ്രാമാണീകരണ ഉപകരണങ്ങൾ (LDAP, Kerberos) ബന്ധിപ്പിക്കുന്നതിനുള്ള കഴിവ്;
• പ്രവേശനത്തിന്റെ മാതൃക;
• ഓഡിറ്റ് കഴിവുകൾ;
• ഡിസ്കിലെ ഡാറ്റയുടെ എൻക്രിപ്ഷൻ;
• നെറ്റ്‌വർക്കിലൂടെ (TLS) ട്രാൻസ്മിഷൻ സമയത്ത് എൻക്രിപ്ഷൻ;
• അഡ്മിനിസ്ട്രേറ്ററിൽ നിന്നുള്ള ഡാറ്റ സംരക്ഷണം.

പ്രകടന പരിശോധന

നിങ്ങൾ ഉണ്ടാക്കാത്ത ഏതെങ്കിലും ലോഡ് ടെസ്റ്റുകളുടെ ഫലങ്ങൾ വാദങ്ങളായി ഉപയോഗിക്കുന്നതിനെതിരെ പ്രത്യേകം മുന്നറിയിപ്പ് നൽകാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

ഒന്നാമതായി, പരിശോധിക്കപ്പെടുന്ന ആപ്ലിക്കേഷനുകളുടെ ഡാറ്റാ ഘടനയും ലോഡ് പ്രൊഫൈലും നിങ്ങൾ പരിഹരിക്കാൻ പോകുന്ന പ്രശ്നത്തിൽ നിന്ന് കാര്യമായ വ്യത്യാസമുണ്ടാകാം. ഏകദേശം 10-15 വർഷം മുമ്പ്, ഡാറ്റാബേസ് വെണ്ടർമാർ ടിപിസി ടെസ്റ്റുകളിൽ നേടിയ ഫലങ്ങൾ കാണിക്കാൻ ഇഷ്ടപ്പെട്ടു, എന്നാൽ ഇപ്പോൾ, ആരും ഈ ഫലങ്ങൾ ഗൗരവമായി എടുക്കുന്നില്ലെന്ന് തോന്നുന്നു.

രണ്ടാമതായി, ഏത് പ്ലാറ്റ്‌ഫോമിന് വേണ്ടിയാണ് കോഡ് ആദ്യം എഴുതിയത്, ഏത് ഉപകരണമാണ് ടെസ്റ്റ് നടത്തിയത് എന്നതിനെ ആശ്രയിച്ചിരിക്കും സിസ്റ്റം പ്രകടനം. ഒറാക്കിളിനെ PostgreSQL-മായി താരതമ്യപ്പെടുത്തിയ നിരവധി പരിശോധനകൾ ഞാൻ കണ്ടിട്ടുണ്ട്. ഒരു വ്യവസ്ഥിതിയുടെ നിരുപാധികമായ ശ്രേഷ്ഠത മുതൽ മറ്റൊന്നിന്റെ തുല്യമായ നിരുപാധികമായ ശ്രേഷ്ഠത വരെയാണ് ഫലങ്ങൾ.

അവസാനമായി, മൂന്നാമതായി, ആരാണ് ടെസ്റ്റ് നടത്തിയത് എന്നതിനെക്കുറിച്ച് നിങ്ങൾക്ക് ഒന്നും അറിയില്ല. രണ്ട് യോഗ്യതകളും പ്രധാനമാണ്, ഒഎസും പ്ലാറ്റ്‌ഫോമും സജ്ജീകരിക്കുന്നതിന്റെ ഗുണനിലവാരത്തെ സ്വാധീനിക്കുന്നു, കൂടാതെ മറ്റെല്ലാ ഘടകങ്ങളെക്കാളും ടെസ്റ്റ് ഫലങ്ങളെ സ്വാധീനിക്കുന്ന പ്രചോദനവും.

പ്രകടനം ഒരു നിർണായക ഘടകമാണെങ്കിൽ, ഉൽപ്പാദന സംവിധാനം ക്രമീകരിക്കുകയും പരിപാലിക്കുകയും ചെയ്യുന്ന ആളുകളുടെ സഹായത്തോടെ സ്വയം പരിശോധന നടത്തുക.

ഫലം

അവസാനമായി, എല്ലാ എസ്റ്റിമേറ്റുകളും സംയോജിപ്പിച്ച് ഗുണിച്ച് സംഗ്രഹിക്കുന്ന ഒരു സ്‌പ്രെഡ്‌ഷീറ്റ് ആയിരിക്കണം എല്ലാ ജോലികളുടെയും ഫലം:

നിങ്ങൾ മനസ്സിലാക്കുന്നതുപോലെ, സ്കെയിലുകൾ മാറ്റുന്നതിലൂടെയും റേറ്റിംഗുകൾ ക്രമീകരിക്കുന്നതിലൂടെയും നിങ്ങൾക്ക് ആവശ്യമുള്ള ഫലം നേടാൻ കഴിയും, എന്നാൽ ഇത് തികച്ചും വ്യത്യസ്തമായ കഥയാണ്...

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