PostgreSQL ક્વેરીઝનું બલ્ક ઑપ્ટિમાઇઝેશન. કિરીલ બોરોવિકોવ (ટેન્સર)

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

કયા તકનીકી ઉકેલો અમને માહિતીના આવા જથ્થાને અસરકારક રીતે પ્રક્રિયા કરવાની મંજૂરી આપે છે, અને આ સામાન્ય વિકાસકર્તાના જીવનને કેવી રીતે સરળ બનાવે છે?

કોને રસ છે? ચોક્કસ સમસ્યાઓ અને વિવિધ ઑપ્ટિમાઇઝેશન તકનીકોનું વિશ્લેષણ SQL પ્રશ્નો અને PostgreSQL માં લાક્ષણિક DBA સમસ્યાઓ ઉકેલવા - તમે પણ કરી શકો છો લેખોની શ્રેણી વાંચો આ વિષય પર.


મારું નામ કિરીલ બોરોવિકોવ છે, હું પ્રતિનિધિત્વ કરું છું ટેન્સર કંપની. ખાસ કરીને, હું અમારી કંપનીમાં ડેટાબેઝ સાથે કામ કરવામાં નિષ્ણાત છું.

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

સામાન્ય રીતે, અમારા એક મિલિયન ક્લાયંટ માટે ટેન્સર છે VLSI એ અમારી એપ્લિકેશન છે: કોર્પોરેટ સોશિયલ નેટવર્ક, વિડિયો કમ્યુનિકેશન માટે ઉકેલો, આંતરિક અને બાહ્ય દસ્તાવેજ પ્રવાહ માટે, એકાઉન્ટિંગ અને વેરહાઉસીસ માટે એકાઉન્ટિંગ સિસ્ટમ્સ,... એટલે કે, એકીકૃત બિઝનેસ મેનેજમેન્ટ માટે આવા "મેગા-કમ્બાઈન", જેમાં 100 થી વધુ વિવિધ છે. આંતરિક પ્રોજેક્ટ્સ.

તે બધા કામ કરે છે અને સામાન્ય રીતે વિકાસ કરે છે તેની ખાતરી કરવા માટે, અમારી પાસે સમગ્ર દેશમાં 10 વિકાસ કેન્દ્રો છે, જેમાં વધુ છે 1000 વિકાસકર્તાઓ.

અમે 2008 થી PostgreSQL સાથે કામ કરી રહ્યા છીએ અને અમે જે પ્રક્રિયા કરીએ છીએ તેનો મોટો જથ્થો એકઠા કર્યો છે - ક્લાયન્ટ ડેટા, આંકડાકીય, વિશ્લેષણાત્મક, બાહ્ય માહિતી સિસ્ટમોમાંથી ડેટા - 400TB થી વધુ. એકલા ઉત્પાદનમાં લગભગ 250 સર્વર્સ છે, અને કુલ મળીને લગભગ 1000 ડેટાબેઝ સર્વર્સ છે જેનું અમે નિરીક્ષણ કરીએ છીએ.

SQL એ ઘોષણાત્મક ભાષા છે. તમે "કેવી રીતે" કંઈક કામ કરવું જોઈએ તેનું વર્ણન નથી, પરંતુ "શું" તમે પ્રાપ્ત કરવા માંગો છો. DBMS વધુ સારી રીતે જાણે છે કે કેવી રીતે જોઇન કરવું - તમારા કોષ્ટકોને કેવી રીતે જોડવા, કઈ શરતો લાદવી, શું અનુક્રમણિકામાંથી પસાર થશે, શું નહીં...

કેટલાક DBMS સંકેતો સ્વીકારે છે: "ના, આ બે કોષ્ટકોને આવી અને આવી કતારમાં જોડો," પરંતુ PostgreSQL આ કરી શકતું નથી. આ અગ્રણી વિકાસકર્તાઓની સભાન સ્થિતિ છે: "અમે વિકાસકર્તાઓને અમુક પ્રકારના સંકેતોનો ઉપયોગ કરવાની મંજૂરી આપવાને બદલે ક્વેરી ઑપ્ટિમાઇઝરને સમાપ્ત કરીશું."

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

