HighLoad++፣ Yuri Nasretdinov (VKontakte): ቪኬ በአስር ሺዎች ከሚቆጠሩ አገልጋዮች ወደ ClickHouse እንዴት እንደሚያስገባ

HighLoad ++ ሞስኮ 2018, ኮንግረስ አዳራሽ. ህዳር 9, 15:00

ማጠቃለያ እና አቀራረብ፡- http://www.highload.ru/moscow/2018/abstracts/4066

Yuri Nasretdinov (VKontakte): ሪፖርቱ በእኛ ኩባንያ ውስጥ ClickHouseን የመተግበር ልምድ - ለምን ያስፈልገናል, ምን ያህል ውሂብ እንደምናከማች, እንዴት እንደምንጽፈው እና የመሳሰሉትን ይናገራል.

ተጨማሪ ቁሳቁሶች ለ ELK፣ Big Query እና TimescaleDB ምትክ Clickhouseን በመጠቀም

ዩሪ ናስሬትዲኖቭ፡- - ሰላም ሁላችሁም! ቀደም ብዬ አስተዋውቄ እንደነበረው ስሜ ዩሪ ናስሬትዲኖቭ ነው። በ VKontakte ውስጥ እሰራለሁ. ከአገልጋያችን መርከቦች (በአስር ሺዎች) ወደ ClickHouse ውሂብ እንዴት እንደምናስገባ እናገራለሁ ።

ምዝግብ ማስታወሻዎች ምንድን ናቸው እና ለምን ይሰበስባሉ?

ምን እንነግራችኋለን፡ ያደረግነውን፣ ለምን “ክሊክ ሃውስ” ያስፈልገን ነበር፣ ለምንድነው የመረጥነው፣ የተለየ ነገር ሳያዋቅሩ ምን አይነት አፈጻጸም በግምት ማግኘት ይችላሉ። ስለ ቋት ጠረጴዛዎች፣ ከነሱ ጋር ስላጋጠሙን ችግሮች እና ከክፍት ምንጭ ስላዘጋጀናቸው የመፍትሄ ሃሳቦች - KittenHouse እና Lighthouse የበለጠ እነግርዎታለሁ።

ለምን ምንም ነገር ማድረግ አስፈለገን (ሁሉም ነገር ሁልጊዜ በ VKontakte ላይ ጥሩ ነው ፣ ትክክል?) የማረም ምዝግብ ማስታወሻዎችን ለመሰብሰብ ፈለግን (እና በመቶዎች የሚቆጠሩ ቴራባይት መረጃዎች እዚያ ነበሩ), ምናልባት በሆነ መንገድ ስታቲስቲክስን ለማስላት የበለጠ አመቺ ይሆናል; እና ይህ ሁሉ መደረግ ያለበት በአስር ሺዎች የሚቆጠሩ አገልጋዮች አሉን።

ለምን ወሰንን? ምዝግብ ማስታወሻዎችን ለማከማቸት መፍትሄዎች ነበሩን. እዚህ - እንደዚህ ያለ ህዝባዊ "Backend VK" አለ. ደንበኝነት እንድትመዘገቡ በጣም እመክራለሁ።

ምዝግብ ማስታወሻዎች ምንድን ናቸው? ይህ ባዶ ድርድሮችን የሚመልስ ሞተር ነው። በ VK ውስጥ ያሉ ሞተሮች ሌሎች ማይክሮ ሰርቪስ ብለው የሚጠሩት ናቸው። እና እዚህ ፈገግታ የሚለጠፍ ተለጣፊ (በጣም ብዙ መውደዶች)። እንዴት እና? ደህና ፣ የበለጠ ያዳምጡ!

ምዝግብ ማስታወሻዎችን ለማከማቸት ምን ጥቅም ላይ ሊውል ይችላል? ሃዱፕን መጥቀስ አይቻልም። ከዚያ, ለምሳሌ, Rsyslog (እነዚህን መዝገቦች በፋይሎች ውስጥ ማከማቸት). ኤልኤስዲ LSD ምን እንደሆነ ማን ያውቃል? አይ፣ ይህ ኤልኤስዲ አይደለም። ፋይሎችን በቅደም ተከተል ያከማቹ። ደህና፣ ClickHouse እንግዳ አማራጭ ነው።

Clickhouse እና ተወዳዳሪዎች: መስፈርቶች እና እድሎች

ምን እንፈልጋለን? ስለ ቀዶ ጥገናው ብዙ መጨነቅ እንደሌለብን ማረጋገጥ እንፈልጋለን, ስለዚህም ከሳጥኑ ውጭ እንዲሰራ, በተለይም በትንሹ ውቅር. ብዙ መጻፍ እንፈልጋለን, እና በፍጥነት መጻፍ. እና ለሁሉም አይነት ወራቶች, አመታት, ማለትም ለረጅም ጊዜ ማቆየት እንፈልጋለን. እነሱ ወደ እኛ መጥተው “የሆነ ነገር እዚህ እየሰራ አይደለም” ያሉት ከ3 ወራት በፊት የሆነ ችግር እንዳለ ለመረዳት ልንፈልግ እንችላለን እና ከ3 ወራት በፊት የሆነውን ለማየት እንፈልጋለን። የውሂብ መጨናነቅ - ለምን ተጨማሪ እንደሚሆን ግልጽ ነው - ምክንያቱም የሚወስደውን ቦታ ይቀንሳል.

እና እንደዚህ አይነት አስደሳች መስፈርት አለን-አንዳንድ ጊዜ የአንዳንድ ትዕዛዞችን ውጤት እንጽፋለን (ለምሳሌ ፣ ሎግ) ፣ በቀላሉ ከ 4 ኪሎባይት በላይ ሊሆን ይችላል። እና ይህ ነገር በ UDP ላይ የሚሰራ ከሆነ, ከዚያ ማውጣት አያስፈልገውም ... ለግንኙነቱ ምንም "ከላይ" አይኖረውም, እና ለብዙ ቁጥር አገልጋዮች ይህ ተጨማሪ ይሆናል.

ክፍት ምንጭ ምን እንደሚሰጠን እንይ። በመጀመሪያ ፣ የሎግ ሞተር አለን - ይህ የእኛ ሞተር ነው ። በመርህ ደረጃ, ሁሉንም ነገር ማድረግ ይችላል, ረጅም መስመሮችን እንኳን መጻፍ ይችላል. ደህና ፣ በግልፅ መረጃን አይጨምቀውም - ከፈለግን ትልቅ አምዶችን እራሳችንን መጭመቅ እንችላለን… እኛ ፣ በእርግጥ ፣ አንፈልግም (ከተቻለ)። ብቸኛው ችግር እሱ በማስታወስ ውስጥ የሚስማማውን ብቻ መስጠት ይችላል; የቀረውን ለማንበብ የዚህን ሞተር ቢንሎግ ማግኘት ያስፈልግዎታል እና በዚህ መሠረት በጣም ረጅም ጊዜ ይወስዳል።

ሌሎች ምን አማራጮች አሉ? ለምሳሌ "Hadup". የስራ ቀላልነት... ሃዱፕ ለማዋቀር ቀላል እንደሆነ ማን ያስባል? እርግጥ ነው, በመቅዳት ላይ ምንም ችግሮች የሉም. በሚያነቡበት ጊዜ, አንዳንድ ጊዜ ጥያቄዎች ይነሳሉ. በመርህ ደረጃ, ምናልባት አይደለም እላለሁ, በተለይም ለሎግ. የረጅም ጊዜ ማከማቻ - በእርግጥ፣ አዎ፣ የውሂብ መጨማደድ - አዎ፣ ረጅም ሕብረቁምፊዎች - መቅዳት እንደሚችሉ ግልጽ ነው። ነገር ግን ከበርካታ አገልጋዮች መቅዳት... አሁንም አንድ ነገር እራስዎ ማድረግ አለብዎት!

