ഈ ഡാറ്റാബേസ് തീപിടിച്ചിരിക്കുന്നു...

ഒരു സാങ്കേതിക കഥ പറയാം.

വർഷങ്ങൾക്കുമുമ്പ്, സഹകരണ സവിശേഷതകളുള്ള ഒരു ആപ്ലിക്കേഷൻ ഞാൻ വികസിപ്പിക്കുകയായിരുന്നു. ആദ്യകാല റിയാക്‌റ്റിന്റെയും കൗച്ച്‌ഡിബിയുടെയും മുഴുവൻ സാധ്യതകളും പ്രയോജനപ്പെടുത്തിയ ഒരു ഉപയോക്തൃ-സൗഹൃദ പരീക്ഷണ സ്റ്റാക്കായിരുന്നു ഇത്. ഇത് JSON വഴി തത്സമയം ഡാറ്റ സമന്വയിപ്പിച്ചു OT. കമ്പനിക്കുള്ളിൽ ഇത് ഉപയോഗിച്ചിരുന്നു, എന്നാൽ മറ്റ് മേഖലകളിൽ അതിന്റെ വിശാലമായ പ്രയോഗവും സാധ്യതയും വ്യക്തമായിരുന്നു.

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


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

റിഫ്രഷ് ബട്ടൺ എന്തിനുവേണ്ടിയാണെന്ന് എല്ലാവർക്കും അറിയാമായിരുന്നിട്ടും, അവർ ഞങ്ങളോട് നിർമ്മിക്കാൻ ആവശ്യപ്പെട്ട വെബ് ആപ്ലിക്കേഷനുകൾ സാധാരണയായി അവരുടെ സ്വന്തം പരിമിതികൾക്ക് വിധേയമാണെന്ന് ആർക്കും മനസ്സിലായില്ല. അവ ഇനി ആവശ്യമില്ലെങ്കിൽ, ഉപയോക്തൃ അനുഭവം തികച്ചും വ്യത്യസ്തമായിരിക്കും. തങ്ങൾ സംസാരിക്കുന്ന ആളുകൾക്ക് കുറിപ്പുകൾ നൽകി "ചാറ്റ്" ചെയ്യാൻ കഴിയുമെന്ന് അവർ കൂടുതലും ശ്രദ്ധിച്ചു, അതിനാൽ ഇത് സ്ലാക്കിൽ നിന്ന് എങ്ങനെ വ്യത്യസ്തമാണെന്ന് അവർ ആശ്ചര്യപ്പെട്ടു. ഛെ!

ദൈനംദിന സമന്വയങ്ങളുടെ രൂപകൽപ്പന

നിങ്ങൾക്ക് സോഫ്‌റ്റ്‌വെയർ വികസനത്തിൽ അനുഭവപരിചയമുണ്ടെങ്കിൽ, മിക്ക ആളുകൾക്കും ഒരു ഇന്റർഫേസിന്റെ ചിത്രം നോക്കാനും അതുമായി ഇടപഴകുമ്പോൾ അത് എന്തുചെയ്യുമെന്ന് മനസ്സിലാക്കാനും കഴിയില്ലെന്ന് ഓർക്കുന്നത് ഞെട്ടിക്കുന്നതായിരിക്കണം. പ്രോഗ്രാമിനുള്ളിൽ തന്നെ എന്താണ് സംഭവിക്കുന്നതെന്ന് പറയേണ്ടതില്ലല്ലോ. എന്ന അറിവ് കഴിയും സംഭവിക്കാൻ പാടില്ലാത്തതും സംഭവിക്കാൻ പാടില്ലാത്തതും അറിയുന്നതിന്റെ ഫലമാണ് സംഭവിക്കുന്നത്. ഇത് ആവശ്യമാണ് മാനസിക മാതൃക സോഫ്‌റ്റ്‌വെയർ ചെയ്യുന്നത് മാത്രമല്ല, അതിന്റെ വ്യക്തിഗത ഭാഗങ്ങൾ എങ്ങനെ ഏകോപിപ്പിക്കുകയും പരസ്പരം ആശയവിനിമയം നടത്തുകയും ചെയ്യുന്നു.

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

