ከፍተኛ አፈጻጸም እና ቤተኛ ክፍልፍል፡ Zabbix ከTimescaleDB ድጋፍ ጋር

ዛቢቢክስ የክትትል ስርዓት ነው። እንደሌላው ስርዓት፣ የሁሉም የክትትል ስርዓቶች ሶስት ዋና ዋና ችግሮች ያጋጥሟቸዋል፡ መረጃን መሰብሰብ እና ማቀናበር፣ ታሪክን ማከማቸት እና ማጽዳት።

መረጃን የመቀበል፣ የማቀናበር እና የመቅዳት ደረጃዎች ጊዜ ይወስዳሉ። ብዙ አይደለም, ነገር ግን ለትልቅ ስርዓት, ይህ ትልቅ መዘግየቶችን ሊያስከትል ይችላል. የማከማቻ ችግር የውሂብ መዳረሻ ጉዳይ ነው። ለሪፖርቶች, ቼኮች እና ቀስቅሴዎች ያገለግላሉ. የውሂብ መዳረሻ መዘግየቶች በአፈጻጸም ላይ ተጽዕኖ ያሳድራሉ. የውሂብ ጎታው ሲያድግ ተዛማጅነት የሌለው ውሂብ መሰረዝ አለበት። ማጥፋት አንዳንድ ሀብቶችን የሚበላ ከባድ ቀዶ ጥገና ነው።

በዛቢክስ ውስጥ የመሰብሰብ እና የማከማቻ መዘግየት ችግሮች በመሸጎጥ ይፈታሉ: ብዙ አይነት መሸጎጫዎች, በመረጃ ቋቱ ውስጥ መሸጎጥ. ሶስተኛውን ችግር ለመፍታት መሸጎጫ ተስማሚ አይደለም፣ ስለዚህ TimecaleDB በዛቢክስ ውስጥ ጥቅም ላይ ውሏል። ስለ እሱ ይነግሩታል። አንድሬ ጉሽቺን። - የቴክኒክ ድጋፍ መሐንዲስ Zabbix SIA. አንድሬ ዛቢክስን ከ 6 ዓመታት በላይ ሲደግፍ ቆይቷል እና በአፈፃፀም ውስጥ በቀጥታ ይሳተፋል።

TimecaleDB እንዴት ነው የሚሰራው፣ ከመደበኛ PostgreSQL ጋር ሲነጻጸር ምን አፈጻጸም ሊሰጥ ይችላል? Zabbix በ TimecaleDB ውስጥ ምን ሚና ይጫወታል? ከባዶ እንዴት እንደሚጀመር እና ከ PostgreSQL እንዴት እንደሚሰደድ እና የትኛው የውቅር አፈጻጸም የተሻለ ነው? ይህ ሁሉ በቆራጩ ስር.

የአፈጻጸም ተግዳሮቶች

እያንዳንዱ የክትትል ስርዓት የተወሰኑ የአፈፃፀም ችግሮች ያጋጥመዋል። ስለ ሶስቱ እናገራለሁ-መረጃ መሰብሰብ እና ማቀናበር, ማከማቻ, ታሪክ ማጽዳት.

ፈጣን መረጃ መሰብሰብ እና ማቀናበር። ጥሩ የክትትል ስርዓት ሁሉንም መረጃዎች በፍጥነት መቀበል እና እንደ ቀስቃሽ አገላለጾች ማካሄድ አለበት - በራሱ መስፈርት። ከሂደቱ በኋላ ስርዓቱ ይህን ውሂብ በኋላ ለመጠቀም በፍጥነት በመረጃ ቋቱ ውስጥ ማከማቸት አለበት።

የታሪክ ማከማቻ። ጥሩ የክትትል ስርዓት ታሪክን በመረጃ ቋት ውስጥ ማከማቸት እና ለሜትሪዎች ቀላል መዳረሻ መስጠት አለበት። ታሪኩ በሪፖርቶች ፣ በግራፎች ፣ ቀስቅሴዎች ፣ ገደቦች እና የተሰላ የማንቂያ ንጥሎች ውስጥ ጥቅም ላይ እንዲውል ያስፈልጋል።

ታሪክን በማጽዳት ላይ። አንዳንድ ጊዜ መለኪያዎችን ማከማቸት የማትፈልግበት ቀን ይመጣል። ለምንድነው ከ 5 አመት በፊት የተሰበሰበ መረጃ ከአንድ ወር ወይም ሁለት: አንዳንድ አንጓዎች ተወግደዋል, አንዳንድ አስተናጋጆች ወይም መለኪያዎች ከአሁን በኋላ አያስፈልጉም, ምክንያቱም ጊዜ ያለፈባቸው እና ከአሁን በኋላ አይሰበሰቡም. ጥሩ የክትትል ስርዓት ታሪካዊ መረጃዎችን ማከማቸት እና የውሂብ ጎታ እንዳያድግ ከጊዜ ወደ ጊዜ መሰረዝ አለበት.

