Яндекстің келесі дерекқорларға қосқан үлесі қаралады.
- кликхаус
- Odyssey
- Белгілі бір уақытқа дейін қалпына келтіру (WAL-G)
- PostgreSQL (соның ішінде тіркеу қателері, Amcheck, үйме тексеру)
- Жасыл қара өрік
Бейне:
Сәлем Әлем! Менің атым Андрей Бородин. Менің Yandex.Cloud-та істейтін жұмысым Яндекс.Cloud және Yandex.Cloud клиенттерінің мүдделері үшін ашық реляциялық дерекқорларды әзірлеу болып табылады.
Бұл әңгімеде біз ауқымды ашық деректер қорлары алдында тұрған қиындықтар туралы айтатын боламыз. Неліктен маңызды? Өйткені масалар сияқты, кейін пілге айналатын кішкентай, кішкентай проблемалар. Көптеген кластерлер болған кезде олар үлкен болады.
Бірақ бұл басты нәрсе емес. Адам сенбейтін нәрселер болады. Миллионнан бір жағдайда болатын нәрселер. Бұлтты ортада сіз бұған дайын болуыңыз керек, өйткені ауқымды нәрсе болған кезде керемет нәрселердің ықтималдығы жоғары болады.
Бірақ! Ашық деректер қорының артықшылығы неде? Өйткені, сізде кез келген мәселені шешуге теориялық мүмкіндік бар. Сізде бастапқы код бар, сізде бағдарламалау білімі бар. Біз оны біріктіреміз және ол жұмыс істейді.
Ашық бастапқы бағдарламалық жасақтамада жұмыс істеудің қандай тәсілдері бар?
- Ең қарапайым әдіс - бағдарламалық жасақтаманы пайдалану. Егер сіз хаттамаларды қолдансаңыз, стандарттарды қолдансаңыз, пішімдерді пайдалансаңыз, ашық бастапқы бағдарламалық құралда сұрауларды жазсаңыз, онда сіз оны бұрыннан қолдағансыз.
- Сіз оның экожүйесін кеңейтіп жатырсыз. Сіз қатені ерте анықтау ықтималдығын арттырасыз. Сіз бұл жүйенің сенімділігін арттырасыз. Сіз әзірлеушілердің нарықтағы қолжетімділігін арттырасыз. Сіз бұл бағдарламалық құралды жақсартасыз. Стиль алуды бастасаңыз және сол жерде бірдеңемен айналыссаңыз, сіз қазірдің өзінде үлес қосушысыз.
- Тағы бір түсінікті тәсіл ашық бастапқы бағдарламалық жасақтаманы демеушілік ету болып табылады. Мысалы, белгілі Google Summer of Code бағдарламасы, Google бүкіл әлемдегі студенттерге белгілі бір лицензиялық талаптарға жауап беретін ашық бағдарламалық жасақтама жобаларын жасау үшін түсінікті ақша төлейді.
- Бұл өте қызықты тәсіл, себебі ол бағдарламалық жасақтаманың назарды қауымдастықтан алшақтатпай дамытуға мүмкіндік береді. Google, технологиялық алпауыт ретінде, біз бұл мүмкіндікті қалаймыз деп айтпайды, біз бұл қатені түзеткіміз келеді және біз оны қазуымыз керек. Google: «Не істесең, соны істе. Сіз қалай жұмыс істесеңіз, солай жұмыс істей беріңіз, сонда бәрі жақсы болады ».
- Ашық дереккөзге қатысудың келесі тәсілі - қатысу. Ашық бастапқы бағдарламалық жасақтамада ақаулық туындаған кезде және әзірлеушілер бар болса, әзірлеушілеріңіз мәселелерді шеше бастайды. Олар сіздің инфрақұрылымыңызды тиімдірек, бағдарламаларыңызды жылдамырақ және сенімдірек ете бастайды.
Ашық бастапқы бағдарламалық қамтамасыз ету саласындағы ең танымал Яндекс жобаларының бірі - ClickHouse. Бұл Yandex.Metrica алдында тұрған қиындықтарға жауап ретінде дүниеге келген деректер базасы.
Мәліметтер базасы ретінде ол экожүйені құру және оны басқа әзірлеушілермен бірге дамыту (тек Яндекс ішінде ғана емес) үшін ашық бастапқы кодта жасалған. Ал қазір бұл көптеген түрлі компаниялар қатысатын үлкен жоба.
Yandex.Cloud-та біз ClickHouse-ты Яндекс нысандар қоймасының үстіне, яғни бұлтты сақтау қоймасының үстіне жасадық.
Неліктен бұл бұлтта маңызды? Өйткені кез келген мәліметтер базасы осы үшбұрышта, осы пирамидада, осы жады түрлерінің иерархиясында жұмыс істейді. Сізде жылдам, бірақ шағын регистрлер және арзан үлкен, бірақ баяу SSD дискілері, қатты дискілер және кейбір басқа блок құрылғылары бар. Ал егер сіз пирамиданың жоғарғы жағында тиімді болсаңыз, онда сізде жылдам деректер базасы бар. егер сіз осы пирамиданың төменгі жағында тиімді болсаңыз, онда сізде ауқымды дерекқор бар. Және осыған байланысты төменнен тағы бір қабатты қосу деректер қорының масштабтауын арттырудың логикалық тәсілі болып табылады.
Мұны қалай жасауға болады? Бұл есептің маңызды сәті.
- Біз MDS арқылы ClickHouse қолданбасын енгізе аламыз. MDS - бұл Яндекстің ішкі сақтау интерфейсі. Бұл қарапайым S3 протоколына қарағанда күрделірек, бірақ блоктық құрылғы үшін қолайлы. Бұл деректерді жазу үшін жақсырақ. Ол қосымша бағдарламалауды қажет етеді. Бағдарламашылар бағдарламалайды, бұл тіпті жақсы, бұл қызықты.
- S3 - жұмыс жүктемесінің белгілі бір түрлеріне аз бейімделу есебінен интерфейсті қарапайым ететін кең таралған тәсіл.
Әрине, бүкіл ClickHouse экожүйесін функционалдылықты қамтамасыз ету және Yandex.Cloud ішінде қажет тапсырманы орындау үшін біз бүкіл ClickHouse қауымдастығы одан пайда көретініне көз жеткізуді шештік. Біз MDS арқылы ClickHouse емес, ClickHouse-ты S3 үстіне енгіздік. Ал бұл көп жұмыс.
сілтемелер:
«Файлдық жүйенің абстракциялық қабаты»
"AWS SDK S3 интеграциясы"
«S3 үшін IDisk интерфейсін базалық енгізу»
«IDisk интерфейсімен журналдарды сақтау механизмдерін біріктіру»
«S3 және SeekableReadBuffer үшін журнал қозғалтқышын қолдау»
"Storage Stripe Log S3 қолдауы"
"S3 үшін Storage MergeTree бастапқы қолдауы"
«MergeTree S3 үшін толық қолдау»
"S3 үстінде ReplicatedMergeTree қолдауы"
«S3 жады үшін әдепкі тіркелгі деректерін және реттелетін тақырыптарды қосу»
«Динамикалық прокси конфигурациясы бар S3»
"S3 прокси-ревизоры бар"
Бұл ClickHouse жүйесінде виртуалды файлдық жүйені енгізуге арналған тарту сұрау тізімі. Бұл тарту сұрауларының үлкен саны.
сілтемелер:
«DiskS3 қатты сілтемелерді оңтайлы іске асыру»
«S3 HTTP клиенті — Жауап ағынын жадқа көшірмеңіз»
«Толық жауап ағынын S3 HTTP жадына көшірмеңіз
клиент»
«S3 дискісі үшін файлдарды белгілеу және индекстеу мүмкіндігі»
«Бөлшектерді DiskLocal-дан DiskS3-ке параллель жылжыту»
Бірақ жұмыс мұнымен бітпеді. Мүмкіндік жасалғаннан кейін бұл функцияны оңтайландыру үшін тағы біраз жұмыс қажет болды.
сілтемелер:
«SelectedRows және SelectedBytes оқиғаларын қосу»
"S3 сұрауынан system.events файлына профильдеу оқиғаларын қосу"
"QueryTimeMicroseconds, SelectQueryTimeMicroseconds және InsertQueryTimeMicroseconds қосу"
Содан кейін оны диагностикалауға, мониторингті орнатуға және оны басқаруға болатындай ету керек болды.
Мұның бәрі бүкіл қауымдастық, бүкіл ClickHouse экожүйесі осы жұмыстың нәтижесін алуы үшін жасалды.
Транзакциялық дерекқорларға, жеке өзіме жақынырақ OLTP дерекқорларына көшейік.
Бұл ашық бастапқы ДҚБЖ әзірлеу бөлімі. Бұл балалар транзакциялық ашық дерекқорларды жақсарту үшін көше сиқырымен айналысады.
Мысал ретінде біз қалай және не істейтініміз туралы айтуға болатын жобалардың бірі - Postgres-тегі Connection Pooler.
Postgres - бұл процесс деректер базасы. Бұл дерекқорда транзакцияларды өңдейтін мүмкіндігінше аз желі қосылымдары болуы керек дегенді білдіреді.
Екінші жағынан, бұлтты ортада мың қосылым бірден бір кластерге келетін әдеттегі жағдай. Ал қосылым пулаторының міндеті - сервер қосылымдарының аз санына мың қосылымды жинақтау.
Байттарды дерекқорға тиімді жету үшін қайта реттейтін телефон операторы қосылымды біріктіруші деп айта аламыз.
Өкінішке орай, қосылу пулаторы үшін жақсы орыс сөзі жоқ. Кейде оны мультиплексорлық қосылымдар деп те атайды. Егер сіз қосылым пулаторын қалай атайтыныңызды білсеңіз, маған міндетті түрде айтыңыз, мен дұрыс орыс техникалық тілінде сөйлегеніме өте қуаныштымын.
Біз басқарылатын постгрес кластері үшін қолайлы қосылым пулерлерін зерттедік. Ал PgBouncer біз үшін ең жақсы таңдау болды. Бірақ біз PgBouncer-те бірқатар мәселелерге тап болдық. Көптеген жылдар бұрын Володя Бородин біз PgBouncer қолданатынымыз туралы есеп берді, бізге бәрі ұнайды, бірақ нюанстар бар, жұмыс істеу керек нәрсе бар.
Ал біз жұмыс істедік. Біз кездескен мәселелерді түзеттік, Bouncer қолданбасын түзеттік және тарту сұрауларын жоғары ағынға жіберуге тырыстық. Бірақ іргелі бір ағынмен жұмыс істеу қиын болды.
Бізге патчталған Bouncers каскадтарын жинауға тура келді. Бізде көптеген бір ағынды Bouncers болғанда, жоғарғы қабаттағы қосылымдар Bouncers ішкі қабатына ауыстырылады. Бұл нашар басқарылатын жүйе, оны құру және кеңейту қиын.
Біз «Одиссей» деп аталатын өзіміздің қосылым пульерін жасадық деген қорытындыға келдік. Біз оны нөлден жаздық.
2019 жылы PgCon конференциясында мен бұл пулизаторды әзірлеушілер қауымдастығына ұсындым. Қазір бізде GitHub-да 2-нан сәл аз жұлдыздар бар, яғни жоба тірі, жоба танымал.
Егер сіз Yandex.Cloud-та Postgres кластерін жасасаңыз, онда ол кластерді алға немесе артқа масштабтау кезінде қайта конфигурацияланатын кірістірілген Odyssey бар кластер болады.
Бұл жобадан не үйрендік? Бәсекелестік жобаны іске қосу әрқашан агрессивті қадам болып табылады, біз жеткілікті жылдам шешілмейтін, бізге қолайлы уақыт аралығында шешілмейтін мәселелер бар деп айтсақ, бұл төтенше шара. Бірақ бұл тиімді шара.
PgBouncer жылдам дами бастады.
Енді басқа жобалар пайда болды. Мысалы, Red Hat әзірлеушілері әзірлеген pgagroal. Олар ұқсас мақсаттарды көздейді және ұқсас идеяларды жүзеге асырады, бірақ, әрине, pgagroal әзірлеушілеріне жақынырақ өзіндік ерекшеліктері бар.
Postgres қауымдастығымен жұмыс істеудің тағы бір жағдайы - белгілі бір уақытқа дейін қалпына келтіру. Бұл сәтсіздіктен кейін қалпына келтіру, бұл сақтық көшірмеден қалпына келтіру.
Көптеген сақтық көшірмелер бар және олардың барлығы әртүрлі. Әрбір дерлік Postgres жеткізушісінің өзінің резервтік шешімі бар.
Егер сіз барлық резервтік жүйені алсаңыз, мүмкіндік матрицасын жасаңыз және осы матрицадағы анықтауышты әзілдеп есептесеңіз, ол нөлге тең болады. Бұл нені білдіреді? Белгілі бір сақтық көшірме файлын алсаңыз ше, оны басқаларының бөліктерінен жинау мүмкін емес. Оның жүзеге асуында да, мақсатымен де бірегей, оған енген идеялары да ерекше. Және олардың барлығы нақты.
Біз осы мәселемен жұмыс істеп жатқан кезде CitusData WAL-G жобасын іске қосты. Бұл бұлттық ортаны ескере отырып жасалған сақтық көшірме жүйесі. Енді CitusData қазірдің өзінде Microsoft корпорациясының бөлігі болып табылады. Сол кезде бізге WAL-G бастапқы шығарылымдарында айтылған идеялар қатты ұнады. Біз бұл жобаға өз үлесімізді қоса бастадық.
Қазір бұл жобада ондаған әзірлеушілер бар, бірақ WAL-G-ге ең жақсы 10 үлес қосушыға 6 Яндексоид кіреді. Біз көптеген идеяларымызды сонда әкелдік. Және, әрине, біз оларды өзіміз іске асырдық, өзіміз сынап көрдік, өндіріске өзіміз енгіздік, біз оларды өзіміз қолданамыз, WAL-G үлкен қауымдастығымен өзара әрекеттесе отырып, әрі қарай қайда көшу керектігін өзіміз анықтаймыз.
Біздің көзқарасымыз бойынша, қазір бұл резервтік жүйе, соның ішінде біздің күш-жігерімізді ескере отырып, бұлтты орта үшін оңтайлы болды. Бұл бұлтта Postgres сақтық көшірмесін жасаудың ең жақсы құны.
Бұл нені білдіреді? Біз өте үлкен идеяны алға тарттық: сақтық көшірме қауіпсіз, жұмыс істеуге арзан және қалпына келтіру мүмкіндігінше жылдам болуы керек.
Неліктен оны пайдалану арзан болуы керек? Ештеңе бұзылмаған кезде, сізде сақтық көшірмелер бар екенін білмеуіңіз керек. Барлығы жақсы жұмыс істейді, сіз мүмкіндігінше аз CPU жұмсайсыз, диск ресурстарыңызды мүмкіндігінше аз пайдаланасыз және құнды қызметтеріңіздің пайдалы жүктемесіне кедергі келтірмеу үшін желіге мүмкіндігінше аз байт жібересіз.
Және бәрі бұзылған кезде, мысалы, әкімші деректерді тастап кетті, бірдеңе дұрыс болмады және сізге шұғыл түрде өткенге оралу керек, сіз барлық ақшамен қалпына келтіресіз, өйткені сіз деректеріңізді тез және бүлінбеген етіп қайтарғыңыз келеді.
Біз бұл қарапайым идеяны алға тарттық. Ал, біз оны жүзеге асыра алдық деп ойлаймыз.
Бірақ бұл бәрі емес. Біз тағы бір кішкентай нәрсені қаладық. Бізге әртүрлі мәліметтер базасы қажет. Біздің клиенттердің барлығы Postgres қолданбайды. Кейбір адамдар MySQL, MongoDB пайдаланады. Қауымдастықта басқа әзірлеушілер FoundationDB-ге қолдау көрсетті. Және бұл тізім үнемі кеңейіп келеді.
Қауымдастық дерекқорды бұлтта басқарылатын ортада іске қосу идеясын ұнатады. Әзірлеушілер өз деректер базасын сақтайды, олардың сақтық көшірмесін Postgres-пен бірге біздің сақтық көшірме жүйемізбен біркелкі жасауға болады.
Бұл әңгімеден біз не білдік? Біздің өнім даму бөлімі ретінде код жолдары емес, мәлімдемелер емес, файлдар емес. Біздің өнім тарту сұраныстары емес. Бұл біздің қоғамға жеткізетін идеяларымыз. Бұл технологиялық сараптама және технологияның бұлтты ортаға қарай қозғалысы.
Postgres сияқты мәліметтер базасы бар. Маған Postgres өзегі көбірек ұнайды. Мен қоғамдастықпен Postgres өзегін дамытуға көп уақыт жұмсаймын.
Бірақ бұл жерде Yandex.Cloud басқарылатын дерекқорлардың ішкі орнатылымы бар екенін айту керек. Және бұл Yandex.Mail-де баяғыда басталды. Қазір басқарылатын Postgres-ке әкелген тәжірибе пошта Postgres-ке ауысқысы келгенде жинақталған.
Пошта бұлтқа өте ұқсас талаптарға ие. Ол сіздің деректеріңіздің кез келген нүктесінде күтпеген экспоненциалды өсуге дейін масштабтауды қажет етеді. Поштада үнемі көптеген сұраныстар жасайтын көптеген пайдаланушылардың жүздеген миллион пошта жәшіктері жүктелді.
Бұл Postgres әзірлеуші команда үшін өте күрделі сынақ болды. Сол кезде біз кез келген мәселе қоғамға хабарланатын. Және бұл проблемалар түзетілді және кейбір жерлерде қоғамдастық тіпті кейбір басқа дерекқорларға ақылы қолдау деңгейінде және одан да жақсырақ түзетілді. Яғни, PgSQL хакеріне хат жолдап, 40 минут ішінде жауап алуға болады. Кейбір дерекқорлардағы ақылы қолдау сіздің қателіктеріңізге қарағанда басымырақ нәрселер бар деп ойлауы мүмкін.
Енді Postgres-тің ішкі орнатылымы - бұл бірнеше петабайт деректер. Бұл секундына миллиондаған сұраулар. Бұл мыңдаған кластерлер. Бұл өте ауқымды.
Бірақ бір нюанс бар. Ол сәнді желілік дискілерде емес, қарапайым жабдықта өмір сүреді. Және қызықты жаңа нәрселер үшін арнайы сынақ ортасы бар.
Ал белгілі бір сәтте сынақ ортасында біз деректер қоры индекстерінің ішкі инварианттары бұзылғанын көрсететін хабарлама алдық.
Инвариант - бұл біз әрқашан ұстанатын қарым-қатынастың бір түрі.
Біз үшін өте қиын жағдай. Бұл кейбір деректердің жоғалғанын көрсетеді. Ал деректердің жоғалуы - бұл апатты нәрсе.
Басқарылатын дерекқорларда біз ұстанатын жалпы идея - күш жұмсағанның өзінде деректерді жоғалту қиын болады. Сіз оларды әдейі алып тастасаңыз да, ұзақ уақыт бойы олардың жоқтығын елемеуге тура келеді. Деректер қауіпсіздігі - бұл біз мұқият ұстанатын дін.
Міне, біз дайын болмайтын жағдайдың болуы мүмкін екенін көрсететін жағдай туындайды. Ал біз бұл жағдайға дайындала бастадық.
Біз жасаған бірінші нәрсе - мыңдаған кластерлердің бөренелерін көму. Біз кластерлердің қайсысы деректер беті жаңартуларын жоғалтып жатқан ақаулы микробағдарламасы бар дискілерде орналасқанын анықтадық. Барлық Postgres деректер кодын белгіледі. Біз ішкі инварианттардың бұзылуын көрсететін хабарларды деректердің бүлінуін анықтауға арналған кодпен белгіледік.
Бұл патчты қауымдастық іс жүзінде көп талқылаусыз қабылдады, өйткені әрбір нақты жағдайда жаман нәрсе болғаны және журналға хабарлау қажет екендігі анық болды.
Осыдан кейін біз журналдарды сканерлейтін мониторинг бар дегенге келдік. Ал күдікті хабарламалар түскен жағдайда кезекшіні оятып, кезекші жөндеу жұмыстарын жүргізеді.
Бірақ! Журналдарды сканерлеу - бұл бір кластерде арзан операция және мың кластер үшін апатты түрде қымбат.
деп аталатын кеңейтімді жаздық . Ол өткен қателер бойынша статистиканы арзан әрі жылдам таңдауға болатын дерекқордың көрінісін жасайды. Егер кезекшіні ояту керек болса, онда біз бұл туралы гигабайттық файлдарды сканерлемей-ақ, хэш кестесінен бірнеше байтты шығару арқылы білеміз.
Бұл кеңейтім, мысалы, үшін репозиторийде қабылданған . Егер сіз оны пайдаланғыңыз келсе, оны өзіңіз орната аласыз. Әрине, бұл ашық бастапқы код.
Бірақ бұл бәрі емес. Біз индекстердегі инвариантты бұзушылықтарды табу үшін қоғамдастық жасаған кеңейтім Amcheck-ті пайдалана бастадық.
Егер сіз оны масштабта қолдансаңыз, қателер бар екенін білдік. Біз оларды жөндей бастадық. Біздің түзетулеріміз қабылданды.
Бұл кеңейтім GiST және GIT индекстерін талдай алмайтынын анықтадық. Біз оларға қолдау көрсеттік. Бірақ бұл қолдау әлі де қоғамда талқылануда, өйткені бұл салыстырмалы түрде жаңа функционалдылық және онда көптеген мәліметтер бар.
Сондай-ақ біз репликация көшбасшысында, шеберде бұзушылықтардың индекстерін тексеру кезінде барлығы жақсы жұмыс істейтінін, бірақ көшірмелерде, ізбасарда сыбайлас жемқорлықты іздеу соншалықты тиімді емес екенін анықтадық. Барлық инварианттар тексерілмейді. Ал бір инвариант бізді қатты мазалады. Көшірмелерді тексеруді қосу үшін біз бір жарым жыл бойы қауымдастықпен байланыста болдық.
Біз барлық can... протоколдарына сәйкес келетін кодты жаздық. Біз бұл патчты Crunchy Data-дан Питер Гаганмен біраз уақыт талқыладық. Бұл патчты қабылдау үшін ол Postgres-тегі бар B-ағашты сәл өзгертуі керек болды. Ол қабылданды. Ал енді көшірмелердегі индекстерді тексеру де біз кездестірген бұзушылықтарды анықтау үшін жеткілікті тиімді болды. Яғни, бұл диск микробағдарламасындағы қателерден, Postgres қателерінен, Linux ядросындағы қателерден және аппараттық ақаулардан туындауы мүмкін бұзушылықтар. Біз дайындаған проблемалардың көздерінің өте кең тізімі.
Бірақ индекстерден басқа, үйме сияқты бөлік бар, яғни деректер сақталатын орын. Тексеруге болатын инварианттар көп емес.
Бізде Heapcheck деп аталатын кеңейтім бар. Біз оны дамытуды бастадық. Сонымен қатар, бізбен бірге EnterpriseDB компаниясы да дәл осылай Heapcheck деп атаған модуль жаза бастады. Тек біз оны PgHeapcheck деп атадық, ал олар оны Heapcheck деп атады. Олардың функциялары ұқсас, қолтаңбасы сәл өзгеше, бірақ идеялары бірдей. Олар кейбір жерлерде оларды біршама жақсырақ енгізді. Және олар мұны бұрын ашық дереккөзге орналастырған.
Енді біз олардың кеңеюін дамытып жатырмыз, өйткені бұл енді олардың кеңеюі емес, қауымдастықтың кеңеюі. Болашақта бұл барлық адамдарға болашақ проблемалар туралы алдын ала білу үшін жеткізілетін ядроның бөлігі.
Кейбір жерлерде біз бақылау жүйелерінде жалған позитивтер бар деген қорытындыға да келдік. Мысалы, 1С жүйесі. Дерекқорды пайдаланған кезде Postgres кейде оған оқи алатын деректерді жазады, бірақ pg_dump оқи алмайды.
Бұл жағдай біздің проблемаларды анықтау жүйемізде сыбайлас жемқорлық болып көрінді. Кезекші оянды. Кезекші не болып жатқанына қарады. Біраз уақыттан кейін клиент келіп, менде қиындықтар бар екенін айтты. Қызметші мәселенің не екенін түсіндірді. Бірақ мәселе Postgres өзегінде.
Мен бұл мүмкіндік туралы пікірталас таптым. Және ол бізде бұл ерекшелікке тап болғанын және бұл жағымсыз екенін жазды, адам түнде оның не екенін анықтау үшін оянған.
Қауымдастық: «Ой, біз оны түзетуіміз керек» деп жауап берді.
Менде қарапайым ұқсастық бар. Егер сізде құм түйіршіктері бар аяқ киіммен жүрсеңіз, онда, негізінен, сіз әрі қарай жүре аласыз - проблема жоқ. Мыңдаған адамға етік сатсаң, мүлде құмсыз етік жасайық. Егер сіздің аяқ киіміңізді пайдаланушылардың бірі марафонға баратын болса, онда сіз өте жақсы аяқ киім жасағыңыз келеді, содан кейін оларды барлық пайдаланушыларыңызға таратқыңыз келеді. Ал мұндай күтпеген пайдаланушылар әрқашан бұлттық ортада болады. Кластерді қандай да бір түпнұсқа жолмен пайдаланатын пайдаланушылар әрқашан болады. Бұған әрқашан дайындалу керек.
Біз мұнда не үйрендік? Біз қарапайым нәрсені білдік: ең бастысы қоғамға мәселе бар екенін түсіндіру. Егер қоғам проблеманы мойындаса, мәселені шешу үшін табиғи бәсекелестік туындайды. Өйткені әрбір адам маңызды мәселені шешкісі келеді. Барлық сатушылар, барлық хакерлер өздері осы рейкке басуға болатынын түсінеді, сондықтан оларды жойғысы келеді.
Егер сіз мәселемен жұмыс істеп жатсаңыз, бірақ ол сізден басқа ешкімді алаңдатпайды, бірақ сіз онымен жүйелі түрде жұмыс жасайсыз және ол ақыр соңында мәселе болып саналса, онда сіздің тарту сұрауыңыз міндетті түрде қабылданады. Сіздің патчыңыз қабылданады, жақсартуларыңыз немесе тіпті жақсартулар туралы сұраулар қауымдастық тарапынан қаралады. Күннің соңында біз бір-біріміз үшін дерекқорды жақсартамыз.
Қызықты деректер базасы Greenplum болып табылады. Бұл маған өте таныс Postgres кодтық базасына негізделген өте параллельді дерекқор.
Және Greenplum қызықты функционалдығы бар - оңтайландырылған кестелерді қосыңыз. Бұл тез қосуға болатын кестелер. Олар бағаналы немесе жолды болуы мүмкін.
Бірақ кластерлеу болған жоқ, яғни кестеде орналасқан деректерді индекстердің біріндегі ретке сәйкес реттеуге болатын функционалдылық болмады.
Таксидегі жігіттер маған келіп: «Андрей, сен Постгресті білесің. Ал мұнда бәрі дерлік бірдей. 20 минутқа ауысыңыз. Сіз оны алыңыз да, жасаңыз ». Мен иә, мен Постгресті білемін, 20 минутқа ауысамын деп ойладым - мен мұны істеуім керек.
Бірақ жоқ, бұл 20 минут емес, мен оны айлар бойы жаздым. PgConf.Russia конференциясында мен Pivotal компаниясынан Хейки Линакангасқа хабарласып: «Мұнда қандай да бір проблемалар бар ма? Неліктен қосымша оңтайландырылған кесте кластері жоқ?» Ол: «Сіз деректерді аласыз. Сіз сұрыптайсыз, қайта реттейсіз. Бұл жай ғана жұмыс». Мен: «Ой, иә, оны алып, істеу керек». Ол: «Иә, мұны істеу үшін бізге бос қол керек», - дейді. Мен мұны міндетті түрде жасауым керек деп ойладым.
Бірнеше айдан кейін мен осы функцияны жүзеге асыратын тарту сұрауын жібердім. Бұл тарту сұрауын Pivotal қауымдастықпен бірге қарады. Әрине, қателер болды.
Бірақ ең қызығы, бұл тарту сұрауы біріктірілген кезде Greenplum-дің өзінде қателер табылды. Біз үйме кестелері кластерленген кезде транзакцияны бұзатынын анықтадық. Ал бұл реттелетін нәрсе. Ал ол мен жаңа ғана түрткен жерде. Менің табиғи реакциям – жарайды, мен де солай істеуге рұқсат етіңіз.
Мен бұл қатені түзеттім. Түзетушілерге тарту сұрауын жіберді. Ол өлтірілді.
Осыдан кейін бұл функцияны PostgreSQL 12 үшін Greenplum нұсқасында алу керек екені белгілі болды. Яғни, 20 минуттық шытырман оқиға жаңа қызықты оқиғалармен жалғасады. Қоғамдастық жаңа және ең маңызды мүмкіндіктерді кесіп жатқан қазіргі дамуды қозғау қызықты болды. Ол қатып қалды.
Бірақ мұнымен бітпеді. Бәрінен кейін осының бәріне құжат жазу керек болып шықты.
Мен құжаттарды жаза бастадым. Бақытымызға орай, Pivotal-тың деректі мамандары келді. Ағылшын тілі - олардың ана тілі. Олар маған құжаттамаға көмектесті. Шындығында, олар мен ұсынған нәрсені нағыз ағылшын тіліне қайта жазды.
Міне, шытырман оқиға біткен сияқты. Ал сіз сол кезде не болғанын білесіз бе? Таксидегі жігіттер маған келіп: «Әлі 10 минуттан екі шытырман оқиға бар», - деді. Ал мен оларға не айтуым керек? Мен қазір масштабта есеп беремін, содан кейін сіздің шытырман оқиғаларыңызды көреміз дедім, өйткені бұл қызықты жұмыс.
Бұл жағдайдан не үйрендік? Ашық дереккөзбен жұмыс істеу әрқашан белгілі бір адаммен жұмыс істейтіндіктен, ол әрқашан қауымдастықпен жұмыс істейді. Өйткені әр кезеңде мен кейбір әзірлеушімен, кейбір тестерлермен, кейбір хакерлермен, кейбір деректі авторлармен, кейбір сәулетшілермен жұмыс істедім. Мен Greenplum компаниясымен жұмыс істемедім, мен Greenplum айналасындағы адамдармен жұмыс істедім.
Бірақ! Тағы бір маңызды сәт бар - бұл жай ғана жұмыс. Яғни, сіз келіңіз, кофе ішіңіз, код жазасыз. Қарапайым инварианттардың барлық түрлері жұмыс істейді. Мұны әдеттегідей орындаңыз - бәрі жақсы болады! Және бұл өте қызықты жұмыс. Бұл жұмысқа Яндекс.Cloud клиенттерінен, Яндекс ішінде де, сыртында да кластерлерді пайдаланушылардан сұраныс бар. Ал біз қатысатын жобалардың саны артып, қатысу тереңдігі де арта түседі деп ойлаймын.
Бар болғаны. Сұрақтарға көшейік.
Сұрақтар сессиясы
Сәлеметсіз бе! Бізде тағы бір сұрақ-жауап бар. Ал Андрей Бородин студиясында. Бұл Яндекс.Cloud пен Яндекстің ашық дереккөзге қосқан үлесі туралы жаңа ғана айтқан адам. Біздің баяндамамыз бұлтқа қатысты емес, сонымен бірге біз осындай технологияларға негізделген. Яндекстің ішінде жасаған әрекеттеріңіз болмаса, Yandex.Cloud-та ешқандай қызмет болмас еді, сондықтан жеке маған рахмет. Эфирдегі бірінші сұрақ: «Сіз айтқан жобалардың әрқайсысы не туралы жазылған?»
WAL-G жүйесіндегі сақтық көшірме жүйесі Go тілінде жазылған. Бұл біз жұмыс істеген жаңа жобалардың бірі. Ол небәрі 3 жаста. Ал деректер базасы көбінесе сенімділікке қатысты. Бұл деректер базаларының әбден ескіргенін және олар әдетте C тілінде жазылғанын білдіреді. Postgres жобасы шамамен 30 жыл бұрын басталған. Сонда C89 дұрыс таңдау болды. Оның үстіне Postgres жазылған. ClickHouse сияқты заманауи дерекқорлар әдетте C++ тілінде жазылады. Барлық жүйенің дамуы C және C++ төңірегінде негізделген.
Бұлттағы шығындарға жауапты қаржылық менеджеріміздің сұрағы: «Бұлт неліктен ашық бастапқы кодты қолдауға ақша жұмсайды?»
Мұнда қаржылық менеджерге қарапайым жауап бар. Біз мұны қызметтерімізді жақсарту үшін жасаймыз. Біз қандай жолдармен жақсырақ істей аламыз? Біз нәрселерді тиімдірек, жылдамырақ жасай аламыз және нәрселерді ауқымды ете аламыз. Бірақ біз үшін бұл әңгіме ең алдымен сенімділік туралы. Мысалы, сақтық көшірме жүйесінде біз оған қолданылатын патчтардың 100% қараймыз. Біз кодтың не екенін білеміз. Біз өндіріске жаңа нұсқаларды шығару ыңғайлырақ. Яғни, ең алдымен, бұл сенімділік, дамуға дайын болу және сенімділік туралы
Тағы бір сұрақ: «Яндекс.Cloud жүйесінде тұратын сыртқы пайдаланушылардың талаптары ішкі бұлтта тұратын ішкі пайдаланушылардан айырмашылығы бар ма?»
Жүктеме профилі, әрине, әртүрлі. Бірақ менің бөлімшенің көзқарасы бойынша, барлық ерекше және қызықты істер стандартты емес жүктемеде жасалады. Қиялы бар әзірлеушілер, күтпеген нәрсені жасайтын әзірлеушілер ішкі және сыртқы жағынан да табылуы мүмкін. Осыған байланысты бәріміз шамамен бірдейміз. Және, бәлкім, Яндекс деректер базасының жұмысындағы жалғыз маңызды мүмкіндік Яндекс ішінде бізде оқыту бар. Бір сәтте кейбір қолжетімділік аймағы толығымен көлеңкеге түседі және оған қарамастан барлық Яндекс қызметтері қандай да бір түрде жұмысын жалғастыруы керек. Бұл кішкене айырмашылық. Бірақ ол деректер қоры мен желілік стек интерфейсінде көптеген зерттеулерді жасайды. Әйтпесе, сыртқы және ішкі қондырғылар мүмкіндіктер үшін бірдей сұрауларды және сенімділік пен өнімділікті арттыруға арналған ұқсас сұрауларды жасайды.
Келесі сұрақ: «Сіз жасаған ісіңіздің көп бөлігін басқа бұлттар пайдаланады дегенге қалай қарайсыз?» Біз нақтыларын атамаймыз, бірақ Yandex.Cloud-та жасалған көптеген жобалар басқа адамдардың бұлттарында қолданылады.
Бұл керемет. Біріншіден, бұл біздің бір нәрсені дұрыс жасағанымыздың белгісі. Және бұл эгоды сызады. Және біз дұрыс шешім қабылдағанымызға сенімдіміз. Екінші жағынан, бұл болашақта бізге жаңа идеялар, үшінші тарап пайдаланушыларының жаңа сұраулары әкеледі деген үміт. GitHub-тағы мәселелердің көпшілігін жеке жүйелік әкімшілер, жеке DBA, жеке сәулетшілер, жеке инженерлер жасайды, бірақ кейде жүйелі тәжірибесі бар адамдар келіп, белгілі бір жағдайлардың 30% -ында бізде бұл мәселе бар және оны қалай шешуге болатынын ойластырайық дейді. Бұл біз ең көп күтетін нәрсе. Біз басқа бұлттық платформалармен тәжірибе алмасуды асыға күтеміз.
Сіз марафон туралы көп айттыңыз. Сіздің Мәскеуде марафонға қатысқаныңызды білемін. Болғандықтан? PostgreSQL жігіттерін басып оздыңыз ба?
Жоқ, Олег Бартунов өте жылдам жүгіреді. Ол менен бір сағат бұрын бітірді. Жалпы, мен қаншалықты жеткеніме ризамын. Мен үшін жай ғана аяқтау жетістік болды. Тұтастай алғанда, постгрес қауымдастығында көптеген жүгірушілер бар екені таң қалдырады. Меніңше, аэробты спорт пен жүйелік бағдарламалауға деген ұмтылыстың арасында қандай да бір байланыс бар сияқты.
ClickHouse-те жүгірушілер жоқ деп айтасыз ба?
Мен олардың бар екенін анық білемін. ClickHouse да дерекқор болып табылады. Айтпақшы, Олег қазір маған: «Есептен кейін жүгіруге барамыз ба?» деп жазып жатыр. Бұл тамаша идея.
Никитаның хабарынан тағы бір сұрақ: «Неге сіз Greenplum қатесін өзіңіз түзетіп, оны жасөспірімдерге бермедіңіз?» Рас, қатенің не және қай қызметте екені анық емес, бірақ бұл сіз айтқан нәрсені білдіруі мүмкін.
Иә, негізі біреуге берілуі мүмкін еді. Мен жай ғана өзгерткен код болды. Және мұны бірден жалғастыру табиғи болды. Негізінде, тәжірибені командамен бөлісу идеясы жақсы идея. Біз Greenplum тапсырмаларын біздің бөлімшенің барлық мүшелері арасында міндетті түрде бөлісетін боламыз.
Біз жасөспірімдер туралы айтып отырғандықтан, сұрақ. Адам Postgres-те бірінші міндеттеме жасауды шешті. Ол бірінші міндеттемені жасау үшін не істеу керек?
Бұл қызықты сұрақ: «Неден бастау керек?» Әдетте ядродағы бір нәрседен бастау өте қиын. Мысалы, Postgres-те орындалатын істер тізімі бар. Бірақ, шын мәнінде, бұл олардың тырысқандары, бірақ сәтсіздігінің парағы. Бұл күрделі заттар. Әдетте сіз экожүйеде кейбір утилиталарды, жақсартуға болатын кейбір кеңейтімдерді таба аласыз, олар ядро әзірлеушілерінің назарын азырақ тартады. Және, сәйкесінше, онда өсу үшін көбірек нүктелер бар. Google Summer of Code бағдарламасында жыл сайын postgres қауымдастығы шешуге болатын көптеген әртүрлі тақырыптарды ұсынады. Биыл бізде үш студент болды деп ойлаймын. Біреуі тіпті WAL-G-де Яндекс үшін маңызды тақырыптарды жазды. Greenplum-те барлығы Postgres қауымдастығына қарағанда оңайырақ, өйткені Greenplum хакерлері тарту сұрауларына өте жақсы қарайды және бірден қарай бастайды. Postgres-ке патч жіберу - бұл бірнеше ай, бірақ Greenplum бір күнде келіп, не істегеніңізді көреді. Тағы бір нәрсе, Greenplum қазіргі мәселелерді шешуі керек. Greenplum кеңінен қолданылмайды, сондықтан мәселеңізді табу өте қиын. Ең алдымен, біз проблемаларды шешуіміз керек, әрине.
Ақпарат көзі: www.habr.com