VictoriaMetrics માં ઑપ્ટિમાઇઝેશન પર જાઓ. એલેક્ઝાંડર વાલાલકીન

હું સૂચન કરું છું કે તમે એલેક્ઝાન્ડર વાલ્યાલ્કિનના 2019ના અંતમાંના અહેવાલની ટ્રાન્સક્રિપ્ટ વાંચો “વિક્ટોરિયામેટ્રિક્સમાં ઑપ્ટિમાઇઝેશન પર જાઓ”

વિક્ટોરિયામેટ્રિક્સ - સમય શ્રેણીના સ્વરૂપમાં ડેટાને સંગ્રહિત કરવા અને પ્રક્રિયા કરવા માટે ઝડપી અને સ્કેલેબલ DBMS (રેકોર્ડ સમય અને આ સમયને અનુરૂપ મૂલ્યોનો સમૂહ બનાવે છે, ઉદાહરણ તરીકે, સેન્સરની સ્થિતિ અથવા સંગ્રહના સામયિક મતદાન દ્વારા મેળવવામાં આવે છે. મેટ્રિક્સ).

આ અહેવાલના વિડીયોની લીંક આ રહી- https://youtu.be/MZ5P21j_HLE

સ્લાઇડ્સ

તમારા વિષે જણાવો. હું એલેક્ઝાંડર વાલ્યાલ્કિન છું. અહીં મારું GitHub એકાઉન્ટ. હું ગો અને પરફોર્મન્સ ઑપ્ટિમાઇઝેશન વિશે ઉત્સાહી છું. મેં ઘણી બધી ઉપયોગી અને એટલી ઉપયોગી લાઈબ્રેરીઓ લખી નથી. તેઓ ક્યાં તો સાથે શરૂ થાય છે fast, અથવા સાથે quick ઉપસર્ગ

હું હાલમાં VictoriaMetrics પર કામ કરું છું. તે શું છે અને હું ત્યાં શું કરી રહ્યો છું? હું આ પ્રસ્તુતિમાં આ વિશે વાત કરીશ.

અહેવાલની રૂપરેખા નીચે મુજબ છે.

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

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

વિક્ટોરિયામેટ્રિક્સ અન્ય સમય શ્રેણીના ડેટાબેસેસ કરતાં વધુ સારી ડેટા કમ્પ્રેશન પ્રદાન કરે છે.

તે ઊભી રીતે સ્કેલ કરે છે - એટલે કે, તમે એક કમ્પ્યુટર પર વધુ પ્રોસેસર્સ, વધુ RAM ઉમેરી શકો છો. VictoriaMetrics આ ઉપલબ્ધ સંસાધનોનો સફળતાપૂર્વક ઉપયોગ કરશે અને રેખીય ઉત્પાદકતામાં સુધારો કરશે.

VictoriaMetrics પણ આડા ધોરણે સ્કેલ કરે છે - એટલે કે, તમે VictoriaMetrics ક્લસ્ટરમાં વધારાના નોડ્સ ઉમેરી શકો છો અને તેનું પ્રદર્શન લગભગ રેખીય રીતે વધશે.

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

કોણ જાણે સમય શ્રેણી શું છે? તે ઘણા લોકોને ઓળખે છે. સમય શ્રેણી એ જોડીની શ્રેણી છે (timestamp, значение), જ્યાં આ જોડીઓ સમય દ્વારા સૉર્ટ કરવામાં આવે છે. મૂલ્ય એ ફ્લોટિંગ પોઈન્ટ નંબર છે - ફ્લોટ64.

દરેક વખતે શ્રૃંખલાને કી દ્વારા વિશિષ્ટ રીતે ઓળખવામાં આવે છે. આ કી શું સમાવે છે? તેમાં કી-વેલ્યુ જોડીના બિન-ખાલી સમૂહનો સમાવેશ થાય છે.

અહીં સમય શ્રેણીનું ઉદાહરણ છે. આ શ્રેણીની ચાવી એ જોડીની સૂચિ છે: __name__="cpu_usage" મેટ્રિકનું નામ છે, instance="my-server" - આ તે કમ્પ્યુટર છે જેના પર આ મેટ્રિક એકત્રિત કરવામાં આવે છે, datacenter="us-east" - આ તે ડેટા સેન્ટર છે જ્યાં આ કમ્પ્યુટર સ્થિત છે.

અમે ત્રણ કી-વેલ્યુ જોડી ધરાવતા સમય શ્રેણીના નામ સાથે સમાપ્ત થયા. આ કી જોડીની યાદીને અનુરૂપ છે (timestamp, value). t1, t3, t3, ..., tN - આ ટાઇમસ્ટેમ્પ છે, 10, 20, 12, ..., 15 - અનુરૂપ મૂલ્યો. આ આપેલ પંક્તિ માટે આપેલ સમયે સીપીયુ-ઉપયોગ છે.

સમય શ્રેણી ક્યાં વાપરી શકાય? શું કોઈને કોઈ વિચાર છે?