የቆየ ውሂብን ማጽዳት በዳታቤዝ አፈጻጸም ላይ ትልቅ ተፅዕኖ ያለው እሾህ ጉዳይ ነው።

በዛቢክስ ውስጥ መሸጎጫ

በዛቢክስ የመጀመሪያ እና ሁለተኛ ጥሪዎች መሸጎጫ በመጠቀም ይፈታሉ። RAM ውሂብ ለመሰብሰብ እና ለማስኬድ ስራ ላይ ይውላል። ለማከማቻ - ታሪክ ቀስቅሴዎች, ግራፎች እና የተሰሉ እቃዎች. በዲቢ በኩል፣ ለመሠረታዊ ምርጫዎች፣ እንደ ግራፎች ያሉ አንዳንድ መሸጎጫዎች አሉ።

በዛቢክስ አገልጋይ በኩል መሸጎጥ ራሱ፡-

• ConfigurationCache;
• ValueCache;
• HistoryCache;
• TrendsCache.

በዝርዝር እንመለከታቸው ፡፡

ውቅረት መሸጎጫ

ይህ ሜትሪክስ ፣ አስተናጋጆች ፣ የውሂብ ዕቃዎች ፣ ቀስቅሴዎች የምናከማችበት ዋናው መሸጎጫ ነው - ለቅድመ ፕሮሴሲንግ እና ለመረጃ አሰባሰብ የሚያስፈልጉትን ነገሮች ሁሉ።

በመረጃ ቋቱ ውስጥ አላስፈላጊ ጥያቄዎችን ላለመፍጠር ይህ ሁሉ በ ConfigurationCache ውስጥ ተከማችቷል። አገልጋዩ ከጀመረ በኋላ፣ ይህን መሸጎጫ እናዘምነዋለን፣ ውቅሮችን እንፈጥራለን እና በየጊዜው እናዘምነዋለን።

የውሂብ መሰብሰብ

መርሃግብሩ በጣም ትልቅ ነው, ነገር ግን በውስጡ ያለው ዋናው ነገር ነው ሰብሳቢዎች. እነዚህ የተለያዩ "ፖለሮች" ናቸው - የመሰብሰቢያ ሂደቶች. ለተለያዩ የመሰብሰቢያ ዓይነቶች ተጠያቂዎች ናቸው፡ በ SNMP፣ IPMI በኩል መረጃዎችን ይሰበስባሉ እና ሁሉንም ወደ ቅድመ ፕሮሰሲንግ ያስተላልፋሉ።

መራጮች በብርቱካናማ ቀለም የተከበቡ ናቸው።

ዛቢቢክስ ቼኮችን ለማዋሃድ የሚያስፈልጉትን የማጠቃለያ ዕቃዎችን አስልቷል። እኛ ካለን ውሂቡን በቀጥታ ከValueCache እንወስዳቸዋለን።

የታሪክ መሸጎጫ ቅድመ ሂደት

ሁሉም ሰብሳቢዎች ስራዎችን ለመቀበል ConfigurationCache ይጠቀማሉ። ከዚያም ወደ ቅድመ ፕሮሰሲንግ ያስተላልፋሉ።

የቅድሚያ ሂደት ደረጃዎችን ለማግኘት ConfigurationCacheን ይጠቀማል። ይህንን መረጃ በተለያዩ መንገዶች ያስተናግዳል።

ውሂቡን በቅድመ ፕሮሰሲንግ ካሰራን በኋላ፣ እሱን ለማስኬድ በHistoryCache ውስጥ እናከማቻለን። ይህ የመረጃ አሰባሰብን ያጠናቅቃል እና በዛቢክስ ውስጥ ወደ ዋናው ሂደት እንሄዳለን - ታሪክ አመሳስል, አሀዳዊ ሥነ ሕንፃ እንደመሆኑ መጠን.

ማሳሰቢያ፡- ቅድመ-ሂደት በጣም ከባድ ስራ ነው። ከቁ 4.2 ጀምሮ ወደ ፕሮክሲ ተወስዷል። ብዙ ቁጥር ያላቸው እቃዎች እና የመሰብሰቢያ ድግግሞሽ ያለው በጣም ትልቅ Zabbix ካለዎት, ይህ ነገሮችን በጣም ቀላል ያደርገዋል.

