હાઇલોડ++, આન્દ્રે ગુશ્ચિન (ઝેબિક્સ): ઉચ્ચ પ્રદર્શન અને સ્થાનિક પાર્ટીશન

અમે જોઈશું કે Zabbix બેકએન્ડ તરીકે TimescaleDB ડેટાબેઝ સાથે કેવી રીતે કામ કરે છે. અમે તમને બતાવીશું કે કેવી રીતે શરૂઆતથી શરૂઆત કરવી અને PostgreSQL માંથી કેવી રીતે સ્થળાંતર કરવું. અમે બે રૂપરેખાંકનોના તુલનાત્મક પ્રદર્શન પરીક્ષણો પણ પ્રદાન કરીશું.

હાઇલોડ++ સાઇબિરીયા 2019. ટોમ્સ્ક હોલ. જૂન 24, 16:00. થીસીસ અને પ્રસ્તુતિ. આગામી હાઇલોડ++ કોન્ફરન્સ 6 અને 7 એપ્રિલ, 2020ના રોજ સેન્ટ પીટર્સબર્ગમાં યોજાશે. વિગતો અને ટિકિટો લિંક.

આન્દ્રે ગુશ્ચિન (ત્યારબાદ - એજી): – હું ZABBIX ટેકનિકલ સપોર્ટ એન્જિનિયર છું (ત્યારબાદ "Zabbix" તરીકે ઓળખાય છે), એક ટ્રેનર. હું 6 વર્ષથી વધુ સમયથી ટેક્નિકલ સપોર્ટમાં કામ કરી રહ્યો છું અને મને પર્ફોર્મન્સનો સીધો અનુભવ છે. આજે હું નિયમિત PostgreSQL 10 ની સરખામણીમાં TimescaleDB પ્રદાન કરી શકે તેવા પ્રદર્શન વિશે વાત કરીશ. ઉપરાંત, તે સામાન્ય રીતે કેવી રીતે કાર્ય કરે છે તે વિશેનો થોડો પ્રારંભિક ભાગ.

ટોચની ઉત્પાદકતા પડકારો: ડેટા સંગ્રહથી ડેટા સફાઇ સુધી

શરૂ કરવા માટે, દરેક મોનિટરિંગ સિસ્ટમનો સામનો કરવા માટે કેટલાક પ્રદર્શન પડકારો છે. પ્રથમ ઉત્પાદકતા પડકાર એ છે કે ઝડપથી ડેટા એકત્રિત અને પ્રક્રિયા કરવી.

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

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

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

કેશીંગ સમસ્યાઓ કેવી રીતે હલ કરવી?

હવે હું ઝબ્બીક્સ વિશે ખાસ વાત કરીશ. Zabbix માં, પ્રથમ અને બીજા કૉલ્સ કેશીંગનો ઉપયોગ કરીને ઉકેલવામાં આવે છે.

ડેટા કલેક્શન અને પ્રોસેસિંગ - આ તમામ ડેટા સ્ટોર કરવા માટે અમે RAM નો ઉપયોગ કરીએ છીએ. આ ડેટા હવે વધુ વિગતવાર ચર્ચા કરવામાં આવશે.

ડેટાબેઝ બાજુ પર મુખ્ય પસંદગીઓ માટે - ગ્રાફ અને અન્ય વસ્તુઓ માટે કેટલીક કેશીંગ છે.

Zabbix સર્વરની બાજુમાં જ કેશીંગ: અમારી પાસે ConfigurationCache, ValueCache, HistoryCache, TrendsCache છે. તે શુ છે?

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

Zabbix માં કેશીંગ. માહિતી સંગ્રહ

અહીં આકૃતિ ખૂબ મોટી છે:

યોજનામાં મુખ્ય આ કલેક્ટર છે:

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

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

ઉપરાંત, જો અમારી પાસે ગણતરી કરેલ ડેટા તત્વો છે (જેઓ Zabbix થી પરિચિત છે તેઓ જાણે છે), એટલે કે ગણતરી કરેલ, એકત્રીકરણ ડેટા તત્વો, તો અમે તેને સીધા જ ValueCache થી લઈએ છીએ. તે કેવી રીતે ભરાય છે તે હું તમને પછીથી કહીશ. આ બધા કલેક્ટર્સ તેમની નોકરીઓ મેળવવા માટે ConfigurationCache નો ઉપયોગ કરે છે અને પછી તેમને પ્રીપ્રોસેસિંગમાં મોકલે છે.

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

