Кажуць, у жыцці ўсё варта паспрабаваць хаця б раз. І калі вы абвыклі працаваць з рэляцыйнымі СКБД, то пазнаёміцца на практыцы з NoSQL варта ў першую чаргу хаця б для агульнага развіцця. Цяпер у сілу бурнага развіцця гэтай тэхналогіі вельмі шмат супярэчлівых меркаванняў і гарачых спрэчак на гэтую тэму, што асабліва падагравае цікавасць.
Калі ўглыбіцца ў сутнасць усіх гэтых спрэчак, то можна ўбачыць, што яны ўзнікаюць з-за няправільнага падыходу. Тыя, хто выкарыстоўвае NoSQL базы менавіта там, дзе яны патрэбныя, задаволены і атрымліваюць ад дадзенага рашэння ўсе яго плюсы. А эксперыментатары, якія спадзяюцца на дадзеную тэхналогію як панацэю там, дзе яна не прымяняецца зусім, адчуваюць расчараванне, страціўшы моцныя бакі рэляцыйных баз без набыцця важкіх выгод.
Я распавяду пра наш досвед укаранення рашэння, заснаванага на СКБД Cassandra: з чым прыйшлося сутыкнуцца, як выкручваліся з цяжкіх сітуацый, ці атрымалася нам атрымаць выйгрыш ад выкарыстання NoSQL і дзе прыйшлося ўкласці дадатковыя высілкі/сродкі.
Зыходная задача – гэта пабудова сістэмы, якая запісвае званкі ў нейкае сховішча.
Прынцып дзеяння сістэмы наступны. На ўваход прыходзяць файлы з вызначанай структурай, якая апісвае структуру выкліку. Затым дадатак забяспечвае захаванне гэтай структуры ў адпаведныя калонкі. У далейшым захаваныя выклікі выкарыстоўваюцца - для адлюстравання інфармацыі па спажыванні трафіку для абанентаў (налічэнні, званкі, гісторыя балансу).
Чаму выбралі Касандра цалкам зразумела - яна піша як кулямёт, лёгка маштабуецца, адмоваўстойлівасць.
Такім чынам, вось што нам падарыў досвед
Так, вылецелая нода - не трагедыя. У тым і сутнасць адмоваўстойлівасці Касандры. Але нода можа быць жывы і пры гэтым пачаць асядаць па прадукцыйнасці. Як высветлілася, гэта адразу адбіваецца на прадукцыйнасць усяго кластара.
Касандра не падстрахуе там, дзе Oracle ратаваў сваімі канстрэйнтамі. І калі аўтар прыкладання загадзя гэтага не зразумеў, то які прыляцеў дубль для Касандры ані не горш арыгіналу. Раз прыйшоў, значыць уставім.
Бясплатная Касандра "са скрынкі" рэзка не спадабалася ИБ: лагіравання дзеянняў карыстальнікаў няма, размежавання правоў таксама. Інфармацыя аб выкліках адносіцца да персанальных дадзеных, а гэта значыць, што ўсе спробы якім-небудзь чынам яе запытаць/змяніць, павінны часопісавацца з магчымасцю наступнага аўдыту. Таксама, трэба ўсведамляць неабходнасць падзяляць правы па розных узроўнях для розных карыстальнікаў. Просты інжынер эксплуатацыі і суперадмін, які свабодна можа выдаліць увесь keyspace - гэта розныя ролі, розная адказнасць, кампетэнцыя. Без такога размежавання правоў доступу каштоўнасць і цэласнасць дадзеных адразу апынецца пад пытаннем хутчэй, чым пры ўзроўні кансістэнтнасці ANY.
Мы не ўлічылі, што па званках патрабуецца як сур'ёзная аналітыка, так і перыядычныя выбаркі па самых розных умовах. Бо абраныя запісы потым мяркуецца выдаляць і перазапісваць (у рамках задачы мы павінны падтрымліваць працэс актуалізацыі дадзеных пры першапачаткова няслушна якія паступілі да нас у контур дадзеных), то Касандра нам тут не таварыш. Касандра, як скарбонка - у яе зручна складаць, але ў ёй не атрымаецца лічыць.
Сутыкнуліся з праблемай пераносу дадзеных у тэставыя зоны (5 нод у тэсце супраць 20 у проме). Дамп у такім выпадку выкарыстоўваць не атрымаецца.
Праблема абнаўленняў схемы дадзеных прыкладання, які піша ў Касандра. Адкат спародзіць вялікае мноства надмагілляў, што непрадказальнай выявай можа нам прасадзіць прадукцыйнасць.. Касандра аптымізавана для запісу, і перад тым, як запісаць, шмат не думае Любая аперацыя з існуючымі дадзенымі ў ёй - гэта таксама запіс. Т. е. выдаліўшы лішняе, мы проста наплодзім яшчэ больш запісаў, і толькі частка з іх будзе пазначана надмагіллямі.
Таймаўты пры ўстаўцы. Касандра ў запісе цудоўная, але часам уваходны струмень можа яе істотна збянтэжыць. Такое адбываецца, калі праграма пачынае ганяць па крузе некалькі запісаў, якія не ўдаецца ўставіць па якой-небудзь прычыне. І нам патрэбен будзе суцэль сабе сапраўдны ДБА, які стане сачыць за gc.log, логі system і debug на прадмет slow query, метрыкі на compaction pending.
Некалькі датацэнтраў у кластары. Адкуль чытаць і куды пісаць?
Магчыма, падзяліць на чытанне і на запіс? І калі так, то бліжэй да дадатку павінен быць ДЦ для запісу або для чытання? І ці не атрымаецца ў нас сапраўдны split brain, калі няправільна абярэм узровень узгодненасці? Вельмі шмат пытанняў, шмат нязведаных налад, магчымасцей, якія так хочацца пакруціць.
Як мы вырашалі
Каб нода не сядала, адключылі SWAP. І зараз пры недахопе памяці нода павінна легчы, а не пладзіць вялікія gc паўзы.
Дык вось, на логіку ў БД мы больш не спадзяемся. Распрацоўнікі прыкладання перавучваюцца і пачынаюць актыўна падстрахоўвацца ў сваім жа кодзе. Ідэальны выразны падзел захоўвання і апрацоўкі дадзеных.
Набывалі падтрымку ад DataStax. Каробачную Касандру ўжо перасталі распрацоўваць (апошні коміт у лютым 2018 года). У той жа час, Datastax прапануе выдатны сэрвіс і вялікая колькасць дапрацаваных і адаптаваных пад існуючыя ІС рашэнняў.
Яшчэ хачу адзначыць, што Касандра не вельмі зручная для запытаў на выбарку. Зразумела, CQL – вялікі крок насустрач карыстальнікам (у параўнанні з Trift). Але калі ў вас ёсць цэлыя аддзелы, якія звыкнуліся да такіх зручных джойнаў, вольнага фільтравання па любым полі і магчымасцям аптымізацыі запыту, і гэтыя аддзелы працуюць над тым, каб зачыняць прэтэнзіі і аварыі, тое рашэнне на Касандры, бачыцца ім варожым і дурным. І мы пачалі вырашаць пытаньне, як нашым калегам рабіць выбаркі.
Разглядалі два варыянты. У першым варыянце пішам выклікі не толькі ў З *, але і ў архіўную БД Oracle. Толькі ў адрозненне ад C* у гэтай БД захоўваюцца выклікі толькі за бягучы месяц (дастатковая глыбіня захоўвання выклікаў для кейсаў ператарыфікацыі). Тут адразу бачылася наступная праблема: калі пісаць сінхронна, то мы губляем усе плюсы З*, звязаныя з хуткай устаўкай, калі асінхронна - няма гарантыі таго, што ўсе патрэбныя выклікі наогул патрапілі ў Oracle. Плюс быў адзін, але вялікі: для эксплуатацыі застаецца ўсё той жа звыклы PL/SQL Developer, т. е. практычна рэалізуем патэрн "Фасад". Альтэрнатыўны варыянт. Рэалізуемы механізм, які выгружае выклікі з C*, цягне нейкія дадзеныя для ўзбагачэння з адпаведных табліц у Oracle, джойніць атрыманыя выбаркі і выдае нам атрыманы вынік, які мы потым неяк выкарыстоўваем (адкочваем, перапаўтараем, аналізуем, захапляемся). Мінусы: працэс атрымліваецца даволі шматкрокавым, а акрамя таго, адсутнічае інтэрфейс для супрацоўнікаў эксплуатацыі.
У выніку спыніліся ўсё ж на другім варыянце. Для выбарак з розных слоікаў выкарыстоўвалі Apache Spark. Сутнасць механізму звялася да Java-кода, які па паказаных ключах (абанент, час здзяйснення выкліку - ключы часткі) выцягвае дадзеныя з C*, а таксама патрэбныя дадзеныя для ўзбагачэння з любой іншай БД. Пасля чаго джойніць іх у сваёй памяці і выводзіць вынік у выніковую табліцу. Над спаркам намалявалі вэб-пыску і атрымалася суцэль прыдатна да эксплуатацыі.
Пры рашэнні задачы з абнаўленнем дадзеных прам-тэст зноў разглядалі некалькі спосабаў рашэння. Як перанос праз Sstloader, так і варыянт з разбіццём кластара ў тэставай зоне на дзве часткі, кожная з якіх напераменку ўваходзіць у адзін кластар з промовским, спрабуючы такім чынам ад яго. Пры абнаўленні тэсту планавалася мяняць іх месцамі: тая частка, якая працавала ў тэсце, ачышчаецца і ўводзіцца ў прам, а іншая пачынае працаваць з дадзенымі асобна. Аднак, падумаўшы яшчэ раз, мы больш рацыянальна ацанілі тыя дадзеныя, якія варта пераносіць, і зразумелі, што самі па сабе выклікі – некансістэнтная сутнасць для тэстаў, якая хутка генеруецца ў выпадку неабходнасці, і менавіта прамаўскі набор дадзеных не мае каштоўнасці для пераносу ў тэст. Ёсць некалькі аб'ектаў-назапашвальнікаў, якія варта пераносіць, але гэта літаральна пары табліц, прычым, не моцна цяжкіх. Таму нам у якасці рашэння зноў прыйшоў на дапамогу Spark, з дапамогай якога мы напісалі і сталі актыўна выкарыстоўваць скрыпт пераносу дадзеных паміж табліцамі прам-тэст.
Наша бягучая палітыка дэплою дазваляе нам працаваць без адкатаў. Перад промам ідзе абавязковы накат на тэст, дзе памылка не такая дарагая. У выпадку няўдачы заўсёды можна дропнуць кейспейс і накаціць усю схему з пачатку.
Для забеспячэння бесперапыннай даступнасці Касандры патрэбен дба і не толькі ён. Усе, хто працуе з дадаткам, павінны разумець, дзе і як глядзець бягучую сітуацыю і як своечасова дыягнаставаць праблемы. Для гэтага мы актыўна выкарыстоўваем DataStax OpsCenter (Адміністраванне і маніторынг працоўных нагрузак), сістэмныя метрыкі Cassandra Driver (колькасць таймаўтаў на запіс у C*, колькі таймаўтаў на чытанне з C*, максімальная latency і т. д.), маніторым працу самога прыкладання, які працуе з Касандра.
Калі задумаліся над папярэднім пытаннем, то зразумелі, дзе ў нас можа быць асноўная рызыка. Гэта - формы адлюстравання дадзеных, якія выводзяць дадзеныя з некалькіх незалежных адзін ад аднаго запытаў да сховішча. Такім чынам, мы можам атрымаць даволі няўзгодненую інфармацыю. Але гэтая праблема была б гэтак жа актуальная і ў выпадку, калі б мы працавалі толькі з адным датацэнтрам. Так што самае разумнае тут - гэта, вядома, рабіць батчавую функцыю чытання дадзеных на іншым дадатку, якая забяспечыць атрыманне дадзеных у адзіны перыяд часу. Што да падзелу на чытанне і запіс у плане прадукцыйнасці, то тут нас спыніў рызыку таго, што пры некаторай страце канэкту паміж ДЦ, мы можам атрымаць два зусім няўзгодненых паміж сабою кластара.
У выніку, на дадзены момант спыніліся на ўзроўні ўзгодненасці для запісу EACH_QUORUM, для чытання - LOCAL_QUORUM
Кароткія ўражанні і высновы
Для таго, каб ацаніць атрыманае рашэнне з пункту гледжання эксплутацыйнай падтрымкі і перспектыў далейшага развіцця, мы вырашылі падумаць, дзе яшчэ можна прымяніць такую распрацоўку.
Калі з ходу, то скоринг дадзеных для праграм тыпу «Плаці, калі зручна» (грузім у З* інфармацыю, разлік на скрыптах Spark), улік прэтэнзіёнкі з агрэгацыяй па кірунках, захоўванне роляў і вылічэнне па ролевай матрыцы правоў доступу карыстачоў.
Як бачым, рэпертуар шырокі і разнастайны. І калі выбіраць лагер прыхільнікаў/праціўнікаў NoSQL, то мы далучымся да прыхільнікаў, бо свае плюсы атрымалі, і менавіта тамака, дзе і чакалі.
Нават варыянт Касандры са скрынкі дазваляе вырабляць гарызантальнае маштабаванне ў рэалтайме, абсалютна бязбольна вырашаючы пытанне павелічэння дадзеных у сістэме. У нас атрымалася вынесці ў асобны контур вельмі высоканагружаны механізм па разліку агрэгатаў па званках, а таксама, падзяліць схему і логіку прыкладання, пазбавіўшыся ад заганнай практыкі напісання кастамных джобаў і аб'ектаў у самой БД. Мы атрымалі магчымасць выбіраць і настройваць, для паскарэння, на якіх ДЦ мы будзем рабіць разлік, а на якіх запіс даных, падстрахавалі сябе на прадмет падзенняў як асобных нод, так і ў цэлым ДЦ.
Ужываючы да новых праектаў нашу архітэктуру, прычым, ужо валодаючы некаторым досведам, жадалася бы адразу ж улічваць апісаныя вышэй нюансы, і не дапусціць некаторых памылак, згладзіць нейкія вострыя куты, якіх не атрымалася пазбегнуць першапачаткова.
Напрыклад, своечасова адсочваць абнаўленні самой Касандры, таму што даволі шмат праблем, якія мы атрымалі, ужо былі вядомыя і кіраваліся.
Не саджаць і саму БД, і Спарк на адны і тыя ж ноды (або строга падзяляць па колькасці дапушчальнага выкарыстання рэсурсаў), бо Спарк можа з'есці АП больш за належнае, і мы хутка атрымаем праблему нумар 1 з нашага спісу.
Прапампоўваць маніторынг і кампетэнцыю эксплуатацыі яшчэ на этапе тэсціравання праекта. Першапачаткова ўлічваць па максімуме ўсіх патэнцыйных спажыўцоў нашага рашэння, таму што менавіта ад гэтага будзе залежаць у выніку структура БД.
Некалькі разоў пакруціць атрыманую схему на прадмет магчымай аптымізацыі. Вылучыць якія палі можна серыялізаваць. Зразумець якія дадатковыя табліцы нам зрабіць, каб найбольш карэктна і аптымальна ўлічваць, і потым аддаваць па запыце патрэбную інфармацыю (напрыклад, дапушчаючы, што адны і тыя ж дадзеныя мы можам захоўваць у розных табліцах, з улікам рознай разбіўкі па розных крытэрах, можна істотна эканоміць працэсарны час пры запытах чытання).
Не дрэнна адразу прадугледзець навешванне TTL і чыстку састарэлых дадзеных.
Пры выгрузцы дадзеных з Касандры логіка прыкладання павінна працаваць па прынцыпе FETCH, каб не ўсе радкі загружаліся ў памяць за адзін раз, а выбіраліся пачкамі.
Пажадана перад перакладам праекту на апісванае рашэнне праверыць адмоваўстойлівасць сістэмы, правядучы серыю краш-тэстаў, накшталт страты дадзеных у адным ЦАД, аднаўлення сапсаваных дадзеных за нейкі перыяд, прасадкі сеткі паміж ЦАД. Такія тэсты не толькі дазволяць ацаніць плюсы і мінусы прапанаванай архітэктуры, але і дадуць добрую разміначную практыку праводзяць іх інжынерам, а атрыманы навык будзе далёка не лішнім, калі адмовы сістэмы прайграюцца ў проме.
Калі мы працуем з крытычнай інфармацыяй (такі як дадзеныя для правядзення білінгу, разлік запазычанасці абанента), то варта таксама надаць увагу інструментам, якія дазволяць знізіць рызыкі, якія ўзнікаюць у сілу асаблівасцяў СКБД. Напрыклад, выкарыстоўваць утыліту nodesync (Datastax), выпрацаваўшы аптымальную стратэгію яе выкарыстання, каб дзеля кансістэнтнасці не сфармаваць залішнюю нагрузку на Касандра і выкарыстоўваць яе толькі для пэўных табліц у пэўны перыяд.
Што ж, праз паўгода жыцця, з Касандра? У цэлым, нявырашаных праблем няма. Сур'ёзных аварый і страты звестак мы таксама не дапусцілі. Так, прыйшлося падумаць над кампенсацыяй некаторых раней не ўзнікалі праблем, але ў выніку гэта не моцна азмрочыла наша архітэктурнае рашэнне. Калі вы хочаце і не баіцеся спрабаваць нешта новае, і пры гэтым не хочаце моцна расчаравацца, то прыгатуйцеся да таго, што бясплатнага нічога не бывае. Разбірацца, унікаць у дакументацыю і збіраць свае індывідуальныя граблі давядзецца больш, чым у старым legacy рашэнні і ніякая тэорыя не падкажа загадзя, якія менавіта граблі чакаюць менавіта вас.
Крыніца: habr.com