በVictoriaMetrics ውስጥ ወደ ማትባቶች ይሂዱ። አሌክሳንደር ቫልያልኪን

የ2019 መጨረሻ ዘገባውን በአሌክሳንደር ቫልያልኪን “Go optimizations in VictoriaMetrics” የሚለውን ጽሑፍ ለማንበብ ሀሳብ አቀርባለሁ።

ቪክቶሪያ ሜትሪክስ ፈጣን እና ሊሰፋ የሚችል DBMS ውሂብን በጊዜ ተከታታይ መልክ ለማከማቸት እና ለማስኬድ (መዝገብ አንድ ጊዜ እና የእሴቶች ስብስብ ይመሰርታል ፣ ለምሳሌ ፣ በሰንሰሮች ሁኔታ ወቅታዊ የሕዝብ አስተያየት የተገኘ ወይም የመለኪያዎች ስብስብ).

የዚህ ዘገባ ቪዲዮ ሊንክ እነሆ - https://youtu.be/MZ5P21j_HLE

ስላይዶች

ስለራስህ ንገረን, ስለራስሽ ንገሪን. እኔ አሌክሳንደር ቫልያልኪን ነኝ። እዚህ የእኔ github መለያ. ስለ Go እና የአፈጻጸም ማመቻቸት በጣም ጓጉቻለሁ። ብዙ ሁሉንም ዓይነት ጠቃሚ እና ብዙ ቤተ-መጻሕፍት ጻፈ። ወይ ይጀምራሉ fast፣ ወይም ከ ጋር quick ቅድመ ቅጥያ

በአሁኑ ጊዜ በ VictoriaMetrics ላይ እየሰራሁ ነው። ምንድን ነው እና እዚያ ምን እየሰራሁ ነው? በዚህ አቀራረብ ውስጥ ስለዚህ ጉዳይ እናገራለሁ.

የሪፖርቱ ዝርዝር የሚከተለው ነው።

• በመጀመሪያ ቪክቶሪያ ሜትሪክስ ምን እንደሆነ እነግርዎታለሁ።
• ከዚያ ተከታታይ ጊዜ ምን እንደሆነ እነግራችኋለሁ.
• ከዚያም የጊዜ ተከታታይ የውሂብ ጎታ እንዴት እንደሚሰራ እነግርዎታለሁ.
• በመቀጠል, ስለ የውሂብ ጎታ አርክቴክቸር እናገራለሁ-ምን ያካትታል.
• እና ከዚያ በቪክቶሪያ ሜትሪክስ ውስጥ ወደሚገኙ ማመቻቸት እንሂድ። እነዚህ ለተገለበጠው ኢንዴክስ ማመቻቸት እና በ Go ውስጥ ለቢትሴት ትግበራ ማመቻቸት ናቸው።

የቪክቶሪያ ሜትሪክስ ምንድን ነው? ዋው ፣ ብዙ ሰዎች ያውቃሉ። ደስ የሚል ዜና ነው። ለማያውቁት ይህ የመረጃ ቋት የጊዜ ተከታታይ ነው። በአንዳንድ የ ClickHouse አተገባበር ዝርዝሮች ላይ በ ClickHouse architecture ላይ የተመሰረተ ነው። ለምሳሌ፣ በመሳሰሉት ላይ፡- MergeTree፣ ትይዩ ማስላት በሁሉም የሚገኙ ፕሮሰሰር ኮሮች እና በፕሮሰሰር መሸጎጫ ውስጥ በተቀመጡ የውሂብ ብሎኮች ላይ በመስራት አፈፃፀምን ማሻሻል።

ቪክቶሪያሜትሪክስ ከሌሎች የሰዓት ተከታታይ የውሂብ ጎታዎች ጋር ሲወዳደር ምርጡን የመረጃ መጭመቂያ ያቀርባል።

በአቀባዊ ይመዝናል - ማለትም ብዙ ፕሮሰሰሮችን፣ በአንድ ኮምፒውተር ላይ ተጨማሪ ራም ማከል ይችላሉ። VictoriaMetrics እነዚህን ያሉትን ሀብቶች በተሳካ ሁኔታ ይጠቀማል እና የመስመራዊ አፈጻጸምን ያሻሽላል።

እንዲሁም፣ VictoriaMetrics በአግድም ይዛመዳል - ማለትም፣ ተጨማሪ ኖዶችን ወደ VictoriaMetrics ክላስተር ማከል ይችላሉ፣ እና አፈፃፀሙ በመስመር ላይ ማለት ይቻላል ያድጋል።

እንደገመቱት ቪክቶሪያ ሜትሪክስ ፈጣን ዳታቤዝ ነው ምክንያቱም ሌሎችን መጻፍ ስለማልችል ነው። እና በ Go ውስጥ ተጽፏል, ስለዚህ በዚህ ስብሰባ ላይ እያወራሁ ነው.

የጊዜ ተከታታይ ምን እንደሆነ ማን ያውቃል? ብዙ ሰዎችንም ያውቃል። የጊዜ ተከታታይ ተከታታይ ጥንድ ነው። (timestamp, значение)እነዚህ ጥንዶች በጊዜ የተደረደሩበት. ዋጋው ተንሳፋፊ ነጥብ ቁጥር ነው - float64.

እያንዳንዱ ተከታታይ ጊዜ በቁልፍ ተለይቶ ይታወቃል። ይህ ቁልፍ ምንድን ነው? እሱ ባዶ ያልሆነ የቁልፍ-እሴት ጥንዶችን ያካትታል።

የሰዓት ተከታታይ ምሳሌ እዚህ አለ። የዚህ ተከታታይ ቁልፍ የጥንዶች ዝርዝር ነው፡- __name__="cpu_usage" የመለኪያው ስም ነው ፣ instance="my-server" ይህ መለኪያ የሚሰበሰብበት ኮምፒውተር ነው datacenter="us-east" - ይህ ኮምፒዩተር የሚገኝበት የመረጃ ማዕከል ነው።

ሶስት ቁልፍ-እሴት ጥንዶችን ያካተተ የጊዜ ተከታታይ ስም አግኝተናል። ይህ ቁልፍ ከጥንዶች ዝርዝር ጋር ይዛመዳል (timestamp, value). t1, t3, t3, ..., tN የጊዜ ማህተም ናቸው፣ 10, 20, 12, ..., 15 ተጓዳኝ እሴቶች ናቸው. ይህ ለተሰጠው ረድፍ የአሁኑ ሲፒዩ አጠቃቀም ነው።

የጊዜ ተከታታይ የት መጠቀም ይቻላል? ማንም ሀሳብ አለው?

• በ DevOps ውስጥ ሲፒዩ፣ RAM፣ ኔትወርክ፣ ራፕስ፣ ስህተቶች፣ ወዘተ መለካት ይችላሉ።
• IoT - የሙቀት መጠን, ግፊት, የጂኦ መጋጠሚያዎች እና ሌላ ነገር መለካት እንችላለን.
• እንዲሁም ፋይናንስ - ለሁሉም ዓይነት አክሲዮኖች እና ምንዛሬዎች ዋጋዎችን መከታተል እንችላለን።
• በተጨማሪም, በፋብሪካዎች ውስጥ የምርት ሂደቶችን በመከታተል ውስጥ የጊዜ ተከታታይን መጠቀም ይቻላል. ለሮቦቶች የንፋስ ተርባይኖችን ለመቆጣጠር VictoriaMetrics የሚጠቀሙ ተጠቃሚዎች አሉን።
• እንዲሁም፣ የጊዜ ተከታታይ ከተለያዩ መሳሪያዎች ዳሳሾች መረጃን ለመሰብሰብ ጠቃሚ ናቸው። ለምሳሌ, ለኤንጂኑ; የጎማውን ግፊት ለመለካት; ፍጥነትን, ርቀትን ለመለካት; የነዳጅ ፍጆታን ለመለካት, ወዘተ.
• እንዲሁም, የጊዜ ተከታታይ አውሮፕላኖችን ለመቆጣጠር ጥቅም ላይ ሊውል ይችላል. እያንዳንዱ አውሮፕላን ለተለያዩ የአውሮፕላኖች ጤና መለኪያዎች የጊዜ ተከታታይን የሚሰበስብ ጥቁር ሳጥን አለው። በኤሮስፔስ ኢንደስትሪ ውስጥም የሰዓት ተከታታይ ስራ ላይ ይውላል።
• የጤና እንክብካቤ የደም ግፊት, የልብ ምት, ወዘተ.

