વ્હીલસેટ્સ માટે વિતરિત રજિસ્ટ્રી: હાયપરલેજર ફેબ્રિક સાથેનો અનુભવ

હેલો, હું DRD KP પ્રોજેક્ટની ટીમમાં કામ કરું છું (વ્હીલ સેટના જીવન ચક્રનું નિરીક્ષણ કરવા માટે વિતરિત ડેટા રજિસ્ટ્રી). અહીં હું ટેકનોલોજીની મર્યાદાઓ હેઠળ આ પ્રોજેક્ટ માટે એન્ટરપ્રાઇઝ બ્લોકચેન વિકસાવવામાં અમારી ટીમનો અનુભવ શેર કરવા માંગુ છું. હું મોટે ભાગે હાયપરલેજર ફેબ્રિક વિશે વાત કરીશ, પરંતુ અહીં વર્ણવેલ અભિગમ કોઈપણ પરવાનગીવાળા બ્લોકચેનમાં એક્સ્ટ્રાપોલેટ કરી શકાય છે. અમારા સંશોધનનો અંતિમ ધ્યેય એન્ટરપ્રાઇઝ બ્લોકચેન સોલ્યુશન્સ તૈયાર કરવાનો છે જેથી અંતિમ ઉત્પાદન વાપરવા માટે સુખદ હોય અને તેની જાળવણી કરવી ખૂબ મુશ્કેલ ન હોય.

અહીં કોઈ શોધો, અણધાર્યા ઉકેલો અને કોઈ અનન્ય વિકાસને અહીં પ્રકાશિત કરવામાં આવશે નહીં (કારણ કે મારી પાસે કોઈ નથી). હું ફક્ત મારો સાધારણ અનુભવ શેર કરવા માંગુ છું, "તે શક્ય હતું" અને, કદાચ, ટિપ્પણીઓમાં સારા અને એટલા સારા નિર્ણયો લેવાના અન્ય લોકોના અનુભવો વિશે વાંચવા માંગુ છું.

સમસ્યા: બ્લોકચેઇન્સ હજુ સુધી સ્કેલ કરતા નથી

આજે, ઘણા વિકાસકર્તાઓના પ્રયત્નોનો હેતુ બ્લોકચેનને ખરેખર અનુકૂળ ટેક્નોલોજી બનાવવાનો છે, અને સુંદર રેપરમાં ટાઇમ બોમ્બ બનાવવાનો નથી. રાજ્ય ચેનલો, આશાવાદી રોલઅપ, પ્લાઝમા અને શાર્ડિંગ કદાચ સામાન્ય બની જશે. કોઈ દિવસ. અથવા કદાચ TON ફરીથી છ મહિના માટે પ્રક્ષેપણ મુલતવી રાખશે, અને આગામી પ્લાઝ્મા જૂથ અસ્તિત્વમાં બંધ થઈ જશે. અમે આગલા રોડમેપમાં વિશ્વાસ કરી શકીએ છીએ અને રાત્રે તેજસ્વી શ્વેતપત્રો વાંચી શકીએ છીએ, પરંતુ અહીં અને હવે આપણી પાસે જે છે તેનાથી કંઈક કરવાની જરૂર છે. છી પૂર્ણ થઈ જાઓ.

વર્તમાન પ્રોજેક્ટમાં અમારી ટીમ માટેનો કાર્ય સેટ સામાન્ય રીતે આના જેવો દેખાય છે: ઘણા વિષયો છે, હજારો સુધી પહોંચે છે, જેઓ વિશ્વાસ પર સંબંધો બાંધવા માંગતા નથી; ડીએલટી પર એક સોલ્યુશન બનાવવું જરૂરી છે જે સામાન્ય પીસી પર ખાસ કામગીરીની આવશ્યકતાઓ વિના કામ કરશે અને વપરાશકર્તા અનુભવ પ્રદાન કરશે જે કોઈપણ કેન્દ્રિય એકાઉન્ટિંગ સિસ્ટમ્સ કરતાં વધુ ખરાબ નથી. સોલ્યુશન પાછળની ટેક્નોલોજીએ ડેટાના દૂષિત મેનીપ્યુલેશનની શક્યતાને ઓછી કરવી જોઈએ - તેથી જ બ્લોકચેન અહીં છે.