ValueCache፣ ታሪክ እና አዝማሚያዎች መሸጎጫ

የታሪክ ማመሳሰል እያንዳንዱን የውሂብ አካል በአቶሚክ የሚያስኬድ ዋና ሂደት ነው፣ ማለትም እያንዳንዱን እሴት።

የታሪክ ማመሳሰል እሴቶችን ከHistoryCache ይወስዳል እና ለስሌቶች ቀስቅሴዎችን ውቅረትን ይፈትሻል። እነሱ ከሆኑ - ያሰላል.

የታሪክ አመሳስል ክስተት ይፈጥራል፣ በውቅረት ከተፈለገ ማንቂያዎችን ለመፍጠር ያድጋል እና ይመዘግባል። ለቀጣይ ሂደት ቀስቅሴዎች ካሉ, የታሪክ ሠንጠረዥን ላለመጥቀስ ይህን እሴት በ ValueCache ውስጥ ያስታውሰዋል. ቀስቅሴዎችን፣ የተሰሉ ዕቃዎችን ለማስላት ቫልዩካሼ በሚያስፈልገው መረጃ የተሞላው በዚህ መንገድ ነው።

የታሪክ ማመሳሰል ሁሉንም ውሂብ ወደ ዳታቤዝ ይጽፋል እና ወደ ዲስክ ይጽፋል። የማቀነባበሪያው ሂደት እዚህ ያበቃል.

ዲቢ መሸጎጫ

ግራፎችን ወይም የክስተት ሪፖርቶችን መመልከት ሲፈልጉ በዲቢ በኩል የተለያዩ መሸጎጫዎች አሉ፡

• Innodb_buffer_pool በ MySQL ጎን;
• shared_buffers በ PostgreSQL በኩል;
• effective_cache_size በ Oracle በኩል;
• shared_pool በዲቢ2 በኩል።

ሌሎች ብዙ መሸጎጫዎች አሉ, ግን እነዚህ ለሁሉም የውሂብ ጎታዎች ዋናዎቹ ናቸው. ብዙ ጊዜ ለጥያቄዎች የሚያስፈልጉትን መረጃዎች በ RAM ውስጥ እንዲያቆዩ ያስችሉዎታል። ለዚህም የራሳቸው ቴክኖሎጂ አላቸው።

የውሂብ ጎታ አፈጻጸም ወሳኝ ነው።

የዛቢክስ አገልጋይ ያለማቋረጥ መረጃዎችን እየሰበሰበ እየጻፈ ነው። እንደገና ሲጀመር፣ ValueCacheን ለመሙላት ከታሪክ ያነባል። ስክሪፕቶች እና ሪፖርቶች ጥቅም ላይ ይውላሉ Zabbix ኤፒአይበድር በይነገጽ ላይ የተመሰረተ ነው. የዛቢክስ ኤፒአይ የውሂብ ጎታውን ይደርሳል እና ለግራፎች፣ ሪፖርቶች፣ የክስተት ዝርዝሮች እና የቅርብ ጊዜ ጉዳዮች አስፈላጊውን ውሂብ ያወጣል።

ለዕይታ - ግራፋና. ይህ በተጠቃሚዎቻችን ዘንድ ታዋቂ መፍትሄ ነው። በቀጥታ በዛቢክስ ኤፒአይ እና በመረጃ ቋቱ በኩል ጥያቄዎችን መላክ ትችላለች፣ እና ውሂብ ለማግኘት የተወሰነ መመሳሰል ትፈጥራለች። ስለዚህ ፈጣን የውጤት አሰጣጥ እና የፈተና ሂደትን ለማጣጣም የተሻለ እና የተሻለ የውሂብ ጎታ ማስተካከያ ያስፈልጋል።

የቤት ጽዳት

በዛቢክስ ውስጥ ያለው ሦስተኛው የአፈጻጸም ፈተና ታሪክን ከቤት ጠባቂ ጋር ማፅዳት ነው። ሁሉንም ቅንጅቶች ያከብራል - የውሂብ አካላት በቀናት ውስጥ ለውጦችን (አዝማሚያዎችን) ተለዋዋጭ ሁኔታዎችን ለምን ያህል ጊዜ እንደሚያከማቹ ያመለክታሉ።

TrendsCache በበረራ ላይ እናሰላለን. ውሂቡ ሲመጣ በአንድ ሰአት ውስጥ እናጠቃልለን እና ለአዝማሚያ ለውጦች ተለዋዋጭነት በሰንጠረዥ ውስጥ እናስቀምጠዋለን።

