Clickhouseን እንደ ELK፣ Big Query እና TimescaleDB ምትክ መጠቀም

ጠቅታ ቤት በ Yandex የተፈጠረ ክፍት ምንጭ የአምድ ዳታቤዝ አስተዳደር ስርዓት ለመስመር ላይ የትንታኔ መጠየቂያ ሂደት (OLAP) ነው። በ Yandex, CloudFlare, VK.com, Badoo እና በዓለም ዙሪያ ያሉ ሌሎች አገልግሎቶች በእውነቱ ከፍተኛ መጠን ያለው ውሂብ ለማከማቸት (በሴኮንድ በሺዎች የሚቆጠሩ ረድፎችን ማስገባት ወይም በዲስክ ላይ የተከማቸ ፔታባይት ውሂብ) ይጠቀማል።

በመደበኛ፣ “ሕብረቁምፊ” ዲቢኤምኤስ፣ የነሱ ምሳሌዎች MySQL፣ Postgres፣ MS SQL አገልጋይ፣ ውሂብ በሚከተለው ቅደም ተከተል ተቀምጧል።

Clickhouseን እንደ ELK፣ Big Query እና TimescaleDB ምትክ መጠቀም

በዚህ ሁኔታ፣ ከአንድ ረድፍ ጋር የተያያዙ እሴቶች በአካል በአቅራቢያው ይከማቻሉ። በአምድ ዲቢኤምኤስ ውስጥ፣ ከተለያዩ ዓምዶች የተውጣጡ እሴቶች ለየብቻ ይቀመጣሉ፣ እና ከአንድ አምድ የመጣ ውሂብ አንድ ላይ ይከማቻል፡

Clickhouseን እንደ ELK፣ Big Query እና TimescaleDB ምትክ መጠቀም

የአዕማድ ዲቢኤምኤስ ምሳሌዎች Vertica፣ Paraccel (Actian Matrix፣ Amazon Redshift)፣ Sybase IQ፣ Exasol፣ Infobright፣ InfiniDB፣ MonetDB (VectorWise፣ Actian Vector)፣ LucidDB፣ SAP HANA፣ Google Dremel፣ Google PowerDrill፣ Druid፣ kdb+ ናቸው።

ደብዳቤ አስተላላፊ ኩባንያ Qwintry እ.ኤ.አ. በ2018 ለሪፖርት ማድረጊያ Clickhouseን መጠቀም የጀመረ ሲሆን በቀላልነቱ፣ በመጠን አቅሙ፣ በSQL ድጋፍ እና ፍጥነት በጣም ተደንቋል። የዚህ ዲቢኤምኤስ ፍጥነት በአስማት ላይ ተወስኗል።

ቀላልነት።

Clickhouse በአንድ ነጠላ ትዕዛዝ በኡቡንቱ ላይ ተጭኗል። SQL ካወቁ ወዲያውኑ ለፍላጎትዎ Clickhouse መጠቀም መጀመር ይችላሉ። ነገር ግን ይህ ማለት በ MySQL ውስጥ "የፍጠር ሰንጠረዥን አሳይ" ማድረግ እና SQL ን በ Clickhouse ውስጥ ቀድተው መለጠፍ ይችላሉ ማለት አይደለም.

ከ MySQL ጋር ሲነጻጸር በሠንጠረዡ ንድፍ ትርጓሜዎች ውስጥ አስፈላጊ የውሂብ አይነት ልዩነቶች አሉ, ስለዚህ አሁንም የሰንጠረዥ ንድፍ ትርጓሜዎችን ለመለወጥ እና ምቾት ለማግኘት የጠረጴዛ ሞተሮችን ለመማር የተወሰነ ጊዜ ያስፈልግዎታል.

Clickhouse ያለ ምንም ተጨማሪ ሶፍትዌር በጣም ጥሩ ይሰራል፣ነገር ግን ማባዛትን ለመጠቀም ከፈለጉ ZooKeeperን መጫን ያስፈልግዎታል። የጥያቄ አፈጻጸም ትንተና ጥሩ ውጤቶችን ያሳያል - የስርዓት ሰንጠረዦች ሁሉንም መረጃዎች ይይዛሉ, እና ሁሉም መረጃዎች አሮጌ እና አሰልቺ የሆነውን SQL በመጠቀም ማግኘት ይቻላል.

