HighLoad++ Мәскеу 2018, Конгресс-холл. 9 қараша, 15:00
Аннотация және презентация:
Юрий Насретдинов (ВКонтакте): баяндамада ClickHouse-ты біздің компанияда енгізу тәжірибесі туралы айтылады - бұл бізге не үшін қажет, біз қанша деректерді сақтаймыз, оны қалай жазамыз және т.б.
Дополнительные материалдар:
Юрий Насретдинов: - Бәріңе сәлем! Менің атым Юрий Насретдинов, өйткені мені бұрыннан таныстырған. Мен ВКонтактеде жұмыс істеймін. Мен біздің серверлер паркінен (он мыңдаған) ClickHouse-ға деректерді қалай енгізетініміз туралы айтатын боламын.
Бөренелер дегеніміз не және оларды не үшін жинау керек?
Біз сізге нені айтамыз: не істедік, не үшін бізге «ClickHouse» қажет болды, сәйкесінше біз оны не үшін таңдадық, арнайы ештеңе конфигурацияламай-ақ шамамен қандай өнімділікке қол жеткізе аласыз. Мен сізге буферлік кестелер туралы, олармен болған мәселелер туралы және ашық көзден - KittenHouse және Lighthouse -дан әзірлеген шешімдеріміз туралы айтып беремін.
Неліктен бізге ештеңе істеу керек болды (ВКонтактеде бәрі әрқашан жақсы, солай ма?). Біз жөндеу журналдарын жинағымыз келді (және онда жүздеген терабайт деректер болды), мүмкін статистиканы есептеу ыңғайлырақ болар еді; және бізде он мыңдаған серверлер паркі бар, олардың барлығын жасау керек.
Неліктен біз шешім қабылдадық? Бізде журналдарды сақтауға арналған шешімдер болған шығар. Міне, осындай қоғамдық «Backend VK» бар. Мен оған жазылуды ұсынамын.
Журналдар дегеніміз не? Бұл бос массивтерді қайтаратын қозғалтқыш. ВК-дағы қозғалтқыштарды басқалар микросервис деп атайды. Міне, күлімсіреген стикер (көп ұнайды). Қалайша? Ал, әрі қарай тыңдаңыз!
Журналдарды сақтау үшін нені пайдалануға болады? Хадупты айтпай кету мүмкін емес. Содан кейін, мысалы, Rsyslog (осы журналдарды файлдарда сақтау). LSD. LSD не екенін кім біледі? Жоқ, бұл LSD емес. Файлдарды да сәйкесінше сақтаңыз. ClickHouse - бұл біртүрлі опция.
Clickhouse және бәсекелестер: талаптар мен мүмкіндіктер
Біз не қалаймыз? Біз операция туралы тым көп алаңдамауымызды қамтамасыз еткіміз келеді, осылайша ол қораптан тыс, ең аз конфигурациямен жұмыс істейді. Біз көп жазғымыз келеді, тез жазғымыз келеді. Ал біз оны әр түрлі айларға, жылдарға, яғни ұзақ уақытқа сақтағымыз келеді. Біз олар бізге келіп: «Мұнда бірдеңе істемей жатыр» деген мәселені түсінгіміз келуі мүмкін, бұл 3 ай бұрын болды) және біз 3 ай бұрын не болғанын көргіміз келеді « Деректерді қысу – бұл неліктен плюс болатыны түсінікті – өйткені ол алатын орын көлемін азайтады.
Бізде мынадай қызықты талап бар: біз кейде кейбір командалардың (мысалы, журналдар) шығысын жазамыз, ол 4 килобайттан көп болуы мүмкін. Ал егер бұл нәрсе UDP арқылы жұмыс істейтін болса, онда оған жұмсаудың қажеті жоқ... қосылым үшін ешқандай «үстеме шығын» болмайды, ал серверлердің көп саны үшін бұл артықшылық болады.
Ашық дереккөз бізге не ұсынатынын көрейік. Біріншіден, бізде Logs Engine бар - бұл біздің қозғалтқыш; Негізінде оның қолынан бәрі келеді, тіпті ұзын-сонар жолдар да жаза алады. Бұл деректерді мөлдір түрде қыспайды - егер қаласақ, біз үлкен бағандарды өзіміз қыса аламыз ... біз, әрине, қаламаймыз (мүмкіндігінше). Жалғыз мәселе, ол жадында не болса, соны ғана беруді біледі; Қалғанын оқу үшін сіз осы қозғалтқыштың бинлогын алуыңыз керек және, тиісінше, бұл өте көп уақытты алады.
Басқа қандай нұсқалар бар? Мысалы, «Хадуп». Пайдаланудың қарапайымдылығы... Хадупты орнату оңай деп кім ойлайды? Әрине, жазуда қиындықтар жоқ. Оқыған кезде кейде сұрақтар туындайды. Негізінде, мен айтарым жоқ, әсіресе журналдар үшін. Ұзақ мерзімді сақтау - әрине, иә, деректерді қысу - иә, ұзын жолдар - жазуға болатыны анық. Бірақ көптеген серверлерден жазу... Сіз әлі де өзіңіз бірдеңе істеуіңіз керек!
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 бар. Әр серверде біз «Kittenhouse» деп атайтын жергілікті агентіміз бар, ол «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-ті кері проксимен ауыстырдым, оны өзім де жаздым.
Ол не істеп жатыр? Ол fasthttp кітапханасының «goshnoy» негізінде жұмыс істейді, яғни nginx сияқты жылдам. Кешіріңіз, Игорь, егер сіз осында болсаңыз (ескерту: Игорь Сысоев nginx веб-серверін жасаған ресейлік бағдарламашы). Ол олардың қандай сұраулар екенін түсіне алады – INSERT немесе SELECT – сәйкесінше ол сұраулардың әртүрлі түрлері үшін әртүрлі қосылым пулдарын сақтайды.
Тиісінше, кірістіру сұрауларын аяқтауға уақытымыз болмаса да, «таңдаушылар» өтеді және керісінше. Және ол деректерді буферлік кестелерге топтастырады - шағын буфермен: егер қателер болса, синтаксистік қателер және т. кішкентай «бачи» болды және барлық синтаксистік қателер тек осы шағын бөлікке әсер етті; және мұнда олар үлкен буферге әсер етеді. Кіші - 1 мегабайт, яғни соншалықты кішкентай емес.
Синхрондауды енгізу және nginx-ті түбегейлі ауыстыру, nginx бұрын жасаған нәрсені жасайды - бұл үшін жергілікті «Котенка үйін» өзгерту қажет емес. Және ол fasthttp пайдаланатындықтан, ол өте жылдам - кері прокси арқылы бір кірістіру үшін секундына 100 мыңнан астам сұраныс жасай аласыз. Теориялық тұрғыдан, сіз котенка кері проксиге бір уақытта бір жолды кірістіре аласыз, бірақ, әрине, біз мұны жасамаймыз.
Схема келесідей көріне бастады: «Киттенхаус», кері прокси көптеген сұрауларды кестелерге топтайды және өз кезегінде буферлік кестелер оларды негізгілеріне кірістіреді.
Киллер - уақытша шешім, Котенка - тұрақты
Бұл қызықты мәселе... Араларыңызда fasthttp пайдаланғандар бар ма? POST сұрауларымен fasthttp қолданбасын кім пайдаланды? Мүмкін, бұл шынымен де жасалмауы керек еді, себебі ол әдепкі бойынша сұрау денесін буферлейді және біздің буфер өлшемі 16 мегабайтқа орнатылды. Кірістіру бір сәтте тоқтатылды және 16 мегабайттық бөліктер он мыңдаған серверлерден келе бастады және олардың барлығы Clickhouse-ға жіберілмес бұрын жадта буферленді. Тиісінше, жад таусылды, жадсыз өлтіруші келіп, кері проксиді өлтірді (немесе кері проксиге қарағанда теориялық тұрғыдан «жеуге» болатын «Clickhouse»). Цикл қайталанды. Өте жағымды мәселе емес. Біз бұған бірнеше ай жұмыс істегеннен кейін ғана тап болдық.
Мен не істедім? Тағы да, мен нақты не болғанын түсінуді ұнатпаймын. Менің ойымша, жадты буферге түсірмеу керек екені анық. Мен тырысқанмен fasthttp патч жасай алмадым. Бірақ мен ештеңені түзетудің қажеті болмайтындай етіп жасаудың жолын таптым және мен HTTP-де өз әдісімді ойлап таптым - мен оны KITTEN деп атадым. Бұл қисынды – «ВК», «Котенка»... Тағы не?..
Егер серверге Котенок әдісімен сұраныс келсе, сервер логикалық түрде «мияу» деп жауап беруі керек. Егер ол бұған жауап берсе, онда ол бұл хаттаманы түсінеді деп есептеледі, содан кейін мен қосылымды тоқтатамын (fasthttp-де мұндай әдіс бар) және қосылым «шикі» режиміне өтеді. Бұл маған не үшін керек? Мен TCP қосылымдарынан оқу қалай болатынын басқарғым келеді. TCP тамаша қасиеті бар: егер басқа жақтан ешкім оқымаса, жазу күте бастайды, ал жады бұған ерекше жұмсалмайды.
Осылайша мен бір уақытта 50-ге жуық клиенттен оқимын (елуден бастап, өйткені мөлшерлеме басқа DC-ден келсе де, елу міндетті түрде жеткілікті болуы керек)... Бұл тәсілмен тұтыну кем дегенде 20 есе азайды, бірақ мен, шынымды айтсам. , Мен нақты қай уақытты өлшей алмадым, себебі бұл қазірдің өзінде мағынасыз (ол қателік деңгейіне жетті). Протокол екілік, яғни кестенің аты мен деректерін қамтиды; http тақырыптары жоқ, сондықтан мен веб-розетканы пайдаланбадым (браузерлермен байланысудың қажеті жоқ - мен қажеттіліктерімізге сәйкес протокол жасадым). Және онымен бәрі жақсы болды.
Буферлік кесте қайғылы
Жақында біз буферлік кестелердің тағы бір қызықты ерекшелігіне тап болдық. Және бұл мәселе басқаларға қарағанда әлдеқайда ауыр. Мына жағдайды елестетіп көрейік: сіз қазірдің өзінде Clickhouse-ды белсенді түрде пайдаланып жатырсыз, сізде ондаған Clickhouse серверлері бар және сізде оқуға өте ұзақ уақытты алатын кейбір сұрауларыңыз бар (айталық, 60 секундтан астам); және сіз осы сәтте келіп, Alter жасайсыз... Осы уақытта «Alter» алдында басталған «таңдамалар» бұл кестеге қосылмайды, «Alter» іске қосылмайды - мүмкін «Clickhouse» жұмысының кейбір ерекшеліктері осы жер. Мүмкін бұл түзетілетін шығар? Әлде мүмкін емес пе?
Тұтастай алғанда, бұл шын мәнінде соншалықты үлкен мәселе емес екені анық, бірақ буферлік кестелермен ол ауыр болады. Өйткені, егер, айталық, сіздің Alter күту уақыты аяқталса (және ол басқа хостта күтуі мүмкін – сіздікі емес, мысалы, көшірмеде), онда... Сіз буфер кестесін, Alter (немесе басқа хост) жойылдыңыз. ) күту уақыты аяқталды. содан кейін «Өзгерту» қатесі орын алды) - сіз әлі де деректердің жазылуын қамтамасыз етуіңіз керек: буферлік кестелерді қайтадан жасайсыз (тектік кестемен бірдей схемаға сәйкес), содан кейін «Өзгерту» өтеді. арқылы аяқталады және буфер кестеде ата-аналық схемадан ерекшелене бастайды. «Өзгерту» деген не екеніне байланысты кірістіру енді осы буферлік кестеге өтпеуі мүмкін - бұл өте өкінішті.
Сондай-ақ, мұндай белгі бар (мүмкін оны біреу байқаған шығар) - бұл Clickhouse жаңа нұсқаларында query_thread_log деп аталады. Әдепкі бойынша, кейбір нұсқаларда біреуі болды. Мұнда біз екі айдың ішінде 840 миллион жазба жинадық (100 гигабайт). Бұл онда «енгізулер» жазылғандығына байланысты (мүмкін, қазір, айтпақшы, олар жазылмаған шығар). Сізге айтқанымдай, біздің «енгізулер» кішкентай - бізде буферлік кестелерге «кірістірулер» көп болды. Бұл өшірілгені анық - мен сізге серверде көргенімді айтып отырмын. Неліктен? Бұл буферлік кестелерді пайдалануға қарсы тағы бір дәлел! Дақтар өте өкінішті.
Бұл жігіттің аты Спотти екенін кім білген? ВК қызметкерлері қолдарын көтерді. Жарайды.
«KitttenHouse» жоспарлары туралы
Жоспарлар әдетте ортақ емес, солай ма? Кенеттен сіз оларды орындамайсыз және басқалардың көз алдында өте жақсы көрінбейсіз. Бірақ мен тәуекелге барамын! Біз келесі әрекеттерді орындағымыз келеді: буферлік кестелер, меніңше, әлі де балдақ болып табылады және біз кірістіруді өзіміз буферлеуіміз керек. Бірақ біз оны әлі де дискіде буферлеуді қаламаймыз, сондықтан кірістіруді жадқа буферлейміз.
Тиісінше, «кірістіру» жасалғанда, ол енді синхронды болмайды - ол буферлік кесте ретінде жұмыс істейді, ата-аналық кестеге кірістіреді (жақсы, бір күні кейінірек) және кірістірулер өткен және қандай бөлек арна арқылы есеп береді. жоқ.
Неліктен мен синхронды кірістіруді қалдыра алмаймын? Бұл әлдеқайда ыңғайлы. Мәселе мынада, егер сіз 10 мың хосттан енгізсеңіз, онда бәрі жақсы - сіз әр хосттан аздап аласыз, секундына бір рет енгізесіз, бәрі жақсы. Бірақ мен бұл схеманың, мысалы, екі машинадан жұмыс істеуін қалаймын, осылайша сіз жоғары жылдамдықта жүктеп ала аласыз - мүмкін Clickhouse-дан максимум ала алмайсыз, бірақ кері прокси арқылы бір машинадан секундына кемінде 100 мегабайт жазыңыз - бұл схема үлкен және кіші өлшемдерге масштабталуы керек, сондықтан әрбір кірістіру үшін бір секунд күте алмаймыз, сондықтан ол асинхронды болуы керек. Сол сияқты, кірістіру аяқталғаннан кейін асинхронды растаулар келуі керек. Өтті ме, өтпеді ме, білетін боламыз.
Ең бастысы, бұл схемада біз кірістіру орын алды ма, жоқ па, анық білеміз. Мына жағдайды елестетіп көріңіз: сізде буферлік кесте бар, оған бірдеңе жаздыңыз, содан кейін кесте тек оқуға арналған режимге өтіп, буферді тазартуға тырысты. Деректер қайда кетеді? Олар буферде қалады. Бірақ біз бұған сенімді бола алмаймыз – егер деректер буферде қалмайтын басқа қате болса ше... (Мекенжайы Алексей Миловидов, Яндекс, ClickHouse әзірлеушісі) Әлде ол қалады ма? Әрқашан? Алексей бізді бәрі жақсы болатынына сендірді. Бізде оған сенбеуге негіз жоқ. Бірақ бәрібір: егер біз буферлік кестелерді қолданбасақ, онда олармен ешқандай проблемалар болмайды. Екі есе көп кестелерді құру да ыңғайсыз, бірақ негізінен үлкен проблемалар жоқ. Бұл жоспар.
Оқу туралы сөйлесейік
Енді оқу туралы сөйлесейік. Біз де осында өз құралымызды жаздық. Бұл жерде неге өз аспабыңды жазу керек сияқты?.. Ал Табиксті кім пайдаланған? Әйтеуір қол көтерген адам аз... Ал Табикстің орындауына кім көңілі толады? Біз бұған риза емеспіз және бұл деректерді қарау үшін өте ыңғайлы емес. Бұл аналитика үшін жақсы, бірақ тек көру үшін оңтайландырылмағаны анық. Сондықтан мен өзімнің интерфейсімді жаздым.
Бұл өте қарапайым - ол тек деректерді оқи алады. Ол графиканы көрсетуді білмейді, ештеңе жасауды білмейді. Бірақ ол бізге не қажет екенін көрсете алады: мысалы, кестеде қанша жол бар, ол қанша орын алады (оны бағандарға бөлмей), яғни өте қарапайым интерфейс бізге қажет.
Ол Sequel Pro-ға өте ұқсайды, бірақ тек Twitter-дің Bootstrap-те және екінші нұсқасында жасалған. Сіз: «Юри, неге екінші нұсқада?» Деп сұрайсыз. Қай жылы? 2018? Жалпы, мен мұны «Muscle» (MySQL) үшін бұрыннан жасадым және сол жердегі сұраулардағы бірнеше жолды өзгерттім және ол «Clickhouse» үшін жұмыс істей бастады, бұл үшін ерекше рахмет! Өйткені талдаушы «бұлшық етке» өте ұқсас, ал сұраулар өте ұқсас - өте ыңғайлы, әсіресе басында.
Ол кестелерді сүзе алады, кестенің құрылымы мен мазмұнын көрсете алады, сұрыптауға, бағандар бойынша сүзуге мүмкіндік береді, нәтижеге әкелген сұрауды, әсер еткен жолдарды (нәтижесінде қанша) көрсетеді, яғни деректерді қарауға арналған негізгі нәрселер. Өте жылдам.
Редакторы да бар. Мен шынымды айтсам, Tabix-тен бүкіл редакторды ұрлауға тырыстым, бірақ алмадым. Бірақ қандай да бір жолмен ол жұмыс істейді. Негізінде, бәрі осы.
«Кликхаус» ұяшықтар үшін қолайлы
Мен Clickhouse сипатталған барлық мәселелерге қарамастан, журналдар үшін өте қолайлы екенін айтқым келеді. Ең бастысы, ол біздің мәселемізді шешеді - бұл өте жылдам және журналдарды бағандар бойынша сүзуге мүмкіндік береді. Негізінде, буферлік кестелер жақсы жұмыс істемеді, бірақ әдетте неге ешкім білмейді... Мүмкін енді сіз қай жерде қиындықтар туындайтынын жақсы білесіз.
TCP? Жалпы, ВК-да UDP пайдалану әдеттегідей. Ал мен TCP пайдаланған кезде... Әрине, ешкім маған: «Юри, сен не айтып тұрсың! Сіз мүмкін емес, сізге UDP керек. TCP соншалықты қорқынышты емес екені белгілі болды. Жалғыз нәрсе, егер сізде жазатын он мыңдаған белсенді қосылыстар болса, оны сәл мұқият дайындау керек; бірақ бұл мүмкін және өте оңай.
Мен «Киттенхаус» пен «Маякты» HighLoad Siberia сайтында жариялауға уәде бердім, егер бәрі біздің «ВК бэйндіне» жазылса... Және бәрі де жазылмағанын білесіздер... Әрине, мен сізден біздің сайтқа жазылуды талап етпеймін. қоғамдық. Сіздердің араларыңыз әлі де көп, біреу ренжіуі мүмкін, бірақ бәрібір жазылыңыз (және мұнда мен мысықтың көздерін жасауым керек). Яғни . Үлкен рахмет! Github біздікі . Clickhouse көмегімен шашыңыз жұмсақ және жібектей болады.
Модератор: - Достар, енді сұрақтар. Біз алғыс сертификатын және VHS туралы баяндамаңызды ұсынғаннан кейін бірден.
Юрий Насретдинов (бұдан әрі – Ю.Н.): – VHS туралы есебім жаңа ғана аяқталса, сіз қалай жаза алдыңыз?
Модератор: – Сіз сондай-ақ «Clickhouse» қалай жұмыс істейтінін немесе жұмыс істемейтінін толық анықтай алмайсыз! Достар, сұрақтарға 5 минут!
Сіздің сұрақтарыңыз
Аудиторияның сұрағы (бұдан әрі – Q): - Қайырлы күн. Баяндама үшін көп рахмет. Менің екі сұрағым бар. Мен жеңіл нәрседен бастайын: диаграммалардағы (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-де болады, тек мен дәл сол нәрсені өзім жүзеге асыру үшін жазғанымнан да көп код жазуым керек еді және, ең алдымен, нашар. Мен тіпті Си тілінде жазғанды ұнатпаймын, тіпті оны былай қойғанда...
З: - Жай ғана ыңғайлы! Жіберілді және ештеңе күтпеңіз - бұл толығымен асинхронды. Барлығы жақсы екендігі туралы хабарлама келді - бұл келді дегенді білдіреді; Егер ол келмесе, бұл оның нашар екенін білдіреді.
YN: – Маған екеуі де керек – жеткізу кепілдігімен де, жеткізу кепілдігісіз де жібере алуым керек. Бұл екі түрлі сценарий. Кейбір журналдарды жоғалтпауым керек немесе оларды себеппен жоғалтпауым керек.
З: – Уақытты босқа өткізбеймін. Бұл туралы көбірек талқылау керек. Рақмет сізге.
Модератор: – Кімнің сұрағы бар – қолдары көкке!
З: - Сәлем, мен Сашамын. Есептің ортасында бір жерде TCP-тен басқа, дайын шешімді - Кафканың қандай да бір түрін қолдануға болады деген сезім пайда болды.
YN: – Жарайды... мен сізге аралық серверлерді пайдаланғым келмейтінін айттым, өйткені... Кафкада бізде он мың хост бар екен; шын мәнінде, бізде көбірек - ондаған мың хосттар бар. Сондай-ақ Кафкамен ешқандай проксисіз әрекет ету ауыр болуы мүмкін. Сонымен қатар, ең бастысы, ол әлі де «кідіріс» береді, ол сізге қажет қосымша хосттарды береді. Бірақ мен оларды алғым келмейді - мен қалаймын ...
З: «Бірақ ақыры бәрібір солай болды».
YN: – Жоқ, хосттар жоқ! Мұның бәрі Clickhouse хосттарында жұмыс істейді.
З: - Ал, ал «котятхаус», ол қай жерде тұрады?
YN: – Clickhouse хостында ол дискіге ештеңе жазбайды.
З: - Ал болсын.
Модератор: – Қанағаттандың ба? Біз сізге жалақы бере аламыз ба?
З: - Иә, мүмкін. Шындығында, бір нәрсені алу үшін көптеген балдақтар бар, ал қазір - TCP тақырыбы бойынша алдыңғы жауап, менің ойымша, бұл жағдайға қайшы келеді. Менің тіземде барлығын әлдеқайда аз уақытта жасауға болатын сияқты.
YN: – Сондай-ақ мен неге Кафканы пайдаланғым келмеді, өйткені Clickhouse Telegram чатында, мысалы, Кафкадан келген хабарламалар жоғалып кеткені туралы көптеген шағымдар болды. Кафканың өзінен емес, Кафка мен Кликхауздың интеграциясында; немесе онда бірдеңе қосылмады. Дөрекі сөзбен айтқанда, ол кезде Кафкаға клиент жазу керек еді. Мен қарапайым немесе сенімдірек шешім болуы мүмкін деп ойламаймын.
З: – Айтыңызшы, неге кезекті немесе қарапайым автобусты көрмедіңіз? Асинхрондылықпен журналдарды кезек арқылы жіберуге және жауапты кезек арқылы асинхронды түрде алуға болады деп айтасыз ба?
YN: – Қандай кезектерді қолдануға болатынын ұсыныңыз?
З: – Кез келген, тіпті олардың тәртіпте екеніне кепілдік болмаса да. Redis-тің бір түрі, RMQ...
YN: – Менің ойымша, Редис тіпті Clickhouse-ды шығаратын бір хостта (бірнеше сервер мағынасында) мұндай кірістіру көлемін тарта алмайды. Мен мұны ешқандай дәлелмен растай алмаймын (мен оны салыстырған жоқпын), бірақ маған Редис бұл жерде ең жақсы шешім емес сияқты. Негізінде бұл жүйені импровизацияланған хабарлама кезегі ретінде қарастыруға болады, бірақ ол тек «Clickhouse» үшін бейімделген.
Модератор: – Юрий, көп рахмет. Сұрақтар мен жауаптарды осы жерден аяқтап, сұрақ қойғандардың қайсысына кітапты беретінімізді айтуды ұсынамын.
YN: – Бірінші сұрақ қойған адамға кітап сыйлағым келеді.
Модератор: - Керемет! Тамаша! Керемет! Үлкен рахмет!
Кейбір жарнамалар 🙂
Бізбен бірге болғандарыңызға рахмет. Сізге біздің мақалалар ұнайды ма? Қызықты мазмұнды көргіңіз келе ме? Тапсырыс беру немесе достарыңызға ұсыну арқылы бізге қолдау көрсетіңіз, , Сіз үшін біз ойлап тапқан бастапқы деңгейдегі серверлердің бірегей аналогы: (RAID1 және RAID10, 24 ядроға дейін және 40 ГБ DDR4 дейін қол жетімді).
Dell R730xd Амстердамдағы Equinix Tier IV деректер орталығында 2 есе арзан ба? Тек осында Нидерландыда! Dell R420 - 2x E5-2430 2.2 ГГц 6C 128 ГБ DDR3 2x960 ГБ SSD 1 Гбит/с 100 ТБ - 99 доллардан бастап! туралы оқыңыз
Ақпарат көзі: www.habr.com