Rsyslog እንደውም ቢንሎግ ሳንጥለው እናነበው ዘንድ እንደ ምትኬ አማራጭ ተጠቅመንበታል ነገርግን ረጅም መስመር መፃፍ አይችልም፤ በመርህ ደረጃ ከ4 ኪሎባይት በላይ መፃፍ አይችልም። እራስዎ በተመሳሳይ መንገድ የውሂብ መጭመቂያ ማድረግ አለብዎት. ንባብ ከፋይሎች ይመጣል።

ከዚያም የኤልኤስዲ "ባዱሽካ" እድገት አለ. በመሠረቱ እንደ “Rsyslog” ተመሳሳይ ነው-ረጅም ገመዶችን ይደግፋል ፣ ግን በ UDP በኩል ሊሠራ አይችልም እና በእውነቱ ፣ በዚህ ምክንያት ፣ በሚያሳዝን ሁኔታ ፣ እዚያ ብዙ ነገሮች እንደገና መፃፍ አለባቸው። ኤልኤስዲ በአስር ሺዎች ከሚቆጠሩ አገልጋዮች መቅዳት እንዲችል እንደገና መንደፍ አለበት።

እና እዚህ! አንድ አስቂኝ አማራጭ ElasticSearch ነው. እንዴት ማለት ይቻላል? እሱ በማንበብ ጥሩ እየሰራ ነው ፣ ማለትም በፍጥነት ያነባል ፣ ግን በጽሑፍ ጥሩ አይደለም። በመጀመሪያ መረጃን ከጨመቀ በጣም ደካማ ነው። ምናልባትም፣ ሙሉ ፍለጋ ከመጀመሪያው የድምጽ መጠን የበለጠ ትላልቅ የውሂብ አወቃቀሮችን ይፈልጋል። ለመሥራት አስቸጋሪ ነው እና ብዙ ጊዜ ችግሮች ይነሳሉ. እና, በድጋሚ, በ Elastic ውስጥ መቅዳት - ሁሉንም ነገር በራሳችን ማድረግ አለብን.

እዚህ ClickHouse በጣም ጥሩ አማራጭ ነው። ብቸኛው ነገር በአስር ሺዎች ከሚቆጠሩ አገልጋዮች መቅዳት ችግር ነው. ግን ቢያንስ አንድ ችግር አለ, በሆነ መንገድ ለመፍታት መሞከር እንችላለን. እና የቀረው ዘገባ ስለዚህ ችግር ነው. ከ ClickHouse ምን አይነት አፈጻጸም መጠበቅ ይችላሉ?

እንዴት እናስገባዋለን? የመዋሃድ ዛፍ

ከእናንተ መካከል ስለ "ክሊክ ሃውስ" ያልሰማ ወይም የማያውቅ ማነው? ልነግርህ አለብኝ አይደል? በጣም ፈጣን. እዚያ ማስገባት - 1-2 ጊጋባይት በሰከንድ, እስከ 10 ጊጋባይት በሰከንድ የሚፈነዳው ይህንን ውቅር በትክክል ይቋቋማል - ሁለት ባለ 6-ኮር Xeons (ይህም በጣም ኃይለኛ አይደለም), 256 ጊጋባይት ራም, 20 ቴራባይት አለ. በ RAID (ማንም አልተዋቀረም, ነባሪ ቅንጅቶች). Alexey Milovidov, ClickHouse ገንቢ, ምንም ነገር ስላላዋቀርን (ሁሉም ነገር ለእኛ እንደዚያ ሰርቷል) እያለቀሰ ሊሆን ይችላል. በዚህ መሠረት መረጃው በደንብ ከተጨመቀ በሰከንድ ወደ 6 ቢሊዮን የሚጠጉ መስመሮችን የመቃኘት ፍጥነት ማግኘት ይቻላል። በጽሑፍ ሕብረቁምፊ ላይ % ከወደዱ - 100 ሚሊዮን መስመሮች በሰከንድ ፣ ማለትም ፣ በጣም ፈጣን ይመስላል።

እንዴት እናስገባዋለን? ደህና ፣ VK PHP እንደሚጠቀም ያውቃሉ። ከእያንዳንዱ የPHP ሰራተኛ በኤችቲቲፒ ወደ "ክሊክ ሃውስ" ለእያንዳንዱ መዝገብ ወደ MergeTree ሰንጠረዥ እናስገባለን። በዚህ እቅድ ላይ ችግር የሚያየው ማነው? በሆነ ምክንያት ሁሉም ሰው እጃቸውን አያነሱም. ልንገርህ።

በመጀመሪያ ፣ ብዙ አገልጋዮች አሉ - በዚህ መሠረት ፣ ብዙ ግንኙነቶች (መጥፎ) ይኖራሉ። ከዚያ በሴኮንድ ከአንድ ጊዜ በላይ ብዙ ጊዜ ወደ MergeTree ውሂብ ማስገባት የተሻለ ነው። እና ለምን እንደሆነ ማን ያውቃል? እሺ እሺ. ስለዚህ ጉዳይ ትንሽ ተጨማሪ እነግርዎታለሁ። ሌላው ትኩረት የሚስብ ጥያቄ እኛ ትንታኔዎችን እያደረግን አይደለም, መረጃን ማበልጸግ አያስፈልገንም, መካከለኛ አገልጋዮችን አያስፈልገንም, በቀጥታ ወደ "ClickHouse" ውስጥ ማስገባት እንፈልጋለን (በተለይም - የበለጠ ቀጥታ, የተሻለ ነው).

በዚህ መሠረት በ MergeTree ውስጥ ማስገባት እንዴት ይከናወናል? በሴኮንድ ውስጥ ከአንድ ጊዜ በላይ ወይም ባነሰ ጊዜ ውስጥ ማስገባት ለምን የተሻለ ነው? እውነታው ግን "ክሊክ ሃውስ" የአምድ ዳታቤዝ ነው እና ውሂቡን በዋናው ቁልፍ ወደ ላይ በሚወጣው ቅደም ተከተል ይመድባል እና ሲያስገቡ ብዙ ፋይሎች ቢያንስ ቢያንስ ውሂቡ ከተደረደረባቸው የአምዶች ብዛት ጋር እኩል ነው የሚፈጠረው። በአንደኛ ደረጃ ቁልፉ ላይ (የተለየ ማውጫ ተፈጠረ ፣ ለእያንዳንዱ ማስገቢያ በዲስክ ላይ ያሉ የፋይሎች ስብስብ)። ከዚያ የሚቀጥለው ማስገቢያ ይመጣል, እና ከበስተጀርባ ወደ ትላልቅ "ክፍልፋዮች" ይጣመራሉ. መረጃው የተደረደረ በመሆኑ ብዙ ማህደረ ትውስታ ሳይወስድ ሁለት የተደረደሩ ፋይሎችን "ማዋሃድ" ይቻላል.

ነገር ግን፣ እርስዎ እንደሚገምቱት፣ ለእያንዳንዱ ማስገቢያ 10 ፋይሎችን ከጻፉ፣ ከዚያ ClickHouse (ወይም አገልጋይዎ) በፍጥነት ያበቃል፣ ስለዚህ በትልቅ ስብስቦች ውስጥ ማስገባት ይመከራል። በዚህ መሠረት የመጀመሪያውን እቅድ ወደ ምርት አልጀመርንም. ወዲያውኑ አንዱን አስጀመርን ይህም እዚህ ቁጥር 2 ያለው፡-

እዚህ ያስጀመርንባቸው ወደ አንድ ሺህ የሚጠጉ አገልጋዮች እንዳሉ አስብ፣ ፒኤችፒ ብቻ አለ። እና በእያንዳንዱ አገልጋይ ላይ "Kittenhouse" ብለን የምንጠራው የአካባቢያችን ወኪል አለ, እሱም ከ "ክሊክሃውስ" ጋር አንድ ግንኙነትን የሚይዝ እና መረጃን በየጥቂት ሰከንዶች ውስጥ ያስገባል. ውሂብን ወደ MergeTree ሳይሆን ወደ ቋት ሠንጠረዥ ውስጥ ያስገባል፣ ይህም በቀጥታ ወደ MergeTree እንዳይገባ በትክክል ያገለግላል።

