የ ClickHouse ውጤታማ አጠቃቀም። አሌክሲ ሚሎቪዶቭ (Yandex)

ClickHouse ልዩ ስርዓት ስለሆነ እሱን በሚጠቀሙበት ጊዜ የሕንፃውን ልዩ ገጽታዎች ግምት ውስጥ ማስገባት አስፈላጊ ነው። በዚህ ዘገባ ውስጥ አሌክሲ ክሊክ ሃውስን ሲጠቀሙ ስለ የተለመዱ ስህተቶች ምሳሌዎች ይናገራል, ይህም ወደ ውጤታማ ያልሆነ ስራ ሊያመራ ይችላል. የተግባር ምሳሌዎችን በመጠቀም፣ የአንድ ወይም ሌላ የውሂብ ማቀናበሪያ እቅድ ምርጫ አፈጻጸምን በትእዛዞች እንዴት እንደሚለውጥ እናሳያለን።

ሰላም ሁላችሁም! ስሜ አሌክሲ እባላለሁ ፣ ክሊክ ሃውስን እሰራለሁ።

በመጀመሪያ ፣ ወዲያውኑ እርስዎን ለማስደሰት እቸኩላለሁ ፣ ClickHouse ምን እንደሆነ ዛሬ አልነግርዎትም። እውነት ለመናገር ደክሞኛል። ምን እንደሆነ ሁል ጊዜ እነግራችኋለሁ። እና ምናልባት ሁሉም ሰው አስቀድሞ ያውቃል.

ይልቁንስ ምን ሊሆን እንደሚችል እነግራችኋለሁ፣ ማለትም ClickHouse እንዴት አላግባብ መጠቀም እንደሚቻል። እንደ እውነቱ ከሆነ, መፍራት የለብዎትም, ምክንያቱም ClickHouseን እንደ ቀላል, ምቹ እና ከሳጥኑ ውጭ የሚሰራ ስርዓት ነው. ሁሉንም ነገር ተጭኗል፣ ምንም ችግር የለም።

ግን አሁንም ፣ ይህ ስርዓት ልዩ መሆኑን እና ይህንን ስርዓት ከምቾት ቀጠና የሚያወጣው ያልተለመደ የአጠቃቀም ጉዳይ ላይ በቀላሉ መሰናከል እንደሚችሉ መታወስ አለበት።

ስለዚህ ፣ ራኮች ምንድን ናቸው? በመሠረቱ ስለ ግልጽ ነገሮች እናገራለሁ. ሁሉም ነገር ለሁሉም ሰው ግልጽ ነው, ሁሉም ሰው ሁሉንም ነገር ይረዳል እና በጣም ብልህ በመሆናቸው ሊደሰቱ ይችላሉ, እና ያልተረዱት አዲስ ነገር ይማራሉ.

የመጀመሪያው በጣም ቀላል ምሳሌ, በሚያሳዝን ሁኔታ, ብዙውን ጊዜ የሚከሰት, ብዙ ቁጥር ያላቸው በትናንሽ ስብስቦች, ማለትም ብዙ ቁጥር ያላቸው ትናንሽ መጨመሪያዎች ናቸው.

ClickHouse እንዴት ማስገባትን እንደሚያከናውን ከተመለከትን፣ በአንድ ጥያቄ ቢያንስ ቴራባይት ውሂብ መላክ ይችላሉ። ችግር አይደለም.

እና የተለመደው አፈፃፀም ምን እንደሚሆን እንይ. ለምሳሌ, የ Yandex.Metrics ውሂብ ያለው ጠረጴዛ አለን. ምቶች 105 አንዳንድ አምዶች. 700 ባይት ያልታመቀ። እና በጥሩ ሁኔታ የአንድ ሚሊዮን መስመሮች ስብስቦችን እናስገባለን.

ወደ MergeTree ሰንጠረዥ ውስጥ እናስገባለን, በሰከንድ ግማሽ ሚሊዮን ረድፎች ይገኛሉ. በጣም ጥሩ. በተባዛ ጠረጴዛ ውስጥ - ትንሽ ያነሰ ይሆናል, በሰከንድ ወደ 400 ረድፎች.

እና ምልአተ ጉባኤውን ካበሩት፣ ትንሽ ቀንሰዋል፣ ግን አሁንም ጥሩ አፈጻጸም ያገኛሉ፣ በሰከንድ 250 ጊዜ። ኮረም ማስገባት በ ClickHouse* ውስጥ ያለ ሰነድ ባህሪ ነው።

* ከ 2020 ጀምሮ አስቀድሞ ተዘግቧል.

ስህተት ከሰሩ ምን ይከሰታል? አንድ ረድፍ ወደ MergeTree ሰንጠረዥ እናስገባለን እና በሰከንድ 59 ረድፎችን እናገኛለን. ይህ 10 ጊዜ ቀርፋፋ ነው። ReplicatedMergeTree ውስጥ - 000 ረድፎች በሰከንድ. እና ምልአተ ጉባኤው ከበራ በሰከንድ 6 መስመሮች ይገኛሉ። በእኔ አስተያየት, ይህ አንድ ዓይነት ብልግና ነው. እንዴት እንደዛ ፍጥነት መቀነስ ይቻላል? እንዲያውም በቲሸርቴ ላይ ClickHouse ፍጥነት መቀነስ የለበትም ይላል። ግን አንዳንድ ጊዜ ይከሰታል።

በእውነቱ ይህ የእኛ ጉድለት ነው። በትክክል እንዲሰራ ማድረግ እንችል ነበር፣ ግን አልሰራነውም። እና አላደረግንም, ምክንያቱም የእኛ ስክሪፕት አያስፈልገውም. ቀደም ሲል ባችዎች ነበሩን። ገና በመግቢያው ላይ ጥቅሎችን ተቀብለናል፣ እና ምንም ችግር የለም። ይሰኩት እና ሁሉም ነገር በትክክል ይሰራል። ግን ፣ በእርግጥ ፣ ሁሉም ዓይነት ሁኔታዎች ሊኖሩ ይችላሉ። ለምሳሌ፣ ውሂብ የሚፈጠርባቸው ብዙ አገልጋዮች ሲኖሩዎት። እና ብዙ ጊዜ ውሂብ አያስገቡም ፣ ግን አሁንም ተደጋጋሚ ማስገቢያ ያገኛሉ። እና ይህን በሆነ መንገድ ማስወገድ ያስፈልግዎታል.

ከቴክኒካዊ እይታ አንጻር, የታችኛው መስመር በ ClickHouse ውስጥ ማስገባትን ሲያደርጉ, ውሂቡ ወደ ምንም የማይለወጥ ነገር ውስጥ አይገባም. ምንም እንኳን ሎግ ወይም memTable ስለሌለ አንድ MergeTree ብቻ እንጂ እውነተኛ የውህደት ሎግ መዋቅር የለንም። እኛ ወዲያውኑ ውሂቡን ወደ የፋይል ስርዓቱ እንጽፋለን ፣ ቀድሞውኑ ወደ አምዶች ተበላሽቷል። እና 100 ዓምዶች ካሉዎት ከዚያ ከ 200 በላይ ፋይሎች ወደ የተለየ ማውጫ መፃፍ አለባቸው። ይህ ሁሉ በጣም አስቸጋሪ ነው.

እና ጥያቄው የሚነሳው "እንዴት በትክክል ማድረግ እንደሚቻል?" እንደዚህ አይነት ሁኔታ ከሆነ, አሁንም በሆነ መንገድ ወደ ClickHouse ውሂብ መጻፍ ያስፈልግዎታል.

ዘዴ 1. ይህ ቀላሉ መንገድ ነው. አንድ ዓይነት የተከፋፈለ ወረፋ ይጠቀሙ። ለምሳሌ, ካፍካ. መረጃን ከካፍካ ብቻ ወስደዋል፣ በሴኮንድ አንድ ጊዜ እንሰበስባለን። እና ሁሉም ነገር ጥሩ ይሆናል, ይመዘግባሉ, ሁሉም ነገር በትክክል ይሰራል.

ጉዳቶቹ ካፍካ ሌላ አስቸጋሪ የተከፋፈለ ስርዓት ነው። ካፍካ በድርጅትዎ ውስጥ እንዳለዎትም ተረድቻለሁ። ጥሩ ነው, ምቹ ነው. ግን እዚያ ከሌለ ሌላ የተከፋፈለ ስርዓት ወደ ፕሮጀክትዎ ከመጎተትዎ በፊት ሶስት ጊዜ ማሰብ አለብዎት። እና ስለዚህ አማራጮችን ግምት ውስጥ ማስገባት ተገቢ ነው.

ዘዴ 2. እንደዚህ ያለ የድሮ-ትምህርት ቤት አማራጭ እና በተመሳሳይ ጊዜ በጣም ቀላል ነው. ምዝግብ ማስታወሻዎችዎን የሚያመነጭ አንድ ዓይነት አገልጋይ አለዎት? እና ምዝግብ ማስታወሻዎችዎን ወደ ፋይል ብቻ ይጽፋል። እና በሰከንድ አንድ ጊዜ, ለምሳሌ, ይህን ፋይል እንደገና እንሰይማለን, አዲስ ይክፈቱ. እና የተለየ ስክሪፕት በክሮን ወይም አንዳንድ ዴሞን በጣም ጥንታዊውን ፋይል ወስዶ ወደ ClickHouse ይጽፋል። ምዝግብ ማስታወሻዎችን በሰከንድ አንድ ጊዜ ከጻፉ, ሁሉም ነገር ደህና ይሆናል.

ነገር ግን የዚህ ዘዴ ጉዳቱ ምዝግብ ማስታወሻዎቹ የተፈጠሩበት አገልጋይዎ የሆነ ቦታ ከጠፋ ውሂቡም ይጠፋል።

ዘዴ 3. ሌላ አስደሳች መንገድ አለ, እሱም ያለ ጊዜያዊ ፋይሎች በጭራሽ. ለምሳሌ፣ መረጃ የሚያመነጭ የሆነ የማስታወቂያ ስፒነር ወይም ሌላ አስደሳች ዴሞን አለዎት። እና በትክክል በ RAM ውስጥ ፣ በቋት ውስጥ ብዙ ውሂብ ማከማቸት ይችላሉ። እና በቂ ጊዜ ሲያልፍ፣ ይህን ቋት ወደ ጎን አስቀምጠው አዲስ ይፍጠሩ እና የተጠራቀመውን ወደ ClickHouse በተለየ ክር ውስጥ ያስገቡት።