શ્વેતપત્રો અને મીડિયાના સૂત્રો અમને વચન આપે છે કે આગામી વિકાસ અમને સેકન્ડ દીઠ લાખો વ્યવહારો કરવાની મંજૂરી આપશે. તે ખરેખર શું છે?

મેઈનનેટ ઈથેરિયમ હાલમાં ~30 tps પર ચાલી રહ્યું છે. આ એકલાને કારણે, તેને કોર્પોરેટ જરૂરિયાતો માટે યોગ્ય કોઈપણ રીતે બ્લોકચેન તરીકે સમજવું મુશ્કેલ છે. અનુમતિ પ્રાપ્ત સોલ્યુશન્સમાં 2000 tps દર્શાવતા બેન્ચમાર્ક છે (કોરમ) અથવા 3000 ટીપીએસ (હાયપરલેડર ફેબ્રિક, પ્રકાશનમાં થોડું ઓછું છે, પરંતુ તમારે ધ્યાનમાં લેવાની જરૂર છે કે બેન્ચમાર્ક જૂના સર્વસંમતિ એન્જિન પર હાથ ધરવામાં આવ્યો હતો). હતી આમૂલ ફેબ્રિક પ્રોસેસિંગનો પ્રયાસ, જેણે સૌથી ખરાબ પરિણામો આપ્યા નથી, 20000 tps, પરંતુ અત્યાર સુધી આ માત્ર શૈક્ષણિક સંશોધન છે, તેના સ્થિર અમલીકરણની રાહ જોઈ રહ્યું છે. તે અસંભવિત છે કે જે કોર્પોરેશન બ્લોકચેન વિકાસકર્તાઓના વિભાગને જાળવવાનું પરવડે છે તે આવા સૂચકાંકો સાથે મૂકે. પરંતુ સમસ્યા માત્ર થ્રુપુટની જ નથી, લેટન્સી પણ છે.

લેટન્સી

સિસ્ટમ દ્વારા ટ્રાન્ઝેક્શન શરૂ કરવામાં આવે તે ક્ષણથી તેની અંતિમ મંજૂરી સુધીનો વિલંબ માત્ર એ જ ઝડપ પર આધારિત નથી કે જેનાથી સંદેશ માન્યતા અને ઓર્ડરિંગના તમામ તબક્કાઓમાંથી પસાર થાય છે, પણ બ્લોક નિર્માણના પરિમાણો પર પણ આધાર રાખે છે. જો અમારું બ્લોકચેન અમને 1000000 tps ની ઝડપે કમિટ કરવાની મંજૂરી આપે છે, પરંતુ 10 MB બ્લોક જનરેટ કરવા માટે 488 મિનિટની જરૂર છે, તો શું તે અમારા માટે સરળ બનશે?

ચાલો હાયપરલેજર ફેબ્રિકમાં ટ્રાન્ઝેક્શન લાઇફસાઇકલ પર નજીકથી નજર કરીએ જેથી સમય ક્યાં પસાર થાય છે અને તે બ્લોક જનરેશન પેરામીટર્સ સાથે કેવી રીતે સંબંધિત છે.

અહીંથી લીધેલ: hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html#swimlane

(1) ક્લાયન્ટ ટ્રાન્ઝેક્શન બનાવે છે, તેને સમર્થન આપતા સાથીદારોને મોકલે છે, બાદમાં ટ્રાન્ઝેક્શનનું અનુકરણ કરે છે (ચેઈનકોડ દ્વારા કરાયેલા ફેરફારોને વર્તમાન સ્થિતિમાં લાગુ કરો, પરંતુ ખાતાવહીને પ્રતિબદ્ધ ન કરો) અને RWSet પ્રાપ્ત કરો - મુખ્ય નામો, સંસ્કરણો અને મૂલ્યો CouchDB માં સંગ્રહમાંથી લેવામાં આવે છે, (2) સમર્થનકર્તા ક્લાયન્ટને હસ્તાક્ષરિત RWSet પાછા મોકલે છે, (3) ક્લાયંટ કાં તો તમામ જરૂરી સાથીદારો (સમર્થનકર્તાઓ) ની સહીઓની હાજરી માટે તપાસ કરે છે, અને પછી ઓર્ડરિંગ સેવાને વ્યવહાર મોકલે છે , અથવા તેને ચકાસણી વિના મોકલે છે (ચેક હજી પણ પછીથી થશે), ઓર્ડરિંગ સેવા એક બ્લોક બનાવે છે અને (4) માત્ર સમર્થન આપનારાઓને જ નહીં, બધા સાથીઓને પાછા મોકલે છે; સાથીદારો તપાસે છે કે રીડ સેટમાંના મુખ્ય સંસ્કરણો ડેટાબેઝમાંના સંસ્કરણો સાથે મેળ ખાય છે, કે તમામ સમર્થનકર્તાઓની સહીઓ છે અને અંતે બ્લોક કમિટ કરે છે.