የቤት ጠባቂ መረጃን ከመረጃ ቋቱ ውስጥ በተለመደው "ይመርጣል" ይጀምር እና ያስወግዳል. ይህ ሁልጊዜ ውጤታማ አይደለም, ይህም ከውስጣዊ ሂደቶች የአፈፃፀም ግራፎች መረዳት ይቻላል.

ቀይ ግራፉ የሚያሳየው የታሪክ ማመሳሰል ያለማቋረጥ ስራ እንደሚበዛበት ነው። ከላይ ያለው የብርቱካናማ ገበታ የቤት ጠባቂ ነው፣ እሱም ያለማቋረጥ ይሰራል። የመረጃ ቋቱ የገለጻቸውን ረድፎች በሙሉ እስኪሰርዝ ድረስ ይጠብቃል።

የቤት ሰራተኛን መቼ ማሰናከል አለብዎት? ለምሳሌ, "የእቃ መታወቂያ" አለ እና የመጨረሻውን 5 ሺህ መስመሮችን በተወሰነ ጊዜ ውስጥ መሰረዝ ያስፈልግዎታል. በእርግጥ ይህ በመረጃ ጠቋሚዎች ይከሰታል. ግን አብዛኛውን ጊዜ የመረጃ ቋቱ በጣም ትልቅ ነው, እና የውሂብ ጎታው አሁንም ከዲስክ አንብቦ በመሸጎጫ ውስጥ ያስቀምጣል. ይህ ሁልጊዜ ለዳታቤዝ በጣም ውድ የሆነ ክዋኔ ሲሆን እንደ የውሂብ ጎታው መጠን ወደ አፈጻጸም ችግሮች ሊመራ ይችላል።

የቤት ጠባቂ ለማሰናከል ቀላል ነው። በድር በይነገጽ ውስጥ ለቤት ጠባቂ በ "አስተዳደር አጠቃላይ" ውስጥ ቅንብር አለ. ለውስጣዊ አዝማሚያ ታሪክ የውስጥ የቤት አያያዝን አሰናክል እና ከአሁን በኋላ ይህንን አይቆጣጠርም።

የቤት ጠባቂ ተሰናክሏል ፣ ግራፊክስ ተስተካክሏል - በዚህ ጉዳይ ላይ ምን ችግሮች ሊኖሩ ይችላሉ እና ሦስተኛውን የአፈፃፀም ፈተና ለመፍታት ምን ሊረዳ ይችላል?

መከፋፈል - መከፋፈል ወይም መከፋፈል

እኔ በዘረዘርኳቸው በእያንዳንዱ ተዛማጅ ዳታቤዝ ላይ መከፋፈል አብዛኛውን ጊዜ በተለየ መንገድ ነው የሚዋቀረው። እያንዳንዳቸው የራሳቸው ቴክኖሎጂ አላቸው, ግን በአጠቃላይ ተመሳሳይ ናቸው. አዲስ ክፋይ መፍጠር ብዙውን ጊዜ ወደ አንዳንድ ችግሮች ያመራል.

በተለምዶ ክፍልፋዮች በ "ማዋቀር" ላይ በመመስረት የተዋቀሩ ናቸው - በአንድ ቀን ውስጥ የሚፈጠረው የውሂብ መጠን. እንደ አንድ ደንብ ክፍልፍል በአንድ ቀን ውስጥ ተዘጋጅቷል, ይህ ዝቅተኛው ነው. ለአዲስ ክፍልፍል አዝማሚያዎች - 1 ወር.

በጣም ትልቅ በሆነ "ማዋቀር" ሁኔታ ውስጥ እሴቶቹ ሊለወጡ ይችላሉ. አንድ ትንሽ "ማዋቀር" እስከ 5 nvps (በሴኮንድ አዲስ እሴቶች) ከሆነ, በአማካይ ከ 000 እስከ 5 ነው, ከዚያም ትልቅ ከ 000 nvps በላይ ነው. እነዚህ ትላልቅ እና በጣም ትልቅ ጭነቶች ናቸው የውሂብ ጎታው ራሱ በጥንቃቄ ማዋቀር የሚያስፈልጋቸው.

በጣም ትልቅ በሆኑ ጭነቶች ላይ አንድ ቀን ጥሩ ላይሆን ይችላል። የ MySQL ክፍልፋዮችን በቀን 40 ጂቢ ወይም ከዚያ በላይ አይቻለሁ። ይህ ወደ ችግሮች ሊያመራ የሚችል በጣም ትልቅ መጠን ያለው መረጃ ነው እና መቀነስ አለበት.

መከፋፈል ምን ይሰጣል?

