ટેરન્ટૂલ DBMS માં ઉચ્ચ-સ્તરની પ્રતિકૃતિ

હેલો, હું DBMS માટે એપ્લિકેશન બનાવી રહ્યો છું ટેરન્ટૂલ Mail.ru ગ્રુપ દ્વારા વિકસિત પ્લેટફોર્મ છે જે ઉચ્ચ-પ્રદર્શન DBMS અને લુઆ ભાષામાં એપ્લિકેશન સર્વરને જોડે છે. ખાસ કરીને, DBMS ના ઇન-મેમરી મોડ અને ડેટા સાથે સિંગલ એડ્રેસ સ્પેસમાં એપ્લીકેશન બિઝનેસ લોજિકને એક્ઝિક્યુટ કરવાની ક્ષમતાને કારણે, ટેરન્ટૂલ પર આધારિત ઉકેલોની ઊંચી ઝડપ પ્રાપ્ત થાય છે. તે જ સમયે, ACID વ્યવહારોનો ઉપયોગ કરીને ડેટાની દ્રઢતા સુનિશ્ચિત કરવામાં આવે છે (ડિસ્ક પર WAL લોગ જાળવવામાં આવે છે). ટેરન્ટૂલમાં પ્રતિકૃતિ અને શાર્ડિંગ માટે બિલ્ટ-ઇન સપોર્ટ છે. સંસ્કરણ 2.1 થી શરૂ કરીને, SQL ભાષામાં ક્વેરીઝ સપોર્ટેડ છે. Tarantool ઓપન સોર્સ છે અને સરળ BSD લાયસન્સ હેઠળ લાઇસન્સ પ્રાપ્ત છે. કોમર્શિયલ એન્ટરપ્રાઇઝ વર્ઝન પણ છે.

શક્તિ અનુભવો! (...ઉર્ફ પ્રદર્શનનો આનંદ માણો)

ઉપરોક્ત તમામ ડેટાબેઝ સાથે કામ કરતી હાઇ-લોડ એપ્લિકેશન્સ બનાવવા માટે ટેરન્ટૂલને આકર્ષક પ્લેટફોર્મ બનાવે છે. આવી એપ્લિકેશન્સમાં, ઘણી વખત ડેટાની નકલ કરવાની જરૂર પડે છે.

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

ચોખા. 1. ક્લસ્ટરની અંદર પ્રતિકૃતિ

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

1. ટ્રાફિક બચત:

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

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

ચોખા. 2. HTTP પર પ્રતિકૃતિ

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

ચોખા. 3. વિજાતીય પ્રણાલીઓમાં પ્રતિકૃતિ

નુકસાન એ છે કે, સરેરાશ, પ્રોગ્રામિંગ રૂપરેખાંકન કરતાં વધુ મુશ્કેલ/ખર્ચાળ છે, અને બિલ્ટ-ઇન કાર્યક્ષમતાને કસ્ટમાઇઝ કરવાને બદલે, તમારે તમારી પોતાની અમલીકરણ કરવી પડશે.

જો તમારી પરિસ્થિતિમાં ઉપરોક્ત ફાયદા નિર્ણાયક છે (અથવા આવશ્યક શરત છે), તો ઉચ્ચ-સ્તરની પ્રતિકૃતિનો ઉપયોગ કરવો તે અર્થપૂર્ણ છે. ચાલો ટેરેન્ટૂલ DBMS માં ઉચ્ચ-સ્તરની ડેટા પ્રતિકૃતિને અમલમાં મૂકવાની ઘણી રીતો જોઈએ.

ટ્રાફિક ન્યૂનતમ

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

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

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

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

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

ઉચ્ચ-સ્તરની પ્રતિકૃતિના માળખામાં સ્થાનાંતરિત ડેટાના જથ્થાને ઘટાડવાની છેલ્લી સૂચિત પદ્ધતિ મને સૌથી શ્રેષ્ઠ અને સાર્વત્રિક લાગે છે. ચાલો તેને વધુ વિગતમાં જોઈએ.

પંક્તિ સંસ્કરણ કાઉન્ટરનો ઉપયોગ કરીને ડેટા પસાર કરવો

સર્વર/માસ્ટર ભાગનું અમલીકરણ

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

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

ટેરન્ટૂલમાં કોઈપણ ડેટાબેઝ ઓપરેશન કરતા પહેલા, તમારે નીચેનો આદેશ ચલાવવાની જરૂર છે:

box.cfg{}

પરિણામે, Tarantool વર્તમાન ડિરેક્ટરીમાં ડેટાબેઝ સ્નેપશોટ અને ટ્રાન્ઝેક્શન લોગ લખવાનું શરૂ કરશે.

ચાલો એક ક્રમ બનાવીએ row_version:

box.schema.sequence.create('row_version',
    { if_not_exists = true })

વિકલ્પ if_not_exists સર્જન સ્ક્રિપ્ટને ઘણી વખત ચલાવવાની મંજૂરી આપે છે: જો ઑબ્જેક્ટ અસ્તિત્વમાં છે, તો ટેરેન્ટૂલ તેને ફરીથી બનાવવાનો પ્રયાસ કરશે નહીં. આ વિકલ્પનો ઉપયોગ પછીના તમામ DDL આદેશોમાં થશે.

ચાલો ઉદાહરણ તરીકે જગ્યા બનાવીએ.

box.schema.space.create('goods', {
    format = {
        {
            name = 'id',
            type = 'unsigned'

        },
        {
            name = 'name',
            type = 'string'

        },
        {
            name = 'code',
            type = 'unsigned'

        },
        {
            name = 'row_ver',
            type = 'unsigned'

        }
    },
    if_not_exists = true
})

અહીં આપણે જગ્યાનું નામ સેટ કરીએ છીએ (goods), ક્ષેત્રના નામો અને તેમના પ્રકારો.

ટેરન્ટૂલમાં ઑટો-ઇન્ક્રિમેન્ટિંગ ફીલ્ડ્સ પણ સિક્વન્સનો ઉપયોગ કરીને બનાવવામાં આવે છે. ચાલો ફીલ્ડ દ્વારા સ્વતઃ-વધારતી પ્રાથમિક કી બનાવીએ id:

box.schema.sequence.create('goods_id',
    { if_not_exists = true })
box.space.goods:create_index('primary', {
    parts = { 'id' },
    sequence = 'goods_id',
    unique = true,
    type = 'HASH',
    if_not_exists = true
})

ટેરેન્ટૂલ અનેક પ્રકારના ઈન્ડેક્સને સપોર્ટ કરે છે. સૌથી વધુ ઉપયોગમાં લેવાતા સૂચકાંકો TREE અને HASH પ્રકારો છે, જે નામને અનુરૂપ બંધારણો પર આધારિત છે. TREE સૌથી સર્વતોમુખી ઇન્ડેક્સ પ્રકાર છે. તે તમને સંગઠિત રીતે ડેટા પુનઃપ્રાપ્ત કરવાની મંજૂરી આપે છે. પરંતુ સમાનતા પસંદગી માટે, HASH વધુ યોગ્ય છે. તદનુસાર, પ્રાથમિક કી માટે HASH નો ઉપયોગ કરવાની સલાહ આપવામાં આવે છે (જે અમે કર્યું છે).

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

box.space.goods:before_replace(function(old, new)
    return box.tuple.new({new[1], new[2], new[3],
        box.sequence.row_version:next()})
end)

નીચેનું ટ્રિગર ફીલ્ડ વેલ્યુને બદલે છે row_ver ક્રમના આગલા મૂલ્ય સુધી સંગ્રહિત ટ્યુપલ row_version.

અવકાશમાંથી ડેટા કાઢવામાં સમર્થ થવા માટે goods કૉલમ દ્વારા row_ver, ચાલો એક અનુક્રમણિકા બનાવીએ:

box.space.goods:create_index('row_ver', {
    parts = { 'row_ver' },
    unique = true,
    type = 'TREE',
    if_not_exists = true
})

અનુક્રમણિકા પ્રકાર - વૃક્ષ (TREE), કારણ કે આપણે કોલમમાંના મૂલ્યોના ચડતા ક્રમમાં ડેટા કાઢવાની જરૂર પડશે row_ver.

ચાલો સ્પેસમાં થોડો ડેટા ઉમેરીએ:

box.space.goods:insert{nil, 'pen', 123}
box.space.goods:insert{nil, 'pencil', 321}
box.space.goods:insert{nil, 'brush', 100}
box.space.goods:insert{nil, 'watercolour', 456}
box.space.goods:insert{nil, 'album', 101}
box.space.goods:insert{nil, 'notebook', 800}
box.space.goods:insert{nil, 'rubber', 531}
box.space.goods:insert{nil, 'ruler', 135}

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

