Олар өмірдегі барлық нәрсені кем дегенде бір рет сынап көруге тұрарлық дейді. Ал егер сіз реляциялық ДҚБЖ-мен жұмыс істеуге дағдыланған болсаңыз, онда NoSQL-мен тәжірибеде танысқан жөн, ең алдымен, жалпы даму үшін. Қазір бұл технологияның қарқынды дамуына байланысты бұл тақырып бойынша көптеген қарама-қайшы пікірлер мен қызу пікірталастар бар, бұл әсіресе қызығушылықты арттырады.
Егер сіз осы даулардың барлығының мәніне үңілсеңіз, олардың дұрыс емес көзқарастан туындайтынын көруге болады. NoSQL дерекқорларын дәл қажет жерде пайдаланатындар қанағаттанады және осы шешімнің барлық артықшылықтарын алады. Ал бұл технологияны мүлде қолдануға болмайтын панацея ретінде пайдаланатын экспериментаторлар айтарлықтай пайдасыз реляциялық деректер базасының күшті жақтарынан айырылып, көңілдері қалды.
Мен сізге Кассандра ДҚБЖ негізіндегі шешімді енгізудегі тәжірибеміз туралы айтып беремін: біз немен бетпе-бет келдік, қиын жағдайлардан қалай шықтық, NoSQL пайдаланудан пайда ала алдық па және қайда қосымша күш/қаражат салу керек еді. .
Бастапқы міндет - қандай да бір жад түріндегі қоңырауларды жазатын жүйені құру.
Жүйенің жұмыс принципі келесідей. Кіріс қоңыраудың құрылымын сипаттайтын белгілі бір құрылымы бар файлдарды қамтиды. Содан кейін қолданба осы құрылымның сәйкес бағандарда сақталуын қамтамасыз етеді. Болашақта сақталған қоңыраулар абоненттер үшін трафикті тұтыну туралы ақпаратты көрсету үшін пайдаланылады (ақылар, қоңыраулар, теңгерім тарихы).
Неліктен олардың Кассандраны таңдағаны түсінікті - ол пулемет сияқты жазады, оңай масштабталады және ақауларға төзімді.
Демек, бұл бізге тәжірибе берді
Иә, сәтсіз түйін трагедия емес. Бұл Кассандраның қателіктерге төзімділігінің мәні. Бірақ түйін тірі болуы мүмкін және сонымен бірге өнімділікте зардап шегеді. Белгілі болғандай, бұл бүкіл кластердің жұмысына бірден әсер етеді.
Oracle сізді шектеулерімен құтқарған жерде Кассандра сізді қорғамайды. Ал егер өтінім авторы мұны алдын ала түсінбесе, Кассандраға келген дубль түпнұсқадан жаман емес. Ол келгеннен кейін біз оны саламыз.
IB қораптан шыққан тегін Кассандраны қатты ұнатпады: Пайдаланушы әрекеттерін тіркеу, құқықтарды саралау жоқ. Қоңыраулар туралы ақпарат жеке деректер болып саналады, яғни оны кез келген жолмен сұрау/өзгерту әрекеттері кейіннен тексеру мүмкіндігімен тіркелуі керек. Сондай-ақ, әртүрлі пайдаланушылар үшін әртүрлі деңгейдегі құқықтарды бөлу қажеттілігін білуіңіз керек. Қарапайым операция инженері және барлық пернелер кеңістігін еркін жоя алатын супер әкімші - әртүрлі рөлдер, әртүрлі жауапкершіліктер және құзыреттер. Қол жеткізу құқықтарының мұндай саралануынсыз деректердің құндылығы мен тұтастығы КЕЗ КЕЛГЕН сәйкестік деңгейіне қарағанда тезірек күмән тудырады.
Біз қоңыраулар күрделі талдауды да, әртүрлі жағдайлар үшін мерзімді іріктеуді де қажет ететінін ескермедік. Таңдалған жазбалар жойылып, қайта жазылуы керек болғандықтан (тапсырманың бөлігі ретінде деректер бастапқыда біздің циклімізге қате енгізілген кезде деректерді жаңарту процесін қолдауымыз керек), Кассандра бұл жерде біздің досымыз емес. Кассандра шошқа банкіне ұқсайды - заттарды салуға ыңғайлы, бірақ сіз оған сене алмайсыз.
Деректерді сынақ аймақтарына тасымалдау кезінде мәселеге тап болдық (сынақтағы 5 түйін және бітіру кешіндегі 20 түйін). Бұл жағдайда үйіндіні пайдалану мүмкін емес.
Кассандраға жазылған қолданбаның деректер схемасын жаңарту мәселесі. Кері қайтару көптеген құлпытастарды тудырады, бұл болжанбайтын жолдармен өнімділіктің жоғалуына әкелуі мүмкін.. Кассандра жазу үшін оңтайландырылған және жазу алдында көп ойланбайды.Онда бар деректермен кез келген операция да жазба болып табылады. Яғни, қажетсізді жою арқылы біз одан да көп жазбаларды шығарамыз және олардың кейбіреулері ғана құлпытастармен белгіленетін болады.
Енгізу кезінде күту уақыты. Кассандра жазбада әдемі, бірақ кейде кіріс ағыны оны айтарлықтай таң қалдырады. Бұл қолданба қандай да бір себептермен кірістірілмейтін бірнеше жазбаларды айналдыра бастағанда орын алады. Бізге gc.log, жүйелік және баяу сұраулар үшін жөндеу журналдарын бақылайтын, нығыздауды күтудегі көрсеткіштерді бақылайтын нақты DBA қажет болады.
Кластердегі бірнеше деректер орталықтары. Қайдан оқып, қайдан жазу керек?
Мүмкін оқу мен жазуға бөлінген шығар? Егер солай болса, жазуға немесе оқуға арналған қосымшаға жақынырақ DC болуы керек пе? Егер біз дұрыс емес консистенция деңгейін таңдасақ, нағыз бөлінген миға тап болмаймыз ба? Көптеген сұрақтар, көптеген белгісіз параметрлер, сіз шынымен айналысқыңыз келетін мүмкіндіктер бар.
Біз қалай шештік
Түйіннің батып кетуіне жол бермеу үшін SWAP өшірілді. Ал енді, егер жад жеткіліксіз болса, түйін төмен түсіп, үлкен gc үзілістерін жасамауы керек.
Сонымен, біз енді дерекқордағы логикаға сенбейміз. Қолданбаларды әзірлеушілер өздерін қайта оқытады және өздерінің кодтарында сақтық шараларын белсенді түрде қолдана бастайды. Деректерді сақтау мен өңдеудің мінсіз анық бөлінуі.
Біз DataStax-тен қолдау сатып алдық. Қорапты Кассандраның дамуы қазірдің өзінде тоқтатылды (соңғы тапсырма 2018 жылдың ақпанында болды). Сонымен бірге, Datastax бар IP шешімдері үшін тамаша сервисті және көптеген өзгертілген және бейімделген шешімдерді ұсынады.
Сондай-ақ Кассандра таңдау сұраулары үшін өте ыңғайлы емес екенін атап өткім келеді. Әрине, CQL - бұл пайдаланушылар үшін үлкен қадам (Trift-пен салыстырғанда). Бірақ егер сізде осындай ыңғайлы қосылыстарға, кез келген өріс бойынша тегін сүзгілеуге және сұрауларды оңтайландыру мүмкіндіктеріне үйренген тұтас бөлімдер болса және бұл бөлімдер шағымдар мен жазатайым оқиғаларды шешу үшін жұмыс істеп жатса, Кассандрадағы шешім оларға дұшпандық және ақымақ болып көрінеді. Әріптестеріміз үлгілерді қалай жасау керектігін шеше бастадық.
Біз екі нұсқаны қарастырдық.Бірінші нұсқада біз қоңырауларды тек C* тілінде емес, сонымен қатар мұрағатталған Oracle деректер базасында жазамыз. Тек, C*-тен айырмашылығы, бұл дерекқор ағымдағы айдағы қоңырауларды ғана сақтайды (қайта зарядтау үшін қоңырауларды сақтау тереңдігі жеткілікті). Мұнда біз бірден келесі мәселені көрдік: егер біз синхронды түрде жазсақ, онда біз жылдам кірістірумен байланысты C* тілінің барлық артықшылықтарын жоғалтамыз; егер асинхронды түрде жазсақ, барлық қажетті қоңыраулардың Oracle-ға мүлде енетініне кепілдік жоқ. Бір плюс болды, бірақ үлкені: жұмыс істеу үшін бұрынғыдай таныс PL/SQL Developer қалады, яғни біз іс жүзінде «Фасад» үлгісін жүзеге асырдық.Баламалы нұсқа. Біз C*-дан қоңырауларды түсіретін, Oracle-дағы сәйкес кестелерден кейбір деректерді байыту үшін алатын, алынған үлгілерді біріктіретін және бізге нәтиже беретін механизмді енгіземіз, біз оны кейін қандай да бір жолмен қолданамыз (қайта ораламыз, қайталаймыз, талдаймыз, таңдаймыз). Кемшіліктері: процесс өте көп сатылы, сонымен қатар операциялық қызметкерлер үшін интерфейс жоқ.
Соңында біз екінші нұсқаға тоқтадық. Apache Spark әртүрлі банкалардан үлгі алу үшін пайдаланылды. Механизмнің мәні Java кодына дейін қысқартылды, ол көрсетілген кілттерді (абонент, қоңырау шалу уақыты - бөлім пернелері) С*-дан деректерді, сондай-ақ кез келген басқа дерекқордан байыту үшін қажетті деректерді шығарады. Осыдан кейін ол оларды жадында біріктіреді және нәтижені кестеде көрсетеді. Біз ұшқынның үстіне веб-бет сыздық және ол өте қолайлы болып шықты.
Өнеркәсіптік сынақ деректерін жаңарту мәселесін шешу кезінде біз тағы да бірнеше шешімдерді қарастырдық. Sstloader арқылы тасымалдау және сынақ аймағындағы кластерді екі бөлікке бөлу опциясы, олардың әрқайсысы кезекпен жарнамалық кластермен бір кластерге жатады, осылайша оның көмегімен қуатталады. Тестті жаңарту кезінде оларды ауыстыру жоспарланды: сынақта жұмыс істеген бөлік тазартылып, өндіріске енгізіледі, ал екіншісі деректермен бөлек жұмыс істей бастайды. Дегенмен, қайталап ойланғаннан кейін, біз тасымалдауға тұрарлық деректерді ұтымдырақ бағаладық және қоңыраулардың өзі сынақтар үшін сәйкес келмейтін, қажет болған жағдайда тез жасалатын объект екенін және бұл жарнамалық деректер жиынтығының жіберу үшін мәні жоқ екенін түсіндік. сынақ. Жылжытуға тұрарлық бірнеше сақтау нысандары бар, бірақ бұл өте ауыр емес, бірнеше кестелер. Сондықтан біз шешім ретінде, Spark қайтадан көмекке келді, оның көмегімен біз кестелер арасында деректерді тасымалдауға арналған сценарийді, prom-test жазып, белсенді пайдалана бастадық.
Біздің ағымдағы орналастыру саясатымыз кері қайтарусыз жұмыс істеуге мүмкіндік береді. Науқанның алдында міндетті тестілеу өткізіледі, онда қателік соншалықты қымбат емес. Сәтсіздік жағдайында сіз әрқашан істер кеңістігін тастап, бүкіл схеманы басынан айналдыра аласыз.
Кассандраның үздіксіз қолжетімділігін қамтамасыз ету үшін оған ғана емес, сізге dba қажет. Қолданбамен жұмыс істейтін әрбір адам ағымдағы жағдайды қайда және қалай қарау керектігін және проблемаларды уақтылы диагностикалауды түсінуі керек. Ол үшін біз DataStax OpsCenter (жұмыс жүктемелерін басқару және бақылау), Cassandra Driver жүйесінің көрсеткіштерін (С* тіліне жазу күту уақытының саны, С*-тан оқуға арналған күту уақытының саны, максималды кідіріс және т.б.) белсенді түрде қолданамыз, жұмысты бақылаймыз. қолданбаның өзі, Кассандрамен жұмыс істейді.
Алдыңғы сұрақты ойластырған кезде, біз негізгі тәуекеліміздің қай жерде болуы мүмкін екенін түсіндік. Бұл бірнеше тәуелсіз сұраулардан деректерді сақтау орнына көрсететін деректерді көрсету пішіндері. Осылайша біз мүлдем сәйкес келмейтін ақпаратты ала аламыз. Бірақ егер біз тек бір деректер орталығымен жұмыс жасасақ, бұл мәселе дәл солай өзекті болар еді. Сондықтан мұнда ең ақылға қонымды нәрсе, әрине, деректердің бір уақыт аралығында алынуын қамтамасыз ететін үшінші тарап қолданбасында деректерді оқуға арналған пакеттік функцияны жасау. Өнімділік тұрғысынан оқу мен жазуға бөлуге келетін болсақ, бұл жерде біз ДК арасындағы байланыстың аздап жоғалуымен бір-біріне мүлдем сәйкес келмейтін екі кластер болуы мүмкін деген қауіппен тоқтадық.
Нәтижесінде, әзірге EACH_QUORUM жазу үшін тұрақтылық деңгейінде тоқталды, оқу үшін - LOCAL_QUORUM
Қысқаша әсерлер мен қорытындылар
Алынған шешімді операциялық қамтамасыз ету және одан әрі даму перспективалары тұрғысынан бағалау үшін біз мұндай әзірлеуді тағы қай жерде қолдануға болатыны туралы ойлануды шештік.
Бірден, содан кейін «Қалай болғанда төлеу» (ақпаратты C* тіліне жүктейміз, Spark сценарийлері арқылы есептеу), аумақтар бойынша біріктіру арқылы шағымдарды есепке алу, рөлдерді сақтау және рөлге негізделген пайдаланушының кіру құқықтарын есептеу сияқты бағдарламалар үшін деректерді бағалау матрица.
Көріп отырғаныңыздай, репертуар кең және алуан түрлі. Ал егер біз NoSQL қолдаушылары/қарсыластары лагерін таңдасақ, онда біз қолдаушыларға қосыламыз, өйткені біз өз артықшылықтарымызды алдық және дәл біз күткен жерде.
Тіпті «Кассандра» опциясы жүйедегі деректерді көбейту мәселесін мүлдем ауыртпалықсыз шеше отырып, нақты уақыт режимінде көлденең масштабтауға мүмкіндік береді. Біз шақыру агрегаттарын есептеудің өте жоғары жүктеме механизмін бөлек схемаға жылжыта алдық, сонымен қатар дерекқордың өзінде реттелетін тапсырмалар мен нысандарды жазудың жаман тәжірибесінен арылтып, қолданба схемасы мен логикасын бөлдік. Біз таңдау және конфигурациялау, жылдамдату мүмкіндігін алдық, қайсысында есептеулер жүргіземіз және қайсысына деректерді жазамыз, біз жеке түйіндердің де, жалпы тұрақты токтың да апаттарынан сақтандық.
Архитектурамызды жаңа жобаларға қолдана отырып және біраз тәжірибеге ие бола отырып, мен жоғарыда сипатталған нюанстарды дереу ескергім келеді және кейбір қателіктерге жол бермей, бастапқыда болдырмауға болмайтын өткір бұрыштарды тегістегім келеді.
Мысалы, Кассандраның жаңартуларын уақтылы қадағалаңызөйткені бізде кездесетін мәселелердің біразы бұрыннан белгілі болды және шешілді.
Дерекқордың өзін де, Spark да бір түйіндерге қоймаңыз (немесе рұқсат етілген ресурстарды пайдалану көлеміне қатаң бөліңіз), өйткені Spark күтілгеннен көп ОП жей алады және біз тізімнен №1 мәселені тез аламыз.
Жобаны тестілеу кезеңінде мониторинг пен операциялық құзыреттілігін арттыру. Бастапқыда, мүмкіндігінше біздің шешіміміздің барлық әлеуетті тұтынушыларын ескеріңіз, себебі бұл дерекқор құрылымы ақыр соңында тәуелді болады.
Ықтимал оңтайландыру үшін алынған тізбекті бірнеше рет бұраңыз. Қай өрістерді сериялауға болатынын таңдаңыз. Неғұрлым дұрыс және оңтайлы есепке алу үшін қандай қосымша кестелер жасау керектігін түсініңіз, содан кейін сұраныс бойынша қажетті ақпаратты беріңіз (мысалы, біз бірдей деректерді әртүрлі кестелерде сақтай аламыз деп есептей отырып, сәйкес әртүрлі бөлулерді ескере отырып әртүрлі критерийлер, біз оқу сұраулары үшін CPU уақытын айтарлықтай үнемдей аламыз).
Жаман емес TTL қосуды және ескірген деректерді тазалауды дереу қамтамасыз етіңіз.
Кассандрадан деректерді жүктеп алу кезінде Қолданба логикасы FETCH принципі бойынша жұмыс істеуі керек, осылайша барлық жолдар бірден жадқа жүктелмейді, бірақ пакеттермен таңдалады.
Жобаны сипатталған шешімге көшірмес бұрын ұсынылады апаттық сынақтар сериясын жүргізу арқылы жүйенің ақауларға төзімділігін тексеріңіз, мысалы, бір деректер орталығында деректердің жоғалуы, белгілі бір уақыт ішінде бүлінген деректерді қалпына келтіру, деректер орталықтары арасындағы желінің үзілуі. Мұндай сынақтар ұсынылған архитектураның оң және теріс жақтарын бағалауға мүмкіндік беріп қана қоймайды, сонымен қатар оларды жүргізетін инженерлерге жақсы қыздыру тәжірибесін береді және жүйенің ақаулары өндірісте қайталанса, алынған дағды артық болмайды.
Егер біз маңызды ақпаратпен жұмыс істейтін болсақ (мысалы, есепшотқа арналған деректер, абоненттік қарызды есептеу), онда ДҚБЖ ерекшеліктеріне байланысты туындайтын тәуекелдерді азайтатын құралдарға да назар аударған жөн. Мысалы, түйінді синхрондау утилитасын (Datastax) пайдаланыңыз, оны пайдаланудың оңтайлы стратегиясын реттеңіз. дәйектілік үшін Кассандраға шамадан тыс жүктеме жасамаңыз және оны белгілі бір кезеңдегі белгілі бір кестелер үшін ғана пайдаланыңыз.
Алты айлық өмірден кейін Кассандрамен не болады? Жалпы, шешімін таппаған мәселе жоқ. Біз сондай-ақ ауыр апаттарға немесе деректердің жоғалуына жол бермедік. Иә, біз бұрын пайда болмаған кейбір мәселелерді өтеу туралы ойлануымыз керек еді, бірақ ақыр соңында бұл біздің архитектуралық шешімімізді бұлыңғырлаған жоқ. Егер сіз жаңа нәрсені көргіңіз келсе және қорықпасаңыз және сонымен бірге тым көңілсіз қалғыңыз келмесе, ештеңе тегін емес екеніне дайын болыңыз. Сізге ескі шешімге қарағанда көбірек түсінуге, құжаттаманы зерделеуге және өзіңіздің жеке тырмаңызды жинауға тура келеді және ешқандай теория сізді қандай рейк күтіп тұрғанын алдын ала айтпайды.
Ақпарат көзі: www.habr.com