የመከፋፈል ጠረጴዛዎች. ብዙውን ጊዜ እነዚህ በዲስክ ላይ የተለዩ ፋይሎች ናቸው. የጥያቄ ዕቅዱ አንድ ክፍልፍል በተሻለ ሁኔታ ይመርጣል። ብዙውን ጊዜ መከፋፈል በክልል ጥቅም ላይ ይውላል - ይህ ለዛቢክስም እውነት ነው። እዚያም "የጊዜ ማህተም" እንጠቀማለን - ከዘመናት መጀመሪያ ጀምሮ ያለውን ጊዜ. መደበኛ ቁጥሮች አሉን. እርስዎ የቀኑን መጀመሪያ እና መጨረሻ አዘጋጅተዋል - ይህ ክፍልፍል ነው።

በፍጥነት ማስወገድ - DELETE. አንድ ፋይል/ንዑስ ተንቀሳቃሽ የተመረጠ እንጂ ለመሰረዝ የረድፎች ምርጫ አይደለም።

የውሂብ ናሙናውን በከፍተኛ ሁኔታ ያፋጥናል SELECT - ሙሉውን ጠረጴዛ ሳይሆን አንድ ወይም ብዙ ክፍልፋዮችን ይጠቀማል። የሁለት ቀን እድሜ ያለው መረጃ እየደረስክ ከሆነ ከመረጃ ቋቱ በፍጥነት ያመጣዋል ምክንያቱም ወደ መሸጎጫው ጫንክ እና አንድ ፋይል ብቻ መመለስ አለብህ እንጂ ትልቅ ጠረጴዛ አይደለም።

ብዙ ጊዜ ብዙ የመረጃ ቋቶች እንዲሁ ያፋጥናል። INSERT - በልጁ ጠረጴዛ ውስጥ ያስገባል.

ታይምስሌል ዲ.ቢ.

ለ ቁ 4.2 ትኩረታችንን ወደ TimescaleDB አዙረናል። ይህ የ PostgreSQL ቅጥያ ከአገርኛ በይነገጽ ጋር ነው። ቅጥያው የግንኙነት የውሂብ ጎታዎችን ጥቅሞች ሳያጣ በጊዜ ተከታታይ ውሂብ በብቃት ይሰራል። TimecaleDB እንዲሁ በራስ-ሰር ክፍልፋዮች።

TimescaleDB ጽንሰ-ሐሳብ አለው hypertable (hypertable) እርስዎ የፈጠሩት። በውስጡ ይገኛሉ ቁርጥራጭ - ክፍልፋዮች. ቸንክች በራስ ሰር የሚተዳደሩት ሌሎች ቁርጥራጮችን የማይነኩ የሃይፐርታብል ቁርጥራጮች ናቸው። እያንዳንዱ ክፍል የራሱ የሆነ የጊዜ ገደብ አለው.

TimescaleDB vs PostgreSQL

TimescaleDB በእርግጥ ውጤታማ ነው። የኤክስቴንሽኑ አምራቾች ይበልጥ ትክክለኛ የሆነ የመጠይቅ ሂደት አልጎሪዝም እንደሚጠቀሙ ይናገራሉ ፣ በተለይም ፣ inserts . የውሂብ ስብስብ ማስገቢያው መጠን ሲያድግ ስልተ ቀመር ቋሚ አፈጻጸምን ያቆያል።

ከ 200 ሚሊዮን ረድፎች በኋላ ፣ PostgreSQL ብዙ ጊዜ ማሽቆልቆል ይጀምራል እና አፈፃፀሙን ወደ 0 ያጣሉ ። TimecaleDB ከማንኛውም የውሂብ መጠን ጋር “ማስገባቶችን” በብቃት እንዲያስገቡ ይፈቅድልዎታል።

ቅንብር

TimecaleDB ን መጫን ለማንኛውም ጥቅሎች ቀላል ነው። ውስጥ ሰነድ ሁሉም ነገር ዝርዝር ነው - በኦፊሴላዊው PostgreSQL ጥቅሎች ላይ የተመሰረተ ነው. TimecaleDB እንዲሁ በእጅ ሊገነባ እና ሊጠናቀር ይችላል።

ለ Zabbix የውሂብ ጎታ፣ በቀላሉ ቅጥያውን እናሰራዋለን፡-

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

ታነቃለህ extension እና ለ Zabbix የውሂብ ጎታ ይፍጠሩ. የመጨረሻው እርምጃ hypertable መፍጠር ነው.

የታሪክ ሠንጠረዦችን ወደ 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

