HighLoad++ Москва 2018, Конгресс Холл. 9-ноябрь, саат 15:00
Аннотациялар жана презентациялар:
Юрий Насретдинов (ВКонтакте): баяндамада ClickHouse программасын биздин компанияга киргизүү тажрыйбасы жөнүндө сөз болот - ал эмне үчүн керек, биз канча маалымат сактайбыз, аны кантип жазабыз ж.б.у.с.
Кошумча материалдар:
Юрий Насретдинов: - Баарына салам! Менин атым Юрий Насретдинов, мени буга чейин тааныштырышкан. Мен ВКонтактеде иштейм. Мен биздин сервердик паркыбыздан (он миңдеген) ClickHouse-га маалыматтарды кантип киргизээрибиз жөнүндө сүйлөшөм.
Журнал деген эмне жана аларды эмне үчүн чогултуу керек?
Биз сизге эмнени айтабыз: биз эмне кылдык, эмне үчүн бизге "ClickHouse" керек болду, тиешелүүлүгүнө жараша, эмне үчүн биз аны тандап алдык, атайын эч нерсени конфигурациялабастан, болжол менен кандай аткарууну ала аласыз. Мен сизге буфердик таблицалар, алар менен болгон көйгөйлөр жана ачык булактан - KittenHouse жана Lighthouse аркылуу иштеп чыккан чечимдерибиз жөнүндө айтып берем.
Эмне үчүн биз бир нерсе кылышыбыз керек болчу (ВКонтактеде баары жакшы, туурабы?). Биз мүчүлүштүктөрдү оңдоо журналдарын чогулткубуз келди (жана ал жерде жүздөгөн терабайт маалыматтар бар болчу), балким кандайдыр бир жол менен статистиканы эсептөө ыңгайлуураак болот; жана бизде он миңдеген серверлердин паркы бар, алардан мунун бардыгы аткарылышы керек.
Эмне үчүн биз чечтик? Бизде журналдарды сактоо боюнча чечимдер бар болчу. Бул жерде - мындай коомдук "Backend VK" бар. Мен ага жазылууну сунуштайм.
Журналдар деген эмне? Бул бош массивдерди кайтаруучу кыймылдаткыч. ВКдагы кыймылдаткычтарды башкалар микросервис деп аташат. Жана бул жерде жылмайган стикер (бир топ жактыруулар). Кантип? Мейли, дагы ук!
Журналдарды сактоо үчүн эмне колдонсо болот? Хадупту айтпай коюуга болбойт. Андан кийин, мисалы, Rsyslog (бул журналдарды файлдарда сактоо). LSD. LSD деген эмне экенин ким билет? Жок, бул LSD эмес. Тиешелүүлүгүнө жараша файлдарды да сактаңыз. Ооба, ClickHouse кызыктай вариант.
Clickhouse жана атаандаштар: талаптар жана мүмкүнчүлүктөр
Биз эмнени каалайбыз? Биз операция жөнүндө көп кабатыр болбошубузду камсыз кылгыбыз келет, ошондуктан ал кутудан тышкары, эң жакшысы минималдуу конфигурация менен иштейт. Биз көп жазгыбыз келет, тез жазгыбыз келет. Ал эми биз аны ар кандай айлар, жылдар бою, башкача айтканда, көпкө сактагыбыз келет. Биз алар бизге келип, "Бул жерде бир нерсе иштебей жатат" деп айтышкан кандайдыр бир көйгөйдү түшүнгүбүз келет, ал эми 3 ай мурун болгон) жана биз 3 ай мурун эмне болгонун көргүбүз келет " Маалыматтарды кысуу - бул эмне үчүн плюс болору айкын - анткени ал ээлеген мейкиндикти азайтат.
Жана бизде мындай кызыктуу талап бар: биз кээде кээ бир командалардын (мисалы, журналдардын) чыгышын жазабыз, ал оңой эле 4 килобайттан ашат. Ал эми бул нерсе UDP аркылуу иштесе, анда аны коротуунун кажети жок... ага туташуу үчүн эч кандай “кошумча чыгым” болбойт жана көп сандагы серверлер үчүн бул плюс болот.
Келгиле, ачык булак бизге эмне сунуштай турганын карап көрөлү. Биринчиден, бизде Logs Engine бар - бул биздин кыймылдаткыч; Негизи анын колунан баары келет, ал тургай узун саптарды да жаза алат. Ооба, ал маалыматтарды ачык кысып койбойт - эгер кааласак чоң мамычаларды өзүбүз кысып алабыз... биз, албетте, каалабайбыз (мүмкүн болсо). Бир гана маселе - ал эсине туура келген нерсени гана бере алат; Калганын окуу үчүн сиз бул кыймылдаткычтын бинлогун алышыңыз керек жана, демек, бул бир топ убакытты талап кылат.
башка параметрлер бар эмне? Мисалы, "Hadup". Иштин оцойлугу... Хадупту орнотуу оцой деп ким ойлойт? Албетте, жаздырууда эч кандай көйгөйлөр жок. Окуп жатканда кээде суроолор пайда болот. Негизи, мен айтаар элем, балким, өзгөчө журналдар үчүн. Узак мөөнөттүү сактоо - албетте, ооба, маалыматтарды кысуу - ооба, узун саптар - жаздыра аларыңыз анык. Бирок көп сандагы серверлерден жаздыруу... Сиз дагы эле бир нерсе кылышыңыз керек!
Rsyslog. Чынында, биз аны бинлогду таштабастан окуш үчүн резервдик вариант катары колдонгонбуз, бирок ал узун саптарды жаза албайт; негизи, ал 4 килобайттан ашык жаза албайт. Берилиштерди кысуу процессин өзүңүз да жасашыңыз керек. Окуу файлдардан келет.
Андан кийин LSDдин "бадушка" өнүгүүсү бар. Негизинен "Rsyslog" менен бирдей: ал узун саптарды колдойт, бирок ал UDP аркылуу иштей албайт жана чындыгында, ушундан улам, тилекке каршы, ал жерде көп нерселерди кайра жазуу керек. Он миңдеген серверлерден жаздыра алуу үчүн LSDди кайра иштеп чыгуу керек.
Мынакей! Күлкүлүү вариант - ElasticSearch. Кантип айтуу керек? Ал окуу менен жакшы иштеп жатат, башкача айтканда, ал тез окуйт, бирок жазуу менен жакшы эмес. Биринчиден, ал маалыматтарды кысып, анда ал абдан начар. Кыязы, толук издөө баштапкы көлөмүнө караганда чоңураак маалымат структураларын талап кылат. Аны иштетүү кыйын жана аны менен көйгөйлөр көп жаралат. Жана дагы, Elastic менен жаздыруу - бардыгын өзүбүз жасашыбыз керек.
Бул жерде ClickHouse, албетте, идеалдуу вариант. Бир гана нерсе, он миңдеген серверлерден жаздыруу көйгөй жаратат. Бирок жок дегенде бир көйгөй бар, аны кандайдыр бир жол менен чечкенге аракет кылсак болот. Ал эми отчеттун калган бөлүгү ушул көйгөй жөнүндө. ClickHouseдан кандай аткарууну күтсө болот?
Аны кантип киргизебиз? MergeTree
Араңарда ким "ClickHouse" жөнүндө уккан эмес же билбейт? Мен сага айтышым керек, туурабы? Абдан тез. Ал жерде киргизүү - секундасына 1-2 гигабит, секундасына 10 гигабитке чейин жарылуулар чындыгында бул конфигурацияга туруштук бере алат - эки 6 ядролуу Xeon бар (башкача айтканда, эң күчтүү эмес), 256 гигабайт оперативдик эс, 20 терабайт RAIDде (эч ким конфигурацияланган эмес, демейки жөндөөлөр). Алексей Миловидов, ClickHouse иштеп чыгуучусу, биз эч нерсени конфигурациялаган жокпуз деп ыйлап жатса керек (биз үчүн баары ушундай болду). Демек, маалымат жакшы кысылган болсо, секундасына болжол менен 6 миллиард сапты сканерлөө ылдамдыгын алууга болот. Эгер сизге текст сапта % жакса - секундасына 100 миллион сап, башкача айтканда, ал абдан тез көрүнөт.
Аны кантип киргизебиз? Ооба, сиз VK PHP колдоноорун билесиз. Биз ар бир PHP жумушчусун HTTP аркылуу "ClickHouse"га, ар бир жазуу үчүн MergeTree таблицасына киргизебиз. Бул схемада көйгөйдү ким көрүп жатат? Эмнегедир баары эле кол көтөргөн жок. Мен айтып берейин.
Биринчиден, серверлер көп - ошого жараша байланыштар көп болот (жаман). Андан кийин MergeTreeге маалыматтарды секундасына бир жолудан көп эмес киргизүү жакшы. Анан эмне үчүн ким билет? Макул макул. Мен бул жөнүндө бир аз көбүрөөк айтып берейин. Дагы бир кызыктуу суроо, биз аналитика жасап жаткан жокпуз, бизге маалыматтарды байытуунун кереги жок, бизге орто серверлердин кереги жок, биз түздөн-түз "ClickHouse" киргизгибиз келет (жакшы - канчалык түз болсо, ошончолук жакшы).
Демек, MergeTreeде киргизүү кантип ишке ашырылат? Эмне үчүн ага секундасына бир жолудан көп эмес же азыраак киргизген жакшы? Чындыгында, "ClickHouse" - бул мамычалык маалымат базасы жана маалыматтарды негизги ачкычтын өсүү тартибинде сорттойт жана сиз кыстарууну аткарганда, жок дегенде маалыматтар сорттолгон тилкелердин санына барабар бир катар файлдар түзүлөт. негизги ачкычтын өсүү тартибинде (өзүнчө каталог түзүлөт, ар бир киргизүү үчүн дисктеги файлдардын топтому). Андан кийин кийинки киргизүү келип, фондо алар чоңураак "бөлүмдөрдү" бириктиришет. Маалыматтар иреттелгендиктен, көп эстутумду талап кылбастан, эки иреттелген файлды "бириктирүүгө" болот.
Бирок, сиз ойлогондой, ар бир киргизүү үчүн 10 файл жазсаңыз, анда ClickHouse (же сиздин сервериңиз) тез бүтөт, андыктан чоң партиялар менен киргизүү сунушталат. Ошого жараша биринчи схеманы эч качан өндүрүшкө киргизген эмеспиз. Биз дароо эле бирин ишке киргиздик, бул жерде №2:
Бул жерде биз ишке киргизген миңге жакын сервер бар деп элестетиңиз, жөн гана PHP бар. Ар бир серверде биздин жергиликтүү агентибиз бар, аны биз "Китенхаус" деп атадык, ал "ClickHouse" менен бир байланышты кармап турат жана ар бир бир нече секундада маалыматтарды киргизет. Маалыматтарды MergeTreeге эмес, буфердик таблицага киргизет, ал дароо MergeTreeге түздөн-түз киргизбөө үчүн так кызмат кылат.
Буфердик таблицалар менен иштөө
Бул эмне? Буфердик таблицалар - эс тутумдун кесилген бөлүгү (башкача айтканда, аны тез-тез киргизүүгө болот). Алар бир нече бөлүктөрдөн турат жана ар бири өз алдынча буфер катары иштейт жана алар өз алдынча жуулат (эгерде буферде көптөгөн бөлүктөр болсо, анда секундасына көптөгөн вставкалар болот). Бул таблицалардан окууга болот - анда буфердин жана ата-эне таблицанын мазмунун окуйсуз, бирок бул учурда жазуу бөгөттөлгөн, андыктан ал жерден окубай эле койгонуңуз оң. Ал эми буфердик таблицалар абдан жакшы QPS көрсөтөт, башкача айтканда, 3 миң QPSке чейин киргизүүдө сизде эч кандай көйгөй болбойт. Эгерде сервер кубаты жоголсо, анда маалыматтар жоголуп кетиши мүмкүн экени түшүнүктүү, анткени ал эстутумда гана сакталган.
Ошол эле учурда буфери бар схема ALTERди татаалдаштырат, анткени алгач эски схема менен эски буфердик таблицаны түшүрүш керек (маалымат эч жерде жок болбойт, анткени таблица жок кылынганга чейин ал тазаланат). Андан кийин сизге керектүү таблицаны "өзгөртүү" жана буфердик таблицаны кайра түзүңүз. Демек, буфердик таблица жок болсо да, сиздин маалыматтарыңыз эч жакка агып кетпейт, бирок сиз аны дискте жок дегенде жергиликтүү түрдө сактай аласыз.
Kittenhouse деген эмне жана ал кантип иштейт?
KittenHouse деген эмне? Бул прокси. Кайсы тилде экен? Мен өз отчетумда эң көп хип темаларды чогулттум - "Clickhouse", Go, балким, мен дагы бир нерсени эстеп калам. Ооба, бул Go тилинде жазылган, анткени мен C тилинде кантип жазууну билбейм, мен каалабайм.
Демек, ал ар бир сервер менен байланышты кармап турат жана эстутумга жаза алат. Мисалы, биз Clickhouse'га ката журналдарын жазсак, анда Clickhouse'да маалыматтарды киргизүүгө убакыт жок болсо (анткени, өтө көп жазылган болсо), анда биз эстутумду көбөйтпөйбүз - калганын жөн эле ыргытып жиберебиз. Анткени биз секундасына бир нече гигабит каталарды жазсак, анда кээ бирлерин чыгарып салышыбыз мүмкүн. Китенхаус муну жасай алат. Мындан тышкары, ал ишенимдүү жеткирүүнү аткара алат, башкача айтканда, локалдык машинада дискке жазуу жана ар бир жолу (ал жерде, эки секундда бир жолу) бул файлдан маалыматтарды жеткирүүгө аракет кылат. Алгач биз кадимки Values форматын колдондук - кандайдыр бир бинардык формат эмес, текст форматы (кадимки SQLдегидей).
Бирок кийин бул окуя болду. Биз ишенимдүү жеткирүүнү колдондук, журналдарды жаздык, анан чечтик (бул шарттуу тест кластери болчу)... Ал бир нече саатка чыгарылып, кайра көтөрүлүп, миң серверден киргизүү башталды - Clickhouse дагы эле бар экени белгилүү болду. "Туташуудагы жип" - ошого жараша миң туташууда активдүү киргизүү серверде бир жарым миңге жакын жүктөмгө алып келет. Таң калыштуусу, сервер суроо-талаптарды кабыл алды, бирок маалыматтар бир нече убакыттан кийин дагы эле киргизилген; бирок серверге аны тейлөө абдан кыйын болду...
nginx кошуу
Туташуу моделине Thread үчүн мындай чечим nginx болуп саналат. Биз Clickhouse'дун алдына nginx орноттук, ошол эле учурда эки репликага тең салмактуулукту орноттук (биздин киргизүү ылдамдыгыбыз 2 эсеге көбөйдү, бирок андай болушу керек эмес) жана Clickhouse менен туташуулардын санын чектедик. агымдын өйдө жагында жана, ошого жараша , 50дөн ашык туташууда, киргизүүнүн эч кандай мааниси жок окшойт.
Ошондо биз бул схеманын жалпысынан кемчиликтери бар экенин түшүндүк, анткени бул жерде бизде бир гана nginx бар. Демек, бул nginx бузулуп калса, репликалардын бар экендигине карабастан, биз маалыматтарды жоготуп алабыз же, жок эле дегенде, эч жакка жазбайбыз. Ошон үчүн биз өзүбүздүн жүктү балансташтырдык. Биз ошондой эле "Clickhouse" журналдар үчүн дагы эле ылайыктуу экенин түшүндүк, ал эми "жин" да өз журналдарын "Clickhouse" менен жаза баштады - чынын айтсам, абдан ыңгайлуу. Биз дагы башка "жиндер" үчүн колдонобуз.
Андан кийин биз бул кызыктуу көйгөйдү таптык: эгер сиз SQL режиминде киргизүүнүн стандарттуу эмес ыкмасын колдонсоңуз, анда ал толук кандуу AST негизиндеги SQL анализдөөчүсүн мажбурлайт, бул абдан жай. Ошого жараша, бул эч качан болбошу үчүн орнотууларды коштук. Биз жүктөөнү балансташтырдык, ден соолукту текшердик, эгер бирөө өлсө, биз дагы эле маалыматтарды калтырабыз. Азыр бизде ар кандай Clickhouse кластерлери болушу керек болгон абдан көп таблицалар бар. Ошондой эле биз башка колдонуулар жөнүндө ойлоно баштадык - мисалы, биз nginx модулдарынан журналдарды жазгыбыз келди, бирок алар биздин RPC аркылуу кантип байланышуу керектигин билишпейт. Ооба, мен аларга жок дегенде кандайдыр бир жол менен кантип жөнөтүүнү үйрөткүм келет - мисалы, UDP аркылуу localhostто окуяларды кабыл алып, андан кийин аларды Clickhouse'ге жөнөтүүнү.
Чечимден бир кадам алыс
Акыркы схема мындай боло баштады (бул схеманын төртүнчү версиясы): Clickhouse алдындагы ар бир серверде nginx бар (ошол эле серверде) жана ал жөн гана 50 туташуунун санына чектөө менен localhostтун прокси-проксиси менен кайрылат. даана. Жана бул схема буга чейин эле иштеп жаткан, баары аны менен абдан жакшы болчу.
Бир айга жакын ушинтип жашадык. Баары сүйүнүп, таблицаларды кошушту, кошушту, кошушту... Негизинен, буфердик таблицаларды кошконубуз анчалык деле оптималдуу эмес экен (мындай деп коёлу). Биз ар бир столдо 16 даана жана бир-эки секунд жарк аралыгы кылды; бизде 20 таблица бар болчу жана ар бир стол секундасына 8 кошумчаны алды - жана ушул учурда "Clickhouse" башталды... жазуулар жайлай баштады. Алар өтүшкөн да жок ... Nginx демейки боюнча ушунчалык кызыктуу нерсеге ээ болгон, эгер туташуулар жогорку агымда бүтсө, анда ал бардык жаңы суроо-талаптарга жөн гана "502" кайтарып берген.
Бул жерде бизде (мен Clickhouse'дун өзүндөгү журналдарды карадым) сурамдардын жарым пайызына жакыны ишке ашпай калды. Ошого жараша дискти колдонуу жогору болгон, биригүү көп болгон. Мейли, мен эмне кылдым? Албетте, мен эмне үчүн так байланыш жана агым токтоп калганын түшүнүп убара болгон жокмун.
Nginxти тескери прокси менен алмаштыруу
Мен муну өзүбүз чечишибиз керек деп чечтим, аны nginxке калтыруунун кереги жок - nginx Clickhouse-да кандай таблицалар бар экенин билбейт жана мен nginxти тескери прокси менен алмаштырдым, аны мен өзүм да жаздым.
Ал эмне кылып жатат? Ал "goshnoy" fasthttp китепканасынын негизинде иштейт, башкача айтканда, nginx сыяктуу тез. Кечиресиз, Игорь, эгер сиз бул жерде болсоңуз (эскертүү: Игорь Сысоев nginx веб-серверин түзгөн орусиялык программист). Бул кандай суроо-талаптар экенин түшүнө алат - INSERT же SELECT - жараша, ал ар кандай сурамдардын түрлөрү үчүн ар кандай туташуу бассейндерин камтыйт.
Демек, биз киргизүү өтүнүчтөрүн аткарууга убакыт жок болсо да, "тандоо" өтөт, жана тескерисинче. Жана ал маалыматтарды буфердик таблицаларга топтойт - кичинекей буфер менен: эгерде кандайдыр бир каталар, синтаксистик каталар жана башкалар болсо - алар калган маалыматтарга чоң таасирин тийгизбеши үчүн, анткени биз жөн эле буфердик таблицаларга киргизгенде, биз кичинекей "бачи" болгон жана бардык синтаксистик каталар бул кичинекей кесимге гана таасирин тийгизген; жана бул жерде алар чоң буферге таасир этет. Кичинекей 1 мегабайт, башкача айтканда, анчалык деле кичинекей эмес.
Синхрондоштурууну киргизүү жана nginxти алмаштыруу, негизинен, nginx мурда жасаган нерсени жасайт - бул үчүн жергиликтүү "Киттенхаусту" өзгөртүүнүн кереги жок. Жана ал fasthttp колдонгондуктан, ал абдан тез - тескери прокси аркылуу бир эле кыстармалар үчүн секундасына 100 миңден ашык суроо-талаптарды жасай аласыз. Теориялык жактан алганда, сиз котенка тескери проксиге бирден бир сапты киргизе аласыз, бирок, албетте, биз муну кылбайбыз.
Схема мындай боло баштады: "Киттенхаус", тескери прокси көптөгөн суроо-талаптарды таблицаларга топтойт жана өз кезегинде буфердик таблицалар аларды негизгилерине киргизет.
Киллер убактылуу чечим, Котенок туруктуу
Бул кызыктуу маселе... Араңарда fasthttp колдонгондор барбы? POST сурамдары менен fasthttp ким колдонду? Кыязы, бул чындап эле жасалбашы керек болчу, анткени ал сурамдын денесин демейки боюнча буферлейт жана биздин буфердин көлөмү 16 мегабайтка коюлган. Кыстаруу кандайдыр бир учурда токтоп калды жана 16 мегабайттык бөлүктөр бардык он миңдеген серверлерден келе баштады жана алардын баары Clickhouse'га жөнөтүлгөнгө чейин эстутумда буферленген. Демек, эс тутум түгөнүп калды, Эстутумдан чыгуучу өлтүргүч келип, тескери проксиди (же тескери проксиге караганда теориялык жактан көбүрөөк “жеген” “Clickhouse”) өлтүрдү. Цикл кайталанды. Абдан жагымдуу маселе эмес. Биз буга бир нече ай иштегенден кийин гана чалындык да.
Мен эмне кылдым? Дагы бир жолу, мен так эмне болгонун түшүнгүм келбейт. Менин оюмча, сиз эстутумга буфер кылбашыңыз керек экени айдан ачык. Мен аракет кылсам да, fasthttp түзө алган жокмун. Бирок мен муну жасоонун жолун таптым, ошондуктан эч нерсени жамоонун кереги жок жана мен HTTPде өзүмдүн методумду ойлоп таптым - мен аны KOYENE деп атадым. Ооба, логикалык - "VK", "Kitten"... Дагы эмне?..
Эгерде серверге Котенок ыкмасы менен суроо келсе, анда сервер логикалык жактан "мяу" деп жооп бериши керек. Эгер ал буга жооп берсе, анда ал бул протоколду түшүндү деп эсептелет, андан кийин мен туташууну токтотуп жатам (fasthttp'де ушундай ыкма бар) жана туташуу "чийки" режимге өтөт. Бул мага эмне үчүн керек? Мен TCP байланыштарынан окуу кандай болорун көзөмөлдөгүм келет. TCP сонун касиетке ээ: эгерде башка тараптан эч ким окубаса, анда жазуу күтө баштайт жана эс тутум буга өзгөчө сарпталбайт.
Ошентип, мен бир убакта 50гө жакын кардардан окудум (элүүдөн, анткени элүү сөзсүз жетиштүү болушу керек, чен башка ДКдан келсе да)... Бул ыкма менен керектөө кеминде 20 эсе азайды, бирок мен, чынын айтсам. , Мен кайсы убакытты так өлчөй алган жокмун, анткени ал ансыз деле маанисиз (ал катачылык деңгээлине жеткен). Протокол бинардык, башкача айтканда, таблица атын жана маалыматтарды камтыйт; http аталыштары жок, ошондуктан мен веб-розетка колдонгон жокмун (браузерлер менен байланышуунун кереги жок - мен биздин муктаждыктарыбызга ылайыктуу протокол түздүм). Ошондо баары аны менен жакшы болуп калды.
Буфердик стол кайгылуу
Жакында биз буфердик таблицалардын дагы бир кызыктуу өзгөчөлүгүнө туш болдук. Ал эми бул көйгөй башкаларга караганда алда канча оор. Келгиле, бул жагдайды элестетип көрөлү: сиз Clickhouse'ду жигердүү колдонуп жатасыз, сизде ондогон Clickhouse серверлери бар жана сизде окууга өтө көп убакыт талап кылынган кээ бир суроо-талаптарыңыз бар (айталы, 60 секунддан ашык); жана сиз ушул учурда келип, Alter кыласыз... Ошол эле учурда, "Alter" чейин башталган "тандоолор" бул таблицага кирбейт, "Alter" башталбайт - балким, "Clickhouse" ишинин кээ бир өзгөчөлүктөрү бул жер. Балким, муну оңдоого болот? Же мүмкүн эмеспи?
Жалпысынан алганда, бул чындыгында анчалык деле чоң көйгөй эмес экендиги анык, бирок буфердик столдор менен бул оорураак болуп калат. Анткени, айталы, эгер сиздин “Өзгөртүү” тайм-ауттары болсо (жана ал башка хостто – сиздикинде эмес, мисалы, репликада тайм бүтүшү мүмкүн), анда... Сиз буфердик таблицаны өчүрдүңүз, сиздин “Өзгөртүү” ( же башка хост) күтүү мөөнөтү бүттү. анда "Өзгөртүү" катасы пайда болду) - сиз дагы эле маалыматтардын жазылышын камсыз кылышыңыз керек: буфердик таблицаларды кайра түзөсүз (ата-энелик таблицадагыдай схемага ылайык), андан кийин "Өзгөртүү" өтүп, акыры бүтөт жана буфер таблицада схема боюнча ата-энеден айырмалана баштайт. "Алтер" эмне болгонуна жараша, кыстарма мындан ары бул буфердик столго барбай калышы мүмкүн - бул абдан өкүнүчтүү.
Мындай белги дагы бар (балким аны кимдир бирөө байкагандыр) - Clickhouse жаңы версияларында query_thread_log деп аталат. Демейки боюнча, кээ бир версияларда бирөө бар болчу. Бул жерде биз бир нече айдын ичинде 840 миллион жазууларды (100 гигабайт) топтодук. Мунун себеби, ал жерде «кыстармалар» жазылган (балким, азыр, демек, алар жазылбай калгандыр). Мен сизге айткандай, биздин "кыстармалар" кичинекей - буфердик таблицаларга бизде көп "киргизүүлөр" бар болчу. Бул өчүрүлгөнү анык - мен сизге серверибизден көргөнүмдү айтып жатам. Неге? Бул буфердик таблицаларды колдонууга каршы дагы бир аргумент! Spotty абдан кайгылуу.
Бул жигиттин аты Spotty экенин ким билген? ВК кызматкерлери колдорун көтөрүштү. Макул анда.
"KitttenHouse" пландары жөнүндө
Пландар адатта бөлүшүлбөйт, туурабы? Күтүлбөгөн жерден сиз аларды аткарбай каласыз жана башкалардын көзүнө жакшы көрүнбөй каласыз. Бирок мен тобокелге барам! Биз төмөнкүлөрдү кылгыбыз келет: буфердик таблицалар, менин оюмча, дагы эле балдак болуп саналат жана биз киргизүүнү өзүбүз буферлешибиз керек. Бирок биз дагы эле аны дискке буфердегибиз келбейт, андыктан кыстарууну эстутумга буферлейбиз.
Демек, "киргизүү" жасалганда, ал синхрондуу болбой калат - ал буфердик таблица катары иштеп, ата-энелик таблицага (жакшы, кийинчерээк) киргизет жана өзүнчө канал аркылуу отчет берет, алар өткөн жана кайсы жок.
Эмне үчүн мен синхрондуу кыстарманы калтыра албайм? Бул алда канча ыңгайлуу. Чынында, эгер сиз 10 миң хосттон киргизсеңиз, анда баары жакшы - ар бир хосттон бир аз аласыз, ал жерге секундасына бир жолу киргизесиз, баары жакшы. Бирок мен бул схеманын, мисалы, эки машинадан иштешин каалайт элем, ошондуктан сиз жогорку ылдамдыкта жүктөй аласыз - балким Clickhouse'дан максимум ала албайсыз, бирок тескери прокси аркылуу бир машинадан секундасына кеминде 100 мегабайт жазыңыз - бул схема чоң жана кичине өлчөмдөргө масштабдалышы керек, андыктан ар бир киргизүү үчүн бир секунд күтө албайбыз, андыктан ал асинхрондуу болушу керек. Жана ошондой эле, асинхрондук ырастоо киргизүү аяктагандан кийин келиши керек. Өттү-өтпөдү, билебиз.
Эң негизгиси бул схемада биз киргизүү болгонбу же жокпу анык билебиз. Бул жагдайды элестетиңиз: сизде буфердик таблица бар, ага бир нерсе жаздыңыз, анан айталы, таблица окуу үчүн гана режимге өтүп, буферди тазалоого аракет кылды. Маалыматтар кайда кетет? Алар буферде калат. Бирок биз буга толук ишене албайбыз - эгер башка ката болсо, анда эмне кылуу керек, анын айынан маалыматтар буферде калбай калат... (Даректер Алексей Миловидов, Яндекс, ClickHouse иштеп чыгуучусу) Же ал кала береби? Ар дайымбы? Алексей бизди баары жакшы болот деп ынандырат. Бизде ага ишенбөөгө негиз жок. Бирок баары бир: эгерде биз буфердик таблицаларды колдонбосок, анда алар менен эч кандай көйгөй болбойт. Эки эсе көп таблицаларды түзүү да ыңгайсыз, бирок принципиалдуу түрдө чоң көйгөйлөр жок. Бул план.
Келгиле, окуу жөнүндө сүйлөшөлү
Эми окуу жөнүндө сүйлөшөлү. Бул жерде өзүбүздүн куралыбызды да жаздык. Көрсө, анда эмне үчүн бул жерге өз аспапыңды жазыпсың?.. Анан Табиксти ким колдонгон? Эмнегедир колун көтөргөндөр аз... Анан Табикстин аткаруусу кимди канааттандырат? Ооба, биз ага ыраазы эмеспиз жана бул маалыматтарды көрүү үчүн абдан ыңгайлуу эмес. Бул аналитика үчүн жакшы, бирок жөн гана көрүү үчүн оптималдаштырылган эмес. Ошентип, мен өзүмдүн интерфейсимди жаздым.
Бул абдан жөнөкөй - ал маалыматтарды гана окуй алат. Графика көрсөткөндү билбейт, эч нерсе кылганды билбейт. Бирок ал бизге эмне керек экенин көрсөтө алат: мисалы, таблицада канча сап бар, ал канча орунду ээлейт (мамычаларга бөлбөстөн), башкача айтканда, эң жөнөкөй интерфейс бизге керек.
Жана ал Sequel Proга абдан окшош, бирок Twitterдин Bootstrap жана экинчи версиясында гана жасалган. Сиз сурайсыз: "Юри, эмне үчүн экинчи версияда?" Кайсы жылы? 2018? Жалпысынан, мен муну "Muscle" (MySQL) үчүн бир топ убакыт мурун жасагам жана ал жердеги сурамдардын бир нече саптарын өзгөрткөм жана ал "Clickhouse" үчүн иштей баштады, бул үчүн өзгөчө рахмат! Анткени талдоочу "булчуңдарга" абдан окшош, ал эми сурамдар абдан окшош - абдан ыңгайлуу, айрыкча, башында.
Ооба, ал таблицаларды чыпкалай алат, таблицанын түзүмүн жана мазмунун көрсөтө алат, сорттоого, мамычалар боюнча чыпкалоого мүмкүндүк берет, натыйжага алып келген суроону, жабыркаган саптарды (натыйжада канча) көрсөтөт, б.а. маалыматтарды көрүү үчүн негизги нерселер. Абдан тез.
Редактору да бар. Чынын айтсам, Табикстен редактордун баарын уурдоого аракет кылдым, бирок кыла албадым. Бирок кандайдыр бир жол менен иштейт. Негизи, ушуну менен бүттү.
"Clickhouse" уйу үчүн ылайыктуу
Мен Clickhouse, сүрөттөлгөн бардык көйгөйлөргө карабастан, журналдар үчүн абдан ылайыктуу экенин айткым келет. Эң негизгиси, бул биздин көйгөйдү чечет - бул абдан тез жана журналдарды мамычалар боюнча чыпкалоого мүмкүндүк берет. Негизи буфердик таблицалар жакшы иштеген жок, бирок, адатта, эмне үчүн эч ким билбейт... Балким, азыр сиз кайсы жерде көйгөй жараларын жакшыраак билесиз.
TCP? Жалпысынан алганда, VK UDP колдонуу салт болуп саналат. Анан мен TCP колдонгондо... Албетте, эч ким мага айткан эмес: «Юрий, сен эмне деп жатасың! Сиз кыла албайсыз, сизге UDP керек." Көрсө, TCP анча деле коркунучтуу эмес экен. Бир гана нерсе, сиз жазган он миңдеген активдүү кошулмаларыңыз болсо, аны бир аз кылдаттык менен даярдашыңыз керек; бирок бул мүмкүн жана абдан оңой.
Эгерде бардыгы биздин коомдук “ВК бэкэндге” жазылса, “Китенка” менен “Маякты” HighLoad Siberiaга жайгаштырам деп убада бергем... А сиз билесизби, баары эле жазылган эмес... Албетте, мен сизден биздин каналга жазылууну талап кылбайм. коомдук. Араңарда дагы деле көп, кимдир бирөө таарынып калышы мүмкүн, бирок баары бир жазылыңыз (жана бул жерде мен мышыктын көздөрүн жасашым керек). Ошол . Чоң рахмат! Github биздики . Clickhouse менен чачыңыз жумшак жана жибектей болот.
Модератор: - Достор, азыр суроо үчүн. Биз ыраазычылык сертификатын жана VHS боюнча отчетуңузду тапшыргандан кийин.
Юрий Насретдинов (мындан ары – Ы.Н.): – VHS боюнча отчетум жаңы эле бүтсө, кантип жаздырдың?
Модератор: - Сиз ошондой эле "Clickhouse" кантип иштей турганын же иштебей турганын толук аныктай албайсыз! Достор, суроолорго 5 мүнөт!
суроолор
Аудиториянын суроосу (мындан ары - С): - Кутмандуу күнүң менен. Баяндама үчүн чоң рахмат. Менин эки суроом бар. Мен жеңил-желпи бир нерсе менен баштайын: диаграммалардагы (3, 4, 7...) "Котенка" аталышындагы t тамгаларынын саны мышыктардын канааттануусуна таасир этеби?
YN: - Эмненин саны?
З: – Т тамгасы. Үч т бар, бир жерде үч т.
YN: - Мен оңдоп койгон жокмунбу? Ооба, албетте, болот! Бул ар кандай продуктулар - мен сизди ушул убакка чейин алдап жүрдүм. Макул, тамашалап жатам - бул маанилүү эмес. Ах, ушул жерде! Жок, ошол эле нерсе, мен ката кетирдим.
З: - Рахмат. Экинчи суроо олуттуу. Менин түшүнүшүм боюнча, Clickhouse-да буфердик таблицалар эстутумда гана жашайт, дискке буферленбейт жана ошого жараша туруктуу эмес.
YN: - Ооба.
З: – Жана ошол эле учурда, сиздин кардарыңыз дискке буферленет, бул ошол эле журналдарды жеткирүүнүн кандайдыр бир кепилдиктерин билдирет. Бирок бул Clickhouse-да эч кандай кепилдик жок. Кепилдик кандайча, эмнеден улам ишке ашып жатканын түшүндүрүп бериңизчи?.. Мына ушул механизм кененирээк
YN: – Ооба, теориялык жактан бул жерде эч кандай карама-каршылыктар жок, анткени Clickhouse кулаганда, аны миллиондогон ар кандай жолдор менен аныктай аласыз. Эгерде Clickhouse бузулуп калса (эгерде ал туура эмес аяктаса), сиз, болжол менен айтканда, сиз жазган журналыңыздын бир азын артка жылдырып, баары жакшы болгон учурдан баштап баштасаңыз болот. Бир мүнөт артка түрдүңүз дейли, башкача айтканда, бир мүнөттүн ичинде баарын кызартып салдыңыз деп эсептелет.
З: – Тактап айтканда, “Котенка” терезени узунураак кармап, кулап калса аны таанып, артка түрө алабы?
YN: - Бирок бул теорияда. Иш жүзүндө биз муну кылбайбыз жана ишенимдүү жеткирүү нөлдөн чексиздикке чейин. Бирок орточо бир. Эгерде Clickhouse кандайдыр бир себептерден улам бузулуп калса же серверлер "кайра жүктөлсө", анда биз бир аз жоготобуз деп ыраазыбыз. Башка бардык учурларда эч нерсе болбойт.
З: - Салам. Мага эң башынан эле сиз отчеттун башынан эле UDPди колдоно тургандай сезилдим. Сизде http бар, ошонун баары... Жана сиз сүрөттөгөн көйгөйлөрдүн көбү, мен түшүнгөндөй, ушул конкреттүү чечимден келип чыккан...
YN: – TCP эмнени колдонобуз?
З: - Негизи ооба.
YN: - Жок!
З: – Fasthttp менен сизде көйгөйлөр болгон, туташууда көйгөйлөр болгон. Эгер сиз UDPди жаңы эле колдонсоңуз, өзүңүздүн бир аз убакытты үнөмдөп калмаксыз. Ооба, узун билдирүүлөр же башка бир нерсе менен көйгөйлөр болмок ...
YN: - Эмне менен?
З: – Узун билдирүүлөр менен, анткени ал МТУга туура келбей калышы мүмкүн, башка нерсе... Ооба, өздөрүнүн көйгөйлөрү болушу мүмкүн. Суроо: эмне үчүн UDP эмес?
YN: – Мен TCP/IPди иштеп чыккан авторлор менден алда канча акылдуу жана пакеттерди кантип сериялаштырууну (алар барышы үчүн) менден жакшыраак билишет деп ишенем, ошол эле учурда жөнөтүү терезесин тууралап, тармакты ашыкча жүктөбөй, эмне жөнүндө пикирлерин айтышат. окулбайт, экинчи тарапты эсептебейт... Бул көйгөйлөрдүн баары, менин оюмча, UDPде болмок, бир гана мен бир эле нерсени өзүм ишке ашыруу үчүн мен жазгандан да көбүрөөк кодду жазышым керек болчу. начар. Мен C тилинде жазганды жактырбайм, ал жакта турсун...
З: - Жөн гана ыңгайлуу! Жакшы жөнөтүлдү жана эч нерсени күтпөңүз - бул толугу менен асинхрондуу. Баардыгы жакшы деген билдирүү кайра келди - бул келди дегенди билдирет; Ал келбесе, бул жаман дегенди билдирет.
YN: – Мага экөө тең керек – жеткирүү кепилдиги менен да, жеткирүү кепилдиги жок да жөнөтө алышым керек. Бул эки башка сценарий. Мен кээ бир журналдарды жоготпошум керек же аларды себеп менен жоготпошум керек.
З: – Убакытты текке кетирбейм. Бул дагы талкууланышы керек. Рахмат.
Модератор: – Кимде суроолор бар – колдору асманга!
З: - Саламатсызбы, мен Сашамын. Отчеттун ортосунда кандайдыр бир сезим пайда болду, TCPден тышкары, даяр чечимди - кандайдыр бир Кафканы колдонууга болот.
YN: – Мейли... Мен сизге айттым эле, мен орто серверлерди колдонгум келбейт, анткени... Кафкада бизде он миң хост бар экен; чындыгында, бизде көбүрөөк - он миңдеген хосттор бар. Кафка менен эч кандай проксисиз иш кылуу да оор болушу мүмкүн. Мындан тышкары, эң негизгиси, ал дагы эле "кечтирүүнү" берет, ал сизге керек болгон кошумча хостторду берет. Бирок мен аларга ээ болгум келбейт - мен каалайм ...
З: "Бирок акыры баары бир ушундай болуп чыкты."
YN: – Жок, коноктор жок! Мунун баары Clickhouse хостторунда иштейт.
З: - Ал эми "Китенхаус", тескерисинче, ал кайда жашайт?
YN: – Clickhouse хостунда ал дискке эч нерсе жазбайт.
З: - Айталы.
Модератор: – Канаттандыңбы? Айлык бере алабызбы?
З: - Ооба сиз кыла аласыз. Чынында эле, бир эле нерсени алуу үчүн балдак көп, азыр - TCP темасы боюнча мурунку жооп, менимче, бул жагдайга карама-каршы келет. Бул жөн гана баарын бир аз убакыттын ичинде тиземде жасаса болот окшойт.
YN: – Ошондой эле эмне үчүн мен Кафканы колдонгум келбеди, анткени Clickhouse Telegram чатында, мисалы, Кафкадан келген билдирүүлөр жоголуп кеткен деген даттануулар көп болчу. Кафканын өзүнөн эмес, Кафка менен Кликхауздун интеграциясында; же ал жерде бир нерсе кошулган жок. Орой айтканда, ошондо Кафкага кардар жазыш керек болчу. Менимче, жөнөкөй же ишенимдүү чечим болушу мүмкүн эмес.
З: – Айтчы, эмне үчүн кезек күткөн жоксуң же кадимки автобустун түрүн көргөн жоксуң? Асинхрондук менен журналдарды кезек аркылуу жөнөтүп, жоопту кезек аркылуу асинхрондук түрдө ала аласызбы?
YN: – Кандай кезектер колдонулса болорун сунуштасаңыз?
З: – Кандай болбосун, ал тургай, алар тартипке кепилдик жок. Кандайдыр бир Redis, RMQ...
YN: – Мен Редис, кыязы, Clickhouse чыгарып турган бир хостто (бир нече серверлердин маанисинде) мынчалык көлөмдү тарта албайт деп ойлойм. Мен муну эч кандай далил менен тастыктай албайм (мен аны салыштыра элекмин), бирок мага Редис бул жерде эң жакшы чечим эмес окшойт. Негизи, бул системаны импровизацияланган билдирүү кезеги катары кароого болот, бирок ал "Clickhouse" үчүн гана ылайыкташтырылган.
Модератор: – Юрий, чоң рахмат. Суроо-жоопторду ушул жерден бүтүрүп, суроо бергендердин кимисине китепти берерибизди айтууну сунуштайм.
YN: – Биринчи суроо берген адамга китеп белек кылгым келет.
Модератор: - Керемет! Абдан жакшы! Fabulous! Чон рахмат!
Кээ бир жарнамалар 🙂
Биз менен болгонуңуз үчүн рахмат. Биздин макалалар сизге жагабы? Көбүрөөк кызыктуу мазмунду көргүңүз келеби? Буйрутма берүү же досторуңузга сунуштоо менен бизди колдоңуз, , биз сиз үчүн ойлоп тапкан баштапкы деңгээлдеги серверлердин уникалдуу аналогу: (RAID1 жана RAID10 менен жеткиликтүү, 24 өзөккө чейин жана 40 ГБ DDR4 чейин).
Dell R730xd Амстердамдагы Equinix Tier IV маалымат борборунда 2 эсе арзанбы? Бул жерде гана Нидерландыда! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллардан! Жөнүндө окуу
Source: www.habr.com