પરંતુ તે બધુ જ નથી. "ઓર્ડરર એક બ્લોક બનાવે છે" શબ્દો માત્ર વ્યવહારોના ક્રમને છુપાવે છે, પણ નેતા તરફથી અનુયાયીઓને અને પાછળની 3 ક્રમિક નેટવર્ક વિનંતીઓ પણ છુપાવે છે: નેતા લોગમાં સંદેશ ઉમેરે છે, તેને અનુયાયીઓને મોકલે છે, બાદમાં તેને ઉમેરે છે. તેમના લોગ પર, નેતાને સફળ પ્રતિકૃતિની પુષ્ટિ મોકલે છે, નેતા સંદેશ મોકલે છે, અનુયાયીઓને પ્રતિબદ્ધ પુષ્ટિ મોકલે છે, અનુયાયીઓ પ્રતિબદ્ધ કરે છે. બ્લોકની રચનાનું કદ અને સમય જેટલો નાનો હશે, તેટલી વાર ઓર્ડરિંગ સેવાએ સર્વસંમતિ સ્થાપિત કરવી પડશે. હાઈપરલેજર ફેબ્રિકમાં બ્લોકની રચના માટેના બે પરિમાણો છે: બેચ ટાઈમઆઉટ - બ્લોક બનાવવાનો સમય અને બેચસાઈઝ - બ્લોકનું કદ (ટ્રાન્ઝેક્શનની સંખ્યા અને બ્લોકનું કદ બાઈટમાં જ). જલદી એક પરિમાણો મર્યાદા સુધી પહોંચે છે, એક નવો બ્લોક બહાર પાડવામાં આવે છે. વધુ ઓર્ડર નોડ્સ, આમાં વધુ સમય લાગશે. તેથી, તમારે BatchTimeout અને BatchSize વધારવાની જરૂર છે. પરંતુ RWSets વર્ઝન કરેલ હોવાથી, અમે જેટલો મોટો બ્લોક બનાવીએ છીએ, તેટલી MVCC તકરારની સંભાવના વધારે છે. વધુમાં, જેમ જેમ BatchTimeout વધે છે તેમ UX આપત્તિજનક રીતે અધોગતિ પામે છે. આ સમસ્યાઓના નિરાકરણ માટેની નીચેની યોજના મને વાજબી અને સ્પષ્ટ લાગે છે.

કેવી રીતે બ્લોક ફાઇનલાઇઝેશનની રાહ જોવાનું ટાળવું અને વ્યવહારની સ્થિતિને ટ્રૅક કરવાની ક્ષમતા ગુમાવવી નહીં

નિર્માણનો સમય અને બ્લોક કદ જેટલો લાંબો છે, બ્લોકચેનનું થ્રુપુટ વધારે છે. એક બીજાથી સીધું અનુસરતું નથી, પરંતુ તે યાદ રાખવું જોઈએ કે RAFT માં સર્વસંમતિ સ્થાપિત કરવા માટે નેતા તરફથી અનુયાયીઓ અને પાછળ ત્રણ નેટવર્ક વિનંતીઓ જરૂરી છે. વધુ ઓર્ડર નોડ્સ, આમાં વધુ સમય લાગશે. બ્લોકની રચનાનું કદ અને સમય જેટલો નાનો છે, ત્યાં આવી ક્રિયાપ્રતિક્રિયાઓ વધુ છે. અંતિમ વપરાશકર્તા માટે સિસ્ટમ પ્રતિભાવ સમય વધાર્યા વિના જનરેશન ટાઇમ અને બ્લોકનું કદ કેવી રીતે વધારવું?

