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

ഞാൻ മോംഗോഡിബിയെ പ്രതിരോധിക്കുകയാണെന്ന് നിങ്ങൾക്ക് തോന്നുന്നുവെങ്കിൽ, ദയവായി വായിക്കുക നിരാകരണം ലേഖനത്തിന്റെ അവസാനം.

പുതിയ പ്രവണത

എനിക്ക് പറയാൻ കഴിയുന്നതിലും കൂടുതൽ വർഷങ്ങളായി ഞാൻ സോഫ്‌റ്റ്‌വെയർ വ്യവസായത്തിൽ ജോലി ചെയ്യുന്നു, പക്ഷേ ഞങ്ങളുടെ വ്യവസായത്തെ ബാധിച്ച ട്രെൻഡുകളുടെ ഒരു ചെറിയ ഭാഗം മാത്രമേ ഞാൻ ഇപ്പോഴും തുറന്നുകാട്ടുന്നുള്ളൂ. 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... എന്നിവയുടെ ഉയർച്ചയ്ക്ക് ഞാൻ സാക്ഷ്യം വഹിച്ചിട്ടുണ്ട്. ഓരോ വർഷവും പുതിയ ട്രെൻഡുകൾ പ്രത്യക്ഷപ്പെടുന്നു. ചിലത് പെട്ടെന്ന് മങ്ങുന്നു, മറ്റുള്ളവ അടിസ്ഥാനപരമായി സോഫ്റ്റ്‌വെയർ വികസിപ്പിച്ച രീതിയെ മാറ്റുന്നു.

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

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

കുറിപ്പ്: ഞാൻ ഡോക്യുമെന്റ് ഡാറ്റാബേസുകളെ കോളം ഡാറ്റാബേസുകൾ, കീ/വാല്യൂ സ്റ്റോറുകൾ അല്ലെങ്കിൽ പൊതുവായ NoSQL നിർവചനത്തിന് കീഴിലുള്ള മറ്റ് നിരവധി തരം ഡാറ്റ സ്റ്റോറുകൾ എന്നിവയുമായി ആശയക്കുഴപ്പത്തിലാക്കുകയാണെന്ന് നിങ്ങൾ കരുതിയേക്കാം. നിങ്ങൾ പറഞ്ഞത് ശരിയാണ്. എന്നാൽ അക്കാലത്ത് അരാജകത്വം നിലനിന്നിരുന്നു. എല്ലാവരും NoSQL-ൽ അഭിനിവേശത്തിലാണ്, അത് എല്ലാവരായി മാറിയിരിക്കുന്നു തികച്ചും വ്യത്യസ്ത സാങ്കേതികവിദ്യകളിലെ വ്യത്യാസങ്ങൾ പലരും കണ്ടില്ലെങ്കിലും ആവശ്യമാണ്. പലർക്കും, മോംഗോഡിബി ആയി മാറി എന്നതിന്റെ പര്യായപദം NoSQL.

ഡവലപ്പർമാർ അതിൽ കുതിച്ചു. ഏത് പ്രശ്‌നവും പരിഹരിക്കാൻ മാന്ത്രികമായി സ്കെയിൽ ചെയ്യുന്ന ഒരു സ്കീമലെസ് ഡാറ്റാബേസ് എന്ന ആശയം തികച്ചും പ്രലോഭിപ്പിക്കുന്നതായിരുന്നു. 2014 ഓടെ, ഒരു വർഷം മുമ്പ് MySQL, Postgres അല്ലെങ്കിൽ SQL സെർവർ പോലുള്ള ഒരു റിലേഷണൽ ഡാറ്റാബേസ് ഉപയോഗിച്ച എല്ലായിടത്തും MongoDB ഡാറ്റാബേസുകൾ വിന്യസിക്കാൻ തുടങ്ങിയതായി തോന്നുന്നു. എന്തുകൊണ്ടെന്ന് ചോദിച്ചാൽ, "ഇതാണ് വെബിന്റെ സ്കെയിൽ" എന്ന നിന്ദ്യതയിൽ നിന്ന് "എന്റെ ഡാറ്റ വളരെ അയഞ്ഞ ഘടനയുള്ളതും ഒരു സ്കീമയില്ലാത്ത ഒരു ഡാറ്റാബേസിലേക്ക് നന്നായി യോജിക്കുന്നതുമാണ്" എന്നതിനുള്ള ഉത്തരം നിങ്ങൾക്ക് ലഭിക്കും.