ምርታማነት

Clickhouseን እንደ ELK፣ Big Query እና TimescaleDB ምትክ መጠቀም

የ ClickHouse ዳታቤዝ በጣም ቀላል ንድፍ አለው - በክላስተር ውስጥ ያሉ ሁሉም አንጓዎች ተመሳሳይ ተግባር አላቸው እና ለማስተባበር ZooKeeper ብቻ ይጠቀሙ። የበርካታ አንጓዎች ትንሽ ዘለላ ገንብተናል እና ሙከራ አድርገናል፣ በዚህ ጊዜ ስርዓቱ በጣም አስደናቂ አፈጻጸም እንዳለው አግኝተናል፣ ይህም በትንታኔ ዲቢኤምኤስ መመዘኛዎች ውስጥ ከተጠቀሱት ጥቅሞች ጋር ይዛመዳል። ከ ClickHouse በስተጀርባ ያለውን ፅንሰ-ሀሳብ በጥልቀት ለማየት ወስነናል። ለምርምር የመጀመርያው መሰናክል የመሳሪያዎች እጥረት እና ትንሹ የ ClickHouse ማህበረሰብ ነው፣ ስለዚህ እንዴት እንደሚሰራ ለመረዳት የዚህን ዲቢኤምኤስ ዲዛይን በጥልቀት መርምረናል።

ClickHouse ዳታቤዝ ብቻ ስለሆነ ከካፍ በቀጥታ መረጃ መቀበልን አይደግፍም ስለዚህ በ Go ውስጥ የራሳችንን አስማሚ አገልግሎት ጽፈናል። ከካፍካ የሚመጡትን የ Cap'n Proto ኢንኮድ መልዕክቶችን አንብቦ ወደ TSV ቀይሮ ወደ ClickHouse በቡድን በኤችቲቲፒ በይነገጽ አስገባ። በኋላ አፈጻጸምን ለማሻሻል የGo ቤተ መፃህፍትን ከ ClickHouse's interface ጋር በጥምረት ለመጠቀም ይህንን አገልግሎት እንደገና ጻፍነው። የፓኬቶችን አፈፃፀም ስንገመግም አንድ አስፈላጊ ነገር አገኘን - ለ ClickHouse ይህ አፈፃፀም በጥብቅ የተመካው በፓኬቱ መጠን ላይ ነው ፣ ማለትም ፣ በተመሳሳይ ጊዜ በተጨመሩ ረድፎች ብዛት። ይህ ለምን እንደሚከሰት ለመረዳት ClickHouse ውሂብን እንዴት እንደሚያከማች ተመልክተናል።

በ ClickHouse ውሂብን ለማከማቸት ዋናው ሞተር ወይም ይልቁንም የጠረጴዛ ሞተሮች ቤተሰብ MergeTree ነው። ይህ ሞተር በጎግል BigTable ወይም Apache Cassandra ውስጥ ጥቅም ላይ ከሚውለው የኤል.ኤስ.ኤም. አልጎሪዝም ጋር በፅንሰ-ሀሳብ ተመሳሳይ ነው፣ ነገር ግን መካከለኛ የማስታወሻ ሠንጠረዥን ከመገንባት ይቆጠባል እና መረጃን በቀጥታ ወደ ዲስክ ይጽፋል። እያንዳንዱ የገባው ፓኬት በዋናው ቁልፍ ብቻ የተደረደረ ፣የተጨመቀ እና ክፍል ለመመስረት በዲስክ የተፃፈ በመሆኑ ይህ እጅግ በጣም ጥሩ የመፃፍ ችሎታ ይሰጠዋል ።

