ઉચ્ચ પ્રદર્શન અને મૂળ પાર્ટીશન: TimescaleDB સપોર્ટ સાથે Zabbix

Zabbix એક મોનિટરિંગ સિસ્ટમ છે. અન્ય કોઈપણ સિસ્ટમની જેમ, તે તમામ મોનિટરિંગ સિસ્ટમ્સની ત્રણ મુખ્ય સમસ્યાઓનો સામનો કરે છે: ડેટા એકત્રિત કરવો અને તેની પ્રક્રિયા કરવી, ઇતિહાસ સંગ્રહિત કરવો અને તેને સાફ કરવું.

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

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

TimescaleDB કેવી રીતે કાર્ય કરે છે, તે નિયમિત PostgreSQL ની તુલનામાં શું પ્રદર્શન આપી શકે છે? TimescaleDB માં Zabbix શું ભૂમિકા ભજવે છે? શરૂઆતથી કેવી રીતે શરૂ કરવું અને PostgreSQL માંથી કેવી રીતે સ્થળાંતર કરવું અને કયું રૂપરેખાંકન પ્રદર્શન વધુ સારું છે? કટ હેઠળ આ બધું.

પ્રદર્શન પડકારો

દરેક મોનિટરિંગ સિસ્ટમ ચોક્કસ પ્રદર્શન પડકારોનો સામનો કરે છે. હું તેમાંથી ત્રણ વિશે વાત કરીશ: ડેટા સંગ્રહ અને પ્રક્રિયા, સંગ્રહ, ઇતિહાસ સફાઈ.

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

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

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

વાસી ડેટાને સાફ કરવો એ એક કાંટાળો મુદ્દો છે જે ડેટાબેઝની કામગીરી પર મોટી અસર કરે છે.

Zabbix માં કેશીંગ

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

Zabbix સર્વરની બાજુ પર કેશીંગ પોતે છે:

• રૂપરેખાંકનકેશ;
• ValueCache;
• HistoryCache;
• TrendsCache.

ચાલો તેમને વધુ વિગતવાર ધ્યાનમાં લઈએ.

ConfigurationCache

આ મુખ્ય કેશ છે જેમાં અમે મેટ્રિક્સ, હોસ્ટ્સ, ડેટા આઇટમ્સ, ટ્રિગર્સ - પ્રી-પ્રોસેસિંગ અને ડેટા સંગ્રહ માટે જરૂરી છે તે બધું સંગ્રહિત કરીએ છીએ.

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

માહિતી સંગ્રહ

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

પીકર નારંગી રંગમાં ચક્કર લગાવે છે.

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

પ્રી-પ્રોસેસિંગ HistoryCache

બધા કલેક્ટર્સ નોકરી મેળવવા માટે કન્ફિગરેશનકેશનો ઉપયોગ કરે છે. પછી તેઓ તેમને પ્રી-પ્રોસેસિંગ પર મોકલે છે.

પ્રી-પ્રોસેસિંગ પ્રીપ્રોસેસિંગ સ્ટેપ્સ મેળવવા માટે કન્ફિગરેશનકૅશનો ઉપયોગ કરે છે. તે આ ડેટાને વિવિધ રીતે પ્રોસેસ કરે છે.

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

નોંધ: પ્રીપ્રોસેસિંગ એ એકદમ ભારે કામગીરી છે. v 4.2 થી તેને પ્રોક્સીમાં ખસેડવામાં આવ્યું છે. જો તમારી પાસે મોટી સંખ્યામાં વસ્તુઓ અને સંગ્રહની આવર્તન સાથે ખૂબ મોટી ઝબ્બીક્સ હોય, તો આ વસ્તુઓને ઘણી સરળ બનાવે છે.

ValueCache, ઇતિહાસ અને વલણો કેશ

હિસ્ટ્રી સિંકર એ મુખ્ય પ્રક્રિયા છે જે દરેક ડેટા એલિમેન્ટ એટલે કે દરેક મૂલ્યને પરમાણુ રીતે પ્રક્રિયા કરે છે.

હિસ્ટ્રી સિંકર હિસ્ટ્રીકેશમાંથી મૂલ્યો લે છે અને ગણતરીઓ માટે ટ્રિગર્સ માટે રૂપરેખાંકન તપાસે છે. જો તેઓ છે - ગણતરી કરે છે.

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

