HighLoad++፣ Andrey Gushchin (ዛቢክስ)፡ ከፍተኛ አፈጻጸም እና ቤተኛ ክፍልፍል

Zabbix ከ TimescaleDB ዳታቤዝ ጋር እንዴት እንደ ደጋፊ ሆኖ እንደሚሰራ እንመለከታለን። ከባዶ እንዴት እንደሚጀምሩ እና ከPostgreSQL እንዴት እንደሚሰደዱ እናሳይዎታለን። እንዲሁም የሁለቱን አወቃቀሮች ንጽጽር የአፈጻጸም ሙከራዎችን እናቀርባለን።

ሃይሎድ++ ሳይቤሪያ 2019. ቶምስክ አዳራሽ። ሰኔ 24, 16:00. ማጠቃለያዎች እና አቀራረብ. ቀጣዩ የHighLoad++ ኮንፈረንስ ኤፕሪል 6 እና 7፣ 2020 በሴንት ፒተርስበርግ ይካሄዳል። ዝርዝሮች እና ቲኬቶች ማያያዣ.

አንድሬ ጉሽቺን (ከዚህ በኋላ - AG) - እኔ ZABBIX የቴክኒክ ድጋፍ መሐንዲስ ነኝ (ከዚህ በኋላ “ዛቢክስ” እየተባለ የሚጠራ)፣ አሰልጣኝ። ከ 6 ዓመታት በላይ በቴክኒክ ድጋፍ እየሰራሁ እና በአፈፃፀም ቀጥተኛ ልምድ ነበረኝ. ዛሬ TimecaleDB ከመደበኛው PostgreSQL 10 ጋር ሲወዳደር ሊሰጠው ስለሚችለው አፈጻጸም እናገራለሁ.እንዲሁም በአጠቃላይ እንዴት እንደሚሰራ አንዳንድ የመግቢያ ክፍል.

ከፍተኛ የአፈጻጸም ተግዳሮቶች፡ ከመረጃ አሰባሰብ እስከ መረጃ ማጽዳት

ለመጀመር እያንዳንዱ የክትትል ስርዓት የሚያጋጥማቸው የተወሰኑ የአፈጻጸም ተግዳሮቶች አሉ። የመጀመሪያው የአፈፃፀም ፈተና ፈጣን መረጃ መሰብሰብ እና ማቀናበር ነው።

ጥሩ የክትትል ስርዓት ሁሉንም መረጃዎች በፍጥነት እና በወቅቱ መቀበል ፣ እንደ ቀስቃሽ አገላለጾች ማስኬድ ፣ ማለትም ፣ በአንዳንድ መመዘኛዎች (ይህ በተለያዩ ስርዓቶች ውስጥ የተለየ ነው) እና ይህንን መረጃ ለመጠቀም በመረጃ ቋቱ ውስጥ ማስቀመጥ አለበት። ወደፊት.

ሁለተኛው የአፈጻጸም ፈተና የታሪክ ማከማቻ ነው። ብዙ ጊዜ በመረጃ ቋት ውስጥ ያከማቹ እና ለተወሰነ ጊዜ የተሰበሰቡትን እነዚህን መለኪያዎች በፍጥነት እና በቀላሉ ማግኘት ይችላሉ። በጣም አስፈላጊው ነገር ይህ ውሂብ ለመቀበል ምቹ መሆን አለበት, በሪፖርቶች, ግራፎች, ቀስቅሴዎች, በአንዳንድ ዓይነት የመነሻ ዋጋዎች, ለማንቂያዎች, ወዘተ.

ሦስተኛው የአፈጻጸም ፈተና ታሪክን ማጽዳት ነው፣ ማለትም እንደዚህ ያለ ቀን ሲኖርዎት ከ5 ዓመታት በላይ (ወራት ወይም ሁለት ወራትም እንኳ) የተሰበሰቡ ዝርዝር መለኪያዎችን ማከማቸት አያስፈልገዎትም። አንዳንድ የአውታረ መረብ አንጓዎች ተወግደዋል ወይም አንዳንድ አስተናጋጆች መለኪያዎች ከአሁን በኋላ አያስፈልጉም ምክንያቱም ቀድሞውንም ያለፈባቸው እና ከአሁን በኋላ ያልተሰበሰቡ ናቸው። የውሂብ ጎታዎ ወደ ትልቅ መጠን እንዳያድግ ይህ ሁሉ ማጽዳት አለበት. እና በአጠቃላይ ታሪክን ማጽዳት ብዙውን ጊዜ ለማከማቻው ከባድ ፈተና ነው - ብዙውን ጊዜ አፈፃፀሙን በእጅጉ ይጎዳል።

የመሸጎጫ ችግሮችን እንዴት መፍታት ይቻላል?

አሁን ስለ Zabbix በተለይ እናገራለሁ. በ Zabbix ውስጥ, የመጀመሪያው እና ሁለተኛ ጥሪዎች መሸጎጫ በመጠቀም ይፈታሉ.

መረጃ መሰብሰብ እና ማቀናበር - ይህን ሁሉ ውሂብ ለማከማቸት RAM እንጠቀማለን. እነዚህ መረጃዎች አሁን በበለጠ ዝርዝር ይብራራሉ.

እንዲሁም በመረጃ ቋቱ በኩል ለዋና ምርጫዎች የተወሰነ መሸጎጫ አለ - ለግራፎች ፣ ሌሎች ነገሮች።

በራሱ ከዛቢክስ አገልጋይ ጎን መሸጎጥ፡ ConfigurationCache፣ ValueCache፣ HistoryCache፣ TrendsCache አለን። ምንድን ነው?

ConfigurationCache መለኪያዎችን፣ አስተናጋጆችን፣ ንጥሎችን፣ ቀስቅሴዎችን የምናከማችበት ዋናው መሸጎጫ ነው። ቅድመ-ሂደትን ለማስኬድ ፣ ውሂብን ለመሰብሰብ ፣ ከየትኞቹ አስተናጋጆች እንደሚሰበሰቡ ፣ በምን ድግግሞሽ ለመስራት የሚያስፈልግዎ ነገር ሁሉ። ይህ ሁሉ በ ConfigurationCache ውስጥ የተከማቸ ወደ የውሂብ ጎታ ላለመሄድ, አላስፈላጊ ጥያቄዎችን ለመፍጠር አይደለም. አገልጋዩ ከጀመረ በኋላ, ይህንን መሸጎጫ እናዘምነዋለን (እንፈጥረው) እና በየጊዜው እናዘምነዋለን (እንደ ውቅር ቅንጅቶች ይወሰናል).