ከጠባቂ ጠረጴዛዎች ጋር በመስራት ላይ

ምንድን ነው? የቋት ጠረጴዛዎች የተበጣጠሰ የማህደረ ትውስታ ክፍል ናቸው (ይህም በተደጋጋሚ ሊገባበት ይችላል)። እነሱ ብዙ ቁርጥራጮችን ያቀፈ ነው ፣ እና እያንዳንዳቸው ቁርጥራጮች እንደ ገለልተኛ ቋት ይሠራሉ ፣ እና እነሱ በተናጥል ይታጠባሉ (በመያዣው ውስጥ ብዙ ቁርጥራጮች ካሉዎት ፣ ከዚያ በሰከንድ ብዙ ማስገቢያዎች ይኖራሉ)። ከእነዚህ ሠንጠረዦች ማንበብ ይቻላል - ከዚያም የመጠባበቂያው ይዘት እና የወላጅ ጠረጴዛን አንድነት ያንብቡ, ነገር ግን በዚህ ቅጽበት መፃፉ ታግዷል, ስለዚህ ከዚያ ማንበብ አይሻልም. እና ቋት ሠንጠረዦች በጣም ጥሩ QPS ያሳያሉ፣ ማለትም፣ እስከ 3 ሺህ QPS በሚያስገቡበት ጊዜ ምንም አይነት ችግር አይኖርብዎትም። አገልጋዩ ኃይል ካጣ ውሂቡ ሊጠፋ እንደሚችል ግልጽ ነው, ምክንያቱም በማህደረ ትውስታ ውስጥ ብቻ ተከማችቷል.

በተመሳሳይ ጊዜ, ከጠባቂ ጋር ያለው እቅድ ALTERን ያወሳስበዋል, ምክንያቱም በመጀመሪያ የድሮውን የመጠባበቂያ ሠንጠረዥ በአሮጌው እቅድ መጣል ያስፈልግዎታል (መረጃው በየትኛውም ቦታ አይጠፋም, ምክንያቱም ጠረጴዛው ከመጥፋቱ በፊት ይታጠባል). ከዚያ የሚፈልጉትን ሰንጠረዥ "ለውጥ" እና እንደገና የማጠራቀሚያውን ጠረጴዛ ይፍጠሩ. በዚህ መሠረት የመጠባበቂያ ሠንጠረዥ ባይኖርም, የእርስዎ ውሂብ ወደ የትኛውም ቦታ አይፈስስም, ነገር ግን ቢያንስ በአካባቢው በዲስክ ላይ ሊኖርዎት ይችላል.

Kittenhouse ምንድን ነው እና እንዴት ነው የሚሰራው?

KittenHouse ምንድን ነው? ይህ ተኪ ነው። ምን ቋንቋ ገምት? በሪፖርቴ ውስጥ በጣም አበረታች ርዕሶችን ሰብስቤ ነበር - “ክሊክ ሃውስ” ፣ ሂድ ፣ ምናልባት ሌላ ነገር አስታውሳለሁ። አዎ፣ ይሄ በ Go ውስጥ ተጽፏል፣ ምክንያቱም በትክክል በ C እንዴት መጻፍ እንዳለብኝ ስለማላውቅ፣ አልፈልግም።

በዚህ መሠረት ከእያንዳንዱ አገልጋይ ጋር ያለውን ግንኙነት ይይዛል እና ወደ ማህደረ ትውስታ መፃፍ ይችላል. ለምሳሌ የስህተት ምዝግብ ማስታወሻዎችን ወደ Clickhouse የምንጽፍ ከሆነ፣ ከዚያም Clickhouse ውሂብ ለማስገባት ጊዜ ከሌለው (ከሁሉም በኋላ ፣ በጣም ብዙ ከተጻፈ) ፣ ከዚያ ማህደረ ትውስታውን አናበጠውም - የቀረውን በቀላሉ እንጥላለን። ምክንያቱም በሴኮንድ ብዙ ጊጋቢትስ ስህተቶችን ከጻፍን ምናልባት ጥቂቱን መጣል እንችላለን። Kittenhouse ይህን ማድረግ ይችላል. በተጨማሪም, አስተማማኝ ማድረስ ይችላል, ማለትም, በአካባቢው ማሽን ላይ ወደ ዲስክ መጻፍ እና አንድ ጊዜ (እዚያ, በየሁለት ሰከንድ አንድ ጊዜ) ከዚህ ፋይል ውሂብ ለማድረስ ይሞክራል. እና መጀመሪያ ላይ መደበኛውን የእሴቶች ቅርጸት ተጠቀምን - አንዳንድ ሁለትዮሽ ቅርፀቶች አይደለም ፣ የጽሑፍ ቅርጸት (እንደ መደበኛ SQL)።

ግን ከዚያ ይህ ሆነ። አስተማማኝ ማድረስ ተጠቀምን፣ ምዝግብ ማስታወሻዎችን ጻፍን፣ ከዚያም ወሰንን (ሁኔታዊ የፈተና ክላስተር ነበር)... ለብዙ ሰአታት ወጥቶ ወደነበረበት እንዲመለስ ተደርጓል፣ እና ማስገባት ከሺህ ሰርቨሮች ተጀመረ - ክሊክሃውስ አሁንም ያለው “በግንኙነት ላይ ያለ ክር” - በዚህ መሠረት በሺህ ግንኙነቶች ውስጥ ንቁ ማስገባት ወደ አንድ ሺህ ተኩል ያህል በአገልጋዩ ላይ አማካይ ጭነት ያስከትላል። የሚገርመው, አገልጋዩ ጥያቄዎችን ተቀብሏል, ነገር ግን ውሂቡ አሁንም ከተወሰነ ጊዜ በኋላ ገብቷል; ግን አገልጋዩ እሱን ለማገልገል በጣም ከባድ ነበር…

nginx ያክሉ

ለእያንዳንዱ የግንኙነት ሞዴል ለክር እንዲህ ዓይነቱ መፍትሔ nginx ነው። ከ Clickhouse ፊት ለፊት nginx ን ጫንን ፣ በተመሳሳይ ጊዜ ለሁለት ቅጂዎች ማመጣጠን አዘጋጅተናል (የእኛ የማስገቢያ ፍጥነት በ 2 ጊዜ ጨምሯል ፣ ምንም እንኳን ይህ መሆን ያለበት እውነታ ባይሆንም) እና ከ Clickhouse ጋር ያለውን ግንኙነት ብዛት ገድቧል ፣ ወደላይ እና፣ በዚህ መሰረት፣ የበለጠ፣ ከ50 ግንኙነቶች ይልቅ፣ ለማስገባት ምንም ፋይዳ የሌለው አይመስልም።

ከዚያ ይህ እቅድ በአጠቃላይ ድክመቶች እንዳሉት ተገነዘብን, ምክንያቱም እዚህ አንድ nginx ብቻ አለን. በዚህ መሠረት, ይህ nginx ከተበላሸ, ቅጂዎች ቢኖሩም, ውሂብ እናጣለን ወይም, ቢያንስ, የትኛውም ቦታ አንጻፍም. ለዚያም ነው የራሳችንን ጭነት ማመጣጠን ያደረግነው። እኛ ደግሞ “ክሊክሃውስ” አሁንም ለእንጨት ተስማሚ እንደሆነ ተገነዘብን ፣ እና “ጋኔኑ” እንዲሁ በ “ክሊክሃውስ” ውስጥ መዝገቦቹን መጻፍ ጀመረ - በጣም ምቹ ፣ እውነቱን ለመናገር። አሁንም ለሌሎች "አጋንንት" እንጠቀማለን.