• DevOps માં, તમે CPU, RAM, નેટવર્ક, rps, ભૂલોની સંખ્યા વગેરે માપી શકો છો.
• IoT - અમે તાપમાન, દબાણ, જીઓ કોઓર્ડિનેટ્સ અને બીજું કંઈક માપી શકીએ છીએ.
• ફાઇનાન્સ પણ - અમે તમામ પ્રકારના સ્ટોક્સ અને કરન્સી માટે કિંમતો પર નજર રાખી શકીએ છીએ.
• વધુમાં, સમય શ્રેણીનો ઉપયોગ કારખાનાઓમાં ઉત્પાદન પ્રક્રિયાઓની દેખરેખમાં કરી શકાય છે. અમારી પાસે એવા વપરાશકર્તાઓ છે કે જેઓ રોબોટ્સ માટે વિન્ડ ટર્બાઇન્સનું નિરીક્ષણ કરવા VictoriaMetrics નો ઉપયોગ કરે છે.
• સમય શ્રેણી વિવિધ ઉપકરણોના સેન્સરમાંથી માહિતી એકત્રિત કરવા માટે પણ ઉપયોગી છે. ઉદાહરણ તરીકે, એન્જિન માટે; ટાયર દબાણ માપવા માટે; ઝડપ, અંતર માપવા માટે; ગેસોલિન વપરાશ, વગેરે માપવા માટે.
• ટાઇમ સિરીઝનો ઉપયોગ એરક્રાફ્ટને મોનિટર કરવા માટે પણ કરી શકાય છે. દરેક એરક્રાફ્ટમાં બ્લેક બોક્સ હોય છે જે એરક્રાફ્ટના સ્વાસ્થ્યના વિવિધ પરિમાણો માટે સમય શ્રેણી એકત્રિત કરે છે. સમય શ્રેણીનો ઉપયોગ એરોસ્પેસ ઉદ્યોગમાં પણ થાય છે.
• હેલ્થકેર એટલે બ્લડપ્રેશર, પલ્સ વગેરે.

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

તમારે ટાઈમ સીરીઝ ડેટાબેઝની જરૂર કેમ છે? શા માટે તમે સમય શ્રેણી સ્ટોર કરવા માટે નિયમિત રીલેશનલ ડેટાબેઝનો ઉપયોગ કરી શકતા નથી?

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

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

ઉદાહરણ તરીકે VictoriaMetrics નો ઉપયોગ કરીને આધુનિક સમયની શ્રેણીના ડેટાબેઝ આર્કિટેક્ચર આ જેવું દેખાય છે.

તે બે ભાગો સમાવે છે. આ ઇન્વર્ટેડ ઇન્ડેક્સ માટેનો સંગ્રહ છે અને સમય શ્રેણીના મૂલ્યો માટેનો સંગ્રહ છે. આ ભંડારો અલગ કરવામાં આવે છે.

જ્યારે ડેટાબેઝમાં નવો રેકોર્ડ આવે છે, ત્યારે આપેલ સેટ માટે સમય શ્રેણી ઓળખકર્તા શોધવા માટે અમે પ્રથમ ઊંધી ઇન્ડેક્સને ઍક્સેસ કરીએ છીએ. label=value આપેલ મેટ્રિક માટે. અમે આ ઓળખકર્તા શોધીએ છીએ અને ડેટા સ્ટોરમાં મૂલ્ય સાચવીએ છીએ.

જ્યારે TSDB માંથી ડેટા પુનઃપ્રાપ્ત કરવા માટે કોઈ વિનંતી આવે છે, ત્યારે અમે પહેલા ઈન્વર્ટેડ ઈન્ડેક્સ પર જઈએ છીએ. ચાલો બધું મેળવીએ timeseries_ids આ સેટ સાથે મેળ ખાતા રેકોર્ડ label=value. અને પછી અમે ડેટા વેરહાઉસમાંથી તમામ જરૂરી ડેટા મેળવીએ છીએ, દ્વારા અનુક્રમિત timeseries_ids.

ચાલો એક ઉદાહરણ જોઈએ કે કેવી રીતે ટાઈમ સીરીઝ ડેટાબેઝ આવનારી પસંદગીની ક્વેરી પર પ્રક્રિયા કરે છે.

• સૌ પ્રથમ તેણીને બધું મળે છે timeseries_ids ઊંધી અનુક્રમણિકામાંથી જે આપેલ જોડીઓ ધરાવે છે label=value, અથવા આપેલ નિયમિત અભિવ્યક્તિને સંતોષો.
• પછી તે મળેલ લોકો માટે આપેલ સમય અંતરાલ પર ડેટા સ્ટોરેજમાંથી તમામ ડેટા પોઈન્ટ પુનઃપ્રાપ્ત કરે છે timeseries_ids.
• આ પછી, ડેટાબેઝ વપરાશકર્તાની વિનંતી અનુસાર, આ ડેટા બિંદુઓ પર કેટલીક ગણતરીઓ કરે છે. અને તે પછી તે જવાબ આપે છે.

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

ચાલો ઇન્વર્ટેડ ઇન્ડેક્સ પર આગળ વધીએ. ઘણાને લાગે છે કે આ સરળ છે. કોણ જાણે છે કે ઇન્વર્ટેડ ઇન્ડેક્સ શું છે અને તે કેવી રીતે કાર્ય કરે છે? ઓહ, હવે ઘણા લોકો નથી. ચાલો તે શું છે તે સમજવાનો પ્રયાસ કરીએ.