በዛቢክስ ውስጥ መሸጎጫ። የውሂብ መሰብሰብ

እዚህ ስዕሉ በጣም ትልቅ ነው-

በእቅዱ ውስጥ ዋናዎቹ እነዚህ ሰብሳቢዎች ናቸው-

እነዚህ የግንባታ ሂደቶች እራሳቸው ናቸው, ለተለያዩ የግንባታ ዓይነቶች ተጠያቂ የሆኑ የተለያዩ "ፖለሮች" ናቸው. የተለያዩ ፕሮቶኮሎችን በመጠቀም መረጃን በicmp፣ ipmi ይሰበስባሉ እና ሁሉንም ወደ ቅድመ ሂደት ያስተላልፋሉ።

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

እንዲሁም፣ የተሰላ መረጃ አባሎች ካሉን (ከዛቢክስ ጋር የሚያውቁት ያውቃሉ)፣ ማለትም፣ የተሰሉ፣ የመደመር ዳታ ክፍሎች፣ በቀጥታ ከValueCache እንወስዳቸዋለን። እንዴት እንደሚሞላ, በኋላ እነግራለሁ. እነዚህ ሁሉ ሰብሳቢዎች ስራቸውን ለመቀበል ConfigurationCacheን ይጠቀማሉ እና ወደ ቅድመ ሂደት ያስተላልፋሉ።

ቅድመ ማቀናበሪያ እንዲሁም የቅድመ ሂደት ደረጃዎችን ለማግኘት ConfigurationCacheን ይጠቀማል እና ይህን ውሂብ በተለየ መንገድ ያስኬዳል። ከስሪት 4.2 ጀምሮ ወደ ፕሮክሲ ወስደነዋል። ይህ በጣም ምቹ ነው, ምክንያቱም ቅድመ-ሂደት እራሱ በጣም ከባድ ስራ ነው. እና በጣም ትልቅ Zabbix ካለህ, ብዙ ቁጥር ያላቸው የውሂብ እቃዎች እና ከፍተኛ ድግግሞሽ, ከዚያም ይህ ስራውን በእጅጉ ያመቻቻል.

በዚህ መሰረት፣ ይህን መረጃ በተወሰነ መንገድ ቅድመ-ሂደትን ተጠቅመን ከሰራን በኋላ፣ የበለጠ ለመስራት በHistoryCache ውስጥ እናስቀምጠዋለን። ይህ የመረጃ አሰባሰብን ያጠናቅቃል. ወደ ዋናው ሂደት እንሄዳለን.

የታሪክ ማመሳሰል ተግባር

በዛቢክስ ውስጥ ዋናው ሂደት (አንድ አሃዳዊ አርክቴክቸር ስለሆነ) የታሪክ ማመሳሰል ነው። ይህ የእያንዳንዱ የውሂብ አካል አቶሚክ ሂደትን ማለትም የእያንዳንዱን እሴት የሚመለከት ዋናው ሂደት ነው፡-

• ዋጋ ይመጣል (ከ HistoryCache ይወስዳል);
• በማዋቀር ማመሳሰል ውስጥ ቼኮች: ለማስላት ማንኛውም ቀስቅሴዎች ካሉ - ያሰላል;
  ካለ, ክስተቶችን ይፈጥራል, በማዋቀር አስፈላጊ ከሆነ ማንቂያ ለመፍጠር, መጨመርን ይፈጥራል;
• ለቀጣይ ሂደት ቀስቅሴዎችን ይጽፋል, ድምር; በመጨረሻው ሰዓት እና በመሳሰሉት ላይ እየሰበሰቡ ከሆነ ይህ እሴት ወደ ታሪክ ሠንጠረዥ እንዳይሄድ በ ValueCache ይታወሳል ። ስለዚህ, ValueCache ቀስቅሴዎችን, የተሰላ እቃዎችን, ወዘተ ለመገምገም በሚያስፈልገው አስፈላጊ መረጃ ተሞልቷል.
• ከዚያ የታሪክ ማመሳሰል ሁሉንም ውሂብ ወደ ዳታቤዝ ይጽፋል;
• የውሂብ ጎታው ወደ ዲስክ ይጽፋቸዋል - ይህ ሂደቱን ያጠናቅቃል.

የውሂብ ጎታ መሸጎጫ

በመረጃ ቋቱ በኩል፣ ገበታዎችን ወይም አንዳንድ ዓይነት የክስተት ሪፖርቶችን ለማየት ሲፈልጉ፣ የተለያዩ መሸጎጫዎች አሉ። ነገር ግን በዚህ ዘገባ ማዕቀፍ ውስጥ ስለእነሱ አልናገርም።

ለ MySQL፣ Innodb_buffer_pool፣ እና እንዲሁም ሊዋቀሩ የሚችሉ የተለያዩ መሸጎጫዎች ስብስብ አለ።
ግን ዋናዎቹ እነዚህ ናቸው፡-

• የተጋሩ_ማቆሚያዎች;
• ውጤታማ_መሸጎጫ_መጠን;
• የጋራ_ገንዳ።

ለሁሉም የውሂብ ጎታዎች ብዙ ጊዜ ለጥያቄዎች የሚያስፈልጉትን መረጃዎች በ RAM ውስጥ እንድታስቀምጡ የሚያስችሉ የተወሰኑ መሸጎጫዎች እንዳሉ አመጣሁ። ለዚህም የራሳቸው ቴክኖሎጂዎች አሏቸው.

ስለ ዳታቤዝ አፈጻጸም

በዚህ መሠረት, ተወዳዳሪ አካባቢ አለ, ማለትም, Zabbix አገልጋይ ውሂብ ይሰበስባል እና ይጽፋል. እንደገና ሲጀመር፣ ValueCache እና የመሳሰሉትን ለመሙላት ከታሪክ ይነበባል። እዚያው በድር በይነገጽ ላይ የተገነባውን Zabbix-API የሚጠቀሙ ስክሪፕቶች እና ሪፖርቶች ሊኖሩዎት ይችላሉ። "Zabbix" -ኤፒአይ ወደ ዳታቤዝ ገብቷል እና ግራፎችን ፣ ሪፖርቶችን ወይም አንዳንድ ዓይነት ክስተቶችን ፣ የቅርብ ጊዜ ችግሮችን ለማግኘት አስፈላጊውን ውሂብ ይቀበላል።