മോംഗോഡിബിയും ഡോക്യുമെന്റ് ഡാറ്റാബേസുകളും പരമ്പരാഗത റിലേഷണൽ ഡാറ്റാബേസുകളിൽ നിരവധി പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നു എന്നത് ഓർത്തിരിക്കേണ്ടത് പ്രധാനമാണ്:

• കർശനമായ പദ്ധതി: ഒരു റിലേഷണൽ ഡാറ്റാബേസ് ഉപയോഗിച്ച്, നിങ്ങൾക്ക് ചലനാത്മകമായി സൃഷ്ടിച്ച ഡാറ്റയുണ്ടെങ്കിൽ, ഒന്നുകിൽ ക്രമരഹിതമായ "പലവക" ഡാറ്റ കോളങ്ങൾ സൃഷ്ടിക്കാനോ ഡാറ്റയുടെ ബ്ലോബുകൾ അവിടെ മാറ്റാനോ കോൺഫിഗറേഷൻ ഉപയോഗിക്കാനോ നിങ്ങൾ നിർബന്ധിതരാകും. ഇ.എ.വി...ഇതിനെല്ലാം കാര്യമായ പോരായ്മകളുണ്ട്.
• സ്കെയിലിംഗ് ബുദ്ധിമുട്ട്: ഒരു സെർവറിൽ ചേരാത്ത അത്രയും ഡാറ്റ ഉണ്ടെങ്കിൽ, ഒന്നിലധികം മെഷീനുകളിൽ സ്കെയിൽ ചെയ്യാൻ മോംഗോഡിബി മെക്കാനിസങ്ങൾ വാഗ്ദാനം ചെയ്തു.
• സങ്കീർണ്ണമായ സർക്യൂട്ട് മാറ്റങ്ങൾ: കുടിയേറ്റങ്ങളൊന്നുമില്ല! ഒരു റിലേഷണൽ ഡാറ്റാബേസിൽ, ഡാറ്റാബേസ് ഘടന മാറ്റുന്നത് ഒരു വലിയ പ്രശ്നമായിരിക്കും (പ്രത്യേകിച്ച് ധാരാളം ഡാറ്റ ഉള്ളപ്പോൾ). പ്രക്രിയ വളരെ ലളിതമാക്കാൻ മോംഗോഡിബിക്ക് കഴിഞ്ഞു. നിങ്ങൾ പോകുമ്പോൾ സർക്യൂട്ട് അപ്‌ഡേറ്റ് ചെയ്യാനും വളരെ വേഗത്തിൽ മുന്നോട്ട് പോകാനും കഴിയുന്ന തരത്തിൽ ഇത് വളരെ എളുപ്പമാക്കി.
• റെക്കോർഡിംഗ് പ്രകടനം: MongoDB പ്രകടനം മികച്ചതായിരുന്നു, പ്രത്യേകിച്ച് ശരിയായി ക്രമീകരിച്ചപ്പോൾ. മോംഗോഡിബിയുടെ ഔട്ട്-ഓഫ്-ദി-ബോക്‌സ് കോൺഫിഗറേഷൻ പോലും, അത് പലപ്പോഴും വിമർശിക്കപ്പെട്ടിരുന്നു, ചില ശ്രദ്ധേയമായ പ്രകടന സംഖ്യകൾ കാണിച്ചു.

എല്ലാ അപകടസാധ്യതകളും നിങ്ങളുടേതാണ്

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