ከዚያ ይህን አስደሳች ችግር ደርሰናል፡ በSQL ሁነታ ላይ መደበኛ ያልሆነ የማስገቢያ ዘዴን ከተጠቀሙ፣ ሙሉ በሙሉ በAST ላይ የተመሰረተ SQL ተንታኝ ያስገድዳል፣ ይህም በጣም ቀርፋፋ ነው። በዚህ መሠረት ይህ በጭራሽ እንዳይከሰት ለማድረግ ቅንብሮችን አክለናል። እኛ የጭነት ማመጣጠን ፣ የጤና ምርመራዎችን አድርገናል ፣ ስለሆነም አንድ ሰው ከሞተ አሁንም መረጃውን እንተዋለን። አሁን የተለያዩ የ Clickhouse ስብስቦች እንዲኖረን የሚያስፈልጉን በጣም ብዙ ጠረጴዛዎች አሉን። እና ስለሌሎች አጠቃቀሞች ማሰብ ጀመርን - ለምሳሌ ፣ ከ nginx ሞጁሎች ምዝግብ ማስታወሻዎችን መጻፍ እንፈልጋለን ፣ ግን የእኛን RPC በመጠቀም እንዴት መገናኘት እንደሚችሉ አያውቁም። ደህና፣ ቢያንስ በሆነ መንገድ እንዴት እንደሚልኩ ማስተማር እፈልጋለሁ - ለምሳሌ በUDP በኩል በ localhost ላይ ዝግጅቶችን ለመቀበል እና ከዚያ ወደ Clickhouse ያስተላልፉ።

ከመፍትሔው አንድ እርምጃ ቀርቷል።

የመጨረሻው እቅድ ይህን ይመስላል (የዚህ እቅድ አራተኛው ስሪት): በ Clickhouse ፊት ለፊት ባለው እያንዳንዱ አገልጋይ ላይ nginx አለ (በተመሳሳይ አገልጋይ ላይ) እና በቀላሉ በ 50 ግንኙነቶች ብዛት ላይ ለ localhost ጥያቄዎችን ያቀርባል. ቁርጥራጮች. እና ይህ እቅድ ቀድሞውኑ በጣም እየሰራ ነበር, ሁሉም ነገር በእሱ በጣም ጥሩ ነበር.

በዚህ መልክ ለአንድ ወር ያህል ኖረናል። ሁሉም ተደስተው፣ ጠረጴዛ ጨመሩ፣ ጨምረዋል፣ ጨመሩ... ባጠቃላይ፣ ቋት ሰንጠረዦችን የጨመርንበት መንገድ በጣም ጥሩ እንዳልነበር ሆነ (እንዲህ እናድርገው)። በእያንዳንዱ ጠረጴዛ ውስጥ 16 ቁርጥራጮችን እና ለሁለት ሰከንዶች ብልጭታ ክፍተት አደረግን; 20 ሠንጠረዦች ነበሩን እና እያንዳንዱ ጠረጴዛ በሰከንድ 8 ማስገቢያዎችን ተቀብሏል - እና በዚህ ጊዜ "ክሊክ ሃውስ" ተጀመረ ... መዝገቦቹ መቀዛቀዝ ጀመሩ. እነሱ እንኳን አላለፉም ... Nginx በነባሪነት እንደዚህ ያለ አስደሳች ነገር ነበረው ፣ ግንኙነቶቹ ከላይኛው ዥረቱ ላይ ካበቁ ፣ ከዚያ በቀላሉ “502” ወደ ሁሉም አዲስ ጥያቄዎች መለሰ።

እና እዚህ አለን (በክሊክ ሃውስ ውስጥ ያሉትን ምዝግብ ማስታወሻዎች ብቻ ተመለከትኩኝ) ወደ ግማሽ በመቶ የሚጠጉ ጥያቄዎች አልተሳኩም። በዚህ መሠረት የዲስክ አጠቃቀም ከፍተኛ ነበር, ብዙ ውህዶች ነበሩ. ደህና፣ ምን አደረግሁ? በተፈጥሮ ፣ ግንኙነቱ እና የላይኛው ዥረቱ በትክክል ለምን እንዳበቃ ለማወቅ አልተቸገርኩም።

Nginxን በተገላቢጦሽ ፕሮክሲ በመተካት።

ይህንን በራሳችን ማስተዳደር እንዳለብን ወሰንኩ ፣ ለ nginx መተው አያስፈልገንም - nginx በ Clickhouse ውስጥ ምን ጠረጴዛዎች እንዳሉ አያውቅም ፣ እና nginxን በተገላቢጦሽ ፕሮክሲ ተክቻለሁ ፣ እኔ እራሴም የፃፍኩት።

ምን እያደረገ ነው? በ fasthttp ቤተ-መጽሐፍት "goshnoy" ላይ የተመሠረተ ነው የሚሰራው፣ ማለትም፣ ፈጣን፣ ልክ እንደ nginx በፍጥነት። ይቅርታ፣ Igor፣ እዚህ ካሉ (ማስታወሻ፡ Igor Sysoev የ nginx ድር አገልጋይን የፈጠረው ሩሲያዊ ፕሮግራመር ነው)። እነዚህ ምን አይነት መጠይቆች እንደሆኑ መረዳት ይችላል - INSERT ወይም SELECT - በዚህ መሰረት ለተለያዩ አይነት መጠይቆች የተለያዩ የግንኙነት ገንዳዎችን ይይዛል።

በዚህ መሠረት, የማስገባት ጥያቄዎችን ለመሙላት ጊዜ ባንኖረውም, "ምርጫዎች" ያልፋሉ, እና በተቃራኒው. እና መረጃውን ወደ ቋት ሰንጠረዦች ይከፋፍላል - በትንሽ ቋት: ስህተቶች ካሉ ፣ የአገባብ ስህተቶች እና ሌሎችም - በተቀረው መረጃ ላይ ከፍተኛ ተጽዕኖ እንዳያሳድሩ ፣ ምክንያቱም በቀላሉ ወደ ቋት ጠረጴዛዎች ውስጥ ስናስገባ ፣ እኛ ትንሽ "ባቺ" ነበረው, እና ሁሉም የአገባብ ስህተቶች በዚህ ትንሽ ቁራጭ ላይ ብቻ ተጽዕኖ ያሳድራሉ. እና እዚህ እነሱ ቀድሞውኑ ትልቅ ቋት ላይ ተጽዕኖ ያሳድራሉ። ትንሹ 1 ሜጋባይት ነው, ማለትም, ትንሽ አይደለም.

ማመሳሰልን ማስገባት እና nginxን በመተካት በመሠረቱ nginx ከዚህ በፊት ያደረገውን ተመሳሳይ ነገር ያደርጋል - ለዚህም የአካባቢውን “Kittenhouse” መለወጥ አያስፈልግዎትም። እና fasthttp ስለሚጠቀም፣ በጣም ፈጣን ነው - በግልባጭ ፕሮክሲ በኩል ለአንድ ማስገቢያ በሰከንድ ከ100 ሺህ በላይ ጥያቄዎችን ማቅረብ ትችላለህ። በንድፈ-ሀሳብ አንድ መስመር በአንድ ጊዜ ወደ ኪተን ሃውስ ሪቨር ፕሮክሲ ማስገባት ትችላላችሁ፣ ግን በእርግጥ ያንን አናደርግም።

መርሃግብሩ እንደዚህ ይመስላል-“Kittenhouse” ፣ የተገላቢጦሽ ተኪ ቡድኖች ብዙ ጥያቄዎችን ወደ ጠረጴዛዎች እና በተራው ፣ የቋት ጠረጴዛዎች ወደ ዋናዎቹ ያስገባቸዋል።

ገዳይ ጊዜያዊ መፍትሄ ነው፣ Kitten ቋሚ ነው።