በሌላ በኩል, መረጃው በመግደል -9 ይጠፋል. አገልጋይህ ከወረደ ይህን ውሂብ ታጣለህ። እና ሌላ ችግር ወደ ዳታቤዝ መጻፍ ካልቻሉ ውሂብዎ በ RAM ውስጥ ይከማቻል። እና ወይ ራም አልቆበታል፣ ወይም ደግሞ መረጃ ታጣለህ።

ዘዴ 4. ሌላ አስደሳች መንገድ. የአገልጋይ ሂደት አለህ? እና እሱ በአንድ ጊዜ ወደ ClickHouse ውሂብ መላክ ይችላል, ግን በአንድ ግንኙነት ውስጥ ያድርጉት. ለምሳሌ፣ የ http ጥያቄ ልኬአለሁ ከዝውውር-ኢኮዲንግ ጋር፡ ቸንክ በ ማስገቢያ። እና በጣም አልፎ አልፎ ቁርጥራጮችን ያመነጫል ፣ እያንዳንዱን መስመር መላክ ይችላሉ ፣ ምንም እንኳን ይህንን ውሂብ ለመቅረጽ ተጨማሪ ገንዘብ ቢኖርም።

ሆኖም፣ በዚህ አጋጣሚ ውሂቡ ወዲያውኑ ወደ ClickHouse ይላካል። እና ClickHouse ራሱ ያስቀምጣቸዋል።

ግን ችግሮችም አሉ. አሁን ሂደትዎ ሲገደል እና የ ClickHouse ሂደት ከተገደለ ጨምሮ ውሂብ ያጣሉ, ምክንያቱም ያልተሟላ ማስገባት ይሆናል. እና በ ClickHouse ማስገቢያዎች ውስጥ በረድፎች መጠን ውስጥ እስከ የተወሰነ የተወሰነ ገደብ ድረስ አቶሚክ ናቸው። በመርህ ደረጃ, ይህ አስደሳች መንገድ ነው. እንዲሁም መጠቀም ይቻላል.

ዘዴ 5. ሌላ አስደሳች መንገድ ይኸውና. ይሄ አንዳንድ አይነት በማህበረሰብ የተገነባ ለውሂብ ማሰባሰብ አገልጋይ ነው። እኔ ራሴ አልተመለከትኩትም, ስለዚህ ምንም ነገር ዋስትና መስጠት አልችልም. ሆኖም ግን ለ ClickHouse እራሱ ምንም ዋስትናዎች የሉም። ይህ እንዲሁ ክፍት ምንጭ ነው፣ ግን በሌላ በኩል፣ ለማቅረብ የምንሞክረውን የተወሰነ የጥራት ደረጃ ልታለማመዱ ትችላላችሁ። ግን ለዚህ ነገር - አላውቅም ፣ ወደ GitHub ይሂዱ ፣ ኮዱን ይመልከቱ። ምናልባት ጥሩ ነገር ጽፈው ይሆናል.

* ከ 2020 ጀምሮ ፣ እንዲሁም ከግምት ውስጥ መግባት አለበት። የድመት ቤት.

ዘዴ 6. ሌላው መንገድ የ Buffer ሰንጠረዦችን መጠቀም ነው. የዚህ ዘዴ ጥቅም መጠቀም ለመጀመር በጣም ቀላል ነው. የማቆያ ጠረጴዛ ይፍጠሩ እና ወደ እሱ ያስገቡ።

ግን ጉዳቱ ችግሩ ሙሉ በሙሉ አለመቀረፉ ነው። በMergeTree አይነት መጠን መረጃን በሴኮንድ በአንድ ባች መቦደን ካለቦት፣በመጠን ቋት ሠንጠረዥ ውስጥ ቢያንስ በሰከንድ እስከ ብዙ ሺዎች ማሰባሰብ ያስፈልግዎታል። በሴኮንድ ከ 10 በላይ ከሆነ, አሁንም መጥፎ ይሆናል. እና በቡድን ውስጥ ካስገቡ ፣ ከዚያ በሰከንድ መቶ ሺህ መስመሮች እዚያ እንደሚገኙ አይተዋል ። እና ይሄ ቀድሞውኑ በጣም ከባድ በሆነ ውሂብ ላይ ነው።

እንዲሁም የመጠባበቂያ ጠረጴዛዎች ምዝግብ ማስታወሻ የላቸውም. እና በአገልጋዩ ላይ የሆነ ችግር ከተፈጠረ ውሂቡ ይጠፋል።

እና እንደ ጉርሻ፣ በቅርቡ በ ClickHouse ውስጥ ከካፍካ መረጃ ለመሰብሰብ እድሉን አግኝተናል። የጠረጴዛ ሞተር አለ - ካፍካ. በቀላሉ እየፈጠሩ ነው። እና በእሱ ላይ ተጨባጭ እይታዎችን መስቀል ትችላለህ. በዚህ አጋጣሚ ውሂቡን ከካፍካ አውጥቶ ወደሚፈልጉት ጠረጴዛዎች ያስገባል.

በተለይ በዚህ አጋጣሚ የሚያስደስት ነገር አለማድረጋችን ነው። ይህ የማህበረሰብ ባህሪ ነው። እናም "የማህበረሰብ ባህሪ" ስል ያለምንም ንቀት እናገራለሁ. ኮዱን እናነባለን, ግምገማ አድርገናል, በትክክል መስራት አለበት.

* ከ 2020 ጀምሮ ተመሳሳይ ድጋፍ አለ። RabbitMQ.

ውሂብ በሚያስገቡበት ጊዜ የማይመች ወይም ያልተጠበቀ ሌላ ምን ሊሆን ይችላል? የእሴቶችን አስገባ ጥያቄ ካደረጉ እና አንዳንድ የተሰሉ መግለጫዎችን በእሴቶች ውስጥ ይፃፉ። ለምሳሌ፣ አሁን() እንዲሁ የተገመገመ አገላለጽ ነው። እና በዚህ አጋጣሚ ClickHouse ለእያንዳንዱ መስመር የእነዚህን አገላለጾች አስተርጓሚ ለማስነሳት ይገደዳል፣ እና አፈፃፀሙ በታላቅ ትዕዛዞች ይወድቃል። እሱን ማስወገድ ይሻላል።

* በአሁኑ ጊዜ ችግሩ ሙሉ በሙሉ ተፈትቷል ፣ በ VALUES ውስጥ አገላለጾችን ሲጠቀሙ ምንም ተጨማሪ የአፈፃፀም መመለሻ የለም።

አንዳንድ ችግሮች ሊኖሩበት የሚችሉበት ሌላው ምሳሌ በአንድ ባች ላይ ያለው ውሂብዎ የክፍሎች ስብስብ ከሆነ ነው። በነባሪ የ ClickHouse ክፍልፍሎች በወር። እና አንድ ሚሊዮን ረድፎችን ካስገቡ እና ለብዙ ዓመታት መረጃ ካለ ፣ ከዚያ እዚያ ብዙ ደርዘን ክፍልፋዮች ይኖርዎታል። እና ይህ ብዙ አስር እጥፍ ያነሱ ስብስቦች ይኖራሉ ከሚለው እውነታ ጋር እኩል ነው ፣ ምክንያቱም በውስጣቸው ሁል ጊዜ በመጀመሪያ ወደ ክፍልፋዮች ይከፈላሉ ።

* በቅርብ ጊዜ በ ClickHouse በሙከራ ሁኔታ ውስጥ በሬም ውስጥ ላሉ ቁርጥራጮች እና ቁርጥራጮች የታመቀ ቅርጸት ከጽሑፍ-ወደፊት ምዝግብ ማስታወሻ ጋር ተጨምሯል ፣ ይህም ችግሩን ሙሉ በሙሉ ይፈታል ።

አሁን ሁለተኛውን አይነት ችግር አስቡበት - የውሂብ መተየብ.

የውሂብ መተየብ ጥብቅ እና አንዳንድ ጊዜ ሕብረቁምፊ ሊሆን ይችላል። ሕብረቁምፊ - ይሄ ሁሉም የህብረቁምፊ አይነት መስኮች እንዳሉዎት ወስደው ሲገልጹ ነው። ያማል። ያንን ማድረግ የለብህም.

አንዳንድ መስክ አለን ለማለት በሚፈልጉበት ጊዜ በትክክል እንዴት ማድረግ እንዳለብን እንወቅ እና ClickHouse በራሱ እንዲያውቀው ይፍቀዱለት፣ ነገር ግን የእንፋሎት መታጠቢያ አልወስድም። ግን አሁንም የተወሰነ ጥረት ማድረግ ጠቃሚ ነው።

ለምሳሌ የአይ ፒ አድራሻ አለን። በአንድ አጋጣሚ እንደ ሕብረቁምፊ አስቀመጥነው። ለምሳሌ 192.168.1.1. ያለበለዚያ የ UInt32* ዓይነት ቁጥር ይሆናል። ለ IPv32 አድራሻ 4 ቢት በቂ ነው።

በመጀመሪያ ፣ በሚያስደንቅ ሁኔታ ፣ ውሂቡ በተመሳሳይ መልኩ ይጨመቃል። ልዩነት ይኖራል, በእርግጠኝነት, ግን ያን ያህል ትልቅ አይደለም. ስለዚህ በዲስክ I / O ላይ ምንም ልዩ ችግሮች የሉም.

ነገር ግን በሲፒዩ ጊዜ እና በጥያቄ ማስፈጸሚያ ጊዜ ላይ ከባድ ልዩነት አለ።

እንደ ቁጥሮች ከተቀመጡ ልዩ የሆኑትን የአይፒ አድራሻዎች ቁጥር እንቆጥራቸው። በሰከንድ 137 ሚሊዮን መስመሮች ይወጣል. እንደ መስመሮች ተመሳሳይ ከሆነ, ከዚያም 37 ሚሊዮን መስመሮች በሰከንድ. ይህ አጋጣሚ ለምን እንደተከሰተ አላውቅም። እነዚህን ጥያቄዎች ራሴ አድርጌአለሁ። ግን ወደ 4 ጊዜ ያህል ቀርፋፋ።

እና በዲስክ ቦታ ላይ ያለውን ልዩነት ካሰሉ, ከዚያ ደግሞ ልዩነት አለ. እና ልዩነቱ አንድ አራተኛ ያህል ነው, ምክንያቱም በጣም ብዙ ልዩ የአይፒ አድራሻዎች አሉ. እና ትንሽ ቁጥር ያላቸው የተለያዩ እሴቶች ያላቸው መስመሮች ቢኖሩ ኖሮ በመዝገበ-ቃላቱ ውስጥ በጸጥታ ወደ ተመሳሳይ መጠን ይጨመቃሉ።