ഇതാണ് തൽസമയ മൂല്യത്തിന്റെ സാരാംശം. ഇക്കാലത്ത്, തത്സമയ ഡാറ്റാബേസുകൾ ഇപ്പോഴും വളരെ കുറച്ച് മാത്രമേ ഉപയോഗിക്കുന്നുള്ളൂ, പലരും അവയെ സംശയത്തോടെയാണ് കാണുന്നത്. ഈ ഡാറ്റാബേസുകളിൽ ഭൂരിഭാഗവും NoSQL ശൈലിയിലേക്ക് വളരെയധികം ചായുന്നു, അതിനാലാണ് അവർ സാധാരണയായി മോംഗോ അടിസ്ഥാനമാക്കിയുള്ള പരിഹാരങ്ങൾ ഉപയോഗിക്കുന്നത്, അവ മറന്നുപോകുന്നു. എന്നിരുന്നാലും, എന്നെ സംബന്ധിച്ചിടത്തോളം ഇതിനർത്ഥം CouchDB-യിൽ സുഖപ്രദമായ ജോലി നേടുക, അതുപോലെ തന്നെ ചില ബ്യൂറോക്രാറ്റുകൾക്ക് ഡാറ്റ പൂരിപ്പിക്കാൻ കഴിയുന്ന ഘടനകൾ രൂപകൽപ്പന ചെയ്യാൻ പഠിക്കുക. ഞാൻ എന്റെ സമയം നന്നായി ഉപയോഗിക്കുന്നുണ്ടെന്ന് ഞാൻ കരുതുന്നു.

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

ഇരുവരുടെയും പേരിൽ തീ എന്ന വാക്ക് ഉണ്ട്. ഒരു കാര്യം ഞാൻ സ്നേഹത്തോടെ ഓർക്കുന്നു. എനിക്ക് രണ്ടാമത്തെ കാര്യം മറ്റൊരു തരം തീയാണ്. അവരുടെ പേരുകൾ പറയാൻ എനിക്ക് തിടുക്കമില്ല, കാരണം ഒരിക്കൽ പറഞ്ഞാൽ, നമ്മൾ ആദ്യത്തെ വലിയ പ്രശ്നത്തിലേക്ക് കടക്കും: പേരുകൾ.

ആദ്യത്തേത് വിളിക്കുന്നു ഫയർബേസ് തത്സമയ ഡാറ്റാബേസ്, രണ്ടാമത്തേത് - ഫയർബേസ് ക്ലൗഡ് ഫയർസ്റ്റോർ. ഇവ രണ്ടും ഉൽപ്പന്നങ്ങളാണ് ഫയർബേസ് സ്യൂട്ട് ഗൂഗിൾ. അവയുടെ API-കളെ യഥാക്രമം വിളിക്കുന്നു firebase.database(…) и firebase.firestore(…).

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

കാരണം നിങ്ങൾ സൂചിപ്പിക്കേണ്ടതുണ്ട് ഫയർബേസ് ഫയർബേസ് ചോദ്യത്തിൽ, ഒപ്പം ഫയർസ്റ്റോർ ഫയർബേസിനെക്കുറിച്ചുള്ള ഒരു ചോദ്യത്തിൽ, കുറച്ച് വർഷങ്ങൾക്ക് മുമ്പ് സ്റ്റാക്ക് ഓവർഫ്ലോയെക്കുറിച്ച് നിങ്ങളെ മനസ്സിലാക്കാൻ.

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

പിറിക് വിജയം

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

എന്നിരുന്നാലും, രണ്ട് ഉൽപ്പന്നങ്ങളിലേക്കുള്ള ഒരു പെട്ടെന്നുള്ള നോട്ടം നിങ്ങളെ ആശയക്കുഴപ്പത്തിലാക്കാം: അടിസ്ഥാനപരമായി ഒരേ API-കളിലൂടെയും ഒരേ ഡാറ്റാബേസ് സെഷനിൽ പോലും അവ ഒരേ കാര്യം ചെയ്യുന്നതായി തോന്നുന്നു. വ്യത്യാസങ്ങൾ സൂക്ഷ്മമായതും വിപുലമായ ഡോക്യുമെന്റേഷന്റെ സൂക്ഷ്മമായ താരതമ്യ പഠനത്തിലൂടെ മാത്രമേ വെളിപ്പെടുകയുള്ളൂ. അല്ലെങ്കിൽ നിങ്ങൾ പോർട്ട് കോഡ് ചെയ്യാൻ ശ്രമിക്കുമ്പോൾ, അത് ഫയർബേസിൽ നന്നായി പ്രവർത്തിക്കുന്നതിനാൽ അത് ഫയർസ്റ്റോറിൽ പ്രവർത്തിക്കും. തത്സമയം മൗസ് ഉപയോഗിച്ച് വലിച്ചിടാൻ ശ്രമിക്കുമ്പോൾ തന്നെ ഡാറ്റാബേസ് ഇന്റർഫേസ് പ്രകാശിക്കുന്നതായി നിങ്ങൾ കണ്ടെത്തും. ഞാൻ ആവർത്തിക്കുന്നു, ഞാൻ തമാശയല്ല.

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

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