ሌላው በጣም ታዋቂው የእይታ መፍትሔ በተጠቃሚዎቻችን ጥቅም ላይ የሚውለው ግራፋና ነው። ሁለቱንም በ "Zabbix" -API እና በመረጃ ቋቱ በኩል በቀጥታ ማስገባት ይችላል። እንዲሁም መረጃ ለማግኘት አንዳንድ ፉክክር ይፈጥራል፡ ፈጣን የውጤት አሰጣጥ እና ለሙከራ ለማዛመድ የተሻለ፣ የተሻለ የውሂብ ጎታ ማስተካከያ ያስፈልጋል።

ታሪክን በማጽዳት ላይ። Zabbix የቤት ጠባቂ አለው።

በዛቢክስ ውስጥ ጥቅም ላይ የሚውለው ሦስተኛው ጥሪ ከቤት ጠባቂ ጋር ታሪክን ማጽዳት ነው። የቤት ጠባቂ ሁሉንም መቼቶች ያከብራል ፣ ማለትም ፣ በእኛ የውሂብ አካላት ውስጥ ምን ያህል ማከማቸት እንዳለበት (በቀናት) ፣ አዝማሚያዎችን ለምን ያህል ጊዜ ማከማቸት እና የለውጦች ተለዋዋጭነት ይጠቁማል።

ስለ TrendCash አልተናገርኩም ፣ በበረራ ላይ እናሰላለን-መረጃው ይመጣል ፣ በአንድ ሰዓት ውስጥ እንሰበስባለን (በአብዛኛው ለመጨረሻው ሰዓት ቁጥሮች) ፣ አማካይ / ዝቅተኛው መጠን እና በሰዓት አንድ ጊዜ ወደ አዝማሚያ ሰንጠረዥ እንጽፋለን። ("አዝማሚያዎች") . የቤት ሰራተኛው ከመረጃ ቋቱ ላይ መረጃን ከመረጃ ቋቱ ይጀምር እና ይሰርዛል፣ ይህም ሁልጊዜ ውጤታማ አይደለም።

ውጤታማ አለመሆኑን እንዴት መረዳት ይቻላል? በውስጣዊ ሂደቶች የአፈፃፀም ግራፎች ላይ የሚከተለውን ምስል ማየት ይችላሉ-

የእርስዎ ታሪክ ማመሳሰል ያለማቋረጥ ስራ ይበዛበታል (ቀይ ግራፍ)። እና ከላይ የሚወጣው "ቀይ" ግራፍ. ይህ "ቤት ጠባቂ" ነው የሚሰራው እና ዳታቤዙ ያስቀመጣቸውን ረድፎች በሙሉ እስኪሰርዝ ድረስ ይጠብቃል።

አንዳንድ የንጥል መታወቂያ እንውሰድ: የመጨረሻውን 5 ሺህ መሰረዝ ያስፈልግዎታል; እርግጥ ነው, በመረጃ ጠቋሚዎች. ግን ብዙውን ጊዜ የመረጃ ቋቱ በጣም ትልቅ ነው - የመረጃ ቋቱ አሁንም ከዲስክ አንብቦ ወደ መሸጎጫ ውስጥ ያስቀምጣል ፣ እና ይህ ለዳታቤዝ በጣም ውድ ክወና ነው። እንደ መጠኑ መጠን, ይህ ወደ አንዳንድ የአፈፃፀም ችግሮች ሊያመራ ይችላል.

የቤት ሰራተኛን በቀላል መንገድ ማሰናከል ይችላሉ - ለሁሉም ሰው የሚታወቅ የድር በይነገጽ አለን። በአጠቃላይ አስተዳደር ውስጥ ማቀናበር (ቅንጅቶች ለ "ቤት ጠባቂ") ለውስጣዊ ታሪክ እና አዝማሚያዎች የውስጥ የቤት አያያዝን እናሰናክላለን። በዚህ መሠረት የቤት ጠባቂ ከአሁን በኋላ ይህንን አያስተዳድርም፡-

ቀጥሎ ምን ሊደረግ ይችላል? አጥፍተውታል፣ ግራፎችዎ ተስተካክለዋል ... በዚህ ጉዳይ ላይ ምን ችግሮች ሊኖሩ ይችላሉ? ምን ሊረዳ ይችላል?

መከፋፈል (መከፋፈል)

ይህ አብዛኛውን ጊዜ በተለየ መንገድ በዘረዘርኳቸው በእያንዳንዱ ተዛማጅ ዳታቤዝ ላይ ይዋቀራል። MySQL የራሱ ቴክኖሎጂ አለው። በአጠቃላይ ግን ወደ PostgreSQL 10 እና MySQL ሲመጣ በጣም ተመሳሳይ ናቸው. በእርግጥ, ብዙ ውስጣዊ ልዩነቶች አሉ, ሁሉም እንዴት እንደሚተገበሩ እና ሁሉም በአፈፃፀም ላይ ተጽዕኖ ያሳድራሉ. ግን በአጠቃላይ ፣ አዲስ ክፍልፍል መፍጠር ብዙውን ጊዜ ወደ አንዳንድ ችግሮች ያመራል።

በማዋቀርዎ ላይ በመመስረት (በአንድ ቀን ውስጥ ምን ያህል ውሂብ እንደሚፈጥሩ) ብዙውን ጊዜ በጣም ዝቅተኛውን ያዘጋጃሉ - ይህ 1 ቀን / ክፍል ነው ፣ እና ለ “አዝማሚያዎች” ፣ የለውጦቹ ተለዋዋጭነት 1 ወር / አዲስ ክፍልፍል ነው። በጣም ትልቅ ቅንብር ካለዎት ይህ ሊለወጥ ይችላል.

ስለ ማዋቀሩ መጠን ወዲያውኑ እንነጋገር-በሴኮንድ እስከ 5 ሺህ የሚደርሱ አዳዲስ እሴቶች (nvps የሚባሉት) - ይህ እንደ ትንሽ "ማዋቀር" ይቆጠራል. መካከለኛ - ከ 5 እስከ 25 ሺህ ዋጋዎች በሰከንድ. ከላይ ያለው ሁሉም ነገር አስቀድሞ ትልቅ እና በጣም ትልቅ የሆኑ ጭነቶች ናቸው የውሂብ ጎታውን ራሱ በጥንቃቄ ማስተካከል የሚያስፈልጋቸው።