સામાન્ય રીતે, વિકાસકર્તા [DBA માટે] સામાન્ય રીતે કઈ ક્લાસિક સમસ્યાઓ સાથે આવે છે? “અહીં અમે વિનંતી પૂરી કરી, અને અમારી સાથે બધું ધીમું છે, બધું અટકી રહ્યું છે, કંઈક થઈ રહ્યું છે... કોઈ પ્રકારની મુશ્કેલી!"

કારણો લગભગ હંમેશા સમાન હોય છે:

• બિનકાર્યક્ષમ ક્વેરી અલ્ગોરિધમ
  વિકાસકર્તા: "હવે હું તેને જોડાઓ દ્વારા એસક્યુએલમાં 10 કોષ્ટકો આપું છું..." - અને અપેક્ષા રાખે છે કે તેની સ્થિતિ ચમત્કારિક રીતે અસરકારક રીતે "ખુલ્લી" થઈ જશે અને તેને ઝડપથી બધું મળી જશે. પરંતુ ચમત્કારો થતા નથી, અને આવી પરિવર્તનશીલતા ધરાવતી કોઈપણ સિસ્ટમ (એકમાંથી 10 કોષ્ટકો) હંમેશા અમુક પ્રકારની ભૂલ આપે છે. [લેખ]
• જૂના આંકડા
  આ બિંદુ ખાસ કરીને PostgreSQL માટે ખૂબ જ સુસંગત છે, જ્યારે તમે સર્વર પર એક મોટો ડેટાસેટ "રેડ્યો", વિનંતી કરો અને તે તમારા ટેબ્લેટને "સેક્સકેનિટ" કરે છે. કારણ કે ગઈકાલે તેમાં 10 રેકોર્ડ હતા, અને આજે 10 મિલિયન છે, પરંતુ PostgreSQL હજુ સુધી આ વિશે જાણતું નથી, અને આપણે તેને તેના વિશે જણાવવાની જરૂર છે. [લેખ]
• સંસાધનો પર "પ્લગ".
  તમે નબળા સર્વર પર એક મોટો અને ભારે લોડ થયેલ ડેટાબેઝ ઇન્સ્ટોલ કર્યો છે કે જેની પાસે પૂરતી ડિસ્ક, મેમરી અથવા પ્રોસેસર કામગીરી નથી. અને તે બધુ જ છે... ક્યાંક પરફોર્મન્સ સીલિંગ છે જેની ઉપર તમે હવે કૂદી નહીં શકો.
• અવરોધિત
  આ એક મુશ્કેલ મુદ્દો છે, પરંતુ તે વિવિધ સંશોધિત પ્રશ્નો (INSERT, UPDATE, DELETE) માટે સૌથી વધુ સુસંગત છે - આ એક અલગ મોટો વિષય છે.

યોજના મેળવી રહી છે

...અને બીજું બધું માટે આપણે યોજનાની જરૂર છે! આપણે એ જોવાની જરૂર છે કે સર્વરની અંદર શું થઈ રહ્યું છે.

PostgreSQL માટે ક્વેરી એક્ઝેક્યુશન પ્લાન એ ટેક્સ્ટ રિપ્રેઝન્ટેશનમાં ક્વેરી એક્ઝેક્યુશન અલ્ગોરિધમનો એક વૃક્ષ છે. તે ચોક્કસ અલ્ગોરિધમ છે જે, આયોજક દ્વારા વિશ્લેષણના પરિણામે, સૌથી અસરકારક હોવાનું જણાયું હતું.

દરેક ટ્રી નોડ એક ઑપરેશન છે: કોષ્ટક અથવા અનુક્રમણિકામાંથી ડેટા પુનઃપ્રાપ્ત કરવો, બીટમેપ બનાવવો, બે કોષ્ટકોને જોડવા, જોડાવું, છેદવું અથવા પસંદગીઓને બાકાત રાખવું. ક્વેરી ચલાવવામાં આ વૃક્ષની ગાંઠોમાંથી પસાર થવું સામેલ છે.