അവൻ തന്റെ അറകളിൽ നിന്ന് പ്രത്യക്ഷപ്പെട്ട് പ്രഖ്യാപിച്ചു:

“ഒരു വലിയ JSON രേഖ? ഇല്ല. നിങ്ങൾ ഡാറ്റയെ പ്രത്യേക ഡോക്യുമെന്റുകളായി വിഭജിക്കും, അവയിൽ ഓരോന്നിനും 1 മെഗാബൈറ്റിൽ കൂടുതൽ വലിപ്പമുണ്ടാകില്ല.

മതിയായ പ്രചോദിത ഉപയോക്തൃ അടിത്തറയുമായുള്ള ആദ്യ ഏറ്റുമുട്ടലിൽ അത്തരമൊരു പരിമിതി അതിജീവിക്കില്ലെന്ന് തോന്നുന്നു. അത് നിങ്ങൾക്കറിയാം. ജോലിസ്ഥലത്ത്, ഉദാഹരണത്തിന്, ഞങ്ങൾക്ക് ഒന്നര ആയിരത്തിലധികം അവതരണങ്ങളുണ്ട്, ഇത് പൂർണ്ണമായും സാധാരണമാണ്.

ഈ പരിമിതിയോടെ, ഡാറ്റാബേസിലെ ഒരു "പ്രമാണം" ഒരു ഉപയോക്താവ് ഒരു ഡോക്യുമെൻറ് എന്ന് വിളിക്കുന്ന ഒരു വസ്തുവുമായി സാമ്യമുള്ളതല്ല എന്ന വസ്തുത അംഗീകരിക്കാൻ നിങ്ങൾ നിർബന്ധിതരാകും.

"ആവർത്തനപരമായി മറ്റ് ഘടകങ്ങൾ ഉൾക്കൊള്ളാൻ കഴിയുന്ന അറേകളുടെ നിരകൾ? ഇല്ല. ദൈവം ഉദ്ദേശിച്ചതുപോലെ, അറേകളിൽ നിശ്ചിത ദൈർഘ്യമുള്ള വസ്തുക്കളോ സംഖ്യകളോ മാത്രമേ ഉണ്ടാകൂ."

അതിനാൽ നിങ്ങളുടെ ഫയർസ്റ്റോറിൽ GeoJSON ഇടാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഇത് സാധ്യമല്ലെന്ന് നിങ്ങൾ കണ്ടെത്തും. ഏകമാനമല്ലാത്ത ഒന്നും സ്വീകാര്യമല്ല. JSON-നുള്ളിൽ Base64 കൂടാതെ/അല്ലെങ്കിൽ JSON നിങ്ങൾക്ക് ഇഷ്ടപ്പെടുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു.

"HTTP, കമാൻഡ് ലൈൻ ടൂളുകൾ അല്ലെങ്കിൽ അഡ്മിൻ പാനൽ വഴി JSON ഇറക്കുമതി ചെയ്യുകയും കയറ്റുമതി ചെയ്യുകയും ചെയ്യണോ? ഇല്ല. നിങ്ങൾക്ക് Google ക്ലൗഡ് സ്റ്റോറേജിലേക്ക് ഡാറ്റ കയറ്റുമതി ചെയ്യാനും ഇറക്കുമതി ചെയ്യാനും മാത്രമേ കഴിയൂ. അതിനെയാണ് ഇപ്പോൾ വിളിക്കുന്നത്, ഞാൻ കരുതുന്നു. "നിങ്ങൾ" എന്ന് ഞാൻ പറയുമ്പോൾ, പ്രോജക്റ്റ് ഉടമയുടെ ക്രെഡൻഷ്യലുകൾ ഉള്ളവരെ മാത്രമാണ് ഞാൻ അഭിസംബോധന ചെയ്യുന്നത്. മറ്റെല്ലാവർക്കും പോയി ടിക്കറ്റ് ഉണ്ടാക്കാം."

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഫയർബേസ് ഡാറ്റ മോഡൽ വിവരിക്കാൻ എളുപ്പമാണ്. JSON കീകളെ URL പാതകളുമായി ബന്ധപ്പെടുത്തുന്ന ഒരു വലിയ JSON പ്രമാണം ഇതിൽ അടങ്ങിയിരിക്കുന്നു. കൂടെ എഴുതിയാൽ HTTP PUT в / ഫയർബേസ് ഇനിപ്പറയുന്നതാണ്:

{
  "hello": "world"
}

എസ് GET /hello തിരിച്ചു വരും "world". അടിസ്ഥാനപരമായി ഇത് നിങ്ങൾ പ്രതീക്ഷിക്കുന്നത് പോലെ തന്നെ പ്രവർത്തിക്കുന്നു. ഫയർബേസ് വസ്തുക്കളുടെ ശേഖരണം /my-collection/:id ഒരു JSON നിഘണ്ടുവിന് തുല്യമാണ് {"my-collection": {...}} റൂട്ടിൽ, അതിന്റെ ഉള്ളടക്കങ്ങൾ ലഭ്യമാണ് /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

ഓരോ ഇൻസേർട്ടിനും ഒരു കൂട്ടിയിടി രഹിത ഐഡി ഉണ്ടെങ്കിൽ, സിസ്റ്റത്തിന് ഒരു സാധാരണ പരിഹാരമുണ്ടെങ്കിൽ ഇത് നന്നായി പ്രവർത്തിക്കും.

മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഡാറ്റാബേസ് 100% JSON(*) അനുയോജ്യവും CouchDB പോലുള്ള HTTP-യുമായി മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നു. എന്നാൽ അടിസ്ഥാനപരമായി നിങ്ങൾ വെബ്‌സോക്കറ്റുകൾ, അംഗീകാരം, സബ്‌സ്‌ക്രിപ്‌ഷനുകൾ എന്നിവ സംഗ്രഹിക്കുന്ന ഒരു തത്സമയ API വഴിയാണ് ഇത് ഉപയോഗിക്കുന്നത്. അഡ്‌മിൻ പാനലിന് തത്സമയ എഡിറ്റിംഗും JSON ഇറക്കുമതി/കയറ്റുമതിയും അനുവദിക്കുന്ന രണ്ട് കഴിവുകളും ഉണ്ട്. നിങ്ങളുടെ കോഡിലും നിങ്ങൾ ഇത് ചെയ്യുകയാണെങ്കിൽ, സ്ഥിരമായ അവസ്ഥ കൈകാര്യം ചെയ്യുന്നതിന്റെ 90% പതിവ് ജോലികളും JSON പരിഹരിക്കുന്നു എന്ന് മനസ്സിലാക്കുമ്പോൾ, എത്ര പ്രത്യേക കോഡ് പാഴാകുമെന്ന് നിങ്ങൾ ആശ്ചര്യപ്പെടും.

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

അവർ ഒരു തത്സമയ NoSQL ഡാറ്റാബേസ് എടുത്ത്, സ്വയമേവ ചേരുന്നതും ഒരു പ്രത്യേക നോൺ-ജെഎസ്ഒഎൻ കോളവും ഉള്ള സ്ലോ നോൺ-എസ്‌ക്യുഎൽ ആക്കി മാറ്റി. GraftQL പോലെയുള്ള ഒന്ന്.

ചൂടുള്ള ജാവ

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

മിക്ക വെബ് ഡെവലപ്പർമാർക്കും മാറ്റമില്ലാത്തതിനെക്കുറിച്ച് അറിയുന്നതിന് മുമ്പ്, ക്ലയന്റ് അതിന്റെ സമയത്തിന് നിരവധി വർഷങ്ങൾക്ക് മുമ്പാണ് സൃഷ്ടിച്ചത് എന്നതാണ് ഫയർബേസിന്റെ പ്രധാന പോരായ്മ. ഇക്കാരണത്താൽ, നിങ്ങൾ ഡാറ്റ മാറ്റുമെന്ന് ഫയർബേസ് അനുമാനിക്കുന്നു, അതിനാൽ ഉപയോക്താവ് നൽകുന്ന മാറ്റമില്ലാത്തത് പ്രയോജനപ്പെടുത്തുന്നില്ല. കൂടാതെ, അത് ഉപയോക്താവിന് കൈമാറുന്ന സ്നാപ്പ്ഷോട്ടുകളിലെ ഡാറ്റ വീണ്ടും ഉപയോഗിക്കുന്നില്ല, ഇത് വ്യത്യാസം കൂടുതൽ ബുദ്ധിമുട്ടാക്കുന്നു. വലിയ ഡോക്യുമെന്റുകൾക്ക്, അതിന്റെ മ്യൂട്ടബിൾ ഡിഫ് അധിഷ്ഠിത ഇടപാട് സംവിധാനം അപര്യാപ്തമാണ്. സുഹൃത്തുക്കളേ, ഞങ്ങൾക്ക് ഇതിനകം ഉണ്ട് WeakMap ജാവാസ്ക്രിപ്റ്റിൽ. ഇത് സുഖകരമാണ്.

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