እና የአራት እጥፍ የጊዜ ልዩነት በመንገድ ላይ አይደለም. ምናልባት እርስዎ, በእርግጥ, ግድ አይሰጡዎትም, ነገር ግን እንደዚህ አይነት ልዩነት ሳይ, አዝናለሁ.

የተለያዩ ጉዳዮችን እንመልከት።

1. ጥቂት የተለያዩ ልዩ እሴቶች ሲኖሩዎት አንድ ጉዳይ። በዚህ አጋጣሚ፣ እርስዎ ሊያውቁት የሚችሉትን እና ለማንኛውም ዲቢኤምኤስ ሊጠቀሙበት የሚችሉትን ቀላል አሰራር እንጠቀማለን። ይህ ሁሉ ለ ClickHouse ብቻ ሳይሆን ትርጉም ያለው ነው። የቁጥር መለያዎችን ወደ ዳታቤዝ ብቻ ይፃፉ። እና ወደ ሕብረቁምፊዎች መለወጥ እና ከመተግበሪያዎ ጎን መመለስ ይችላሉ።

ለምሳሌ ክልል አለህ። እና እንደ ሕብረቁምፊ ለማስቀመጥ እየሞከሩ ነው። እና እዚያ ይጻፋል-ሞስኮ እና ሞስኮ ክልል. እና "ሞስኮ" እዚያ እንደተጻፈ ስመለከት, ይህ አሁንም ምንም አይደለም, እና MO ሲሆን, በሆነ መንገድ ሙሉ በሙሉ አሳዛኝ ይሆናል. ስንት ባይት ነው።

ይልቁንስ በቀላሉ የ Ulnt32 ቁጥርን እና 250 ን እንጽፋለን. በ Yandex ውስጥ 250 አለን, ግን የእርስዎ የተለየ ሊሆን ይችላል. እንደዚያ ከሆነ, ClickHouse ከጂኦቤዝ ጋር አብሮ የመሥራት ችሎታ አለው እላለሁ. በቀላሉ ከክልሎች ጋር ማውጫ ይጽፋሉ, ተዋረድን ጨምሮ, ማለትም ሞስኮ, ሞስኮ ክልል እና የሚፈልጉትን ሁሉ. እና በጥያቄው ደረጃ መለወጥ ይችላሉ።

ሁለተኛው አማራጭ ተመሳሳይ ነው ፣ ግን በ ClickHouse ውስጥ ባለው ድጋፍ። የEnum የውሂብ አይነት ነው። በቀላሉ በ Enum ውስጥ የሚፈልጉትን ሁሉንም እሴቶች ይፃፉ። ለምሳሌ የመሳሪያውን አይነት እና እዚያ ይፃፉ: ዴስክቶፕ, ሞባይል, ታብሌት, ቲቪ. 4 አማራጮች ብቻ።

ጉዳቱ በየጊዜው መለወጥ ያስፈልግዎታል. አንድ አማራጭ ብቻ ታክሏል። ተለዋጭ ጠረጴዛ እንሰራለን. በእውነቱ፣ በ ClickHouse ውስጥ ያለው ለውጥ ሠንጠረዥ ነፃ ነው። በተለይ ለ Enum ነፃ ነው ምክንያቱም በዲስክ ላይ ያለው መረጃ አይለወጥም. ሆኖም ግን፣ ለውጥ በጠረጴዛው ላይ መቆለፊያ * ያገኛል እና ሁሉም ምርጫዎች እስኪጠናቀቁ ድረስ መጠበቅ አለበት። እና ይህ ለውጥ ከተፈጸመ በኋላ ብቻ ነው, ማለትም, አሁንም አንዳንድ ችግሮች አሉ.

* በቅርብ ጊዜ የ ClickHouse ስሪቶች ውስጥ፣ ALTER ሙሉ በሙሉ እንዳይታገድ ተደርጓል።

ለ ClickHouse በጣም ልዩ የሆነው ሌላው አማራጭ የውጪ መዝገበ ቃላት ግንኙነት ነው። በ ClickHouse ውስጥ ቁጥሮችን መጻፍ እና ማውጫዎችዎን በማንኛውም ለእርስዎ በሚመች ስርዓት ውስጥ ማስቀመጥ ይችላሉ። ለምሳሌ፡- MySQL፣ Mongo፣ Postgresን መጠቀም ይችላሉ። ይህን ውሂብ በ http በኩል ይልካል የራስዎን ማይክሮ አገልግሎት እንኳን መፍጠር ይችላሉ. እና በ ClickHouse ደረጃ፣ ይህን ውሂብ ከቁጥሮች ወደ ሕብረቁምፊዎች የሚቀይር ተግባር ይጽፋሉ።

ይህ በውጫዊ ጠረጴዛ ላይ መቀላቀልን ለማከናወን ልዩ ነገር ግን በጣም ቀልጣፋ መንገድ ነው። እና ሁለት አማራጮች አሉ. በአንደኛው አማራጭ፣ ይህ ውሂብ ሙሉ በሙሉ መሸጎጫ፣ ሙሉ በሙሉ በ RAM ውስጥ ይገኛል እና በአንዳንድ ክፍተቶች ይሻሻላል። እና በሌላ አማራጭ ፣ ይህ ውሂብ ከ RAM ጋር የማይጣጣም ከሆነ ፣ ከዚያ በከፊል መሸጎጥ ይችላሉ።

አንድ ምሳሌ እዚህ አለ። Yandex.Direct አለ. እና የማስታወቂያ ኩባንያ እና ባነሮች አሉ. ምናልባት በአስር ሚሊዮኖች የሚቆጠሩ የማስታወቂያ ኩባንያዎች ሊኖሩ ይችላሉ። እና በ RAM ውስጥ በግምት ተስማሚ። እና በቢሊዮኖች የሚቆጠሩ ባነሮች አሉ, አይመጥኑም. እና ከ MySQL የተሸጎጠ መዝገበ ቃላት እየተጠቀምን ነው።

ብቸኛው ችግር የተሸጎጠው መዝገበ-ቃላት የተሸጠው ፍጥነት ወደ 100% የሚጠጋ ከሆነ በጥሩ ሁኔታ ይሰራል። አነስ ያለ ከሆነ ለእያንዳንዱ የውሂብ ጥቅል ጥያቄዎችን በሚሰራበት ጊዜ የጎደሉትን ቁልፎች በትክክል መውሰድ እና ከ MySQL ውሂብ ለመውሰድ መሄድ አስፈላጊ ይሆናል. ስለ ClickHouse ፣ አሁንም ያንን ዋስትና መስጠት እችላለሁ - አዎ ፣ አይዘገይም ፣ ስለሌሎች ስርዓቶች አልናገርም።

እና እንደ ጉርሻ፣ መዝገበ-ቃላቶች በ ClickHouse ውስጥ መረጃን እንደገና ለማዘመን በጣም ቀላል መንገዶች ናቸው። ማለትም ፣ በማስታወቂያ ኩባንያዎች ላይ ሪፖርት ነበራችሁ ፣ ተጠቃሚው የማስታወቂያ ኩባንያውን በቀላሉ ቀይሯል እና በሁሉም የድሮው መረጃዎች ፣ በሁሉም ሪፖርቶች ውስጥ ፣ ይህ ውሂብ እንዲሁ ተቀይሯል። ረድፎችን በቀጥታ ወደ ጠረጴዛው ከጻፉ, ከዚያ እነሱን ማዘመን አይችሉም.

የሕብረቁምፊዎችህን መለያዎች ከየት እንደምታገኝ የማታውቅበት ሌላ መንገድ። ብቻ ሃሽ ማድረግ ትችላለህ። እና በጣም ቀላሉ አማራጭ ባለ 64-ቢት ሃሽ መውሰድ ነው.

ብቸኛው ችግር ሃሽ 64-ቢት ከሆነ, በእርግጠኝነት በእርግጠኝነት ግጭቶች ይኖሩዎታል. ምክንያቱም አንድ ቢሊዮን መስመሮች ካሉ, ዕድሉ ቀድሞውኑ ተጨባጭ እየሆነ መጥቷል.

እና እንደዚህ አይነት የማስታወቂያ ኩባንያዎችን ስም ሃሽ ማድረግ በጣም ጥሩ አይሆንም። የተለያዩ ኩባንያዎች የማስታወቂያ ዘመቻዎች ከተደባለቁ, ከዚያም ለመረዳት የማይቻል ነገር ይኖራል.

እና ቀላል ዘዴ አለ. እውነት ነው ፣ ለከባድ መረጃም በጣም ተስማሚ አይደለም ፣ ግን አንድ ነገር በጣም ከባድ ካልሆነ ፣ በቀላሉ ሌላ የደንበኛ መለያ ወደ መዝገበ-ቃላቱ ቁልፍ ያክሉ። እና ከዚያ ግጭቶች ይኖሩዎታል፣ ግን በአንድ ደንበኛ ውስጥ ብቻ። እና ይህን ዘዴ በ Yandex.Metrica ውስጥ ላለው አገናኝ ካርታ እንጠቀማለን. እዚያ ዩአርኤል አለን ፣ hashes እናከማቻለን ። እና በእርግጥ ግጭቶች እንዳሉ እናውቃለን. ነገር ግን አንድ ገጽ ሲታይ በአንድ ገጽ ላይ ለአንድ ተጠቃሚ አንዳንድ ዩአርኤሎች ተጣብቀው የመቆየቱ ዕድል እና ይሄ ይስተዋላል፣ ከዚያ ይህ ችላ ሊባል ይችላል።

እንደ ጉርሻ ለብዙ ኦፕሬሽኖች ሃሽ ብቻ በቂ ነው እና ገመዶቹ እራሳቸው የትም ሊቀመጡ አይችሉም።

እንደ ድር ጣቢያ ጎራዎች ያሉ ሕብረቁምፊዎች አጭር ከሆኑ ሌላ ምሳሌ። እንደነበሩ ሊቀመጡ ይችላሉ. ወይም, ለምሳሌ, የአሳሽ ቋንቋ ru 2 ባይት ነው. በእርግጥ ለባይት አዝኛለሁ ግን አይጨነቁ 2 ባይት አያሳዝንም። እባካችሁ እንደነበሩ ያቆዩት, አትጨነቁ.

