വീൽസെറ്റുകൾക്കുള്ള ഡിസ്ട്രിബ്യൂട്ടഡ് രജിസ്ട്രി: ഹൈപ്പർലെഡ്ജർ ഫാബ്രിക്കുമായുള്ള ഒരു അനുഭവം

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

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

പ്രശ്നം: ബ്ലോക്ക്ചെയിനുകൾ ഇതുവരെ സ്കെയിലബിൾ ആയിട്ടില്ല

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

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

അടുത്ത വികസനം സെക്കൻഡിൽ ദശലക്ഷക്കണക്കിന് ഇടപാടുകൾ അനുവദിക്കുമെന്ന് വൈറ്റ്പേപ്പറുകളിൽ നിന്നും മാധ്യമങ്ങളിൽ നിന്നുമുള്ള മുദ്രാവാക്യങ്ങൾ നമുക്ക് വാഗ്ദാനം ചെയ്യുന്നു. അത് ശരിക്കും എന്താണ്?

Mainnet Ethereum നിലവിൽ ~30 ടിപിഎസ് വേഗതയിലാണ് പ്രവർത്തിക്കുന്നത്. ഇക്കാരണത്താൽ മാത്രം, കോർപ്പറേറ്റ് ആവശ്യങ്ങൾക്ക് അനുയോജ്യമായ ഒരു ബ്ലോക്ക്ചെയിൻ ആയി അതിനെ മനസ്സിലാക്കാൻ പ്രയാസമാണ്. അനുവദനീയമായ പരിഹാരങ്ങളിൽ, 2000 ടിപിഎസ് കാണിക്കുന്ന ബെഞ്ച്മാർക്കുകൾ അറിയപ്പെടുന്നു (Quorum) അല്ലെങ്കിൽ 3000 ടിപിഎസ് (ഹൈപ്പർലേജർ ഫാബ്രിക്, പ്രസിദ്ധീകരണത്തിൽ അൽപ്പം കുറവുണ്ട്, എന്നാൽ പഴയ സമവായ എഞ്ചിനിലാണ് മാനദണ്ഡം നടപ്പിലാക്കിയതെന്ന് ഓർമ്മിക്കുക). ആയിരുന്നു ഫാബ്രിക്ക് സമൂലമായി പുനർനിർമ്മിക്കാനുള്ള ശ്രമം, ഇത് ഏറ്റവും മോശം ഫലങ്ങൾ നൽകിയില്ല, 20000 ടിപിഎസ്, എന്നാൽ ഇതുവരെ ഇവ സ്ഥിരമായ നടപ്പാക്കലിനായി കാത്തിരിക്കുന്ന അക്കാദമിക് പഠനങ്ങൾ മാത്രമാണ്. ബ്ലോക്ക്‌ചെയിൻ ഡെവലപ്പർമാരുടെ ഒരു ഡിപ്പാർട്ട്‌മെന്റ് പരിപാലിക്കാൻ കഴിയുന്ന ഒരു കോർപ്പറേഷൻ അത്തരം സൂചകങ്ങൾ പാലിക്കാൻ സാധ്യതയില്ല. എന്നാൽ പ്രശ്നം ത്രോപുട്ടിൽ മാത്രമല്ല, ലേറ്റൻസിയും ഉണ്ട്.

ലേറ്റൻസി

ഒരു ഇടപാട് ആരംഭിച്ച നിമിഷം മുതൽ സിസ്റ്റം അതിന്റെ അന്തിമ അംഗീകാരം വരെയുള്ള കാലതാമസം, മൂല്യനിർണ്ണയത്തിന്റെയും ഓർഡറിംഗിന്റെയും എല്ലാ ഘട്ടങ്ങളിലൂടെയും കടന്നുപോകുന്ന സന്ദേശത്തിന്റെ വേഗതയെ മാത്രമല്ല, ബ്ലോക്ക് രൂപീകരണ പാരാമീറ്ററുകളെയും ആശ്രയിച്ചിരിക്കുന്നു. 1000000 ടിപിഎസ് കമ്മിറ്റ് ചെയ്യാൻ ഞങ്ങളുടെ ബ്ലോക്ക്ചെയിൻ ഞങ്ങളെ അനുവദിച്ചാലും, 10MB ബ്ലോക്ക് രൂപീകരിക്കാൻ 488 മിനിറ്റ് എടുക്കും, അത് ഞങ്ങൾക്ക് എളുപ്പമാകുമോ?