የማህደረ ትውስታ ሠንጠረዥ አለመኖር ወይም የትኛውም የመረጃ “ትኩስነት” ፅንሰ-ሀሳብ እንዲሁ ሊጨመሩ የሚችሉት ብቻ ነው ፣ ስርዓቱ መለወጥ እና መሰረዝን አይደግፍም። በአሁኑ ጊዜ መረጃን ለመሰረዝ ብቸኛው መንገድ በቀን መቁጠሪያ ወር ውስጥ መሰረዝ ነው ፣ ምክንያቱም ክፍሎች የአንድ ወር ወሰን አያልፍም። ይህንን ባህሪ ማበጀት የሚችል ለማድረግ የ ClickHouse ቡድን በንቃት እየሰራ ነው። በሌላ በኩል፣ ክፍሎችን መፃፍ እና ማዋሃድ ከክርክር ነጻ ያደርገዋል፣ ስለዚህ I/O ወይም ኮር ሙሌት እስኪፈጠር ድረስ የፍተሻ ሚዛኖችን በተመሳሳይ ጊዜ ከተጨመሩት ማስገቢያዎች ጋር በመስመር ይቀበሉ።
ነገር ግን ይህ ማለት ስርዓቱ ለአነስተኛ ፓኬቶች ተስማሚ አይደለም, ስለዚህ የካፍካ አገልግሎቶች እና አስገቢዎች ለመጠባበቂያነት ያገለግላሉ. በመቀጠል፣ ከበስተጀርባ ያለው ClickHouse ክፍልን በማዋሃድ በቋሚነት ማከናወኑን ይቀጥላል፣ ስለዚህም ብዙ ትናንሽ መረጃዎች እንዲዋሃዱ እና ብዙ ጊዜ እንዲመዘገቡ፣ በዚህም የመቅጃውን ጥንካሬ ይጨምራል። ነገር ግን፣ በጣም ብዙ ያልተገናኙ ክፍሎች ውህደቱ እስከቀጠለ ድረስ የማስገቢያዎች መጨናነቅን ያስከትላል። በቅጽበት በመጠጣት እና በመጠጣት አፈጻጸም መካከል በጣም ጥሩው ስምምነት በሰከንድ ውስጥ የተወሰኑ ማስገቢያዎችን ወደ ጠረጴዛው ውስጥ ማስገባት እንደሆነ ደርሰንበታል።

የሠንጠረዥ ንባብ አፈፃፀም ቁልፍ መረጃ ጠቋሚ እና በዲስክ ላይ ያለው መረጃ የሚገኝበት ቦታ ነው. ሂደቱ ምንም ያህል ፈጣን ቢሆንም ሞተሩ ከዲስክ ላይ ቴራባይት ዳታ መፈተሽ ሲፈልግ እና የተወሰነውን ክፍል ብቻ ሲጠቀም, ጊዜ ይወስዳል. ClickHouse የአምድ መደብር ነው፣ ስለዚህ እያንዳንዱ ክፍል ለእያንዳንዱ ረድፍ የተደረደሩ እሴቶች ያለው ለእያንዳንዱ አምድ (አምድ) ፋይል ይይዛል። በዚህ መንገድ፣ ከጥያቄው የጎደሉ ሙሉ ዓምዶች መጀመሪያ ሊዘለሉ ይችላሉ፣ እና ከዚያ በኋላ ብዙ ህዋሶች ከቬክተራይዝድ አፈጻጸም ጋር በትይዩ ሊሰሩ ይችላሉ። ሙሉ ፍተሻን ለማስቀረት እያንዳንዱ ክፍል ትንሽ የመረጃ ጠቋሚ ፋይል አለው።

ሁሉም ዓምዶች በ"ዋና ቁልፍ" የተደረደሩ ከመሆናቸው አንጻር የመረጃ ጠቋሚው ፋይል በጣም ትልቅ ለሆኑ ጠረጴዛዎች እንኳን ሳይቀር በማስታወሻ ውስጥ ለማቆየት የእያንዳንዱ Nth ረድፍ መለያዎችን (የተያዙ ረድፎችን) ብቻ ይይዛል። ለምሳሌ ነባሪውን መቼቶች “በእያንዳንዱ 8192 ኛ ረድፍ ላይ ምልክት ያድርጉ”፣ ከዚያ “ትንሽ” ከ1 ትሪሊዮን ጋር የሰንጠረዥ መረጃ ጠቋሚ ማድረግ ይችላሉ። በቀላሉ ወደ ማህደረ ትውስታ የሚገቡ መስመሮች 122 ቁምፊዎች ብቻ ይወስዳሉ.

የስርዓት ልማት