તે ખરેખર સરળ છે. તે ફક્ત એક શબ્દકોશ છે જે મૂલ્યની ચાવીને મેપ કરે છે. ચાવી શું છે? આ યુગલ label=valueજ્યાં label и value - આ રેખાઓ છે. અને મૂલ્યો એક સમૂહ છે timeseries_ids, જેમાં આપેલ જોડીનો સમાવેશ થાય છે label=value.

ઇન્વર્ટેડ ઇન્ડેક્સ તમને ઝડપથી બધું શોધવાની મંજૂરી આપે છે timeseries_ids, જે આપ્યા છે label=value.

તે તમને ઝડપથી શોધવા માટે પણ પરવાનગી આપે છે timeseries_ids ઘણી જોડી માટે સમય શ્રેણી label=value, અથવા યુગલો માટે label=regexp. આ કેવી રીતે થાય છે? સમૂહના આંતરછેદને શોધીને timeseries_ids દરેક જોડી માટે label=value.

ચાલો ઈન્વર્ટેડ ઈન્ડેક્સના વિવિધ અમલીકરણો જોઈએ. ચાલો સરળ નિષ્કપટ અમલીકરણ સાથે પ્રારંભ કરીએ. તેણી આના જેવી દેખાય છે.

કાર્ય getMetricIDs તારોની યાદી મેળવે છે. દરેક લીટી સમાવે છે label=value. આ ફંક્શન યાદી આપે છે metricIDs.

તે કેવી રીતે કામ કરે છે? અહીં આપણી પાસે વૈશ્વિક ચલ છે જેને કહેવાય છે invertedIndex. આ એક નિયમિત શબ્દકોશ છે (map), જે સ્ટ્રિંગને સ્લાઈસ ઈન્ટ્સ માટે મેપ કરશે. લીટી સમાવે છે label=value.

કાર્ય અમલીકરણ: મેળવો metricIDs પ્રથમ માટે label=value, પછી આપણે બાકીની બધી બાબતોમાંથી પસાર થઈએ છીએ label=value, અમે તે મેળવીએ છીએ metricIDs તેમને માટે. અને ફંક્શનને કૉલ કરો intersectInts, જેની નીચે ચર્ચા કરવામાં આવશે. અને આ ફંક્શન આ યાદીઓનું આંતરછેદ આપે છે.

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

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

આ સમસ્યાને તૈયાર ઉકેલોનો ઉપયોગ કરીને ઉકેલી શકાય છે જેમ કે લેવલડીબી, અથવા રોક્સડીબી.

ટૂંકમાં, અમને એક ડેટાબેઝની જરૂર છે જે અમને ત્રણ કામગીરી ઝડપથી કરવા દે.

• પ્રથમ ઓપરેશન રેકોર્ડિંગ છે ключ-значение આ ડેટાબેઝ માટે. તેણી આ ખૂબ જ ઝડપથી કરે છે, જ્યાં ключ-значение મનસ્વી શબ્દમાળાઓ છે.
• બીજી ક્રિયા એ આપેલ કીનો ઉપયોગ કરીને મૂલ્ય માટે ઝડપી શોધ છે.
• અને ત્રીજી ક્રિયા એ આપેલ ઉપસર્ગ દ્વારા તમામ મૂલ્યો માટે ઝડપી શોધ છે.

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

લેવલડીબીનો ઉપયોગ કરીને ઇન્વર્ટેડ ઇન્ડેક્સ લાગુ કરી શકાય છે. તે કેવી રીતે કરવું? અમે કી તરીકે સાચવીએ છીએ label=value. અને મૂલ્ય એ સમય શ્રેણીનું ઓળખકર્તા છે જ્યાં જોડી હાજર છે label=value.

જો આપણી પાસે આપેલ જોડી સાથે ઘણી વખત શ્રેણી હોય label=value, તો પછી આ ડેટાબેઝમાં એક જ કી અને અલગ સાથે ઘણી પંક્તિઓ હશે timeseries_ids. બધાની યાદી મેળવવા માટે timeseries_ids, જે આ સાથે શરૂ થાય છે label=prefix, અમે શ્રેણી સ્કેન કરીએ છીએ જેના માટે આ ડેટાબેઝ ઑપ્ટિમાઇઝ કરવામાં આવે છે. એટલે કે, અમે સાથે શરૂ થતી તમામ રેખાઓ પસંદ કરીએ છીએ label=prefix અને જરૂરી મેળવો timeseries_ids.

Go માં તે કેવું દેખાશે તેનો અહીં એક નમૂનો અમલીકરણ છે. અમારી પાસે ઊંધી ઇન્ડેક્સ છે. આ લેવલડીબી છે.

કાર્ય નિષ્કપટ અમલીકરણ માટે સમાન છે. તે નિષ્કપટ અમલીકરણને લગભગ લાઇન દ્વારા પુનરાવર્તન કરે છે. એકમાત્ર મુદ્દો એ છે કે તરફ વળવાને બદલે map અમે ઇન્વર્ટેડ ઇન્ડેક્સ એક્સેસ કરીએ છીએ. આપણે પ્રથમ માટે તમામ મૂલ્યો મેળવીએ છીએ label=value. પછી અમે બાકીની બધી જોડીમાંથી પસાર થઈએ છીએ label=value અને તેમના માટે મેટ્રિકઆઈડીના અનુરૂપ સેટ મેળવો. પછી આપણે આંતરછેદ શોધીએ છીએ.

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