ഹൈപ്പർലെഡ്ജർ ഫാബ്രിക്കിലെ ഒരു ഇടപാടിന്റെ ജീവിത ചക്രം നമുക്ക് സൂക്ഷ്മമായി പരിശോധിക്കാം, എന്താണ് സമയമെടുക്കുന്നതെന്നും അത് ബ്ലോക്ക് രൂപീകരണ പാരാമീറ്ററുകളുമായി എങ്ങനെ ബന്ധപ്പെട്ടിരിക്കുന്നുവെന്നും മനസ്സിലാക്കാൻ.

ഇവിടെ നിന്ന് എടുത്തത്: hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html#swimlane

(1) ക്ലയന്റ് ഒരു ഇടപാട് നടത്തുന്നു, അത് അംഗീകരിക്കുന്ന സമപ്രായക്കാർക്ക് അയയ്ക്കുന്നു, രണ്ടാമത്തേത് ഇടപാടിനെ അനുകരിക്കുന്നു (നിലവിലെ അവസ്ഥയിലേക്ക് ചെയിൻകോഡ് വരുത്തിയ മാറ്റങ്ങൾ പ്രയോഗിക്കുക, പക്ഷേ ലെഡ്ജറിൽ പ്രതിജ്ഞാബദ്ധമാക്കരുത്) കൂടാതെ RWSet - പ്രധാന പേരുകൾ, പതിപ്പുകൾ എന്നിവ സ്വീകരിക്കുക. CouchDB-യിലെ ശേഖരണത്തിൽ നിന്ന് എടുത്ത മൂല്യങ്ങൾ, (2) അംഗീകൃതർ ഒരു ഒപ്പിട്ട RWSet ക്ലയന്റിലേക്ക് തിരികെ അയയ്ക്കുന്നു, (3) ക്ലയന്റ് ഒന്നുകിൽ ആവശ്യമായ എല്ലാ സഹപാഠികളുടെയും (എൻഡോഴ്‌സർമാർ) ഒപ്പ് പരിശോധിക്കുന്നു, തുടർന്ന് ഇടപാട് ഓർഡറിംഗിലേക്ക് അയയ്ക്കുന്നു. സേവനം, അല്ലെങ്കിൽ പരിശോധിച്ചുറപ്പിക്കാതെ അയയ്‌ക്കുന്നു (പരിശോധനം തുടർന്നും നടക്കും), ഓർഡറിംഗ് സേവനം ഒരു ബ്ലോക്ക് രൂപീകരിക്കുകയും (4) എല്ലാ സഹപാഠികൾക്കും തിരികെ അയയ്‌ക്കുകയും ചെയ്യുന്നു, അംഗീകാരം നൽകുന്നവർ മാത്രമല്ല; റീഡ് സെറ്റിലെ കീകളുടെ പതിപ്പുകൾ ഡാറ്റാബേസിലെ പതിപ്പുകളുമായും എല്ലാ എൻഡോഴ്‌സർമാരുടെയും ഒപ്പുകളുമായും പൊരുത്തപ്പെടുന്നുണ്ടോയെന്ന് സഹപ്രവർത്തകർ പരിശോധിച്ച് ഒടുവിൽ തടയുക.

