Жашоодо баары жок дегенде бир жолу сынап көрүүгө татыктуу дешет. Жана эгер сиз реляциялык DBMS менен иштөөгө көнүп калган болсоңуз, анда NoSQL менен практикада таанышып, биринчи кезекте, жок дегенде жалпы өнүгүү үчүн керек. Азыр бул технологиянын тез өнүгүшүнө байланыштуу бул темада карама-каршы пикирлер жана кызуу талаш-тартыштар көп болуп жатат, бул өзгөчө кызыгууну арттырат.
Бул талаш-тартыштардын баарынын маңызына тереңдеп кирсеңиз, алар туура эмес мамиледен улам келип чыкканын көрүүгө болот. NoSQL маалымат базаларын керектүү жерде колдонгондор канааттандырат жана бул чечимдин бардык артыкчылыктарын алышат. Ал эми бул технологияны такыр колдонбогон панацея катары колдонгон экспериментаторлор реляциялык маалымат базаларынын күчтүү жактарын жоготуп, олуттуу пайдасыз калышат.
Мен Cassandra DBMS негизинде чечимди ишке ашыруу боюнча тажрыйбабыз жөнүндө айтып берем: биз эмнеге туш болдук, биз кыйын кырдаалдардан кантип чыктык, 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 кайрадан жардамга келди, анын жардамы менен биз таблицалардын, пром-тесттин ортосунда маалыматтарды өткөрүү үчүн скрипт жазып, активдүү колдоно баштадык.
Биздин учурдагы жайгаштыруу саясатыбыз артка кайтуусуз иштөөгө мүмкүндүк берет. Промо алдында, ката мынчалык кымбат эмес, милдеттүү тестирлөө бар. Иштебей калган учурда, сиз ар дайым иштердин мейкиндигин таштап, бүт схеманы башынан тарта аласыз.
Кассандранын үзгүлтүксүз жеткиликтүүлүгүн камсыз кылуу үчүн сизге ага гана эмес, dba керек. Тиркеме менен иштеген ар бир адам учурдагы кырдаалды кайда жана кантип кароону жана көйгөйлөрдү өз убагында аныктоону түшүнүшү керек. Бул үчүн биз DataStax OpsCenter (Администрация жана жумуш жүгүн көзөмөлдөө), Cassandra Driver тутумунун көрсөткүчтөрүн (С* га жазуу үчүн тайм-ауттардын саны, С* дан окуу үчүн тайм-ауттардын саны, максималдуу кечигүү ж.б.) активдүү колдонобуз, операцияны көзөмөлдөйбүз. колдонмонун өзү, Кассандра менен иштөө.
Мурунку суроону ойлонгондо, биздин негизги тобокелчилик кайда экенин түшүндүк. Бул бир нече көз карандысыз суроо-талаптардан сактагычка маалыматтарды көрсөткөн маалыматтарды көрсөтүү формалары. Бул жол менен биз такыр дал келбеген маалыматтарды ала алабыз. Бирок, эгерде биз бир гана маалымат борбору менен иштесек, бул маселе да актуалдуу болмок. Демек, бул жерде эң акылга сыярлык нерсе, албетте, үчүнчү тараптын тиркемесинде маалыматтарды окуу үчүн пакеттик функцияны түзүү, бул маалыматтардын бир убакыттын ичинде алынышын камсыз кылат. Аткаруу жагынан окуу жана жазууга бөлүнүүгө келсек, бул жерде биз ДКнын ортосундагы байланышты жоготуу менен, бири-бирине такыр дал келбеген эки кластер пайда болушу мүмкүн деген коркунуч менен токтоп калдык.
Натыйжада, азыр EACH_QUORUM жазуу үчүн ырааттуулук деңгээлинде токтоду, окуу үчүн - LOCAL_QUORUM
Кыскача таасирлер жана корутундулар
Алынган чечимди оперативдүү колдоо жана андан аркы өнүгүү перспективалары көз карашынан баалоо үчүн, биз мындай иштеп чыгууну дагы кайсы жерде колдонсо болору жөнүндө ойлонууну чечтик.
Дароо эле, андан кийин "Ыңгайлуу болгондо төлөө" сыяктуу программалар үчүн берилиштерди баалоо (биз маалыматты C* форматына жүктөйбүз, Spark скрипттеринин жардамы менен эсептөө), аймактар боюнча топтоо менен дооматтарды эсепке алуу, ролдорду сактоо жана ролдун негизинде колдонуучунун кирүү укуктарын эсептөө матрица.
Көрүнүп тургандай, репертуар кенен жана ар түрдүү. Эгерде биз NoSQLдин жактоочуларынын/оппоненттеринин лагерин тандасак, анда биз колдоочуларга кошулабыз, анткени биз өзүбүздүн артыкчылыктарыбызды жана биз күткөн жерден алдык.
Жада калса Кассандра варианты да реалдуу убакыт режиминде горизонталдуу масштабга мүмкүндүк берет, системадагы маалыматтарды көбөйтүү маселесин такыр оорутпай чечет. Биз чалуу агрегаттарын эсептөө үчүн өтө чоң жүктөө механизмин өзүнчө схемага жылдыра алдык, ошондой эле колдонмонун схемасын жана логикасын бөлүп, маалымат базасында ыңгайлаштырылган жумуштарды жана объекттерди жазуудагы жаман тажрыйбадан арылтык. Биз тандоо жана конфигурациялоо, ылдамдатуу мүмкүнчүлүгүнө ээ болдук, кайсы DC боюнча эсептөөлөрдү жүргүзөбүз жана кайсынысына маалыматтарды жаздырабыз, биз жеке түйүндөрдүн да, бүтүндөй ДКнын да кыйроолорунан өзүбүздү камсыздандырдык.
Архитектурабызды жаңы долбоорлорго колдонуу менен жана буга чейин кандайдыр бир тажрыйбага ээ болуп, мен жогоруда айтылган нюанстарды дароо эске алып, кээ бир каталарды болтурбай, алгач качууга мүмкүн болбогон курч бурчтарды текшилгим келет.
Мисалы, Кассандранын жаңыртууларына өз убагында көз салып туруңузанткени бизде пайда болгон көйгөйлөрдүн бир нечеси мурунтан эле белгилүү болгон жана чечилген.
Маалыматтар базасынын өзүн да, Sparkты да бир түйүндөргө койбоңуз (же ресурстун уруксат берилген көлөмүнө бөлүңүз), анткени Spark күтүлгөндөн көбүрөөк OP жей алат жана биз тез арада тизмебизден №1 көйгөйдү алабыз.
Долбоорду тестирлөө этабында мониторингди жана оперативдүү компетенттүүлүктү жакшыртуу. Башында, мүмкүн болушунча биздин чечимдин бардык потенциалдуу керектөөчүлөрүн эске алыңыз, анткени бул маалымат базасынын түзүлүшү акыры көз каранды болот.
Мүмкүн болгон оптималдаштыруу үчүн алынган схеманы бир нече жолу айлантыңыз. Кайсы талааларды сериялаштырууну тандаңыз. Эң туура жана оптималдуу эсепке алуу үчүн кандай кошумча таблицаларды түзүшүбүз керек экенин түшүнүп, андан кийин талап боюнча талап кылынган маалыматты бериңиз (мисалы, биз бир эле маалыматтарды ар кандай таблицаларда сактай алабыз деп ойлойбуз, ар кандай критерийлер, биз окуу суроо-талаптары үчүн CPU убактысын бир кыйла үнөмдөй алабыз).
Жаман эмес Ошол замат TTL тиркөө жана эскирген маалыматтарды тазалоо үчүн камсыз кылуу.
Кассандрадан маалыматтарды жүктөөдө Колдонмо логикасы FETCH принцибинде иштеши керек, андыктан бардык саптар эстутумга бир убакта жүктөлбөй, партиялар менен тандалып алынат.
Долбоорду сүрөттөлгөн чечимге өткөрүүдөн мурун сунушталат бир катар ката сыноолорду өткөрүү менен системанын катачылыкка чыдамдуулугун текшериңиз, мисалы, бир маалымат борборунда маалыматтарды жоготуу, белгилүү бир мезгил ичинде бузулган маалыматтарды калыбына келтирүү, маалымат борборлорунун ортосундагы тармактын үзүлүшү. Мындай сыноолор сунуш кылынган архитектуранын оң жана терс жактарын баалоого гана мүмкүндүк бербестен, аларды жүргүзүүчү инженерлер үчүн жакшы жылынуу практикасын камсыз кылат жана системанын бузулуулары өндүрүштө кайталанса, алынган көндүм ашыкча болбойт.
Эгерде биз маанилүү маалымат менен иштесек (мисалы, эсеп-кысап үчүн маалыматтар, абоненттик карызды эсептөө), анда ошондой эле МББнын өзгөчөлүктөрүнөн улам келип чыккан тобокелдиктерди азайта турган инструменттерге көңүл буруу керек. Мисалы, аны колдонуу үчүн оптималдуу стратегияны иштеп чыгып, nodesync утилитасын (Datastax) колдонуңуз. ырааттуулугу үчүн, Кассандрага ашыкча жүк жаратпаңыз жана аны белгилүү бир мезгил ичинде белгилүү таблицалар үчүн гана колдонуңуз.
Кассандра алты ай жашагандан кийин эмне болот? Негизинен чечилбеген көйгөйлөр жок. Биз ошондой эле олуттуу кырсыктарга же маалыматтарды жоготууга жол берген жокпуз. Ооба, биз мурда пайда болбогон кээ бир көйгөйлөрдүн ордун толтуруу жөнүндө ойлонушубуз керек болчу, бирок акыры бул биздин архитектуралык чечимибизди булуттай алган жок. Эгерде сиз кааласаңыз жана жаңы нерсени сынап көрүүдөн коркпосоңуз, жана ошол эле учурда көңүлүңүздү чөгөрүүнү каалабасаңыз, анда эч нерсе бекер эмес экенине даяр болуңуз. Сиз түшүнүп, документтерди изилдеп, өзүңүздүн жеке тырмооңузду эски эски чечимге караганда чогултушуңуз керек жана эч кандай теория сизди кайсы тырмоо күтүп турганын алдын ала айтып бербейт.
Source: www.habr.com