የ Clickhouse እድገት እና መሻሻል በ ላይ ሊገኝ ይችላል። Github repos እና "የማደግ" ሂደት በአስደናቂ ፍጥነት መከሰቱን ያረጋግጡ.

Clickhouseን እንደ ELK፣ Big Query እና TimescaleDB ምትክ መጠቀም

ተወዳጅነት

በተለይ በሩሲያኛ ተናጋሪው ማህበረሰብ ውስጥ የ Clickhouse ተወዳጅነት በከፍተኛ ደረጃ እያደገ የመጣ ይመስላል። ባለፈው ዓመት ከፍተኛ ጭነት 2018 ኮንፈረንስ (ሞስኮ, ህዳር 8-9, 2018) እንደ vk.com እና Badoo ያሉ ጭራቆች በአንድ ጊዜ በአስር ሺዎች ከሚቆጠሩ አገልጋዮች ውሂብ (ለምሳሌ, ምዝግብ ማስታወሻዎች) ያስገባሉ, Clickhouse ይጠቀማሉ. በ40 ደቂቃ ቪዲዮ Yuri Nasretdinov ከ VKontakte ቡድን ይህ እንዴት እንደሚደረግ ይናገራል. ከቁስ ጋር ለመስራት ቀላል እንዲሆን በቅርቡ ግልባጩን በሀብር ላይ እንለጥፋለን።

መተግበሪያዎች

ጥቂት ጊዜን በምርምር ካሳለፍኩ በኋላ፣ ClickHouse ጠቃሚ ሊሆን የሚችል ወይም እንደ MySQL፣ PostgreSQL፣ ELK፣ Google Big Query፣ Amazon RedShift፣ TimescaleDB፣ Hadoop፣ MapReduce፣ Pinot እና የመሳሰሉ ሌሎች ባህላዊ እና ታዋቂ መፍትሄዎችን ሙሉ በሙሉ ሊተካ የሚችልባቸው ቦታዎች ያሉ ይመስለኛል። ድሩይድ ከዚህ በታች ያለውን DBMS ለማዘመን ወይም ሙሉ ለሙሉ ለመተካት ClickHouseን ስለመጠቀም ዝርዝሮችን ይገልፃል።

የ MySQL እና PostgreSQL ችሎታዎችን ማራዘም

በቅርቡ MySQL ለጋዜጣችን መድረክ በ ClickHouse ተክተናል Mautic ጋዜጣ. ችግሩ MySQL፣ በደካማ ንድፍ ምክንያት፣ የተላከውን እያንዳንዱን ኢሜል እና እያንዳንዱን ኢሜል በbase64 hash እያስመዘገበ፣ ትልቅ የ MySQL ሠንጠረዥ (email_stats) ፈጠረ። ለአገልግሎት ተመዝጋቢዎች 10 ሚሊዮን ኢሜይሎችን ብቻ ከላከ በኋላ ይህ ሰንጠረዥ 150 ጂቢ የፋይል ቦታ ይይዛል እና MySQL በቀላል መጠይቆች ላይ "ሞኝ" መሆን ጀመረ. የፋይል ቦታን ችግር ለመፍታት የ InnoDB ሠንጠረዥ መጭመቂያ በተሳካ ሁኔታ ተጠቅመን በ4 እጥፍ ቀንሶታል። ሆኖም ግን፣ ታሪክን ለማንበብ ሲባል ብቻ ከ20-30 ሚሊዮን በላይ ኢሜይሎችን በ MySQL ውስጥ ማከማቸት አሁንም ትርጉም የለውም፣ ምክንያቱም ማንኛውም ቀላል ጥያቄ በሆነ ምክንያት ሙሉ ቅኝት ማድረግ ስለሚያስፈልገው ስዋፕ እና ብዙ I / ኦ ሎድ ፣ በዚህ መሠረት ከዛቢክስ ማስጠንቀቂያዎች አዘውትረን እንቀበላለን ።

Clickhouseን እንደ ELK፣ Big Query እና TimescaleDB ምትክ መጠቀም

Clickhouse የውሂብ መጠንን በግምት የሚቀንሱ ሁለት የመጭመቂያ ስልተ ቀመሮችን ይጠቀማል 3-4 ጊዜ, ነገር ግን በዚህ ልዩ ሁኔታ ውሂቡ በተለይ "ተጨናቂ" ነበር.

