ഡാറ്റാബേസ് ഡിസൈൻ അടിസ്ഥാനകാര്യങ്ങൾ - PostgreSQL, Cassandra, MongoDB എന്നിവ താരതമ്യം ചെയ്യുന്നു

ഹലോ സുഹൃത്തുക്കളെ. മെയ് അവധിക്കാലത്തിന്റെ രണ്ടാം ഭാഗത്തിനായി പുറപ്പെടുന്നതിന് മുമ്പ്, കോഴ്‌സിൽ ഒരു പുതിയ സ്ട്രീം ആരംഭിക്കുന്നത് പ്രതീക്ഷിച്ച് ഞങ്ങൾ വിവർത്തനം ചെയ്‌ത മെറ്റീരിയൽ നിങ്ങളുമായി പങ്കിടുന്നു "റിലേഷണൽ ഡിബിഎംഎസ്".

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

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

SQL ഉം NoSQL ഉം തമ്മിലുള്ള വ്യത്യാസം എന്താണ്?

SQL ഡാറ്റാബേസുകൾ ACID ട്രാൻസാക്ഷൻ ഗ്യാരന്റികളിലൂടെ ആപ്ലിക്കേഷൻ ഫ്ലെക്സിബിലിറ്റി വർദ്ധിപ്പിക്കുന്നു, അതുപോലെ നിലവിലുള്ള നോർമലൈസ്ഡ് റിലേഷണൽ ഡാറ്റാബേസ് മോഡലുകൾക്ക് മുകളിൽ അപ്രതീക്ഷിതമായ രീതിയിൽ JOIN-കൾ ഉപയോഗിച്ച് ഡാറ്റ അന്വേഷിക്കാനുള്ള അവരുടെ കഴിവും.

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

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

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

NoSQL ഡാറ്റാബേസുകൾ ലീനിയർ റൈറ്റ് സ്കേലബിളിറ്റിയും ഉയർന്ന തെറ്റ് സഹിഷ്ണുതയും നൽകുമ്പോൾ, ട്രാൻസാക്ഷൻ ഗ്യാരന്റി നഷ്ടപ്പെടുന്നത് മിഷൻ-ക്രിട്ടിക്കൽ ഡാറ്റയ്ക്ക് അനുയോജ്യമല്ലെന്ന് ഒരു വാദമുണ്ട്.

NoSQL-ലെ ഡാറ്റ മോഡലിംഗ് SQL-ൽ നിന്ന് എങ്ങനെ വ്യത്യാസപ്പെട്ടിരിക്കുന്നുവെന്ന് ഇനിപ്പറയുന്ന പട്ടിക കാണിക്കുന്നു.

SQL ഉം NoSQL ഉം: എന്തുകൊണ്ട് രണ്ടും ആവശ്യമാണ്?

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

YugaByte DB എങ്ങനെയാണ് SQL, NoSQL എന്നിവ സംയോജിപ്പിക്കുന്നത്?