ચાલો નિવેશ પરિણામ તપાસીએ:

tarantool> box.space.goods:select()
---
- - [1, 'pen', 123, 1]
  - [2, 'pencil', 321, 2]
  - [3, 'brush', 100, 3]
  - [4, 'watercolour', 456, 4]
  - [5, 'album', 101, 5]
  - [6, 'notebook', 800, 6]
  - [7, 'rubber', 531, 7]
  - [8, 'ruler', 135, 8]
...

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

local page_size = 5
local function get_goods(row_ver)
    local index = box.space.goods.index.row_ver
    local goods = {}
    local counter = 0
    for _, tuple in index:pairs(row_ver, {
        iterator = 'GT' }) do
        local obj = tuple:tomap({ names_only = true })
        table.insert(goods, obj)
        counter = counter + 1
        if counter >= page_size then
            break
        end
    end
    return goods
end

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

ટેરન્ટૂલમાં ડેટા સેમ્પલિંગ ઈન્ડેક્સ દ્વારા કરવામાં આવે છે. કાર્ય get_goods અનુક્રમણિકા દ્વારા ઇટરરેટરનો ઉપયોગ કરે છે row_ver બદલાયેલ ડેટા મેળવવા માટે. ઇટરરેટરનો પ્રકાર જીટી (ગ્રેટર ધેન, તેનાથી વધુ) છે. આનો અર્થ એ છે કે પુનરાવર્તક અનુક્રમે પસાર કરેલ કી (ક્ષેત્ર મૂલ્ય row_ver).

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

local function unflatten_goods(tuple)
    local obj = {}
    obj.id = tuple.id
    obj.goods_name = tuple.name
    obj.comment = 'some comment'
    obj.row_ver = tuple.row_ver
    return obj
end

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

ચાલો ફંક્શન એક્ઝીક્યુટ કરીએ get_goods:

tarantool> get_goods(0)

---
- - row_ver: 1
    code: 123
    name: pen
    id: 1
  - row_ver: 2
    code: 321
    name: pencil
    id: 2
  - row_ver: 3
    code: 100
    name: brush
    id: 3
  - row_ver: 4
    code: 456
    name: watercolour
    id: 4
  - row_ver: 5
    code: 101
    name: album
    id: 5
...

ચાલો ફીલ્ડ વેલ્યુ લઈએ row_ver છેલ્લી લાઇનમાંથી અને ફંક્શનને ફરીથી કૉલ કરો:

tarantool> get_goods(5)

---
- - row_ver: 6
    code: 800
    name: notebook
    id: 6
  - row_ver: 7
    code: 531
    name: rubber
    id: 7
  - row_ver: 8
    code: 135
    name: ruler
    id: 8
...

ફરી એકવાર:

tarantool> get_goods(8)
---
- []
...

જેમ તમે જોઈ શકો છો, જ્યારે આ રીતે ઉપયોગ થાય છે, ત્યારે ફંક્શન બધા સ્પેસ રેકોર્ડ્સ પેજ બાય પેજ પરત કરે છે goods. છેલ્લું પૃષ્ઠ ખાલી પસંદગી દ્વારા અનુસરવામાં આવે છે.

ચાલો જગ્યામાં ફેરફાર કરીએ:

box.space.goods:update(4, {{'=', 6, 'copybook'}})
box.space.goods:insert{nil, 'clip', 234}
box.space.goods:insert{nil, 'folder', 432}

અમે ફીલ્ડ વેલ્યુ બદલી છે name એક એન્ટ્રી માટે અને બે નવી એન્ટ્રીઓ ઉમેરી.

ચાલો છેલ્લા ફંક્શન કોલને પુનરાવર્તિત કરીએ:

tarantool> get_goods(8)
---



- - row_ver: 9
    code: 800
    name: copybook
    id: 6
  - row_ver: 10
    code: 234
    name: clip
    id: 9
  - row_ver: 11
    code: 432
    name: folder
    id: 10
...

ફંક્શને બદલાયેલ અને ઉમેરેલા રેકોર્ડ પરત કર્યા. તેથી કાર્ય get_goods તમને તેના છેલ્લા કૉલથી બદલાયેલ ડેટા પ્રાપ્ત કરવાની મંજૂરી આપે છે, જે વિચારણા હેઠળની પ્રતિકૃતિ પદ્ધતિનો આધાર છે.

