Бәріңе сәлем! Менің атым Голов Николай. Бұрын мен Avito-да жұмыс істедім және алты жыл бойы Data Platform-ты басқардым, яғни мен барлық деректер базаларында жұмыс істедім: аналитикалық (Vertica, ClickHouse), ағындық және OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Осы уақыт ішінде мен көптеген деректер базаларымен айналыстым - өте әртүрлі және әдеттен тыс және оларды пайдаланудың стандартты емес жағдайларымен.
Мен қазір ManyChat-та жұмыс істеймін. Негізінде бұл стартап – жаңа, өршіл және қарқынды дамып келе жатқан. Мен компанияға алғаш кірген кезде классикалық сұрақ туындады: «Қазір жас стартап ДҚБЖ және деректер базасы нарығынан не алуы керек?»
Бұл мақалада менің баяндамама негізделген , Мен бұл сұраққа жауап беремін. Есептің бейне нұсқасы мына сайтта орналасқан .
Жалпыға белгілі дерекқорлар 2020
2020 жыл болды, мен жан-жаққа қарасам, мәліметтер базасының үш түрін көрдім.
Бірінші түрі - классикалық OLTP дерекқорлары: PostgreSQL, SQL Server, Oracle, MySQL. Олар ұзақ уақыт бұрын жазылған, бірақ әлі де өзекті, өйткені олар әзірлеушілер қауымдастығына өте жақсы таныс.
Екінші түрі негіздері «нөлден». Олар SQL, дәстүрлі құрылымдар мен ACID-ден бас тартып, кірістірілген үзінділерді және басқа да тартымды мүмкіндіктерді қосу арқылы классикалық үлгілерден бас тартуға тырысты. Мысалы, бұл Cassandra, MongoDB, Redis немесе Tarantool. Бұл шешімдердің барлығы нарыққа түбегейлі жаңа нәрсені ұсынғысы келді және өз орнын алды, өйткені олар белгілі бір тапсырмалар үшін өте ыңғайлы болды. Мен бұл дерекқорларды NOSQL терминімен белгілеймін.
«Нөлдер» аяқталды, біз NOSQL дерекқорларына үйрендік және әлем, менің көзқарасым бойынша, келесі қадамды жасады - басқарылатын мәліметтер базасы. Бұл дерекқорлар классикалық OLTP дерекқорларымен немесе жаңа NoSQL деректерімен бірдей ядроға ие. Бірақ оларға DBA және DevOps қажет емес және бұлттарда басқарылатын жабдықта жұмыс істейді. Әзірлеуші үшін бұл бір жерде жұмыс істейтін «жай база», бірақ оның серверде қалай орнатылғаны, серверді кім конфигурациялағаны және оны кім жаңартып жатқаны ешкімді қызықтырмайды.
Мұндай мәліметтер базасының мысалдары:
- AWS RDS — PostgreSQL/MySQL үшін басқарылатын қаптама.
- DynamoDB — Redis және MongoDB сияқты құжатқа негізделген дерекқордың AWS аналогы.
- Amazon Redshift – басқарылатын аналитикалық дерекқор.
Бұл негізінен ескі дерекқорлар, бірақ аппараттық құралдармен жұмыс істеуді қажет етпейтін басқарылатын ортада жасалған.
Ескерту. Мысалдар AWS ортасы үшін алынған, бірақ олардың аналогтары Microsoft Azure, Google Cloud немесе Yandex.Cloud жүйесінде де бар.
Бұл туралы не жаңалық бар? 2020 жылы мұның ешқайсысы жоқ.
Серверсіз тұжырымдама
2020 жылы нарықтағы шын мәнінде жаңалық - серверсіз немесе серверсіз шешімдер.
Мен мұның нені білдіретінін кәдімгі қызмет немесе серверлік қолданба мысалында түсіндіруге тырысамын.
Кәдімгі сервер қолданбасын қолдану үшін біз серверді сатып аламыз немесе жалға аламыз, оған кодты көшіреміз, соңғы нүктені сыртта жариялаймыз және жалдау, электр қуаты және деректер орталығының қызметтеріне тұрақты түрде төлейміз. Бұл стандартты схема.
Басқа амал бар ма? Серверсіз қызметтермен сіз жасай аласыз.
Бұл тәсілдің басты мақсаты: сервер жоқ, бұлтта виртуалды дананы жалға алу да жоқ. Қызметті қолдану үшін кодты (функцияларды) репозиторийге көшіріп, оны соңғы нүктеге жариялаңыз. Содан кейін біз бұл функцияға әрбір қоңырау үшін төлейміз, ол орындалатын аппараттық құралды мүлдем елемейміз.
Мен бұл тәсілді суреттермен көрсетуге тырысамын.
Классикалық орналастыру. Бізде белгілі бір жүктемесі бар қызмет бар. Біз екі дананы көтереміз: физикалық серверлер немесе AWS ішіндегі даналар. Сыртқы сұраулар осы даналарға жіберіледі және сол жерде өңделеді.
Суретте көріп отырғаныңыздай, серверлер бірдей жойылмайды. Біреуі 100% пайдаланылды, екі сұрау бар, ал біреуі небәрі 50% - жартылай бос. Егер үш емес, 30 сұраныс келсе, бүкіл жүйе жүктемені көтере алмайды және баяулай бастайды.
Серверсіз орналастыру. Серверсіз ортада мұндай қызметтің даналары немесе серверлері болмайды. Қыздырылған ресурстардың белгілі бір пулы бар - функционалды коды бар шағын дайындалған Docker контейнерлері. Жүйе сыртқы сұрауларды қабылдайды және олардың әрқайсысы үшін серверсіз құрылым коды бар шағын контейнерді көтереді: ол осы нақты сұранысты өңдейді және контейнерді өлтіреді.
Бір сұраныс – бір контейнер көтерілді, 1000 сұраныс – 1000 контейнер. Ал аппараттық серверлерде орналастыру қазірдің өзінде бұлттық провайдердің жұмысы болып табылады. Ол серверсіз құрылым арқылы толығымен жасырылған. Бұл тұжырымдамада біз әрбір қоңырау үшін төлейміз. Мысалы, күніне бір қоңырау келді – бір қоңырауға төледік, минутына миллион келді – миллионға төледік. Немесе бір секундта бұл да болады.
Серверсіз функцияны жариялау тұжырымдамасы азаматтығы жоқ қызмет үшін қолайлы. Егер сізге (мемлекеттік) толық қызмет қажет болса, онда біз қызметке дерекқор қосамыз. Бұл жағдайда күймен жұмыс істеуге келгенде, әрбір толық функция дерекқордан жай жазады және оқиды. Сонымен қатар, мақаланың басында сипатталған үш түрдің кез келгенінің дерекқорынан.
Барлық осы дерекқорлардың ортақ шектеуі қандай? Бұл үнемі пайдаланылатын бұлттың немесе аппараттық сервердің (немесе бірнеше серверлердің) шығындары. Классикалық немесе басқарылатын дерекқорды қолданамыз ба, бізде Devops және әкімші бар ма, жоқ па, маңызды емес, біз әлі күнге дейін аппараттық құралдарды, электр энергиясын және деректер орталығын тәулік бойы жалға алу үшін төлейміз. Егер бізде классикалық база болса, біз қожайын мен құл үшін төлейміз. Егер бұл жоғары жүктелген ортақ дерекқор болса, біз 24, 7 немесе 10 сервер үшін төлейміз және біз үнемі төлейміз.
Шығындар құрылымында тұрақты сақталған серверлердің болуы бұрын қажетті зұлымдық ретінде қабылданған. Кәдімгі дерекқорлардың басқа да қиындықтары бар, мысалы, қосылымдар санының шектеулері, масштабтау шектеулері, гео-таратылған консенсус – оларды қандай да бір түрде белгілі бір дерекқорларда шешуге болады, бірақ барлығы бірден емес және идеалды емес.
Серверсіз мәліметтер базасы – теория
2020 жылғы сұрақ: дерекқорды серверсіз де жасауға болады ма? Барлығы серверсіз сервер туралы естіген... дерекқорды серверсіз етіп көрейікші?
Бұл біртүрлі естіледі, себебі дерекқор толыққанды қызмет, серверсіз инфрақұрылым үшін өте қолайлы емес. Бұл ретте деректер қорының күйі өте үлкен: гигабайттар, терабайттар, ал аналитикалық деректер қорларында тіпті петабайттар. Оны жеңіл Docker контейнерлерінде көтеру оңай емес.
Екінші жағынан, барлық дерлік қазіргі дерекқорлар логика мен компоненттердің үлкен көлемін қамтиды: транзакциялар, тұтастықты үйлестіру, процедуралар, реляциялық тәуелділіктер және көптеген логика. Көптеген дерекқор логикасы үшін шағын күй жеткілікті. Гигабайттар мен терабайттарды сұрауларды тікелей орындауға қатысатын дерекқор логикасының аз ғана бөлігі ғана пайдаланады.
Тиісінше, идея мынада: егер логиканың бір бөлігі азаматтығы жоқ орындауға мүмкіндік берсе, неге базаны күй және азаматтығы жоқ бөліктерге бөлуге болмайды.
OLAP шешімдері үшін серверсіз
Тәжірибелік мысалдарды пайдалану арқылы дерекқорды күй және азаматтығы жоқ бөліктерге кесу қалай көрінетінін көрейік.
Мысалы, бізде аналитикалық база бар: сыртқы деректер (сол жақтағы қызыл цилиндр), деректерді дерекқорға жүктейтін ETL процесі және дерекқорға SQL сұрауларын жіберетін талдаушы. Бұл деректер қоймасының классикалық жұмыс схемасы.
Бұл схемада ETL шартты түрде бір рет орындалады. Содан кейін сұрауларды жіберуге болатын нәрсе болуы үшін ETL толтырылған деректермен дерекқор жұмыс істейтін серверлерге үнемі ақы төлеу керек.
AWS Athena Serverless жүйесінде енгізілген балама тәсілді қарастырайық. Жүктелген деректер сақталатын тұрақты арнайы жабдық жоқ. Бұның орнына:
- Пайдаланушы Athena жүйесіне SQL сұрауын жібереді. Athena оңтайландырғышы SQL сұрауын талдайды және сұрауды орындау үшін қажетті нақты деректер үшін метадеректер қоймасынан (Метадеректер) іздейді.
- Оңтайландырушы жиналған деректерге сүйене отырып, қажетті деректерді сыртқы көздерден уақытша сақтауға (уақытша дерекқорға) жүктейді.
- Пайдаланушыдан SQL сұрауы уақытша жадта орындалады және нәтиже пайдаланушыға қайтарылады.
- Уақытша сақтау орны тазартылып, ресурстар босатылады.
Бұл архитектурада біз тек сұранысты орындау процесі үшін төлейміз. Сұраныс жоқ - шығындар жоқ.
Бұл жұмыс тәсілі және тек Athena Serverless жүйесінде ғана емес, сонымен қатар Redshift Spectrum-да (AWS-де) жүзеге асырылады.
Athena мысалы серверсіз дерекқордың ондаған және жүздеген терабайт деректері бар нақты сұрауларда жұмыс істейтінін көрсетеді. Жүздеген терабайт жүздеген серверлерді қажет етеді, бірақ біз олар үшін ақы төлеудің қажеті жоқ - біз сұраулар үшін төлейміз. Әрбір сұраудың жылдамдығы Vertica сияқты мамандандырылған аналитикалық дерекқорлармен салыстырғанда (өте) төмен, бірақ біз тоқтап тұрған уақыт үшін төлем жасамаймыз.
Мұндай дерекқор сирек кездесетін аналитикалық арнайы сұраулар үшін қолданылады. Мысалы, біз гипотезаны кейбір үлкен деректер көлеміне сынауға шешім қабылдағанда. Афина бұл жағдайлар үшін өте қолайлы. Тұрақты сұраныстар үшін мұндай жүйе қымбатқа түседі. Бұл жағдайда деректерді кейбір арнайы шешімде кэштеңіз.
OLTP шешімдері үшін серверсіз
Алдыңғы мысал OLAP (аналитикалық) тапсырмаларын қарастырды. Енді OLTP тапсырмаларын қарастырайық.
Кеңейтілетін PostgreSQL немесе MySQL-ті елестетейік. Ең аз ресурстармен тұрақты басқарылатын PostgreSQL немесе MySQL данасын шығарайық. Дана көбірек жүктеме алған кезде, біз оқу жүктемесінің бір бөлігін тарататын қосымша көшірмелерді қосамыз. Егер сұраулар немесе жүктемелер болмаса, көшірмелерді өшіреміз. Бірінші инстанция - шебер, ал қалғандары - көшірмелер.
Бұл идея Aurora Serverless AWS деп аталатын дерекқорда жүзеге асырылады. Принцип қарапайым: сыртқы қосымшалардан келген сұрауларды прокси флот қабылдайды. Жүктеменің артқанын көріп, ол алдын ала қыздырылған минималды инстанциялардан есептеу ресурстарын бөледі - қосылым мүмкіндігінше жылдам орындалады. Даналарды өшіру дәл осылай орын алады.
Аврора ішінде Aurora сыйымдылық бірлігі, ACU тұжырымдамасы бар. Бұл (шартты түрде) дана (сервер). Әрбір нақты ACU мастер немесе құл болуы мүмкін. Әрбір сыйымдылық бірлігінде өзінің жедел жады, процессоры және минималды дискісі бар. Тиісінше, біреуі шебер, қалғандары тек оқылатын көшірмелер.
Осы жұмыс істеп тұрған Аврора сыйымдылық бірліктерінің саны конфигурацияланатын параметр болып табылады. Ең аз сан бір немесе нөлге тең болуы мүмкін (бұл жағдайда сұраулар болмаса, дерекқор жұмыс істемейді).
Негіз сұрауларды қабылдағанда, прокси флоты жүйенің өнімділік ресурстарын арттыра отырып, Aurora CapacityUnits деңгейін көтереді. Ресурстарды ұлғайту және азайту мүмкіндігі жүйеге ресурстарды «жеңгелеуге» мүмкіндік береді: жеке ACU-ларды автоматты түрде көрсету (оларды жаңаларымен ауыстыру) және алынған ресурстарға барлық ағымдағы жаңартуларды шығару.
Aurora серверсіз негізі оқу жүктемесін масштабтай алады. Бірақ құжаттама бұл туралы тікелей айтпайды. Олар мульти-мастер көтере алатындай сезінуі мүмкін. Сиқыр жоқ.
Бұл дерекқор алдын ала болжауға болмайтын кіру мүмкіндігі бар жүйелерге үлкен ақша жұмсамау үшін өте қолайлы. Мысалы, MVP немесе маркетингтік визиттік сайттарды жасау кезінде біз әдетте тұрақты жүктемені күтпейміз. Тиісінше, қолжетімділік болмаса, біз даналар үшін төлемейміз. Күтпеген жүктеме пайда болғанда, мысалы, конференциядан немесе жарнамалық науқаннан кейін, сайтқа көптеген адамдар кіреді және жүктеме күрт артады, Aurora Serverless бұл жүктемені автоматты түрде қабылдайды және жетіспейтін ресурстарды (ACU) жылдам қосады. Содан кейін конференция өтеді, барлығы прототипті ұмытады, серверлер (ACU) қараңғыланады және шығындар нөлге дейін төмендейді - ыңғайлы.
Бұл шешім тұрақты жоғары жүктемеге жарамайды, себебі ол жазу жүктемесін масштабтамайды. Барлық осы қосылымдар мен ресурстарды ажырату «масштаб нүктесі» деп аталатын жерде орын алады - деректер базасын транзакция немесе уақытша кестелер қолдамайтын уақыт нүктесі. Мысалы, бір апта ішінде масштабтау нүктесі болмауы мүмкін және база бірдей ресурстарда жұмыс істейді және жай кеңейе немесе қысқара алмайды.
Ешқандай сиқыр жоқ - бұл қарапайым PostgreSQL. Бірақ машиналарды қосу және оларды ажырату процесі ішінара автоматтандырылған.
Дизайн бойынша серверсіз
Aurora Serverless — бұлт үшін қайта жазылған ескі дерекқор, серверсіздің кейбір артықшылықтарын пайдалану үшін. Енді мен сізге серверсіз тәсіл үшін бастапқыда бұлт үшін жазылған база туралы айтып беремін - дизайн бойынша серверсіз. Ол физикалық серверлерде жұмыс істейді деген болжамсыз бірден әзірленді.
Бұл негіз Snowflake деп аталады. Оның үш негізгі блогы бар.
Біріншісі - метадеректер блогы. Бұл қауіпсіздік, метадеректер, транзакциялар және сұрауларды оңтайландыру мәселелерін шешетін жылдам жад қызметі (сол жақтағы суретте көрсетілген).
Екінші блок - есептеулерге арналған виртуалды есептеу кластерлерінің жиынтығы (суретте көк шеңберлер жиынтығы бар).
Үшінші блок – S3 негізіндегі мәліметтерді сақтау жүйесі. S3 – бизнеске арналған өлшемсіз Dropbox сияқты AWS жүйесіндегі өлшемсіз нысанды сақтау.
Снежинканың қалай жұмыс істейтінін көрейік. Яғни, мәліметтер базасы бар, оған деректер жүктеледі, орындалатын сұраулар жоқ. Тиісінше, егер дерекқорға сұраныстар болмаса, біз жедел жадтағы метадеректер қызметін (бірінші блок) көтердік. Ал бізде S3 сақтау орны бар, онда кесте деректері сақталады, олар микробөлімдерге бөлінеді. Қарапайымдылық үшін: кестеде транзакциялар болса, онда микробөлімдер транзакция күндері болып табылады. Күн сайын бөлек микробөлім, бөлек файл. Ал деректер базасы осы режимде жұмыс істегенде, сіз тек деректер алатын орын үшін төлейсіз. Оның үстіне, бір орындық көрсеткіш өте төмен (әсіресе айтарлықтай қысуды ескере отырып). Метадеректер қызметі де тұрақты жұмыс істейді, бірақ сұрауларды оңтайландыру үшін сізге көп ресурстар қажет емес және қызметті ортақ бағдарламалық құрал деп санауға болады.
Енді пайдаланушы біздің дерекқорымызға келіп, SQL сұрауын жіберді деп елестетейік. SQL сұрауы өңдеу үшін бірден метадеректер қызметіне жіберіледі. Сәйкесінше, сұрауды алғаннан кейін бұл қызмет сұрауды, қол жетімді деректерді, пайдаланушы рұқсаттарын талдайды және егер бәрі жақсы болса, сұрауды өңдеу жоспарын жасайды.
Әрі қарай қызмет есептеу кластерін іске қосуды бастайды. Есептеу кластері – есептеулерді орындайтын серверлер кластері. Яғни, бұл 1 сервер, 2 сервер, 4, 8, 16, 32 - қалағаныңызша болуы мүмкін кластер. Сіз сұрау жібересіз және бұл кластерді іске қосу дереу басталады. Бұл шынымен секундты алады.
Содан кейін, кластер басталғаннан кейін сұрауыңызды өңдеуге қажет микробөлімдер S3 кластерінен көшіріледі. Яғни, SQL сұрауын орындау үшін бір кестеден екі бөлім және екіншісінен бір бөлім қажет деп елестетіп көрейік. Бұл жағдайда кластерге барлық кестелер толығымен емес, үш қажетті бөлім ғана көшіріледі. Міне, сондықтан, бәрі бір деректер орталығында орналасқан және өте жылдам арналар арқылы қосылғандықтан, бүкіл тасымалдау процесі өте жылдам жүреді: секундтарда, өте сирек, бірнеше минут ішінде, егер біз кейбір құбыжық сұраулар туралы айтпасақ . Сәйкесінше, микробөлімдер есептеу кластеріне көшіріледі және аяқталғаннан кейін осы есептеу кластерінде SQL сұрауы орындалады. Бұл сұраудың нәтижесі бір жол, бірнеше жол немесе кесте болуы мүмкін - олар оны жүктеп алуы, BI құралында көрсетуі немесе басқа жолмен пайдалануы үшін пайдаланушыға сырттан жіберіледі.
Әрбір SQL сұрауы бұрын жүктелген деректерден агрегаттарды оқып қана қоймай, сонымен қатар дерекқордағы жаңа деректерді жүктей/генерациялай алады. Яғни, бұл, мысалы, басқа кестеге жаңа жазбаларды кірістіретін сұрау болуы мүмкін, бұл есептеу кластерінде жаңа бөлімнің пайда болуына әкеледі, ол өз кезегінде автоматты түрде жалғыз S3 жадында сақталады.
Жоғарыда сипатталған сценарий, пайдаланушының келуінен бастап кластерді көтеруге, деректерді жүктеуге, сұрауларды орындауға, нәтижелерді алуға дейін көтерілген виртуалды есептеу кластерін, виртуалды қойманы пайдалану минуттары үшін ставка бойынша төленеді. Тариф AWS аймағына және кластер өлшеміне байланысты өзгереді, бірақ орташа есеппен сағатына бірнеше долларды құрайды. Төрт машинадан тұратын кластер екі станоктан тұратын кластерге қарағанда екі есе қымбат, ал сегіз машина кластері бұрынғысынша екі есе қымбат. Сұраныстардың күрделілігіне байланысты 16, 32 машинаның нұсқалары бар. Бірақ сіз кластер нақты жұмыс істеп тұрған минуттар үшін ғана төлейсіз, өйткені сұраулар болмаған кезде, сіз қолыңызды алып тастайсыз және 5-10 минут күткеннен кейін (конфигурацияланатын параметр) ол өздігінен өшеді, ресурстарды босатып, еркін болыңыз.
Толығымен шынайы сценарий - сұрау жіберген кезде кластер бір минутта пайда болады, салыстырмалы түрде айтқанда, ол тағы бір минутты есептейді, содан кейін өшіру үшін бес минут кетеді және сіз осы кластердің жеті минуттық жұмысы үшін төлейсіз және айлар мен жылдар бойы емес.
Бір пайдаланушы параметрінде Snowflake пайдалану арқылы сипатталған бірінші сценарий. Енді нақты сценарийге жақынырақ пайдаланушылар көп екенін елестетіп көрейік.
Біздің дерекқорымызды көптеген қарапайым аналитикалық SQL сұрауларымен үнемі бомбалайтын көптеген аналитиктер мен Tableau есептері бар делік.
Бұған қоса, бізде деректермен қорқынышты нәрселер жасауға тырысатын, ондаған терабайттармен жұмыс істейтін, миллиардтаған және триллиондаған деректер қатарын талдайтын өнертапқыш Data Scientists бар делік.
Жоғарыда сипатталған жұмыс жүктемесінің екі түрі үшін Snowflake әртүрлі қуаттағы бірнеше тәуелсіз есептеу кластерін көтеруге мүмкіндік береді. Сонымен қатар, бұл есептеу кластерлері дербес жұмыс істейді, бірақ жалпы тұрақты деректермен.
Жеңіл сұраулардың үлкен саны үшін әрқайсысы шамамен 2 машинадан тұратын 3-2 шағын кластерді көтеруге болады. Бұл әрекетті, басқалармен қатар, автоматты параметрлерді пайдалану арқылы жүзеге асыруға болады. Сондықтан сіз: «Қар ұшқыны, кішкене шоғыр көтеріңіз. Егер оған жүктеме белгілі бір параметрден жоғары болса, ұқсас екінші, үшінші көтеріңіз. Жүктеме басыла бастағанда, артықты өшіріңіз». Қанша аналитик келіп, есептерді қарай бастаса да, барлығында ресурстар жеткілікті.
Сонымен қатар, егер талдаушылар ұйықтап жатса және есептерге ешкім қарамаса, кластерлер толығымен қараңғы болуы мүмкін және сіз олар үшін төлеуді тоқтатасыз.
Сонымен қатар, ауыр сұраулар үшін (Data Scientists-тен) 32 машина үшін бір өте үлкен кластерді көтере аласыз. Бұл кластер сіздің үлкен сұрауыңыз орындалған минуттар мен сағаттар үшін ғана төленеді.
Жоғарыда сипатталған мүмкіндік тек 2 ғана емес, сонымен қатар жұмыс жүктемесінің одан да көп түрлерін кластерлерге бөлуге мүмкіндік береді (ETL, мониторинг, есепті материалдандыру,...).
Ақшақарды қорытындылайық. Негіз әдемі идея мен іске асыруды біріктіреді. ManyChat-та біз қолымызда бар барлық деректерді талдау үшін Snowflake пайдаланамыз. Бізде мысалдағыдай үш кластер жоқ, бірақ өлшемдері әртүрлі 5-тен 9-ға дейін. Бізде кәдімгі 16-станок, 2-станок, сондай-ақ кейбір тапсырмалар үшін өте кішкентай 1-машиналар бар. Олар жүктемені сәтті бөледі және көп нәрсені үнемдеуге мүмкіндік береді.
Дерекқор оқу және жазу жүктемесін сәтті масштабтайды. Бұл тек оқу жүктемесін көтерген сол «Аврорамен» салыстырғанда үлкен айырмашылық және үлкен серпіліс. Snowflake осы есептеу кластерлері арқылы жазу жұмысының көлемін ұлғайтуға мүмкіндік береді. Яғни, мен айтып өткенімдей, біз ManyChat-та бірнеше кластерлерді қолданамыз, шағын және супер-кіші кластерлер негізінен ETL үшін, деректерді жүктеу үшін қолданылады. Ал талдаушылар қазірдің өзінде орташа кластерлерде тұрады, олар ETL жүктемесіне мүлдем әсер етпейді, сондықтан олар өте жылдам жұмыс істейді.
Тиісінше, дерекқор OLAP тапсырмалары үшін өте қолайлы. Алайда, өкінішке орай, ол OLTP жұмыс жүктемелері үшін әлі қолданылмайды. Біріншіден, бұл деректер базасы бағаналы, оның барлық салдары бар. Екіншіден, әрбір сұраныс үшін қажет болған жағдайда есептеу кластерін көтеріп, оны деректермен толтыратын тәсілдің өзі, өкінішке орай, OLTP жүктемелері үшін әлі жеткілікті жылдам емес. OLAP тапсырмаларын күту секундтары қалыпты жағдай, бірақ OLTP тапсырмалары үшін бұл мүмкін емес; 100 мс жақсырақ немесе 10 мс одан да жақсырақ болар еді.
Нәтиже
Серверсіз дерекқор дерекқорды азаматтығы жоқ және күйі бар бөліктерге бөлу арқылы мүмкін болады. Жоғарыда келтірілген мысалдардың барлығында «Статистика» бөлігі, салыстырмалы түрде айтқанда, S3 ішінде микро бөлімдерді сақтайтынын және азаматтығы жоқ — оңтайландырушы екенін, метадеректермен жұмыс істейтінін, тәуелсіз жеңіл азаматтығы жоқ қызметтер ретінде көтерілуі мүмкін қауіпсіздік мәселелерін өңдейтінін байқаған боларсыз.
SQL сұрауларын орындау, сонымен қатар, Snowflake есептеу кластерлері сияқты серверсіз режимде пайда болатын, тек қажетті деректерді жүктеп, сұрауды орындап, «шығуға» болатын жеңіл күйдегі қызметтер ретінде қабылдануы мүмкін.
Серверсіз өндірістік деңгейдегі дерекқорлар қазірдің өзінде пайдалану үшін қол жетімді, олар жұмыс істейді. Бұл серверсіз дерекқорлар OLAP тапсырмаларын өңдеуге дайын. Өкінішке орай, OLTP тапсырмалары үшін олар нюанстармен қолданылады, өйткені шектеулер бар. Бір жағынан, бұл минус. Бірақ, екінші жағынан, бұл мүмкіндік. Мүмкін, оқырмандардың бірі Aurora шектеулерінсіз OLTP дерекқорын толығымен серверсіз ету жолын табады.
Сізге қызықты болды деп үміттенемін. Серверсіз - бұл болашақ :)
Ақпарат көзі: www.habr.com