ઇતિહાસ સમન્વયકર્તા ડેટાબેઝમાં તમામ ડેટા લખે છે, અને તે ડિસ્ક પર લખે છે. પ્રક્રિયા પ્રક્રિયા અહીં સમાપ્ત થાય છે.

DB કેશીંગ

જ્યારે તમે ગ્રાફ અથવા ઇવેન્ટ રિપોર્ટ્સ જોવા માંગતા હો ત્યારે DB બાજુ પર વિવિધ કેશ હોય છે:

• Innodb_buffer_pool MySQL બાજુ પર;
• shared_buffers PostgreSQL બાજુ પર;
• effective_cache_size ઓરેકલ બાજુ પર;
• shared_pool DB2 બાજુ પર.

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

ડેટાબેઝ કામગીરી નિર્ણાયક છે

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

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

ઘરની સંભાળ રાખનાર વ્યક્તિ

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

TrendsCache અમે ફ્લાય પર ગણતરી કરીએ છીએ. જ્યારે ડેટા આવે છે, ત્યારે અમે તેને એક કલાકમાં એકીકૃત કરીએ છીએ અને વલણના ફેરફારોની ગતિશીલતા માટે તેને કોષ્ટકોમાં મૂકીએ છીએ.

હાઉસકીપર સામાન્ય "પસંદ" સાથે ડેટાબેઝમાંથી માહિતી શરૂ કરે છે અને દૂર કરે છે. આ હંમેશા કાર્યક્ષમ હોતું નથી, જે આંતરિક પ્રક્રિયાઓના પ્રદર્શન ગ્રાફ પરથી સમજી શકાય છે.

લાલ ગ્રાફ બતાવે છે કે હિસ્ટ્રી સિંકર સતત વ્યસ્ત છે. ટોપ પર નારંગી ચાર્ટ હાઉસકીપર છે, જે સતત ચાલી રહ્યો છે. તે ડેટાબેઝ દ્વારા ઉલ્લેખિત તમામ પંક્તિઓ કાઢી નાખવાની રાહ જુએ છે.

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

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

ઘરની સંભાળ રાખનારને અક્ષમ કરવામાં આવ્યો છે, ગ્રાફિક્સ બંધ થઈ ગયા છે - આ કિસ્સામાં શું સમસ્યાઓ હોઈ શકે છે અને ત્રીજા પ્રદર્શન પડકારને ઉકેલવામાં શું મદદ કરી શકે છે?

પાર્ટીશન - પાર્ટીશન અથવા પાર્ટીશન

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

સામાન્ય રીતે, પાર્ટીશનો "સેટઅપ" ના આધારે ગોઠવવામાં આવે છે - ડેટાની માત્રા કે જે એક દિવસમાં બનાવવામાં આવે છે. એક નિયમ તરીકે, પાર્ટીશન એક દિવસમાં સેટ કરવામાં આવે છે, આ ન્યૂનતમ છે. નવા પાર્ટીશન વલણો માટે - 1 મહિનો.

ખૂબ મોટા "સેટઅપ" ના કિસ્સામાં મૂલ્યો બદલાઈ શકે છે. જો નાનું “સેટઅપ” 5 nvps (નવા મૂલ્યો પ્રતિ સેકન્ડ) સુધીનું હોય, તો સરેરાશ એક 000 થી 5 સુધીનું હોય, તો મોટું 000 nvps કરતા વધારે હોય. આ મોટા અને ખૂબ મોટા સ્થાપનો છે જેને ડેટાબેઝની જ સાવચેતીપૂર્વક ગોઠવણીની જરૂર છે.

ખૂબ મોટા સ્થાપનો પર, એક દિવસ શ્રેષ્ઠ ન હોઈ શકે. મેં દરરોજ 40 GB કે તેથી વધુના MySQL પાર્ટીશનો જોયા છે. આ ડેટાનો ખૂબ મોટો જથ્થો છે જે સમસ્યાઓ તરફ દોરી શકે છે અને તેને ઘટાડવો જોઈએ.

પાર્ટીશન શું આપે છે?

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

ઝડપી દૂર - DELETE. એક ફાઇલ/સબટેબલ પસંદ કરેલ છે, કાઢી નાખવા માટે પંક્તિઓની પસંદગી નહીં.

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