ይህ የሚያስደስት ችግር ነው... አንዳችሁም fasthttp ተጠቅመዋል? Fasthttpን ከPOST ጥያቄዎች ጋር የተጠቀመው ማነው? ምናልባት፣ ይህ በእውነት መደረግ አልነበረበትም፣ ምክንያቱም የጥያቄውን አካል በነባሪነት ስለሚያስቀምጠው፣ እና የኛ ቋት መጠን ወደ 16 ሜጋባይት ተቀናብሯል። ማስገባቱ በተወሰነ ደረጃ መቆየቱን አቆመ፣ እና 16-ሜጋባይት ቁርጥራጮች ከሁሉም በአስር ሺዎች ከሚቆጠሩ አገልጋዮች መምጣት ጀመሩ፣ እና ሁሉም ወደ Clickhouse ከመላካቸው በፊት በማስታወሻ ውስጥ ተይዘዋል። በዚህ መሰረት፣ የማስታወስ ችሎታው አለቀ፣ ከትውስታ ውጪ ገዳይ መጥቶ የተገላቢጦሹን ፕሮክሲ (ወይም "ክሊክሃውስ") ገደለው፣ እሱም በንድፈ ሀሳብ ከተገላቢጦሽ ፕሮክሲ የበለጠ "መብላት" ይችላል። ዑደቱ እራሱን ደገመ። በጣም ደስ የሚል ችግር አይደለም. ምንም እንኳን በዚህ ላይ የተደናቀፍነው ከበርካታ ወራት ቀዶ ጥገና በኋላ ብቻ ነው.

አኔ ያደረግኩት? እንደገና፣ በትክክል የሆነውን በትክክል መረዳት አልወድም። እኔ እንደማስበው ወደ ማህደረ ትውስታ መቆጠብ እንደሌለብዎት በጣም ግልፅ ነው። እኔ fasthttp መጠገኛ አልቻለም, እኔ ሞክረው ቢሆንም. ነገር ግን ምንም ነገር ማስተካከል እንዳይኖር ለማድረግ የሚያስችል መንገድ አገኘሁ እና በ HTTP ውስጥ የራሴን ዘዴ ይዤ መጣሁ - KITTEN ብዬ ጠራሁት። ደህና፣ ምክንያታዊ ነው - “VK”፣ “Kitten”... ሌላስ?...

ጥያቄ በኪቲን ዘዴ ወደ አገልጋዩ ከመጣ አገልጋዩ “meow” የሚል ምላሽ መስጠት አለበት - ምክንያታዊ። ለዚህ ምላሽ ከሰጠ, ይህንን ፕሮቶኮል እንደሚረዳው ይቆጠራል, ከዚያም ግንኙነቱን እጥለዋለሁ (fasthttp እንደዚህ አይነት ዘዴ አለው), ግንኙነቱ ወደ "ጥሬ" ሁነታ ይሄዳል. ለምን አስፈለገኝ? ከTCP ግንኙነቶች ማንበብ እንዴት እንደሚከሰት መቆጣጠር እፈልጋለሁ። TCP አስደናቂ ንብረት አለው: ማንም ከሌላኛው ወገን የማያነብ ከሆነ, ጽሑፉ መጠበቅ ይጀምራል, እና ማህደረ ትውስታ በተለይ በዚህ ላይ አይውልም.

እናም በአንድ ጊዜ ወደ 50 ያህል ደንበኞች አነበብኩ (ከሃምሳ ምክንያቱም ሃምሳ በእርግጠኝነት በቂ መሆን አለበት, ምንም እንኳን መጠኑ ከሌላ ዲሲ ቢመጣም) ... በዚህ አቀራረብ ፍጆታ ቢያንስ 20 ጊዜ ቀንሷል, እኔ ግን እውነቱን ለመናገር. , በትክክል የትኛውን ሰዓት መለካት አልቻልኩም, ምክንያቱም ቀድሞውኑ ትርጉም የለሽ ነው (ቀድሞውንም የስህተት ደረጃ ላይ ደርሷል). ፕሮቶኮሉ ሁለትዮሽ ነው, ማለትም, የሰንጠረዡን ስም እና ውሂብ ይዟል; ምንም http ራስጌዎች የሉም፣ ስለዚህ የድር ሶኬት አልተጠቀምኩም (ከአሳሾች ጋር መገናኘት አያስፈልገኝም - ፍላጎታችንን የሚያሟላ ፕሮቶኮል ሰራሁ)። እና ሁሉም ነገር በእሱ ላይ መልካም ሆነ.

ቋት ጠረጴዛው ያሳዝናል።

በቅርቡ ሌላ ትኩረት የሚስብ የጠረጴዛዎች ገጽታ አጋጥሞናል። እና ይህ ችግር ከሌሎቹ የበለጠ ህመም ነው. እስቲ ይህንን ሁኔታ በዓይነ ሕሊናህ እናስብ፡ አንተ ቀድሞውንም Clickhouse ን በንቃት እየተጠቀምክ ነው፣ በደርዘን የሚቆጠሩ የ Clickhouse አገልጋዮች አሉህ፣ እና ለማንበብ በጣም ረጅም ጊዜ የሚወስድ አንዳንድ ጥያቄዎች አሎት (ከ 60 ሰከንድ በላይ እንበል)። እና በዚህ ቅጽበት መጥተህ Alter አድርግ... እስከዚያው ድረስ ከ“መቀየር” በፊት የተጀመሩ “ይምረጡ” በዚህ ሠንጠረዥ ውስጥ አይካተቱም “መቀየር” አይጀምርም - ምናልባት “ክሊክ ሃውስ” እንዴት እንደሚሰራ አንዳንድ ባህሪዎች ይህ ቦታ. ምናልባት ይህ ሊስተካከል ይችላል? ወይስ የማይቻል ነው?

በአጠቃላይ, በእውነቱ ይህ ያን ያህል ትልቅ ችግር እንዳልሆነ ግልጽ ነው, ነገር ግን በተጠባባቂ ጠረጴዛዎች የበለጠ ህመም ይሆናል. ምክንያቱም፣ እንበል፣ የእርስዎ “ለውጥ” ጊዜ ካለፈ (እና በሌላ አስተናጋጅ ላይ ጊዜ ሊያልቅ ይችላል - በእርስዎ ላይ ሳይሆን በብዜት፣ ለምሳሌ)፣ ከዚያ... የቋት ሰንጠረዡን ሰርዘዋል፣ የእርስዎ “መቀየር” ( ወይም ሌላ አስተናጋጅ) ጊዜው አልፎበታል። ከዚያ “መቀየር” ስህተት ተፈጥሯል) - አሁንም ውሂቡ መጻፉን መቀጠሉን ማረጋገጥ አለብዎት፡ የቋት ሠንጠረዦችን መልሰው ይፈጥራሉ (እንደ ወላጅ ጠረጴዛው ተመሳሳይ ዕቅድ) ፣ ከዚያ “መቀየር” ያልፋል፣ ከሁሉም በኋላ ያበቃል፣ እና ቋት ሰንጠረዡ ከወላጅ በሼማ ልዩነት ይጀምራል። “መለዋወጫ” ምን እንደነበረ ላይ በመመስረት ፣ ማስገቢያው ወደዚህ ቋት ጠረጴዛ ላይሄድ ይችላል - ይህ በጣም አሳዛኝ ነው።

እንደዚህ አይነት ምልክትም አለ (ምናልባት አንድ ሰው አስተውሎታል) - በአዲሱ የ Clickhouse ስሪቶች ውስጥ query_thread_log ይባላል። በነባሪ፣ በአንዳንድ ስሪት ውስጥ አንድ ነበር። እዚህ በሁለት ወራት ውስጥ 840 ሚሊዮን መዝገቦችን ሰብስበናል (100 ጊጋባይት)። ይህ የሆነበት ምክንያት "ማስገባቶች" እዚያ የተፃፉ በመሆናቸው ነው (ምናልባት, በነገራችን ላይ, አሁን አልተጻፉም). እንደነገርኳችሁ፣ የእኛ “ማስገቢያዎች” ትንሽ ናቸው - ወደ ቋት ጠረጴዛዎች ብዙ “ማስገቢያዎች” ነበሩን። ይህ እንደተሰናከለ ግልጽ ነው - በአገልጋያችን ላይ ያየሁትን ነው የምነግራችሁ። ለምን? ይህ የማጠራቀሚያ ሰንጠረዦችን መጠቀምን የሚቃወም ሌላ ክርክር ነው! ስፖቲ በጣም አዝኗል።