ሌላው ጉዳይ ደግሞ በተቃራኒው ብዙ ሕብረቁምፊዎች ሲኖሩ እና በተመሳሳይ ጊዜ በውስጣቸው ብዙ ልዩ የሆኑ, እና ስብስቡ እንኳን ያልተገደበ ሊሆን ይችላል. የተለመደው ምሳሌ የፍለጋ ሐረጎች ወይም ዩአርኤልዎች ነው። በመተየብ ምክንያት ጨምሮ ሀረጎችን ይፈልጉ። በቀን ስንት ልዩ የፍለጋ ሀረጎችን እንይ። እና ከሁሉም ክስተቶች ውስጥ ግማሽ ያህል የሚሆኑት መሆናቸው ተገለጠ። እና በዚህ ሁኔታ, ውሂቡን መደበኛ ማድረግ, መለያዎችን መቁጠር, በተለየ ሠንጠረዥ ውስጥ ማስቀመጥ ያስፈልግዎታል ብለው ያስቡ ይሆናል. ግን ያንን ማድረግ የለብዎትም. እነዚህን መስመሮች እንደነበሩ ብቻ ያቆዩ.

የተሻለ - ምንም ነገር አይፍጠሩ, ምክንያቱም ለብቻው ካከማቹት, መቀላቀል ያስፈልግዎታል. እና ይህ መቀላቀል አሁንም በማህደረ ትውስታ ውስጥ የሚስማማ ከሆነ በዘፈቀደ ወደ ማህደረ ትውስታ መድረስ ነው። የማይመጥን ከሆነ በአጠቃላይ ችግሮች ሊኖሩ ይችላሉ.

እና ውሂቡ በቦታው ላይ ከተከማቸ በቀላሉ ከፋይል ስርዓቱ በትክክለኛው ቅደም ተከተል ይነበባሉ እና ሁሉም ነገር ጥሩ ነው.

ዩአርኤል ወይም ሌላ ውስብስብ ረጅም ሕብረቁምፊ ካለዎት, አንዳንድ ጭምቆችን አስቀድመው ማስላት እና በተለየ አምድ ውስጥ መፃፍ እንደሚችሉ ማሰብ አለብዎት.

ለዩአርኤሎች፣ ለምሳሌ፣ ጎራውን ለብቻው ማከማቸት ይችላሉ። እና በእርግጥ ጎራ ከፈለጉ ፣ ከዚያ ይህንን አምድ ብቻ ይጠቀሙ ፣ እና ዩአርኤሎቹ ይዋሻሉ ፣ እና እርስዎ እንኳን አይነኳቸውም።

ልዩነቱ ምን እንደሆነ እንይ። ClickHouse ጎራውን የሚያሰላ ልዩ ተግባር አለው። በጣም ፈጣን ነው፣ አመቻችተናል። እና፣ እውነቱን ለመናገር፣ ከ RFC ጋር እንኳን አያሟላም፣ ሆኖም ግን የሚያስፈልገንን ሁሉ ግምት ውስጥ ያስገባል።

እና በአንድ አጋጣሚ በቀላሉ ዩአርኤሎችን እናገኛለን እና ጎራውን እናሰላለን። 166 ሚሊሰከንድ ይወጣል። እና ዝግጁ የሆነ ጎራ ከወሰዱ ፣ ከዚያ 67 ሚሊሰከንዶች ብቻ ይወጣል ፣ ማለትም ፣ በፍጥነት ሶስት ጊዜ። እና ፈጣን, አንዳንድ ስሌቶችን ማድረግ ስላለብን ሳይሆን ትንሽ ውሂብ ስላነበብን ነው.

በሆነ ምክንያት፣ አንድ ጥያቄ፣ ቀርፋፋ፣ በሴኮንድ ጊጋባይት የበለጠ ፍጥነት ያገኛል። ምክንያቱም ብዙ ጊጋባይት ስለሚያነብ ነው። ይህ ሙሉ በሙሉ ተደጋጋሚ ውሂብ ነው። ጥያቄው በፍጥነት የሚሰራ ይመስላል፣ ግን ለማጠናቀቅ ረጅም ጊዜ ይወስዳል።

እና በዲስክ ላይ ያለውን የውሂብ መጠን ከተመለከቱ, ዩአርኤሉ 126 ሜጋባይት ነው, እና ጎራ 5 ሜጋባይት ብቻ ነው. በ 25 እጥፍ ያነሰ ይሆናል. ሆኖም፣ መጠይቁ አሁንም 4 ጊዜ ብቻ ፈጣን ነው። ነገር ግን መረጃው ትኩስ ስለሆነ ነው. እና ቀዝቃዛ ከሆነ ምናልባት በዲስክ I / O ምክንያት 25 እጥፍ ፈጣን ሊሆን ይችላል.

በነገራችን ላይ, ጎራው ከዩአርኤል ምን ያህል ያነሰ እንደሆነ ከገመገሙ, ወደ 4 ጊዜ ያህል ይሆናል. ነገር ግን በሆነ ምክንያት, በዲስክ ላይ ያለው መረጃ 25 እጥፍ ያነሰ ይወስዳል. ለምን? በመጨመቅ ምክንያት. እና ዩአርኤል ተጨምቋል፣ እና ጎራው ተጨምቋል። ግን ብዙ ጊዜ ዩአርኤል ብዙ የቆሻሻ መጣያ ይይዛል።

እና በእርግጥ ለትክክለኛዎቹ እሴቶች የተነደፉ ወይም የሚስማሙ ትክክለኛ የውሂብ አይነቶችን መጠቀም ተገቢ ነው። በ IPv4 ውስጥ ካሉ UInt32* ያከማቹ። IPv6 ከሆነ፣ ከዚያ FixedString(16)፣ ምክንያቱም የIPv6 አድራሻ 128 ቢት ነው፣ ማለትም በቀጥታ በሁለትዮሽ ቅርጸት አከማች።

ግን አንዳንድ ጊዜ IPv4 አድራሻዎች እና አንዳንድ ጊዜ IPv6 ካለዎትስ? አዎ, ሁለቱንም ማቆየት ይችላሉ. አንድ አምድ ለ IPv4፣ ሌላው ለ IPv6። እርግጥ ነው, IPv4 ን ወደ IPv6 ለመቅረጽ አንድ አማራጭ አለ. ይሄ እንዲሁ ይሰራል፣ ነገር ግን በጥያቄዎችዎ ውስጥ ብዙ ጊዜ IPv4 አድራሻ ከፈለጉ፣ ከዚያ በተለየ አምድ ውስጥ ማስቀመጥ ጥሩ ነው።

* አሁን ClickHouse የተለየ IPv4፣ IPv6 የውሂብ አይነቶች አሉት፣ መረጃን እንደ ቁጥሮች በብቃት የሚያከማች፣ ነገር ግን እንደ strings በሚመች መልኩ ይወክላሉ።

በተጨማሪም ውሂቡን አስቀድመው ማካሄድ ጠቃሚ መሆኑን ልብ ሊባል ይገባል. ለምሳሌ, አንዳንድ ጥሬ ምዝግብ ማስታወሻዎች ወደ እርስዎ ይመጣሉ. እና, ምናልባት, ወዲያውኑ ወደ ClickHouse ውስጥ ማስገባት የለብዎትም, ምንም እንኳን ምንም ነገር ላለማድረግ በጣም ፈታኝ ቢሆንም እና ሁሉም ነገር ይሰራል. ግን አሁንም ሊሆኑ የሚችሉትን ስሌቶች ማከናወን አሁንም ጠቃሚ ነው.

ለምሳሌ, የአሳሽ ስሪት. በአንዳንድ አጎራባች ዲፓርትመንቶች ውስጥ, ጣቴን ለመጠቆም የማልፈልገው, የአሳሽ እትም እዚያ ውስጥ ተከማችቷል, ማለትም, እንደ ሕብረቁምፊ: 12.3. እና ከዚያ፣ ሪፖርት ለማድረግ፣ ይህን ሕብረቁምፊ ወስደው በአደራደር ይከፋፈላሉ፣ ከዚያም በድርድር የመጀመሪያው አካል። በተፈጥሮ, ሁሉም ነገር ፍጥነት ይቀንሳል. ለምን ይህን እንደሚያደርጉ ጠየቅኳቸው። ያለጊዜው ማመቻቸትን እንደማይወዱ ነገሩኝ። እና ያለጊዜው አፍራሽነት አልወድም።

ስለዚህ በዚህ ሁኔታ በ 4 አምዶች መከፋፈል የበለጠ ትክክል ይሆናል. እዚህ አትፍሩ፣ ምክንያቱም ይህ ClickHouse ነው። ClickHouse የአምድ ዳታቤዝ ነው። እና የበለጠ የተጣራ ትናንሽ ዓምዶች, የተሻለ ነው. 5 BrowserVersion ይኖራል፣ 5 አምዶችን ይስሩ። ይህ ጥሩ ነው።

አሁን ብዙ በጣም ረጅም ሕብረቁምፊዎች, በጣም ረጅም ድርድሮች ካሉ ምን ማድረግ እንዳለብዎት ያስቡ. በ ClickHouse ውስጥ ማከማቸት አያስፈልጋቸውም። በምትኩ፣ በ ClickHouse ውስጥ የተወሰነ መለያ ብቻ ማከማቸት ይችላሉ። እና እነዚህ ረዣዥም መስመሮች ወደ ሌላ ስርዓት ገፋፋቸው።

ለምሳሌ፣ ከኛ የትንታኔ አገልግሎቶች አንዱ አንዳንድ የክስተት መለኪያዎች አሉት። እና ብዙ መለኪያዎች ወደ ክስተቶች ከመጡ ፣ በቀላሉ የሚመጡትን የመጀመሪያዎቹን 512 እናድናለን ፣ ምክንያቱም 512 አያሳዝንም።

እና በእርስዎ የውሂብ አይነቶች ላይ መወሰን ካልቻሉ ወደ ClickHouse ውሂብ መጻፍም ይችላሉ ፣ ግን ለጊዜያዊ ውሂብ ልዩ በሆነው የሎግ ዓይነት ጊዜያዊ ሰንጠረዥ ላይ። ከዚያ በኋላ ምን ዓይነት የእሴቶች ስርጭት እንዳለዎት ፣ በአጠቃላይ ምን እንዳለ እና ትክክለኛዎቹን ዓይነቶች መተንተን ይችላሉ ።

* አሁን ClickHouse የውሂብ አይነት አለው። ዝቅተኛ ካርዲናዊነት በትንሽ ጥረት ሕብረቁምፊዎችን በብቃት እንዲያከማቹ ያስችልዎታል።