ተግባሩ ሶስት መለኪያዎች አሉት. አንደኛ - በመረጃ ቋት ውስጥ ሰንጠረዥhypertable ለመፍጠር የሚፈልጉት. ሁለተኛ - መስክ, በዚህ መሠረት መፍጠር አስፈላጊ ነው chunk_time_interval - ጥቅም ላይ የሚውለው የክፋይ ቁርጥራጮች ክፍተት. በእኔ ሁኔታ, ክፍተቱ አንድ ቀን ነው - 86.

ሦስተኛው መለኪያ ነው migrate_data. ከተዋቀረ true, ከዚያ ሁሉም የአሁኑ ውሂብ ወደ ቀድሞ-የተፈጠሩ ቁርጥራጮች ይተላለፋል. እኔ ራሴ ተጠቅሜበታለሁ። migrate_data. ከአንድ ሰአት በላይ የፈጀ 1 ቴባ ገደማ ነበረኝ። በአንዳንድ ሁኔታዎች እንኳን, በሚሞከርበት ጊዜ, እነሱን ላለማስተላለፍ, ለማከማቻ አማራጭ የሆኑትን የቁምፊ ዓይነቶችን ታሪካዊ ውሂብ ሰርዣለሁ.

የመጨረሻው ደረጃ - UPDATE: በ db_extension ማስቀመጥ timescaledbየውሂብ ጎታው ይህ ቅጥያ እንዳለ እንዲረዳው. ዛቢቢክስ ያነቃዋል እና አገባብ እና መጠይቆችን ቀድሞውኑ ወደ ዳታቤዝ ይጠቀማል - እነዚያ ለTimescaleDB አስፈላጊ የሆኑ ባህሪያት።

የሃርድዌር ውቅር

ሁለት አገልጋዮችን ተጠቀምኩኝ. አንደኛ - VMware ማሽን. በቂ ትንሽ ነው፡ 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz፣ 16GB RAM እና 200GB SSD ድራይቭ።

በላዩ ላይ PostgreSQL 10.8 በዴቢያን ኦኤስ 10.8-1.pgdg90+1 እና xfs የፋይል ስርዓት ጫንኩ። ይህን ልዩ የውሂብ ጎታ ለመጠቀም ሁሉንም ነገር በትንሹ አዋቅሬዋለሁ፣ ዛቢክስ እራሱ የሚጠቀመውን ሲቀንስ።

በዚያው ማሽን ላይ የዛቢክስ አገልጋይ፣ PostgreSQL እና የጭነት ወኪሎች. ጥቅም ላይ የዋሉ 50 ንቁ ወኪሎች ነበሩኝ LoadableModuleየተለያዩ ውጤቶችን በፍጥነት ለማመንጨት: ቁጥሮች, ሕብረቁምፊዎች. ዳታቤዙን በብዙ መረጃዎች ሞላሁት።

መጀመሪያ ላይ ውቅሩ ይዟል 5 እቃዎች ውሂብ በአንድ አስተናጋጅ. እያንዳንዱ ንጥረ ነገር እውነተኛ ጭነቶች እንዲመስል ለማድረግ ቀስቅሴ ይዟል። በአንዳንድ ሁኔታዎች ከአንድ በላይ ቀስቅሴዎች ነበሩ. አንድ የአውታረ መረብ መስቀለኛ መንገድ ነበረው። 3-000 ቀስቅሴዎች.

የንጥል ማሻሻያ ክፍተት - 4-7 ሰከንዶች. 50 ወኪሎችን ብቻ ሳይሆን ተጨማሪ በመጨመር ጭነቱን እራሴን አስተካክለው. እንዲሁም በመረጃ አካላት እገዛ ጭነቱን በተለዋዋጭ ሁኔታ አስተካክዬ የዝማኔውን ክፍተት ወደ 4 ሴ.

PostgreSQL 35 nvps

በዚህ ሃርድዌር ላይ የመጀመሪያ ሩጫዬ በንጹህ PostgreSQL - 35 ሺህ ዋጋዎች በሰከንድ ነበር። እንደሚመለከቱት ፣ መረጃን ማስገባት የአንድ ሰከንድ ክፍልፋዮችን ይወስዳል - ሁሉም ነገር ጥሩ እና ፈጣን ነው። ብቸኛው ነገር 200 ጂቢ SSD ድራይቭ በፍጥነት ይሞላል.

ይህ መደበኛ የዛቢክስ አገልጋይ አፈጻጸም ዳሽቦርድ ነው።