ശരിയായി പറഞ്ഞാൽ, 10gen/MongoDB Inc-ൽ ആരും ഇല്ല. ഇനിപ്പറയുന്നവ ശരിയല്ലെന്ന് പറയില്ല, ഇവ വെറും വിട്ടുവീഴ്ചകൾ മാത്രമാണ്.

• ഇടപാടുകൾ നഷ്ടപ്പെട്ടു: ഇടപാടുകൾ പല റിലേഷണൽ ഡാറ്റാബേസുകളുടെയും ഒരു പ്രധാന സവിശേഷതയാണ് (എല്ലാം അല്ല, മിക്കതും). ഇടപാട് എന്നതിനർത്ഥം നിങ്ങൾക്ക് ആറ്റോമിക് ആയി ഒന്നിലധികം പ്രവർത്തനങ്ങൾ നടത്താനും ഡാറ്റ സ്ഥിരതയുള്ളതാണെന്ന് ഉറപ്പാക്കാനും കഴിയും എന്നാണ്. തീർച്ചയായും, ഒരു NoSQL ഡാറ്റാബേസ് ഉപയോഗിച്ച്, ട്രാൻസാക്ഷനാലിറ്റി ഒരൊറ്റ ഡോക്യുമെന്റിനുള്ളിൽ ആയിരിക്കാം, അല്ലെങ്കിൽ നിങ്ങൾക്ക് ട്രാൻസാക്ഷനൽ സെമാന്റിക്‌സ് ലഭിക്കുന്നതിന് രണ്ട്-ഘട്ട കമ്മിറ്റുകൾ ഉപയോഗിക്കാം. എന്നാൽ ഈ പ്രവർത്തനം നിങ്ങൾ സ്വയം നടപ്പിലാക്കേണ്ടതുണ്ട്... ഇത് ബുദ്ധിമുട്ടുള്ളതും സമയമെടുക്കുന്നതുമായ ഒരു ജോലിയാണ്. പ്രവർത്തനങ്ങളുടെ ആറ്റോമിസിറ്റി ഉറപ്പുനൽകാൻ കഴിയാത്തതിനാൽ, ഡാറ്റാബേസിലെ ഡാറ്റ അസാധുവായ അവസ്ഥകളിൽ അവസാനിക്കുന്നത് കാണുന്നതുവരെ ഒരു പ്രശ്‌നമുണ്ടെന്ന് നിങ്ങൾ പലപ്പോഴും മനസ്സിലാക്കുന്നില്ല. ശ്രദ്ധിക്കുക: മോംഗോഡിബി 4.0 കഴിഞ്ഞ വർഷം ഇടപാടുകൾ അവതരിപ്പിച്ചതായി പലരും എന്നോട് പറഞ്ഞു, എന്നാൽ ചില പരിമിതികളോടെ. ലേഖനത്തിൽ നിന്നുള്ള ടേക്ക്അവേ അതേപടി തുടരുന്നു: സാങ്കേതികവിദ്യ നിങ്ങളുടെ ആവശ്യങ്ങൾ എത്രത്തോളം നിറവേറ്റുന്നുവെന്ന് വിലയിരുത്തുക.
• ബന്ധങ്ങളുടെ സമഗ്രത നഷ്ടപ്പെടുന്നു (വിദേശ കീകൾ): നിങ്ങളുടെ ഡാറ്റയ്ക്ക് ബന്ധങ്ങളുണ്ടെങ്കിൽ, നിങ്ങൾ അവ ആപ്ലിക്കേഷനിൽ പ്രയോഗിക്കേണ്ടതുണ്ട്. ഈ ബന്ധങ്ങളെ ബഹുമാനിക്കുന്ന ഒരു ഡാറ്റാബേസ് ഉണ്ടായിരിക്കുന്നത് ആപ്ലിക്കേഷന്റെയും അതിനാൽ നിങ്ങളുടെ പ്രോഗ്രാമർമാരുടെയും ഒരുപാട് ജോലികൾ ഇല്ലാതാക്കും.
• ഡാറ്റ ഘടന പ്രയോഗിക്കാനുള്ള കഴിവിന്റെ അഭാവം: കർശനമായ സ്കീമകൾ ചിലപ്പോൾ ഒരു വലിയ പ്രശ്‌നമായേക്കാം, എന്നാൽ അവ വിവേകപൂർവ്വം ഉപയോഗിക്കുകയാണെങ്കിൽ നല്ല ഡാറ്റ സ്ട്രക്ചറിംഗിനുള്ള ശക്തമായ സംവിധാനം കൂടിയാണ്. മോംഗോഡിബി പോലുള്ള ഡോക്യുമെന്റ് ഡാറ്റാബേസുകൾ അവിശ്വസനീയമായ സ്കീമ ഫ്ലെക്സിബിലിറ്റി നൽകുന്നു, എന്നാൽ ഈ ഫ്ലെക്സിബിലിറ്റി ഡാറ്റ വൃത്തിയായി സൂക്ഷിക്കുന്നതിനുള്ള ഉത്തരവാദിത്തം നീക്കം ചെയ്യുന്നു. നിങ്ങൾ അവരെ പരിപാലിക്കുന്നില്ലെങ്കിൽ, നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന ഫോമിൽ സംഭരിച്ചിട്ടില്ലാത്ത ഡാറ്റയ്ക്കായി നിങ്ങളുടെ ആപ്ലിക്കേഷനിൽ ധാരാളം കോഡുകൾ എഴുതുന്നത് അവസാനിക്കും. ഞങ്ങളുടെ കമ്പനി സിമ്പിൾ ത്രെഡിൽ ഞങ്ങൾ പലപ്പോഴും പറയുന്നതുപോലെ... ആപ്ലിക്കേഷൻ എന്നെങ്കിലും മാറ്റിയെഴുതപ്പെടും, പക്ഷേ ഡാറ്റ എന്നെന്നേക്കുമായി നിലനിൽക്കും. കുറിപ്പ്: MongoDB സ്കീമ പരിശോധനയെ പിന്തുണയ്ക്കുന്നു: ഇത് ഉപയോഗപ്രദമാണ്, എന്നാൽ ഒരു റിലേഷണൽ ഡാറ്റാബേസിൽ ഉള്ള അതേ ഗ്യാരണ്ടി നൽകുന്നില്ല. ഒന്നാമതായി, ഒരു സ്കീമ പരിശോധന ചേർക്കുന്നതും മാറ്റുന്നതും ശേഖരത്തിലെ നിലവിലുള്ള ഡാറ്റയെ ബാധിക്കില്ല. പുതിയ സ്കീമ അനുസരിച്ച് നിങ്ങൾ ഡാറ്റ അപ്ഡേറ്റ് ചെയ്യുന്നുവെന്ന് ഉറപ്പാക്കേണ്ടത് നിങ്ങളാണ്. നിങ്ങളുടെ ആവശ്യങ്ങൾക്ക് ഇത് മതിയോ എന്ന് സ്വയം തീരുമാനിക്കുക.
• പ്രാദേശിക അന്വേഷണ ഭാഷ / ടൂൾ ഇക്കോസിസ്റ്റത്തിന്റെ നഷ്ടം: SQL ന്റെ വരവ് ഒരു സമ്പൂർണ്ണ വിപ്ലവമായിരുന്നു, അതിനുശേഷം ഒന്നും മാറിയിട്ടില്ല. ഇത് അവിശ്വസനീയമാംവിധം ശക്തമായ ഭാഷയാണ്, മാത്രമല്ല വളരെ സങ്കീർണ്ണവുമാണ്. JSON ശകലങ്ങൾ അടങ്ങുന്ന ഒരു പുതിയ ഭാഷയിൽ ഡാറ്റാബേസ് അന്വേഷണങ്ങൾ നിർമ്മിക്കേണ്ടതിന്റെ ആവശ്യകത SQL-ൽ പ്രവർത്തിച്ച് പരിചയമുള്ള ആളുകൾ ഒരു വലിയ പിന്നോട്ട് ചുവടുവെപ്പായി കണക്കാക്കുന്നു. IDE-കൾ മുതൽ റിപ്പോർട്ടിംഗ് ടൂളുകൾ വരെ SQL ഡാറ്റാബേസുകളുമായി സംവദിക്കുന്ന ടൂളുകളുടെ ഒരു പ്രപഞ്ചം മുഴുവൻ ഉണ്ട്. SQL-നെ പിന്തുണയ്‌ക്കാത്ത ഒരു ഡാറ്റാബേസിലേക്ക് നീങ്ങുക എന്നതിനർത്ഥം നിങ്ങൾക്ക് ഈ ടൂളുകളിൽ ഭൂരിഭാഗവും ഉപയോഗിക്കാൻ കഴിയില്ല അല്ലെങ്കിൽ അവ ഉപയോഗിക്കുന്നതിന് നിങ്ങൾ ഡാറ്റ SQL-ലേക്ക് വിവർത്തനം ചെയ്യണം, അത് നിങ്ങൾ കരുതുന്നതിലും കൂടുതൽ ബുദ്ധിമുട്ടായിരിക്കും.

