Как да погледнем в очите на Касандра, без да загубим данни, стабилност и вяра в NoSQL

Смятат, че в живота всичко трябва да се опита поне веднъж. И ако сте свикнали да работите с релационни СУБД, то опознаването на NoSQL на практика определено ще е полезно поне за общо развитие. В момента, поради бурното развитие на тази технология, има много противоречиви мнения и горещи спорове по тази тема, което особено подхранва интереса.
Ако се вникне в същността на всички тези спорове, може да се види, че те произтичат от неправилен подход. Тези, които използват NoSQL бази наистина там, където са нужни, са доволни и получават всички ползи от решението. А експериментаторите, които разчитат на тази технология като панацея там, където тя не е приложима, изпитват разочарование, губейки силните страни на релационните бази без да придобият значителни преимущества.

Ще разкажа за нашия опит с внедряване на решение, основано на СУБД Cassandra: с какво се наложи да се сблъскаме, как се справяхме с трудните ситуации, успяхме ли да извлечем ползи от използването на NoSQL и къде се наложи да вложим допълнителни усилия/средства.
Исходната задача е изграждането на система, записваща повиквания в определено хранилище.

Принципът на действие на системата е следния. На входа постъпват файлове с определена структура, описваща структурата на повикването. След това приложението осигурява запазването на тази структура в съответните колони. Впоследствие запазените повиквания се използват – за показване на информация за потреблението на трафик за абонатите ( начисления, повиквания, история на баланса).

Защо избрахме Cassandra е напълно разбираемо - тя записва бързо, лесно е мащабируема и устойчива на отказ.

И така, ето какво ни дари опитът

Да, излязлата нода - не е трагедия. Във това се състои откажоустойчивостта на Cassandra. Но нода може да е активна и все пак да започне да се представя по-слабо. Както стана ясно, това веднага се отразява върху производителността на целия клъстер.

Cassandra не осигурява защита там, където Oracle спасяваше с ограниченията си. И ако авторът на приложението не е разбрал това предварително, то дублирането за Cassandra не е по-лошо от оригинала. Щом е дошло, значи ще го включим.

Безплатната Cassandra „из коробки” рязко не се понрави на ИБ: липсват логове на действията на потребителите, нямат ограничения на правата също. Информацията за повикванията се отнася до лични данни, което означава, че всички опити за тяхното искане/промяна трябва да бъдат регистрирани с възможност за последващ одит. Също така, трябва да осъзнаваме необходимостта от разделяне на правата на различни нива за различни потребители. Обикновеният инженер по експлоатация и супер администратор, който свободно може да изтрие целия keyspace – това са различни роли, различна отговорност и компетентност. Без такова разграничаване на правата на достъп стойността и целостта на данните веднага ще бъдат поставени под въпрос по-бързо, отколкото при ниво на консистентност ANY.

Не сме взели предвид, че за повикванията са необходими както сериозни анализи, така и периодични извадки при най-различни условия. Тъй като избраните записи след това се предполага, че ще бъдат изтривани и презаписвани (в рамките на задачата трябва да поддържаме процеса на актуализиране на данните при първоначално неправилно предоставени данни), то Кассандра тук не е наш съюзник. Кассандра, като касичка – удобно е да се вмъква, но не може да се изчислява в нея.

Сблъскахме се с проблема с прехвърлянето на данни в тестови зони (5 нода в теста срещу 20 в продукцията). В този случай не може да се използва дамп.

Проблема с актуализациите на схемата на данните на приложението, записващо в Кассандра. Откатът ще породи голямо количество надгробия, което по непредсказуем начин може да намали производителността.. Кассандра е оптимизирана за запис, и преди да запише, не мисли много. Всяка операция с съществуващи данни в нея – това също е запис. Тоест, като изтрием излишното, просто ще натрупаме още повече записи, и само част от тях ще бъдат обозначени с надгробия.

Таймаути при вмъкване. Кассандра е чудесна при запис, но понякога влизащият поток може да я озадачи съществено.. Това се случва, когато приложението започне да върти в кръг няколко записа, които не могат да бъдат вмъкнати по някаква причина. И ще ни е необходим напълно истински DBA, който да следи gc.log, логовете на системата и дебъг на предмет бавни запитвания, метрики за незавършена компакция.

Няколко датацентрове в клъстера. От къде да четем и къде да пишем?
Възможно ли е да се раздели на четене и писане? И ако да, то близо до приложението трябва ли да има DC за запис или за четене? И няма ли да имаме истински split brain, ако неправилно изберем нивото на съгласуваност? Много въпроси, много неизследвани настройки и възможности, които толкова искам да експериментирам.

Как решавахме

За да не се потопи нодата, изключихме SWAP. И сега, при недостиг на памет, нодата трябва да падне, а не да генерира големи gc паузи.