ምናልባት አሁንም የረሳኋቸው አፕሊኬሽኖች ሊኖሩ ይችላሉ ፣ ግን የጊዜ ተከታታይ በዘመናዊው ዓለም ውስጥ በንቃት ጥቅም ላይ እንደሚውል እንደምትረዱ ተስፋ አደርጋለሁ ። እና አጠቃቀማቸው በየዓመቱ እያደገ ነው.

የጊዜ ተከታታይ የውሂብ ጎታ ምንድን ነው? የጊዜ ተከታታይን ለማከማቸት መደበኛ የግንኙነት ዳታቤዝ ለምን መጠቀም አይችሉም?

ምክንያቱም ተከታታይ ጊዜዎች በተለመደው የመረጃ ቋቶች ውስጥ ለማከማቸት እና ለማስኬድ አስቸጋሪ የሆኑ ብዙ መረጃዎችን ይይዛሉ። ስለዚህ, ለጊዜ ተከታታይ ልዩ የውሂብ ጎታዎች ታየ. እነዚህ መሰረቶች ውጤታማ ነጥቦችን ያከማቻሉ (timestamp, value) በተሰጠው ቁልፍ. የተከማቸ ውሂብን በቁልፍ፣ በአንድ ቁልፍ እሴት ጥንድ ወይም በብዙ ጥንዶች ወይም በ regexp ለማንበብ ኤፒአይ ይሰጣሉ። ለምሳሌ የሁሉም አገልግሎቶችዎን የሲፒዩ ጭነት በአሜሪካ ውስጥ ባለው የመረጃ ማእከል ውስጥ ማግኘት ይፈልጋሉ፣ ከዚያ ይህን የውሸት መጠይቅ መጠቀም ያስፈልግዎታል።

በተለምዶ፣ የጊዜ ተከታታይ የውሂብ ጎታዎች ልዩ የመጠይቅ ቋንቋዎች ናቸው ምክንያቱም SQL ለጊዜ ተከታታይነት በጣም ተስማሚ ስላልሆነ። SQL ን የሚደግፉ የውሂብ ጎታዎች ቢኖሩም, በጣም ጥሩ ተስማሚ አይደለም. የተሻሉ ተስማሚ የጥያቄ ቋንቋዎች PromQL, InfluxQL, የማያቋርጥ, 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) ints ለመቁረጥ ገመዱን ካርታ ያደርገዋል። መስመሩ ይዟል label=value.

የተግባር ትግበራ: ማግኘት metricIDs ለመጀመሪያው label=value, ከዚያም በቀሩት ሁሉ ይሂዱ label=value, እናገኛለን metricIDs ለእነርሱ. እና ተግባሩን ይደውሉ intersectInts, ይህም ከዚህ በታች ይብራራል. እና ይህ ተግባር የእነዚህን ዝርዝሮች መገናኛ ይመልሳል.

እንደምታየው, የተገላቢጦሽ ኢንዴክስ አተገባበር በጣም የተወሳሰበ አይደለም. ይህ ግን የዋህነት አተገባበር ነው። ጉድለቶቿ ምንድን ናቸው? የናቭ አተገባበር ዋነኛው መሰናክል እንዲህ ያለውን የተገለበጠ ኢንዴክስ በ RAM ውስጥ ማከማቸት ነው። ማመልከቻውን እንደገና ከጀመርን በኋላ, ይህንን መረጃ ጠቋሚ እናጣለን. ይህንን መረጃ ጠቋሚ ወደ ዲስክ ማስቀመጥ የለም። ለዳታቤዝ፣ እንዲህ ያለው የተገለበጠ መረጃ ጠቋሚ እምብዛም ተስማሚ አይደለም።

ሁለተኛው ጉዳት ከማስታወስ ጋር የተያያዘ ነው. የተገለበጠ መረጃ ጠቋሚ በ RAM ውስጥ መመጣጠን አለበት። ከ RAM መጠን በላይ ከሆነ, እኛ እንደምናገኝ ግልጽ ነው - ከማስታወሻ ስህተት. እና ፕሮግራሙ አይሰራም.

ይህ ችግር እንደ ዝግጁ የሆኑ መፍትሄዎችን በመጠቀም ሊፈታ ይችላል ደረጃ ዲቢ, ወይም ሮክ ዲቢ.

ባጭሩ ሶስት ነገሮችን በፍጥነት ለመስራት የሚያስችል ዳታቤዝ ያስፈልገናል።

• የመጀመሪያው ክዋኔ በመጻፍ ላይ ነው ключ-значение ወደዚህ መሠረት። ይህንንም በፍጥነት ታደርጋለች። ключ-значение የዘፈቀደ ሕብረቁምፊዎች ናቸው።
• ሁለተኛው ክዋኔ በተሰጠው ቁልፍ ፈጣን ፍለጋ ነው።
• እና ሶስተኛው ክዋኔ በተሰጠው ቅድመ ቅጥያ ለሁሉም ዋጋዎች ፈጣን ፍለጋ ነው.

LevelDB እና RocksDB - እነዚህ የመረጃ ቋቶች በGoogle እና በፌስቡክ የተገነቡ ናቸው። መጀመሪያ ደረጃ የመጣው LevelDB። ከዚያ የፌስቡክ ሰዎች LevelDB ወስደው ማሻሻል ጀመሩ ሮክስ ዲቢን ሠሩ። አሁን ሁሉም ማለት ይቻላል የውስጥ ዳታቤዝ ወደ RocksDB እና MySQL የተዘዋወሩትን ጨምሮ በፌስቡክ ውስጥ በRocksDB ላይ ይሰራሉ። ብለው ሰይመውታል። myrocks.

የተገለበጠ መረጃ ጠቋሚ LevelDB በመጠቀም ሊተገበር ይችላል። እንዴት ማድረግ ይቻላል? እንደ ቁልፍ እንቆጥባለን label=value. እና እንደ እሴት - የጊዜ ተከታታይ መለያ, ጥንድ ባለበት label=value.

ከዚህ ጥንድ ጋር ብዙ ተከታታይ ጊዜ ካለን label=value, ከዚያ በዚህ የውሂብ ጎታ ውስጥ አንድ አይነት ቁልፍ ያላቸው እና የተለያዩ ብዙ ረድፎች ይኖራሉ timeseries_ids. የሁሉንም ዝርዝር ለማግኘት timeseries_idsበዚህ የሚጀምሩት። label=prefixይህ ዳታቤዝ የተመቻቸበትን የክልል ቅኝት እናደርጋለን። ማለትም የሚጀምሩትን ሁሉንም መስመሮች እንመርጣለን label=prefix እና አስፈላጊውን ያግኙ timeseries_ids.

በGo ውስጥ ምን እንደሚመስል የሚያሳይ ምሳሌ እዚህ አለ። የተገለበጠ መረጃ ጠቋሚ አለን። ይህ LevelDB ነው።

ተግባሩ ከናቭ ትግበራ ጋር ተመሳሳይ ነው። በመስመር ከሞላ ጎደል የዋህ አተገባበርን ይደግማል። ብቸኛው ነጥብ ከመጥቀስ ይልቅ map የተገለበጠውን ኢንዴክስ እንጠቅሳለን። ሁሉንም ዋጋዎች ለመጀመሪያ ጊዜ እናገኛለን label=value. ከዚያም ሁሉንም የቀሩትን ጥንዶች እናልፋለን label=value እና ለእነሱ ተዛማጅ የሆኑ የmetricIDs ስብስቦችን ያግኙ። ከዚያም መገናኛውን እናገኛለን.

ሁሉም ነገር ጥሩ ይመስላል, ግን ይህ መፍትሔ ድክመቶች አሉት. VictoriaMetrics በመጀመሪያ ደረጃ በLevelDB ላይ የተመሰረተ የተገለበጠ መረጃ ጠቋሚን ተግባራዊ አድርጓል። በመጨረሻ ግን መተው ነበረብኝ።

