VKontakte સંદેશ ડેટાબેઝને શરૂઆતથી ફરીથી લખો અને ટકી રહો

અમારા વપરાશકર્તાઓ થાકને જાણ્યા વિના એકબીજાને સંદેશા લખે છે.

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

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

અમારા માટે, આ ક્ષણ દોઢ વર્ષ પહેલા આવી હતી. અમે આમાં કેવી રીતે આવ્યા અને અંતે શું થયું - અમે તમને ક્રમમાં કહીએ છીએ.

પૃષ્ઠભૂમિ

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

2009 ના અંતમાં, પ્રથમ ટેક્સ્ટ-એન્જિન રીપોઝીટરી લખવામાં આવી હતી, અને 2010 માં સંદેશાઓ તેના પર સ્થાનાંતરિત કરવામાં આવ્યા હતા.

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

આ બે વપરાશકર્તાઓ વચ્ચેના પત્રવ્યવહાર માટે પૂરતું હતું. અનુમાન કરો કે આગળ શું થયું?

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

"PHP, ચાલો ચેટ પર સંદેશ મોકલીએ," વપરાશકર્તા કહે છે.
"ચાલો, {username}," PHP કહે છે.

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

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

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

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

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

નવો ખ્યાલ

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

જરૂરી ન્યૂનતમ બે નવા ડેટાબેસેસ છે:

• ચેટ એન્જિન. આ ચેટ વેક્ટરનો ભંડાર છે. દરેક ચેટમાં સંદેશાઓનું વેક્ટર હોય છે જે તેને સંબંધિત હોય છે. દરેક સંદેશમાં એક ટેક્સ્ટ અને ચેટની અંદર એક અનન્ય સંદેશ ઓળખકર્તા હોય છે - chat_local_id.
• વપરાશકર્તા-એન્જિન. આ વપરાશકર્તાઓ વેક્ટરનો સંગ્રહ છે - વપરાશકર્તાઓની લિંક્સ. દરેક યુઝર પાસે peer_id (ઇન્ટરલોક્યુટર્સ - અન્ય યુઝર્સ, મલ્ટિ-ચેટ અથવા સમુદાયો) અને સંદેશાઓનું વેક્ટર હોય છે. દરેક પીઅર_આઈડીમાં સંદેશાઓનું વેક્ટર હોય છે જે તેનાથી સંબંધિત હોય છે. દરેક સંદેશમાં એક chat_local_id અને તે વપરાશકર્તા માટે એક અનન્ય સંદેશ ID હોય છે - user_local_id.

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

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

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

નવી યોજનામાં સંદેશ મોકલવો આના જેવો દેખાય છે:

1. PHP બેકએન્ડ સંદેશ મોકલવાની વિનંતી સાથે વપરાશકર્તા-એન્જિનનો સંપર્ક કરે છે.
2. વપરાશકર્તા-એન્જિન ઇચ્છિત ચેટ-એન્જિન દાખલાની વિનંતીને પ્રોક્સી કરે છે, જે વપરાશકર્તા-એન્જિન ચેટ_લોકલ_આઈડી પર પરત આવે છે - આ ચેટમાં એક નવા સંદેશનું અનન્ય ઓળખકર્તા. ચેટ_એન્જિન પછી ચેટમાંના તમામ પ્રાપ્તકર્તાઓને સંદેશનું પ્રસારણ કરે છે.
3. વપરાશકર્તા-એન્જિન ચેટ-એન્જિનમાંથી chat_local_id મેળવે છે અને PHP પર user_local_id પરત કરે છે - આ વપરાશકર્તા માટે એક અનન્ય સંદેશ ઓળખકર્તા. પછી આ ઓળખકર્તાનો ઉપયોગ થાય છે, ઉદાહરણ તરીકે, API મારફતે સંદેશાઓ સાથે કામ કરવા માટે.

પરંતુ વાસ્તવમાં સંદેશા મોકલવા ઉપરાંત, તમારે કેટલીક વધુ મહત્વપૂર્ણ બાબતોનો અમલ કરવાની જરૂર છે:

• સબલિસ્ટ્સ, ઉદાહરણ તરીકે, સૌથી તાજેતરના સંદેશાઓ છે જે તમે વાતચીતની સૂચિ ખોલતી વખતે જુઓ છો. ન વાંચેલા સંદેશાઓ, ટૅગ્સ સાથેના સંદેશા (“મહત્વપૂર્ણ”, “સ્પામ”, વગેરે).
• ચેટ-એન્જિનમાં સંદેશાઓને સંકુચિત કરવું
• વપરાશકર્તા-એન્જિનમાં સંદેશાઓ કેશીંગ
• શોધો (બધા સંવાદો દ્વારા અને ચોક્કસ એકની અંદર).
• રીઅલ-ટાઇમ અપડેટ (લોંગપોલિંગ).
• મોબાઇલ ક્લાયંટ પર કેશીંગને અમલમાં મૂકવા માટે ઇતિહાસ સાચવી રહ્યું છે.

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

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

ચેટ કરતાં ઘણા ઓછા વપરાશકર્તાઓ હોવાથી, ચેટ-એન્જિનમાં રેન્ડમ-ઍક્સેસ ડિસ્ક વિનંતીઓને સાચવવા માટે, અમે વપરાશકર્તા-એન્જિનમાં સંદેશાઓને કૅશ કરીએ છીએ.

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

ઠીક છે, બધી વિગતો ધ્યાનમાં લેવામાં આવી છે, જે બાકી છે તે એક નવી સ્કીમ પર સ્વિચ કરવાનું છે - અને પ્રાધાન્ય વપરાશકર્તાઓ તેને ધ્યાનમાં લીધા વિના.

ડેટા સ્થળાંતર

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

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

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

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

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

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

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

અમે આયાતી સંદેશાઓને સંગ્રહિત કરવા માટે વિશિષ્ટ ડેટા સ્ટ્રક્ચરનો ઉપયોગ કરીએ છીએ.

તે કદના વેક્ટરનું પ્રતિનિધિત્વ કરે છે દરેક ક્યાં છે - તત્વોના વિશેષ ક્રમ સાથે અલગ અને ઉતરતા ક્રમમાં ક્રમાંકિત છે. સૂચકાંકો સાથે દરેક સેગમેન્ટમાં તત્વો ક્રમાંકિત છે. આવી રચનામાં તત્વ શોધવામાં સમય લાગે છે દ્વારા દ્વિસંગી શોધ. એક તત્વ ઉમેરા પર ઋણમુક્તિ થાય છે .

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

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

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

રિઝલ્ટ

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

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

વધુમાં, સર્વરની સંખ્યા બમણી કરવાને બદલે, અમે તેમની સંખ્યા અડધાથી ઘટાડી દીધી છે - હવે વપરાશકર્તા-એન્જિન અને ચેટ-એન્જિન 500 ભૌતિક મશીનો પર લાઇવ છે, જ્યારે નવી યોજનામાં લોડ માટે મોટો હેડરૂમ છે. અમે સાધનો પર ઘણા પૈસા બચાવ્યા - લગભગ $5 મિલિયન + $750 હજાર પ્રતિ વર્ષ ઓપરેટિંગ ખર્ચમાં.

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

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

સોર્સ: www.habr.com