શા માટે? કારણ કે લેવલડીબી નિષ્કપટ અમલીકરણ કરતા ધીમું છે. નિષ્કપટ અમલીકરણમાં, આપેલ કી આપવામાં આવે છે, અમે તરત જ સમગ્ર સ્લાઇસ પુનઃપ્રાપ્ત કરીએ છીએ metricIDs. આ એક ખૂબ જ ઝડપી કામગીરી છે - સમગ્ર સ્લાઇસ ઉપયોગ માટે તૈયાર છે.

લેવલડીબીમાં, દરેક વખતે ફંક્શનને બોલાવવામાં આવે છે GetValues તમારે શરૂ થતી તમામ રેખાઓમાંથી પસાર થવાની જરૂર છે label=value. અને દરેક લાઇન માટે મૂલ્ય મેળવો timeseries_ids. જેમ કે timeseries_ids આનો ટુકડો એકત્રિત કરો timeseries_ids. દેખીતી રીતે, આ ફક્ત કી દ્વારા નિયમિત નકશાને ઍક્સેસ કરવા કરતાં ઘણું ધીમું છે.

બીજી ખામી એ છે કે LevelDB C માં લખાયેલું છે. Go માંથી C ફંક્શન્સને કૉલ કરવાનું ખૂબ ઝડપી નથી. તે સેંકડો નેનોસેકન્ડ લે છે. આ બહુ ઝડપી નથી, કારણ કે ગોમાં લખેલા નિયમિત ફંક્શન કૉલની સરખામણીમાં, જે 1-5 નેનોસેકન્ડ લે છે, પ્રદર્શનમાં તફાવત દસ ગણો છે. વિક્ટોરિયામેટ્રિક્સ માટે આ એક જીવલેણ ખામી હતી :)

તેથી મેં ઇન્વર્ટેડ ઇન્ડેક્સનું મારું પોતાનું અમલીકરણ લખ્યું. અને તેણે તેણીને બોલાવી મર્જસેટ.

મર્જસેટ મર્જટ્રી ડેટા સ્ટ્રક્ચર પર આધારિત છે. આ ડેટા સ્ટ્રક્ચર ક્લિકહાઉસમાંથી ઉધાર લેવામાં આવ્યું છે. દેખીતી રીતે, મર્જસેટને ઝડપી શોધ માટે ઑપ્ટિમાઇઝ કરવું જોઈએ timeseries_ids આપેલ કી અનુસાર. મર્જસેટ સંપૂર્ણપણે ગોમાં લખાયેલું છે. તમે જોઈ શકો છો GitHub પર VictoriaMetrics સ્ત્રોતો. મર્જસેટનું અમલીકરણ ફોલ્ડરમાં છે /lib/mergeset. તમે ત્યાં શું થઈ રહ્યું છે તે શોધવાનો પ્રયાસ કરી શકો છો.

મર્જસેટ API એ LevelDB અને RocksDB જેવું જ છે. એટલે કે, તે તમને ત્યાં ઝડપથી નવા રેકોર્ડ્સ સાચવવા અને આપેલ ઉપસર્ગ દ્વારા રેકોર્ડ્સને ઝડપથી પસંદ કરવાની મંજૂરી આપે છે.

અમે મર્જસેટના ગેરફાયદા વિશે પછીથી વાત કરીશું. હવે ચાલો વાત કરીએ કે વિક્ટોરિયામેટ્રિક્સના ઉત્પાદનમાં ઊંધી સૂચકાંક લાગુ કરતી વખતે કઈ સમસ્યાઓ ઊભી થઈ.

તેઓ શા માટે ઉભા થયા?

પ્રથમ કારણ ઉચ્ચ મંથન દર છે. રશિયનમાં અનુવાદિત, આ સમય શ્રેણીમાં વારંવાર ફેરફાર છે. આ ત્યારે થાય છે જ્યારે સમય શ્રેણી સમાપ્ત થાય છે અને નવી શ્રેણી શરૂ થાય છે, અથવા ઘણી નવી સમય શ્રેણી શરૂ થાય છે. અને આ વારંવાર થાય છે.

બીજું કારણ સમય શ્રેણીની મોટી સંખ્યા છે. શરૂઆતમાં, જ્યારે મોનિટરિંગ લોકપ્રિયતા મેળવી રહ્યું હતું, ત્યારે સમય શ્રેણીની સંખ્યા ઓછી હતી. ઉદાહરણ તરીકે, દરેક કમ્પ્યુટર માટે તમારે CPU, મેમરી, નેટવર્ક અને ડિસ્ક લોડને મોનિટર કરવાની જરૂર છે. કમ્પ્યુટર દીઠ 4 વખતની શ્રેણી. ધારો કે તમારી પાસે 100 કમ્પ્યુટર્સ અને 400 સમય શ્રેણી છે. આ બહુ ઓછું છે.

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

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

એક મેટ્રિકમાંથી અમને માત્ર એક કમ્પ્યુટર માટે 40 x 8 = 320 મેટ્રિક્સ મળ્યા. 100 વડે ગુણાકાર કરીએ તો આપણને 32 ને બદલે 000 મળે છે.

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

