અમે સબલાઇટ પર PostgreSQL માં લખીએ છીએ: 1 હોસ્ટ, 1 દિવસ, 1TB

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

#1. વિભાગીકરણ

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

"ગયા દિવસોની વાતો..."

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

સમય લગભગ મહાકાવ્ય સમય જેવો હતો, PostgreSQL 9.x ની વિવિધ આવૃત્તિઓ સુસંગત હતી, તેથી તમામ પાર્ટીશન "મેન્યુઅલી" - દ્વારા કોષ્ટક વારસો અને ટ્રિગર્સ ગતિશીલ સાથે રૂટીંગ EXECUTE.

પરિણામી ઉકેલ એટલો સાર્વત્રિક હોવાનું બહાર આવ્યું છે કે તે તમામ કોષ્ટકોમાં અનુવાદિત થઈ શકે છે:

• એક ખાલી "હેડર" પેરેંટ ટેબલ જાહેર કરવામાં આવ્યું હતું, જે તમામનું વર્ણન કરે છે જરૂરી સૂચકાંકો અને ટ્રિગર્સ.
• ક્લાયંટના દૃષ્ટિકોણથી રેકોર્ડ "રુટ" કોષ્ટકમાં બનાવવામાં આવ્યો હતો, અને આંતરિક રીતે ઉપયોગ કરીને રૂટીંગ ટ્રિગર BEFORE INSERT રેકોર્ડ જરૂરી વિભાગમાં "શારીરિક રીતે" દાખલ કરવામાં આવ્યો હતો. જો હજી સુધી આવી કોઈ વસ્તુ ન હતી, તો અમે એક અપવાદ પકડ્યો અને...
• … ઉપયોગ કરીને CREATE TABLE ... (LIKE ... INCLUDING ...) પિતૃ કોષ્ટકના નમૂનાના આધારે બનાવવામાં આવ્યું હતું ઇચ્છિત તારીખ પર પ્રતિબંધ સાથેનો વિભાગજેથી જ્યારે ડેટા પુનઃપ્રાપ્ત કરવામાં આવે છે, ત્યારે વાંચન ફક્ત તેમાં જ કરવામાં આવે છે.

PG10: પ્રથમ પ્રયાસ

પરંતુ વારસા દ્વારા પાર્ટીશન ઐતિહાસિક રીતે સક્રિય લેખન પ્રવાહ અથવા મોટી સંખ્યામાં ચાઇલ્ડ પાર્ટીશનો સાથે વ્યવહાર કરવા માટે યોગ્ય નથી. ઉદાહરણ તરીકે, તમે યાદ કરી શકો છો કે જરૂરી વિભાગ પસંદ કરવા માટે અલ્ગોરિધમનો હતો ચતુર્ભુજ જટિલતા, કે તે 100+ વિભાગો સાથે કામ કરે છે, તમે પોતે સમજો છો કે કેવી રીતે...

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

મેન્યુઅલ દ્વારા ખોદકામ કર્યા પછી તે બહાર આવ્યું તેમ, આ સંસ્કરણમાં મૂળ રીતે વિભાજિત કોષ્ટક છે:

• અનુક્રમણિકા વર્ણનોને સમર્થન આપતું નથી
• તેના પર ટ્રિગર્સને સપોર્ટ કરતું નથી
• કોઈના "વંશજ" ન હોઈ શકે
• આધાર આપશો નહીં INSERT ... ON CONFLICT
• આપમેળે વિભાગ જનરેટ કરી શકતા નથી

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

PG10: બીજી તક

તેથી, અમે એક પછી એક ઊભી થતી સમસ્યાઓને હલ કરવાનું શરૂ કર્યું:

1. કારણ કે ટ્રિગર્સ અને ON CONFLICT અમને જાણવા મળ્યું કે અમને હજી પણ તેમની અહીં અને ત્યાં જરૂર છે, તેથી અમે તેમને કામ કરવા માટે મધ્યવર્તી તબક્કો બનાવ્યો પ્રોક્સી ટેબલ.
2. "રાઉટીંગ" થી છુટકારો મેળવ્યો ટ્રિગર્સમાં - એટલે કે, થી EXECUTE.
3. તેઓએ તેને અલગથી બહાર કાઢ્યું તમામ અનુક્રમણિકાઓ સાથે ટેમ્પલેટ ટેબલજેથી તેઓ પ્રોક્સી ટેબલમાં પણ હાજર ન હોય.

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

"સોઇંગ" શબ્દકોશો