ലോഗ്-ഓറിയന്റഡ് മിക്സഡ് സ്റ്റോറേജ് എഞ്ചിൻ, ഓട്ടോ-ഷെർഡിംഗ്, ഷെർഡഡ് ഡിസ്ട്രിബ്യൂഡ് കൺസെൻസസ് റെപ്ലിക്കേഷൻ, എസിഐഡി ഡിസ്ട്രിബ്യൂഡ് ട്രാൻസാക്ഷനുകൾ (ഗൂഗിൾ സ്പാനറിൽ നിന്ന് പ്രചോദനം ഉൾക്കൊണ്ട്), NoSQL (കസാന്ദ്ര & റെഡിസ്) എന്നിവയുമായി ഒരേസമയം പൊരുത്തപ്പെടുന്ന ലോകത്തിലെ ആദ്യത്തെ ഓപ്പൺ സോഴ്‌സ് ഡാറ്റാബേസാണ് യുഗാബൈറ്റ് ഡിബി. SQL (PostgreSQL). ചുവടെയുള്ള പട്ടികയിൽ കാണിച്ചിരിക്കുന്നതുപോലെ, കസാന്ദ്രയുമായി പൊരുത്തപ്പെടുന്ന YugaByte DB API ആയ YCQL, NoSQL API-യിലേക്ക് സിംഗിൾ, മൾട്ടി-കീ ACID ഇടപാടുകളുടെയും ആഗോള ദ്വിതീയ സൂചികകളുടെയും ആശയങ്ങൾ ചേർക്കുന്നു, അതുവഴി ഇടപാട് NoSQL ഡാറ്റാബേസുകളുടെ യുഗത്തിലേക്ക് നയിക്കുന്നു. കൂടാതെ, YCQL, PostgreSQL-ന് അനുയോജ്യമായ YugaByte DB API, SQL API-യിലേക്ക് ലീനിയർ റൈറ്റ് സ്കെയിലിംഗ്, ഓട്ടോമാറ്റിക് ഫോൾട്ട് ടോളറൻസ് എന്നീ ആശയങ്ങൾ ചേർക്കുന്നു, ഇത് വിതരണം ചെയ്ത SQL ഡാറ്റാബേസുകൾ ലോകത്തിലേക്ക് കൊണ്ടുവരുന്നു. YugaByte DB ഇടപാട് സ്വഭാവമുള്ളതിനാൽ, NoSQL API ഇപ്പോൾ മിഷൻ-ക്രിട്ടിക്കൽ ഡാറ്റയുടെ പശ്ചാത്തലത്തിൽ ഉപയോഗിക്കാനാകും.

ലേഖനത്തിൽ മുമ്പ് പറഞ്ഞതുപോലെ "YSQL അവതരിപ്പിക്കുന്നു: YugaByte DB-യ്‌ക്കായി ഒരു PostgreSQL അനുയോജ്യമായ വിതരണം ചെയ്ത SQL API", YugaByte DB-യിലെ SQL അല്ലെങ്കിൽ NoSQL എന്നിവയ്ക്കിടയിലുള്ള തിരഞ്ഞെടുപ്പ് അടിസ്ഥാനപരമായ ജോലിഭാരത്തിന്റെ സവിശേഷതകളെ പൂർണ്ണമായും ആശ്രയിച്ചിരിക്കുന്നു:

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

നേറ്റീവ് ഡാറ്റാബേസുകളിൽ നിന്ന് വ്യത്യസ്തമായി, അടുത്ത വിഭാഗത്തിലെ ഡാറ്റ മോഡലിംഗ് ലാബ് PostgreSQL, Cassandra API എന്നിവയ്ക്ക് അനുയോജ്യമായ യുഗാബൈറ്റ് DB ഡാറ്റാബേസുകളെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്. രണ്ട് വ്യത്യസ്ത ഡാറ്റാബേസുകളുടെ പൂർണ്ണമായും സ്വതന്ത്രമായ ക്ലസ്റ്ററുകൾ ഉപയോഗിക്കുന്നതിന് വിരുദ്ധമായി, ഒരേ ഡാറ്റാബേസ് ക്ലസ്റ്ററിന്റെ രണ്ട് വ്യത്യസ്ത എപിഐകളുമായി (രണ്ട് വ്യത്യസ്ത പോർട്ടുകളിൽ) സംവദിക്കാനുള്ള എളുപ്പത്തിന് ഈ സമീപനം ഊന്നൽ നൽകുന്നു.
ഇനിപ്പറയുന്ന വിഭാഗങ്ങളിൽ, വിവരിച്ചിരിക്കുന്ന ഡാറ്റാബേസുകളുടെ വ്യത്യാസങ്ങളും ചില പൊതുതത്വങ്ങളും ചിത്രീകരിക്കുന്നതിന് ഞങ്ങൾ ഡാറ്റ മോഡലിംഗ് ലാബിലേക്ക് നോക്കും.