અમે આ લેખના અવકાશની બહાર JSON ના રૂપમાં HTTP મારફતે પરિણામો જારી કરીશું. તમે આ વિશે અહીં વાંચી શકો છો: https://habr.com/ru/company/mailru/blog/272141/

ગ્રાહક/ગુલામ ભાગનું અમલીકરણ

ચાલો જોઈએ કે પ્રાપ્તકર્તા બાજુનું અમલીકરણ કેવું દેખાય છે. ચાલો ડાઉનલોડ કરેલ ડેટાને સંગ્રહિત કરવા માટે પ્રાપ્તિ બાજુ પર એક જગ્યા બનાવીએ:

box.schema.space.create('goods', {
    format = {
        {
            name = 'id',
            type = 'unsigned'

        },
        {
            name = 'name',
            type = 'string'

        },
        {
            name = 'code',
            type = 'unsigned'

        }
    },
    if_not_exists = true
})

box.space.goods:create_index('primary', {
    parts = { 'id' },
    sequence = 'goods_id',
    unique = true,
    type = 'HASH',
    if_not_exists = true
})

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

વધુમાં, મૂલ્યોને બચાવવા માટે અમને જગ્યાની જરૂર છે row_ver:

box.schema.space.create('row_ver', {
    format = {
        {
            name = 'space_name',
            type = 'string'

        },
        {
            name = 'value',
            type = 'string'

        }
    },
    if_not_exists = true
})

box.space.row_ver:create_index('primary', {
    parts = { 'space_name' },
    unique = true,
    type = 'HASH',
    if_not_exists = true
})

દરેક લોડ કરેલી જગ્યા માટે (ક્ષેત્ર space_name) આપણે છેલ્લી લોડ કરેલી કિંમત અહીં સાચવીશું row_ver (ક્ષેત્ર value). કૉલમ પ્રાથમિક કી તરીકે કામ કરે છે space_name.

ચાલો સ્પેસ ડેટા લોડ કરવા માટે એક ફંક્શન બનાવીએ goods HTTP દ્વારા. આ કરવા માટે, અમને એક લાઇબ્રેરીની જરૂર છે જે HTTP ક્લાયંટનો અમલ કરે. નીચેની લાઇન લાઇબ્રેરીને લોડ કરે છે અને HTTP ક્લાયંટને ઇન્સ્ટન્ટ કરે છે:

local http_client = require('http.client').new()

અમને json ડિસિરિયલાઇઝેશન માટે લાઇબ્રેરીની પણ જરૂર છે:

local json = require('json')

ડેટા લોડિંગ ફંક્શન બનાવવા માટે આ પૂરતું છે:

local function load_data(url, row_ver)
    local url = ('%s?rowVer=%s'):format(url,
        tostring(row_ver))
    local body = nil
    local data = http_client:request('GET', url, body, {
        keepalive_idle =  1,
        keepalive_interval = 1
    })
    return json.decode(data.body)
end

ફંક્શન url સરનામાં પર HTTP વિનંતી ચલાવે છે અને તેને મોકલે છે row_ver પરિમાણ તરીકે અને વિનંતીનું ડીસીરિયલાઈઝ્ડ પરિણામ પરત કરે છે.

પ્રાપ્ત ડેટા બચાવવા માટેનું કાર્ય આના જેવું દેખાય છે:

local function save_goods(goods)
    local n = #goods
    box.atomic(function()
        for i = 1, n do
            local obj = goods[i]
            box.space.goods:put(
                obj.id, obj.name, obj.code)
        end
    end)
end

અવકાશમાં ડેટા બચાવવાનું ચક્ર goods વ્યવહારમાં મૂકવામાં આવે છે (આ માટે કાર્યનો ઉપયોગ થાય છે box.atomic) ડિસ્ક કામગીરીની સંખ્યા ઘટાડવા માટે.

છેલ્લે, સ્થાનિક જગ્યા સિંક્રનાઇઝેશન કાર્ય goods સ્ત્રોત સાથે તમે તેને આ રીતે અમલમાં મૂકી શકો છો:

local function sync_goods()
    local tuple = box.space.row_ver:get('goods')
    local row_ver = tuple and tuple.value or 0

    —— set your url here:
    local url = 'http://127.0.0.1:81/test/goods/list'

    while true do
        local goods = load_goods(url, row_ver)

        local count = #goods
        if count == 0 then
            return
        end

        save_goods(goods)

        row_ver = goods[count].rowVer
        box.space.row_ver:put({'goods', row_ver})
    end