Clickhouseን እንደ ELK፣ Big Query እና TimescaleDB ምትክ መጠቀም

ኤልኬን በመተካት።

ከራሴ ልምድ በመነሳት የELK ቁልል (ElasticSearch፣ Logstash እና Kibana፣ በዚህ ጉዳይ ላይ ElasticSearch) መዝገቦችን ለማከማቸት ከሚያስፈልገው በላይ ለማሄድ ብዙ ተጨማሪ ግብዓቶችን ይፈልጋል። ElasticSearch ጥሩ የሙሉ ጽሑፍ የምዝግብ ማስታወሻ ፍለጋ ከፈለጉ (በእርግጥ የሚያስፈልግዎ አይመስለኝም) በጣም ጥሩ ሞተር ነው፣ ግን ለምን መደበኛ የሎግ ሞተር ሊሆን እንደቻለ እያሰብኩ ነው። የማስገቢያ አፈጻጸም ከሎግስታሽ ጋር ተዳምሮ ቀላል በሆኑ ጭነቶች ውስጥ እንኳን ችግር ፈጠረን እና ተጨማሪ እና ተጨማሪ RAM እና የዲስክ ቦታ እንድንጨምር አስፈልጎናል። እንደ ዳታቤዝ፣ በሚከተሉት ምክንያቶች Clickhouse ከ ElasticSearch የተሻለ ነው።

  • የ SQL ዘዬ ድጋፍ;
  • የተከማቸ ውሂብ ምርጥ የመጨመቂያ ደረጃ;
  • ከሙሉ የጽሑፍ ፍለጋዎች ይልቅ ለ Regex መደበኛ መግለጫ ፍለጋዎች ድጋፍ;
  • የተሻሻለ የጥያቄ መርሐግብር እና ከፍተኛ አጠቃላይ አፈጻጸም።

በአሁኑ ጊዜ, ClickHouse ን ከ ELK ጋር ሲያወዳድሩ የሚፈጠረው ትልቁ ችግር የምዝግብ ማስታወሻዎችን ለመስቀል መፍትሄዎች አለመኖር, እንዲሁም በርዕሱ ላይ የሰነድ እና የማጠናከሪያ ትምህርት አለመኖር ነው. ከዚህም በላይ እያንዳንዱ ተጠቃሚ ለእንደዚህ አይነት ቴክኖሎጂዎች ፈጣን ትግበራ በጣም አስፈላጊ የሆነውን የዲጂታል ውቅያኖስ መመሪያን በመጠቀም ELK ን ማዋቀር ይችላል. የውሂብ ጎታ ሞተር አለ፣ ግን ለ ClickHouse እስካሁን Filebeat የለም። አዎ እዚያ አለ። አቀላጥፎ መናገር የሚችል እና ከምዝግብ ማስታወሻዎች ጋር ለመስራት የሚያስችል ስርዓት ሎግ ቤት, መሳሪያ አለ ጠቅታ ጭራ የሎግ ፋይል ውሂብን ወደ ClickHouse ለማስገባት ፣ ግን ይህ ሁሉ ተጨማሪ ጊዜ ይወስዳል። ነገር ግን፣ ClickHouse በቀላልነቱ አሁንም መሪ ነው፣ ስለዚህ ጀማሪዎች እንኳን በቀላሉ ጭነው በ10 ደቂቃ ውስጥ ሙሉ ለሙሉ አገልግሎት መስጠት ይችላሉ።

አነስተኛ መፍትሄዎችን መረጥኩኝ፣ FluentBit ን ለመጠቀም ሞከርኩ፣ በጣም ትንሽ ማህደረ ትውስታ ያለው የማጓጓዣ ምዝግብ ማስታወሻ ከ ClickHouse ጋር፣ ካፍካን ላለመጠቀም እየሞከርኩ ነው። ነገር ግን፣ እንደ እነዚህ ያሉ ጥቃቅን አለመጣጣሞችን ማስተካከል ያስፈልጋል የቀን ቅርጸት ችግሮችይህ ከመደረጉ በፊት ውሂቡን ከFluentBit ወደ ClickHouse የሚቀይር ተኪ ንብርብር ሳይኖር።