ഡാറ്റ മോഡലിംഗ് ലബോറട്ടറി

ഡാറ്റാബേസ് ഇൻസ്റ്റാളേഷൻ

ഡാറ്റാ മോഡൽ ഡിസൈനിൽ ഊന്നൽ നൽകിക്കൊണ്ട് (സങ്കീർണ്ണമായ വിന്യാസ ആർക്കിടെക്ചറുകൾക്ക് പകരം), ഞങ്ങൾ ലോക്കൽ മെഷീനിലെ ഡോക്കർ കണ്ടെയ്‌നറുകളിൽ ഡാറ്റാബേസുകൾ ഇൻസ്റ്റാൾ ചെയ്യുകയും അതത് കമാൻഡ് ലൈൻ ഷെല്ലുകൾ ഉപയോഗിച്ച് അവയുമായി സംവദിക്കുകയും ചെയ്യും.

PostgreSQL & Cassandra compatible, YugaByte DB ഡാറ്റാബേസ്

mkdir ~/yugabyte && cd ~/yugabyte
wget https://downloads.yugabyte.com/yb-docker-ctl && chmod +x yb-docker-ctl
docker pull yugabytedb/yugabyte
./yb-docker-ctl create --enable_postgres

മോംഗോഡിബി

docker run --name my-mongo -d mongo:latest

കമാൻഡ് ലൈൻ ആക്സസ്

അനുബന്ധ API-കൾക്കായി കമാൻഡ് ലൈൻ ഷെൽ ഉപയോഗിച്ച് നമുക്ക് ഡാറ്റാബേസുകളിലേക്ക് കണക്റ്റുചെയ്യാം.

PostgreSQL എന്നീ

psql PostgreSQL-മായി സംവദിക്കുന്നതിനുള്ള ഒരു കമാൻഡ് ലൈൻ ഷെൽ ആണ്. എളുപ്പത്തിൽ ഉപയോഗിക്കുന്നതിന്, യുഗാബൈറ്റ് ഡിബി ബിൻ ഫോൾഡറിൽ തന്നെ psql-നൊപ്പം വരുന്നു.

docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgres

ചേട്ടനാണു

cqlsh CQL (Cassandra Query Language) വഴി കസാന്ദ്രയുമായും അതിന്റെ അനുയോജ്യമായ ഡാറ്റാബേസുകളുമായും സംവദിക്കുന്നതിനുള്ള ഒരു കമാൻഡ് ലൈൻ ഷെൽ ആണ്. ഉപയോഗത്തിന്റെ എളുപ്പത്തിനായി, യുഗബൈറ്റ് ഡിബി വരുന്നു cqlsh കാറ്റലോഗിൽ bin.
CQL SQL-ൽ നിന്ന് പ്രചോദനം ഉൾക്കൊണ്ടതാണെന്നും പട്ടികകൾ, വരികൾ, നിരകൾ, സൂചികകൾ എന്നിവയുടെ സമാന ആശയങ്ങളുണ്ടെന്നും ശ്രദ്ധിക്കുക. എന്നിരുന്നാലും, ഒരു NoSQL ഭാഷ എന്ന നിലയിൽ, ഇത് ഒരു നിശ്ചിത പരിമിതികൾ ചേർക്കുന്നു, അവയിൽ മിക്കതും ഞങ്ങൾ മറ്റ് ലേഖനങ്ങളിൽ ഉൾപ്പെടുത്തും.

docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlsh

മോംഗോഡിബി

മോങ്കോ മോംഗോഡിബിയുമായി സംവദിക്കുന്നതിനുള്ള ഒരു കമാൻഡ് ലൈൻ ഷെൽ ആണ്. മോംഗോഡിബി ഇൻസ്റ്റാളേഷന്റെ ബിൻ ഡയറക്ടറിയിൽ ഇത് കാണാം.

docker exec -it my-mongo bash 
cd bin
mongo