ለምን? ምክንያቱም LevelDB ከዋህ ትግበራ ቀርፋፋ ነው። በቀላል አተገባበር ውስጥ ፣ ለተወሰነ ቁልፍ ፣ ወዲያውኑ ሙሉውን ቁራጭ እናገኛለን metricIDs. ይህ በጣም ፈጣን ቀዶ ጥገና ነው - ሙሉው ቁራጭ ለአገልግሎት ዝግጁ ነው.

በLevelDB፣ በእያንዳንዱ የተግባር ጥሪ ላይ GetValues የሚጀምሩትን ሁሉንም መስመሮች ማለፍ ያስፈልግዎታል label=value. እና ለእያንዳንዱ መስመር ዋጋውን ያግኙ timeseries_ids. ከእንደዚህ timeseries_ids ከእነዚህ ውስጥ አንድ ቁራጭ ይሰብስቡ timeseries_ids. ግልጽ ነው፣ ይህ መደበኛ ካርታን በቁልፍ ከመጠቀም በጣም ቀርፋፋ ነው።

ሁለተኛው ጉዳቱ LevelDB የተፃፈው በ C ነው። C ተግባራትን ከ Go መድረስ በጣም ፈጣን አይደለም። በመቶዎች የሚቆጠሩ ናኖሴኮንዶች ይወስዳል። ይህ በጣም ፈጣን አይደለም, ምክንያቱም በጉዞ ውስጥ ከተጻፈ መደበኛ የተግባር ጥሪ ጋር ሲነጻጸር, 1-5 nanoseconds ይወስዳል, የአፈፃፀም ልዩነት በደርዘን የሚቆጠሩ ጊዜ ነው. ለ VictoriaMetrics፣ ይህ ገዳይ ጉድለት ነበር 🙂

ስለዚህ የተገለበጠውን ኢንዴክስ የራሴን አተገባበር ጻፍኩ። ጠራዋትም። ውህደት.

ውህደት በMergeTree ውሂብ መዋቅር ላይ የተመሰረተ ነው። ይህ የውሂብ መዋቅር ከ ClickHouse ተበድሯል። ለፈጣን መልሶ ማግኛ ውህደት ማመቻቸት እንደሚያስፈልግ ግልጽ ነው። timeseries_ids በተሰጠው ቁልፍ. Mergeset ሙሉ በሙሉ በGo ውስጥ ተጽፏል። ማየት ትችላለህ የ VictoriaMetrics ምንጮች በ GitHub ላይ. የማዋሃድ አተገባበር በአቃፊው ውስጥ ነው። /lib/መዋሃድ. እዚያ ምን እየተፈጠረ እንዳለ ለማወቅ መሞከር ይችላሉ.

የውህደት ኤፒአይ ከLevelDB እና RocksDB ጋር በጣም ተመሳሳይ ነው። ያም ማለት እዚያ አዳዲስ መዝገቦችን በፍጥነት እንዲያስቀምጡ እና በፍጥነት በተሰጠው ቅድመ ቅጥያ መዝገቦችን እንዲመርጡ ያስችልዎታል.

ስለ ውህደት ጉዳቶች በኋላ እንነጋገራለን ። አሁን የተገለበጠውን ኢንዴክስ በሚተገበርበት ጊዜ በቪክቶሪያ ሜትሪክስ ምርት ውስጥ ስላሉት ችግሮች እንነጋገር ።

ለምን ተነሱ?

የመጀመሪያው ምክንያት ከፍተኛ የችኮላ መጠን ነው. ወደ ሩሲያኛ ተተርጉሟል, ይህ በጊዜ ተከታታይ ውስጥ ተደጋጋሚ ለውጥ ነው. ይህ ተከታታይ የሰዓት ተከታታዮች ሲያልቅ እና አዲስ ተከታታዮች ሲጀምሩ ወይም ብዙ አዲስ ተከታታይ የሰዓት ተከታታይ ሲጀምሩ ነው። እና ይሄ ብዙ ጊዜ ይከሰታል.

ሁለተኛው ምክንያት ብዙ ቁጥር ያለው የጊዜ ቅደም ተከተል ነው. መጀመሪያ ላይ, ክትትል ተወዳጅነት ሲያገኝ, ተከታታይ የጊዜ ብዛት አነስተኛ ነበር. ለምሳሌ በእያንዳንዱ ኮምፒዩተር ላይ የማቀነባበሪያውን፣ የማህደረ ትውስታውን፣ የኔትወርክን እና የዲስክን ጭነት መከታተል ያስፈልግዎታል። በአንድ ኮምፒውተር 4 ጊዜ ተከታታይ። 100 ኮምፒውተሮች እና 400 ተከታታይ ጊዜያት አሉህ እንበል። ይህ በጣም ትንሽ ነው.

ከጊዜ በኋላ ሰዎች የበለጠ ዝርዝር መረጃ ሊለካ ይችላል የሚል ሀሳብ አቅርበዋል. ለምሳሌ, የሙሉውን ፕሮሰሰር ጭነት ሳይሆን የእያንዳንዱን ፕሮሰሰር ኮር በተናጠል ለመለካት. 40 ፕሮሰሰር ኮሮች ካሉዎት፣ በዚህ መሰረት፣ የአቀነባባሪውን ጭነት ለመለካት 40 እጥፍ ተጨማሪ ተከታታይ ጊዜ አለዎት።

ግን ያ ብቻ አይደለም። እያንዳንዱ ፕሮሰሰር ኮር ስራ ሲፈታ እንደ ስራ ፈት ያሉ በርካታ ግዛቶች ሊኖሩት ይችላል። እንዲሁም በተጠቃሚ ቦታ ላይ በመስራት, በከርነል ቦታ እና በሌሎች ግዛቶች ውስጥ ይስሩ. እና እያንዳንዱ እንደዚህ አይነት ሁኔታ እንደ የተለየ የጊዜ ተከታታይነት ሊለካ ይችላል. ይህ በተጨማሪ የረድፎችን ብዛት በ7-8 ጊዜ ይጨምራል።

ከአንድ መለኪያ ለአንድ ኮምፒውተር ብቻ 40 x 8 = 320 ሜትሪክ አግኝተናል። በ100 እናባዛለን፣ ከ32 ይልቅ 000 እናገኛለን።

ከዚያ ኩበርኔትስ መጣ። እና አሁንም የበለጠ የከፋ እንዲሆን አድርጎታል, ምክንያቱም ብዙ የተለያዩ አገልግሎቶች በኩበርኔትስ ውስጥ ሊስተናገዱ ይችላሉ. በኩበርኔትስ ውስጥ ያለው እያንዳንዱ አገልግሎት ከብዙ ፖድሎች የተሰራ ነው። እና ይህ ሁሉ ክትትል ሊደረግበት ይገባል. በተጨማሪም፣ አዲስ የአገልግሎቶችዎ ስሪቶች በቋሚነት መሰማራት አለን። ለእያንዳንዱ አዲስ ስሪት አዲስ ተከታታይ ጊዜ መፍጠር ያስፈልግዎታል። በውጤቱም, የሰዓት ተከታታይ ቁጥር በከፍተኛ ደረጃ ያድጋል እና ከፍተኛ-ካርዲኒቲ ተብሎ የሚጠራው ብዙ ቁጥር ያለው የጊዜ ችግር ያጋጥመናል. ቪክቶሪያ ሜትሪክስ ከሌሎች የጊዜ ተከታታይ የውሂብ ጎታዎች ጋር ሲወዳደር ጥሩ ያደርገዋል።

የከፍተኛ ፍጥነት መጨመርን ጠለቅ ብለን እንመርምር። በምርት ውስጥ ከፍተኛ የፍጥነት መጠን እንዲጨምር የሚያደርገው ምንድን ነው? ምክንያቱም አንዳንድ የመለያዎች እና መለያዎች ትርጉም በየጊዜው እየተለወጡ ነው።

ለምሳሌ ኩበርኔትስን እንውሰድ፣ እሱም ጽንሰ-ሀሳቡ አለው። deploymentማለትም አዲስ የመተግበሪያዎ ስሪት ሲለቀቅ። በሆነ ምክንያት የኩበርኔትስ ገንቢዎች የማሰማራት መታወቂያውን ወደ መለያው ለመጨመር ወሰኑ።