ચાલો ઉચ્ચ મંથન દર પર નજીકથી નજર કરીએ. ઉત્પાદનમાં ઊંચા મંથન દરનું કારણ શું છે? કારણ કે લેબલ અને ટેગના કેટલાક અર્થો સતત બદલાતા રહે છે.

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

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

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

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

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

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

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

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

અગાઉના સોલ્યુશન કરતાં આ સોલ્યુશનનો ફાયદો એ છે કે અમે સમય શ્રેણીની માહિતીની નકલ કરતા નથી જે સમય જતાં અદૃશ્ય થઈ ન જાય. તેઓ સતત હાજર રહે છે અને બદલાતા નથી.

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

મારે તેની સાથે લડવું પડ્યું. સંઘર્ષ એ હતો કે આ અમલીકરણમાં તમારે હજી ઘણી મોટી સંખ્યા પસંદ કરવાની જરૂર છે timeseries_ids જ્યારે ઇન્વર્ટેડ ઇન્ડેક્સ સમય વિભાજિત થાય ત્યારે ડેટા માટે.

અમે આ સમસ્યા કેવી રીતે હલ કરી? અમે તેને મૂળ રીતે હલ કર્યો - એક ઓળખકર્તાને બદલે દરેક ઇન્વર્ટેડ ઇન્ડેક્સ એન્ટ્રીમાં ઘણા સમયની શ્રેણી ઓળખકર્તાઓને સંગ્રહિત કરીને. એટલે કે, અમારી પાસે એક ચાવી છે label=value, જે દરેક સમયની શ્રેણીમાં થાય છે. અને હવે અમે ઘણા બચાવીએ છીએ timeseries_ids એક એન્ટ્રીમાં.

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

આનાથી આવા ઇન્વર્ટેડ ઇન્ડેક્સની સ્કેનિંગ સ્પીડને 10 ગણી સુધી વધારવાનું શક્ય બન્યું. અને તે અમને કેશ માટે મેમરી વપરાશ ઘટાડવાની મંજૂરી આપે છે, કારણ કે હવે આપણે શબ્દમાળા સંગ્રહિત કરીએ છીએ label=value કેશમાં માત્ર એક જ વાર N વખત. અને જો તમે તમારા ટૅગ્સ અને લેબલ્સમાં લાંબી લાઈનો સંગ્રહિત કરો છો, તો આ લાઇન મોટી હોઈ શકે છે, જેને કુબરનેટસને ત્યાં ખસેડવાનું પસંદ છે.

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

હવે ચાલો આપણા ઘેટાં પર પાછા જઈએ - આંતરછેદ કાર્ય પર timeseries_ids. ચાલો વિચાર કરીએ કે ત્યાં કયા અમલીકરણો હોઈ શકે છે. આ કાર્ય તમને શોધવા માટે પરવાનગી આપે છે timeseries_ids આપેલ સેટ માટે label=value.

પ્રથમ વિકલ્પ નિષ્કપટ અમલીકરણ છે. બે નેસ્ટેડ લૂપ્સ. અહીં આપણને ફંક્શન ઇનપુટ મળે છે intersectInts બે ટુકડા - a и b. આઉટપુટ પર, તે અમને આ સ્લાઇસેસના આંતરછેદ પર પાછા આવવું જોઈએ.

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

ગેરફાયદા શું છે? ચતુર્ભુજ જટિલતા તેની મુખ્ય ખામી છે. ઉદાહરણ તરીકે, જો તમારા પરિમાણો સ્લાઇસ છે a и b એક સમયે એક મિલિયન, પછી આ કાર્ય તમને ક્યારેય જવાબ આપશે નહીં. કારણ કે તેને એક ટ્રિલિયન પુનરાવર્તનો કરવાની જરૂર પડશે, જે આધુનિક કમ્પ્યુટર્સ માટે પણ ઘણું છે.

બીજું અમલીકરણ નકશા પર આધારિત છે. અમે નકશો બનાવીએ છીએ. અમે આ નકશામાં સ્લાઇસમાંથી તમામ મૂલ્યો મૂકીએ છીએ a. પછી આપણે એક અલગ લૂપમાં સ્લાઇસમાંથી પસાર થઈએ છીએ b. અને અમે તપાસીએ છીએ કે શું આ મૂલ્ય સ્લાઈસમાંથી છે b નકશામાં જો તે અસ્તિત્વમાં છે, તો પછી તેને પરિણામમાં ઉમેરો.

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

નુકસાન એ છે કે આ નકશો બનાવવા માટે આ કાર્યને વધુ મેમરીની જરૂર છે.

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

આ સ્થળોએ સીપીયુનો સમય કેમ વેડફાય છે? કારણ કે ગો આ રેખાઓ પર હેશિંગ ઓપરેશન કરે છે. એટલે કે, તે HashMap માં આપેલ અનુક્રમણિકા પર તેને ઍક્સેસ કરવા માટે કીના હેશની ગણતરી કરે છે. હેશ ગણતરીની કામગીરી દસ નેનોસેકન્ડમાં પૂર્ણ થાય છે. VictoriaMetrics માટે આ ધીમું છે.