ഒരു മേശ ഉണ്ടാക്കുന്നു

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

PostgreSQL എന്നീ

CREATE TABLE Music (
    Artist VARCHAR(20) NOT NULL, 
    SongTitle VARCHAR(30) NOT NULL,
    AlbumTitle VARCHAR(25),
    Year INT,
    Price FLOAT,
    Genre VARCHAR(10),
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);	

ചേട്ടനാണു

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

CREATE KEYSPACE myapp;
USE myapp;
CREATE TABLE Music (
    Artist TEXT, 
    SongTitle TEXT,
    AlbumTitle TEXT,
    Year INT,
    Price FLOAT,
    Genre TEXT,
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);

മോംഗോഡിബി

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

use myNewDatabase;

ഒരു പട്ടികയെക്കുറിച്ചുള്ള വിവരങ്ങൾ നേടുന്നു
PostgreSQL എന്നീ

d Music
Table "public.music"
    Column    |         Type          | Collation | Nullable | Default 
--------------+-----------------------+-----------+----------+--------
 artist       | character varying(20) |           | not null | 
 songtitle    | character varying(30) |           | not null | 
 albumtitle   | character varying(25) |           |          | 
 year         | integer               |           |          | 
 price        | double precision      |           |          | 
 genre        | character varying(10) |           |          | 
 criticrating | double precision      |           |          | 
 tags         | text                  |           |          | 
Indexes:
    "music_pkey" PRIMARY KEY, btree (artist, songtitle)

ചേട്ടനാണു

DESCRIBE TABLE MUSIC;
CREATE TABLE myapp.music (
    artist text,
    songtitle text,
    albumtitle text,
    year int,
    price float,
    genre text,
    tags text,
    PRIMARY KEY (artist, songtitle)
) WITH CLUSTERING ORDER BY (songtitle ASC)
    AND default_time_to_live = 0
    AND transactions = {'enabled': 'false'};

മോംഗോഡിബി

use myNewDatabase;
show collections;

ഒരു പട്ടികയിൽ ഡാറ്റ നൽകുന്നു
PostgreSQL എന്നീ

INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Year, Price, Genre, CriticRating, 
    Tags)
VALUES(
    'No One You Know', 'Call Me Today', 'Somewhat Famous',
    2015, 2.14, 'Country', 7.8,
    '{"Composers": ["Smith", "Jones", "Davis"],"LengthInSeconds": 214}'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, CriticRating)
VALUES(
    'No One You Know', 'My Dog Spot', 'Hey Now',
    1.98, 'Country', 8.4
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre)
VALUES(
    'The Acme Band', 'Look Out, World', 'The Buck Starts Here',
    0.99, 'Rock'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, 
    Tags)
VALUES(
    'The Acme Band', 'Still In Love', 'The Buck Starts Here',
    2.47, 'Rock', 
    '{"radioStationsPlaying": ["KHCR", "KBQX", "WTNR", "WJJH"], "tourDates": { "Seattle": "20150625", "Cleveland": "20150630"}, "rotation": Heavy}'
);

ചേട്ടനാണു

മൊത്തത്തിലുള്ള ആവിഷ്കാരം INSERT കസാന്ദ്രയിൽ PostgreSQL-ലേതിന് വളരെ സാമ്യമുണ്ട്. എന്നിരുന്നാലും, അർത്ഥശാസ്ത്രത്തിൽ ഒരു വലിയ വ്യത്യാസമുണ്ട്. കസാന്ദ്രയിൽ INSERT യഥാർത്ഥത്തിൽ ഒരു ഓപ്പറേഷൻ ആണ് UPSERT, വരി നിലവിലുണ്ടെങ്കിൽ അവസാന മൂല്യങ്ങൾ വരിയിൽ ചേർക്കുന്നു.

ഡാറ്റാ എൻട്രി PostgreSQL-ന് സമാനമാണ് INSERT കൂടുതൽ