ምን አመጣው? በእያንዳንዱ አዲስ ማሰማራቱ ሁሉም የቆዩ ተከታታይ ጊዜዎች ይቋረጣሉ እና በእነሱ ምትክ አዲስ የሰዓት ተከታታይ በአዲስ መለያ እሴት ይጀምራል። deployment_id. በመቶ ሺዎች እና እንዲያውም በሚሊዮኖች የሚቆጠሩ እንደዚህ ያሉ ረድፎች ሊኖሩ ይችላሉ.

የዚህ ሁሉ አስፈላጊ ገጽታ የጠቅላላው የጊዜ ተከታታይ ቁጥር እያደገ ነው, ነገር ግን በአሁኑ ጊዜ ንቁ የሆኑ ተከታታይ ጊዜዎች ብዛት, መረጃው እየመጣ ነው, ቋሚ ነው. ይህ ሁኔታ ከፍተኛ የችኮላ መጠን ይባላል.

የከፍተኛ የፍጥነት መጠን ዋናው ችግር ለተወሰነ የጊዜ ልዩነት ለተወሰነ ጊዜ የመለያዎች ስብስብ ለሁሉም ጊዜዎች የማያቋርጥ የፍለጋ ፍጥነት ማቅረብ ነው። ይህ አብዛኛውን ጊዜ የመጨረሻው ሰዓት ወይም የመጨረሻው ቀን የጊዜ ክፍተት ነው.

ይህንን ችግር እንዴት መፍታት ይቻላል? የመጀመሪያው አማራጭ ይኸውና. ይህ የተገለበጠውን ኢንዴክስ በጊዜ ሂደት ወደ ገለልተኛ ክፍሎች ለመከፋፈል ነው. ማለትም፣ የተወሰነ የጊዜ ክፍተት ያልፋል፣ ከተገለበጠው የአሁኑ ኢንዴክስ ጋር መስራት እንጨርሰዋለን። እና አዲስ የተገለበጠ ኢንዴክስ እንፈጥራለን. ሌላ የጊዜ ክፍተት ያልፋል, ሌላ አንድ እና ሌላ እንፈጥራለን.

እና ከእነዚህ የተገለበጡ ኢንዴክሶች ናሙና ስንወስድ፣ በተሰጠው የጊዜ ክፍተት ውስጥ የሚወድቁ የተገለበጡ ኢንዴክሶችን እናገኛለን። እና, በዚህ መሠረት, ከዚያ ውስጥ የሰዓት ተከታታዮችን መታወቂያ እንመርጣለን.

ይህ ሀብቶችን ይቆጥባል ምክንያቱም በተሰጠው የጊዜ ክፍተት ውስጥ የማይወድቁ ክፍሎችን መመልከት ስለሌለብን. ይህም ማለት፣ አብዛኛውን ጊዜ፣ ለመጨረሻው ሰዓት ውሂብ ከመረጥን፣ ከዚያ ለቀደመው የጊዜ ክፍተቶች ጥያቄዎችን እንዘለላለን።

ለዚህ ችግር ሌላ መፍትሄ አለ. ይህ ለእያንዳንዱ ቀን የተለየ የመታወቂያ ጊዜ ዝርዝር በእለቱ ተከስቶ ለማከማቸት ነው።

የዚህ መፍትሄ ጥቅሙ ከቀደመው መፍትሄ ይልቅ በጊዜ ሂደት የማይጠፋውን የሰአት ተከታታይ መረጃ አለማባዛታችን ነው። እነሱ ቋሚ ናቸው እና አይለወጡም.

ጉዳቱ እንዲህ ዓይነቱ መፍትሔ ለመተግበር በጣም አስቸጋሪ እና ለማረም በጣም አስቸጋሪ ነው. እና ቪክቶሪያ ሜትሪክስ ይህንን መፍትሄ መርጦታል. በታሪክ እንዲህ ሆነ። ይህ መፍትሔ ከቀዳሚው ጋር ሲነጻጸር እራሱን በደንብ ያሳያል. ምክንያቱም ይህ መፍትሔ አልተተገበረም ምክንያቱም በእያንዳንዱ ክፍልፋዮች ውስጥ የማይለዋወጡትን ማለትም በጊዜ ሂደት የማይጠፉ መረጃዎችን ማባዛት ስላለባችሁ ነው። ቪክቶሪያ ሜትሪክስ በዋናነት ለዲስክ ቦታ ፍጆታ የተመቻቸ ነበር፣ እና የቀደመው ትግበራ የዲስክ ቦታ ፍጆታን አባብሶታል። ነገር ግን ይህ አተገባበር የዲስክ ቦታን ፍጆታ ለመቀነስ የተሻለ ነው, ስለዚህ ተመርጧል.

እሷን መታገል ነበረብኝ። ትግሉ በዚህ ትግበራ ውስጥ አሁንም በጣም ትልቅ ቁጥር መምረጥ ያስፈልግዎታል timeseries_ids የተገላቢጦሽ ኢንዴክስ በጊዜ ከተከፋፈለ ይልቅ ለመረጃ።

ይህንን ችግር እንዴት ፈታነው? እኛ ኦሪጅናል በሆነ መንገድ ፈትነናል - ከአንድ ለዪ ይልቅ በተገለበጠው ኢንዴክስ በእያንዳንዱ መዝገብ ውስጥ ብዙ ጊዜ ተከታታይ መለያዎችን በማከማቸት። ማለትም ቁልፉ አለን። label=valueበእያንዳንዱ ተከታታይ ጊዜ ውስጥ የሚከሰት. እና አሁን ጥቂቶቹን እናስቀምጣለን timeseries_ids በአንድ ግቤት ውስጥ.

አንድ ምሳሌ እዚህ አለ። ቀድሞ N መግባቶች ነበሩን፣ እና አሁን ልክ እንደሌሎቹ ሁሉ ተመሳሳይ ቅድመ ቅጥያ ያለው አንድ ግቤት አለን። ለቀደመው ግቤት እሴቱ ሁሉንም የጊዜ ተከታታይ መታወቂያዎችን ይይዛል።

ይህም እንዲህ ዓይነቱን የተገለበጠ መረጃ ጠቋሚ የፍተሻ ፍጥነት እስከ 10 ጊዜ ለመጨመር አስችሏል. እና ለመሸጎጫ ማህደረ ትውስታ ፍጆታ እንዲቀንስ ተፈቅዶለታል, ምክንያቱም አሁን ገመዱን እናከማቻለን label=value በመሸጎጫው ውስጥ አንድ ጊዜ ብቻ N ጊዜዎች. እና ኩበርኔትስ እዚያ መጎተት በሚወዳቸው መለያዎች እና መለያዎች ውስጥ የተከማቹ ረጅም መስመሮች ካሉዎት ይህ መስመር ትልቅ ሊሆን ይችላል።

የተገላቢጦሽ ኢንዴክስ ፍለጋን ለማፋጠን ሌላው አማራጭ ማጭበርበር ነው። ከአንድ ይልቅ ብዙ የተገለበጠ ኢንዴክሶችን መፍጠር እና በመካከላቸው ውሂብ በቁልፍ መጋራት። ይህ ስብስብ ነው። key=value እንፋሎት. ማለትም፣ በበርካታ ፕሮሰሰሮች ላይ በትይዩ መመርመር የምንችላቸውን በርካታ ገለልተኛ የተገለበጠ ኢንዴክሶች እናገኛለን። የቀደሙ ትግበራዎች የተፈቀደላቸው ነጠላ ፕሮሰሰር ሁነታን ብቻ ነው፣ ማለትም በአንድ ኮር ላይ ውሂብን መቃኘት። ክሊክ ሃውስ ማድረግ እንደሚወደው ይህ መፍትሄ በአንድ ጊዜ በተለያዩ ኮሮች ላይ መረጃን ለመቃኘት ያስችልዎታል። ተግባራዊ ለማድረግ ያቀድነው ይህንን ነው።

እና አሁን ወደ ራሞቻችን ተመለስ - ወደ መገናኛው ተግባር timeseries_ids. አተገባበር ምን ሊሆን እንደሚችል እናስብ። ይህ ተግባር እንዲያገኙ ያስችልዎታል timeseries_ids ለተሰጠው ስብስብ label=value.