የዚህ ሰው ስም ስፖቲ መሆኑን ማን ያውቃል? የቪኬ ሰራተኞች እጃቸውን አነሱ። እሺ

ስለ “KitttenHouse” ዕቅዶች

ዕቅዶች ብዙውን ጊዜ አይጋሩም፣ አይደል? በድንገት እነሱን አያሟሉም እና በሌሎች ሰዎች ዓይን ውስጥ በጣም ጥሩ አይመስሉም. ግን አደጋውን እወስዳለሁ! እኛ የሚከተሉትን ማድረግ እንፈልጋለን: ቋት ጠረጴዛዎች, ለእኔ የሚመስለኝ, አሁንም ክራንች ናቸው እና እኛ እራሳችንን ማስገቢያ ቋት ያስፈልገናል. ግን አሁንም በዲስክ ላይ ማቆየት ስለማንፈልግ ማስገባቱን በሜሞሪ ውስጥ እናስቀምጠዋለን።

በዚህ መሠረት ፣ “ማስገባት” ሲሠራ ፣ ከአሁን በኋላ የሚመሳሰል አይሆንም - ቀድሞውኑ እንደ ቋት ጠረጴዛ ይሠራል ፣ በወላጅ ጠረጴዛው ውስጥ ያስገባል (ጥሩ ፣ አንድ ቀን በኋላ) እና ያስገባው ያለፈበት እና የትኛውም በተለየ ቻናል በኩል ሪፖርት ያደርጋል ። የለኝም.

የተመሳሰለውን ማስገቢያ ለምን መተው አልችልም? የበለጠ ምቹ ነው። እውነታው ግን ከ 10 ሺህ አስተናጋጆች ካስገቡ ሁሉም ነገር ጥሩ ነው - ከእያንዳንዱ አስተናጋጅ ትንሽ ትንሽ ያገኛሉ, በሴኮንድ አንድ ጊዜ ያስገባሉ, ሁሉም ነገር ጥሩ ነው. ግን ይህ እቅድ እንዲሠራ እፈልጋለሁ ፣ ለምሳሌ ፣ ከሁለት ማሽኖች ፣ በከፍተኛ ፍጥነት ማውረድ ይችላሉ - ምናልባት ከፍተኛውን ከ Clickhouse ላያገኙ ይችላሉ ፣ ግን ቢያንስ 100 ሜጋባይት በሰከንድ ከአንድ ማሽን በግልባጭ ፕሮክሲ ይፃፉ - ይህ መርሃግብሩ ወደ ትልቅ እና ትንሽ መጠን መመዘን አለበት ፣ ስለሆነም ለእያንዳንዱ ግቤት አንድ ሰከንድ መጠበቅ አንችልም ፣ ስለዚህ የማይመሳሰል መሆን አለበት። እና በተመሳሳይ መልኩ, ማስገባቱ ከተጠናቀቀ በኋላ ያልተመሳሰሉ ማረጋገጫዎች መምጣት አለባቸው. አልፏል ወይም አላለፈም እናውቃለን።

በጣም አስፈላጊው ነገር በዚህ እቅድ ውስጥ ማስገባቱ ተከስቶ እንደሆነ ወይም እንዳልሆነ በእርግጠኝነት እናውቃለን. ይህንን ሁኔታ በዓይነ ሕሊናህ አስብ: የመጠባበቂያ ጠረጴዛ አለህ, አንድ ነገር ጽፈሃል, እና ከዚያ እንበል, ሠንጠረዡ ወደ ንባብ ሁነታ ብቻ ገባ እና ቋቱን ለማጠብ ሞክሯል. መረጃው የት ይሄዳል? በመጠባበቂያው ውስጥ ይቀራሉ. ግን በዚህ ላይ እርግጠኛ መሆን አንችልም - ሌላ ስህተት ካለ ምን ይሆናል, በዚህ ምክንያት ውሂቡ በመጠባበቂያው ውስጥ አይቆይም ... (አድራሻዎች Alexey Milovidov, Yandex, ClickHouse ገንቢ) ወይም ይቀራል? ሁሌም? አሌክሲ ሁሉም ነገር ደህና እንደሚሆን ያሳምነናል. እሱን የማናምንበት ምንም ምክንያት የለንም። ግን ሁሉም ተመሳሳይ ናቸው-የመያዣ ሰንጠረዦችን ካልተጠቀምን, ከዚያ በእነሱ ላይ ምንም ችግሮች አይኖሩም. ሁለት እጥፍ ጠረጴዛዎችን መፍጠርም ምቹ አይደለም, ምንም እንኳን በመርህ ደረጃ ምንም ትልቅ ችግሮች የሉም. እቅዱ ይህ ነው።

ስለ ንባብ እንነጋገር

አሁን ስለ ማንበብ እናውራ። የራሳችንን መሳሪያ እዚህም ጽፈናል። ጥሩ ይመስላል, ለምን የራስዎን መሳሪያ እዚህ ይፃፉ? ... እና ታቢክስን የተጠቀመው ማን ነው? እንደምንም ጥቂት ሰዎች እጃቸውን አነሱ... እና በታቢክስ አፈጻጸም የረካው ማነው? ደህና, በእሱ ደስተኛ አይደለንም, እና ውሂብን ለማየት በጣም ምቹ አይደለም. ለትንታኔ ጥሩ ነው፣ ግን ለማየት ብቻ በግልጽ አልተመቻቸም። ስለዚህ የራሴን ፣ የራሴን በይነገጽ ጻፍኩ ።

በጣም ቀላል ነው - ውሂብ ብቻ ማንበብ ይችላል. ግራፊክስን እንዴት ማሳየት እንዳለበት አያውቅም, ምንም ነገር እንዴት እንደሚሰራ አያውቅም. ነገር ግን የሚያስፈልገንን ነገር ሊያሳይ ይችላል-ለምሳሌ በሠንጠረዡ ውስጥ ስንት ረድፎች እንዳሉ, ምን ያህል ቦታ እንደሚወስድ (ወደ አምዶች ሳይሰበር), ማለትም በጣም መሠረታዊ የሆነ በይነገጽ ያስፈልገናል.

እና ከሴኬል ፕሮ ጋር በጣም ተመሳሳይ ይመስላል ፣ ግን በ Twitter's Bootstrap ላይ ብቻ የተሰራ እና ሁለተኛው ስሪት። እርስዎ ይጠይቃሉ: "ዩሪ, ለምን በሁለተኛው ስሪት ላይ?" ስንት አመት? 2018? በአጠቃላይ ፣ ይህንን ከረጅም ጊዜ በፊት ለ “ጡንቻ” (MySQL) አድርጌያለሁ እና እዚያ ባሉት መጠይቆች ውስጥ ሁለት መስመሮችን ቀይሬያለሁ እና ለ “ክሊክ ሃውስ” መሥራት ጀመረ ፣ ለየትኛውም ልዩ አመሰግናለሁ! ተንታኙ ከ "ጡንቻ" ጋር በጣም ተመሳሳይ ስለሆነ እና ጥያቄዎቹ በጣም ተመሳሳይ ናቸው - በጣም ምቹ, በተለይም በመጀመሪያ.

ደህና, ሰንጠረዦችን ማጣራት ይችላል, የሠንጠረዡን መዋቅር እና ይዘቶች ያሳያል, ለመደርደር, በአምዶች ለማጣራት, ውጤቱን ያስከተለውን መጠይቅ ያሳያል, የተጎዱ ረድፎች (በውጤቱ ስንት), ማለትም, መረጃን ለመመልከት መሰረታዊ ነገሮች. በጣም ፈጣን።

አርታኢም አለ። ሙሉውን አርታኢ ከታቢክስ ለመስረቅ ሞከርኩ ነገር ግን አልቻልኩም። ግን በሆነ መንገድ ይሰራል. በመርህ ደረጃ፣ ያ ብቻ ነው።

