የበርካታ ጊዜ ተከታታይ ዳታቤዞችን እንዴት እንደሞከርን

ባለፉት ጥቂት አመታት ውስጥ፣ ተከታታይ ጊዜ ያላቸው የውሂብ ጎታዎች ከአገር ውጪ የሆነ ነገር (በጣም ልዩ የሆነ በክፍት የክትትል ስርዓቶች (እና ከተወሰኑ መፍትሄዎች ጋር የተቆራኘ) ወይም በትልቁ ዳታ ፕሮጄክቶች ውስጥ) ወደ "የሸማች ምርት" ተለውጠዋል። በሩሲያ ፌዴሬሽን ግዛት ውስጥ ለ Yandex እና ClickHouse ልዩ ምስጋናዎች መሰጠት አለባቸው. እስከዚህ ነጥብ ድረስ፣ ብዙ ተከታታይ ጊዜ ያለው መረጃ ማከማቸት ካስፈለገዎት አንድም አስፈሪ የሃዱፕ ቁልል መገንባት እና እሱን ማቆየት ወይም ለእያንዳንዱ ስርዓት ከፕሮቶኮሎች ጋር መገናኘት አስፈላጊ መሆኑን ማወቅ አለብዎት።

እ.ኤ.አ. በ 2019 TSDB ጥቅም ላይ መዋል ያለበት አንድ ጽሑፍ አንድ ዓረፍተ ነገር ብቻ የሚይዝ ሊመስል ይችላል፡ “ክሊክ ሃውስን ብቻ ይጠቀሙ። ግን... አንዳንድ ነገሮች አሉ።

በእርግጥ ClickHouse በንቃት እያደገ ነው፣ የተጠቃሚው መሰረት እያደገ ነው፣ እና ድጋፍ በጣም ንቁ ነው፣ ነገር ግን ሌሎች ምናልባትም ይበልጥ ውጤታማ/አስተማማኝ መፍትሄዎችን ለጨረሰው የ ClickHouse ህዝባዊ ስኬት ታጋቾች ሆነናል?

ባለፈው አመት መጀመሪያ ላይ የራሳችንን የክትትል ስርዓት እንደገና መስራት ጀመርን, በዚህ ጊዜ መረጃን ለማከማቸት ተስማሚ የውሂብ ጎታ የመምረጥ ጥያቄ ተነስቷል. እዚህ ስለ ምርጫው ታሪክ ማውራት እፈልጋለሁ.

የችግሩ ቀመር

በመጀመሪያ ደረጃ, አስፈላጊ የሆነ መቅድም. የራሳችንን የክትትል ስርዓት ለምን ያስፈልገናል እና እንዴት ተዘጋጀ?

እ.ኤ.አ. በ 2008 የድጋፍ አገልግሎት መስጠት ጀመርን ፣ እና በ 2010 በደንበኛው መሠረተ ልማት ውስጥ ስለሚከናወኑ ሂደቶች በወቅቱ ከነበሩት መፍትሄዎች ጋር መረጃን ማሰባሰብ አስቸጋሪ እየሆነ መጣ (እየተናገረን ነው ፣ እግዚአብሔር ይቅር በለኝ ፣ Cacti ፣ Zabbix)። እና ብቅ ያለው ግራፋይት).

ዋና ፍላጎቶቻችን የሚከተሉት ነበሩ፡-

• ድጋፍ (በዚያን ጊዜ - በደርዘን የሚቆጠሩ, እና ለወደፊቱ - በመቶዎች የሚቆጠሩ) ደንበኞች በአንድ ስርዓት ውስጥ እና በተመሳሳይ ጊዜ የተማከለ የማንቂያ አስተዳደር ስርዓት መኖር;
• የማንቂያ ስርዓቱን ለማስተዳደር ተለዋዋጭነት (በተረኛ መኮንኖች መካከል ያሉ ማንቂያዎች መጨመር, የጊዜ ሰሌዳ, የእውቀት መሰረት);
• ግራፎችን በጥልቀት የመዘርዘር ችሎታ (በዛን ጊዜ ዛቢቢክስ በስዕሎች መልክ የተቀረጹ ግራፎች);
• ከፍተኛ መጠን ያለው መረጃ (አንድ አመት ወይም ከዚያ በላይ) የረጅም ጊዜ ማከማቻ እና በፍጥነት የማውጣት ችሎታ።