አሁን ደግሞ ሌላ አስደሳች ጉዳይ ተመልከት። አንዳንድ ጊዜ ነገሮች ለሰዎች እንግዳ በሆነ መንገድ ይሠራሉ. ሄጄ አየዋለሁ። እና ወዲያውኑ ይህ የተደረገው MySQL ስሪት 3.23 በማዋቀር ረገድ ሰፊ ልምድ ባላቸው በጣም ልምድ ባላቸው ብልህ አስተዳዳሪ ይመስላል።

እዚህ አንድ ሺህ ጠረጴዛዎችን እናያለን, እያንዳንዳቸው የቀረውን መከፋፈል የያዘው በሺህ ምን እንደሆነ ግልጽ አይደለም.

በመርህ ደረጃ፣ ይህ ልምድ ምን አይነት ስቃይ ሊገኝ እንደሚችል መረዳትን ጨምሮ የሌሎችን ልምድ አከብራለሁ።

እና ምክንያቶቹ ብዙ ወይም ትንሽ ግልጽ ናቸው. እነዚህ ከሌሎች ስርዓቶች ጋር በሚሰሩበት ጊዜ ሊከማቹ የሚችሉ የቆዩ አመለካከቶች ናቸው። ለምሳሌ፣ የMyISAM ሠንጠረዦች የተሰባጠረ ዋና ቁልፍ የላቸውም። እና ይህ መረጃ የማጋራት መንገድ ተመሳሳይ ተግባር ለማግኘት ተስፋ አስቆራጭ ሙከራ ሊሆን ይችላል።

ሌላው ምክንያት በትልልቅ ጠረጴዛዎች ላይ ምንም አይነት የለውጥ ስራዎችን ለመስራት አስቸጋሪ ነው. ሁሉም ነገር ይታገዳል። ምንም እንኳን በዘመናዊው MySQL ስሪቶች ውስጥ, ይህ ችግር ከአሁን በኋላ ያን ያህል ከባድ አይደለም.

ወይም፣ ለምሳሌ፣ microsharding፣ ግን ከዚያ በኋላ ላይ ተጨማሪ።

በ ClickHouse ውስጥ, ይህንን ማድረግ አያስፈልግዎትም, ምክንያቱም በመጀመሪያ, ዋናው ቁልፉ ተሰብስቧል, ውሂቡ በዋናው ቁልፍ የታዘዘ ነው.

እና አንዳንድ ጊዜ ሰዎች እንዲህ ብለው ይጠይቁኛል፡- “የክልል መጠይቆች በ ClickHouse ውስጥ ያለው አፈጻጸም እንዴት በጠረጴዛው መጠን ይቀየራል?” በፍፁም አይለወጥም እላለሁ። ለምሳሌ፣ አንድ ቢሊዮን ረድፎች ያለው ጠረጴዛ አለህ እና የአንድ ሚሊዮን ረድፎችን ክልል እያነበብክ ነው። ሁሉ ነገር ጥሩ ነው. ሠንጠረዡ አንድ ትሪሊዮን ረድፎች ካሉት እና አንድ ሚሊዮን ረድፎችን እያነበቡ ከሆነ, ያኔ ከሞላ ጎደል ተመሳሳይ ይሆናል.

እና፣ ሁለተኛ፣ እንደ በእጅ ክፍልፍሎች ያሉ ማንኛቸውም ቁርጥራጮች አያስፈልጉም። ወደ ውስጥ ገብተህ በፋይል ስርዓቱ ላይ ያለውን ነገር ከተመለከትክ ጠረጴዛ በጣም ከባድ ነገር መሆኑን ታያለህ። እና እዚያ ውስጥ እንደ ክፍልፋዮች ያለ ነገር አለ። ማለትም፣ ClickHouse ለእርስዎ ሁሉንም ነገር ይሰራል እና መሰቃየት አያስፈልገዎትም።

የአምድ መደመር/ማስቀመጥ ከቀየሩ በ ClickHouse ላይ ለውጥ ነፃ ነው።

እና ትንሽ ጠረጴዛዎችን መስራት የለብዎትም, ምክንያቱም በጠረጴዛዎ ውስጥ 10 ረድፎች ወይም 10 ረድፎች ካሉ, ከዚያ ምንም ለውጥ አያመጣም. ClickHouse ማለት ዘግይቶ ሳይሆን የግብአት አቅርቦትን የሚያሻሽል ስርዓት ነው ስለዚህ 000 መስመሮችን መስራት ምንም ትርጉም የለውም።

አንድ ትልቅ ጠረጴዛ መጠቀም ትክክል ነው. የድሮውን አስተሳሰቦች አስወግዱ, ሁሉም ነገር ደህና ይሆናል.

እና እንደ ጉርሻ, በአዲሱ ስሪት ውስጥ, በግለሰብ ክፍልፋዮች ላይ ሁሉንም ዓይነት የጥገና ስራዎችን ለማከናወን የዘፈቀደ የመከፋፈያ ቁልፍ ለማድረግ እድሉ አለን.

ለምሳሌ, ብዙ ትናንሽ ጠረጴዛዎች ያስፈልጉዎታል, ለምሳሌ, አንዳንድ መካከለኛ መረጃዎችን ማካሄድ በሚያስፈልግበት ጊዜ, ቁርጥራጮች ይቀበላሉ እና ወደ መጨረሻው ጠረጴዛ ከመጻፍዎ በፊት በእነሱ ላይ ለውጥ ማድረግ ያስፈልግዎታል. ለዚህ ጉዳይ አስደናቂ የሆነ የጠረጴዛ ሞተር - StripeLog አለ. ልክ እንደ TinyLog ነው፣ የተሻለ ብቻ።

* አሁን ClickHouse ብዙ አለው። የሠንጠረዥ ተግባር ግቤት.

ሌላው ፀረ-ንድፍ ማይክሮሶርዲንግ ነው. ለምሳሌ ዳታ ማጋራት አለብህ እና 5 አገልጋዮች አሉህ እና ነገ 6 አገልጋዮች ይኖራሉ። እና ይህን ውሂብ እንዴት እንደገና ማመጣጠን እንደሚችሉ ያስባሉ. እና በምትኩ, ወደ 5 ሼዶች ሳይሆን ወደ 1 ሼዶች እየተከፋፈሉ ነው. እና ከዚያ እያንዳንዱን ማይክሮሻርድ ወደተለየ አገልጋይ ካርታ ታደርጋለህ። እና በአንድ አገልጋይ ላይ ይሳካሉ, ለምሳሌ, 000 ClickHouse, ለምሳሌ. በተለየ ወደቦች ወይም በተለየ የውሂብ ጎታዎች ላይ የተለየ ምሳሌ.

ነገር ግን በ ClickHouse ውስጥ ይህ በጣም ጥሩ አይደለም. ምክንያቱም የ ClickHouse አንድ ምሳሌ እንኳን አንድ ጥያቄን ለማስኬድ ሁሉንም የሚገኙትን የአገልጋይ ሀብቶች ለመጠቀም ይሞክራል። ያም ማለት አንድ ዓይነት አገልጋይ አለህ እና እዚያ ለምሳሌ 56 ፕሮሰሰር ኮሮች። አንድ ሰከንድ የሚፈጅ መጠይቅ እየሮጡ ነው እና 56 ኮሮች ይጠቀማል። እና 200 ClickHouses በአንድ አገልጋይ ላይ ካስቀመጥክ 10 ክሮች ይጀምራል። በአጠቃላይ ሁሉም ነገር በጣም መጥፎ ይሆናል.

ሌላው ምክንያት በእነዚህ አጋጣሚዎች ላይ ያለው የሥራ ስርጭት ያልተመጣጠነ ይሆናል. አንዳንዶቹ ቀደም ብለው ይጠናቀቃሉ, አንዳንዶቹ በኋላ ይጠናቀቃሉ. ይህ ሁሉ የሆነው በአንድ አጋጣሚ ከሆነ፣ ClickHouse ራሱ እንዴት በዥረቶቹ መካከል ውሂቡን በትክክል ማሰራጨት እንዳለበት ያውቅ ነበር።

እና ሌላው ምክንያት በTCP ላይ የኢንተርፕሮሰሰር ግንኙነት ይኖርዎታል። ውሂቡ ተከታታይ መሆን፣ መገለል አለበት፣ እና ይህ እጅግ በጣም ብዙ የማይክሮሻርድስ ነው። ብቻ አይሰራም።

ሌላ ፀረ-ንድፍ፣ ምንም እንኳን አንቲፓተርን ተብሎ ሊጠራ ባይቻልም። ይህ ከፍተኛ መጠን ያለው ቅድመ-ስብስብ ነው.

በአጠቃላይ, ቅድመ-ስብስብ ጥሩ ነው. አንድ ቢሊዮን ረድፎች ነበሩህ፣ አጠቃለልከው እና 1 ረድፎች ሆነህ፣ እና አሁን መጠይቁ ወዲያውኑ ተፈፅሟል። ሁሉም ነገር ጥሩ ነው። እንደዛ ነው ማድረግ የምትችለው። ለዚህ ደግሞ ClickHouse እንኳን ዳታ ሲገባ ተጨማሪ ድምርን የሚያደርግ ልዩ AggregatingMergeTree የሰንጠረዥ አይነት አለው።

ነገር ግን እንደዚህ አይነት መረጃዎችን እንሰበስባለን እና እንደዚህ አይነት መረጃዎችን እንሰበስባለን ብለው የሚያስቡበት ጊዜ አለ። እና በአንዳንድ አጎራባች ክፍል ውስጥ የትኛውንም መናገር አልፈልግም ፣ በዋና ቁልፍ ለማጠቃለል የ SummingMergeTree ሰንጠረዦችን ይጠቀማሉ ፣ እና 20 አምዶች እንደ ዋና ቁልፍ ያገለግላሉ። እንደዚያ ከሆነ፣ የአንዳንድ አምዶችን ስም ለሴራ ቀይሬያለሁ፣ ግን ስለሱ ነው።

እና እንደዚህ አይነት ችግሮች ይነሳሉ. በመጀመሪያ, ያለዎት የውሂብ መጠን በጣም ብዙ አይቀንስም. ለምሳሌ, በሶስት እጥፍ ይቀንሳል. ያልተዋሃደ ውሂብ ከመኖሩ ጋር ተያይዞ የሚመጣውን ያልተገደበ ትንታኔ ለመግዛት ሶስት ጊዜ ጥሩ ዋጋ ነው። ውሂቡ ከተጠቃለለ፣ ከመተንተን ይልቅ አሳዛኝ ስታቲስቲክስ ብቻ ታገኛለህ።

