હજુ પણ ફિલ્મ "અવર સિક્રેટ યુનિવર્સ: ધ હિડન લાઇફ ઓફ ધ સેલ" માંથી

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

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

વધુમાં, રશિયન અને વિદેશી બંને નિયમનકારોની જરૂરિયાતો વધી રહી છે.

વર્તમાન જરૂરિયાતોને પહોંચી વળવા અને ભાવિ અપગ્રેડનો પાયો નાખવા માટે, અમે ટેરન્ટૂલ પર આધારિત રોકાણ બિઝનેસ કોર વિકસાવ્યું છે.

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

પ્રાગૈતિહાસિક

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

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

નવા ઉકેલ માટે જરૂરીયાતો

વ્યવસાયોને સમજાયું છે કે વધુ વિકાસ માટે તકનીકી પરિવર્તન મહત્વપૂર્ણ છે. અમને કાર્યો આપવામાં આવ્યા હતા:

1. એક જ, ઝડપી સ્ટોરેજમાં અને એક જ ડેટા મોડેલમાં તમામ વ્યવસાયિક ડેટા એકત્રિત કરો.
2. આપણે આ માહિતી ગુમાવવી કે બદલવી ન જોઈએ.
3. ડેટાનું સંસ્કરણ કરવું જરૂરી છે, કારણ કે કોઈપણ ક્ષણે નિયમનકાર પાછલા વર્ષોના આંકડા માંગી શકે છે.
4. આપણે માત્ર કેટલાક નવા, ફેશનેબલ DBMS લાવવું જોઈએ નહીં, પરંતુ વ્યવસાયિક સમસ્યાઓ ઉકેલવા માટે એક પ્લેટફોર્મ બનાવવું જોઈએ.

આ ઉપરાંત, અમારા આર્કિટેક્ટ્સ તેમની પોતાની શરતો સેટ કરે છે:

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

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

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

હું તમને કહીશ નહીં કે અમે દરેક વસ્તુનું પરીક્ષણ કેવી રીતે કર્યું અને તેમાં કેટલો સમય લાગ્યો, હું ફક્ત સારાંશ આપીશ: Mail.ru ગ્રુપ ડેવલપમેન્ટ ટીમના ટેરન્ટૂલ પર આધારિત પ્રોટોટાઇપ સોલ્યુશન દ્વારા લોડ પરીક્ષણોમાં શ્રેષ્ઠ પ્રદર્શન દર્શાવવામાં આવ્યું હતું. અમે એક કરાર પર હસ્તાક્ષર કર્યા અને વિકાસ શરૂ કર્યો. Mail.ru ગ્રુપમાંથી ચાર લોકો હતા, અને Alfa-Bank તરફથી ત્રણ ડેવલપર, ત્રણ સિસ્ટમ એનાલિસ્ટ, એક સોલ્યુશન આર્કિટેક્ટ, એક પ્રોડક્ટ માલિક અને એક સ્ક્રમ માસ્ટર હતા.

આગળ હું તમને જણાવીશ કે અમારી સિસ્ટમ કેવી રીતે વધી, તે કેવી રીતે વિકસિત થઈ, અમે શું કર્યું અને શા માટે આ બરાબર છે.

વિકાસ

અમે અમારી જાતને પહેલો પ્રશ્ન પૂછ્યો હતો કે અમારી વર્તમાન સિસ્ટમોમાંથી ડેટા કેવી રીતે મેળવવો. અમે નક્કી કર્યું કે HTTP અમારા માટે એકદમ યોગ્ય છે, કારણ કે તમામ વર્તમાન સિસ્ટમો HTTP પર XML અથવા JSON મોકલીને એકબીજા સાથે વાતચીત કરે છે.

અમે ટેરેન્ટૂલમાં બનેલા HTTP સર્વરનો ઉપયોગ કરીએ છીએ કારણ કે અમને SSL સત્રોને સમાપ્ત કરવાની જરૂર નથી, અને તેનું પ્રદર્શન અમારા માટે પૂરતું છે.

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

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

વેરિફિકેશન પછી, ડેટા સેવ કરવો આવશ્યક છે. અમે આ vshard નો ઉપયોગ કરીને કરીએ છીએ (અમારી પાસે શાર્ડની જીઓ-વિખેરાયેલી પ્રતિકૃતિઓ છે).

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