.

മോംഗോഡിബി

മോംഗോഡിബി കസാന്ദ്രയെപ്പോലെ ഒരു NoSQL ഡാറ്റാബേസ് ആണെങ്കിലും, അതിന്റെ ഉൾപ്പെടുത്തൽ പ്രവർത്തനത്തിന് കസാന്ദ്രയുടെ സെമാന്റിക് സ്വഭാവവുമായി പൊതുവായി ഒന്നുമില്ല. മോംഗോഡിബിയിൽ തിരുകുക () അവസരങ്ങളില്ല UPSERT, ഇത് PostgreSQL-ന് സമാനമാക്കുന്നു. ഇല്ലാതെ ഡിഫോൾട്ട് ഡാറ്റ ചേർക്കുന്നു _idspecified ശേഖരത്തിലേക്ക് ഒരു പുതിയ പ്രമാണം ചേർക്കുന്നതിന് കാരണമാകും.

db.music.insert( {
artist: "No One You Know",
songTitle: "Call Me Today",
albumTitle: "Somewhat Famous",
year: 2015,
price: 2.14,
genre: "Country",
tags: {
Composers: ["Smith", "Jones", "Davis"],
LengthInSeconds: 214
}
}
);
db.music.insert( {
artist: "No One You Know",
songTitle: "My Dog Spot",
albumTitle: "Hey Now",
price: 1.98,
genre: "Country",
criticRating: 8.4
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Look Out, World",
albumTitle:"The Buck Starts Here",
price: 0.99,
genre: "Rock"
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Still In Love",
albumTitle:"The Buck Starts Here",
price: 2.47,
genre: "Rock",
tags: {
radioStationsPlaying:["KHCR", "KBQX", "WTNR", "WJJH"],
tourDates: {
Seattle: "20150625",
Cleveland: "20150630"
},
rotation: "Heavy"
}
}
);

പട്ടിക ചോദ്യം

അന്വേഷണ നിർമ്മാണത്തിന്റെ കാര്യത്തിൽ SQL ഉം NoSQL ഉം തമ്മിലുള്ള ഏറ്റവും പ്രധാനപ്പെട്ട വ്യത്യാസം ഉപയോഗിച്ച ഭാഷയാണ് FROM и WHERE. എക്സ്പ്രഷനുശേഷം SQL അനുവദിക്കുന്നു FROM ഒന്നിലധികം പട്ടികകൾ തിരഞ്ഞെടുക്കുക, ഒപ്പം എക്സ്പ്രഷൻ WHERE ഏത് സങ്കീർണ്ണതയിലും ആകാം (പ്രവർത്തനങ്ങൾ ഉൾപ്പെടെ JOIN പട്ടികകൾക്കിടയിൽ). എന്നിരുന്നാലും, NoSQL ഒരു കടുത്ത പരിമിതി ചുമത്തുന്നു FROM, കൂടാതെ ഒരു നിർദ്ദിഷ്‌ട പട്ടികയിൽ മാത്രം പ്രവർത്തിക്കുക WHERE, പ്രാഥമിക കീ എപ്പോഴും വ്യക്തമാക്കിയിരിക്കണം. ഞങ്ങൾ നേരത്തെ സംസാരിച്ച NoSQL പ്രകടന പുഷുമായി ഇത് ബന്ധപ്പെട്ടിരിക്കുന്നു. ഈ ആഗ്രഹം ഏതെങ്കിലും ക്രോസ്-ടേബിൾ, ക്രോസ്-കീ ഇടപെടലുകളിൽ സാധ്യമായ എല്ലാ കുറവുകളിലേക്കും നയിക്കുന്നു. ഒരു അഭ്യർത്ഥനയോട് പ്രതികരിക്കുമ്പോൾ ഇത് ഇന്റർ-നോഡ് ആശയവിനിമയത്തിൽ വലിയ കാലതാമസം വരുത്താം, അതിനാൽ പൊതുവെ ഒഴിവാക്കുന്നതാണ് നല്ലത്. ഉദാഹരണത്തിന്, ചില ഓപ്പറേറ്റർമാർക്ക് മാത്രമായി അന്വേഷണങ്ങൾ പരിമിതപ്പെടുത്താൻ കസാന്ദ്ര ആവശ്യപ്പെടുന്നു (മാത്രം =, IN, <, >, =>, <=) പാർട്ടീഷൻ കീകളിൽ, ഒരു ദ്വിതീയ സൂചിക അഭ്യർത്ഥിക്കുമ്പോൾ ഒഴികെ (ഇവിടെ = ഓപ്പറേറ്റർ മാത്രം അനുവദനീയമാണ്).