በዚህ ጽሑፍ ውስጥ በመጨረሻው ነጥብ ላይ ፍላጎት አለን.

ስለ ማከማቻው ስንናገር መስፈርቶቹ የሚከተሉት ነበሩ።

• ስርዓቱ በፍጥነት መስራት አለበት;
• ስርዓቱ የ SQL በይነገጽ እንዲኖረው ተፈላጊ ነው;
• ስርዓቱ የተረጋጋ እና ንቁ የተጠቃሚ መሰረት እና ድጋፍ ሊኖረው ይገባል (አንድ ጊዜ እንደ MemcacheDB ያሉ ስርዓቶችን የመደገፍ አስፈላጊነት ሲያጋጥመን፣ ከአሁን በኋላ ያልተሻሻለው ወይም MooseFS የተከፋፈለ ማከማቻ፣ የሳንካ መከታተያ በቻይንኛ ተቀምጧል። ይህንን ታሪክ እንደግመዋለን ለፕሮጀክታችን አልፈለገም);
• ከ CAP ቲዎሬም ጋር መጣጣም: ወጥነት (አስፈላጊ) - መረጃው ወቅታዊ መሆን አለበት, የማንቂያ አስተዳደር ስርዓቱ አዲስ ውሂብ እንዳይቀበል እና ለሁሉም ፕሮጀክቶች መረጃ አለመምጣቱን ማንቂያዎችን እንዲተፋ አንፈልግም; ክፍልፍል መቻቻል (የሚያስፈልግ) - እኛ የተከፈለ የአንጎል ሥርዓት ማግኘት አንፈልግም; መገኘት (ወሳኝ አይደለም, ንቁ ቅጂ ካለ) - ኮድን በመጠቀም በአደጋ ጊዜ እራሳችንን ወደ የመጠባበቂያ ስርዓቱ መቀየር እንችላለን.

በሚገርም ሁኔታ፣ በዚያን ጊዜ MySQL ለኛ ተስማሚ መፍትሄ ሆኖ ተገኘ። የእኛ የውሂብ መዋቅር እጅግ በጣም ቀላል ነበር፡ የአገልጋይ መታወቂያ፣ ቆጣሪ መታወቂያ፣ የጊዜ ማህተም እና እሴት; ፈጣን የሙቅ መረጃ ናሙና በትልቁ ቋት ገንዳ የተረጋገጠ ሲሆን የታሪካዊ መረጃ ናሙና በኤስኤስዲ ተረጋግጧል።

ስለዚህ፣ መረጃው ሙሉ በሙሉ ከመሰራቱ በፊት እስከ 200 ሚሴ ድረስ በዝርዝር በመያዝ የሁለት ሳምንት አዲስ መረጃ ናሙና አግኝተናል እና በዚህ ስርዓት ውስጥ ለረጅም ጊዜ ኖረናል።

ይህ በእንዲህ እንዳለ, ጊዜ አለፈ እና የውሂብ መጠን እያደገ. እ.ኤ.አ. በ 2016 የውሂብ መጠን በአስር ቴራባይት ደርሷል ፣ ይህም በተከራየው የኤስኤስዲ ማከማቻ አውድ ውስጥ ከፍተኛ ወጪ ነበር።