እንደ አማራጭ፣ Kibana እንደ ClickHouse የጀርባ ማቀፊያ ሆኖ ሊያገለግል ይችላል። ግራፋና. እኔ እንደተረዳሁት ከሆነ ይህ እጅግ በጣም ብዙ የውሂብ ነጥቦችን ሲያቀርብ የአፈጻጸም ችግርን ሊያስከትል ይችላል፣በተለይ ከድሮው የግራፋና ስሪቶች ጋር። ይህንን በQwintry እስካሁን አልሞከርነውም፣ ነገር ግን በዚህ ጉዳይ ላይ ቅሬታዎች በቴሌግራም ውስጥ ባለው የ ClickHouse የድጋፍ ቻናል ላይ ከጊዜ ወደ ጊዜ ይታያሉ።

የጉግል ቢግ መጠይቅ እና Amazon RedShift መተካት (ለትላልቅ ኩባንያዎች መፍትሄ)

ለBigQuery በጣም ጥሩው የአጠቃቀም ጉዳይ 1 ቴባ የJSON ውሂብ መጫን እና በእሱ ላይ የትንታኔ መጠይቆችን ማስኬድ ነው። ትልቅ መጠይቅ ልኬቱ ሊታለፍ የማይችል በጣም ጥሩ ምርት ነው። ይህ በውስጣዊ ክላስተር ላይ ከሚሰራው ClickHouse የበለጠ ውስብስብ ሶፍትዌር ነው፣ ነገር ግን ከደንበኛው አንፃር ከ ClickHouse ጋር ብዙ የሚያመሳስለው ሶፍትዌር ነው። BigQuery በየ SELECT መክፈል ከጀመሩ በኋላ በፍጥነት ውድ ሊሆን ይችላል፣ስለዚህ ከጥቅሞቹ እና ጉዳቶቹ ጋር እውነተኛ የSaaS መፍትሄ ነው።

ብዙ በስሌት ውድ የሆኑ መጠይቆችን ሲያደርጉ ClickHouse ምርጥ ምርጫ ነው። ብዙ የ SELECT መጠይቆችን በየቀኑ ባሮጡ ቁጥር Big Queryን በ ClickHouse መተካት የበለጠ ትርጉም ይሰጣል ምክንያቱም እንዲህ ያለው ምትክ ብዙ ቴራባይት ውሂብ በሚሰራበት ጊዜ በሺዎች የሚቆጠሩ ዶላሮችን ይቆጥብልዎታል። ይህ በተከማቸ መረጃ ላይ አይተገበርም፣ ይህም በትልቁ መጠይቅ ለመስራት በጣም ርካሽ ነው።

በአልቲኒቲ ተባባሪ መስራች አሌክሳንደር ዛይቴሴቭ በአንድ ጽሑፍ ውስጥ "ወደ ClickHouse በመቀየር ላይ" ስለ እንደዚህ ዓይነት ዲቢኤምኤስ ፍልሰት ጥቅሞች ይናገራል።

የጊዜ መለኪያ ዲቢ ምትክ

TimecaleDB የ PostgreSQL ቅጥያ ሲሆን በመደበኛ የውሂብ ጎታ ውስጥ (ከጊዜ ተከታታዮች) ጋር መስራትን የሚያመቻች ነው።https://docs.timescale.com/v1.0/introduction, https://habr.com/ru/company/zabbix/blog/458530/).

ምንም እንኳን ClickHouse በጊዜ ተከታታይ ትልቅ ቦታ ላይ ያለ ከባድ ተፎካካሪ ባይሆንም የአምድ መዋቅር እና የቬክተር መጠይቅ አፈፃፀም፣ በአብዛኛዎቹ የትንታኔ መጠይቆች ሂደት ከTimescaleDB በጣም ፈጣን ነው። በተመሳሳይ ጊዜ ፣ ​​ከ ClickHouse የቡድን ውሂብ የመቀበል አፈፃፀም በግምት 3 እጥፍ ከፍ ያለ ነው ፣ እና እንዲሁም 20 ጊዜ ያነሰ የዲስክ ቦታን ይጠቀማል ፣ ይህም ብዙ ታሪካዊ መረጃዎችን ለማስኬድ በጣም አስፈላጊ ነው ። 
https://www.altinity.com/blog/ClickHouse-for-time-series.