PostgreSQL എന്നീ

ഒരു SQL ഡാറ്റാബേസിന് എളുപ്പത്തിൽ നടപ്പിലാക്കാൻ കഴിയുന്ന ചോദ്യങ്ങളുടെ മൂന്ന് ഉദാഹരണങ്ങൾ ചുവടെയുണ്ട്.

• ഒരു കലാകാരന്റെ എല്ലാ ഗാനങ്ങളും പ്രദർശിപ്പിക്കുക;
• ശീർഷകത്തിന്റെ ആദ്യ ഭാഗവുമായി പൊരുത്തപ്പെടുന്ന കലാകാരന്റെ എല്ലാ ഗാനങ്ങളും പ്രദർശിപ്പിക്കുക;
• ശീർഷകത്തിൽ ഒരു നിശ്ചിത വാക്ക് ഉള്ളതും 1.00-ൽ താഴെ വിലയുള്ളതുമായ ഒരു കലാകാരന്റെ എല്ലാ ഗാനങ്ങളും പ്രദർശിപ്പിക്കുക.

SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE 'Call%';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE '%Today%'
AND Price > 1.00;

ചേട്ടനാണു

മുകളിൽ ലിസ്റ്റുചെയ്തിരിക്കുന്ന PostgreSQL അന്വേഷണങ്ങളിൽ, ആദ്യത്തേത് മാത്രമേ കസാന്ദ്രയിൽ മാറ്റമില്ലാതെ പ്രവർത്തിക്കൂ, കാരണം ഓപ്പറേറ്റർ LIKE പോലുള്ള ക്ലസ്റ്ററിംഗ് കോളങ്ങളിൽ പ്രയോഗിക്കാൻ കഴിയില്ല SongTitle. ഈ സാഹചര്യത്തിൽ, ഓപ്പറേറ്റർമാരെ മാത്രമേ അനുവദിക്കൂ = и IN.

SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle IN ('Call Me Today', 'My Dog Spot')
AND Price > 1.00;

മോംഗോഡിബി

മുമ്പത്തെ ഉദാഹരണങ്ങളിൽ കാണിച്ചിരിക്കുന്നതുപോലെ, MongoDB-യിൽ ചോദ്യങ്ങൾ സൃഷ്ടിക്കുന്നതിനുള്ള പ്രധാന രീതി db.collection.find(). ഈ രീതിയിൽ ശേഖരത്തിന്റെ പേര് വ്യക്തമായി അടങ്ങിയിരിക്കുന്നു (music ചുവടെയുള്ള ഉദാഹരണത്തിൽ), അതിനാൽ ഒന്നിലധികം ശേഖരങ്ങൾ അന്വേഷിക്കുന്നത് നിരോധിച്ചിരിക്കുന്നു.

db.music.find( {
  artist: "No One You Know"
 } 
);
db.music.find( {
  artist: "No One You Know",
  songTitle: /Call/
 } 
);

ഒരു മേശയുടെ എല്ലാ വരികളും വായിക്കുന്നു

എല്ലാ വരികളും വായിക്കുന്നത് നമ്മൾ നേരത്തെ നോക്കിയ അന്വേഷണ പാറ്റേണിന്റെ ഒരു പ്രത്യേക കേസാണ്.