እና በተለይ ጥሩ ምንድነው? እነዚህ ከሚቀጥለው ክፍል የመጡ ሰዎች ሄደው አንዳንድ ጊዜ አንድ ተጨማሪ አምድ ወደ ዋናው ቁልፍ እንዲጨምሩ ይጠይቁ። ያም ማለት, እንደዚህ አይነት መረጃን ሰብስበናል, እና አሁን ትንሽ ተጨማሪ እንፈልጋለን. ግን በ ClickHouse ውስጥ ምንም ተለዋጭ ዋና ቁልፍ የለም። ስለዚህ, በ C ++ ውስጥ አንዳንድ ስክሪፕቶችን መጻፍ አለብዎት. እና ምንም እንኳን በC++ ውስጥ ቢሆኑም ስክሪፕቶችን አልወድም።

እና ClickHouse ለምን እንደተፈጠረ ከተመለከቱ፣ ያልተጠቃለለ ውሂብ በትክክል የተወለደበት ሁኔታ ነው። ላልተጠቃለለ ዳታ ClickHouse እየተጠቀሙ ከሆነ ሁሉንም ነገር በትክክል እየሰሩ ነው። እየሰበሰቡ ከሆነ, ይህ አንዳንድ ጊዜ ይቅር ይባላል.

ሌላው አስደሳች ጉዳይ ማለቂያ በሌለው ዑደት ውስጥ ያሉ ጥያቄዎች ናቸው። አንዳንድ ጊዜ ወደ አንዳንድ የምርት አገልጋይ እሄዳለሁ እና እዚያ ያለውን የማሳያ ፕሮሰስ ዝርዝርን እመለከታለሁ። እና አንድ አስከፊ ነገር እየተከሰተ እንዳለ ባወቅሁ ቁጥር።

ለምሳሌ ይሄው ነው። በአንድ ጥያቄ ውስጥ ሁሉንም ነገር ማድረግ እንደሚቻል ወዲያውኑ ግልጽ ነው. በቀላሉ ዩአርኤልን እና ዝርዝሩን እዚያ ይፃፉ።

ለምንድነው ብዙ እንደዚህ ያሉ ጥያቄዎች ማለቂያ በሌለው ዑደት ውስጥ መጥፎ የሆኑት? መረጃ ጠቋሚው ጥቅም ላይ ካልዋለ, በተመሳሳይ ውሂብ ላይ ብዙ ማለፊያዎች ይኖሩዎታል. ነገር ግን ኢንዴክስ ጥቅም ላይ ከዋለ, ለምሳሌ, በ ru ላይ ዋና ቁልፍ አለዎት እና url = የሆነ ነገር ይጽፋሉ. እና አንድ ዩአርኤል ከጠረጴዛው ላይ በትክክል ይነበባል ብለው ያስባሉ, ሁሉም ነገር ደህና ይሆናል. ግን በእርግጥ አይደለም. ምክንያቱም ClickHouse ሁሉንም ነገር በቡድን ስለሚያደርግ ነው።

አንዳንድ የውሂብ ክልል ማንበብ ሲፈልግ, በ ClickHouse ውስጥ ያለው መረጃ ጠቋሚ ትንሽ ስለሆነ ትንሽ ተጨማሪ ያነባል። ይህ መረጃ ጠቋሚ በሠንጠረዡ ውስጥ አንድ ነጠላ ረድፍ እንዲያገኙ አይፈቅድልዎትም, የተወሰነ ዓይነት ብቻ ነው. እና ውሂቡ በብሎኮች ውስጥ ተጨምቋል። አንድ መስመር ለማንበብ ሙሉውን ብሎክ መውሰድ እና መፍታት ያስፈልግዎታል. እና ብዙ መጠይቆችን ብታካሂዱ, እንደዚህ አይነት ብዙ መገናኛዎች ይኖሩዎታል, እና ብዙ ስራዎችን ደጋግመው ይሠራሉ.

እና እንደ ጉርሻ ፣ በ ClickHouse ውስጥ ሜጋባይት እና በመቶዎች የሚቆጠሩ ሜጋባይት እንኳን ወደ IN ክፍል ለማስተላለፍ መፍራት እንደሌለብዎት ማየት ይችላሉ። በተግባራችን አስታውሳለሁ በ MySQL ውስጥ በ IN ክፍል ውስጥ ብዙ እሴቶችን ካለፍን ፣ ለምሳሌ ፣ 100 ሜጋባይት የተወሰኑ ቁጥሮችን እዚያ እናሳልፋለን ፣ ከዚያ MySQL 10 ጊጋባይት ማህደረ ትውስታን እንደሚበላ እና ምንም ነገር አይከሰትም ። እሱ ፣ ሁሉም ነገር መጥፎ ይሰራል።

እና ሁለተኛው ነገር በ ClickHouse ውስጥ ፣ መጠይቆችዎ ኢንዴክስ የሚጠቀሙ ከሆነ ፣ ከዚያ ሁል ጊዜ ከሙሉ ቅኝት ቀርፋፋ አይደለም ፣ ማለትም ፣ ሙሉውን ጠረጴዛ ከሞላ ጎደል ለማንበብ ከፈለጉ ፣ እሱ በቅደም ተከተል ይሄዳል እና ሙሉውን ጠረጴዛ ያነባል። ባጠቃላይ, እሱ ይገነዘባል.

ይሁን እንጂ አንዳንድ ችግሮች አሉ. ለምሳሌ፣ ያ IN ከንዑስ መጠይቅ ጋር መረጃ ጠቋሚውን አይጠቀምም። ግን ይህ የኛ ችግር ነው እና ልናስተካክለው ይገባል። እዚህ ምንም መሠረታዊ ነገር የለም. እንስራው*.

እና ሌላ አስደሳች ነገር በጣም ረጅም ጥያቄ ካለዎት እና የተከፋፈለ የጥያቄ ሂደት እየተካሄደ ከሆነ ይህ በጣም ረጅም ጥያቄ ለእያንዳንዱ አገልጋይ ያለምንም መጨናነቅ ይላካል። ለምሳሌ, 100 ሜጋባይት እና 500 አገልጋዮች. እና በዚህ መሠረት 50 ጊጋባይት በአውታረ መረቡ ላይ ይተላለፋል። ይተላለፋል ከዚያም ሁሉም ነገር በተሳካ ሁኔታ ይከናወናል.

* ቀድሞውኑ በመጠቀም; ሁሉም ነገር በገባው ቃል ተስተካክሏል።

እና ጥያቄዎቹ ከኤፒአይ የመጡ ከሆነ በጣም የተለመደ ነው። ለምሳሌ አንድ ዓይነት አገልግሎት ሰርተሃል። እና አንድ ሰው የእርስዎን አገልግሎት የሚፈልግ ከሆነ፣ ከዚያ ኤፒአይውን ከፈቱ እና በትክክል ከሁለት ቀናት በኋላ አንድ ለመረዳት የማይቻል ነገር እየተፈጠረ እንደሆነ ያያሉ። ሁሉም ነገር ከመጠን በላይ ተጭኗል እና በጭራሽ መሆን ያልነበረባቸው አንዳንድ አስፈሪ ጥያቄዎች እየመጡ ነው።

እና አንድ መፍትሄ ብቻ ነው. ኤፒአይውን ከከፈቱት ከዚያ መቁረጥ ይኖርብዎታል። ለምሳሌ አንዳንድ ኮታዎችን ለማስገባት። ሌሎች ምክንያታዊ አማራጮች የሉም. አለበለዚያ, ወዲያውኑ ስክሪፕት ይጽፋሉ እና ችግሮች ይኖራሉ.

እና ClickHouse ልዩ ባህሪ አለው - ይህ የኮታዎች ስሌት ነው. በተጨማሪም የኮታ ቁልፍዎን ማስተላለፍ ይችላሉ። ይህ ለምሳሌ የውስጥ ተጠቃሚ መታወቂያ ነው። እና ኮታዎች ለእያንዳንዳቸው ለብቻው ይሰላሉ.

አሁን ሌላ አስደሳች ነገር. ይህ በእጅ ማባዛት ነው።

ብዙ ጉዳዮችን አውቃለሁ፣ ClickHouse አብሮ የተሰራ የማባዛት ድጋፍ ቢኖረውም፣ ሰዎች ClickHouseን በእጅ ይደግማሉ።

መርህ ምንድን ነው? የውሂብ ማቀነባበሪያ ቧንቧ አለዎት. እና ራሱን ችሎ ይሰራል, ለምሳሌ, በተለያዩ የመረጃ ማእከሎች ውስጥ. ልክ እንደነበረው ተመሳሳይ ውሂብ ወደ ClickHouse በተመሳሳይ መንገድ ይጽፋሉ። እውነት ነው፣ ልምምድ እንደሚያሳየው በኮድዎ ውስጥ ባሉ አንዳንድ ልዩነቶች ምክንያት ውሂቡ አሁንም ይለያያል። በእናንተ ውስጥ ተስፋ አደርጋለሁ.

እና በየጊዜው አሁንም በእጅ ማመሳሰል አለብዎት. ለምሳሌ በወር አንድ ጊዜ አስተዳዳሪዎች rsync ያደርጋሉ።

እንደ እውነቱ ከሆነ, በ ClickHouse ውስጥ አብሮ የተሰራውን ማባዛትን መጠቀም በጣም ቀላል ነው. ግን አንዳንድ ተቃርኖዎች ሊኖሩ ይችላሉ, ምክንያቱም ለዚህ እርስዎ ZooKeeper ን መጠቀም ያስፈልግዎታል. ስለ ZooKeeper ምንም መጥፎ ነገር አልናገርም, በመርህ ደረጃ, ስርዓቱ ይሰራል, ነገር ግን ሰዎች በጃቫ-ፎቢያ ምክንያት የማይጠቀሙበት ሁኔታ ይከሰታል, ምክንያቱም ClickHouse በ C ++ ውስጥ የተጻፈ በጣም ጥሩ ስርዓት ስለሆነ እና ሊጠቀሙበት ይችላሉ. ሁሉም ነገር ደህና ይሆናል. እና ZooKeeper በጃቫ። እና በሆነ መልኩ ማየት እንኳን አይፈልጉም, ግን ከዚያ በእጅ ማባዛትን መጠቀም ይችላሉ.