በጣም ትልቅ በሆኑ ጭነቶች ላይ፣ 1 ቀን ጥሩ ላይሆን ይችላል። እኔ በግሌ በቀን 40 ጊጋባይት የ MySQL ክፍልፋዮችን አየሁ (እና ተጨማሪ ሊኖር ይችላል)። ይህ በጣም ትልቅ መጠን ያለው የውሂብ መጠን ነው, ይህም ወደ አንዳንድ ችግሮች ሊያመራ ይችላል. መቀነስ ያስፈልገዋል.

መከፋፈል ለምን አስፈለገ?

ክፋይ የሚያደርገው፣ ሁሉም የሚያውቀው ይመስለኛል፣ የጠረጴዛ ክፍፍል ነው። ብዙውን ጊዜ እነዚህ በዲስክ እና በስፓን ጥያቄዎች ላይ የተለዩ ፋይሎች ናቸው። በመደበኛ ክፍፍል ውስጥ ከተካተተ አንድ ክፍልፍል በተሻለ ሁኔታ ይመርጣል.

ለ Zabbix ፣ በተለይም ፣ በክልል ፣ በክልል ፣ ማለትም ፣ የጊዜ ማህተም (መደበኛ ቁጥር ፣ ከዘመናት መጀመሪያ ጀምሮ) እንጠቀማለን ። የቀኑ መጀመሪያ/የቀኑን መጨረሻ ይገልፃሉ እና ክፍፍሉ ነው። በዚህ መሠረት ከሁለት ቀናት በፊት ጀምሮ መረጃን እየደረስክ ከሆነ, ሁሉም በፍጥነት ከመረጃ ቋቱ ውስጥ ይመረጣል, ምክንያቱም ወደ መሸጎጫው ለመጫን እና ለማሳየት አንድ ፋይል ብቻ ስለሚያስፈልግ (ከትልቅ ጠረጴዛ ይልቅ).

ብዙ የውሂብ ጎታዎች ማስገባትን ያፋጥኑታል (በአንድ የልጅ ሠንጠረዥ ውስጥ ማስገባት). እኔ በአብስትራክት ስናገር, ግን ደግሞ ይቻላል. መከፋፈል ብዙ ጊዜ ይረዳል።

Elasticsearch ለ NoSQL

በቅርብ ጊዜ, በ 3.4 ውስጥ, ለ NoSQL መፍትሄ ተግባራዊ እናደርጋለን. ወደ Elasticsearch የመጻፍ ችሎታ ታክሏል። አንዳንድ የተለዩ ዓይነቶችን መጻፍ ይችላሉ: ይምረጡ - ቁጥሮችን ይጻፉ, ወይም አንዳንድ ምልክቶች; የሕብረቁምፊ ጽሑፍ አለን ፣ በ Elasticsearch ውስጥ ምዝግብ ማስታወሻዎችን መጻፍ ይችላሉ… በዚህ መሠረት ፣ የድር በይነገጽ Elasticsearchንም ይደርሳል። ይህ በአንዳንድ ሁኔታዎች ጥሩ ይሰራል, ነገር ግን በአሁኑ ጊዜ ጥቅም ላይ ሊውል ይችላል.

timescaledb. ከፍተኛ ጠረጴዛዎች

ለ 4.4.2 እንደ TimescaleDB ላለ አንድ ነገር ትኩረት ሰጥተናል። ምንድን ነው? ይህ ለ Postgres ቅጥያ ነው፣ ማለትም፣ ቤተኛ የPostgreSQL በይነገጽ አለው። በተጨማሪም፣ ይህ ቅጥያ ከጊዜ ተከታታይ ውሂብ ጋር በብቃት እንዲሰሩ እና አውቶማቲክ ክፍፍል እንዲኖርዎት ይፈቅድልዎታል። ምን ይመስላል፡-

ይህ hypertable ነው - Timecale ውስጥ እንዲህ ያለ ነገር አለ. ይህ እርስዎ የፈጠሩት hypertable ነው፣ እና ቁራጮችን ይዟል። ክፋዮች ክፍልፋዮች ናቸው, እነዚህ የልጆች ጠረጴዛዎች ናቸው, ካልተሳሳትኩ. በትክክል ውጤታማ ነው።

TimescaleDB እና PostgreSQL

የTimescaleDB አምራቾች እንደሚያረጋግጡት፣ ይበልጥ ትክክለኛ የሆነ የመጠይቅ ሂደት ስልተ ቀመር ይጠቀማሉ፣በተለይ ማስገቢያዎች፣ይህም እየጨመረ በሚሄድ የውሂብ ስብስብ የማስገባት መጠን በግምት ቋሚ አፈፃፀም እንዲኖርዎት ይፈቅድልዎታል። ማለትም ከ 200 ሚሊዮን መስመሮች በኋላ ፖስትግሬስ በጣም በመጥፎ ማሽቆልቆል ይጀምራል እና አፈፃፀሙን በጥሬው ወደ ዜሮ ያጣል ፣ ታይምስካሌ ግን በማንኛውም የውሂብ መጠን በተቻለ መጠን በተቀላጠፈ ሁኔታ ማስገባትን ያስችልዎታል።

TimecaleDB እንዴት እንደሚጫን? ሁሉም ነገር ቀላል ነው!

እሱ በሰነዱ ውስጥ አለው, ይገለጻል - ለማንኛውም ከፓኬጆች ሊጭኑት ይችላሉ ... በኦፊሴላዊው የ Postgres ጥቅሎች ላይ የተመሰረተ ነው. በእጅ መሰብሰብ ይቻላል. ለዲቢ ማጠናቀር ስላለብኝ ነው።

በዛቢክስ ላይ፣ በቀላሉ ኤክስቴንሽን እናነቃለን። በፖስትግሬስ ውስጥ ኤክስቴንሽን የተጠቀሙ ይመስለኛል… ኤክስቴንሽን ብቻ ነቅተው ለምትጠቀመው የዛቢክስ ዳታቤዝ ይፍጠሩት።

እና የመጨረሻው ደረጃ ...

timescaledb. የስደት ታሪክ ሠንጠረዦች