ક્વેરી પ્લાન મેળવવા માટે, સ્ટેટમેન્ટનો અમલ કરવાનો સૌથી સહેલો રસ્તો છે EXPLAIN. તમામ વાસ્તવિક વિશેષતાઓ સાથે મેળવવા માટે, એટલે કે, ખરેખર આધાર પર ક્વેરી ચલાવવા માટે - EXPLAIN (ANALYZE, BUFFERS) SELECT ....

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

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

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

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

બધું સારું લાગે છે - પરંતુ ખરેખર શું થયું તે કંઈ સ્પષ્ટ નથી. સામાન્ય સમય સિવાય, આપણે ખરેખર કંઈપણ જોતા નથી. કારણ કે સાદા લખાણના આવા "લેમ્બ" ને જોવું સામાન્ય રીતે દ્રશ્ય નથી.

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

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

આવી પરિસ્થિતિઓમાં, સમજો "સૌથી નબળી કડી કોણ છે?" લગભગ અશક્ય. તેથી, વિકાસકર્તાઓ પણ પોતાને "મેન્યુઅલ" માં લખે છે "યોજનાને સમજવી એ એક કળા છે જે શીખવી જોઈએ, અનુભવો...".

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

યોજના વિઝ્યુલાઇઝેશન

તેથી, અમને સમજાયું કે આ સમસ્યાઓનો સામનો કરવા માટે, અમને જરૂર છે યોજનાનું સારું વિઝ્યુલાઇઝેશન. [લેખ]

અમે પહેલા "બજાર દ્વારા" ગયા - ચાલો ઇન્ટરનેટ પર જોઈએ કે શું અસ્તિત્વમાં છે.

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

• નોડનો પોતાનો પ્રોસેસિંગ સમય
• સમગ્ર સબટ્રી માટે કુલ સમય
• પુનઃપ્રાપ્ત થયેલા રેકોર્ડ્સની સંખ્યા જે આંકડાકીય રીતે અપેક્ષિત હતી
• નોડ બોડી પોતે

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

પરંતુ નાની સમસ્યાઓ પણ છે.

પ્રથમ, "કોપી-પેસ્ટ" નો વિશાળ જથ્થો. તમે લોગનો ટુકડો લો, તેને ત્યાં વળગી રહો, અને ફરીથી, અને ફરીથી.

બીજું, વાંચેલા ડેટાની માત્રાનું કોઈ વિશ્લેષણ નથી - તે જ બફર જે આઉટપુટ કરે છે EXPLAIN (ANALYZE, BUFFERS), અમે તેને અહીં જોતા નથી. તે ફક્ત તેમને કેવી રીતે ડિસએસેમ્બલ કરવું, તેમને સમજવું અને તેમની સાથે કામ કરવું તે જાણતો નથી. જ્યારે તમે ઘણો ડેટા વાંચી રહ્યાં હોવ અને સમજો કે તમે ડિસ્ક અને મેમરી કેશને ખોટી રીતે ફાળવી રહ્યાં છો, ત્યારે આ માહિતી ખૂબ જ મહત્વપૂર્ણ છે.

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

પરંતુ આ બધા "ગીતો" છે, અમે કોઈક રીતે આ સાથે જીવી શકીએ છીએ, પરંતુ એક એવી વસ્તુ છે જેણે અમને આ સેવાથી મોટા પ્રમાણમાં દૂર કરી દીધા. આ કોમન ટેબલ એક્સપ્રેશન (CTE) અને InitPlan/SubPlan જેવા વિવિધ ડાયનેમિક નોડ્સના વિશ્લેષણમાં ભૂલો છે.

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

પછી અમને સમજાયું કે હવે આપણું પોતાનું લખવાનો સમય છે - હુરે! દરેક ડેવલપર કહે છે: "હવે અમે આપણું પોતાનું લખીશું, તે ખૂબ જ સરળ હશે!"