የመጀመሪያው አማራጭ የዋህ አተገባበር ነው። ሁለት የጎጆ ቀለበቶች። እዚህ በተግባሩ ግቤት ላይ እናገኛለን intersectInts ሁለት ቁርጥራጮች - a и b. በውጤቱ ላይ, የእነዚህን ቁርጥራጮች መገናኛ ወደ እኛ መመለስ አለበት.

የዋህ አተገባበሩ ይህን ይመስላል። ሁሉንም ዋጋዎች ከቁራጭ እንደግመዋለን aበዚህ loop ውስጥ ሁሉንም የቁራጭ እሴቶችን እናልፋለን። b. እና እናነፃፅራቸዋለን። እነሱ የሚዛመዱ ከሆነ, እኛ መገናኛ አግኝተናል. እና አስቀምጠው result.

ጉዳቶቹ ምንድን ናቸው? ኳድራቲክ ውስብስብነት ዋነኛው ጉዳቱ ነው። ለምሳሌ ፣ የተቆራረጡ ልኬቶች ካሉዎት a и b እያንዳንዳቸው አንድ ሚሊዮን ፣ ከዚያ ይህ ተግባር በጭራሽ ለእርስዎ መልስ አይሰጥም። ምክንያቱም አንድ ትሪሊዮን ድግግሞሾችን ማድረግ ያስፈልገዋል, ይህም ለዘመናዊ ኮምፒተሮች እንኳን በጣም ብዙ ነው.

ሁለተኛው ትግበራ በካርታው ላይ የተመሰረተ ነው. ካርታ እየፈጠርን ነው። ሁሉንም ዋጋዎች በዚህ ካርታ ውስጥ ከተቆራረጡ እናስቀምጣለን a. ከዚያም በተለየ ዑደት ውስጥ በቆርቆሮ እንሮጣለን b. እና ይህ ዋጋ ከቁራጭ መሆኑን ያረጋግጡ b በካርታው ውስጥ. ካለ, ከዚያም ወደ ውጤቱ ያክሉት.

ጥቅሞቹ ምንድ ናቸው? ጥቅሙ የመስመር ውስብስብነት ብቻ ነው. ያም ማለት ተግባሩ ለትላልቅ ቁርጥራጮች በጣም ፈጣን ይሆናል. ለአንድ ሚሊዮንኛ ቁራጭ ይህ ተግባር በ 2 ሚሊዮን ድግግሞሾች ውስጥ ይሰራል ፣ ከትሪሊዮን ድግግሞሾች በተቃራኒ ፣ እንደ ቀድሞው ተግባር።

እና ጉዳቱ ይህንን ካርታ ለመፍጠር ይህ ተግባር ተጨማሪ ማህደረ ትውስታን ይፈልጋል።

ሁለተኛው ጉዳቱ ለሃሺንግ ትልቅ ወጪ ነው። ይህ ጉድለት በጣም ግልጽ አይደለም. እና ለእኛ ፣ እንዲሁ በጣም ግልፅ አልነበረም ፣ ስለሆነም በመጀመሪያ በቪክቶሪያ ሜትሪክስ የመስቀለኛ መንገድ አተገባበር በካርታ ነበር። ነገር ግን ፕሮፋይል ማድረግ ዋናው ፕሮሰሰር ጊዜ የሚያሳልፈው በካርታው ላይ ለመፃፍ እና በዚህ ካርታ ውስጥ ያለውን እሴት ለመፈተሽ ነው።

ለምንድን ነው እነዚህ ቦታዎች የሲፒዩ ጊዜ የሚያባክኑት? ምክንያቱም በእነዚህ መስመሮች ውስጥ ሂድ የሃሺንግ ኦፕሬሽን ይሰራል። ማለትም በሃሽማፕ በተሰጠው ኢንዴክስ በኋላ ለማግኘት ሃሽውን ከቁልፍ ያሰላል። የሃሽ ስሌት ክዋኔው በአስር ናኖሴኮንዶች ይወስዳል። ይህ ለ VictoriaMetrics ቀርፋፋ ነው።

በተለይ ለዚህ ጉዳይ የተመቻቸ ቢትሴትን ለመተግበር ወሰንኩ። አሁን የሁለቱ ቁርጭምጭሚቶች መገናኛ ይህን ይመስላል። እዚህ ቢትሴት እንፈጥራለን. ከመጀመሪያው ቁራጭ ላይ ንጥረ ነገሮችን እንጨምራለን. ከዚያም እነዚህን ንጥረ ነገሮች በሁለተኛው ቁራጭ ውስጥ መኖራቸውን እናረጋግጣለን. እና ወደ ውጤቱ ያክሏቸው. ማለትም ከቀዳሚው ምሳሌ አይለይም ማለት ይቻላል። ብቸኛው ነገር የካርታ ጥሪውን እዚህ በብጁ ተግባራት መተካታችን ነው። add и has.

በቅድመ-እይታ ፣ መደበኛ ካርታው ከዚህ በፊት ጥቅም ላይ ከዋለ እና ከዚያ አንዳንድ ሌሎች ተግባራት ከተጠሩ ይህ በዝግታ መስራት ያለበት ይመስላል ፣ ግን መገለጫው ይህ ነገር ለ VictoriaMetrics ጉዳይ ከመደበኛ ካርታ በ 10 እጥፍ ፈጣን መሆኑን ያሳያል ።

በተጨማሪም, ከካርታው አተገባበር ጋር ሲነፃፀር በጣም ያነሰ ማህደረ ትውስታን ይጠቀማል. ምክንያቱም ከስምንት ባይት እሴቶች ይልቅ ቢት እዚህ እናከማቻለን::

የዚህ ዓይነቱ አተገባበር ጉዳቱ በጣም ግልጽ አለመሆኑ ነው, ቀላል አይደለም.

ብዙዎች ሊያስተውሉ የማይችሉት ሌላው ጉዳት ይህ ትግበራ በአንዳንድ ሁኔታዎች ጥሩ ላይሰራ ይችላል. ያም ማለት፣ ለተወሰነ ጉዳይ ተመቻችቷል፣ ለዚህ ​​ጉዳይ የቪክቶሪያሜትሪክስ የጊዜ ተከታታይ መታወቂያዎች መገናኛ። ይህ ማለት ለሁሉም ጉዳዮች ተስማሚ ነው ማለት አይደለም. በስህተት ጥቅም ላይ ከዋለ የአፈጻጸም መጨመር ሳይሆን የማስታወስ ችሎታ ስህተት እና የአፈጻጸም መቀዛቀዝ አናገኝም።

የዚህን መዋቅር አተገባበር አስቡበት. ሊያዩት ከፈለጉ በቪክቶሪያ ሜትሪክስ ምንጮች፣ በአቃፊው ውስጥ ነው። lib/uint64set. በተለይ ለቪክቶሪያሜትሪክስ ጉዳይ ተመቻችቷል፣ የት timeseries_id የመጀመሪያዎቹ 64 ቢት በመሠረቱ ቋሚ እና የመጨረሻዎቹ 32 ቢት ብቻ የሚቀየሩበት ባለ 32-ቢት እሴት ነው።

ይህ የውሂብ መዋቅር በዲስክ ላይ አይከማችም, በማህደረ ትውስታ ውስጥ ብቻ ይሰራል.

የእሱ ኤ ፒ አይ ነው። በጣም የተወሳሰበ አይደለም. ኤፒአይው በተለይ ለቪክቶሪያሜትሪክስ የአጠቃቀም ጉዳይ የተዘጋጀ ነው። ማለትም ምንም ተጨማሪ ተግባራት የሉም። በ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 የመታወቂያ ዋጋ በክፍል ቢት እንዲሁ bitmask. ይህ ለዚህ 64-ቢት እሴት ጭንብል ነው፣ በዚህም የዚህን ቢት መኖር ማረጋገጥ ወይም ማዋቀር ይችላሉ። ይህ ቢት መዘጋጀቱን እና እንዳቀናበረው እና መገኘቱን እንመልሳለን። የኛ አተገባበር ይኸውና፣ ይህም ከመደበኛ ካርታዎች ጋር ሲነፃፀር የመሻገሪያ መታወቂያዎችን በ10 ጊዜ ለማፋጠን አስችሎናል።