የመጀመሪያው ሰማያዊ ግራፍ በሰከንድ የእሴቶች ብዛት ነው። በቀኝ በኩል ያለው ሁለተኛው ግራፍ የግንባታ ሂደቶችን መጫን ነው. ሦስተኛው የውስጣዊ ግንባታ ሂደቶችን መጫን ነው-የታሪክ ማመሳሰል እና ሃውስ ጠባቂ, እዚህ ለረጅም ጊዜ ሲሰራ ቆይቷል.

አራተኛው ግራፍ የHistoryCache አጠቃቀምን ያሳያል. ወደ ዳታቤዝ ከመግባትዎ በፊት ይህ አይነት ቋት ነው። አረንጓዴው አምስተኛው ግራፍ የValueCache አጠቃቀምን ያሳያል፣ ማለትም፣ ምን ያህል ValueCache ለመቀስቀሻዎች ሲመታ በሰከንድ በሺዎች የሚቆጠሩ እሴቶች ነው።

PostgreSQL 50 nvps

ከዚያም ጭነቱን ወደ 50 ሺህ ዋጋዎች በአንድ ሰከንድ በተመሳሳይ ሃርድዌር ላይ ጨምሬያለሁ.

ከቤት ጠባቂ ሲጫኑ 10 ሺህ እሴቶችን ማስገባት ከ2-3 ሰከንድ ይወስዳል።

የቤት ሰራተኛ ቀድሞውንም መንገድ ላይ መግባት ጀምሯል።

ሦስተኛው ግራፍ እንደሚያሳየው, በአጠቃላይ, የወጥመዶች እና የታሪክ ማመሳሰሎች ጭነት አሁንም በ 60% ደረጃ ላይ ይገኛል. በአራተኛው ግራፍ ላይ፣ የቤት ጠባቂ በሚሰራበት ጊዜ የታሪክ መሸጎጫ ቀድሞውኑ በንቃት መሙላት ይጀምራል። 20% ሙሉ ነው - 0,5 ጂቢ ገደማ።

PostgreSQL 80 nvps

ከዚያም ጭነቱን በሰከንድ ወደ 80 ሺህ እሴቶች ጨምሬያለሁ. ይህ በግምት 400 ሺህ የውሂብ አካላት እና 280 ሺህ ቀስቅሴዎች ነው.

የሠላሳ ታሪክ ማመሳሰሎች የመጫኛ ማስገቢያ ቀድሞውኑ በጣም ከፍተኛ ነው።

እንዲሁም የተለያዩ መለኪያዎችን ጨምሬአለሁ: የታሪክ ማመሳሰሎች, መሸጎጫዎች.

በእኔ ሃርድዌር ላይ፣ የታሪክ ማመሳሰሎች ጭነት ወደ ከፍተኛው ጨምሯል። HistoryCache በፍጥነት በውሂብ ተሞልቷል - ቋት ለማቀናበር ውሂብ አከማችቷል።

በዚህ ጊዜ ሁሉ ፕሮሰሰር፣ RAM እና ሌሎች የስርዓት መለኪያዎች እንዴት ጥቅም ላይ እንደዋሉ ተመለከትኩኝ እና የዲስክ አጠቃቀም ከፍተኛ መሆኑን ተገነዘብኩ።

ተጠቅሜበታለሁ። ከፍተኛው የዲስክ አቅም በዚህ ሃርድዌር እና በዚህ ምናባዊ ማሽን ላይ. በእንደዚህ ዓይነት ጥንካሬ ፣ PostgreSQL መረጃን በንቃት መጣል ጀመረ ፣ እና ዲስኩ ለመፃፍ እና ለማንበብ ጊዜ አልነበረውም ።

ሁለተኛ አገልጋይ

ቀድሞውንም 48 ፕሮሰሰር እና 128 ጊባ ራም የነበረውን ሌላ አገልጋይ ወሰድኩ። አስተካክዬዋለሁ - 60 ታሪክ ማመሳሰልን አዘጋጅቼ ተቀባይነት ያለው አፈጻጸም አሳክቻለሁ።

በእርግጥ, ይህ ቀድሞውኑ አንድ ነገር መደረግ ያለበት የአፈጻጸም ገደብ ነው.

timescaledb. 80 nvps

ዋና ስራዬ የ TimescaleDBን አቅም ከዛቢክስ ጭነት ጋር መሞከር ነው። በሰከንድ 80 ሺህ ዋጋዎች ብዙ ናቸው ፣ ልኬቶችን የመሰብሰብ ድግግሞሽ (በእርግጥ ከ Yandex በስተቀር) እና በጣም ትልቅ “ማዋቀር”።