എന്നാൽ അത് മാത്രമല്ല. “ഓർഡർ ഒരു ബ്ലോക്ക് ഉണ്ടാക്കുന്നു” എന്ന വാക്കിന് പിന്നിൽ ഇടപാടുകളുടെ ക്രമം മാത്രമല്ല, ലീഡറിൽ നിന്ന് അനുയായികളിലേക്കും തിരിച്ചും തുടർച്ചയായി 3 നെറ്റ്‌വർക്ക് അഭ്യർത്ഥനകളും മറഞ്ഞിരിക്കുന്നു: നേതാവ് ലോഗിലേക്ക് ഒരു സന്ദേശം ചേർക്കുന്നു, അനുയായികൾക്ക് അയയ്ക്കുന്നു, രണ്ടാമത്തേത് ഇതിലേക്ക് ചേർക്കുന്നു. അവരുടെ ലോഗ്, വിജയകരമായ ആവർത്തനത്തിന്റെ സ്ഥിരീകരണം നേതാവിന് അയയ്ക്കുക, നേതാവ് സന്ദേശം സമർപ്പിക്കുന്നു, അനുയായികൾക്ക് പ്രതിബദ്ധത സ്ഥിരീകരണം അയയ്ക്കുന്നു, അനുയായികൾ സമർപ്പിക്കുന്നു. ബ്ലോക്കിന്റെ വലുപ്പവും സമയവും ചെറുതാകുമ്പോൾ, ഓർഡറിംഗ് സേവനത്തിന് സമവായം സ്ഥാപിക്കേണ്ടിവരും. ഹൈപ്പർലെഡ്ജർ ഫാബ്രിക്കിന് രണ്ട് ബ്ലോക്ക് രൂപീകരണ പാരാമീറ്ററുകളുണ്ട്: BatchTimeout - ബ്ലോക്ക് രൂപീകരണ സമയം, BatchSize - ബ്ലോക്ക് വലുപ്പം (ഇടപാടുകളുടെ എണ്ണവും ബ്ലോക്കിന്റെ വലുപ്പവും ബൈറ്റുകളിൽ തന്നെ). പരാമീറ്ററുകളിലൊന്ന് പരിധിയിലെത്തുമ്പോൾ, ഒരു പുതിയ ബ്ലോക്ക് ഇഷ്യു ചെയ്യുന്നു. കൂടുതൽ ഓർഡർ നോഡുകൾ, ഇത് കൂടുതൽ സമയം എടുക്കും. അതിനാൽ, നിങ്ങൾ BatchTimeout, BatchSize എന്നിവ വർദ്ധിപ്പിക്കേണ്ടതുണ്ട്. എന്നാൽ RWSets പതിപ്പ് ആയതിനാൽ, ഞങ്ങൾ ബ്ലോക്ക് വലുതാക്കുന്നു, MVCC വൈരുദ്ധ്യങ്ങളുടെ സാധ്യത കൂടുതലാണ്. കൂടാതെ, ബാച്ച് ടൈംഔട്ടിന്റെ വർദ്ധനവോടെ, UX വിനാശകരമായി തരംതാഴുന്നു. ഈ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിനുള്ള ഇനിപ്പറയുന്ന സ്കീം ന്യായയുക്തവും വ്യക്തവുമാണെന്ന് എനിക്ക് തോന്നുന്നു.

ബ്ലോക്ക് ഫൈനലൈസേഷനായി കാത്തിരിക്കുന്നതും ഇടപാട് നിലയുടെ ട്രാക്ക് നഷ്‌ടപ്പെടാതിരിക്കുന്നതും എങ്ങനെ ഒഴിവാക്കാം

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

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

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

അടുത്ത ഘട്ടം, സിസ്റ്റവുമായുള്ള ക്ലയന്റിന്റെ ഇടപെടൽ അസമന്വിതമാക്കുക എന്നതാണ്, അതുവഴി അത് 15, 30 അല്ലെങ്കിൽ 10000000 സെക്കൻഡുകൾ വരെ കാത്തിരിക്കില്ല, അത് ഞങ്ങൾ ബാച്ച് ടൈംഔട്ടായി സജ്ജമാക്കും. എന്നാൽ അതേ സമയം, ഇടപാട് ആരംഭിച്ച മാറ്റങ്ങൾ ബ്ലോക്ക്ചെയിനിൽ രേഖപ്പെടുത്തിയിട്ടുണ്ടെന്ന് / രേഖപ്പെടുത്തിയിട്ടില്ലെന്ന് ഉറപ്പാക്കാനുള്ള കഴിവ് നിലനിർത്തേണ്ടത് ആവശ്യമാണ്.
ഇടപാട് നില സംഭരിക്കുന്നതിന് ഒരു ഡാറ്റാബേസ് ഉപയോഗിക്കാം. എളുപ്പത്തിലുള്ള ഉപയോഗം കാരണം CouchDB ആണ് ഏറ്റവും ലളിതമായ ഓപ്ഷൻ: ഡാറ്റാബേസിന് ബോക്‌സിന് പുറത്ത് ഒരു UI ഉണ്ട്, ഒരു REST API, നിങ്ങൾക്ക് അതിനായി എളുപ്പത്തിൽ റെപ്ലിക്കേഷനും ഷാർഡിംഗും സജ്ജീകരിക്കാനാകും. ഫാബ്രിക്ക് അതിന്റെ വേൾഡ് സ്റ്റേറ്റ് സംഭരിക്കാൻ ഉപയോഗിക്കുന്ന അതേ CouchDB ഉദാഹരണത്തിൽ നിങ്ങൾക്ക് ഒരു പ്രത്യേക ശേഖരം സൃഷ്ടിക്കാൻ കഴിയും. ഇത്തരത്തിലുള്ള രേഖകൾ നമ്മൾ സൂക്ഷിക്കേണ്ടതുണ്ട്.