മോംഗോഡിബിയിലേക്ക് തിരിയുന്ന പല ഡവലപ്പർമാരും ട്രേഡ് ഓഫുകൾ ശരിക്കും മനസ്സിലാക്കിയിരുന്നില്ല, മാത്രമല്ല ഇത് അവരുടെ പ്രാഥമിക ഡാറ്റ സ്റ്റോറായി ഇൻസ്റ്റാൾ ചെയ്യുന്നതിൽ തലകുനിച്ചു. ഇതിനുശേഷം, തിരിച്ചുവരവ് പലപ്പോഴും അവിശ്വസനീയമാംവിധം ബുദ്ധിമുട്ടായിരുന്നു.

വ്യത്യസ്തമായി എന്തുചെയ്യാമായിരുന്നു?

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

ശരിയായ സാങ്കേതികവിദ്യ എങ്ങനെ തിരഞ്ഞെടുക്കാം? സാങ്കേതിക വിലയിരുത്തലിനായി ചിട്ടയായ ചട്ടക്കൂട് സൃഷ്ടിക്കാൻ നിരവധി ശ്രമങ്ങൾ നടന്നിട്ടുണ്ട് "സോഫ്റ്റ്‌വെയർ ഓർഗനൈസേഷനുകളിൽ സാങ്കേതികവിദ്യകൾ അവതരിപ്പിക്കുന്നതിനുള്ള ചട്ടക്കൂട്" и "സോഫ്റ്റ്‌വെയർ സാങ്കേതികവിദ്യകൾ വിലയിരുത്തുന്നതിനുള്ള ചട്ടക്കൂട്", എന്നാൽ ഇത് അനാവശ്യമായ സങ്കീർണ്ണതയാണെന്ന് എനിക്ക് തോന്നുന്നു.