અમે વેબ સેવાઓ માટે લાક્ષણિક સ્ટેક લીધો: Node.js + Express પર આધારિત કોર, સુંદર આકૃતિઓ માટે બુટસ્ટ્રેપ અને D3.js નો ઉપયોગ કર્યો. અને અમારી અપેક્ષાઓ સંપૂર્ણપણે ન્યાયી હતી - અમને 2 અઠવાડિયામાં પ્રથમ પ્રોટોટાઇપ મળ્યો:

• કસ્ટમ પ્લાન પાર્સર
  એટલે કે, હવે અમે PostgreSQL દ્વારા જનરેટ કરાયેલ કોઈપણ પ્લાનને પાર્સ કરી શકીએ છીએ.
• ડાયનેમિક નોડ્સનું યોગ્ય વિશ્લેષણ - CTE સ્કેન, InitPlan, SubPlan
• બફર વિતરણનું વિશ્લેષણ - જ્યાં ડેટા પૃષ્ઠો મેમરીમાંથી વાંચવામાં આવે છે, ક્યાં સ્થાનિક કેશમાંથી, ક્યાં ડિસ્કમાંથી
• સ્પષ્ટતા મળી
  જેથી લોગમાં આ બધું "ખોદવું" નહીં, પરંતુ ચિત્રમાં તરત જ "નબળી કડી" જોવા માટે.

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

આ સંક્ષિપ્ત રજૂઆત છે જેને આપણે કહીએ છીએ યોજના નમૂનો.

બીજું શું અનુકૂળ હશે? આપણા કુલ સમયનો કેટલો હિસ્સો કયા નોડને ફાળવવામાં આવે છે તે જોવાનું અનુકૂળ રહેશે - અને ફક્ત તેને બાજુ પર "ચીંસો" પાઇ ચાર્ટ.

અમે નોડ પર નિર્દેશ કરીએ છીએ અને જુઓ - તે તારણ આપે છે કે સેક સ્કેન કુલ સમયના એક ક્વાર્ટર કરતા ઓછો સમય લે છે, અને બાકીનો 3/4 CTE સ્કેન દ્વારા લેવામાં આવ્યો હતો. હોરર! જો તમે તમારી ક્વેરીઝમાં તેનો સક્રિય રીતે ઉપયોગ કરો છો તો CTE સ્કેનના "આગના દર" વિશે આ એક નાની નોંધ છે. તેઓ ખૂબ ઝડપી નથી - તેઓ નિયમિત ટેબલ સ્કેનિંગ કરતા પણ હલકી ગુણવત્તાવાળા છે. [લેખ] [લેખ]

પરંતુ સામાન્ય રીતે આવા આકૃતિઓ વધુ રસપ્રદ, વધુ જટિલ હોય છે, જ્યારે આપણે તરત જ કોઈ સેગમેન્ટ તરફ નિર્દેશ કરીએ છીએ અને જોઈએ છીએ, ઉદાહરણ તરીકે, અડધા કરતાં વધુ સમય અમુક Seq Scan “ખાતો” છે. તદુપરાંત, અંદર એક પ્રકારનું ફિલ્ટર હતું, તે મુજબ ઘણા બધા રેકોર્ડ્સ કાઢી નાખવામાં આવ્યા હતા... તમે આ ચિત્ર સીધા વિકાસકર્તાને ફેંકી શકો છો અને કહી શકો છો: “વાસ્યા, અહીં તમારા માટે બધું ખરાબ છે! તેને શોધો, જુઓ - કંઈક ખોટું છે!”

સ્વાભાવિક રીતે, તેમાં કેટલાક "રેક" સામેલ હતા.

અમે જે પ્રથમ વસ્તુ તરફ આવ્યા તે રાઉન્ડિંગ સમસ્યા હતી. યોજનામાં દરેક વ્યક્તિગત નોડનો સમય 1 μs ની ચોકસાઈ સાથે દર્શાવેલ છે. અને જ્યારે નોડ સાયકલની સંખ્યા વધી જાય, ઉદાહરણ તરીકે, 1000 - અમલીકરણ પછી પોસ્ટગ્રેએસક્યુએલ "ચોકસાઈની અંદર" વિભાજિત થાય છે, તો જ્યારે પાછું ગણતરી કરીએ છીએ ત્યારે અમને "ક્યાંક 0.95ms અને 1.05ms વચ્ચે" કુલ સમય મળે છે. જ્યારે ગણતરી માઇક્રોસેકન્ડ્સમાં જાય છે, ત્યારે તે ઠીક છે, પરંતુ જ્યારે તે પહેલેથી જ [મિલી] સેકન્ડ્સ છે, ત્યારે તમારે આ માહિતીને ધ્યાનમાં લેવી પડશે જ્યારે "કોણે કેટલો વપરાશ કર્યો" યોજનાના ગાંઠો પર સંસાધનો "ઉપયોગ" કરો.