ClickHouse ተግባራዊ ሥርዓት ነው። ፍላጎቶችዎን ግምት ውስጥ ያስገባል. በእጅ ማባዛት ካልዎት፣ የእራስዎን ቅጂዎች የሚመለከት እና በመካከላቸው ውድቀትን የሚያደርግ የተከፋፈለ ሰንጠረዥ መፍጠር ይችላሉ። እና ምንም እንኳን መስመሮችዎ በስርዓት ቢለያዩም ፍሎፕን ለማስወገድ የሚያስችል ልዩ አማራጭ እንኳን አለ።

በተጨማሪም, ጥንታዊ የጠረጴዛ ሞተሮችን ከተጠቀሙ ችግሮች ሊኖሩ ይችላሉ. ClickHouse የተለያዩ የጠረጴዛ ሞተሮች ያሉት እንደዚህ ያለ ግንበኛ ነው። ለሁሉም ከባድ ጉዳዮች፣ በሰነዱ ላይ እንደተፃፈው፣ የMergeTree ቤተሰብ ሰንጠረዦችን ይጠቀሙ። እና ሁሉም የቀሩት - ይህ እንደዚያ ነው, ለግለሰብ ጉዳዮች ወይም ለፈተናዎች.

በMergeTree ሠንጠረዥ ውስጥ ምንም ቀን እና ሰዓት እንዲኖርዎት አያስፈልግም። አሁንም መጠቀም ይችላሉ። ቀን እና ሰዓት ከሌለ ነባሪውን 2000 ይጻፉ። ይሰራል እና ሃብት አይፈልግም።

እና በአዲሱ የአገልጋዩ ስሪት ውስጥ ያለ ክፋይ ቁልፍ ብጁ ክፍፍል እንዳለዎት መግለጽ ይችላሉ። ተመሳሳይ ይሆናል.

በሌላ በኩል, ጥንታዊ የጠረጴዛ ሞተሮች መጠቀም ይቻላል. ለምሳሌ ውሂቡን አንድ ጊዜ ይሙሉ እና ይመልከቱ ፣ ያጥፉ እና ይሰርዙ። Log ን መጠቀም ይችላሉ።

ወይም ለመካከለኛ ሂደት ትናንሽ መጠኖችን ማከማቸት StripeLog ወይም TinyLog ነው።

ማህደረ ትውስታ አነስተኛ መጠን ያለው መረጃ ካለ እና በ RAM ውስጥ የሆነ ነገር ማጣመም ይቻላል.

ClickHouse የተሻሻለ ውሂብን በጣም አይወድም።

አንድ የተለመደ ምሳሌ እዚህ አለ. ይህ እጅግ በጣም ብዙ የዩአርኤልዎች ብዛት ነው። በአቅራቢያው ባለው ጠረጴዛ ውስጥ አስቀምጣቸው. እና ከእነሱ ጋር JOIN ለማድረግ ወስነናል፣ ነገር ግን ይሄ እንደ ደንቡ አይሰራም፣ ምክንያቱም ClickHouse Hash JOINን ብቻ ነው የሚደግፈው። ለማገናኘት ለብዙ ውሂብ በቂ RAM ከሌለ JOIN አይሰራም *።

ውሂቡ ከፍተኛ ካርዲናሊቲ ከሆነ, አይጨነቁ, በተመጣጣኝ መልክ ያስቀምጡት, ዩአርኤሎቹ በቀጥታ በዋናው ሠንጠረዥ ውስጥ ይገኛሉ.

* እና አሁን ClickHouse እንዲሁ የውህደት መቀላቀል አለው፣ እና መካከለኛው ዳታ ከ RAM ጋር በማይገባበት ሁኔታ ላይ ይሰራል። ነገር ግን ይህ ውጤታማ አይደለም እና ምክሩ ትክክለኛ ሆኖ ይቆያል.

አንድ ባልና ሚስት ተጨማሪ ምሳሌዎች፣ ግን ጸረ-ቅጦች መሆናቸውን ወይም አለመሆናቸውን አስቀድሜ እጠራጠራለሁ።

ClickHouse አንድ የታወቀ ጉድለት አለው። * እንዴት ማዘመን እንዳለበት አያውቅም። በአንድ በኩል, ይህ እንኳን ጥሩ ነው. አንዳንድ አስፈላጊ መረጃዎች ካሉዎት, ለምሳሌ, የሂሳብ አያያዝ, ከዚያ ማንም ሰው ሊልክላቸው አይችልም, ምክንያቱም ምንም ማሻሻያ የለም.

* በቡድን ሁነታ ለማዘመን እና ለመሰረዝ ድጋፍ ለረጅም ጊዜ ታክሏል።

ግን ዝማኔዎች ከበስተጀርባ እንዲታዩ የሚፈቅዱ አንዳንድ ልዩ መንገዶች አሉ። ለምሳሌ፣ የ ReplaceMergeTree ዓይነት ሠንጠረዦች። ከበስተጀርባ ውህደት ጊዜ ማሻሻያዎችን ያደርጋሉ። ይህንን በማመቻቸት ሰንጠረዥ ማስገደድ ይችላሉ። ግን ብዙ ጊዜ አያድርጉ, ምክንያቱም ክፋዩን ሙሉ በሙሉ ይተካዋል.

በ ClickHouse ውስጥ የተከፋፈሉ JOINs - ይህ ደግሞ በመጠይቁ እቅድ አውጪው በደንብ አይስተናገድም።

መጥፎ ፣ ግን አንዳንድ ጊዜ እሺ።

ዳታውን በተመረጠ* ለማንበብ ብቻ ClickHouseን በመጠቀም።

ለጅምላ ስሌቶች ClickHouseን እንድትጠቀም አልመክርም። ግን ይህ ሙሉ በሙሉ እውነት አይደለም ፣ ምክንያቱም እኛ ከዚህ ምክር እየራቅን ነው። እና በቅርቡ በ ClickHouse - Catboost ውስጥ የማሽን መማሪያ ሞዴሎችን የመተግበር ችሎታን ጨምረናል። እና ያስጨንቀኛል, ምክንያቱም እኔ እንደማስበው: "ምን አይነት አስፈሪ ነው. ይህ በአንድ ባይት ስንት ዑደቶች ነው የሚወጣው! በባይት ላይ የሰዓት ዑደቶችን መጀመር ለእኔ ያሳዝነኛል።

ግን አይፍሩ, ClickHouseን ይጫኑ, ሁሉም ነገር ደህና ይሆናል. የሆነ ነገር ካለ ማህበረሰብ አለን። በነገራችን ላይ ማህበረሰቡ አንተ ነህ። እና ማንኛውም ችግር ካጋጠመዎት, ቢያንስ ወደ ቻታችን መሄድ ይችላሉ, እና እርስዎ እንደሚረዱዎት ተስፋ አደርጋለሁ.

ጥያቄዎች

ለሪፖርቱ እናመሰግናለን! ስለ ClickHouse ብልሽት የት ቅሬታ አለ?

አሁን በግል እኔን ማጉረምረም ትችላላችሁ።

በቅርቡ ClickHouseን መጠቀም ጀመርኩ። ወዲያውኑ የክሊ በይነገጽን ወደቀ።

ምን አይነት ነጥብ ነው።

ትንሽ ቆይቼ አገልጋዩን በትንሽ ምርጫ ጣልኩት።

ተሰጥኦ አለህ።

የ GitHub ስህተት ከፈትኩ፣ ነገር ግን ችላ ተብሏል።

እናያለን.

አሌክሲ በውስጥህ ያለውን መረጃ እንዴት እየጨመቅክ እንዳለህ ሊነግረኝ ቃል በመግባት በሪፖርቱ እንድገኝ አታለልኩ።

በጣም ቀላል።

ትናንት የተገነዘብኩት ይህንን ነው። ተጨማሪ ዝርዝሮች።

ምንም አስፈሪ ዘዴዎች የሉም. ብሎክ-በብሎክ መጭመቅ ብቻ ነው። ነባሪው LZ4 ነው፣ ZSTD* ማንቃት ይችላሉ። ከ 64 ኪሎባይት እስከ 1 ሜጋባይት ያግዳል.

* እንዲሁም ከሌሎች ስልተ ቀመሮች ጋር በሰንሰለት ጥቅም ላይ ሊውሉ ለሚችሉ ልዩ የማመቂያ ኮዴኮች ድጋፍ አለ።

ብሎኮች ጥሬ መረጃ ብቻ ናቸው?

በትክክል ጥሬ አይደለም. ድርድሮች አሉ። የቁጥር አምድ ካለህ በረድፍ ውስጥ ያሉት ቁጥሮች በአንድ ድርድር ውስጥ ተከማችተዋል።

ግልፅ ነው።

አሌክሲ፣ በ uniqExact በአይፒዎች ላይ የነበረ ምሳሌ፣ ማለትም uniqExact ከቁጥሮች ይልቅ በሕብረቁምፊዎች ለመቁጠር ረዘም ያለ ጊዜ የሚወስድ መሆኑ እና የመሳሰሉት። እርማት በሚደረግበት ጊዜ በጆሮዎቻችን ላይ ፊንጢጣ ብናስቀምጠውስ? ማለትም በዲስክ ላይ ብዙም አይለይም የተናገርክ ይመስላል። ከዲስክ ላይ መስመሮችን ካነበብን, ካስቀመጥን, ከዚያ ፈጣን ድምር ይኖረናል ወይስ አይኖረንም? ወይንስ አሁንም እዚህ በትንሹ እያተረፍን ነው? የሞከርከው መስሎ ይታየኛል ነገርግን በሆነ ምክንያት በቤንችማርክ ላይ አላሳየም።

እኔ እንደማስበው ከመውሰድ ይልቅ ቀርፋፋ ይሆናል. በዚህ አጋጣሚ የአይፒ አድራሻው ከሕብረቁምፊው መተንተን አለበት። በእርግጥ፣ በ ClickHouse ውስጥ፣ የአይ ፒ አድራሻን መተንተንም ተመቻችቷል። በጣም ጠንክረን ሞክረናል, ነገር ግን እዚያው ቦታ ላይ ቁጥሮች በአሥር ሺሕ መልክ የተጻፉ ናቸው. በጣም የማይመች። በሌላ በኩል፣ የ uniqExact ተግባር በሕብረቁምፊዎች ላይ ቀርፋፋ ይሰራል፣ እነዚህ ሕብረቁምፊዎች በመሆናቸው ብቻ ሳይሆን፣ የአልጎሪዝም የተለየ ልዩ ሙያ ስለተመረጠ ነው። ሕብረቁምፊዎች በተለየ መንገድ ብቻ ይያዛሉ.