PostgreSQL എന്നീ

SELECT * 
FROM Music;

ചേട്ടനാണു

മുകളിലുള്ള PostgreSQL ഉദാഹരണത്തിന് സമാനമാണ്.

മോംഗോഡിബി

db.music.find( {} );

ഒരു പട്ടികയിലെ ഡാറ്റ എഡിറ്റുചെയ്യുന്നു

PostgreSQL എന്നീ

PostgreSQL നിർദ്ദേശങ്ങൾ നൽകുന്നു UPDATE ഡാറ്റ മാറ്റാൻ. അവൾക്ക് അവസരങ്ങളൊന്നുമില്ല UPSERT, അതിനാൽ വരി ഡാറ്റാബേസിൽ ഇല്ലെങ്കിൽ ഈ പ്രസ്താവന പരാജയപ്പെടും.

UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';

ചേട്ടനാണു

കസാന്ദ്രയ്ക്ക് ഉണ്ട് UPDATE PostgreSQL-ന് സമാനമാണ്. UPDATE ഒരേ അർത്ഥശാസ്ത്രമുണ്ട് UPSERT, സമാനമായ INSERT.

മുകളിലുള്ള PostgreSQL ഉദാഹരണത്തിന് സമാനമാണ്.

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

db.music.update(
  {"artist": "The Acme Band"},
  { 
    $set: {
      "genre": "Disco"
    }
  },
  {"multi": true, "upsert": true}
);

ഒരു പട്ടികയിൽ നിന്ന് ഡാറ്റ നീക്കംചെയ്യുന്നു

PostgreSQL എന്നീ

DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';

ചേട്ടനാണു

മുകളിലുള്ള PostgreSQL ഉദാഹരണത്തിന് സമാനമാണ്.

മോംഗോഡിബി

ഡോക്യുമെന്റുകൾ ഇല്ലാതാക്കാൻ മോംഗോഡിബിക്ക് രണ്ട് തരം പ്രവർത്തനങ്ങളുണ്ട് - deleteOne() പലതും ഇല്ലാതാക്കുക() и നീക്കംചെയ്യുക (). രണ്ട് തരങ്ങളും പ്രമാണങ്ങൾ ഇല്ലാതാക്കുന്നു, പക്ഷേ വ്യത്യസ്ത ഫലങ്ങൾ നൽകുന്നു.

db.music.deleteMany( {
        artist: "The Acme Band"
    }
);

ഒരു പട്ടിക ഇല്ലാതാക്കുന്നു

PostgreSQL എന്നീ

DROP TABLE Music;

ചേട്ടനാണു

മുകളിലുള്ള PostgreSQL ഉദാഹരണത്തിന് സമാനമാണ്.

മോംഗോഡിബി

db.music.drop();

തീരുമാനം

SQL-നും NoSQL-നും ഇടയിൽ തിരഞ്ഞെടുക്കുന്നതിനെക്കുറിച്ചുള്ള ചർച്ച 10 വർഷത്തിലേറെയായി നടക്കുന്നു. ഈ സംവാദത്തിന് രണ്ട് പ്രധാന വശങ്ങളുണ്ട്: ഡാറ്റാബേസ് എഞ്ചിൻ ആർക്കിടെക്ചർ (മോണോലിത്തിക്ക്, ട്രാൻസാക്ഷണൽ SQL vs വിതരണം, നോൺ-ട്രാൻസക്ഷണൽ NoSQL), ഡാറ്റാബേസ് ഡിസൈൻ സമീപനം (SQL-ൽ നിങ്ങളുടെ ഡാറ്റ മോഡലിംഗ്, NoSQL-ൽ നിങ്ങളുടെ ചോദ്യങ്ങൾ മോഡലിംഗ്).

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