ઘણીવાર ઘણા ડેટાબેઝ પણ ઝડપે છે INSERT - બાળકના ટેબલમાં દાખલ કરે છે.

ટાઇમસ્કેલડીબી

v 4.2 માટે અમે અમારું ધ્યાન TimescaleDB તરફ વળ્યું. આ મૂળ ઇન્ટરફેસ સાથેનું પોસ્ટગ્રેએસક્યુએલ એક્સ્ટેંશન છે. એક્સ્ટેંશન રિલેશનલ ડેટાબેઝના ફાયદા ગુમાવ્યા વિના સમય શ્રેણીના ડેટા સાથે કાર્યક્ષમ રીતે કાર્ય કરે છે. TimescaleDB પણ આપમેળે પાર્ટીશનો કરે છે.

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

ટાઇમસ્કેલડીબી વિ પોસ્ટગ્રેએસક્યુએલ

TimescaleDB ખરેખર કાર્યક્ષમ છે. એક્સ્ટેંશનના નિર્માતાઓ દાવો કરે છે કે તેઓ વધુ યોગ્ય ક્વેરી પ્રોસેસિંગ અલ્ગોરિધમનો ઉપયોગ કરે છે, ખાસ કરીને, inserts . જેમ જેમ ડેટાસેટ ઇન્સર્ટનું કદ વધે છે, અલ્ગોરિધમ સતત કામગીરી જાળવી રાખે છે.

200 મિલિયન પંક્તિઓ પછી, PostgreSQL સામાન્ય રીતે ઘણું ઓછું થવાનું શરૂ કરે છે અને 0 પર કાર્યક્ષમતા ગુમાવે છે. TimescaleDB તમને કોઈપણ પ્રમાણમાં ડેટા સાથે અસરકારક રીતે "ઇન્સર્ટ" દાખલ કરવાની મંજૂરી આપે છે.

સ્થાપન

TimescaleDB ઇન્સ્ટોલ કરવું કોઈપણ પેકેજો માટે પૂરતું સરળ છે. IN દસ્તાવેજીકરણ બધું વિગતવાર છે - તે સત્તાવાર PostgreSQL પેકેજો પર આધાર રાખે છે. TimescaleDB હાથથી પણ બનાવી અને કમ્પાઈલ કરી શકાય છે.

Zabbix ડેટાબેઝ માટે, અમે ફક્ત એક્સ્ટેંશનને સક્રિય કરીએ છીએ:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

તમે સક્રિય કરો extension અને તેને Zabbix ડેટાબેઝ માટે બનાવો. છેલ્લું પગલું એ હાયપરટેબલ બનાવવાનું છે.

ઇતિહાસ કોષ્ટકોને TimescaleDB પર સ્થાનાંતરિત કરી રહ્યાં છે

આ માટે એક વિશેષ કાર્ય છે. create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

ફંક્શનમાં ત્રણ પરિમાણો છે. પ્રથમ - ડેટાબેઝમાં કોષ્ટકજેના માટે તમે હાઇપરટેબલ બનાવવા માંગો છો. બીજું - ક્ષેત્ર, જે મુજબ તે બનાવવું જરૂરી છે chunk_time_interval — વાપરવા માટે પાર્ટીશન હિસ્સાનું અંતરાલ. મારા કિસ્સામાં, અંતરાલ એક દિવસ છે - 86.

ત્રીજું પરિમાણ છે migrate_data. જો તમે સેટ કરો છો true, પછી તમામ વર્તમાન ડેટા પૂર્વ-નિર્મિત હિસ્સામાં સ્થાનાંતરિત થાય છે. મેં જાતે ઉપયોગ કર્યો છે migrate_data. મારી પાસે લગભગ 1TB હતું જેમાં એક કલાકનો સમય લાગ્યો. કેટલાક કિસ્સાઓમાં પણ, પરીક્ષણ કરતી વખતે, મેં અક્ષર પ્રકારોનો ઐતિહાસિક ડેટા કાઢી નાખ્યો, જે સ્ટોરેજ માટે વૈકલ્પિક છે, જેથી તેને સ્થાનાંતરિત ન થાય.