hypertable መፍጠር አለብዎት. ለዚህ ልዩ ተግባር አለ - hypertable ይፍጠሩ. በእሱ ውስጥ, እንደ መጀመሪያው መለኪያ, በዚህ የውሂብ ጎታ ውስጥ አስፈላጊውን ሰንጠረዥ ይግለጹ (ለዚህም hypertable መፍጠር አለብዎት).

የመስክ_ጊዜ_ኢንተርቫልን ለመፍጠር እና ለመቁረጥ (ይህ የክፍሎች ክፍተት ነው (ጥቅም ላይ የሚውለው ክፍልፍሎች)። 86 አንድ ቀን ነው።

migrate_data parameter፡ ወደ እውነት ከለጠፍክ፣ ይሄ ሁሉንም የአሁኑን ውሂብ ወደ ቀድሞ የተፈጠሩ ቁርጥራጮች ያሸጋግራል።

እኔ ራሴ migrate_data ተጠቀምኩ - የውሂብ ጎታህ ምን ያህል ትልቅ እንደሆነ በመወሰን በቂ ጊዜ ይወስዳል። ከቴራባይት በላይ ነበረኝ - ለመፍጠር ከአንድ ሰዓት በላይ ፈጅቷል። በአንዳንድ አጋጣሚዎች፣ ስሞክር፣ እንዳላስተላልፍ የፅሁፉን (history_text) እና string (history_str) ታሪካዊ ዳታ ሰርዤ ነበር - እነሱ ለእኔ በጣም አስደሳች አልነበሩም።

እና በእኛ db_extention ውስጥ የመጨረሻውን ማሻሻያ እናደርጋለን፡ ዳታቤዙን እና በተለይም የእኛ ዛቢክስ ዲቢ_ኤክስቴንሽን እንዳለ እንዲገነዘብ timescaledb አዘጋጅተናል። ያነቃዋል እና ለTimescaleDB አስፈላጊ የሆኑትን "ባህሪዎች" በመጠቀም ትክክለኛውን አገባብ እና መጠይቆችን ወደ ዳታቤዝ ይጠቀማል።

የአገልጋይ ውቅር

ሁለት አገልጋዮችን ተጠቀምኩኝ. የመጀመሪያው አገልጋይ በጣም ትንሽ የሆነ ምናባዊ ማሽን ፣ 20 ፕሮሰሰር ፣ 16 ጊጋባይት ራም ነው። በላዩ ላይ Postgres 10.8 አዋቅር

ስርዓተ ክወናው ዴቢያን ነበር፣ የፋይል ስርዓቱ xfs ነበር። ዛቢክስ ራሱ የሚጠቀመውን ሳይቀንስ ይህን ልዩ የውሂብ ጎታ ለመጠቀም አነስተኛውን መቼቶች አዘጋጅቻለሁ። በዚያው ማሽን ላይ የዛቢክስ አገልጋይ፣ PostgreSQL እና የጭነት ወኪሎች ነበሩ።

በፍጥነት የተለያዩ ውጤቶችን ለማመንጨት LoadableModule የሚጠቀሙ 50 ንቁ ወኪሎችን ተጠቀምኩ። ገመዶችን, ቁጥሮችን እና የመሳሰሉትን ያመነጩት እነሱ ናቸው. ዳታቤዙን በብዙ መረጃዎች ሞላሁት። መጀመሪያ ላይ አወቃቀሩ በአንድ አስተናጋጅ 5 ሺህ የውሂብ ንጥሎችን ይዟል, እና ስለ እያንዳንዱ የውሂብ ንጥል ቀስቅሴ ይዟል - ይህ እውነተኛ ማዋቀር እንዲሆን. አንዳንድ ጊዜ ለመጠቀም ከአንድ በላይ ቀስቅሴ እንኳ ይወስዳል።

የዝማኔ ክፍተቱን፣ ጭነቱን ራሱ 50 ኤጀንቶችን በመጠቀም (ተጨማሪ በመጨመር) ብቻ ሳይሆን ተለዋዋጭ ዳታ ክፍሎችን በመጠቀም እና የዝማኔ ክፍተቱን ወደ 4 ሰከንድ እንዲቀንስ አድርጌያለሁ።

የአፈጻጸም ሙከራ. PostgreSQL፡ 36k NVPs

የመጀመሪያው ሩጫ፣ የመጀመሪያው ማዋቀር በዚህ ሃርድዌር ላይ በንጹህ PostreSQL 10 ላይ ነበር (በሴኮንድ 35 ሺህ ዋጋዎች)። በአጠቃላይ ፣ በስክሪኑ ላይ እንደሚታየው መረጃን ማስገባት የአንድ ሰከንድ ክፍልፋዮችን ይወስዳል - ሁሉም ነገር ጥሩ እና ፈጣን ነው ፣ የኤስኤስዲ ድራይቭ (200 ጊጋባይት)። ብቸኛው ነገር 20 ጂቢ በፍጥነት ይሞላል.

ለወደፊቱ ብዙ እንደዚህ ያሉ ገበታዎች ይኖራሉ. ይህ የዛቢክስ አገልጋይ መደበኛ አፈጻጸም ዳሽቦርድ ነው።

የመጀመሪያው ግራፍ በሰከንድ የእሴቶች ብዛት (ሰማያዊ ፣ ከላይ በስተግራ) ፣ በዚህ ሁኔታ 35 ሺህ እሴቶች ነው። ይህ (የላይኛው ማእከል) የግንባታ ሂደቶችን እየጫነ ነው ፣ እና ይህ (ከላይ በስተቀኝ) በትክክል የውስጥ ሂደቶችን እየጫነ ነው-የታሪክ ማመሳሰል እና የቤት ውስጥ ጠባቂ ፣ እዚህ (የታችኛው መሃል) ለተወሰነ ጊዜ እየሄደ ነው።

ይህ ግራፍ (የታችኛው መሃል) የValueCache አጠቃቀምን ያሳያል - ምን ያህል ValueCache ለመቀስቀሻዎች (በሴኮንድ ብዙ ሺህ እሴቶች) እንደሚመታ ያሳያል። ሌላው አስፈላጊ ግራፍ አራተኛው (ከታች በስተግራ) ነው, ይህም እኔ የተናገርኩትን የHistoryCache አጠቃቀም ያሳያል, ይህም ወደ ዳታቤዝ ውስጥ ከማስገባትዎ በፊት መያዣ ነው.

የአፈጻጸም ሙከራ. PostgreSQL፡ 50k NVPs

በመቀጠል ጭነቱን ወደ 50 ሺህ ዋጋዎች በአንድ ሰከንድ በተመሳሳይ ሃርድዌር ላይ ጨምሬያለሁ. በሃውስ ጠባቂው ሲጫኑ 10 ሺህ እሴቶች ቀድሞውኑ በ2-3 ሰከንድ ውስጥ በስሌቱ ተመዝግበዋል ። የትኛው፣ በእውነቱ፣ በሚከተለው ቅጽበታዊ ገጽ እይታ ላይ የሚታየው፡-

የቤት ጠባቂው መንገዱን ማቋረጥ ጀምሯል፣ ነገር ግን አጠቃላይ የታሪክ ሰሚ አጥፊዎች አጠቃቀም አሁንም በ60% (ሶስተኛ ገበታ፣ ከላይ በቀኝ) ላይ ነው። HistoryCache ቀድሞውኑ "ቤት ጠባቂ" በሚሠራበት ጊዜ በንቃት መሙላት ይጀምራል (ከታች በስተግራ). ወደ ግማሽ ጊጋባይት ነበር፣ 20% ሞልቷል።

የአፈጻጸም ሙከራ. PostgreSQL፡ 80k NVPs

በሰከንድ ወደ 80 ሺህ እሴቶች ጨምሯል፡

ወደ 400 ሺህ የውሂብ አካላት, 280 ሺህ ቀስቅሴዎች ነበር. እርስዎ እንደሚመለከቱት ፣ የታሪክ ማጠቢያዎችን ከመጫን አንፃር (30ዎቹ ነበሩ) ቀድሞውኑ በጣም ከፍተኛ ነበር። ከዚያ የተለያዩ መለኪያዎችን ጨምሬአለሁ-የታሪክ ማጠቢያዎች ፣ መሸጎጫ… በዚህ ሃርድዌር ላይ የታሪክ ማጠቢያዎች ጭነት ወደ ከፍተኛው ፣ “ወደ መደርደሪያው” ማለት ይቻላል መጨመር ጀመረ - በዚህ መሠረት HistoryCache ወደ ከፍተኛ ጭነት ሄደ ።

በዚህ ጊዜ ሁሉ የስርዓቱን ሁሉንም መመዘኛዎች እየተከታተልኩ ነበር (አቀነባባሪው እንዴት ጥቅም ላይ እንደሚውል ፣ RAM) እና የዲስክ አጠቃቀም ከፍተኛ መሆኑን አገኘሁ - በዚህ ቨርቹዋል ማሽን ውስጥ የዚህ ዲስክ ከፍተኛውን አቅም በዚህ ሃርድዌር ላይ አሳክቻለሁ። Postgres በእንደዚህ ዓይነት ጥንካሬ ላይ መረጃን በንቃት መጣል ጀመረ ፣ እና ዲስኩ ለመፃፍ ፣ ለማንበብ ጊዜ አልነበረውም…

ቀድሞውንም 48 ፕሮሰሰር 128 ጊጋባይት ራም የነበረውን ሌላ አገልጋይ ወሰድኩ።

እኔም “አስተካክዬዋለሁ” - የታሪክ ማመሳሰልን (60 ቁርጥራጮች) ጫንኩ እና ተቀባይነት ያለው አፈፃፀም አገኘሁ። እንደ እውነቱ ከሆነ, እኛ "በመደርደሪያው ውስጥ" አይደለንም, ነገር ግን ይህ ምናልባት የምርታማነት ገደብ ነው, በዚህ ጉዳይ ላይ አንድ ነገር ለማድረግ አስቀድሞ አስፈላጊ ነው.

የአፈጻጸም ሙከራ. የጊዜ መጠን ዲቢ፡ 80 ኪ NVPs

ዋና ስራዬ TimecaleDBን መጠቀም ነበር። እያንዳንዱ ግራፍ ዳይፕ ያሳያል፡-

እነዚህ ውድቀቶች የውሂብ ሽግግር ብቻ ናቸው። ከዚያ በኋላ, በዛቢክስ አገልጋይ ውስጥ, እርስዎ እንደሚመለከቱት የታሪክ-ሰመጠኞች አውርድ መገለጫ ብዙ ተለውጧል. መረጃን ወደ 3 ጊዜ ያህል በፍጥነት እንዲያስገቡ እና ያነሰ የታሪክ መሸጎጫ እንዲጠቀሙ ይፈቅድልዎታል - በዚህ መሠረት መረጃን በወቅቱ ይቀበላሉ ። እንደገና ፣ 80 ሺህ ዋጋዎች በሰከንድ በጣም ከፍተኛ መጠን ነው (በእርግጥ ፣ ለ Yandex አይደለም)። በአጠቃላይ ይህ በጣም ትልቅ ቅንብር ነው፣ ከአንድ አገልጋይ ጋር።

PostgreSQL ቤንችማርክ፡ 120K NVPs

በመቀጠል የውሂብ ክፍሎችን ቁጥር ወደ ግማሽ ሚሊዮን ከፍ በማድረግ በሴኮንድ 125 ሺህ የተሰላ እሴት አገኘሁ.

እና እነዚህን ገበታዎች አግኝተናል፡-

በመርህ ደረጃ, ይህ የሚሰራ ማዋቀር ነው, ለረጅም ጊዜ ሊሠራ ይችላል. ነገር ግን 1,5 ቴራባይት ብቻ ያለው ዲስክ ስለነበረኝ በሁለት ቀናት ውስጥ አሳለፍኩት። በጣም አስፈላጊው ነገር ፣ በተመሳሳይ ጊዜ በ TimescaleDB ላይ አዲስ ክፍልፋዮች ተፈጥረዋል ፣ እና ይህ ለአፈፃፀም ሙሉ በሙሉ የማይታወቅ ነበር ፣ ይህ ስለ MySQL ሊባል አይችልም።

ክፍልፋዮች ብዙውን ጊዜ የሚፈጠሩት በምሽት ነው ፣ ምክንያቱም ይህ ማስገባትን ያግዳል እና በአጠቃላይ ከጠረጴዛዎች ጋር ለመስራት እና የአገልግሎቱን ውድቀት ያስከትላል። በዚህ ሁኔታ, አይደለም! ዋናው ተግባር የ TimecaleDB ችሎታዎችን መሞከር ነበር። እንደዚህ ያለ አኃዝ ተገኘ-120 ሺህ ዋጋዎች በሰከንድ።

በ "ማህበረሰብ" ውስጥ ምሳሌዎችም አሉ፡-

ግለሰቡም TimecaleDB አብርቷል እና io.weight አጠቃቀም ላይ ያለውን ጭነት አንጎለ ላይ ወደቀ; እና የ TimecaleDB ን በማካተት የውስጣዊ ሂደት አካላት አጠቃቀም ቀንሷል። እና እነዚህ ተራ የፓንኬክ ዲስኮች ናቸው፣ ማለትም፣ በተራ ዲስኮች (ኤስኤስዲዎች ሳይሆን) ላይ ያለ ተራ ምናባዊ ማሽን!

በዲስክ አፈጻጸም ለተገደቡ አንዳንድ ትናንሽ ማዋቀርዎች፣ TimescaleDB ለእኔ በጣም ጥሩ መፍትሄ መስሎ ይታየኛል። ወደ ፈጣን የውሂብ ጎታ ሃርድዌር ከመሸጋገርዎ በፊት መስራትዎን መቀጠል ጥሩ ሀሳብ ነው።

ሁላችሁንም ወደ ዝግጅቶቻችን እጋብዛችኋለሁ፡ ኮንፈረንስ - በሞስኮ፣ ሰሚት - በሪጋ። የእኛን ቻናሎች ይጠቀሙ - ቴሌግራም ፣ መድረክ ፣ አይአርሲ። ማንኛቸውም ጥያቄዎች ካሉዎት ወደ መደርደሪያችን ይምጡ, ስለ ሁሉም ነገር ማውራት እንችላለን.

የተመልካቾች ጥያቄዎች

የተመልካቾች ጥያቄ (ከዚህ በኋላ - ሀ): - TimecaleDB ለማዋቀር በጣም ቀላል ከሆነ እና እንደዚህ አይነት የአፈፃፀም እድገትን ይሰጣል ፣ ታዲያ ምናልባት ይህ ዛቢቢክስን በ Postgres ለማዋቀር እንደ ምርጥ ልምምድ ጥቅም ላይ መዋል አለበት? እና የዚህ መፍትሔ ችግሮች እና ጉዳቶች አሉ ፣ ወይም አሁንም ፣ ዛቢክስን ለራሴ ለመስራት ከወሰንኩ ፣ ፖስትግሬስን በደህና መውሰድ እችላለሁ ፣ Timecalleን ወዲያውኑ እዚያ ላይ አድርጌው ፣ ተጠቀምበት እና ስለማንኛውም ችግር አላስብም?

AG - አዎ፣ በTimescaleDB ቅጥያ ወዲያውኑ Postgresን መጠቀም ጥሩ ምክር ነው እላለሁ። እንዳልኩት, ይህ "ባህሪ" የሙከራ ቢሆንም, ብዙ ጥሩ ግምገማዎች. ግን በእውነቱ ሙከራዎች ጥሩ መፍትሄ መሆኑን ያሳያሉ (በTimescaleDB) እና በዝግመተ ለውጥ ይመጣል ብዬ አስባለሁ! ይህ ቅጥያ እንዴት እንደሚዳብር እንከታተላለን እና አስፈላጊውን ነገር ያስተካክላል።

በእድገት ወቅት ከሚታወቁት "ባህሪያቶቻቸው" በአንዱ ላይ እንኳን እንመካለን: እዚያ ትንሽ ለየት ባለ መልኩ ከቆርቆሮዎች ጋር መስራት ይቻል ነበር. ግን ከዚያ በሚቀጥለው ልቀት ላይ ቆርጠዋል፣ እና በዚህ ኮድ ከአሁን በኋላ መተማመን የለብንም። ይህንን መፍትሄ በብዙ ማዘጋጃዎች ላይ እንዲጠቀሙ እመክራለሁ. MySQL እየተጠቀምክ ከሆነ... ለመካከለኛ ውቅሮች፣ የትኛውም መፍትሔ ጥሩ ይሰራል።

መ - ከማህበረሰቡ በመጡ የቅርብ ጊዜ ገበታዎች ላይ “ቤት ጠባቂ” ያለው ገበታ ነበረ።

ሥራውን ቀጠለ። የቤት ሰራተኛ በ TimecaleDB ምን ያደርጋል?

AG - አሁን በእርግጠኝነት መናገር አልችልም - ኮዱን ተመልክቼ በበለጠ ዝርዝር እነግርዎታለሁ. የTimescaleDB መጠይቆችን ቁርጥራጮችን ለማስወገድ ሳይሆን እንደምንም ጠቅለል አድርጎ ይጠቀማል። ይህንን ቴክኒካዊ ጥያቄ ለመመለስ ዝግጁ ባልሆንም። ዛሬ ወይም ነገ በቆመበት ቦታ ላይ እናብራራለን.

መ - ተመሳሳይ ጥያቄ አለኝ - በ Timecale ውስጥ ስላለው የመሰረዝ አሠራር አፈፃፀም።
ሀ (ከተመልካቾች የተሰጠ መልስ): - መረጃን ከጠረጴዛ ላይ ሲሰርዙ, በሰርዝ በኩል ካደረጉት, ከዚያም በጠረጴዛው ውስጥ ማለፍ ያስፈልግዎታል - ሰርዝ, ማጽዳት, ለወደፊቱ ቫክዩም ሁሉንም ነገር ምልክት ያድርጉ. በTimescale ውስጥ፣ ቁርጥራጭ ነገር ስላሎት፣ መጣል ይችላሉ። በግምት፣ በትልቁ ውሂብ ውስጥ ያለውን ፋይል ብቻ ይንገሩት፡- “ሰርዝ!”

Timecale በቀላሉ እንደዚህ ያለ ቁራጭ ከአሁን በኋላ እንደሌለ ይገነዘባል። እና ወደ መጠይቁ እቅድ አውጪው ጋር ስለሚዋሃድ፣ ሁኔታዎን በምርጫም ሆነ በሌሎች ኦፕሬሽኖች ውስጥ ያያይዘዋል እና ይህ ቁራጭ ከአሁን በኋላ እንደሌለ ወዲያውኑ ይገነዘባል - “ከዚህ በኋላ ወደዚያ አልሄድም!” (ውሂቡ አይገኝም)። ይኼው ነው! ያም ማለት የሠንጠረዥ ቅኝት በሁለትዮሽ ፋይል መሰረዝ ተተካ, ስለዚህ ፈጣን ነው.

መ - ቀደም ሲል SQL ሳይሆን ርዕሰ ጉዳዩን ነክተናል. እኔ እስከሚገባኝ ድረስ Zabbix በእርግጥ ውሂቡን ማሻሻል አያስፈልገውም ፣ እና ይህ ሁሉ እንደ ሎግ ያለ ነገር ነው። ውሂባቸውን መለወጥ የማይችሉ ልዩ የውሂብ ጎታዎችን መጠቀም ይቻላል, ግን በተመሳሳይ ጊዜ ማስቀመጥ, ማከማቸት, በፍጥነት መመለስ - Clickhouse, ለምሳሌ, ካፍካ የሚመስል ነገር?... ካፍካ እንዲሁ መዝገብ ነው! በሆነ መንገድ እነሱን ማዋሃድ ይቻላል?

AG - ማራገፍ ይቻላል. ከስሪት 3.4 ጀምሮ የተወሰነ "ባህሪ" አለን: ሁሉንም ታሪካዊ ፋይሎችን, ክስተቶችን, ሁሉንም ነገር ወደ ፋይሎች መጻፍ ይችላሉ; እና ከዚያ የተወሰነ ተቆጣጣሪ ወደ ሌላ ማንኛውም የውሂብ ጎታ ይላኩ። እንደ እውነቱ ከሆነ, ብዙ ሰዎች እንደገና ይሠራሉ እና በቀጥታ ወደ የውሂብ ጎታ ይጽፋሉ. በመብረር ላይ፣ የታሪክ አስመጪዎች ይህንን ሁሉ ወደ ፋይሎች ይጽፋሉ፣ እነዚህን ፋይሎች ያሽከርክሩ እና የመሳሰሉትን እና ይህንን ወደ Clickhouse ማስተላለፍ ይችላሉ። ዕቅዶቹ ምን እንደሆኑ መናገር አልችልም፣ ግን ምናልባት ለ NoSQL መፍትሄዎች (እንደ Clickhouse ያሉ) ተጨማሪ ድጋፍ ይቀጥላል።

መ - በአጠቃላይ ፣ ፖስትግሬስን ሙሉ በሙሉ ማስወገድ እንደሚችሉ ይገለጣል?

AG - በእርግጥ በዛቢክስ ውስጥ በጣም አስቸጋሪው ክፍል ብዙ ችግሮችን እና ክስተቶችን የሚፈጥሩ ታሪካዊ ጠረጴዛዎች ናቸው ። በዚህ ሁኔታ, ክስተቶችን ለረጅም ጊዜ ካላከማቹ እና ታሪክን ከሌሎች አንዳንድ ፈጣን ማከማቻዎች አዝማሚያዎች ጋር ካላከማቹ, በአጠቃላይ, ምንም ችግሮች አይኖሩም ብዬ አስባለሁ.

መ - ለምሳሌ ወደ Clickhouse ከቀየሩ ሁሉም ነገር ምን ያህል በፍጥነት እንደሚሰራ መገመት ይችላሉ?

AG - አልሞከርኩትም። እኔ እንደማስበው Clickhouse የራሱ የሆነ በይነገጽ ስላለው ቢያንስ ተመሳሳይ ቁጥሮች በቀላሉ ሊገኙ ይችላሉ, ግን በእርግጠኝነት መናገር አልችልም. መፈተሽ ይሻላል። ሁሉም በአወቃቀሩ ላይ የተመሰረተ ነው: ምን ያህል አስተናጋጆች እንዳሉዎት እና ወዘተ. ማስገባት አንድ ነገር ነው፣ ግን ይህን ውሂብ መውሰድም ያስፈልግዎታል - ግራፋና ወይም ሌላ።

መ - ማለትም, ስለ እኩል ውጊያ እየተነጋገርን ነው, እና ስለ እነዚህ ፈጣን የውሂብ ጎታዎች ትልቅ ጥቅም አይደለም?

AG - እንደማስበው ስንዋሃድ የበለጠ ትክክለኛ ፈተናዎች ይኖራሉ።

መ አሮጌው RRD የት ሄደ? ወደ SQL ዳታቤዝ እንዲቀይሩ ያደረገው ምንድን ነው? መጀመሪያ ላይ ሁሉም መለኪያዎች የተሰበሰቡት በ RRD ላይ ነው።

AG - በ "Zabbix" RRD, ምናልባት በጣም ጥንታዊ በሆነ ስሪት ውስጥ. ሁልጊዜም የ SQL የውሂብ ጎታዎች ነበሩ - ክላሲክ አቀራረብ። ክላሲክ አቀራረብ MySQL, PostgreSQL ነው (በጣም ለረጅም ጊዜ ነበሩ). ለ SQL እና RRD የውሂብ ጎታዎች የጋራ በይነገጽ አልተጠቀምንም ማለት ይቻላል።

አንዳንድ ማስታወቂያዎች 🙂

ከእኛ ጋር ስለቆዩ እናመሰግናለን። ጽሑፎቻችንን ይወዳሉ? የበለጠ አስደሳች ይዘት ማየት ይፈልጋሉ? ትእዛዝ በማዘዝ ወይም ለጓደኞች በመምከር ይደግፉን፣ ደመና ቪፒኤስ ለገንቢዎች ከ$4.99, በእኛ ለእርስዎ የተፈለሰፈው ልዩ የመግቢያ ደረጃ አገልጋዮች አናሎግ፡- ስለ VPS (KVM) ሙሉ እውነት E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps ከ$19 ወይንስ እንዴት አገልጋይ መጋራት ይቻላል? (በRAID1 እና RAID10፣ እስከ 24 ኮሮች እና እስከ 40GB DDR4 ድረስ ይገኛል።

በአምስተርዳም ውስጥ በ Equinix Tier IV የመረጃ ማዕከል ውስጥ Dell R730xd 2x ርካሽ? እዚህ ብቻ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ከ$199 በኔዘርላንድስ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ከ$99! ስለ አንብብ የመሠረተ ልማት ኮርፖሬሽን እንዴት እንደሚገነባ ክፍል ጋር Dell R730xd E5-2650 v4 አገልጋዮች ዋጋ 9000 አንድ ሳንቲም ዩሮ?

ምንጭ: hab.com