બીજો મુદ્દો, વધુ જટિલ, ગતિશીલ ગાંઠો વચ્ચે સંસાધનોનું (તે બફર્સ) વિતરણ છે. આનાથી અમને પ્રોટોટાઇપના પ્રથમ 2 અઠવાડિયા ઉપરાંત બીજા 4 અઠવાડિયાનો ખર્ચ થયો.

આ પ્રકારની સમસ્યા મેળવવી એકદમ સરળ છે - અમે CTE કરીએ છીએ અને તેમાં કંઈક વાંચીએ છીએ. હકીકતમાં, PostgreSQL "સ્માર્ટ" છે અને ત્યાં સીધું કંઈપણ વાંચશે નહીં. પછી અમે તેમાંથી પ્રથમ રેકોર્ડ લઈએ છીએ, અને તે જ CTE માંથી એકસો અને પ્રથમ રેકોર્ડ લઈએ છીએ.

અમે યોજના જોઈએ છીએ અને સમજીએ છીએ - તે વિચિત્ર છે, અમારી પાસે Seq સ્કેનમાં 3 બફર્સ (ડેટા પૃષ્ઠો) "વપરાશ" છે, 1 વધુ CTE સ્કેનમાં, અને બીજા CTE સ્કેનમાં 2 વધુ છે. એટલે કે, જો આપણે દરેક વસ્તુનો સરવાળો કરીએ, તો આપણને 6 મળશે, પરંતુ ટેબ્લેટમાંથી આપણે ફક્ત 3 વાંચીશું! CTE સ્કેન ગમે ત્યાંથી કંઈપણ વાંચતું નથી, પરંતુ પ્રોસેસ મેમરી સાથે સીધું કામ કરે છે. એટલે કે, અહીં કંઈક સ્પષ્ટ રીતે ખોટું છે!

હકીકતમાં, તે તારણ આપે છે કે અહીં તે તમામ 3 પૃષ્ઠ ડેટા છે જે Seq સ્કેનથી વિનંતી કરવામાં આવી હતી, પ્રથમ 1 એ 1 લી CTE સ્કેન માટે પૂછ્યું હતું, અને પછી 2 જી અને 2 વધુ તેને વાંચવામાં આવ્યા હતા. એટલે કે, કુલ 3 પાનાનો ડેટા વાંચવામાં આવ્યો હતો, 6 નહીં.

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

અમે થોડીવાર માટે શ્વાસ છોડ્યો. તેઓએ કહ્યું: “હવે, નીઓ, તમે કૂંગ ફુ જાણો છો! હવે અમારો અનુભવ તમારી સ્ક્રીન પર જ છે. હવે તમે તેનો ઉપયોગ કરી શકો છો." [લેખ]

લોગ એકીકરણ

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

સામાન્ય રીતે, ત્યાં એક પ્રમાણભૂત મોડ્યુલ છે જે આંકડા એકત્રિત કરી શકે છે, જો કે, તેને રૂપરેખામાં સક્રિય કરવાની પણ જરૂર છે - આ મોડ્યુલ pg_stat_statements. પરંતુ તે અમને અનુકૂળ ન હતો.