በዚህ ጊዜ, የአዕማዱ የውሂብ ጎታዎች በንቃት ተስፋፍተዋል, እኛ በንቃት ማሰብ ጀመርን: በአዕማዱ የውሂብ ጎታዎች ውስጥ, እርስዎ እንደሚረዱት, በአምዶች ውስጥ, ውሂብ ይከማቻል, እና የእኛን ውሂብ ከተመለከቱ, አንድ ትልቅ ለማየት ቀላል ነው. የአምድ ዳታቤዝ ከተጠቀሙ መጭመቂያን በመጠቀም መጭመቅ የሚችሉ የተባዙ ብዛት።

ይሁን እንጂ የኩባንያው ቁልፍ ስርዓት በተረጋጋ ሁኔታ መስራቱን ቀጥሏል, እና ወደ ሌላ ነገር ለመቀየር መሞከር አልፈልግም.

እ.ኤ.አ. በ 2017 ፣ በሳን ሆሴ ውስጥ በፔርኮና ላይቭ ኮንፈረንስ ፣ የክሊክሃውስ ገንቢዎች ምናልባት ለመጀመሪያ ጊዜ እራሳቸውን አሳውቀዋል። በአንደኛው እይታ ስርዓቱ ለምርት ዝግጁ ነበር (ጥሩ ፣ Yandex.Metrica ከባድ የምርት ስርዓት ነው) ፣ ድጋፍ ፈጣን እና ቀላል ነበር ፣ እና ከሁሉም በላይ ፣ አሠራሩ ቀላል ነበር። ከ 2018 ጀምሮ የሽግግሩን ሂደት ጀምረናል. ነገር ግን በዚያን ጊዜ፣ ብዙ “አዋቂዎች” እና በጊዜ የተፈተኑ የ TSDB ስርዓቶች ነበሩ፣ እና እንደፍላጎታችን ለ Clickhouse ምንም አማራጭ መፍትሄዎች አለመኖራቸውን ለማረጋገጥ ብዙ ጊዜ ለመስጠት እና አማራጮችን ለማወዳደር ወስነናል።

ቀደም ሲል ከተገለጹት የማከማቻ መስፈርቶች በተጨማሪ አዳዲሶች ታይተዋል፡

• አዲሱ ስርዓት ቢያንስ ተመሳሳይ የሃርድዌር መጠን ላይ MySQL ጋር ተመሳሳይ አፈጻጸም ማቅረብ አለበት;
• የአዲሱ ስርዓት ማከማቻ በጣም ያነሰ ቦታ መያዝ አለበት ፣
• DBMS አሁንም ለማስተዳደር ቀላል መሆን አለበት;
• ዲቢኤምኤስን በሚቀይርበት ጊዜ አፕሊኬሽኑን በትንሹ ለመቀየር ፈልጌ ነበር።

የትኞቹን ስርዓቶች ግምት ውስጥ ማስገባት ጀመርን?

Apache Hive/Apache Impala
የቆየ፣ በውጊያ የተፈተነ የሃዱፕ ቁልል። በመሠረቱ፣ በኤችዲኤፍኤስ ላይ በአገርኛ ቅርጸቶች መረጃን በማከማቸት ላይ የተገነባ የSQL በይነገጽ ነው።

ጥቅም.

• በተረጋጋ አሠራር, ውሂብን ለመለካት በጣም ቀላል ነው.
• ለመረጃ ማከማቻ (ያነሰ ቦታ) የአምድ መፍትሄዎች አሉ።
• ሀብቶች በሚገኙበት ጊዜ ትይዩ ተግባራትን በጣም ፈጣን አፈፃፀም።

Cons:

• ሃዱፕ ነው፣ እና ለመጠቀም አስቸጋሪ ነው። በደመና ውስጥ የተዘጋጀ መፍትሄ ለመውሰድ ዝግጁ ካልሆንን (በዋጋም ዝግጁ ካልሆንን) ሙሉ ቁልል በአስተዳዳሪዎች ተሰብስቦ መደገፍ አለበት እና በእውነት አንፈልግም። ይህ.
• መረጃው ተደምሮ ነው። በጣም ፈጣን.

ሆኖም