እና የበለጠ ጥንታዊ የውሂብ አይነት ከወሰድን? ለምሳሌ እኛ ያለንበትን የተጠቃሚ መታወቂያ ጽፈው በመስመር ጻፉት እና ከዚያ ጣሉት የበለጠ አስደሳች ይሆናል ወይንስ አይሆንም?

እጠራጠራለሁ. እንዲያውም የበለጠ የሚያሳዝን ይመስለኛል, ምክንያቱም ለነገሩ ቁጥሮችን መተንተን ከባድ ችግር ነው. ይህ ባልደረባዬ ቁጥሮችን በአሥር ሺሕ መልክ መፈተሽ ምን ያህል ከባድ እንደሆነ እንኳ ዘገባ ያለው ይመስላል፣ ግን ላይሆን ይችላል።

አሌክሲ ፣ ለሪፖርቱ በጣም አመሰግናለሁ! እና ለ ClickHouse በጣም እናመሰግናለን! ስለ እቅዶች ጥያቄ አለኝ. መዝገበ-ቃላትን ሙሉ በሙሉ ለማዘመን በእቅዶቹ ውስጥ ባህሪ አለ?

ማለትም ከፊል ዳግም መነሳት?

አዎ አዎ. ልክ እንደ MySQL መስክ እዚያ የማዘጋጀት ችሎታ፣ ማለትም መዝገበ ቃላቱ በጣም ትልቅ ከሆነ ይህ ውሂብ ብቻ እንዲጫኑ በኋላ ማዘመን።

በጣም አስደሳች ባህሪ. እና፣ ለእኔ የሚመስለኝ፣ አንድ ሰው በቻታችን ውስጥ ጠቁሟል። ምናልባት እርስዎ እንኳን ነበሩ.

አይመስለኝም.

በጣም ጥሩ፣ አሁን ሁለት ጥያቄዎች ሆኑ። እና ቀስ በቀስ ማድረግ መጀመር ይችላሉ. ግን ይህ ባህሪ ለመተግበር በጣም ቀላል እንደሆነ ወዲያውኑ ላስጠነቅቅዎ እፈልጋለሁ። ማለትም ፣ በንድፈ ሀሳብ ፣ የስሪት ቁጥሩን ወደ ጠረጴዛው ውስጥ መፃፍ እና ከዚያ መፃፍ ብቻ ያስፈልግዎታል-ስሪት ከእንደዚህ እና ከእንደዚህ አይነት ያነሰ ነው። እና ይህ ማለት, ምናልባትም, ለአድናቂዎች እናቀርባለን. ቀናተኛ ነህ?

አዎ፣ ግን በሚያሳዝን ሁኔታ በC++ ውስጥ የለም።

ባልደረቦችዎ በC++ ውስጥ መጻፍ ይችላሉ?

ሰው አገኛለሁ።

በጣም ጥሩ*.

* ባህሪው ከሪፖርቱ ከሁለት ወራት በኋላ ተጨምሯል - በጥያቄው ደራሲ ተዘጋጅቶ በእሱ ቀርቧል የመጫን ጥያቄ.

እናመሰግናለን!

ሀሎ! ለሪፖርቱ እናመሰግናለን! ClickHouse ለእሱ ያሉትን ሁሉንም ሀብቶች በደንብ እንደሚጠቀም ጠቅሰሃል። እና ከሉክሶፍት ቀጥሎ ያለው ተናጋሪ ስለ ሩሲያ ፖስት ውሳኔው ተናግሯል ። ክሊክ ሃውስን በጣም እንደወደዱት ተናግሯል፣ ነገር ግን ሙሉውን ፕሮሰሰር ስለበላ ከዋና ተፎካካሪያቸው ይልቅ በትክክል አልተጠቀሙበትም። እና ከሥነ-ህንፃቸው ጋር፣ ወደ ዙ ጠባቂያቸው ከዶክተሮች ጋር መግጠም አልቻሉም። ክሊክ ሃውስ ለእሱ የሚገኘውን ሁሉ እንዳይበላው በሆነ መንገድ መገደብ ይቻላል?

አዎ ይቻላል እና በጣም ቀላል ነው. ያነሱ ኮርሞችን ለመብላት ከፈለጉ ፣ ከዚያ ብቻ ይፃፉ set max_threads = 1. እና ያ ብቻ ነው, ጥያቄውን በአንድ ኮር ውስጥ ያስፈጽማል. በተጨማሪም, ለተለያዩ ተጠቃሚዎች የተለያዩ ቅንብሮችን መግለጽ ይችላሉ. ስለዚህ ምንም ችግር የለም. እና ከሉክሶፍት ላሉ የስራ ባልደረቦችህ ይህን መቼት በሰነዱ ውስጥ አለማግኘታቸው ጥሩ እንዳልሆነ ንገራቸው።

አሌክሲ ፣ ሰላም! ይህን ጥያቄ መጠየቅ እፈልጋለሁ. ብዙ ሰዎች ClickHouseን እንደ የምዝግብ ማስታወሻ ማከማቻ መጠቀም መጀመራቸውን ስሰማ ይህ የመጀመሪያዬ አይደለም። በሪፖርቱ ላይ ይህን አታድርጉ ማለትም ረጅም መስመሮችን ማከማቸት አያስፈልግም ብለዋል. ስለሱ ምን ያስባሉ?

በመጀመሪያ, ምዝግብ ማስታወሻዎች ብዙውን ጊዜ ረጅም መስመሮች አይደሉም. እርግጥ ነው, ልዩ ሁኔታዎች አሉ. ለምሳሌ፣ በጃቫ የተፃፈ አንዳንድ አገልግሎት የተለየ ነገር ይጥላል፣ ተመዝግቧል። እና ስለዚህ ማለቂያ በሌለው ዑደት ውስጥ እና የሃርድ ድራይቭ ቦታ እያለቀ ነው። መፍትሄው በጣም ቀላል ነው. መስመሮቹ በጣም ረጅም ከሆኑ, ከዚያም ይቁረጡ. ረጅም ማለት ምን ማለት ነው? በአስር ኪሎባይት መጥፎ ነው *.

* በቅርብ ጊዜ የ ClickHouse እትሞች "አስማሚ ኢንዴክስ ግራናላሪቲ" ነቅቷል፣ ይህም ረጅም ገመዶችን የማከማቸት ችግርን በአብዛኛው ያስወግዳል።

ኪሎባይት መደበኛ ነው?

የተለመደ ነው.

ሀሎ! ለሪፖርቱ እናመሰግናለን! በቻት ውስጥ ስለዚህ ጉዳይ አስቀድሜ ጠየኩ, ነገር ግን መልስ እንዳገኝ አላስታውስም. የ WITH ክፍልን በCTE ፋሽን ለማራዘም እቅድ አለ?

ገና ነው. የ WITH ክፍል በመጠኑ ቀላል ያልሆነ ነው። ለእኛ እንደ ትንሽ ባህሪ ነው።

ገባኝ. አመሰግናለሁ!

ለሪፖርቱ እናመሰግናለን! በጣም አስገራሚ! ዓለም አቀፍ ጥያቄ. የውሂብ ስረዛን በማሻሻል ምናልባት በአንዳንድ ዓይነት ገለባዎች መልክ ለማድረግ ታቅዷል?

የግድ። ይህ በወረፋችን የመጀመሪያ ስራችን ነው። አሁን ሁሉንም ነገር በትክክል እንዴት ማድረግ እንዳለብን በንቃት እያሰብን ነው. እና የቁልፍ ሰሌዳውን መጫን መጀመር አለብዎት *.

* በቁልፍ ሰሌዳው ላይ ያሉትን ቁልፎች ተጫን እና ሁሉም ነገር ተከናውኗል.

በሆነ መንገድ የስርዓት አፈፃፀም ላይ ተጽዕኖ ይኖረዋል ወይንስ አይጎዳውም? ማስገባቱ አሁን እንዳለው ፈጣን ይሆናል?

ምናልባት እራሳቸው ይሰርዛሉ, ዝማኔዎቹ እራሳቸው በጣም ከባድ ይሆናሉ, ነገር ግን ይህ በምርጫዎች አፈፃፀም እና በምንም መልኩ የማስገባት አፈፃፀም ላይ ተጽዕኖ አይኖረውም.

እና አንድ ተጨማሪ ትንሽ ጥያቄ. በዝግጅቱ ላይ ስለ ዋናው ቁልፍ ተናገሩ። በዚህ መሠረት በነባሪ ወርሃዊ የሆነ ክፍፍል አለን ፣ አይደል? እና ከአንድ ወር ጋር የሚስማማ የቀን ገደብ ስናስቀምጥ፣ ያኔ ይህን ክፍልፋይ ብቻ እናነባለን፣ አይደል?

አዎን.

ጥያቄ። የትኛውንም ዋና ቁልፍ መምረጥ ካልቻልን ፣ በትክክል በ “ቀን” መስክ ላይ በትክክል ማድረግ ትክክል ነው ፣ ስለሆነም ከበስተጀርባው የበለጠ ሥርዓት ባለው መንገድ እንዲገጣጠሙ ከበስተጀርባ ትንሽ እንደገና ማዋቀር ይኖርዎታል? የክልል መጠይቆች ከሌልዎት እና ምንም አይነት ዋና ቁልፍ እንኳን መምረጥ ካልቻሉ በዋናው ቁልፍ ውስጥ ቀን ማስቀመጥ ጠቃሚ ነው?

አዎን.

ምናልባት በዚህ መስክ ከተደረደሩ ውሂቡ በተሻለ ሁኔታ የሚጨመቅበትን መስክ በዋናው ቁልፍ ውስጥ ማስገባት ምክንያታዊ ሊሆን ይችላል። ለምሳሌ የተጠቃሚ መታወቂያ። ተጠቃሚ ለምሳሌ ወደ ተመሳሳይ ጣቢያ ይሄዳል። በዚህ አጋጣሚ የተጠቃሚውን መታወቂያ እና ጊዜ ያስቀምጡ. እና ከዚያ የእርስዎ ውሂብ በተሻለ ሁኔታ የታመቀ ይሆናል። ቀኑን በተመለከተ፣ በእውነቱ ከሌልዎት እና በቀናት ላይ የክልል መጠይቆች ከሌሉዎት ቀኑን በዋናው ቁልፍ ውስጥ ማስገባት አይችሉም።

እሺ በጣም አመሰግናለሁ!

ምንጭ: hab.com