મેં આ કેસ માટે ખાસ કરીને ઑપ્ટિમાઇઝ કરેલ બિટસેટ અમલમાં મૂકવાનું નક્કી કર્યું છે. બે સ્લાઇસનું આંતરછેદ હવે આના જેવું દેખાય છે. અહીં આપણે બીટસેટ બનાવીએ છીએ. અમે તેમાં પ્રથમ સ્લાઇસમાંથી ઘટકો ઉમેરીએ છીએ. પછી આપણે બીજી સ્લાઇસમાં આ તત્વોની હાજરી તપાસીએ છીએ. અને તેમને પરિણામમાં ઉમેરો. એટલે કે, તે અગાઉના ઉદાહરણથી લગભગ અલગ નથી. અહીં એકમાત્ર વસ્તુ એ છે કે અમે નકશાની ઍક્સેસને કસ્ટમ ફંક્શન્સ સાથે બદલી છે add и has.

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

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

આ અમલીકરણનો ગેરલાભ એ છે કે તે એટલું સ્પષ્ટ નથી, તુચ્છ નથી.

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

ચાલો આ રચનાના અમલીકરણને ધ્યાનમાં લઈએ. જો તમે જોવા માંગો છો, તો તે ફોલ્ડરમાં, VictoriaMetrics સ્ત્રોતોમાં સ્થિત છે lib/uint64set. તે ખાસ કરીને VictoriaMetrics કેસ માટે ઑપ્ટિમાઇઝ કરેલ છે, જ્યાં timeseries_id 64-બીટ મૂલ્ય છે, જ્યાં પ્રથમ 32 બિટ્સ મૂળભૂત રીતે સ્થિર હોય છે અને માત્ર છેલ્લા 32 બિટ્સ બદલાય છે.

આ માહિતી માળખું ડિસ્ક પર સંગ્રહિત નથી, તે ફક્ત મેમરીમાં કાર્ય કરે છે.

અહીં તેનું API છે. તે બહુ જટિલ નથી. API એ ખાસ કરીને VictoriaMetrics નો ઉપયોગ કરવાના ચોક્કસ ઉદાહરણને અનુરૂપ છે. એટલે કે, અહીં કોઈ બિનજરૂરી કાર્યો નથી. VictoriaMetrics દ્વારા સ્પષ્ટપણે ઉપયોગમાં લેવાતા કાર્યો અહીં છે.

કાર્યો છે add, જે નવા મૂલ્યો ઉમેરે છે. એક કાર્ય છે has, જે નવા મૂલ્યો માટે તપાસે છે. અને ત્યાં એક કાર્ય છે del, જે મૂલ્યોને દૂર કરે છે. સહાયક કાર્ય છે len, જે સેટનું કદ પરત કરે છે. કાર્ય clone ઘણું ક્લોન્સ કરે છે. અને કાર્ય appendto આ સમૂહને સ્લાઈસમાં ફેરવે છે timeseries_ids.

આ ડેટા સ્ટ્રક્ચરનું અમલીકરણ આના જેવું દેખાય છે. સેટમાં બે ઘટકો છે:

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

• બીજું ક્ષેત્ર છે buckets. આ રચનામાંથી સ્લાઇસ છે bucket32. દરેક માળખું સ્ટોર કરે છે hi ક્ષેત્ર આ ઉપલા 32 બિટ્સ છે. અને બે ટુકડા - b16his и buckets થી bucket16 માળખાં

16-બીટ સ્ટ્રક્ચરના બીજા ભાગના ટોચના 64 બિટ્સ અહીં સંગ્રહિત છે. અને અહીં દરેક બાઈટના નીચલા 16 બિટ્સ માટે બિટસેટ્સ સંગ્રહિત થાય છે.

Bucket64 એરેનો સમાવેશ થાય છે uint64. આ સ્થિરાંકોનો ઉપયોગ કરીને લંબાઈની ગણતરી કરવામાં આવે છે. એકમાં bucket16 મહત્તમ સંગ્રહ કરી શકાય છે 2^16=65536 બીટ જો તમે આને 8 વડે ભાગો તો તે 8 કિલોબાઈટ થાય. જો તમે ફરીથી 8 વડે ભાગશો તો તે 1000 થશે uint64 અર્થ તે જ Bucket16 - આ અમારું 8-કિલોબાઈટ માળખું છે.

ચાલો જોઈએ કે નવું મૂલ્ય ઉમેરવા માટેની આ રચનાની પદ્ધતિઓમાંથી એક કેવી રીતે લાગુ કરવામાં આવે છે.

તે બધા સાથે શરૂ થાય છે uint64 અર્થો અમે ઉપલા 32 બિટ્સની ગણતરી કરીએ છીએ, અમે નીચલા 32 બિટ્સની ગણતરી કરીએ છીએ. ચાલો બધું પસાર કરીએ buckets. અમે દરેક બકેટમાં ટોચના 32 બિટ્સની સરખામણી કરીએ છીએ તે મૂલ્ય ઉમેરવામાં આવે છે. અને જો તેઓ મેળ ખાતા હોય, તો અમે કાર્યને કૉલ કરીએ છીએ add બંધારણ b32 માં buckets. અને ત્યાં નીચેના 32 બિટ્સ ઉમેરો. અને જો તે પાછો ફર્યો true, તો પછી આનો અર્થ એ થયો કે અમે ત્યાં આવી કિંમત ઉમેરી છે અને અમારી પાસે આવી કિંમત નથી. જો તે પરત આવે false, તો પછી આવા અર્થ પહેલેથી અસ્તિત્વમાં છે. પછી આપણે બંધારણમાં તત્વોની સંખ્યામાં વધારો કરીએ છીએ.