"ክሊክ ሃውስ" ለዳስ ተስማሚ ነው

ክሊክ ሃውስ ምንም እንኳን የተገለጹት ሁሉም ችግሮች ቢኖሩም, ለሎግ በጣም ተስማሚ መሆኑን ልነግርዎ እፈልጋለሁ. ከሁሉም በላይ, ችግራችንን ይፈታል - በጣም ፈጣን ነው እና ምዝግብ ማስታወሻዎችን በአምዶች ለማጣራት ያስችልዎታል. በመርህ ደረጃ, የጠረጴዛዎች ጠረጴዛዎች ጥሩ ውጤት አላመጡም, ነገር ግን ብዙውን ጊዜ ማንም ለምን እንደሆነ አያውቅም ... ምናልባት አሁን የት እንደሚቸገሩ በደንብ ያውቃሉ.

TCP? በአጠቃላይ, በ VK ውስጥ UDP ን መጠቀም የተለመደ ነው. እና ቲሲፒን ስጠቀም...በእርግጥ ማንም አልነገረኝም:- “ዩሪ፣ ስለ ምን እያወራህ ነው! አትችልም፣ ዩዲፒ ያስፈልግሃል። TCP ያን ያህል አስፈሪ እንዳልሆነ ታወቀ። ብቸኛው ነገር እርስዎ የሚጽፉት በአስር ሺዎች የሚቆጠሩ ንቁ ውህዶች ካሉዎት, ትንሽ በጥንቃቄ ማዘጋጀት ያስፈልግዎታል; ግን ይቻላል ፣ እና በጣም ቀላል።

ሁሉም ሰው ለሕዝባችን "VK backend" ከተመዘገቡ "Kittenhouse" እና "Lighthouse" በሃይሎድ ሳይቤሪያ ላይ ለመለጠፍ ቃል ገባሁ...እናም ታውቃለህ ሁሉም ሰው አልመዘገበም...በእርግጥ፣ለእኛ እንዲመዘገቡ አልጠይቅም። የህዝብ። አሁንም በጣም ብዙዎቻችሁ አሉ፣ አንድ ሰው እንኳን ቅር ያሰኛችሁ ይሆናል፣ ግን አሁንም እባክዎን ለደንበኝነት ይመዝገቡ (እና እዚህ እንደ ድመት ዓይኖች ማድረግ አለብኝ)። ያ ነው። በነገራችን ላይ አያይዘው. በጣም አመሰግናለሁ! Github የኛ ነው። እዚሁ. በ Clickhouse ፀጉርዎ ለስላሳ እና ለስላሳ ይሆናል.

እየመራ፡ - ጓደኞች, አሁን ለጥያቄዎች. የምስጋና ሰርተፍኬት እና በVHS ላይ ያቀረቡትን ሪፖርት ካቀረብን በኋላ ወዲያው።

ዩሪ ናስሬትዲኖቭ (ከዚህ በኋላ YN ይባላል) - አሁን ካለቀ በVHS ላይ የእኔን ዘገባ እንዴት መቅዳት ቻልክ?

እየመራ፡ - እንዲሁም "ክሊክ ሃውስ" እንዴት እንደሚሰራ ወይም እንደማይሰራ ሙሉ በሙሉ መወሰን አይችሉም! ጓደኞች ፣ ለጥያቄዎች 5 ደቂቃዎች!

ጥያቄዎች

ከአድማጮች የቀረበ ጥያቄ (ከዚህ በኋላ ጥ ይባላል)፡- - እንደምን አረፈድክ. ለሪፖርቱ በጣም አመሰግናለሁ። ሁለት ጥያቄዎች አሉኝ። በማይረባ ነገር እጀምራለሁ፡ በሥዕላዊ መግለጫው ውስጥ “Kittenhouse” በሚለው ስም የተጻፉት ፊደሎች ቁጥር (3፣ 4፣ 7...) የድመቶችን እርካታ ይነካል?

YN፡ - ምን መጠን?

З: - ደብዳቤ ቲ. ሶስት ቲዎች አሉ ፣ የሆነ ቦታ ወደ ሶስት t's አካባቢ።

YN፡ - አላስተካከልኩትም? ደህና ፣ በእርግጥ ያደርገዋል! እነዚህ የተለያዩ ምርቶች ናቸው - በዚህ ጊዜ ሁሉ እያታለልኩህ ነበር። እሺ እየቀለድኩ ነው - ምንም አይደለም. አህ ፣ እዚሁ! አይ፣ ተመሳሳይ ነገር ነው፣ እኔ የትየባ ሠራሁ።

З: - አመሰግናለሁ. ሁለተኛው ጥያቄ ከባድ ነው። እኔ እስከገባኝ ድረስ፣ በ Clickhouse ውስጥ፣ የማቋረጫ ሠንጠረዦች በማህደረ ትውስታ ብቻ ይኖራሉ፣ በዲስክ ላይ አልተቀመጡም እና፣ በዚህ መሰረት፣ ቋሚ አይደሉም።

YN፡ - አዎ.

З: - እና በተመሳሳይ ጊዜ ደንበኛዎ ወደ ዲስክ ቋት ይይዛል፣ ይህም ለእነዚህ ተመሳሳይ ምዝግብ ማስታወሻዎች የማድረስ የተወሰነ ዋስትናን ያሳያል። ግን ይህ በ Clickhouse በምንም መልኩ ዋስትና አይሰጥም። ዋስትናው እንዴት እንደሚካሄድ ያብራሩ, በምን ምክንያት? ... ይህ ዘዴ በበለጠ ዝርዝር ውስጥ አለ

YN፡ - አዎ ፣ በንድፈ ሀሳብ እዚህ ምንም ተቃርኖዎች የሉም ፣ ምክንያቱም Clickhouse ሲወድቅ ፣ በእውነቱ በሚሊዮን የሚቆጠሩ መንገዶችን ማግኘት ይችላሉ። Clickhouse ከተበላሸ (በስህተት የሚያልቅ ከሆነ)፣ በግምት ለመናገር፣ ከጻፉት ምዝግብ ማስታወሻ ትንሽ ወደ ኋላ መመለስ እና ሁሉም ነገር በትክክል ከተስተካከለበት ጊዜ ጀምሮ መጀመር ይችላሉ። አንድ ደቂቃ ወደ ኋላ መለስ ብለህ እንበል፣ ማለትም፣ ሁሉንም ነገር በደቂቃ ውስጥ እንዳጸዳህ ይቆጠራል።

З: - ማለትም "Kittenhouse" መስኮቱን ረዘም ላለ ጊዜ ይይዛል እና ውድቀት ቢከሰት, ሊያውቀው እና ሊመልሰው ይችላል?

YN፡ - ግን ይህ በንድፈ ሀሳብ ውስጥ ነው. በተግባር, ይህንን አናደርግም, እና አስተማማኝ ማድረስ ከዜሮ ወደ ማለቂያ ጊዜዎች ነው. ግን በአማካይ አንድ. ክሊክ ሃውስ በሆነ ምክንያት ቢበላሽ ወይም አገልጋዮቹ “እንደገና ቢጀምሩ” ትንሽ እንደጠፋን ረክተናል። በሌሎች በሁሉም ሁኔታዎች ምንም ነገር አይከሰትም.

З: - ሀሎ. ገና ከመጀመሪያው ጀምሮ ከሪፖርቱ መጀመሪያ ጀምሮ ዩዲፒን የምትጠቀመው መሰለኝ። http አለህ፣ ያ ሁሉ... እና እኔ እንደተረዳሁት የገለጽካቸው አብዛኞቹ ችግሮች የተፈጠሩት በዚህ ልዩ መፍትሄ ነው...

YN፡ - TCP ምን እንጠቀማለን?

З: - በመሠረቱ አዎ.

YN፡ - አይደለም ፡፡