ከዚህ ማመቻቸት በተጨማሪ ቪክቶሪያሜትሪክስ ሌሎች ብዙ ማሻሻያዎች አሉት። አብዛኛዎቹ እነዚህ ማሻሻያዎች በአንድ ምክንያት ተጨምረዋል ፣ ግን በምርት ውስጥ ያለውን ኮድ ከገለጹ በኋላ።

ይህ ዋናው የማመቻቸት ህግ ነው - ማነቆ ሊኖር እንደሚችል በማሰብ ማመቻቸትን አይጨምሩ, ምክንያቱም ማነቆ ሊኖር አይችልም. ማመቻቸት አብዛኛውን ጊዜ የኮዱን ጥራት ይቀንሳል. ስለዚህ ይህ ትክክለኛ መረጃ እንዲሆን ከገለፃ በኋላ እና በተለይም በምርት ውስጥ ማመቻቸት ጠቃሚ ነው ። ፍላጎት ላላቸው፣ የ VictoriaMetrics ምንጭ ኮድን መመልከት እና እዚያ ያሉትን ሌሎች ማሻሻያዎችን ማሰስ ይችላሉ።

ስለ ቢትሴት ጥያቄ አለኝ። ከ C++ የቬክተር ቡል አተገባበር ጋር በጣም ተመሳሳይ፣ ቢትሴት ተመቻችቷል። አተገባበሩን ከዚያ ወስደዋል?

የለም፣ ከዚያ አይደለም። ይህንን ቢትሴት ስተገበር፣ በቪክቶሪያሜትሪክስ ውስጥ ጥቅም ላይ በሚውሉት የ ids timeseries አወቃቀር እውቀት ተመርቻለሁ። እና የእነሱ መዋቅር ከፍተኛዎቹ 32 ቢት በመሠረቱ ቋሚ ናቸው. የታችኛው 32 ቢት ሊለወጡ ይችላሉ። ትንሽ ትንሽ, ብዙ ጊዜ ሊለወጥ ይችላል. ስለዚህ, ይህ አተገባበር ለዚህ የውሂብ መዋቅር የተመቻቸ ነው. እኔ እስከማውቀው ድረስ የC++ ትግበራ ለአጠቃላይ ጉዳይ የተመቻቸ ነው። ለአጠቃላይ ጉዳይ ማመቻቸትን ካደረጉ, ይህ ማለት ለአንድ የተወሰነ ጉዳይ በጣም ጥሩ አይሆንም ማለት ነው.

የአሌሴይ ሚሎቪድ ዘገባ እንድትመለከቱ እመክራችኋለሁ. ከአንድ ወር ገደማ በፊት, በ ClickHouse ውስጥ ለተወሰኑ ስፔሻሊስቶች ስለ ማመቻቸት ተናግሯል. እሱ በጥቅሉ ሲታይ የC ++ ትግበራ ወይም ሌላ ትግበራ በአማካይ በሆስፒታል ውስጥ ለጥሩ ስራ የተበጀ ነው ይላል። የላይኛው 32 ቢት ባብዛኛው ቋሚ መሆናቸውን ስናውቅ እንደእኛ ለተለየ እውቀት ከተለየ ትግበራ የከፋ ሊፈጽም ይችላል።

ሁለተኛ ጥያቄ አለኝ። ከ InfluxDB መሠረታዊ ልዩነት ምንድን ነው?

ብዙ ካርዲናል ልዩነቶች አሉ. በአፈጻጸም እና በማህደረ ትውስታ ፍጆታ ከሆነ፣ በፈተናዎች ውስጥ InfluxDB 10 እጥፍ የበለጠ የማህደረ ትውስታ ፍጆታ ለከፍተኛ ካርዲናሊቲ ጊዜ ተከታታይ፣ ብዙ ሲኖሮት ለምሳሌ በሚሊዮን የሚቆጠሩ። ለምሳሌ፣ VictoriaMetrics 1 ጂቢ በሚሊዮን ንቁ ረድፎችን ይጠቀማል፣ InfluxDB ደግሞ 10 ጂቢ ይወስዳል። ይህ ደግሞ ትልቅ ልዩነት ነው።

ሁለተኛው ካርዲናል ልዩነት InfluxDB እንግዳ የሆኑ የጥያቄ ቋንቋዎች አሉት - Flux እና InfluxQL። ከግዜ ተከታታይ ጋር ሲወዳደሩ ለመስራት በጣም አመቺ አይደሉም PromQLበ VictoriaMetrics የሚደገፍ። PromQL ከPrometheus የጥያቄ ቋንቋ ነው።

እና ሌላው ልዩነት InfluxDB ትንሽ እንግዳ የሆነ የውሂብ ሞዴል አለው, እያንዳንዱ መስመር የተለያዩ የመለያዎች ስብስብ ያላቸው በርካታ መስኮችን ማከማቸት ይችላል. እነዚህ መስመሮች የበለጠ ወደ ሁሉም ዓይነት ጠረጴዛዎች ተከፋፍለዋል. እነዚህ ተጨማሪ ውስብስቦች ከዚህ መሠረት ጋር ቀጣይ ሥራን ያወሳስባሉ. ለመጠበቅ እና ለመረዳት አስቸጋሪ ነው.

በ VictoriaMetrics ውስጥ ሁሉም ነገር በጣም ቀላል ነው። እዚያ፣ እያንዳንዱ ተከታታይ ጊዜ ቁልፍ-እሴት ነው። እሴት የነጥቦች ስብስብ ነው - (timestamp, value), እና ቁልፉ ስብስብ ነው label=value. በሜዳዎች እና ልኬቶች መካከል ምንም መለያየት የለም. ይህ ማንኛውንም ዳታ ለመምረጥ እና ከዚያ ለማጣመር ፣ ለማከል ፣ ለመቀነስ ፣ ለማባዛት ፣ ለማካፈል ፣ እንደ InfluxDB በተለየ ፣ በተለያዩ ረድፎች መካከል ያሉ ስሌቶች እስከማውቀው ድረስ አልተተገበሩም። ቢተገበርም, አስቸጋሪ ነው, የኮድ ስብስብ መፃፍ አለብዎት.

ግልጽ ጥያቄ አለኝ። የተናገርከው አንድ ዓይነት ችግር እንዳለ በትክክል ተረድቻለሁ፣ ይህ የተገለበጠ መረጃ ጠቋሚ ወደ ማህደረ ትውስታ የማይገባ ነው፣ ስለዚህ እዚያ መከፋፈል እየተካሄደ ነው?

በመጀመሪያ፣ በመደበኛ የ Go ካርታ ላይ የተገለበጠ ኢንዴክስ የዋህ አተገባበርን አሳይቻለሁ። ይህ አተገባበር ለመረጃ ቋቶች ተስማሚ አይደለም ምክንያቱም ይህ የተገለበጠ ኢንዴክስ በዲስክ ላይ አልተቀመጠም እና ዳታቤዙ በዲስክ ላይ ማስቀመጥ አለበት ስለዚህ ይህ ውሂብ እንደገና ሲጀመር ይገኛል። በዚህ ትግበራ, ማመልከቻውን እንደገና ሲያስጀምሩ, የተገለበጠ መረጃ ጠቋሚዎ ይጠፋል. እና የሁሉንም ውሂብ መዳረሻ ታጣለህ ምክንያቱም እሱን ማግኘት አትችልም።

ሀሎ! ለሪፖርቱ እናመሰግናለን! ስሜ ፓቬል ነው። እኔ ከ Wildberry ነኝ። ለአንተ ጥቂት ጥያቄዎች አሉኝ። ጥያቄ አንድ። የመተግበሪያዎን አርክቴክቸር እና በጊዜ የተከፋፈሉ መረጃዎችን በሚገነቡበት ጊዜ የተለየ መርሆ ከመረጡ ምናልባት አንድ ክፍልፍል ለአንድ ጊዜ መረጃ የያዘ በመሆኑ ብቻ በመፈለግ የውሂብ መገናኛን ማድረግ ይችሉ ነበር ብለው ያስባሉ ጊዜ ፣ ማለትም ፣ በአንድ የጊዜ ልዩነት ውስጥ እና ቁርጥራጮቹ በተለያየ መንገድ የተበታተኑ ስለመሆናቸው መጨነቅ አያስፈልገዎትም? ጥያቄ ቁጥር 2 - ተመሳሳይ ስልተ ቀመር ከቢትሴት እና ከሌሎች ነገሮች ጋር ስለተተገበሩ ምናልባት የአቀነባባሪ መመሪያዎችን ለመጠቀም ሞክረዋል? ምናልባት እንደዚህ አይነት ማመቻቸት ሞክረህ ሊሆን ይችላል?