જો અમને તમને જોઈતું ન મળ્યું હોય bucket જરૂરી હાઇ-વેલ્યુ સાથે, પછી અમે ફંક્શનને કૉલ કરીએ છીએ addAlloc, જે એક નવું ઉત્પાદન કરશે bucket, તેને બકેટ સ્ટ્રક્ચરમાં ઉમેરી રહ્યા છે.

આ કાર્યનું અમલીકરણ છે b32.add. તે અગાઉના અમલીકરણ જેવું જ છે. અમે સૌથી નોંધપાત્ર 16 બિટ્સ, સૌથી ઓછા નોંધપાત્ર 16 બિટ્સની ગણતરી કરીએ છીએ.

પછી આપણે બધા ઉપરના 16 બિટ્સમાંથી પસાર થઈએ છીએ. અમે મેચો શોધીએ છીએ. અને જો ત્યાં મેચ હોય, તો અમે એડ મેથડ કહીએ છીએ, જેના માટે અમે આગળના પૃષ્ઠ પર વિચારણા કરીશું bucket16.

અને અહીં સૌથી નીચું સ્તર છે, જે શક્ય તેટલું ઑપ્ટિમાઇઝ કરવું જોઈએ. માટે અમે ગણતરી કરીએ છીએ uint64 સ્લાઇસ બીટમાં id મૂલ્ય અને એ પણ bitmask. આ આપેલ 64-બીટ મૂલ્ય માટેનો માસ્ક છે, જેનો ઉપયોગ આ બીટની હાજરી તપાસવા અથવા તેને સેટ કરવા માટે કરી શકાય છે. આ બીટ સેટ છે કે કેમ તે જોવા માટે અમે તપાસ કરીએ છીએ અને તેને સેટ કરીએ છીએ અને હાજરી પરત કરીએ છીએ. આ અમારું અમલીકરણ છે, જેણે અમને પરંપરાગત નકશાની તુલનામાં 10 ગણી સમય શ્રેણીના ids ને છેદવાની ક્રિયાને ઝડપી બનાવવાની મંજૂરી આપી.

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

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

મારી પાસે બિટસેટ વિશે એક પ્રશ્ન છે. C++ વેક્ટર બૂલ અમલીકરણ, ઑપ્ટિમાઇઝ બિટસેટ જેવું જ. શું તમે ત્યાંથી અમલીકરણ લીધો?

ના, ત્યાંથી નહીં. આ બિટસેટનો અમલ કરતી વખતે, મને વિક્ટોરિયામેટ્રિક્સમાં ઉપયોગમાં લેવાતી આ ids ટાઈમસીરીઝના માળખાના જ્ઞાન દ્વારા માર્ગદર્શન આપવામાં આવ્યું હતું. અને તેમની રચના એવી છે કે ઉપલા 32 બિટ્સ મૂળભૂત રીતે સ્થિર છે. નીચલા 32 બિટ્સ ફેરફારને પાત્ર છે. નીચું બીટ, વધુ વખત તે બદલી શકે છે. તેથી, આ અમલીકરણ ખાસ કરીને આ ડેટા સ્ટ્રક્ચર માટે ઑપ્ટિમાઇઝ કરવામાં આવ્યું છે. C++ અમલીકરણ, જ્યાં સુધી હું જાણું છું, સામાન્ય કેસ માટે ઑપ્ટિમાઇઝ કરેલ છે. જો તમે સામાન્ય કેસ માટે ઑપ્ટિમાઇઝ કરો છો, તો તેનો અર્થ એ છે કે તે ચોક્કસ કેસ માટે સૌથી વધુ શ્રેષ્ઠ રહેશે નહીં.

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

મારો બીજો પ્રશ્ન છે. InfluxDB થી મૂળભૂત તફાવત શું છે?

ઘણા મૂળભૂત તફાવતો છે. પ્રદર્શન અને મેમરી વપરાશના સંદર્ભમાં, પરીક્ષણોમાં InfluxDB ઉચ્ચ કાર્ડિનલિટી ટાઇમ સિરીઝ માટે 10 ગણો વધુ મેમરી વપરાશ દર્શાવે છે, જ્યારે તમારી પાસે ઘણી બધી હોય છે, ઉદાહરણ તરીકે, લાખો. ઉદાહરણ તરીકે, VictoriaMetrics 1 GB પ્રતિ મિલિયન સક્રિય પંક્તિઓ વાપરે છે, જ્યારે InfluxDB 10 GB વાપરે છે. અને તે એક મોટો તફાવત છે.

બીજો મૂળભૂત તફાવત એ છે કે InfluxDB પાસે વિચિત્ર ક્વેરી લેંગ્વેજ છે - Flux અને InfluxQL. તેઓ સરખામણીમાં સમય શ્રેણી સાથે કામ કરવા માટે ખૂબ અનુકૂળ નથી પ્રોમક્યુએલ, જે VictoriaMetrics દ્વારા સમર્થિત છે. PromQL એ પ્રોમિથિયસની ક્વેરી લેંગ્વેજ છે.

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

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