ከ ClickHouse በተለየ በTimescaleDB ውስጥ የተወሰነ የዲስክ ቦታ ለመቆጠብ ብቸኛው መንገድ ZFS ወይም ተመሳሳይ የፋይል ስርዓቶችን መጠቀም ነው።

በቅርቡ ወደ ClickHouse የሚደረጉ ዝማኔዎች የዴልታ መጭመቅን ያስተዋውቁ ይሆናል፣ይህም ለተከታታይ ተከታታይ መረጃዎችን ለመስራት እና ለማከማቸት የበለጠ ተስማሚ ያደርገዋል። TimecaleDB በሚከተሉት ሁኔታዎች ከባዶ ClickHouse የተሻለ ምርጫ ሊሆን ይችላል፡

  • በጣም ትንሽ ራም (<3 ጂቢ) ያላቸው ትናንሽ ጭነቶች;
  • ወደ ትላልቅ ቁርጥራጮች ማሸግ የማይፈልጉ ብዙ ቁጥር ያላቸው ትናንሽ INSERT;
  • የተሻለ ወጥነት, ተመሳሳይነት እና የ ACID መስፈርቶች;
  • የድህረ ጂአይኤስ ድጋፍ;
  • Timescale DB በመሠረቱ PostgreSQL ስለሆነ ከነባር PostgreSQL ሠንጠረዦች ጋር መቀላቀል።

ከ Hadoop እና MapReduce ስርዓቶች ጋር ውድድር

ሃዱፕ እና ሌሎች የ MapReduce ምርቶች ብዙ ውስብስብ ስሌቶችን ሊሰሩ ይችላሉ፣ነገር ግን በትልቅ መዘግየት የመሮጥ አዝማሚያ አላቸው። ClickHouse ይህንን ችግር የሚፈታው ቴራባይት ዳታዎችን በማዘጋጀት እና ወዲያውኑ ውጤት በማምጣት ነው። ስለዚህ፣ ClickHouse ፈጣን፣ በይነተገናኝ ትንታኔያዊ ምርምርን በማከናወን የበለጠ ውጤታማ ነው፣ ይህም የመረጃ ሳይንቲስቶችን ትኩረት ሊስብ ይገባል።

ከ Pinot እና Druid ጋር ውድድር

የ ClickHouse የቅርብ ተፎካካሪዎች ዓምደኛ፣ በመስመር ሊሰሉ የሚችሉ ክፍት ምንጭ ምርቶች ፒኖት እና ድሩይድ ናቸው። እነዚህን ስርዓቶች በማነፃፀር በጣም ጥሩ ስራ በአንቀጹ ውስጥ ታትሟል ሮማና Leventova የካቲት 1 ቀን 2018 ዓ.ም

Clickhouseን እንደ ELK፣ Big Query እና TimescaleDB ምትክ መጠቀም

ይህ መጣጥፍ ማዘመን ያስፈልገዋል - ClickHouse UPDATE እና DELETE ስራዎችን እንደማይደግፍ ይናገራል ይህም ለቅርብ ጊዜ ስሪቶች ሙሉ በሙሉ እውነት አይደለም.

በእነዚህ የመረጃ ቋቶች ላይ ብዙ ልምድ የለንም ፣ ግን ድሩይድ እና ፒኖትን ለማስኬድ የሚያስፈልገው የመሠረተ ልማት ውስብስብነት በእውነት አልወደውም - በሁሉም አቅጣጫ በጃቫ የተከበበ አጠቃላይ ተንቀሳቃሽ አካላት ነው።

ድሩይድ እና ፒኖት የ Apache ኢንኩቤተር ፕሮጄክቶች ናቸው፣ የሂደቱ ሂደት በአፓቼ በGitHub የፕሮጀክት ገጾቹ ላይ በዝርዝር ተሸፍኗል። ፒኖት በጥቅምት 2018 በማቀፊያው ውስጥ ታየ ፣ እና ድሩይድ የተወለደው ከ 8 ወር በፊት - በየካቲት ውስጥ ነው።