હવે તમારે સાચવેલ ડેટાને કેવી રીતે પુનઃપ્રાપ્ત કરવો તે શીખવાની જરૂર છે. અમે અમારી સિસ્ટમ્સનું કાળજીપૂર્વક વિશ્લેષણ કર્યું અને જોયું કે Java અને Oracleના ક્લાસિક સ્ટેકમાં આવશ્યકપણે અમુક પ્રકારનો ORM હોય છે જે ડેટાને રિલેશનલમાંથી ઑબ્જેક્ટમાં રૂપાંતરિત કરે છે. તો શા માટે તરત જ સિસ્ટમોને ગ્રાફના રૂપમાં ઑબ્જેક્ટ્સ આપશો નહીં? તેથી અમે ખુશીથી GraphQL અપનાવ્યું, જે અમારી તમામ જરૂરિયાતો પૂરી કરે છે. તે તમને આલેખના રૂપમાં ડેટા પ્રાપ્ત કરવાની અને તમને હમણાં જે જોઈએ છે તે જ ખેંચવાની મંજૂરી આપે છે. તમે API ને ઘણી બધી સુગમતા સાથે સંસ્કરણ પણ કરી શકો છો.

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

પ્રમાણીકરણ સિસ્ટમ લાગુ કરી.

પછી અમે નોંધ્યું કે અમારા નિર્ણયમાં ઘણી ભૂમિકાઓ સ્ફટિકિત છે. ભૂમિકા એ ફંક્શનનો એક પ્રકાર છે. સામાન્ય રીતે, ભૂમિકાઓમાં વિવિધ સાધનો વપરાશ પ્રોફાઇલ્સ હોય છે:

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

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

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

પરીક્ષણ

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

અમે ટેસ્ટ આધારિત વિકાસનો ઉપયોગ કેવી રીતે કરી શકીએ?

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

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

જો કે, અમને સૌથી વધુ ગમે છે તે લોડ પરીક્ષણ છે; અમે તેને સૌથી મહત્વપૂર્ણ માનીએ છીએ અને તેને નિયમિતપણે કરીએ છીએ.

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

અમે ખૂબ દુઃખી હતા. અમે સર્વર લોડને જોઈએ છીએ, પરંતુ તે બહાર આવ્યું છે કે તેઓ નિષ્ક્રિય છે.

અમે વિકાસકર્તાઓને કૉલ કરીએ છીએ, અને તેઓ અમને સમજાવે છે, જે લોકો જાવાની દુનિયામાંથી આવે છે, કે ટેરન્ટૂલ સિંગલ-થ્રેડેડ છે. તે માત્ર લોડ હેઠળ એક પ્રોસેસર કોર દ્વારા અસરકારક રીતે ઉપયોગ કરી શકાય છે. પછી અમે દરેક સર્વર પર મહત્તમ સંભવિત સંખ્યામાં ટેરેન્ટૂલ દાખલાઓ જમાવ્યા, લોડ ચાલુ કર્યો અને પ્રતિ સેકન્ડ પહેલાથી જ 14,5 હજાર વ્યવહારો પ્રાપ્ત કર્યા.

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

આ કિસ્સામાં, મેમરીનો ઉપયોગ ફક્ત ઇનકમિંગ કનેક્શન્સ અને કામચલાઉ ઑબ્જેક્ટ્સની પ્રક્રિયા માટે કરવામાં આવતો હતો.

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

અને મેમરીનો વપરાશ લોડ થયેલ ડેટાની માત્રાના સીધા પ્રમાણમાં વધ્યો.

સેવાઓ

અમારા નવા ઉત્પાદનને ખાસ કરીને એપ્લિકેશન પ્લેટફોર્મ તરીકે વિકસાવવા માટે, અમે તેના પર સેવાઓ અને પુસ્તકાલયો ગોઠવવા માટે એક ઘટક બનાવ્યો છે.

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

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

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

જૂની સિસ્ટમો

અમારી બધી લેગસી સિસ્ટમ અમને HTTP પર કૉલ કરી શકતી નથી અને GraphQL નો ઉપયોગ કરી શકતી નથી, જો કે તેઓ પ્રોટોકોલને સપોર્ટ કરે છે. તેથી, અમે એક મિકેનિઝમ બનાવ્યું છે જે ડેટાને આ સિસ્ટમ્સમાં નકલ કરવાની મંજૂરી આપે છે.

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

નવા સુધારા

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

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

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

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

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

નિષ્કર્ષ

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

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

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

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

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

જ્યારે આપણે એ હકીકત વિશે વાત કરીએ છીએ કે અમારી પાસે SQL નથી, ત્યારે તે લોકોને ડરાવે છે. “તમે SQL વિના ડેટા કેવી રીતે મેળવશો? શું આ શક્ય છે? ચોક્કસ. OLTP ક્લાસ સિસ્ટમમાં, SQL ની જરૂર નથી. અમુક પ્રકારની ભાષાના રૂપમાં એક વિકલ્પ છે જે તમને તરત જ દસ્તાવેજ-લક્ષી દૃશ્ય પર પરત કરે છે. ઉદાહરણ તરીકે, GraphQL. અને વિતરિત કમ્પ્યુટિંગના સ્વરૂપમાં એક વિકલ્પ છે.

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

સોર્સ: www.habr.com