કોઈપણ વિશ્લેષણાત્મક સિસ્ટમની જેમ, અમારી પાસે પણ હતું "તથ્યો" અને "કટ" (શબ્દકોષો). અમારા કિસ્સામાં, આ ક્ષમતામાં તેઓએ કાર્ય કર્યું, ઉદાહરણ તરીકે, ટેમ્પલેટ બોડી સમાન ધીમી ક્વેરીઝ અથવા ક્વેરીનો જ ટેક્સ્ટ.

"તથ્યો" પહેલાથી જ લાંબા સમયથી દિવસ દ્વારા વિભાગ કરવામાં આવ્યા હતા, તેથી અમે શાંતિથી જૂના વિભાગોને કાઢી નાખ્યા, અને તે અમને પરેશાન કરતા ન હતા (લોગ!). પરંતુ શબ્દકોશોમાં સમસ્યા હતી...

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

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

• ઝડપથી લખો/વાંચો નાના વિભાગના કદને કારણે
• ઓછી મેમરી લે છે વધુ કોમ્પેક્ટ ઇન્ડેક્સ સાથે કામ કરીને
• ઓછો ડેટા સ્ટોર કરો જૂનાને ઝડપથી દૂર કરવાની ક્ષમતાને કારણે

પગલાંના સમગ્ર સંકુલના પરિણામે CPU લોડ ~30%, ડિસ્ક લોડ ~50% ઘટ્યો:

તે જ સમયે, અમે ડેટાબેઝમાં બરાબર એ જ વસ્તુ લખવાનું ચાલુ રાખ્યું, માત્ર ઓછા લોડ સાથે.

#2. ડેટાબેઝ ઉત્ક્રાંતિ અને રિફેક્ટરિંગ

તેથી અમે અમારી પાસે જે છે તેના પર સમાધાન કર્યું દરેક દિવસનો પોતાનો વિભાગ હોય છે ડેટા સાથે. ખરેખર, CHECK (dt = '2018-10-12'::date) — અને ત્યાં એક પાર્ટીશનીંગ કી અને ચોક્કસ વિભાગમાં રેકોર્ડ આવવા માટેની શરત છે.

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

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

ઑપ્ટિમાઇઝેશનની દિશા સ્પષ્ટ છે - સરળ તમામ અનુક્રમણિકાઓમાંથી તારીખ ફીલ્ડ દૂર કરો વિભાજિત કોષ્ટકો પર. અમારા વોલ્યુમો જોતાં, લાભ લગભગ છે 1TB/અઠવાડિયું!

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

#3. પીક લોડ "ફેલાવવું".

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

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

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

setInterval(sendToDB, interval)

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

સદનસીબે, આને ઠીક કરવું એકદમ સરળ છે, "રેન્ડમ" રન-અપ ઉમેરી રહ્યા છીએ સમય દ્વારા:

setInterval(sendToDB, interval * (1 + 0.1 * (Math.random() - 0.5)))

#4. આપણે જે જોઈએ તે કેશ કરીએ છીએ

ત્રીજી પરંપરાગત હાઇલોડ સમસ્યા છે કોઈ કેશ નથી તે ક્યાં છે શકવું હોવું.

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

ના, અલબત્ત, ડેટાબેઝ પર ફરીથી કંઈપણ લખવામાં આવતું નથી, આ ટ્રિગરને કાપી નાખે છે INSERT ... ON CONFLICT DO NOTHING. પરંતુ આ ડેટા હજુ પણ ડેટાબેઝ સુધી પહોંચે છે અને તે બિનજરૂરી છે સંઘર્ષની તપાસ કરવા માટે વાંચન કરવું પડશે. અરે #3...

કેશીંગ સક્ષમ કર્યા પહેલા/પછી ડેટાબેઝમાં મોકલવામાં આવેલ રેકોર્ડની સંખ્યામાં તફાવત સ્પષ્ટ છે:

અને સ્ટોરેજ લોડમાં આ સાથેનો ઘટાડો છે:

કુલ

"ટેરાબાઇટ-પ્રતિ-દિવસ" માત્ર ડરામણી લાગે છે. જો તમે બધું બરાબર કરો છો, તો આ ન્યાયી છે 2^40 બાઇટ્સ / 86400 સેકન્ડ = ~12.5MB/sકે જે ડેસ્કટોપ IDE સ્ક્રૂ પણ ધરાવે છે. 🙂

પરંતુ ગંભીરતાપૂર્વક, દિવસ દરમિયાન લોડના દસ ગણા "સ્ક્યુ" સાથે પણ, તમે આધુનિક SSD ની ક્ષમતાઓને સરળતાથી પૂરી કરી શકો છો.

સોર્સ: www.habr.com