તદનુસાર, અમે પ્રી-પ્રોસેસિંગનો ઉપયોગ કરીને આ ડેટાને અમુક રીતે પ્રોસેસ કર્યા પછી, અમે તેને આગળ પ્રક્રિયા કરવા માટે HistoryCache માં સાચવીએ છીએ. આ ડેટા સંગ્રહને સમાપ્ત કરે છે. અમે મુખ્ય પ્રક્રિયા પર આગળ વધીએ છીએ.

હિસ્ટ્રી સિંકરનું કામ

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

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

ડેટાબેઝ. કેશીંગ

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

MySQL માટે ત્યાં Innodb_buffer_pool છે, અને વિવિધ કેશનો સમૂહ છે જેને રૂપરેખાંકિત પણ કરી શકાય છે.
પરંતુ આ મુખ્ય છે:

• વહેંચાયેલ_બફર્સ;
• અસરકારક_કેશ_સાઇઝ;
• શેર કરેલ_પૂલ.

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

ડેટાબેઝ કામગીરી વિશે

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

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

ઇતિહાસ સાફ કરી રહ્યું છે. Zabbix પાસે હાઉસકીપર છે

ત્રીજો કૉલ જે Zabbix માં વપરાય છે તે હાઉસકીપરનો ઉપયોગ કરીને ઇતિહાસ સાફ કરે છે. હાઉસકીપર તમામ સેટિંગ્સને અનુસરે છે, એટલે કે, અમારા ડેટા તત્વો સૂચવે છે કે કેટલો સમય સંગ્રહ કરવો (દિવસોમાં), પ્રવાહોને કેટલો સમય સંગ્રહિત કરવો અને ફેરફારોની ગતિશીલતા.

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

કેવી રીતે સમજવું કે તે બિનઅસરકારક છે? તમે આંતરિક પ્રક્રિયાઓના પ્રદર્શન ગ્રાફ પર નીચેનું ચિત્ર જોઈ શકો છો:

તમારું હિસ્ટ્રી સિંકર સતત વ્યસ્ત છે (લાલ ગ્રાફ). અને "લાલ" ગ્રાફ જે ટોચ પર જાય છે. આ એક "હાઉસકીપર" છે જે ડેટાબેઝ દ્વારા ઉલ્લેખિત તમામ પંક્તિઓ કાઢી નાખવા માટે શરૂ થાય છે અને રાહ જુએ છે.

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

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

તમે આગળ શું કરી શકો? તમે તેને બંધ કરી દીધું છે, તમારા આલેખ બરાબર થઈ ગયા છે... આ કિસ્સામાં વધુ કઈ સમસ્યાઓ ઊભી થઈ શકે છે? શું મદદ કરી શકે?

પાર્ટીશન (વિભાગ)

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

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

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

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

તમારે પાર્ટીશનની શા માટે જરૂર છે?

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

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

ઘણા ડેટાબેઝ પણ ઇન્સર્ટ (એક ચાઇલ્ડ ટેબલમાં નિવેશ) ને ઝડપી બનાવે છે. હું હમણાં માટે અમૂર્ત રીતે બોલી રહ્યો છું, પરંતુ આ પણ શક્ય છે. પાર્ટીશન ઘણીવાર મદદ કરે છે.

NoSQL માટે સ્થિતિસ્થાપક શોધ

તાજેતરમાં, 3.4 માં, અમે NoSQL સોલ્યુશન અમલમાં મૂક્યું છે. Elasticsearch માં લખવાની ક્ષમતા ઉમેરી. તમે ચોક્કસ પ્રકારો લખી શકો છો: તમે પસંદ કરો - કાં તો નંબરો અથવા અમુક ચિહ્નો લખો; અમારી પાસે સ્ટ્રિંગ ટેક્સ્ટ છે, તમે Elasticsearch પર લોગ લખી શકો છો... તદનુસાર, વેબ ઇન્ટરફેસ પણ Elasticsearch ને ઍક્સેસ કરશે. આ કેટલાક કિસ્સાઓમાં સરસ કામ કરે છે, પરંતુ આ ક્ષણે તેનો ઉપયોગ કરી શકાય છે.

ટાઇમસ્કેલડીબી. હાયપરટેબલ

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

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

TimescaleDB અને PostgreSQL

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

TimescaleDB કેવી રીતે ઇન્સ્ટોલ કરવું? તે સરળ છે!

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

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

અને છેલ્લું પગલું...

ટાઇમસ્કેલડીબી. ઇતિહાસ કોષ્ટકોનું સ્થળાંતર

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