સૌપ્રથમ, અમારે મોટા બ્લોક સાઈઝને કારણે થતા MVCC તકરારને કોઈક રીતે ઉકેલવાની જરૂર છે, જેમાં સમાન સંસ્કરણ સાથે વિવિધ RWSets શામેલ હોઈ શકે છે. દેખીતી રીતે, ક્લાયન્ટ બાજુ પર (બ્લોકચેન નેટવર્કના સંબંધમાં, આ બેકએન્ડ હોઈ શકે છે, અને મારો મતલબ છે) તમને જરૂર છે MVCC સંઘર્ષ હેન્ડલર, જે કાં તો એક અલગ સેવા અથવા કૉલની ઉપર નિયમિત ડેકોરેટર હોઈ શકે છે જે ફરીથી પ્રયાસ તર્ક સાથે વ્યવહાર શરૂ કરે છે.

ઘાતાંકીય વ્યૂહરચના સાથે પુનઃપ્રયાસનો અમલ કરી શકાય છે, પરંતુ તે પછી વિલંબતા ઘાતાંકીય રીતે ઘટશે. તેથી તમારે કાં તો અમુક નાની મર્યાદાઓમાં રેન્ડમાઇઝ્ડ પુનઃપ્રયાસનો ઉપયોગ કરવો જોઈએ અથવા સતત એકનો ઉપયોગ કરવો જોઈએ. પ્રથમ વિકલ્પમાં સંભવિત અથડામણ પર નજર રાખીને.

આગળનું પગલું એ સિસ્ટમ સાથે ક્લાયંટની ક્રિયાપ્રતિક્રિયાને અસુમેળ બનાવવાનું છે જેથી તે 15, 30 અથવા 10000000 સેકંડની રાહ ન જુએ, જેને આપણે BatchTimeout તરીકે સેટ કરીશું. પરંતુ તે જ સમયે, તે ચકાસવાની ક્ષમતા જાળવવી જરૂરી છે કે ટ્રાન્ઝેક્શન દ્વારા શરૂ કરાયેલા ફેરફારો બ્લોકચેનમાં નોંધાયેલા છે/નથી.
ટ્રાન્ઝેક્શન સ્ટેટસ સ્ટોર કરવા માટે ડેટાબેઝનો ઉપયોગ કરી શકાય છે. સૌથી સરળ વિકલ્પ CouchDB છે તેના ઉપયોગની સરળતાને કારણે: ડેટાબેઝમાં બોક્સની બહાર એક UI છે, એક REST API છે અને તમે તેના માટે સરળતાથી પ્રતિકૃતિ અને શાર્ડિંગ સેટ કરી શકો છો. તમે તે જ CouchDB ઉદાહરણમાં એક અલગ સંગ્રહ બનાવી શકો છો જે ફેબ્રિકનો ઉપયોગ તેની વિશ્વ સ્થિતિને સંગ્રહિત કરવા માટે કરે છે. અમારે આ પ્રકારના દસ્તાવેજો સંગ્રહિત કરવાની જરૂર છે.

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

ટ્રાન્ઝેક્શન સાથીદારોને મોકલવામાં આવે તે પહેલાં આ દસ્તાવેજ ડેટાબેઝ પર લખવામાં આવે છે, એન્ટિટી ID વપરાશકર્તાને પરત કરવામાં આવે છે (તે જ ID કી તરીકે ઉપયોગમાં લેવાય છે) જો આ બનાવટ કામગીરી હોય, અને પછી સ્થિતિ, TxID અને ભૂલ ક્ષેત્રો છે. સાથીદારો પાસેથી સંબંધિત માહિતી પ્રાપ્ત થાય તે રીતે અપડેટ કરવામાં આવે છે.

આ સ્કીમમાં, વપરાશકર્તા આખરે બ્લોક બનવાની રાહ જોતો નથી, 10 સેકન્ડ માટે સ્ક્રીન પર સ્પિનિંગ વ્હીલ જોઈને, તેને સિસ્ટમ તરફથી ત્વરિત પ્રતિસાદ મળે છે અને તે કામ કરવાનું ચાલુ રાખે છે.