મારી પાસે એક સ્પષ્ટતા પ્રશ્ન છે. શું હું યોગ્ય રીતે સમજી શક્યો કે તમે જે વિશે વાત કરી હતી તે કોઈ પ્રકારની સમસ્યા હતી કે આ ઊંધી ઇન્ડેક્સ મેમરીમાં બંધબેસતું નથી, તેથી ત્યાં પાર્ટીશન છે?

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

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

હું તરત જ બીજાનો જવાબ આપીશ. અમે હજી તે બિંદુ સુધી પહોંચ્યા નથી. પરંતુ જો જરૂરી હોય તો, અમે ત્યાં પહોંચીશું. અને પ્રથમ, પ્રશ્ન શું હતો?

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

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

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

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

ડેટાને પાર કરવા માટે આપણે કર્સરનો ઉપયોગ કેમ કરતા નથી?

હા.

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

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

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

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

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

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

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

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

અને બીજી વાત એ છે કે VictoriaMetrics, ClickHouseની જેમ, મોટી માત્રામાં કાચા ડેટા પર કામ કરવા માટે ઑપ્ટિમાઇઝ કરવામાં આવે છે, તેથી જો તમારી સિસ્ટમમાં ઘણા બધા કોરો હોય તો તે એક સેકન્ડ કરતાં ઓછા સમયમાં એક અબજ લાઇનને પાવડો કરી શકે છે. વિક્ટોરિયામેટ્રિક્સમાં સ્કેનિંગ ટાઈમ સિરીઝ પોઈન્ટ્સ – 50 પોઈન્ટ પ્રતિ સેકન્ડ પ્રતિ કોર. અને આ પ્રદર્શન હાલના કોરો સુધી માપે છે. એટલે કે, જો તમારી પાસે 000 કોરો છે, ઉદાહરણ તરીકે, તમે પ્રતિ સેકન્ડ એક અબજ પોઇન્ટ સ્કેન કરશો. અને VictoriaMetrics અને ClickHouseની આ મિલકત ડાઉનસેમલિંગની જરૂરિયાત ઘટાડે છે.

બીજી વિશેષતા એ છે કે VictoriaMetrics આ ડેટાને અસરકારક રીતે સંકુચિત કરે છે. ઉત્પાદનમાં સરેરાશ કમ્પ્રેશન 0,4 થી 0,8 બાઇટ્સ પ્રતિ બિંદુ છે. દરેક બિંદુ એ ટાઇમસ્ટેમ્પ + મૂલ્ય છે. અને તે સરેરાશ એક કરતાં ઓછા બાઈટમાં સંકુચિત થાય છે.

સર્ગેઈ. મને એક પ્રશ્ન છે. લઘુત્તમ રેકોર્ડિંગ સમય ક્વોન્ટમ શું છે?

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

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

VictoriaMetrics માં મિલિસેકન્ડની ચોકસાઈ એ DevOps કેસ માટે પણ યોગ્ય છે, અને રિપોર્ટની શરૂઆતમાં મેં ઉલ્લેખ કર્યો છે તે મોટાભાગના કેસ માટે યોગ્ય હોઈ શકે છે. એકમાત્ર વસ્તુ જેના માટે તે યોગ્ય ન હોઈ શકે તે છે ઉચ્ચ આવર્તન ટ્રેડિંગ સિસ્ટમ્સ.

આભાર! અને બીજો પ્રશ્ન. PromQL માં સુસંગતતા શું છે?

સંપૂર્ણ પાછળની સુસંગતતા. VictoriaMetrics સંપૂર્ણપણે PromQL ને સપોર્ટ કરે છે. વધુમાં, તે PromQL માં વધારાની અદ્યતન કાર્યક્ષમતા ઉમેરે છે, જેને કહેવામાં આવે છે મેટ્રિક્સક્યુએલ. આ વિસ્તૃત કાર્યક્ષમતા વિશે YouTube પર ચર્ચા છે. મેં સેન્ટ પીટર્સબર્ગમાં વસંતઋતુમાં મોનિટરિંગ મીટઅપમાં વાત કરી હતી.

ટેલિગ્રામ ચેનલ વિક્ટોરિયામેટ્રિક્સ.

ફક્ત નોંધાયેલા વપરાશકર્તાઓ જ સર્વેમાં ભાગ લઈ શકે છે. સાઇન ઇન કરો, મહેરબાની કરીને.

પ્રોમિથિયસ માટે તમારા લાંબા ગાળાના સ્ટોરેજ તરીકે તમને VictoriaMetrics પર સ્વિચ કરવાથી શું રોકી રહ્યું છે? (ટિપ્પણીઓમાં લખો, હું તેને મતદાનમાં ઉમેરીશ))

• 71,4%હું Prometheus5 નો ઉપયોગ કરતો નથી

• 28,6%VictoriaMetrics2 વિશે ખબર ન હતી

7 વપરાશકર્તાઓએ મતદાન કર્યું. 12 વપરાશકર્તાઓ દૂર રહ્યા.

સોર્સ: www.habr.com