ለሁለተኛው መልስ እሰጣለሁ. እስካሁን እዚያ አልደረስንም። ካስፈለገ ግን እናደርጋለን። የመጀመሪያው ጥያቄ ምን ነበር?

በሁለት ሁኔታዎች ላይ ተወያይተሃል። ሁለተኛውን ደግሞ ውስብስብ በሆነ አተገባበር መርጠዋል አሉ። እና ውሂቡ በጊዜ የተከፋፈለበትን የመጀመሪያውን አልመረጡም.

አዎ. በመጀመሪያው ሁኔታ, የመረጃ ጠቋሚው አጠቃላይ መጠን ትልቅ ይሆናል, ምክንያቱም በእያንዳንዱ ክፍል ውስጥ በእነዚህ ሁሉ ክፍሎች ውስጥ ለሚቀጥሉት ተከታታይ ጊዜዎች የተባዙ መረጃዎችን ማከማቸት አለብን. እና ለጊዜ ተከታታዮች ትንሽ የፍጥነት መጠን ካለዎት ፣ ማለትም ፣ ተመሳሳይ ተከታታይ በቋሚነት ጥቅም ላይ ይውላሉ ፣ ከዚያ በመጀመሪያው ሁኔታ ከሁለተኛው ጉዳይ ጋር ሲነፃፀር በተያዘው የዲስክ ቦታ ላይ የበለጠ እናጣለን ።

እና ስለዚህ - አዎ, በጊዜ መከፋፈል ጥሩ አማራጭ ነው. ፕሮሜቲየስ ይጠቀምበታል. ነገር ግን ፕሮሜቲየስ ሌላ ችግር አለው. እነዚህን የውሂብ ቁርጥራጮች በሚያዋህድበት ጊዜ፣ ለሁሉም መለያዎች እና ተከታታይ ጊዜዎች ሜታ-መረጃን በማህደረ ትውስታ ውስጥ ማስቀመጥ አለበት። ስለዚህ, የመረጃው ክፍሎች ትልቅ ከሆኑ, እሱም ይዋሃዳል, ከዚያም የማስታወሻ ፍጆታው በሚዋሃድበት ጊዜ በጣም በጠንካራ ሁኔታ ያድጋል, ከ VictoriaMetrics በተለየ. በሚዋሃዱበት ጊዜ ቪክቶሪያ ሜትሪክስ ማህደረ ትውስታን ጨርሶ አይፈጅም, ሁለት ኪሎባይትስ እዚያ ይበላል, የውሂብ ቁርጥራጮች መጠኑ ምንም ይሁን ምን ይዋሃዳሉ.

ያለህ አልጎሪዝም ማህደረ ትውስታን መጠቀም ነው። እሴቶች ያላቸውን የጊዜ ተከታታይ-ምልክቶችን ያመላክታል። እና በዚህ መንገድ የተጣመረውን ተገኝነት በአንድ የውሂብ ድርድር እና በሌላ ውስጥ ያረጋግጡ። እና ኢንተርሴክቱ ተከስቷል ወይም እንዳልሆነ ይገባሃል። በተለምዶ የውሂብ ጎታዎች በነዚህ ኦፕሬሽኖች ቀላል ውስብስብነት ምክንያት የአሁኑን ዋጋ የሚያከማቹ እና የተደረደሩ መረጃዎችን የሚያካሂዱ ጠቋሚዎችን, ተደጋጋሚዎችን ይተገብራሉ.

መረጃን ለመሻገር ለምን ጠቋሚዎችን አንጠቀምም?

አዎን.

በእኛ LevelDB ወይም ውህደት ውስጥ፣ ልክ የተደረደሩ መስመሮች ተቀምጠዋል። በጠቋሚው መራመድ እና መገናኛውን ማግኘት እንችላለን. ለምን አንጠቀምበትም? ምክንያቱም ቀርፋፋ ነው። ምክንያቱም ጠቋሚዎች ለእያንዳንዱ መስመር ተግባር መጥራት እንዳለቦት ያመለክታሉ። የተግባር ጥሪ 5 nanoseconds ነው። እና 100 መስመሮች ካሉዎት, ግማሽ ሰከንድ በተግባር ጥሪ ላይ ብቻ እናጠፋለን.

እንደዚህ ያለ ነገር አለ, አዎ. እና የመጨረሻ ጥያቄዬ። ጥያቄው ትንሽ እንግዳ ሊመስል ይችላል። ለምንድነው, መረጃው በሚደርስበት ጊዜ, ሁሉንም አስፈላጊ ስብስቦችን መቁጠር እና በሚፈለገው ቅጽ ማስቀመጥ አይቻልም? በኋላ ላይ ብዙ ጊዜ ለማሳለፍ እንደ VictoriaMetrics፣ ClickHouse፣ ወዘተ ባሉ አንዳንድ ስርዓቶች ላይ ትልቅ መጠን ለምን ይቆጥባል?

የበለጠ ግልጽ ለማድረግ አንድ ምሳሌ እሰጣለሁ. ትንሽ አሻንጉሊት የፍጥነት መለኪያ እንዴት እንደሚሰራ እንበል? የተጓዙበትን ርቀት ይመዘግባል, ሁል ጊዜ ወደ አንድ እሴት, ወደ ሁለተኛው - ጊዜ ይጨምራል. እና ይከፋፈላል. እና አማካይ ፍጥነት ያገኛል. አንተ ቆንጆ ያህል ተመሳሳይ ማድረግ ትችላለህ. በበረራ ላይ ሁሉንም አስፈላጊ እውነታዎች ይጨምሩ.

እሺ ጥያቄውን ተረድቻለሁ። የእርስዎ ምሳሌ የመኖሪያ ቦታ አለው። ምን አይነት ድምር እንደሚፈልጉ ካወቁ, ይህ በጣም ጥሩው ትግበራ ነው. ግን ችግሩ ሰዎች እነዚህን መለኪያዎች, አንዳንድ መረጃዎችን በ ClickHouse ውስጥ ያስቀምጣሉ, እና አሁንም እንዴት እንደሚዋሃዱ እና ወደፊት እንደሚያጣሩ አያውቁም, ስለዚህ ሁሉንም ጥሬ ውሂቦች ማስቀመጥ አለብዎት. ነገር ግን አንድ ነገር ማስላት እንደሚያስፈልግዎት ካወቁ ብዙ ጥሬ እሴቶችን እዚያ ከማጠራቀም ይልቅ ለምን አታሰሉትም? ነገር ግን ይህ የሚያስፈልገዎትን በትክክል ካወቁ ብቻ ነው.

በነገራችን ላይ የጊዜ ተከታታይን ለማከማቸት የውሂብ ጎታዎች ድምርን ለመቁጠር ይደግፋሉ. ለምሳሌ, ፕሮሜቲየስ ይደግፋል የመቅዳት ደንቦች. ይህም ማለት ምን ዓይነት ክፍሎች እንደሚፈልጉ ካወቁ ሊደረግ ይችላል. ይህ ገና በቪክቶሪያ ሜትሪክስ ውስጥ አይገኝም፣ ነገር ግን ብዙውን ጊዜ ከፕሮሜቲየስ በፊት ነው፣ በዚህ ውስጥ ህጎችን በመቀየር ይህንን ማድረግ ይችላሉ።

ለምሳሌ, በቀድሞው ሥራ, በመጨረሻው ሰዓት ውስጥ በተንሸራታች መስኮት ውስጥ ያሉትን የክስተቶች ብዛት መቁጠር አለብዎት. ችግሩ በ Go ውስጥ ብጁ ትግበራ ማድረግ ነበረብኝ፣ ማለትም ይህንን ነገር ለመቁጠር አገልግሎት። ይህ አገልግሎት በመጨረሻ ቀላል አልነበረም፣ ምክንያቱም ለመቁጠር አስቸጋሪ ነው። በተወሰነ የጊዜ ልዩነት ውስጥ የተወሰኑ ድምርን መቁጠር ከፈለጉ አተገባበሩ ቀላል ሊሆን ይችላል. በተንሸራታች መስኮት ውስጥ ክስተቶችን ለመቁጠር ከፈለጉ, የሚመስለውን ያህል ቀላል አይደለም. እኔ እንደማስበው ይህ ገና በ ClickHouse ውስጥ ወይም በጊዜ ተከታታይ የውሂብ ጎታዎች ውስጥ አልተተገበረም, ምክንያቱም ለመተግበር አስቸጋሪ ነው.

