ડેટા ડિકોટોમી: ડેટા અને સેવાઓ વચ્ચેના સંબંધ પર પુનર્વિચાર કરવો

કેમ છો બધા! અમારી પાસે સારા સમાચાર છે, OTUS જૂનમાં ફરીથી કોર્સ શરૂ કરી રહ્યું છે "સોફ્ટવેર આર્કિટેક્ટ", જેના સંબંધમાં અમે પરંપરાગત રીતે તમારી સાથે ઉપયોગી સામગ્રી શેર કરીએ છીએ.

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

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

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

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

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

એન્કેપ્સ્યુલેશન હંમેશા તમારા મિત્ર રહેશે નહીં

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

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

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

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

મોટાભાગની વ્યવસાય સેવાઓ સમાન ડેટા સ્ટ્રીમનો ઉપયોગ કરે છે, તેથી તેમનું કાર્ય હંમેશા એકબીજા સાથે જોડાયેલું છે.

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

ડેટા ડિકોટોમી

સેવા-લક્ષી અભિગમો પહેલેથી અસ્તિત્વમાં હોઈ શકે છે, પરંતુ સેવાઓ વચ્ચે મોટી માત્રામાં ડેટાનું વિનિમય કેવી રીતે કરવું તે અંગે હજુ પણ થોડી માહિતી છે.

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

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

અને અહીં એક મૂંઝવણ ઊભી થાય છે. વિરોધાભાસ. દ્વિભાષા. છેવટે, માહિતી સિસ્ટમો ડેટા પ્રદાન કરવા વિશે છે, અને સેવાઓ છુપાવવા વિશે છે.

આ બે દળો મૂળભૂત છે. તેઓ અમારા મોટા ભાગના કાર્યને અન્ડરપિન કરે છે, અમે જે સિસ્ટમ બનાવીએ છીએ તેમાં સર્વોપરીતા માટે સતત પ્રયત્નશીલ રહે છે.

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

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

ખરાબ, ડેટા વોલ્યુમ્સ સેવાની સીમાઓ સાથે સમસ્યાઓનો ગુણાકાર કરે છે. સેવાની અંદર જેટલો સામાન્ય ડેટા રહેલો છે, તેટલો વધુ જટિલ ઇન્ટરફેસ બનશે અને વિવિધ સેવાઓમાંથી આવતા ડેટા સેટને જોડવાનું વધુ મુશ્કેલ બનશે.

સમગ્ર ડેટાસેટ્સ કાઢવા અને ખસેડવાના વૈકલ્પિક અભિગમની પણ પોતાની સમસ્યાઓ છે. આ પ્રશ્નનો એક સામાન્ય અભિગમ ફક્ત સમગ્ર ડેટાસેટને પુનઃપ્રાપ્ત અને સંગ્રહિત કરવાનો છે, અને પછી તેને દરેક ઉપભોક્તા સેવામાં સ્થાનિક રીતે સંગ્રહિત કરવાનો છે.

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

નકલો જેટલી વધુ પરિવર્તનશીલ હશે, તેટલો વધુ ડેટા સમય સાથે બદલાશે.

તેનાથી પણ ખરાબ, આવા ડેટાને પાછલી તપાસમાં સુધારવું મુશ્કેલ છે (એમડીએમ આ તે છે જ્યાં તે ખરેખર હાથમાં આવે છે.) વાસ્તવમાં, કેટલીક અટપટી તકનીકી પડકારોનો સામનો વ્યવસાયો વિજાતીય ડેટાથી થાય છે જે એપ્લિકેશનથી એપ્લિકેશન સુધી ફેલાય છે.

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

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

ડેટા નિષ્ફળતા ચક્ર

પ્રવાહો: ડેટા અને સેવાઓ માટે વિકેન્દ્રિત અભિગમ

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

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

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

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

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

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

અપરિવર્તનશીલ સ્ટેટ સ્ટ્રીમને વિભાજિત કરીને ડેટા ડિકોટોમીથી છુટકારો મેળવો. પછી સ્ટેટફુલ સ્ટ્રીમ પ્રોસેસિંગનો ઉપયોગ કરીને દરેક સેવામાં આ કાર્યક્ષમતા ઉમેરો.

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

તેની અખંડિતતા સાથે સમાધાન કર્યા વિના ડેટા શેર કરો. ફંક્શનને સમાવિષ્ટ કરો, સ્ત્રોત નહીં, દરેક સેવામાં કે જેને તેની જરૂર છે.

તેથી એવું બને છે કે ડેટાને બલ્કમાં ખસેડવાની જરૂર છે. કેટલીકવાર સેવાને પસંદગીના ડેટાબેઝ એન્જિનમાં સ્થાનિક ઐતિહાસિક ડેટાસેટની જરૂર હોય છે. યુક્તિ એ છે કે તે ખાતરી આપી શકાય છે કે, જો જરૂરી હોય તો, વિતરિત લોગીંગ મિકેનિઝમનો સંપર્ક કરીને સ્રોતમાંથી નકલ પુનઃસ્થાપિત કરી શકાય છે. કાફકામાં કનેક્ટર્સ આનું સારું કામ કરે છે.

તેથી, આજે ચર્ચા કરેલ અભિગમના ઘણા ફાયદા છે:

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

જેમ તમે જોઈ શકો છો, તે આરામ કરતાં વધુ છે. અમને સાધનોનો સમૂહ પ્રાપ્ત થયો છે જે તમને વિકેન્દ્રિત રીતે શેર કરેલા ડેટા સાથે કામ કરવાની મંજૂરી આપે છે.

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

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

કોર્સ વિશે વધુ જાણો.

સોર્સ: www.habr.com