ፍጥነት የሚገኘው የኮምፒዩተር አገልጋዮችን ቁጥር በመለካት ነው። በቀላል አነጋገር ትልቅ ኩባንያ ከሆንን በመተንተን ላይ የተሰማራን እና ንግዱ በተቻለ ፍጥነት መረጃን ማሰባሰብ በጣም አስፈላጊ ነው (ምንም እንኳን ከፍተኛ መጠን ያለው የኮምፒዩተር ሀብቶችን ለመጠቀም በሚያስከፍል ወጪ) ይህ የእኛ ምርጫ ሊሆን ይችላል። ነገር ግን ስራዎችን ለማፋጠን የሃርድዌር መርከቦችን ለማባዛት ዝግጁ አልነበርንም።

ድሩይድ/ፒኖት።

ስለ TSDB በተለይ ብዙ ነገር አለ፣ ግን በድጋሚ፣ የሃዱፕ ቁልል።

አሉ የድሩይድ እና ፒኖትን ከ ClickHouse ጋር የሚያነፃፅር ታላቅ መጣጥፍ .

በጥቂት ቃላት፡- Druid/Pint በሚከተሉት ጉዳዮች ላይ ከ Clickhouse የተሻለ ይመስላል፡-

• የተለያዩ የውሂብ ተፈጥሮ አለህ (በእኛ ሁኔታ የአገልጋይ መለኪያዎችን ብቻ እንመዘግባለን ፣ እና በእውነቱ ፣ ይህ አንድ ሠንጠረዥ ነው ። ግን ሌሎች ጉዳዮች ሊኖሩ ይችላሉ-የመሳሪያ ጊዜ ተከታታይ ፣ ኢኮኖሚያዊ ጊዜ ተከታታይ ፣ ወዘተ. የራሱ መዋቅር, ማሰባሰብ እና ማቀናበር ያስፈልገዋል).
• ከዚህም በላይ ይህ መረጃ በጣም ብዙ ነው.
• የሰዓት ተከታታዮች ያላቸው ሰንጠረዦች እና ውሂቦች ይታያሉ እና ይጠፋሉ (ማለትም፣ አንዳንድ የውሂብ ስብስብ ደርሷል፣ ተንትኖ እና ተሰርዟል)።
• መረጃ የሚከፋፈልበት ግልጽ መስፈርት የለም።

በተቃራኒ ሁኔታዎች, ClickHouse በተሻለ ሁኔታ ይሰራል, እና ይህ የእኛ ጉዳይ ነው.

ጠቅታ ቤት

• SQL-እንደ
• ለማስተዳደር ቀላል።
• ሰዎች ይሰራል ይላሉ።

ለሙከራ በእጩዎች ዝርዝር ውስጥ ገብቷል።

InfluxDB

ከ ClickHouse ሌላ አማራጭ። ከመቀነሱ ውስጥ: ከፍተኛ ተገኝነት በንግድ ስሪት ውስጥ ብቻ ነው, ነገር ግን ማወዳደር ያስፈልገዋል.

ለሙከራ በእጩዎች ዝርዝር ውስጥ ገብቷል።

ካሳንድራ

በአንድ በኩል፣ በመሳሰሉት የክትትል ሥርዓቶች፣ ለምሳሌ፣ ሲግናልኤፍክስ ወይም OkMeter. ሆኖም, ልዩ ሁኔታዎች አሉ.

ካሳንድራ በባህላዊ መልኩ የአምድ ዳታቤዝ አይደለም። እሱ የረድፍ እይታን ይመስላል ፣ ግን እያንዳንዱ መስመር የተለያዩ የአምዶች ብዛት ሊኖረው ይችላል ፣ ይህም የአምድ እይታን ለማደራጀት ቀላል ያደርገዋል። ከዚህ አንፃር በ 2 ቢሊዮን ዓምዶች ገደብ አንዳንድ መረጃዎችን በአምዶች (እና በተመሳሳይ ጊዜ ተከታታይ) ማከማቸት እንደሚቻል ግልጽ ነው. ለምሳሌ በ MySQL ውስጥ የ 4096 አምዶች ገደብ አለ እና ተመሳሳይ ለማድረግ ከሞከሩ በ 1117 ኮድ ስህተት ላይ መሰናከል ቀላል ነው.