И така, вече не разчитаме на логиката в БД. Разработчиците на приложението сменят начина си на работа и започват активно да се подсигуряват в собствения си код. Идеално ясно разделение на съхранението и обработката на данни.

Купувахме поддръжка от DataStax. Коробочната Касандра вече не се разработва (последният комит е през февруари 2018 година). В същото време Datastax предлага отличен сервис и голямо количество доразвити и адаптирани решения за съществуващи ИС.

Още искам да подчертая, че Касандра не е много удобна за запитвания за избор. Разбира се, CQL е голяма крачка напред за потребителите (в сравнение с Trift). Но ако имате цели отдели, свикнали с така удобните джойнове, свободното филтриране по всяко поле и възможностите за оптимизиране на запитванията, и тези отдели работят за решаване на претенции и инциденти, то решението с Касандра ще им изглежда враждебно и глупаво. И започнахме да разглеждаме как нашите колеги да извършват изборки.

Разгледахме два варианта. В първия вариант записваме повиквания не само в С*, но и в архивната БД Oracle. Само че, за разлика от C*, в тази БД се съхраняват повиквания само за текущия месец (достатъчна дълбочина на съхранение на повикванията за случаи на повторна тарификация). Тук веднага се появи следният проблем: ако пишем синхронно, губим всичките предимства на С*, свързани с бързото вмъкване, а ако асинхронно – няма гаранция, че всички необходими повиквания изобщо ще попаднат в Oracle. Едно голямо предимство: за експлоатация остава същият познат PL/SQL Developer, т. е. практически осъществяваме патерна „Фасада“. Алтернативен вариант. Реализираме механизъм, който изнася повикванията от C*, извлича някакви данни за обогатяване от съответните таблици в Oracle, свързва получените извадки и ни предоставя получен резултат, който после някак използваме (откатываме, повторяваме, анализираме, възхищаваме се). Недостатъци: процесът се оказва доста многостъпков, а освен това, липсва интерфейс за служителите по експлоатация.

Крайната ни позиция все пак е върху втория вариант. За извадките от различни банки използвахме Apache Spark. Същността на механизма се свежда до Java код, който по указани ключове (абонат, време на извършване на повикването – ключове от секцията) извлича данни от C*, както и нужните данни за обогатяване от всяка друга БД. След това свързва тези данни в паметта си и извежда резултата в резултативната таблица. Над Spark проектирахме уеб интерфейс и всичко се оказа изключително подходящо за експлоатация.

При решаването на задачата с обновяване на данни пром-тест отново разгледахме няколко начина за решаване. Има вариант за пренос през Sstloader, както и опция за разделяне на клъстера в тестовата зона на две части, всяка от които последователно влиза в един промовски клъстер, захранвайки се така от него. При обновяването на теста се планираше да ги сменим: частта, която работеше в теста, се чисти и влиза в пром, а другата започва да работи с данните поотделно. Въпреки това, след като помислихме отново, по-рационално оценихме данните, които е необходимо да пренесем, и осъзнахме, че самите повиквания са неконсистентна същност за тестовете, бързо генерирани в случай на нужда, и именно промовският набор от данни няма стойност за пренос в теста. Има няколко обекта-накопителя, които си заслужава да бъдат пренесени, но това буквално са две-три таблици, и то не особено тежки. Затова ние в качеството на решение отново се включи Spark, с помощта на който написахме и започнахме активно да използваме скрипт за пренос на данни между таблиците пром-тест.

Нашата текуща политика за разгръщане позволява да работим без откат. Преди прома е задължителен накат на теста, където грешката не е толкова фатална. В случай на неуспех винаги може да се дропне кейспейсът и да се накачи цялата схема отначало.

За да осигурим непрекъсната наличност на Касандра, е необходима DBA и не само той. Всеки, който работи с приложението, трябва да разбира къде и как да следи текущата ситуация и как навременно да диагностицира проблемите. За това активно използваме DataStax OpsCenter (Администрация и мониторинг на работните натоварвания), системни метрики на Cassandra Driver (броя на таймаутите при запис в C*, броя на таймаутите при четене от C*, максимална латентност и т.н.), мониторим работата на самото приложение, което работи с Касандра.

Когато обмисляхме предишния въпрос, осъзнахме къде може да се крие основният риск. Това са формите на представяне на данни, които извеждат информация от няколко независими запитвания към хранилището. По този начин можем да получим доста несъгласувана информация. Но този проблем щеше да бъде актуален и ако работехме само с един дата център. Така че най-разумното решение тук е, разбира се, да направим партидна функция за четене на данни на странично приложение, което да осигури получаването на данни в един и същи времеви период. Що се отнася до разделението на четене и запис по отношение на производителността, тук ни спря рискът, че при евентуална загуба на свързаност между дата центровете, можем да получим два съвсем несъгласувани клъстера.