અમે ટ્રાન્ઝેક્શન સ્ટેટસ સ્ટોર કરવા માટે BoltDB પસંદ કર્યું છે કારણ કે અમારે મેમરી બચાવવાની જરૂર છે અને અલગ ડેટાબેઝ સર્વર સાથે નેટવર્ક ક્રિયાપ્રતિક્રિયા પર સમય બગાડવા માંગતા નથી, ખાસ કરીને જ્યારે આ ક્રિયાપ્રતિક્રિયા સાદા ટેક્સ્ટ પ્રોટોકોલનો ઉપયોગ કરીને થાય છે. માર્ગ દ્વારા, ભલે તમે ઉપર વર્ણવેલ યોજનાને અમલમાં મૂકવા માટે CouchDB નો ઉપયોગ કરો છો અથવા ફક્ત વિશ્વની સ્થિતિને સંગ્રહિત કરવા માટે, કોઈપણ સંજોગોમાં CouchDB માં ડેટા કેવી રીતે સંગ્રહિત થાય છે તેને ઑપ્ટિમાઇઝ કરવામાં અર્થપૂર્ણ છે. મૂળભૂત રીતે, CouchDB માં, બી-ટ્રી નોડ્સનું કદ 1279 બાઇટ્સ છે, જે ડિસ્ક પરના સેક્ટરના કદ કરતાં ઘણું નાનું છે, જેનો અર્થ છે કે વૃક્ષને વાંચવા અને ફરીથી સંતુલિત કરવા બંને માટે ડિસ્કની વધુ ભૌતિક ઍક્સેસની જરૂર પડશે. શ્રેષ્ઠ કદ ધોરણને અનુરૂપ છે એડવાન્સ્ડ ફોર્મેટ અને 4 કિલોબાઈટ છે. ઑપ્ટિમાઇઝ કરવા માટે આપણે પરિમાણ સેટ કરવાની જરૂર છે btree_chunk_size બરાબર 4096 CouchDB રૂપરેખાંકન ફાઇલમાં. BoltDB માટે આવા મેન્યુઅલ હસ્તક્ષેપ જરૂરી નથી.

બેકપ્રેશર: બફર વ્યૂહરચના

પરંતુ ઘણા બધા સંદેશા હોઈ શકે છે. સિસ્ટમ હેન્ડલ કરી શકે છે તેના કરતાં વધુ, ડાયાગ્રામમાં દર્શાવેલ સેવાઓ સિવાય એક ડઝન અન્ય સેવાઓ સાથે સંસાધનોની વહેંચણી - અને આ બધું એવા મશીનો પર પણ દોષરહિત રીતે કામ કરવું જોઈએ કે જેના પર Intellij Idea ચલાવવું અત્યંત કંટાળાજનક હશે.

સંચાર પ્રણાલી, ઉત્પાદક અને ઉપભોક્તાની વિવિધ ક્ષમતાની સમસ્યા અલગ અલગ રીતે હલ થાય છે. ચાલો જોઈએ કે આપણે શું કરી શકીએ.

ડ્રોપિંગ: અમે દાવો કરી શકીએ છીએ કે અમે T સેકન્ડમાં મોટાભાગના X વ્યવહારો પર પ્રક્રિયા કરવા સક્ષમ છીએ. આ મર્યાદાને ઓળંગતી તમામ વિનંતીઓ કાઢી નાખવામાં આવે છે. આ એકદમ સરળ છે, પરંતુ પછી તમે UX વિશે ભૂલી શકો છો.

નિયંત્રણ: ઉપભોક્તા પાસે કોઈ પ્રકારનું ઈન્ટરફેસ હોવું જોઈએ જેના દ્વારા, લોડના આધારે, તે નિર્માતાના ટીપીએસને નિયંત્રિત કરી શકે. ખરાબ નથી, પરંતુ તે આ ઇન્ટરફેસને અમલમાં મૂકવા માટે લોડ બનાવતા ક્લાયંટના વિકાસકર્તાઓ પર જવાબદારી લાદે છે. અમારા માટે આ અસ્વીકાર્ય છે, કારણ કે ભવિષ્યમાં બ્લોકચેન મોટી સંખ્યામાં લાંબા સમયથી અસ્તિત્વમાં રહેલી સિસ્ટમમાં એકીકૃત થશે.

બફરિંગ: ઇનપુટ ડેટા સ્ટ્રીમનો પ્રતિકાર કરવાનો પ્રયાસ કરવાને બદલે, અમે આ સ્ટ્રીમને બફર કરી શકીએ છીએ અને તેને જરૂરી ઝડપે પ્રક્રિયા કરી શકીએ છીએ. દેખીતી રીતે આ શ્રેષ્ઠ ઉકેલ છે જો આપણે સારો વપરાશકર્તા અનુભવ પ્રદાન કરવા માંગીએ છીએ. અમે RabbitMQ માં કતારનો ઉપયોગ કરીને બફરનો અમલ કર્યો.