የካሳንድራ ሞተር ከፍተኛ መጠን ያለው ዳታ በማከማቸት ላይ ያተኮረ ያለ ማስተር ሲሆን ከላይ የተጠቀሰው የካሳንድራ CAP ቲዎረም ስለ ኤፒ ማለትም ስለመረጃ መገኘት እና መከፋፈልን መቋቋም ነው። ስለዚህ ወደዚህ ዳታቤዝ ብቻ መጻፍ እና ብዙም ማንበብ ካልቻሉ ይህ መሳሪያ በጣም ጥሩ ሊሆን ይችላል። እና እዚህ ካሳንድራን እንደ "ቀዝቃዛ" ማከማቻ መጠቀም ምክንያታዊ ነው. ያም ማለት እንደ ረጅም ጊዜ አስተማማኝ ቦታ ብዙ የማይፈለጉ ታሪካዊ መረጃዎችን ለማከማቸት አስፈላጊ ከሆነ ግን ሊገኝ ይችላል. ቢሆንም፣ ለሙሉነት ሲባል፣ እኛም እንፈትነዋለን። ግን ፣ ቀደም ብዬ እንደገለጽኩት ፣ ለተመረጠው የውሂብ ጎታ መፍትሄ ኮድን በንቃት እንደገና ለመፃፍ ምንም ፍላጎት የለም ፣ ስለሆነም እኛ በተወሰነ መጠን እንሞክራለን - የውሂብ ጎታውን መዋቅር ከካሳንድራ ልዩ ሁኔታዎች ጋር ሳናስተካክል።

ፕሮሚትየስ

ደህና ፣ ከጉጉት የተነሳ ፣ እኛ የፕሮሜቲየስ ማከማቻን አፈፃፀም ለመፈተሽ ወሰንን - አሁን ካሉ መፍትሄዎች ፈጣን ወይም ቀርፋፋ መሆናችንን እና በምን ያህል መጠን ለመረዳት።

የሙከራ ዘዴ እና ውጤቶች

ስለዚህ፣ በሚከተሉት 5 ውቅሮች ውስጥ 6 የውሂብ ጎታዎችን ሞክረናል፡ ClickHouse (1 node)፣ ClickHouse (ለ 3 ኖዶች የተከፋፈለ ሰንጠረዥ)፣ InfluxDB፣ Mysql 8፣ Cassandra (3 nodes) እና Prometheus። የፈተናው እቅድ እንደሚከተለው ነው።

1. ለአንድ ሳምንት ያህል ታሪካዊ መረጃን ይስቀሉ (በቀን 840 ሚሊዮን ዋጋዎች; 208 ሜትሪክስ);
2. የመቅጃ ጭነት እንፈጥራለን (6 የመጫኛ ሁነታዎች ግምት ውስጥ ገብተዋል, ከታች ይመልከቱ);
3. ከመቅዳት ጋር በትይዩ፣ ከገበታዎች ጋር የሚሰራውን የተጠቃሚ ጥያቄዎችን በመምሰል በየጊዜው ምርጫዎችን እናደርጋለን። ነገሮችን ከመጠን በላይ ላለማወሳሰብ ለአንድ ሳምንት ያህል መረጃን ለ 10 ሜትሪክስ መርጠናል (በሲፒዩ ግራፍ ላይ በትክክል ስንት ናቸው)።

በየ15 ሰከንድ አንድ ጊዜ እሴቶችን ወደ እያንዳንዱ መለኪያ የሚልክ የክትትል ወኪላችንን ባህሪ በመምሰል እንጭናለን። በተመሳሳይ ጊዜ፣ ለመለያየት ፍላጎት አለን፡-