સૌપ્રથમ, તે સમાન ડેટાબેઝમાં વિવિધ યોજનાઓનો ઉપયોગ કરીને સમાન પ્રશ્નોને સોંપે છે વિવિધ QueryIds. એટલે કે, જો તમે પહેલા કરો SET search_path = '01'; SELECT * FROM user LIMIT 1;અને પછી SET search_path = '02'; અને તે જ વિનંતી, તો પછી આ મોડ્યુલના આંકડાઓ અલગ અલગ રેકોર્ડ ધરાવશે, અને હું યોજનાઓને ધ્યાનમાં લીધા વિના, ખાસ કરીને આ વિનંતી પ્રોફાઇલના સંદર્ભમાં સામાન્ય આંકડા એકત્રિત કરી શકીશ નહીં.

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

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

તેથી, અમે કોપી-પેસ્ટ સામે લડવાનું નક્કી કર્યું અને લખવાનું શરૂ કર્યું કલેક્ટર.

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

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

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

"ત્યાં માત્ર એક જ વસ્તુ છે જેને તમે ધ્યાનમાં ન લીધી, હાથી જેવી મધમાખીઓની એક પ્રજાતિ છે!.." અમે 10 સર્વરનું નિરીક્ષણ કરવા માંગતા હતા ત્યારે અમે આ સિસ્ટમ વિકસાવવાનું શરૂ કર્યું. અમારી સમજણમાં સૌથી જટિલ, જ્યાં કેટલીક સમસ્યાઓ ઊભી થઈ જેનો સામનો કરવો મુશ્કેલ હતો. પરંતુ પ્રથમ ક્વાર્ટર દરમિયાન, અમને મોનિટરિંગ માટે સો પ્રાપ્ત થયા - કારણ કે સિસ્ટમ કામ કરતી હતી, દરેકને તે જોઈતું હતું, દરેક આરામદાયક હતું.

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

પરંતુ ફક્ત "રેડવું" ડેટા ખરેખર અમારી તકનીક નથી. કારણ કે જો તમારી પાસે સો સર્વર પર સેકન્ડ દીઠ અંદાજે 50k વિનંતીઓ છે, તો આ દરરોજ 100-150GB લોગ જનરેટ કરશે. તેથી, અમારે કાળજીપૂર્વક આધાર "કટ" કરવો પડ્યો.

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

બીજું, અમે શીખ્યા (બળજબરીથી) ઉપયોગ કરીને લખવામાં ખૂબ જ ઝડપી COPY. એટલે કે, માત્ર નહીં COPYકારણ કે તે તેના કરતા ઝડપી છે INSERT, અને વધુ ઝડપી.

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

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

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

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

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

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

ટેક્સ્ટ - વિનંતી, યોજના, ટેમ્પ્લેટ,...માંથી MD5 નો ઉપયોગ કરવો તે અમારા માટે યોગ્ય હતું... અમે તેને કલેક્ટર બાજુએ ગણીએ છીએ, અને તૈયાર ID ને ડેટાબેઝમાં "ઠાલવીએ છીએ". MD5 ની લંબાઈ અને દૈનિક પાર્ટીશન અમને સંભવિત અથડામણ વિશે ચિંતા ન કરવાની મંજૂરી આપે છે.

પરંતુ આ બધું ઝડપથી રેકોર્ડ કરવા માટે, અમારે રેકોર્ડિંગ પ્રક્રિયામાં જ ફેરફાર કરવાની જરૂર હતી.

તમે સામાન્ય રીતે ડેટા કેવી રીતે લખો છો? અમારી પાસે અમુક પ્રકારનો ડેટાસેટ છે, અમે તેને અનેક કોષ્ટકોમાં વિભાજિત કરીએ છીએ, અને પછી તેને કૉપિ કરીએ છીએ - પહેલા પ્રથમમાં, પછી બીજામાં, ત્રીજામાં... તે અસુવિધાજનક છે, કારણ કે અમે ત્રણ પગલામાં એક ડેટા સ્ટ્રીમ લખી રહ્યા હોય તેવું લાગે છે. અનુક્રમે. અપ્રિય. શું તે ઝડપથી કરી શકાય છે? કરી શકો છો!

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

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

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

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