В крайна сметка, в момента остановихме се на ниво на съгласуваност за запис EACH_QUORUM, за четене – LOCAL_QUORUM

Кратки впечатления и изводи

За да оценим полученото решение от гледна точка на експлоатационна поддръжка и перспективите за по-нататъшно развитие, решихме да помислим къде още може да се приложи такава разработка.

От първо гледане, скоринг на данни за програми като „Плати, когато удобно“ (зареждаме в С* информация, изчисления на скриптове Spark), отчет на рекламации с агрегация по направления, съхранение на роли и изчисление по ролевата матрица на правата за достъп на потребители.

Както виждаме, репертоарът е широк и разнообразен. И ако трябва да изберем лагер на привърженици/противници на NoSQL, то ние ще се присъединим към привържениците, тъй като сме получили своите предимства, точно там, където и очаквахме.

Дори вариантът на Кассандра от кутията позволява хоризонтално мащабиране в реално време, абсолютно безболезнено решавайки въпроса за увеличаване на данните в системата. Успяхме да изведем в отделен контур механизмът с високо натоварване за изчисление наAggregати по обаждания, а също и да разделим схемата и логиката на приложението, освобождавайки се от порочната практика на писане на персонализирани джобове и обекти в самата база данни. Получихме възможност да избираме и настройваме, за да ускорим, на кои дата центрове ще извършваме изчисления, а на кои - запис на данни, обезопасили сме се срещу падания както на отделни нодове, така и на целите дата центрове.

Прилагане на нашата архитектура в новите проекти, имайки вече известен опит, е желателно веднага да вземем предвид посочените по-горе нюанси, за да избегнем някои грешки и да изгладим остри ъгли, които не сме успели да избегнем първоначално.

Например, време да следим обновленията на самата Касандра, тъй като доста от проблемите, с които се сблъскахме, вече бяха известни и бяха поправени.

Да не инсталираме и самата база данни, и Спарк на одни и същи нодове (или строго да ги разделяме според допустимото използване на ресурси), тъй като Спарк може да изяде повече оперативна памет, отколкото е позволено, и бързо да получим проблем номер 1 от нашия списък.

Да развиваме наблюдение и експертиза в експлоатацията още на етапа на тестване на проекта. Първоначално да вземем предвид максимално всички потенциални потребители на нашето решение, тъй като именно от това ще зависи в крайна сметка структурата на базата данни.

Няколко пъти да прегледаме получената структура с цел оптимизация. Да определим кои полета могат да бъдат сериализирани. Да разберем какви допълнителни таблици да създадем, за да можем най-коректно и оптимално да взимаме и предоставяме изискваната информация (например, допускайки, че същите данни можем да съхраняваме в различни таблици с оглед на различна разбивка по различни критерии, можем значително да спестим процесорно време при запитвания за четене).

Не е зле веднага да предвидим добавяне на TTL и почистване на остарели данни.

При експортиране на данни от Касандра логиката на приложението трябва да работи на принципа FETCH, така че не всички редове да се зареждат в паметта наведнъж, а да се избират на партиди.

Би било желателно преди прехвърлянето на проекта към описаното решение да проверим устойчивостта на системата, провеждайки серия от краш-тестове, като например загуба на данни в един ЦОД, възстановяване на повредени данни за определен период, забавяне на мрежата между ЦОД-ите. Тези тестове не само че ще позволят оценка на предимствата и недостатъците на предлаганата архитектура, но и ще предоставят добра стартова практика на инженерите, които ги провеждат, а придобитият опит ще бъде полезен, ако системата се сблъска с откази в производството.

Ако работим с критична информация (като данни за извършване на фактуриране, изчисляване на задълженията на абоната), тогава е важно да обърнем внимание на инструментите, които могат да намалят рисковете, произтичащи от особеностите на СУБД. Например, използвайте утилитата nodesync (Datastax), разработвайки оптимална стратегия за нейното ползване, за да не предизвикаме излишно натоварване на Кассандра за консистентност и да я използваме само за определени таблици в определен период.

Какво да кажем, след половин година с Кассандра? Като цяло, нямаме нерешени проблеми. Сериозни аварии и загуба на данни също не допускаме. Да, наложи се да помислим за компенсиране на някои преди невъзникващи проблеми, но в крайна сметка това не затъмни значително нашето архитектурно решение. Ако искате и не се страхувате да пробвате нещо ново, а в същото време не искате да се разочаровате, подгответе се, че нищо безплатно не съществува. Ще трябва да се запознаете с документацията и да съберете своите индивидуални проблеми повече, отколкото в старото наследствено решение и никаква теория не може предварително да ви подскаже какви точно проблеми ви очакват.

Източник: habr.com