Казват, че всичко в живота си струва да се опита поне веднъж. И ако сте свикнали да работите с релационни СУБД, тогава си струва да се запознаете с NoSQL на практика, на първо място, поне за общо развитие. Сега, поради бързото развитие на тази технология, има много противоречиви мнения и разгорещени дебати по тази тема, което особено подхранва интереса.
Ако се задълбочите в същността на всички тези спорове, можете да видите, че те възникват поради грешен подход. Тези, които използват NoSQL бази данни точно там, където са необходими, са доволни и получават всички предимства от това решение. И експериментаторите, които разчитат на тази технология като панацея там, където тя изобщо не е приложима, са разочаровани, тъй като са загубили силните страни на релационните бази данни, без да получат значителни ползи.
Ще ви разкажа за нашия опит в внедряването на решение, базирано на СУБД Cassandra: с какво трябваше да се сблъскаме, как излязохме от трудни ситуации, дали успяхме да се възползваме от използването на NoSQL и къде трябваше да инвестираме допълнителни усилия/средства .
Първоначалната задача е да се изгради система, която записва обажданията в някакъв вид хранилище.
Принципът на работа на системата е следният. Входът включва файлове със специфична структура, която описва структурата на повикването. След това приложението гарантира, че тази структура се съхранява в съответните колони. В бъдеще запазените разговори се използват за показване на информация за потреблението на трафик за абонати (такси, разговори, история на баланса).
Съвсем ясно е защо са избрали Касандра - тя пише като картечница, лесно се мащабира и е устойчива на грешки.
И така, това ни даде опитът
Да, неуспешният възел не е трагедия. Това е същността на отказоустойчивостта на Касандра. Но един възел може да е жив и в същото време да започне да страда от производителност. Както се оказа, това веднага се отразява на производителността на целия клъстер.
Cassandra няма да ви защити там, където Oracle ви спаси с ограниченията си. И ако авторът на приложението не е разбрал това предварително, тогава двойникът, който пристигна за Касандра, не е по-лош от оригинала. След като пристигне, ще го поставим.
IB силно не хареса безплатната Касандра от кутията: Няма регистриране на действията на потребителите, няма разграничаване на правата. Информацията за обажданията се счита за лична информация, което означава, че всички опити за нейното искане/промяна по какъвто и да е начин трябва да се регистрират с възможност за последващ одит. Освен това трябва да сте наясно с необходимостта от разделяне на правата на различни нива за различните потребители. Един прост оперативен инженер и супер администратор, който може свободно да изтрие цялото пространство на ключовете, са различни роли, различни отговорности и компетенции. Без такова разграничаване на правата за достъп, стойността и целостта на данните веднага ще бъдат поставени под въпрос по-бързо, отколкото при ВСЯКО ниво на съгласуваност.
Не взехме предвид, че разговорите изискват както сериозен анализ, така и периодично вземане на проби за различни условия. Тъй като след това избраните записи трябва да бъдат изтрити и пренаписани (като част от задачата трябва да поддържаме процеса на актуализиране на данни, когато данните първоначално са влезли неправилно в нашия цикъл), Касандра не е наш приятел тук. Касандра е като касичка - удобно е да слагате неща, но не можете да разчитате в нея.
Срещнахме проблем при прехвърлянето на данни към тестовите зони (5 възела в теста срещу 20 в бала). В този случай дъмпът не може да се използва.
Проблемът с актуализирането на схемата на данните на приложение, което пише на Cassandra. Връщане назад ще генерира много надгробни плочи, което може да доведе до загуба на производителност по непредвидими начини.. Касандра е оптимизирана за запис и не мисли много преди да пише.Всяка операция със съществуващи данни в нея също е запис. Тоест, като изтрием ненужното, ние просто ще произведем още повече записи и само някои от тях ще бъдат маркирани с надгробни паметници.
Изчакване при вмъкване. Касандра е красива на записа, но понякога входящият поток може значително да я озадачи. Това се случва, когато приложението започне да обикаля няколко записа, които не могат да бъдат вмъкнати по някаква причина. И ние ще се нуждаем от истински DBA, който ще следи gc.log, системни и регистрационни файлове за отстраняване на грешки за бавни заявки, показатели за уплътняване в очакване.
Няколко центъра за данни в клъстер. Откъде да чета и къде да пиша?
Може би разделяне на четене и писане? И ако да, трябва ли да има DC по-близо до приложението за писане или четене? И няма ли да се окажем с истински раздвоен мозък, ако изберем грешното ниво на консистенция? Има много въпроси, много неизвестни настройки, възможности, с които наистина искате да се заровите.
Как решихме
За да се предотврати потъването на възела, SWAP беше деактивиран. И сега, ако има липса на памет, възелът трябва да падне и да не създава големи gc паузи.
Така че вече не разчитаме на логиката в базата данни. Разработчиците на приложения се преквалифицират и започват активно да вземат предпазни мерки в собствения си код. Идеално ясно разделяне на съхранението и обработката на данни.
Купихме поддръжка от DataStax. Разработването на касандра в кутия вече е спряно (последният комит беше през февруари 2018 г.). В същото време Datastax предлага отлично обслужване и голям брой модифицирани и адаптирани решения за съществуващи IP решения.
Също така искам да отбележа, че Касандра не е много удобна за заявки за избор. Разбира се, CQL е голяма крачка напред за потребителите (в сравнение с Trift). Но ако имате цели отдели, които са свикнали с такива удобни присъединявания, безплатно филтриране по всяко поле и възможности за оптимизиране на заявки, и тези отдели работят за разрешаване на оплаквания и злополуки, тогава решението на Касандра им изглежда враждебно и глупаво. И започнахме да решаваме как нашите колеги да правят проби.
Разгледахме два варианта.В първия вариант записваме разговори не само в C*, но и в архивираната база данни на Oracle. Само, за разлика от C*, тази база данни съхранява разговори само за текущия месец (достатъчна дълбочина на съхранение на разговори за случаи на презареждане). Тук веднага видяхме следния проблем: ако пишем синхронно, губим всички предимства на C*, свързани с бързото вмъкване; ако пишем асинхронно, няма гаранция, че всички необходими извиквания изобщо са попаднали в Oracle. Имаше един плюс, но голям: за работа остава същият познат PL/SQL Developer, т.е. практически прилагаме шаблона „Фасада“. Внедряваме механизъм, който разтоварва обаждания от C*, изтегля някои данни за обогатяване от съответните таблици в Oracle, обединява получените проби и ни дава резултата, който след това по някакъв начин използваме (връщаме назад, повтаряме, анализираме, възхищаваме се). Минуси: процесът е доста многоетапен и освен това няма интерфейс за оперативните служители.
В крайна сметка се спряхме на втория вариант. Apache Spark беше използван за вземане на проби от различни буркани. Същността на механизма е сведена до Java код, който с помощта на посочените ключове (абонат, време на повикване - ключове на секции) извлича данни от C*, както и необходимите данни за обогатяване от всяка друга база данни. След което ги обединява в паметта си и извежда резултата в получената таблица. Начертахме уеб лице върху искрата и се оказа доста използваемо.
Когато решавахме проблема с актуализирането на данните от промишлени тестове, ние отново разгледахме няколко решения. Както прехвърлянето чрез Sstloader, така и опцията за разделяне на клъстера в тестовата зона на две части, всяка от които последователно принадлежи към същия клъстер с промоционалния, като по този начин се захранва от него. При актуализирането на теста беше планирано да ги размените: частта, която е работила в теста, се изчиства и влиза в производство, а другата започва да работи с данните отделно. Въпреки това, след като помислихме отново, ние оценихме по-рационално данните, които си струва да бъдат прехвърлени, и осъзнахме, че самите обаждания са несъгласувана единица за тестове, бързо генерирана, ако е необходимо, и промоционалният набор от данни няма стойност за прехвърляне към тест. Има няколко предмета за съхранение, които си струва да бъдат преместени, но това са буквално няколко маси и то не много тежки. Следователно ние като решение отново дойде на помощ Spark, с помощта на който написахме и започнахме активно да използваме скрипт за прехвърляне на данни между таблици, prom-test.
Текущата ни политика за внедряване ни позволява да работим без връщане назад. Преди промоцията има задължителен тест, където грешката не е толкова скъпа. В случай на неуспех, винаги можете да изпуснете casespace и да завъртите цялата схема от самото начало.
За да осигурите непрекъсната наличност на Cassandra, имате нужда от dba и не само от него. Всеки, който работи с приложението, трябва да разбере къде и как да погледне текущата ситуация и как да диагностицира проблемите навреме. За да направим това, ние активно използваме DataStax OpsCenter (Администриране и наблюдение на натоварванията), системни показатели на Cassandra Driver (брой изчаквания за запис в C*, брой изчаквания за четене от C*, максимална латентност и т.н.), наблюдаваме операцията на самото приложение, работещо с Cassandra.
Когато се замислихме върху предишния въпрос, разбрахме къде може да се крие основният ни риск. Това са формуляри за показване на данни, които показват данни от няколко независими заявки към хранилището. По този начин можем да получим доста противоречива информация. Но този проблем би бил също толкова важен, ако работим само с един център за данни. Така че най-разумното нещо тук е, разбира се, да се създаде пакетна функция за четене на данни в приложение на трета страна, което ще гарантира, че данните се получават за един период от време. Що се отнася до разделянето на четене и писане по отношение на производителността, тук бяхме спряни от риска, че с известна загуба на връзка между DC-ите можем да се окажем с два клъстера, които са напълно несъвместими един с друг.
В резултат на това за сега спряно на ниво последователност за писане EACH_QUORUM, за четене - LOCAL_QUORUM
Кратки впечатления и изводи
За да оценим полученото решение от гледна точка на оперативната поддръжка и перспективите за по-нататъшно развитие, решихме да помислим къде другаде може да се приложи подобно развитие.
Веднага, след това точкуване на данни за програми като „Плащане, когато е удобно“ (ние зареждаме информация в C*, изчисляваме с помощта на скриптове на Spark), отчитане на искове с агрегиране по области, съхраняване на роли и изчисляване на потребителски права за достъп въз основа на ролята матрица.
Както виждате, репертоарът е богат и разнообразен. И ако изберем лагера на привържениците/противниците на NoSQL, тогава ще се присъединим към поддръжниците, тъй като получихме своите предимства и точно там, където очаквахме.
Дори опцията Cassandra извън кутията позволява хоризонтално мащабиране в реално време, като абсолютно безболезнено решава проблема с увеличаването на данните в системата. Успяхме да преместим механизъм с много високо натоварване за изчисляване на агрегатите на повикванията в отделна верига и също така да отделим схемата и логиката на приложението, като се отървахме от лошата практика за писане на персонализирани задачи и обекти в самата база данни. Получихме възможност да избираме и конфигурираме, да ускоряваме, на кои DC ще извършваме изчисления и на кои ще записваме данни, застраховахме се срещу сривове както на отделните възли, така и на DC като цяло.
Прилагайки нашата архитектура към нови проекти и вече имайки известен опит, бих искал незабавно да взема предвид описаните по-горе нюанси и да предотвратя някои грешки, да изгладя някои остри ъгли, които не можаха да бъдат избегнати първоначално.
Например, следете своевременно актуализациите на Cassandraтъй като доста от проблемите, които получихме, вече бяха известни и отстранени.
Не поставяйте самата база данни и Spark на едни и същи възли (или стриктно разделете на размера на допустимото използване на ресурси), тъй като Spark може да изяде повече OP от очакваното и бързо ще получим проблем номер 1 от нашия списък.
Подобрете мониторинга и оперативната компетентност на етапа на тестване на проекта. Първоначално вземете под внимание, доколкото е възможно, всички потенциални потребители на нашето решение, защото това е, от което в крайна сметка ще зависи структурата на базата данни.
Завъртете получената верига няколко пъти за възможно оптимизиране. Изберете кои полета могат да бъдат сериализирани. Разберете какви допълнителни таблици трябва да направим, за да вземем предвид най-правилно и оптимално, и след това да предоставим необходимата информация при поискване (например като приемем, че можем да съхраняваме едни и същи данни в различни таблици, като вземем предвид различни разбивки според различни критерии, можем да спестим значително процесорно време за заявки за четене).
Не е зле Незабавно осигурете прикачване на TTL и почистване на остарели данни.
При изтегляне на данни от Cassandra Логиката на приложението трябва да работи на принципа FETCH, така че не всички редове да се зареждат в паметта наведнъж, а да се избират на партиди.
Препоръчително е преди да прехвърлите проекта към описаното решение проверете устойчивостта на грешки на системата чрез провеждане на серия от краш тестове, като загуба на данни в един център за данни, възстановяване на повредени данни за определен период, прекъсване на мрежата между центрове за данни. Такива тестове не само ще позволят да се оценят плюсовете и минусите на предложената архитектура, но също така ще осигурят добра практика за загряване на инженерите, които ги провеждат, а придобитите умения далеч не са излишни, ако системните повреди се възпроизвеждат в производството.
Ако работим с критична информация (като данни за фактуриране, изчисляване на абонатен дълг), тогава си струва да обърнете внимание и на инструменти, които ще намалят рисковете, произтичащи от характеристиките на СУБД. Например, използвайте помощната програма nodesync (Datastax), като сте разработили оптимална стратегия за нейното използване, за да в името на последователността, не създавайте прекомерно натоварване на Касандра и го използвайте само за определени таблици в определен период.
Какво се случва с Касандра след шест месеца живот? Като цяло няма нерешени проблеми. Също така не допуснахме сериозни инциденти или загуба на данни. Да, трябваше да помислим за компенсиране на някои проблеми, които не са възникнали преди това, но в крайна сметка това не помрачи много нашето архитектурно решение. Ако искате и не се страхувате да опитате нещо ново и в същото време не искате да бъдете твърде разочаровани, тогава се пригответе за факта, че нищо не е безплатно. Ще трябва да разберете, да се заровите в документацията и да сглобите свой собствен индивидуален рейк повече, отколкото в старото наследено решение, и никоя теория няма да ви каже предварително кой рейк ви очаква.
Източник: www.habr.com