ኤኤፍኤስ እንዴት እንደሚሰራ መረጃ ማጣት አንዳንድ እና ምናልባትም ደደብ ጥያቄዎችን ያስነሳልኛል። የፒኖት ደራሲዎች አፓቼ ፋውንዴሽን ለድሩይድ የበለጠ አመቺ መሆኑን አስተውለው ከሆነ እና ለተወዳዳሪው ያለው አመለካከት የምቀኝነት ስሜት ፈጠረ ወይ? የድሮው ደጋፊዎች በድንገት የኋለኛውን ፍላጎት ካሳዩ የድሩይድ እድገት ይቀንሳል እና የፒኖት እድገት ያፋጥናል?

የ ClickHouse ጉዳቶች

አለመብሰል፡ ግልፅ ነው፣ ይህ አሁንም አሰልቺ ቴክኖሎጂ አይደለም፣ ነገር ግን በማንኛውም ሁኔታ፣ እንደዚህ ያለ ምንም ነገር በሌሎች አምድ ዲቢኤምኤስ ውስጥ አይታይም።

ትንንሽ ማስገቢያዎች በከፍተኛ ፍጥነት በደንብ አይሰሩም: ማስገቢያዎች ወደ ትላልቅ ቁርጥራጮች መከፋፈል አለባቸው ምክንያቱም የትናንሽ ማስገቢያዎች አፈፃፀም በእያንዳንዱ ረድፍ ውስጥ ካሉት የአምዶች ብዛት ጋር ተመጣጣኝ ነው. ክሊክ ሃውስ በዲስክ ላይ ዳታ የሚያከማችበት መንገድ በዚህ መንገድ ነው - እያንዳንዱ አምድ 1 ፋይል ወይም ከዚያ በላይ ይወክላል ስለዚህ 1 አምዶችን የያዘ 100 ረድፍ ለማስገባት ቢያንስ 100 ፋይሎችን መክፈት እና መጻፍ ያስፈልግዎታል። ለዚህ ነው ማቋረጫ ማስገቢያ መካከለኛ የሚያስፈልገው (ደንበኛው ራሱ ማቋት ካልሰጠ በስተቀር) - ብዙውን ጊዜ ካፍካ ወይም የሆነ የወረፋ አስተዳደር ስርዓት። እንዲሁም በኋላ ላይ ትላልቅ መረጃዎችን ወደ MergeTree ሰንጠረዦች ለመቅዳት የ Buffer table ሞተርን መጠቀም ይችላሉ።

የጠረጴዛ መጋጠሚያዎች በአገልጋዩ ራም የተገደቡ ናቸው, ግን ቢያንስ እዚያ አሉ! ለምሳሌ, Druid እና Pinot በምንም መልኩ እንደዚህ አይነት ግንኙነቶች የላቸውም, ምክንያቱም እነሱ በቀጥታ በስርጭት ስርዓቶች ውስጥ ለመተግበር አስቸጋሪ ስለሆኑ በኖዶች መካከል ትላልቅ ቁርጥራጮችን ለማንቀሳቀስ የማይደግፉ ናቸው.

ግኝቶች

ይህ DBMS እጅግ በጣም ጥሩ የአፈጻጸም ሚዛን፣ ዝቅተኛ ትርፍ፣ ልኬታማነት እና ቀላልነት ስለሚሰጥ በሚቀጥሉት አመታት ClickHouseን በQwintry በስፋት ለመጠቀም አቅደናል። የ ClickHouse ማህበረሰብ ከትንሽ እስከ መካከለኛ መጠን ያላቸውን ጭነቶች ለመጠቀም ተጨማሪ መንገዶችን ካመጣ በኋላ በፍጥነት መሰራጨት እንደሚጀምር እርግጠኛ ነኝ።

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

ከእኛ ጋር ስለቆዩ እናመሰግናለን። ጽሑፎቻችንን ይወዳሉ? የበለጠ አስደሳች ይዘት ማየት ይፈልጋሉ? ትእዛዝ በማዘዝ ወይም ለጓደኞች በመምከር ይደግፉን፣ ደመና ቪፒኤስ ለገንቢዎች ከ$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

አስተያየት ያክሉ