ક્ષેત્ર કે જેના દ્વારા બનાવવાનું છે, અને chunk_time_interval (આ હિસ્સાનું અંતરાલ છે (પાર્ટીશનો જેનો ઉપયોગ કરવાની જરૂર છે). 86 એક દિવસ છે.

સ્થાનાંતરિત_ડેટા પરિમાણ: જો તમે true માં દાખલ કરો છો, તો આ તમામ વર્તમાન ડેટાને પહેલાથી બનાવેલ હિસ્સામાં સ્થાનાંતરિત કરશે.

મેં જાતે migrate_data નો ઉપયોગ કર્યો છે - તમારો ડેટાબેઝ કેટલો મોટો છે તેના આધારે તે ઘણો સમય લે છે. મારી પાસે એક ટેરાબાઈટથી વધુ હતી - તેને બનાવવામાં એક કલાક જેટલો સમય લાગ્યો. કેટલાક કિસ્સાઓમાં, પરીક્ષણ દરમિયાન, મેં ટેક્સ્ટ (history_text) અને શબ્દમાળા (history_str) માટેનો ઐતિહાસિક ડેટા કાઢી નાખ્યો જેથી તેમને સ્થાનાંતરિત ન થાય - તે મારા માટે ખરેખર રસપ્રદ ન હતા.

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

સર્વર રૂપરેખાંકન

મેં બે સર્વરનો ઉપયોગ કર્યો. પ્રથમ સર્વર એકદમ નાનું વર્ચ્યુઅલ મશીન, 20 પ્રોસેસર્સ, 16 ગીગાબાઇટ્સ રેમ છે. મેં તેના પર પોસ્ટગ્રેસ 10.8 ને ગોઠવ્યું છે:

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

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

મેં માત્ર 50 એજન્ટ્સ (વધુ ઉમેરીને) નો ઉપયોગ કરીને જ નહીં, પણ ડાયનેમિક ડેટા તત્વોનો ઉપયોગ કરીને અને અપડેટ અંતરાલને 4 સેકન્ડ સુધી ઘટાડીને અપડેટ અંતરાલ અને લોડને નિયંત્રિત કર્યું.

પ્રદર્શન પરીક્ષણ. PostgreSQL: 36 હજાર NVPs

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

ભવિષ્યમાં આવા ઘણા બધા ગ્રાફ હશે. આ પ્રમાણભૂત Zabbix સર્વર પ્રદર્શન ડેશબોર્ડ છે.

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

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

પ્રદર્શન પરીક્ષણ. PostgreSQL: 50 હજાર NVPs

આગળ, મેં સમાન હાર્ડવેર પર લોડને 50 હજાર મૂલ્યો પ્રતિ સેકન્ડ સુધી વધાર્યો. જ્યારે હાઉસકીપર દ્વારા લોડ કરવામાં આવે છે, ત્યારે ગણતરી સાથે 10-2 સેકન્ડમાં 3 હજાર મૂલ્યો રેકોર્ડ કરવામાં આવ્યા હતા. શું, હકીકતમાં, નીચેના સ્ક્રીનશોટમાં બતાવવામાં આવ્યું છે:

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

પ્રદર્શન પરીક્ષણ. PostgreSQL: 80 હજાર NVPs

પછી મેં તેને વધારીને 80 હજાર મૂલ્ય પ્રતિ સેકન્ડ કર્યું:

તે આશરે 400 હજાર ડેટા તત્વો, 280 હજાર ટ્રિગર્સ હતા. દાખલ કરો, જેમ તમે જોઈ શકો છો, ઇતિહાસ સિંકર્સના ભારની દ્રષ્ટિએ (તેમાંના 30 હતા) પહેલેથી જ ખૂબ ઊંચા હતા. પછી મેં વિવિધ પરિમાણો વધાર્યા: હિસ્ટરી સિંકર્સ, કેશ... આ હાર્ડવેર પર, હિસ્ટ્રી સિંકર્સ પરનો ભાર મહત્તમ થવા લાગ્યો, લગભગ "શેલ્ફ પર" - તે મુજબ, હિસ્ટ્રીકેશ ખૂબ ઊંચા લોડમાં ગયો:

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

મેં બીજું સર્વર લીધું જેમાં પહેલાથી જ 48 પ્રોસેસર્સ અને 128 ગીગાબાઇટ્સ રેમ છે:

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

પ્રદર્શન પરીક્ષણ. ટાઇમસ્કેલડીબી: 80 હજાર NVP

મારું મુખ્ય કાર્ય TimescaleDB નો ઉપયોગ કરવાનું હતું. દરેક ગ્રાફ ડિપ બતાવે છે:

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

PostgreSQL પ્રદર્શન પરીક્ષણ: 120 હજાર NVPs

આગળ, મેં ડેટા ઘટકોની સંખ્યાના મૂલ્યને અડધા મિલિયન સુધી વધારી દીધું અને પ્રતિ સેકન્ડ 125 હજારનું ગણતરી કરેલ મૂલ્ય પ્રાપ્ત કર્યું:

અને મને આ ગ્રાફ મળ્યા:

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

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

સમુદાયમાં ઉદાહરણો પણ છે:

વ્યક્તિએ TimescaleDB પણ ચાલુ કર્યું અને પ્રોસેસર પર io.weightનો ઉપયોગ કરવાનો ભાર ઘટી ગયો; અને TimescaleDB ના સમાવેશને કારણે આંતરિક પ્રક્રિયા તત્વોનો ઉપયોગ પણ ઘટ્યો છે. તદુપરાંત, આ સામાન્ય પેનકેક ડિસ્ક છે, એટલે કે, સામાન્ય ડિસ્ક પર એક સામાન્ય વર્ચ્યુઅલ મશીન (એસએસડી નહીં)!

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

હું તમને અમારી ઇવેન્ટ્સમાં આમંત્રિત કરું છું: મોસ્કોમાં કોન્ફરન્સ, રીગામાં સમિટ. અમારી ચેનલોનો ઉપયોગ કરો - ટેલિગ્રામ, ફોરમ, IRC. જો તમને કોઈ પ્રશ્નો હોય, તો અમારા ડેસ્ક પર આવો, અમે દરેક વસ્તુ વિશે વાત કરી શકીએ છીએ.

પ્રેક્ષકોના પ્રશ્નો

પ્રેક્ષકો તરફથી પ્રશ્ન (ત્યારબાદ - A): - જો TimescaleDB રૂપરેખાંકિત કરવા માટે ખૂબ જ સરળ છે, અને તે આવા પ્રદર્શનને પ્રોત્સાહન આપે છે, તો પછી કદાચ આનો ઉપયોગ પોસ્ટગ્રેસ સાથે Zabbix ને ગોઠવવા માટે શ્રેષ્ઠ પ્રથા તરીકે થવો જોઈએ? અને શું આ સોલ્યુશનમાં કોઈ ક્ષતિઓ અને ગેરફાયદા છે, અથવા છેવટે, જો મેં મારા માટે ઝબ્બીક્સ બનાવવાનું નક્કી કર્યું હોય, તો હું સરળતાથી પોસ્ટગ્રેસ લઈ શકું છું, ત્યાં તરત જ ટાઇમસ્કેલ ઇન્સ્ટોલ કરી શકું છું, તેનો ઉપયોગ કરી શકું છું અને કોઈ સમસ્યા વિશે વિચારતો નથી?

એજી: - હા, હું કહીશ કે આ એક સારી ભલામણ છે: TimescaleDB એક્સ્ટેંશન સાથે તરત જ Postgres નો ઉપયોગ કરો. મેં પહેલેથી જ કહ્યું તેમ, આ "સુવિધા" પ્રાયોગિક હોવા છતાં, ઘણી સારી સમીક્ષાઓ. પરંતુ વાસ્તવમાં પરીક્ષણો દર્શાવે છે કે આ એક ઉત્તમ ઉકેલ છે (TimescaleDB સાથે) અને મને લાગે છે કે તે વિકસિત થશે! અમે આ એક્સ્ટેંશન કેવી રીતે વિકસિત થાય છે તેનું નિરીક્ષણ કરી રહ્યા છીએ અને જરૂરી ફેરફારો કરીશું.

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

એ: - સમુદાયના છેલ્લા ગ્રાફ પર, "હાઉસકીપર" સાથેનો ગ્રાફ હતો:

તેણે કામ ચાલુ રાખ્યું. ટાઇમસ્કેલડીબી સાથે હાઉસકીપર શું કરે છે?

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

એ: – મારી પાસે સમાન પ્રશ્ન છે – ટાઇમસ્કેલમાં ડિલીટ ઓપરેશનના પ્રદર્શન વિશે.
A (પ્રેક્ષકો તરફથી જવાબ): – જ્યારે તમે કોષ્ટકમાંથી ડેટા કાઢી નાખો છો, જો તમે તેને કાઢી નાખો દ્વારા કરો છો, તો તમારે કોષ્ટકમાંથી પસાર થવાની જરૂર છે - ભાવિ શૂન્યાવકાશ માટે બધું કાઢી નાખો, સાફ કરો, માર્ક કરો. ટાઈમસ્કેલમાં, તમારી પાસે હિસ્સા હોવાથી, તમે છોડી શકો છો. સામાન્ય રીતે કહીએ તો, તમે ફક્ત મોટા ડેટામાં રહેલી ફાઇલને કહો: "કાઢી નાખો!"

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

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

એજી: - અનલોડિંગ કરી શકાય છે. આવૃત્તિ 3.4 થી અમારી પાસે એક ચોક્કસ "સુવિધા" છે: તમે બધી ઐતિહાસિક ફાઈલો, ઘટનાઓ, બીજું બધું ફાઈલોમાં લખી શકો છો; અને પછી તેને કેટલાક હેન્ડલરનો ઉપયોગ કરીને કોઈપણ અન્ય ડેટાબેઝ પર મોકલો. હકીકતમાં, ઘણા લોકો પુનઃકાર્ય કરે છે અને સીધા ડેટાબેઝ પર લખે છે. ફ્લાય પર, હિસ્ટ્રી સિંકર્સ આ બધું ફાઇલોમાં લખે છે, આ ફાઇલોને ફેરવે છે, વગેરે, અને તમે તેને ક્લિકહાઉસમાં સ્થાનાંતરિત કરી શકો છો. હું યોજનાઓ વિશે કહી શકતો નથી, પરંતુ કદાચ NoSQL સોલ્યુશન્સ (જેમ કે ક્લિકહાઉસ) માટે વધુ સમર્થન ચાલુ રહેશે.

એ: - સામાન્ય રીતે, તે તારણ આપે છે કે તમે પોસ્ટગ્રેસથી સંપૂર્ણપણે છુટકારો મેળવી શકો છો?

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

એ: - ઉદાહરણ તરીકે, જો તમે ક્લિકહાઉસ પર સ્વિચ કરો તો બધું કેટલી ઝડપથી કામ કરશે તેનો અંદાજ લગાવી શકો છો?

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

એ: - તો અમે સમાન લડાઈ વિશે વાત કરી રહ્યા છીએ, અને આ ઝડપી ડેટાબેસેસના મહાન ફાયદા વિશે નહીં?

એજી: - મને લાગે છે કે જ્યારે અમે એકીકૃત થઈશું, ત્યારે વધુ સચોટ પરીક્ષણો થશે.

એ: - સારા જૂના RRD ક્યાં ગયા? તમે એસક્યુએલ ડેટાબેસેસ પર સ્વિચ કરવા માટે શું કર્યું? શરૂઆતમાં, તમામ મેટ્રિક્સ RRD પર એકત્રિત કરવામાં આવ્યા હતા.

એજી: - Zabbix પાસે RRD હતું, કદાચ ખૂબ જ પ્રાચીન સંસ્કરણમાં. ત્યાં હંમેશા SQL ડેટાબેસેસ છે - એક ઉત્તમ અભિગમ. ક્લાસિક અભિગમ MySQL, PostgreSQL છે (તેઓ ખૂબ લાંબા સમયથી અસ્તિત્વમાં છે). અમે લગભગ ક્યારેય SQL અને RRD ડેટાબેસેસ માટે સામાન્ય ઈન્ટરફેસનો ઉપયોગ કર્યો નથી.

કેટલીક જાહેરાતો 🙂

અમારી સાથે રહેવા બદલ આભાર. શું તમને અમારા લેખો ગમે છે? વધુ રસપ્રદ સામગ્રી જોવા માંગો છો? ઓર્ડર આપીને અથવા મિત્રોને ભલામણ કરીને અમને ટેકો આપો, $4.99 થી વિકાસકર્તાઓ માટે ક્લાઉડ VPS, એન્ટ્રી-લેવલ સર્વર્સનું એક અનન્ય એનાલોગ, જેની શોધ અમારા દ્વારા તમારા માટે કરવામાં આવી છે: VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps વિશેનું સંપૂર્ણ સત્ય $19 થી અથવા સર્વર કેવી રીતે શેર કરવું? (RAID1 અને RAID10 સાથે ઉપલબ્ધ, 24 કોરો સુધી અને 40GB DDR4 સુધી).

એમ્સ્ટરડેમમાં ઇક્વિનિક્સ ટાયર IV ડેટા સેન્ટરમાં ડેલ R730xd 2 ગણું સસ્તું? માત્ર અહીં 2 x ઇન્ટેલ ટેટ્રાડેકા-કોર Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ટીવી $199 થી નેધરલેન્ડમાં! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 થી! વિશે વાંચો ઇન્ફ્રાસ્ટ્રક્ચર કોર્પોરેશન કેવી રીતે બનાવવું. ડેલ R730xd E5-2650 v4 સર્વર્સના ઉપયોગ સાથેનો વર્ગ એક પેની માટે 9000 યુરોના મૂલ્યના છે?

સોર્સ: www.habr.com