છેલ્લું પગલું - UPDATE: અંતે db_extension મૂકો timescaledbજેથી ડેટાબેઝ સમજે કે આ એક્સ્ટેંશન છે. Zabbix તેને સક્રિય કરે છે અને ડેટાબેઝમાં પહેલેથી જ વાક્યરચના અને પ્રશ્નોનો યોગ્ય રીતે ઉપયોગ કરે છે - તે સુવિધાઓ કે જે TimescaleDB માટે જરૂરી છે.

હાર્ડવેર રૂપરેખાંકન

મેં બે સર્વરનો ઉપયોગ કર્યો. પ્રથમ - VMware મશીન. તે પૂરતું નાનું છે: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz, 16 GB RAM અને 200 GB SSD ડ્રાઇવ.

મેં તેના પર ડેબિયન OS 10.8-10.8.pgdg1+90 અને xfs ફાઇલ સિસ્ટમ સાથે PostgreSQL 1 ઇન્સ્ટોલ કર્યું છે. મેં આ ચોક્કસ ડેટાબેઝનો ઉપયોગ કરવા માટે દરેક વસ્તુને ન્યૂનતમ રૂપરેખાંકિત કરી છે, જે બાદ Zabbix પોતે ઉપયોગ કરશે.

એ જ મશીન પર Zabbix સર્વર, PostgreSQL અને હતું લોડ એજન્ટો. મારી પાસે 50 સક્રિય એજન્ટો હતા જેમણે ઉપયોગ કર્યો હતો LoadableModuleવિવિધ પરિણામો ખૂબ જ ઝડપથી જનરેટ કરવા માટે: સંખ્યાઓ, શબ્દમાળાઓ. મેં ઘણા બધા ડેટા સાથે ડેટાબેઝ ભર્યો.

શરૂઆતમાં, રૂપરેખાંકન સમાયેલ છે 5 વસ્તુઓ હોસ્ટ દીઠ ડેટા. લગભગ દરેક ઘટકમાં તેને વાસ્તવિક સ્થાપનો જેવો દેખાવા માટે ટ્રિગર હોય છે. કેટલાક કિસ્સાઓમાં એક કરતાં વધુ ટ્રિગર હતા. એક નેટવર્ક નોડ હતો 3-000 ટ્રિગર્સ.

આઇટમ અપડેટ અંતરાલ - 4-7 સેકન્ડ. મેં ફક્ત 50 એજન્ટોનો ઉપયોગ કરીને જ નહીં, પરંતુ વધુ ઉમેરીને લોડને નિયંત્રિત કર્યું. ઉપરાંત, ડેટા ઘટકોની મદદથી, મેં ગતિશીલ રીતે લોડને નિયંત્રિત કર્યું અને અપડેટ અંતરાલને 4 સે સુધી ઘટાડ્યું.

PostgreSQL. 35 એનવીપીએસ

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

આ પ્રમાણભૂત Zabbix સર્વર પ્રદર્શન ડેશબોર્ડ છે.

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

ચોથો ગ્રાફ HistoryCache નો ઉપયોગ દર્શાવે છે. ડેટાબેઝમાં દાખલ કરતા પહેલા આ એક પ્રકારનું બફર છે. લીલો પાંચમો ગ્રાફ ValueCache નો ઉપયોગ દર્શાવે છે, એટલે કે ટ્રિગર્સ માટે કેટલા ValueCache હિટ થાય છે તે સેકન્ડ દીઠ કેટલાંક હજાર મૂલ્યો છે.

PostgreSQL. 50 એનવીપીએસ

પછી મેં એ જ હાર્ડવેર પર લોડને 50 હજાર વેલ્યુ પ્રતિ સેકન્ડ સુધી વધાર્યો.

હાઉસકીપરથી લોડ કરતી વખતે, 10 હજાર મૂલ્યો દાખલ કરવામાં 2-3 સેકન્ડનો સમય લાગ્યો.

ઘરની સંભાળ રાખનાર વ્યક્તિ પહેલેથી જ માર્ગમાં આવવાનું શરૂ કરી રહ્યું છે.

ત્રીજો ગ્રાફ બતાવે છે કે, સામાન્ય રીતે, ટ્રેપર્સ અને હિસ્ટ્રી સિંકર્સનું લોડિંગ હજુ પણ 60% ના સ્તરે છે. ચોથા ગ્રાફ પર, હાઉસકીપરની કામગીરી દરમિયાન હિસ્ટ્રીકેશ પહેલેથી જ ખૂબ સક્રિય રીતે ભરવાનું શરૂ કરી રહ્યું છે. તે 20% ભરેલું છે - લગભગ 0,5 GB.