{
 Status string // Статус транзакции: "pending", "done", "failed"
 TxID: string // ID транзакции
 Error: string // optional, сообщение об ошибке
}

ഇടപാട് സമപ്രായക്കാർക്ക് അയയ്‌ക്കുന്നതിന് മുമ്പ് ഈ ഡോക്യുമെന്റ് ഡാറ്റാബേസിലേക്ക് എഴുതിയിരിക്കുന്നു, ഇത് ഒരു സൃഷ്‌ടി പ്രവർത്തനമാണെങ്കിൽ, എന്റിറ്റി ഐഡി ഉപയോക്താവിന് തിരികെ നൽകും (അതേ ഐഡി ഒരു കീയായി ഉപയോഗിക്കുന്നു), തുടർന്ന് സ്റ്റാറ്റസ്, ടിഎക്സ്ഐഡി, പിശക് ഫീൽഡുകൾ എന്നിവ സമപ്രായക്കാരിൽ നിന്ന് പ്രസക്തമായ വിവരങ്ങൾ ലഭിച്ചതിനാൽ അപ്ഡേറ്റ് ചെയ്യുന്നു.

ഈ സ്കീമിൽ, ബ്ലോക്ക് രൂപപ്പെടുന്നതുവരെ ഉപയോക്താവ് കാത്തിരിക്കുന്നില്ല, സ്ക്രീനിൽ 10 സെക്കൻഡ് നേരം സ്പിന്നിംഗ് വീൽ വീക്ഷിക്കുന്നു, അയാൾക്ക് സിസ്റ്റത്തിൽ നിന്ന് തൽക്ഷണ പ്രതികരണം ലഭിക്കുകയും പ്രവർത്തിക്കുകയും ചെയ്യുന്നു.

ഞങ്ങൾക്ക് മെമ്മറി ലാഭിക്കേണ്ടതിനാലും ഒരു സ്റ്റാൻഡ്-എലോൺ ഡാറ്റാബേസ് സെർവറുമായുള്ള നെറ്റ്‌വർക്ക് ഇടപെടലിൽ സമയം പാഴാക്കേണ്ടതില്ലാത്തതിനാലും ഇടപാട് സ്റ്റാറ്റസുകൾ സംഭരിക്കുന്നതിന് ഞങ്ങൾ BoltDB തിരഞ്ഞെടുത്തു, പ്രത്യേകിച്ചും ഈ ഇടപെടൽ പ്ലെയിൻ ടെക്സ്റ്റ് പ്രോട്ടോക്കോൾ ഉപയോഗിച്ച് നടക്കുമ്പോൾ. വഴിയിൽ, മുകളിൽ വിവരിച്ച സ്കീം നടപ്പിലാക്കാൻ നിങ്ങൾ CouchDB ഉപയോഗിക്കുന്നുണ്ടോ അതോ ലോക നില സംഭരിക്കുന്നതിന് വേണ്ടിയാണെങ്കിലും, CouchDB-യിൽ ഡാറ്റ സംഭരിക്കുന്ന രീതി ഒപ്റ്റിമൈസ് ചെയ്യുന്നത് അർത്ഥമാക്കുന്നു. ഡിഫോൾട്ടായി, CouchDB-യിൽ, b-ട്രീ നോഡുകളുടെ വലുപ്പം 1279 ബൈറ്റുകളാണ്, ഇത് ഡിസ്കിലെ സെക്ടർ വലുപ്പത്തേക്കാൾ വളരെ ചെറുതാണ്, അതായത് ട്രീ വായിക്കുന്നതിനും പുനഃസന്തുലിതമാക്കുന്നതിനും കൂടുതൽ ഫിസിക്കൽ ഡിസ്ക് ആക്‌സസ്സ് ആവശ്യമായി വരും. ഒപ്റ്റിമൽ വലുപ്പം നിലവാരം പുലർത്തുന്നു വിപുലമായ ഫോർമാറ്റ് 4 കിലോബൈറ്റ് ആണ്. ഒപ്റ്റിമൈസേഷനായി, ഞങ്ങൾ പാരാമീറ്റർ സജ്ജമാക്കേണ്ടതുണ്ട് btree_chunk_size 4096 ന് തുല്യമാണ് CouchDB കോൺഫിഗറേഷൻ ഫയലിൽ. BoltDB അത്തരം മാനുവൽ ഇടപെടൽ വേണ്ടി ആവശ്യമില്ല.