കൂടാതെ, ഒരു ലേഖനത്തിൽ പറഞ്ഞിരിക്കുന്നതുപോലെ Google ക്ലൗഡ്, ഇടപാട്, ശക്തമായി സ്ഥിരതയുള്ള വാസ്തുവിദ്യകൾ ഇപ്പോൾ കൂടുതൽ , ഇടപാട് അല്ലാത്ത, ഒടുവിൽ സ്ഥിരതയുള്ള ആർക്കിടെക്ചറുകളേക്കാൾ മികച്ച വികസന ചാപല്യം നൽകാൻ ഉപയോഗിക്കുന്നു.

ഡാറ്റാബേസ് ഡിസൈൻ ചർച്ചയിലേക്ക് തിരികെ വരുമ്പോൾ, ഏത് സങ്കീർണ്ണമായ യഥാർത്ഥ ലോക ആപ്ലിക്കേഷനും രണ്ട് ഡിസൈൻ സമീപനങ്ങളും (SQL, NoSQL) ആവശ്യമാണെന്ന് പറയുന്നത് ന്യായമാണ്. SQL "ഡാറ്റ മോഡലിംഗ്" സമീപനം, മാറുന്ന ബിസിനസ് ആവശ്യകതകൾ കൂടുതൽ എളുപ്പത്തിൽ നിറവേറ്റാൻ ഡവലപ്പർമാരെ അനുവദിക്കുന്നു, അതേസമയം NoSQL "ക്വറി മോഡലിംഗ്" സമീപനം അതേ ഡെവലപ്പർമാരെ കുറഞ്ഞ ലേറ്റൻസിയും ഉയർന്ന ത്രൂപുട്ടും ഉള്ള വലിയ അളവിലുള്ള ഡാറ്റയിൽ പ്രവർത്തിക്കാൻ അനുവദിക്കുന്നു. ഇക്കാരണത്താൽ YugaByte DB ഒരു സമീപനം പ്രോത്സാഹിപ്പിക്കുന്നതിനുപകരം ഒരു പൊതു കോറിൽ SQL, NoSQL API-കൾ നൽകുന്നു. കൂടാതെ, PostgreSQL, Cassandra എന്നിവയുൾപ്പെടെയുള്ള ജനപ്രിയ ഡാറ്റാബേസ് ഭാഷകളുമായി അനുയോജ്യത നൽകുന്നതിലൂടെ, യുഗബൈറ്റ് ഡിബി, വിതരണം ചെയ്തതും ഉയർന്ന സ്ഥിരതയുള്ളതുമായ ഡാറ്റാബേസ് എഞ്ചിനുമായി പ്രവർത്തിക്കാൻ ഡെവലപ്പർമാർ മറ്റൊരു ഭാഷ പഠിക്കേണ്ടതില്ലെന്ന് ഉറപ്പാക്കുന്നു.

ഈ ലേഖനത്തിൽ, PostgreSQL, Cassandra, MongoDB എന്നിവയ്ക്കിടയിൽ ഡാറ്റാബേസ് ഡിസൈൻ അടിസ്ഥാനങ്ങൾ എങ്ങനെ വ്യത്യാസപ്പെട്ടിരിക്കുന്നുവെന്ന് ഞങ്ങൾ പരിശോധിച്ചു. ഭാവിയിലെ ലേഖനങ്ങളിൽ, സൂചികകൾ, ഇടപാടുകൾ, ജോയിനുകൾ, TTL നിർദ്ദേശങ്ങൾ, JSON ഡോക്യുമെന്റുകൾ എന്നിവ പോലുള്ള വിപുലമായ ഡിസൈൻ ആശയങ്ങളിലേക്ക് ഞങ്ങൾ കടക്കും.

വാരാന്ത്യത്തിൽ നിങ്ങൾക്ക് മികച്ച വിശ്രമം ആശംസിക്കുകയും നിങ്ങളെ ക്ഷണിക്കുകയും ചെയ്യുന്നു സൗജന്യ വെബിനാർ, മെയ് 14 ന് നടക്കും.

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