രണ്ട് അടിസ്ഥാന ചോദ്യങ്ങൾ മാത്രം ചോദിച്ച് പല സാങ്കേതികവിദ്യകളും ബുദ്ധിപരമായി വിലയിരുത്താൻ കഴിയും. പക്ഷപാതമില്ലാതെ ഉത്തരങ്ങൾ കണ്ടെത്താൻ സമയമെടുത്ത് അവയ്ക്ക് ഉത്തരവാദിത്തത്തോടെ ഉത്തരം നൽകാൻ കഴിയുന്ന ആളുകളെ കണ്ടെത്തുന്നതാണ് പ്രശ്നം.

നിങ്ങൾക്ക് എന്തെങ്കിലും പ്രശ്നം നേരിടുന്നില്ലെങ്കിൽ, നിങ്ങൾക്ക് ഒരു പുതിയ ഉപകരണം ആവശ്യമില്ല. ഡോട്ട്.

ചോദ്യം 1: ഞാൻ എന്ത് പ്രശ്‌നങ്ങളാണ് പരിഹരിക്കാൻ ശ്രമിക്കുന്നത്?

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

ചോദ്യം 2: എനിക്ക് എന്താണ് നഷ്ടമായത്?

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

നിങ്ങൾക്ക് ഒന്നുമില്ലെങ്കിൽ, ഈ ഉപകരണത്തിന്റെ മൂല്യം നിർണ്ണയിക്കാൻ സാധ്യമായ ഏറ്റവും കുറഞ്ഞ നിക്ഷേപത്തെക്കുറിച്ച് ചിന്തിക്കുന്നത് അർത്ഥമാക്കുന്നു. നിങ്ങൾ നിക്ഷേപം നടത്തിക്കഴിഞ്ഞാൽ, തീരുമാനം മാറ്റുന്നത് എത്ര ബുദ്ധിമുട്ടായിരിക്കും?