പിന്നിലെ മർദ്ദം: ബഫർ തന്ത്രം

എന്നാൽ ധാരാളം സന്ദേശങ്ങൾ ഉണ്ടാകാം. സിസ്റ്റത്തിന് കൈകാര്യം ചെയ്യാൻ കഴിയുന്നതിനേക്കാൾ കൂടുതൽ, ഡയഗ്രാമിൽ കാണിച്ചിരിക്കുന്നവ കൂടാതെ മറ്റ് ഒരു ഡസൻ സേവനങ്ങളുമായി ഉറവിടങ്ങൾ പങ്കിടുന്നു - കൂടാതെ Intellij ഐഡിയ പ്രവർത്തിക്കുന്ന മെഷീനുകളിൽ പോലും ഇതെല്ലാം കുറ്റമറ്റ രീതിയിൽ പ്രവർത്തിക്കണം.

ആശയവിനിമയ സംവിധാനങ്ങൾ, നിർമ്മാതാവ്, ഉപഭോക്താവ് എന്നിവയുടെ വ്യത്യസ്ത ത്രൂപുട്ടിന്റെ പ്രശ്നം വ്യത്യസ്ത രീതികളിൽ പരിഹരിക്കപ്പെടുന്നു. നമുക്ക് എന്തുചെയ്യാനാകുമെന്ന് നോക്കാം.

ഉപേക്ഷിക്കുന്നു: T സെക്കൻഡിൽ പരമാവധി X ഇടപാടുകൾ പ്രോസസ്സ് ചെയ്യാൻ കഴിയുമെന്ന് ഞങ്ങൾക്ക് അവകാശപ്പെടാം. ഈ പരിധി കവിയുന്ന എല്ലാ അഭ്യർത്ഥനകളും ഉപേക്ഷിച്ചു. ഇത് വളരെ ലളിതമാണ്, എന്നാൽ നിങ്ങൾക്ക് UX-നെ കുറിച്ച് മറക്കാൻ കഴിയും.

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

ബഫറിംഗ്: ഇൻപുട്ട് ഡാറ്റാ സ്ട്രീമിനെ പ്രതിരോധിക്കുന്നതിന് പകരം, നമുക്ക് ഈ സ്ട്രീം ബഫർ ചെയ്ത് ആവശ്യമായ വേഗതയിൽ പ്രോസസ്സ് ചെയ്യാം. വ്യക്തമായും, ഒരു നല്ല ഉപയോക്തൃ അനുഭവം നൽകാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ ഇതാണ് ഏറ്റവും മികച്ച പരിഹാരം. RabbitMQ-ലെ ഒരു ക്യൂ ഉപയോഗിച്ച് ഞങ്ങൾ ബഫർ നടപ്പിലാക്കി.

സ്കീമിലേക്ക് രണ്ട് പുതിയ പ്രവർത്തനങ്ങൾ ചേർത്തു: (1) ഒരു API അഭ്യർത്ഥന ലഭിച്ചതിന് ശേഷം, ഇടപാടിനെ വിളിക്കുന്നതിന് ആവശ്യമായ പാരാമീറ്ററുകൾ അടങ്ങിയ ഒരു സന്ദേശം ക്യൂവിൽ വയ്ക്കുന്നു, കൂടാതെ ഇടപാട് സിസ്റ്റം അംഗീകരിച്ചതായി ക്ലയന്റിന് ഒരു സന്ദേശം ലഭിക്കുന്നു, ( 2) ക്യൂവിൽ നിന്ന് കോൺഫിഗറേഷനിൽ വ്യക്തമാക്കിയ വേഗതയിൽ ബാക്കെൻഡ് ഡാറ്റ വായിക്കുന്നു; ഒരു ഇടപാട് ആരംഭിക്കുകയും സ്റ്റാറ്റസ് സ്റ്റോറിലെ ഡാറ്റ അപ്‌ഡേറ്റ് ചെയ്യുകയും ചെയ്യുന്നു.
ഇപ്പോൾ നിങ്ങൾക്ക് ബിൽഡ് സമയം വർദ്ധിപ്പിക്കാനും നിങ്ങൾക്ക് ആവശ്യമുള്ളത്ര ബ്ലോക്ക് കപ്പാസിറ്റി വർദ്ധിപ്പിക്കാനും കഴിയും, ഉപയോക്താവിൽ നിന്ന് കാലതാമസം മറയ്ക്കുന്നു.

മറ്റ് ഉപകരണങ്ങൾ