እና አንድ ተጨማሪ ጥያቄ. ስለ አማካኝነት ብቻ ነው እየተነጋገርን ያለነው፣ እና በአንድ ወቅት እንደ ካርቦን ጀርባ ያለው ግራፋይት የሚባል ነገር እንደነበረ አስታውሳለሁ። እና የድሮ ውሂብን እንዴት ማቃለል እንደሚቻል ያውቅ ነበር ፣ ማለትም በደቂቃ አንድ ነጥብ ፣ በሰዓት አንድ ነጥብ ፣ ወዘተ. በመርህ ደረጃ ፣ ጥሬ መረጃን በአንጻራዊ ሁኔታ ለአንድ ወር ከፈለግን ይህ በጣም ምቹ ነው ፣ እና ሁሉም ነገር ሊቀንስ ይችላል ውጣ . ግን ፕሮሜቴየስ ፣ ቪክቶሪያ ሜትሪክስ ይህንን ተግባር አይደግፉም። ለመደገፍ ታቅዷል? ካልሆነ ለምን አይሆንም?

ለጥያቄው አመሰግናለሁ። ተጠቃሚዎቻችን በየጊዜው ይጠይቃሉ። ለቅጥነት (ሳምፕሊንግ) ድጋፍ መቼ እንደምንጨምር ይጠይቃሉ። እዚህ ብዙ ችግሮች አሉ. በመጀመሪያ, እያንዳንዱ ተጠቃሚ ይረዳል downsampling የራሳቸው የሆነ ነገር: አንድ ሰው በተወሰነ የጊዜ ልዩነት ላይ ማንኛውንም የዘፈቀደ ነጥብ ማግኘት ይፈልጋል, አንድ ሰው ከፍተኛውን, ዝቅተኛውን, አማካይ እሴቶችን ይፈልጋል. ብዙ ስርዓቶች ወደ የውሂብ ጎታዎ ውሂብን የሚጽፉ ከሆነ ሁሉንም አንድ መጠን ለመደርደር አይችሉም። ለእያንዳንዱ ስርዓት የተለየ ዲሲሜሽን መጠቀም እንደሚያስፈልግዎ ሊገነዘቡ ይችላሉ። እና ለመተግበር አስቸጋሪ ነው.

እና ሁለተኛው ነገር ቪክቶሪያ ሜትሪክስ ልክ እንደ ClickHouse ፣ ከፍተኛ መጠን ካለው ጥሬ መረጃ ጋር ለመስራት የተመቻቸ በመሆኑ በስርዓትዎ ውስጥ ብዙ ኮሮች ካሉ ከአንድ ሰከንድ ባነሰ ጊዜ ውስጥ በአንድ ቢሊዮን ረድፎች ውስጥ አካፋ ማድረግ ይችላል። የጊዜ ተከታታይ ነጥብ ቅኝት በ VictoriaMetrics - 50 ነጥብ በሰከንድ በኮር። እና ያ አፈፃፀሙ ወደሚገኙት ኮሮች ይደርሳል። ማለትም 000 ኮሮች ካሉዎት ለምሳሌ በሴኮንድ አንድ ቢሊዮን ነጥቦችን ይቃኛሉ። እና ይህ የ VictoriaMetrics እና ClickHouse ንብረት የማውረድ ፍላጎትን ይቀንሳል።

ሌላው ጥቅም ቪክቶሪያ ሜትሪክስ ይህንን መረጃ በብቃት መጨመቁ ነው። ለምርት በአማካይ መጨናነቅ ከ 0,4 እስከ 0,8 ባይት በአንድ ነጥብ ነው. እያንዳንዱ ነጥብ የጊዜ ማህተም + እሴት ነው። እና በአማካይ ከአንድ ባይት ያነሰ ይጨመቃል።

ሰርጌይ ጥያቄ አለኝ. ዝቅተኛው የቀረጻ ጊዜ ቁራጭ ምንድነው?

አንድ ሚሊሰከንድ. በቅርቡ ከሌሎች ተከታታይ ተከታታይ የውሂብ ጎታ ገንቢዎች ጋር ውይይት አድርገናል። የእነሱ ዝቅተኛ ጊዜ ኳንተም አንድ ሰከንድ ነው። እና በግራፋይት ውስጥ, ለምሳሌ, እንዲሁም አንድ ሰከንድ ነው. OpenTSDB እንዲሁ አንድ ሰከንድ አለው። በ InfluxDB፣ nanosecond ትክክለኛነት። ቪክቶሪያ ሜትሪክስ አንድ ሚሊሰከንድ አለው ምክንያቱም ፕሮሜቲየስ አንድ ሚሊሰከንድ አለው። እና VictoriaMetrics በመጀመሪያ የተሰራው ለፕሮሜቲየስ የርቀት ማከማቻ ነው። አሁን ግን ከሌሎች ስርዓቶች መረጃን መቆጠብ ይችላል.

ያነጋገርኳቸው ሰው ሁለተኛ ትክክለኛነት አላቸው - ይህ ለእነሱ በቂ ነው, ምክንያቱም በጊዜ ተከታታይ የውሂብ ጎታ ውስጥ በተከማቸ የውሂብ አይነት ይወሰናል. ይህ የዴቭኦፕስ መረጃ ወይም መረጃ በ30 ሰከንድ በየደቂቃ የምትሰበስቡበት የመሠረተ ልማት መረጃ ከሆነ፣ ከዚያ በቂ ሁለተኛ ትክክለኛነት አለ፣ ትንሽ አያስፈልጎትም። እና ይህን ውሂብ ከከፍተኛ ድግግሞሽ የግብይት ስርዓቶች ከሰበሰቡ, ከዚያ nanosecond ትክክለኛነት ያስፈልግዎታል.

ሚሊሰከንድ ትክክለኛነት በ VictoriaMetrics ለDevOps ጉዳይም ተስማሚ ነው፣ እና በሪፖርቱ መጀመሪያ ላይ ለጠቀስኳቸው ለአብዛኛዎቹ ጉዳዮች ተስማሚ ሊሆን ይችላል። ተስማሚ ላይሆን የሚችለው ብቸኛው ነገር ከፍተኛ ድግግሞሽ የንግድ ስርዓቶች ነው.

አመሰግናለሁ! እና ሌላ ጥያቄ. በPromQL ውስጥ ተኳኋኝነት ምንድነው?

ሙሉ ወደ ኋላ ተኳኋኝነት። VictoriaMetrics PromQLን ሙሉ በሙሉ ይደግፋል። በተጨማሪም, ወደ PromQL ሌላ የላቀ ተግባር ይጨምራል, እሱም ይባላል MetricsQL. ስለዚህ የተራዘመ ተግባር በዩቲዩብ ላይ ንግግር አለ። በጸደይ ወቅት በሴንት ፒተርስበርግ በተካሄደው የክትትል ስብሰባ ላይ ተናገርኩ።

የቴሌግራም ሰርጥ ቪክቶሪያ ሜትሪክስ.

በዳሰሳ ጥናቱ ውስጥ የተመዘገቡ ተጠቃሚዎች ብቻ መሳተፍ ይችላሉ። ስግን እንእባክህን።

ለፕሮሜቲየስ የረጅም ጊዜ ማከማቻ ወደ VictoriaMetrics እንዳይቀይሩ የሚያግድዎት ምንድን ነው? (በአስተያየቶቹ ውስጥ ይጻፉ, ወደ ምርጫው እጨምራለሁ))

• 71,4%Prometheus5ን አለመጠቀም

• 28,6%ስለ VictoriaMetrics2 አያውቅም ነበር።

7 ተጠቃሚዎች ድምጽ ሰጥተዋል። 12 ተጠቃሚዎች ድምፀ ተአቅቦ አድርገዋል።

ምንጭ: hab.com