ആളുകൾ എപ്പോഴും എല്ലാം നശിപ്പിക്കുന്നു

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

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

വസ്തുനിഷ്ഠമായ വിലയിരുത്തൽ എളുപ്പമല്ല, എന്നാൽ അടിസ്ഥാനപരമായ വൈജ്ഞാനിക പക്ഷപാതങ്ങൾ മനസ്സിലാക്കുന്നത് കൂടുതൽ യുക്തിസഹമായ തീരുമാനങ്ങൾ എടുക്കാൻ നിങ്ങളെ സഹായിക്കും.

സംഗ്രഹം

ഒരു പുതുമ പ്രത്യക്ഷപ്പെടുമ്പോഴെല്ലാം, രണ്ട് ചോദ്യങ്ങൾക്ക് വളരെ ശ്രദ്ധയോടെ ഉത്തരം നൽകണം:

• ഈ ഉപകരണം ഒരു യഥാർത്ഥ പ്രശ്നം പരിഹരിക്കുമോ?
• ഇടപാടുകൾ ഞങ്ങൾ നന്നായി മനസ്സിലാക്കുന്നുണ്ടോ?

നിങ്ങൾക്ക് ഈ രണ്ട് ചോദ്യങ്ങൾക്ക് ആത്മവിശ്വാസത്തോടെ ഉത്തരം നൽകാൻ കഴിയുന്നില്ലെങ്കിൽ, കുറച്ച് ചുവടുകൾ പിന്നോട്ട് പോയി ചിന്തിക്കുക.

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

എ

മോംഗോഡിബിയുമായി എനിക്ക് പ്രണയമോ വിദ്വേഷമോ ഇല്ലെന്ന് വ്യക്തമാക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. മോംഗോഡിബി പരിഹരിക്കാൻ ഏറ്റവും അനുയോജ്യമായ തരത്തിലുള്ള പ്രശ്‌നങ്ങൾ ഞങ്ങൾക്കുണ്ടായിട്ടില്ല. 10gen/MongoDB Inc എന്ന് എനിക്കറിയാം. ആദ്യം വളരെ ബോൾഡ് ആയിരുന്നു, സുരക്ഷിതമല്ലാത്ത ഡിഫോൾട്ടുകൾ സജ്ജീകരിക്കുകയും എല്ലായിടത്തും (പ്രത്യേകിച്ച് ഹാക്കത്തോണുകളിൽ) മോംഗോഡിബി പ്രൊമോട്ട് ചെയ്യുകയും ചെയ്തു, ഏത് ഡാറ്റയിലും പ്രവർത്തിക്കാനുള്ള സാർവത്രിക പരിഹാരമായി. ഒരുപക്ഷേ അത് ഒരു മോശം തീരുമാനമായിരുന്നു. എന്നാൽ ഇവിടെ വിവരിച്ചിരിക്കുന്ന സമീപനത്തെ ഇത് സ്ഥിരീകരിക്കുന്നു: സാങ്കേതികവിദ്യയുടെ ഉപരിപ്ലവമായ വിലയിരുത്തൽ പോലും ഈ പ്രശ്നങ്ങൾ വളരെ വേഗത്തിൽ കണ്ടെത്താനാകും.

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