end

પ્રથમ આપણે અગાઉ સાચવેલ મૂલ્ય વાંચીએ છીએ row_ver જગ્યા માટે goods. જો તે ખૂટે છે (પ્રથમ વિનિમય સત્ર), તો અમે તેને તરીકે લઈએ છીએ row_ver શૂન્ય આગળના ચક્રમાં અમે ઉલ્લેખિત url પર સ્ત્રોતમાંથી બદલાયેલ ડેટાનું પૃષ્ઠ-દર-પેજ ડાઉનલોડ કરીએ છીએ. દરેક પુનરાવર્તન પર, અમે પ્રાપ્ત ડેટાને યોગ્ય સ્થાનિક જગ્યામાં સાચવીએ છીએ અને મૂલ્ય અપડેટ કરીએ છીએ row_ver (અવકાશ મા row_ver અને ચલમાં row_ver) - મૂલ્ય લો row_ver લોડ કરેલા ડેટાની છેલ્લી લાઇનમાંથી.

આકસ્મિક લૂપિંગ સામે રક્ષણ આપવા માટે (પ્રોગ્રામમાં ભૂલના કિસ્સામાં), લૂપ while દ્વારા બદલી શકાય છે for:

for _ = 1, max_req do ...

કાર્ય ચલાવવાના પરિણામે sync_goods જગ્યા goods રીસીવરમાં તમામ સ્પેસ રેકોર્ડ્સના નવીનતમ સંસ્કરણો હશે goods સ્ત્રોતમાં.

દેખીતી રીતે, ડેટા કાઢી નાખવાનું આ રીતે પ્રસારણ કરી શકાતું નથી. જો આવી કોઈ જરૂરિયાત હોય, તો તમે ડિલીશન માર્કનો ઉપયોગ કરી શકો છો. જગ્યામાં ઉમેરો goods બુલિયન ક્ષેત્ર is_deleted અને રેકોર્ડને ભૌતિક રીતે કાઢી નાખવાને બદલે, અમે તાર્કિક કાઢી નાખવાનો ઉપયોગ કરીએ છીએ - અમે ફીલ્ડ મૂલ્ય સેટ કરીએ છીએ is_deleted અર્થમાં true. ક્યારેક બુલિયન ક્ષેત્રને બદલે is_deleted ક્ષેત્રનો ઉપયોગ કરવો વધુ અનુકૂળ છે deleted, જે રેકોર્ડના તાર્કિક કાઢી નાખવાની તારીખ-સમય સંગ્રહિત કરે છે. લોજિકલ ડિલીટ કર્યા પછી, ડિલીટ કરવા માટે ચિહ્નિત થયેલ રેકોર્ડ સ્ત્રોતમાંથી ગંતવ્ય સ્થાન પર ટ્રાન્સફર કરવામાં આવશે (ઉપર ચર્ચા કરેલ તર્ક મુજબ).

ક્રમ row_ver અન્ય જગ્યાઓમાંથી ડેટા ટ્રાન્સમિટ કરવા માટે ઉપયોગ કરી શકાય છે: દરેક ટ્રાન્સમિટેડ સ્પેસ માટે અલગ ક્રમ બનાવવાની જરૂર નથી.

અમે ટેરેન્ટૂલ DBMS નો ઉપયોગ કરીને એપ્લિકેશન્સમાં ઉચ્ચ-સ્તરની ડેટા પ્રતિકૃતિની અસરકારક રીત જોઈ.

તારણો

1. ટેરન્ટૂલ DBMS એ હાઇ-લોડ એપ્લિકેશન બનાવવા માટે આકર્ષક, આશાસ્પદ ઉત્પાદન છે.
2. નિમ્ન-સ્તરની પ્રતિકૃતિ કરતાં ઉચ્ચ-સ્તરની માહિતી પ્રતિકૃતિના ઘણા ફાયદા છે.
3. લેખમાં ચર્ચા કરાયેલ ઉચ્ચ-સ્તરની પ્રતિકૃતિ પદ્ધતિ તમને છેલ્લા વિનિમય સત્રથી બદલાયેલા રેકોર્ડ્સને સ્થાનાંતરિત કરીને સ્થાનાંતરિત ડેટાની માત્રાને ઘટાડવાની મંજૂરી આપે છે.

સોર્સ: www.habr.com