በእያንዳንዱ ግራፍ ላይ ዳይፕ አለ - ይህ የውሂብ ፍልሰት ብቻ ነው። በ Zabbix አገልጋይ ውስጥ ካሉት ውድቀቶች በኋላ ፣ የታሪክ አመሳስል የመጫኛ መገለጫ ብዙ ተለውጧል - ሶስት ጊዜ ወድቋል።

TimecaleDB መረጃን ወደ 3 ጊዜ ያህል በፍጥነት እንዲያስገቡ እና ያነሰ የታሪክ መሸጎጫ እንዲጠቀሙ ይፈቅድልዎታል።

በዚህ መሠረት መረጃን በጊዜው ይቀበላሉ.

timescaledb. 120 nvps

ከዚያ የመረጃ ክፍሎችን ቁጥር ወደ 500 ሺህ ጨምሬያለሁ ። ዋናው ተግባር የ TimecaleDB ችሎታዎችን መፈተሽ ነበር - በሴኮንድ 125 ሺህ እሴቶችን ስሌት አገኘሁ።

ይህ ለመስራት ረጅም ጊዜ የሚወስድ "ማዋቀር" ነው. ነገር ግን የእኔ ዲስክ 1,5 ቴባ ብቻ ስለነበር በሁለት ቀናት ውስጥ ሞላሁት።

ከሁሉም በላይ፣ አዲስ የTimescaleDB ክፍልፋዮች በተመሳሳይ ጊዜ እየተፈጠሩ ነበር።

ለአፈፃፀም, ይህ ሙሉ በሙሉ የማይታወቅ ነው. በ MySQL ውስጥ ክፍልፋዮች ሲፈጠሩ, ለምሳሌ, ነገሮች የተለያዩ ናቸው. ይህ አብዛኛውን ጊዜ የሚከሰተው በምሽት ነው, ምክንያቱም አጠቃላይ ማስገባትን, የጠረጴዛዎችን ማጭበርበርን ስለሚገድብ እና የአገልግሎቱን ውድቀት ሊፈጥር ይችላል. በTimescaleDB ጉዳዩ ይህ አይደለም።

ለምሳሌ፣ በማህበረሰብ ውስጥ ካለው ስብስብ አንድ ግራፍ አሳይሻለሁ። በሥዕሉ ላይ TimecaleDB ነቅቷል፣ ለዚህም ምስጋና ይግባውና በአይኦ.ክብደት አጠቃቀም ላይ ያለው ጭነት በአቀነባባሪው ላይ ወድቋል። የውስጣዊ ሂደቶች አካላት አጠቃቀምም ቀንሷል። ከዚህም በላይ ይህ በተለመደው የፓንኬክ ዲስኮች ላይ ያለ ተራ ምናባዊ ማሽን ነው, እና ኤስኤስዲ አይደለም.

ግኝቶች

TimecaleDB ለአነስተኛ "ማዋቀር" ጥሩ መፍትሄ ነው., ይህም በዲስክ አፈፃፀም ላይ ያርፋል. የመረጃ ቋቱ በፍጥነት ወደ ሃርድዌር እስኪሸጋገር ድረስ በጥሩ ሁኔታ መስራቱን እንዲቀጥሉ ያስችልዎታል።

TimecaleDB ለማዋቀር ቀላል ነው፣ የአፈጻጸም ጭማሪን ይሰጣል፣ ከ Zabbix እና ጋር በደንብ ይሰራል ከ PostgreSQL በላይ ጥቅሞች አሉት.

PostgreSQL ን ከተጠቀሙ እና ለመለወጥ ካላሰቡ እኔ እመክራለሁ። ከዛቢክስ ጋር በማጣመር PostgreSQLን ከTimescaleDB ቅጥያ ጋር ይጠቀሙ. ይህ መፍትሄ እስከ መካከለኛ "ማዋቀር" ድረስ ውጤታማ በሆነ መንገድ ይሰራል.

"ከፍተኛ አፈፃፀም" እንላለን - ማለታችን ነው። HighLoad ++. አገልግሎቶች በሚሊዮን የሚቆጠሩ ተጠቃሚዎችን እንዲያገለግሉ የሚፈቅዱ ቴክኖሎጂዎችን እና ልምዶችን ለማወቅ ብዙም አይቆይም። ዝርዝር ሪፖርቶች ለኖቬምበር 7 እና 8 አስቀድመን አዘጋጅተናል, ግን መገናኘት የበለጠ ሊመከር ይችላል.

የእኛን ይመዝገቡ ርስቶች и ቴሌግራምየመጪውን ኮንፈረንስ ገፅታዎች የምንገልፅበት እና እንዴት ከሱ የበለጠ ጥቅም ማግኘት እንደምንችል እወቅ።

ምንጭ: hab.com