• ውሂቡ የተፃፈበት አጠቃላይ የመለኪያዎች ብዛት;
• እሴቶችን ወደ አንድ መለኪያ ለመላክ ክፍተት;
• የምድብ መጠን.

ስለ ባች መጠን። ሁሉንም የእኛን የሙከራ ዳታቤዞች በነጠላ ማስገቢያዎች መጫን የማይመከር በመሆኑ፣ መጪ መለኪያዎችን የሚሰበስብ እና በቡድን በቡድን የሚያከፋፍል እና እንደ ባች ማስገቢያ ወደ ዳታቤዝ የሚጽፍ ቅብብል ያስፈልገናል።

እንዲሁም ፣ የተቀበለውን ውሂብ እንዴት እንደሚተረጉም በተሻለ ለመረዳት ፣ እኛ ብዙ ልኬቶችን እየላክን እንዳልሆነ እናስብ ፣ ግን መለኪያዎች በአገልጋዮች የተደራጁ ናቸው - በአንድ አገልጋይ 125 ሜትሪክ። እዚህ አገልጋዩ በቀላሉ ምናባዊ አካል ነው - ለመገንዘብ ያህል፣ ለምሳሌ 10000 ሜትሪክስ ከ80 አገልጋዮች ጋር ይዛመዳል።

እና እዚህ ፣ ይህንን ሁሉ ከግምት ውስጥ በማስገባት ፣ የእኛ 6 የውሂብ ጎታ የመፃፍ ሁነታዎች አሉ ።

እዚህ ሁለት ነጥቦች አሉ. በመጀመሪያ ፣ ለካሳንድራ እነዚህ የመጠን መጠኖች በጣም ትልቅ ሆነው ቆይተዋል ፣ እዚያ 50 ወይም 100 እሴቶችን እንጠቀማለን ። በሁለተኛ ደረጃ ፣ ፕሮሜቲየስ በጥብቅ በሚጎትት ሁኔታ ውስጥ ስለሚሰራ ፣ ማለትም። እሱ ራሱ ሄዶ መረጃን ከመለኪያ ምንጮች ይሰበስባል (እና ሌላው ቀርቶ የግፋ መግቢያ ዌይ ፣ ምንም እንኳን ስሙ ቢሆንም ፣ ሁኔታውን በመሠረታዊነት አይለውጥም) ፣ ተዛማጅ ጭነቶች የስታቲክ ውቅሮች ጥምረት በመጠቀም ተተግብረዋል።

የፈተና ውጤቶቹ የሚከተሉት ናቸው።

ልብ ሊባል የሚገባው ነገር ምንድን ነውከፕሮሜቴየስ እጅግ በጣም ፈጣን የሆኑ ናሙናዎች፣ በጣም ቀርፋፋ ናሙናዎች ከካሳንድራ፣ ተቀባይነት የሌላቸው ቀርፋፋ ናሙናዎች ከ InfluxDB; ከመቅዳት ፍጥነት አንፃር ፣ ClickHouse ሁሉንም ሰው አሸንፏል ፣ እና ፕሮሜቲየስ በውድድሩ ውስጥ አይሳተፍም ፣ ምክንያቱም እሱ ራሱ ማስገቢያዎችን ስለሚሰራ እና ምንም ነገር አንለካም።

በዚህም ምክንያት,: ClickHouse እና InfluxDB እራሳቸውን ምርጥ ሆነው አሳይተዋል ነገር ግን ከ Influx ክላስተር ሊገነባ የሚችለው በኢንተርፕራይዝ ስሪት ላይ ብቻ ነው, ይህም ገንዘብ ያስወጣል, ClickHouse ምንም ወጪ የማይጠይቅ እና በሩሲያ ውስጥ ነው. በዩኤስኤ ውስጥ ምርጫው ምናልባት influxDB የሚደግፍ መሆኑ ምክንያታዊ ነው, እና በአገራችን ውስጥ ለ ClickHouse ድጋፍ ነው.

ምንጭ: hab.com