ചെയിൻകോഡിനെക്കുറിച്ച് ഇവിടെ ഒന്നും പറഞ്ഞിട്ടില്ല, കാരണം അതിൽ ഒപ്റ്റിമൈസ് ചെയ്യാൻ സാധാരണയായി ഒന്നുമില്ല. ചെയിൻകോഡ് കഴിയുന്നത്ര ലളിതവും സുരക്ഷിതവുമായിരിക്കണം - അത് ആവശ്യമാണ്. ലളിതമായും സുരക്ഷിതമായും ചെയിൻകോഡ് എഴുതാൻ ചട്ടക്കൂട് നമ്മെ വളരെയധികം സഹായിക്കുന്നു. CSKit S7 ടെക്‌ലാബിൽ നിന്നും സ്റ്റാറ്റിക് അനലൈസറിൽ നിന്നും പുനരുജ്ജീവിപ്പിക്കുക^CC.

കൂടാതെ, ഫാബ്രിക്കിനൊപ്പം പ്രവർത്തിക്കുന്നത് ലളിതവും ആസ്വാദ്യകരവുമാക്കുന്നതിന് ഞങ്ങളുടെ ടീം ഒരു കൂട്ടം യൂട്ടിലിറ്റികൾ വികസിപ്പിക്കുന്നു: ബ്ലോക്ക്ചെയിൻ എക്സ്പ്ലോറർ, യൂട്ടിലിറ്റി യാന്ത്രിക നെറ്റ്‌വർക്ക് പുനഃക്രമീകരണം (ഓർഗനൈസേഷനുകൾ ചേർക്കുക/നീക്കംചെയ്യുക, RAFT നോഡുകൾ), ഇതിനായി യൂട്ടിലിറ്റി സർട്ടിഫിക്കറ്റ് അസാധുവാക്കലും ഐഡന്റിറ്റി നീക്കം ചെയ്യലും. നിങ്ങൾ സംഭാവന ചെയ്യാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, സ്വാഗതം.

തീരുമാനം

ഈ സമീപനം, ഹൈപ്പർലെഡ്ജർ ഫാബ്രിക്ക് കോറം, മറ്റ് സ്വകാര്യ Ethereum നെറ്റ്‌വർക്കുകൾ (PoA അല്ലെങ്കിൽ PoW) ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുന്നത് എളുപ്പമാക്കുന്നു, യഥാർത്ഥ ത്രൂപുട്ട് ഗണ്യമായി കുറയ്ക്കുന്നു, എന്നാൽ അതേ സമയം സാധാരണ UX നിലനിർത്തുന്നു (ബ്രൗസറിലെ ഉപയോക്താക്കൾക്കും സംയോജിത സിസ്റ്റങ്ങളുടെ വശത്തുനിന്നും. ). സ്കീമിൽ ഫാബ്രിക്കിനെ Ethereum ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുമ്പോൾ, MVCC വൈരുദ്ധ്യങ്ങൾ കൈകാര്യം ചെയ്യുന്നതിൽ നിന്ന് ഒരു ആറ്റോമിക് നോൺസ് ഇൻക്രിമെന്റിലേക്കും വീണ്ടും അയയ്ക്കുന്നതിലേക്കും റീട്രി സർവീസ് / ഡെക്കറേറ്ററിന്റെ ലോജിക് മാത്രം മാറ്റേണ്ടതുണ്ട്. ബഫറിംഗും സ്റ്റാറ്റസ് സ്റ്റോറേജും ബ്ലോക്ക് രൂപീകരണ സമയത്തിൽ നിന്ന് പ്രതികരണ സമയം വേർപെടുത്തുന്നത് സാധ്യമാക്കി. ഇപ്പോൾ നിങ്ങൾക്ക് ആയിരക്കണക്കിന് ഓർഡർ നോഡുകൾ ചേർക്കാൻ കഴിയും, കൂടാതെ ബ്ലോക്കുകൾ ഇടയ്ക്കിടെ രൂപപ്പെടുകയും ഓർഡറിംഗ് സേവനം ലോഡ് ചെയ്യുകയും ചെയ്യുമെന്ന് ഭയപ്പെടരുത്.

പൊതുവേ, ഞാൻ പങ്കിടാൻ ആഗ്രഹിച്ചത് ഇതാണ്. ആരെയെങ്കിലും അവരുടെ ജോലിയിൽ സഹായിച്ചാൽ ഞാൻ സന്തോഷിക്കും.

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