ડેટા રેકોર્ડિંગ માટે આ અભિગમનો પરિચય આપતા પહેલા, અમારી પાસે લગભગ 4K રાઇટ ઑપ્સ હતા, અને આ રીતે અમે લોડને 4 ગણો ઘટાડી દીધો. હવે તેઓ નવા મોનિટર કરેલા ડેટાબેસેસને કારણે 6 ગણા વધ્યા છે - 100MB/s સુધી. અને હવે અમે લગભગ 3-10TB ના જથ્થામાં છેલ્લા 15 મહિનાના લૉગ્સ સ્ટોર કરીએ છીએ, આશા રાખીએ છીએ કે માત્ર ત્રણ મહિનામાં કોઈપણ વિકાસકર્તા કોઈપણ સમસ્યાને ઉકેલવામાં સક્ષમ હશે.

અમે સમસ્યાઓ સમજીએ છીએ

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

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

અમે ત્રણ મુખ્ય મુદ્દાઓ ઓળખ્યા છે:

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

"કોણે" અમને વિનંતી મોકલી છે તે સમજવા માટે, અમે એક માનક સાધનનો ઉપયોગ કરીએ છીએ - સત્ર ચલ સેટ કરો: SET application_name = '{bl-host}:{bl-method}'; — અમે બિઝનેસ લોજિક હોસ્ટનું નામ મોકલીએ છીએ જેમાંથી વિનંતી આવે છે, અને તે પદ્ધતિ અથવા એપ્લિકેશનનું નામ જેણે તેને શરૂ કર્યું છે.

અમે વિનંતીના "માલિક"ને પસાર કર્યા પછી, તે લોગમાં આઉટપુટ હોવું આવશ્યક છે - આ માટે અમે વેરીએબલને ગોઠવીએ છીએ log_line_prefix = ' %m [%p:%v] [%d] %r %a'. રસ ધરાવતા લોકો માટે, કદાચ માર્ગદર્શિકામાં જુઓતે બધાનો અર્થ શું છે. તે તારણ આપે છે કે આપણે લોગમાં જોઈએ છીએ:

• время
• પ્રક્રિયા અને વ્યવહાર ઓળખકર્તાઓ
• ડેટાબેઝ નામ
• આ વિનંતી મોકલનાર વ્યક્તિનો IP
• અને પદ્ધતિનું નામ

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

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

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

જ્યારે અમે ચોક્કસ દાખલાઓમાંથી નમૂનાઓ પર ગયા, ત્યારે અમને એક સાથે બે ફાયદા મળ્યા:

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

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

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

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

અને તરત જ તમે વિવિધ એપ્લિકેશનો જોઈ શકો છો જે એક જ ટેમ્પલેટ સાથે આવે છે જેવી વિનંતીથી SELECT * FROM users WHERE login = 'Vasya'. ફ્રન્ટએન્ડ, બેકએન્ડ, પ્રોસેસિંગ... અને તમે આશ્ચર્ય પામો છો કે પ્રોસેસિંગ શા માટે વપરાશકર્તાને વાંચશે જો તે તેની સાથે સંપર્ક ન કરે.

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

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

તમારી પાસે પ્લેટ પર યોગ્ય અનુક્રમણિકા નથી, તમે તેને વિનંતી કરો છો, તે અનુક્રમણિકામાંથી પસાર થાય છે, સેક સ્કેનમાં આવે છે... તમે એક સિવાયના તમામ રેકોર્ડ ફિલ્ટર કરી દીધા છે. તમારે દરરોજ 100M ફિલ્ટર કરેલા રેકોર્ડ્સની શા માટે જરૂર છે? શું ઇન્ડેક્સ રોલ અપ કરવું વધુ સારું નથી?

નોડ દ્વારા તમામ યોજનાઓનું વિશ્લેષણ કર્યા પછી, અમને સમજાયું કે યોજનાઓમાં કેટલીક લાક્ષણિક રચનાઓ છે જે શંકાસ્પદ લાગે તેવી શક્યતા છે. અને વિકાસકર્તાને કહેવું સરસ રહેશે: "મિત્ર, અહીં તમે પહેલા અનુક્રમણિકા દ્વારા વાંચો, પછી સૉર્ટ કરો અને પછી કાપી નાખો" - એક નિયમ તરીકે, એક રેકોર્ડ છે.

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

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

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

સોર્સ: www.habr.com