સ્કીમમાં બે નવી ક્રિયાઓ ઉમેરવામાં આવી છે: (1) API ને વિનંતી આવ્યા પછી, ટ્રાન્ઝેક્શનને કૉલ કરવા માટે જરૂરી પરિમાણો સાથેનો સંદેશ કતારમાં મૂકવામાં આવે છે, અને ક્લાયન્ટને સંદેશ પ્રાપ્ત થાય છે કે ટ્રાન્ઝેક્શન સ્વીકારવામાં આવ્યું છે. સિસ્ટમ, (2) બેકએન્ડ કતારમાંથી રૂપરેખામાં ઉલ્લેખિત ઝડપે ડેટા વાંચે છે; ટ્રાન્ઝેક્શન શરૂ કરે છે અને સ્ટેટસ સ્ટોરમાં ડેટા અપડેટ કરે છે.
હવે તમે રચનાના સમયને વધારી શકો છો અને તમે ઇચ્છો તેટલું અવરોધિત કરી શકો છો, વપરાશકર્તાથી વિલંબ છુપાવી શકો છો.

અન્ય સાધનો

ચેઇનકોડ વિશે અહીં કંઈ કહેવામાં આવ્યું ન હતું, કારણ કે, એક નિયમ તરીકે, તેમાં ઑપ્ટિમાઇઝ કરવા માટે કંઈ નથી. ચેઈનકોડ શક્ય તેટલું સરળ અને સુરક્ષિત હોવું જોઈએ - આટલું જ જરૂરી છે. ફ્રેમવર્ક અમને ચેઈનકોડ સરળ અને સુરક્ષિત રીતે લખવામાં મદદ કરે છે CCKit S7 ટેકલેબ અને સ્ટેટિક વિશ્લેષકમાંથી પુનઃજીવિત^CC.

વધુમાં, અમારી ટીમ ફેબ્રિક સાથે કામ સરળ અને આનંદપ્રદ બનાવવા માટે ઉપયોગિતાઓનો સમૂહ વિકસાવી રહી છે: બ્લોકચેન એક્સપ્લોરરમાટે ઉપયોગિતા સ્વચાલિત નેટવર્ક રૂપરેખાંકન ફેરફારો (સંસ્થાઓ ઉમેરવી/દૂર કરવી, RAFT નોડ્સ), માટે ઉપયોગિતા પ્રમાણપત્રો રદ કરવા અને ઓળખ દૂર કરવા. જો તમે યોગદાન આપવા માંગતા હો, તો તમારું સ્વાગત છે.

નિષ્કર્ષ

આ અભિગમ તમને હાયપરલેજર ફેબ્રિકને સરળતાથી Quorum, અન્ય ખાનગી Ethereum નેટવર્ક્સ (PoA અથવા તો PoW) સાથે બદલવાની પરવાનગી આપે છે, વાસ્તવિક થ્રુપુટને નોંધપાત્ર રીતે ઘટાડી શકે છે, પરંતુ તે જ સમયે સામાન્ય UX (બ્રાઉઝરમાં વપરાશકર્તાઓ અને સંકલિત સિસ્ટમો માટે બંને) જાળવી રાખે છે. સ્કીમમાં ફેબ્રિકને Ethereum સાથે બદલતી વખતે, તમારે MVCC કોન્ટ્રાક્ટ્સની પ્રક્રિયાથી લઈને પરમાણુ નોન્સ ઇન્ક્રીમેન્ટ અને રિસેંડિંગ માટે માત્ર ફરી પ્રયાસ સેવા/ડેકોરેટરના તર્કને બદલવાની જરૂર પડશે. બફરિંગ અને સ્ટેટસ સ્ટોરેજને કારણે પ્રતિભાવ સમયને બ્લોક બનાવવાના સમયથી અલગ કરવાનું શક્ય બન્યું. હવે તમે હજારો ઓર્ડર નોડ્સ ઉમેરી શકો છો અને ડરશો નહીં કે બ્લોક્સ ઘણી વાર બને છે અને ઓર્ડરિંગ સેવા લોડ કરે છે.

મૂળભૂત રીતે, આટલું જ હું શેર કરવા માંગતો હતો. જો આ કોઈને તેમના કામમાં મદદ કરશે તો મને આનંદ થશે.

સોર્સ: www.habr.com