З: - ችግር ያጋጠመዎት በ fasthttp ነበር ፣ ግንኙነቱ ላይ ችግሮች ያጋጠሙዎት። አሁን UDP ን ተጠቅመህ ቢሆን ኖሮ እራስህን ትንሽ ጊዜ ታድን ነበር። ደህና፣ ረጅም መልእክት ወይም ሌላ ነገር ላይ ችግሮች ሊኖሩ ይችላሉ...

YN፡ - ከምን ጋር?

З: - ከረጅም መልእክቶች ጋር, ወደ MTU ውስጥ የማይገባ ሊሆን ስለሚችል, ሌላ ነገር ... ደህና, የራሳቸው ችግሮች ሊኖሩ ይችላሉ. ጥያቄው፡ ለምን UDP አይሆንም?

YN፡ - TCP/IPን ያዳበሩት ደራሲዎች ከእኔ የበለጠ ብልህ እንደሆኑ እና እሽጎችን እንዴት በቅደም ተከተል ማስቀመጥ (እንዲሄዱ) ከእኔ በተሻለ እንደሚያውቁ አምናለሁ ፣ በተመሳሳይ ጊዜ የመላኪያ መስኮቱን ያስተካክሉ ፣ አውታረ መረቡን ከመጠን በላይ አይጫኑ ፣ ምን ላይ አስተያየት ይስጡ አልተነበበም ፣ በሌላኛው በኩል አይቆጠርም… እነዚህ ሁሉ ችግሮች ፣ በእኔ አስተያየት ፣ በ UDP ውስጥ ሊኖሩ ይችላሉ ፣ እኔ ብቻ እኔ ራሴ እና ምናልባትም ተመሳሳይ ነገርን ለመተግበር ከጻፍኩት በላይ ኮድ መፃፍ አለብኝ ። ደካማ. በሲ መፃፍ እንኳን አልወድም፣ እዚያ ይቅርና...

З: - ልክ ምቹ! እሺ ተልኳል እና ምንም ነገር አትጠብቅ - ሙሉ በሙሉ አልተመሳሰልም። ሁሉም ነገር ጥሩ እንደነበረ ማሳወቂያ ተመልሶ መጣ - ያ ማለት ደርሷል; ካልመጣ, መጥፎ ነው ማለት ነው.

YN፡ - ሁለቱንም እፈልጋለሁ - ሁለቱንም የማስረከቢያ ዋስትና እና ያለ ማቅረቢያ ዋስትና መላክ መቻል አለብኝ። እነዚህ ሁለት የተለያዩ ሁኔታዎች ናቸው። አንዳንድ ምዝግቦችን ላለማጣት ወይም በምክንያት ውስጥ ላለማጣት እፈልጋለሁ.

З: - ጊዜ አላጠፋም. ይህ የበለጠ መወያየት አለበት. አመሰግናለሁ.

እየመራ፡ - ጥያቄ ያለው ማን ነው - እጆች ወደ ሰማይ!

З: - ሰላም, እኔ ሳሻ ነኝ. በሪፖርቱ መካከል የሆነ ቦታ, ከ TCP በተጨማሪ, ዝግጁ የሆነ መፍትሄን - አንዳንድ ዓይነት ካፍካን መጠቀም እንደሚቻል ስሜት ታየ.

YN፡ - ደህና ... እኔ መካከለኛ አገልጋዮችን መጠቀም እንደማልፈልግ ነግሬዎታለሁ, ምክንያቱም ... በካፍካ ውስጥ, አሥር ሺህ አስተናጋጆች እንዳሉን; በእውነቱ እኛ ብዙ አለን - በአስር ሺዎች የሚቆጠሩ አስተናጋጆች። እንዲሁም ያለ ምንም ተኪዎች በካፍካ ማድረግ ህመም ሊሆን ይችላል. በተጨማሪም ፣ ከሁሉም በላይ ፣ አሁንም “ዘግይቶ” ይሰጣል ፣ ሊኖርዎት የሚገባቸውን ተጨማሪ አስተናጋጆች ይሰጣል። ግን እንዲኖራቸው አልፈልግም - እፈልጋለሁ ...

З: ግን በመጨረሻ እንደዚያ ሆነ ።

YN፡ - አይ ፣ አስተናጋጆች የሉም! ይሄ ሁሉም በ Clickhouse አስተናጋጆች ላይ ይሰራል.

З: - ደህና, እና "Kittenhouse", ተቃራኒው - የት ነው የሚኖረው?

YN፡ - በ Clickhouse አስተናጋጅ ላይ, በዲስክ ላይ ምንም ነገር አይጽፍም.

З: - እናስብ።

እየመራ፡ - ረክተሃል? ደሞዝ ልንሰጥህ እንችላለን?

З: - አዎ፣ ትችላለህ። እንደ እውነቱ ከሆነ, ተመሳሳይ ነገር ለማግኘት ብዙ ክራንች አሉ, እና አሁን - በ TCP ርዕስ ላይ ያለው የቀድሞ መልስ በእኔ አስተያየት, ይህንን ሁኔታ ይቃረናል. በጣም ባነሰ ጊዜ ውስጥ ሁሉም ነገር በጉልበቴ ሊደረግ የሚችል ይመስላል።

YN፡ - እና ለምን ካፍካን መጠቀም አልፈለግኩም ፣ ምክንያቱም በ Clickhouse ቴሌግራም ቻት ውስጥ ብዙ ቅሬታዎች ስለነበሩ ለምሳሌ ከካፍ የመጡ መልዕክቶች ጠፍተዋል። ከካፍ እራሱ ሳይሆን በካፍካ እና ክሊክሃውስ ውህደት; ወይም የሆነ ነገር እዚያ አልተገናኘም። በግምት፣ ከዚያ ለካፍ ደንበኛ መጻፍ አስፈላጊ ነው። ቀላል ወይም የበለጠ አስተማማኝ መፍትሄ ሊኖር የሚችል አይመስለኝም።

З: - ንገረኝ ፣ ለምን ምንም ወረፋ ወይም የተለመደ አውቶቡስ አልሞከርክም? ከተመሳሰለው ጋር ሎጎቹን ራሳቸው በሰልፍ መላክ እና ምላሹን በተመሣሣይ መልኩ በወረፋው ሊቀበሉ ይችላሉ ስላሉ?

YN፡ - እባክዎ ምን ወረፋዎችን መጠቀም እንደሚቻል ይጠቁሙ?

З: - ማንኛውም ፣ ምንም እንኳን እነሱ በቅደም ተከተል መኖራቸውን ያለ ዋስትና። አንዳንድ ዓይነት Redis፣ RMQ...

YN፡ - ሬዲስ ክሊክ ሃውስን በሚጎትት በአንድ አስተናጋጅ ላይ (በበርካታ አገልጋዮች ስሜት) እንኳን እንደዚህ አይነት የማስገባት መጠን መሳብ እንደማይችል ይሰማኛል ። ይህንን በማናቸውም ማስረጃዎች መደገፍ አልችልም (ቤንችማርክ አላደረግኩትም) ግን ለእኔ የሚመስለኝ ​​ሬዲስ እዚህ የተሻለው መፍትሄ አይደለም። በመርህ ደረጃ, ይህ ስርዓት እንደ የተሻሻለ የመልዕክት ወረፋ ሊቆጠር ይችላል, ነገር ግን ለ "ክሊክ ሃውስ" ብቻ የተዘጋጀ ነው.

እየመራ፡ - ዩሪ ፣ በጣም አመሰግናለሁ። ጥያቄዎቹን እና መልሶቹን እዚህ ላይ እንድቋጭ ሀሳብ አቀርባለሁ እና ጥያቄውን ከጠየቁት ውስጥ መፅሃፉን የምንሰጠው ለማን ነው ።

YN፡ - ለመጀመሪያ ጊዜ ጥያቄ ለጠየቀ ሰው መጽሐፍ መስጠት እፈልጋለሁ።

እየመራ፡ - ድንቅ! በጣም ጥሩ! ድንቅ! በጣም አመግናለሁ!

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

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