PostgreSQL. 80 એનવીપીએસ

પછી મેં લોડને પ્રતિ સેકન્ડ 80 હજાર મૂલ્યો સુધી વધાર્યો. આ લગભગ 400 હજાર ડેટા તત્વો અને 280 હજાર ટ્રિગર્સ છે.

ત્રીસ હિસ્ટ્રી સિંકર્સનું લોડિંગ ઇન્સર્ટ પહેલેથી જ ઘણું વધારે છે.

મેં વિવિધ પરિમાણો પણ વધાર્યા છે: ઇતિહાસ સમન્વયન, કેશ.

મારા હાર્ડવેર પર, હિસ્ટ્રી સિંકર્સનું લોડિંગ મહત્તમ થઈ ગયું છે. હિસ્ટ્રીકેશ ઝડપથી ડેટાથી ભરાઈ ગયો - બફરે પ્રોસેસિંગ માટે ડેટા એકઠો કર્યો છે.

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

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

બીજું સર્વર

મેં બીજું સર્વર લીધું જેમાં પહેલાથી જ 48 પ્રોસેસર્સ અને 128 GB RAM હતી. મેં તેને ટ્યુન કર્યું - 60 ઇતિહાસ સમન્વયક સેટ કર્યું, અને સ્વીકાર્ય પ્રદર્શન પ્રાપ્ત કર્યું.

વાસ્તવમાં, આ પહેલેથી જ પ્રદર્શન મર્યાદા છે જ્યાં કંઈક કરવાની જરૂર છે.

timecaledb. 80 એનવીપીએસ

મારું મુખ્ય કાર્ય Zabbix લોડ સામે TimescaleDB ની ક્ષમતાઓનું પરીક્ષણ કરવાનું છે. સેકન્ડ દીઠ 80 હજાર મૂલ્યો ઘણો છે, મેટ્રિક્સ એકત્રિત કરવાની આવર્તન (યાન્ડેક્ષ સિવાય, અલબત્ત) અને એકદમ મોટું "સેટઅપ".

દરેક ગ્રાફ પર ડિપ છે - આ માત્ર ડેટા સ્થાનાંતરણ છે. Zabbix સર્વરમાં નિષ્ફળતાઓ પછી, ઇતિહાસ સમન્વયનની લોડિંગ પ્રોફાઇલ ઘણી બદલાઈ ગઈ છે - તે ત્રણ વખત ઘટી છે.

TimescaleDB તમને લગભગ 3 ગણો ઝડપી ડેટા દાખલ કરવાની અને ઓછી HistoryCache નો ઉપયોગ કરવાની મંજૂરી આપે છે.

તદનુસાર, તમને સમયસર ડેટા પ્રાપ્ત થશે.

timecaledb. 120 એનવીપીએસ

પછી મેં ડેટા ઘટકોની સંખ્યા વધારીને 500 હજાર કરી. મુખ્ય કાર્ય TimescaleDB ની ક્ષમતાઓ તપાસવાનું હતું - મને પ્રતિ સેકન્ડ 125 હજાર મૂલ્યોનું ગણતરી કરેલ મૂલ્ય મળ્યું.

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

સૌથી અગત્યનું, નવા TimescaleDB પાર્ટીશનો તે જ સમયે બનાવવામાં આવી રહ્યા હતા.

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

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

તારણો

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

ટાઈમસ્કેલડીબી સેટઅપ કરવું સરળ છે, પ્રદર્શનને બૂસ્ટ આપે છે, ઝબ્બીક્સ અને સાથે સારી રીતે કામ કરે છે PostgreSQL પર ફાયદા છે.

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

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

અમારા પર સબ્સ્ક્રાઇબ કરો ылку и ટેલિગ્રામ, જેમાં અમે આગામી કોન્ફરન્સની વિશેષતાઓ જાહેર કરીએ છીએ અને તેમાંથી સૌથી વધુ કેવી રીતે મેળવવું તે શોધી કાઢીએ છીએ.

સોર્સ: www.habr.com