ഫയർസ്റ്റോർ ഉണ്ടാക്കിയതിന് പിന്നിലെ എല്ലാ യുക്തിയും എനിക്കറിയില്ല. ബ്ലാക്ക് ബോക്‌സിനുള്ളിൽ ഉയരുന്ന ഉദ്ദേശ്യങ്ങളെക്കുറിച്ച് ഊഹക്കച്ചവടവും വിനോദത്തിന്റെ ഭാഗമാണ്. വളരെ സാമ്യമുള്ളതും എന്നാൽ താരതമ്യപ്പെടുത്താനാവാത്തതുമായ രണ്ട് ഡാറ്റാബേസുകളുടെ ഈ സംയോജനം വളരെ അപൂർവമാണ്. ആരോ ചിന്തിച്ചതുപോലെ: "Google ക്ലൗഡിൽ നമുക്ക് അനുകരിക്കാൻ കഴിയുന്ന ഒരു ഫംഗ്‌ഷൻ മാത്രമാണ് ഫയർബേസ്", എന്നാൽ യഥാർത്ഥ ലോക ആവശ്യകതകൾ തിരിച്ചറിയുന്നതിനോ ആ ആവശ്യകതകളെല്ലാം നിറവേറ്റുന്ന ഉപയോഗപ്രദമായ പരിഹാരങ്ങൾ സൃഷ്ടിക്കുന്നതിനോ ഉള്ള ആശയം ഇതുവരെ കണ്ടെത്തിയിട്ടില്ല. “ഡെവലപ്പർമാർ അതിനെക്കുറിച്ച് ചിന്തിക്കട്ടെ. UI മനോഹരമാക്കൂ... കൂടുതൽ തീ ചേർക്കാമോ?”

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

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

ഇതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾക്കായി നിങ്ങൾ Google ഡോക്‌സിൽ തിരയുകയാണെങ്കിൽ, BigTable, BigQuery എന്നിവ പോലെയുള്ള എന്തെങ്കിലും ദിശയിലേക്ക് നിങ്ങളെ ചൂണ്ടിക്കാണിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നു. എന്നിരുന്നാലും, ഈ പരിഹാരങ്ങളെല്ലാം വളരെ സാന്ദ്രമായ കോർപ്പറേറ്റ് വിൽപ്പന പദപ്രയോഗങ്ങൾക്കൊപ്പമാണ്, നിങ്ങൾ പെട്ടെന്ന് പിന്തിരിഞ്ഞ് മറ്റെന്തെങ്കിലും തിരയാൻ തുടങ്ങും.

ഒരു തത്സമയ ഡാറ്റാബേസ് ഉപയോഗിച്ച് നിങ്ങൾക്ക് അവസാനമായി വേണ്ടത് മാനേജ്മെന്റ് പേ സ്കെയിലിലുള്ള ആളുകൾക്ക് വേണ്ടി നിർമ്മിച്ചതാണ്.

(*) ഇതൊരു തമാശയാണ്, അങ്ങനെയൊന്നില്ല 100% JSON അനുയോജ്യമാണ്.

ഒരു പരസ്യമായി

ഇതിനായി തിരയുന്നു വി.ഡി.എസ് പ്രോജക്‌റ്റുകൾ ഡീബഗ്ഗുചെയ്യുന്നതിന്, വികസനത്തിനും ഹോസ്റ്റിംഗിനുമുള്ള ഒരു സെർവർ? നിങ്ങൾ തീർച്ചയായും ഞങ്ങളുടെ ക്ലയന്റാണ് 🙂 വിവിധ കോൺഫിഗറേഷനുകളുടെ സെർവറുകളുടെ പ്രതിദിന വിലനിർണ്ണയം, ആന്റി-ഡിഡിഒഎസ്, വിൻഡോസ് ലൈസൻസുകൾ എന്നിവ ഇതിനകം വിലയിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്.

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