Әзірлеушілерге арналған NoSQL нұсқаулығы

Егер сіз serverді әзірлеу және үлкен деректердегі тенденцияларды қадағалап отырсаңыз, соңғы жылдары NoSQL дерекқорларының айналасындағы шуылдарды байқаған боларсыз . Кейбір адамдар дерекқорға деген осындай көзқараспен шабыттандырады, ал басқалары онда қандай да бір қулық жасырылған деп ойлайды: олардағы деректер үлгілері әдеттегі реляциялық дерекқорлардағыдай емес, қолданбалы бағдарламалау интерфейстері әдеттен тыс және қолданбалар жиі түсініксіз. Бұл мақалада мен сізге олардың бірінші кезекте неліктен құрылғанын, осы NoSQL дерекқорлары, олар қандай мәселелерді шешетінін және неге сонша әр түрлі дерекқорлар кенеттен қажет болатынын айтамын. Егер сіз NoSQL үшін жаңа болсаңыз, сізді мақаланың соңғы бөлігі қызықтыруы мүмкін, онда NoSQL дерекқор түрлері тізімі берілген, менің ойымша, бұл саланы толық түсіну үшін алдымен зерттеу керек.

Неліктен бізге кенеттен жаңа деректер базасы қажет?

Сіз сұрақ қоюға таң қалуыңыз мүмкін: реляциялық деректер қорында не дұрыс емес? Мәселе мынада, олар көп жылдар бойы шынымен жақсы жұмыс істеді, бірақ қазір олар шеше алмайтын мәселе бар. Кейбір болжамдарға сәйкес, 2018 жылы адамзат секундына 50 000 гигаbyte деректер шығарады. Бұл деректердің үлкен көлемі! Оны сақтау және өңдеу күрделі инженерлік қиындық тудырады. Ең сорақысы, бұл көлем үнемі өсіп отырады. Белгілі болғандай, реляциялық дерекқорлар шынымен үлкен көлемдегі деректермен жұмыс істеуге жарамсыз. Олар бір машинада жұмыс істеуге арналған және егер сіз көбірек сұрауларды орындағыңыз келсе, онда жалғыз нұсқа - көбірек жедел жады және қуатты процессоры бар компьютерді сатып алу. Өкінішке орай, бір машина өңдей алатын сұраулар саны шектеулі және бірнеше машиналарда бөлінген жұмыс үшін бізге басқа дерекқор технологиясы қажет. Әрине, кейбір оқырмандар осы сәтте күледі және реляциялық дерекқор жағдайында бірнеше машинаны пайдаланудың екі кеңінен қолданылатын әдісі бар екенін айтады: репликация және бөлшектеу. Бұл дұрыс, бірақ бұл әдістер біздің міндеттерімізді жеңу үшін жеткіліксіз. Оқу репликасы - әрбір дерекқор жаңартуы тек оқу сұрауларын өңдей алатын басқа машиналарға таратылатын әдіс. Бұл жағдайда барлық өзгерістер басты түйін деп аталатын бір server арқылы орындалады, ал оқу көшірмелері деп аталатын басқа serverлер деректердің көшірмелерін ғана сақтайды. Пайдаланушы кез келген машинадан оқи алады, бірақ деректерді тек негізгі түйін арқылы өзгерте алады. Бұл ыңғайлы және өте танымал әдіс, бірақ ол тек көбірек оқу сұрауларын өңдеуге мүмкіндік береді және қажетті көлемдегі мәліметтерді өңдеу мәселесін ешбір жолмен шешпейді. Sharding - реляциялық дерекқордың бірнеше даналарын пайдаланатын тағы бір танымал тәсіл. Олардың әрқайсысы деректер бөлігі үшін жазу және оқу әрекеттерін өңдейді. Егер дерекқор тұтынушылар туралы ақпаратты сақтаса, мысалы, sharding көмегімен, бір құрылғы аттары А әрпінен басталатын тұтынушыларға арналған барлық сұрауларды өңдей алады, басқа машина аттары B әрпінен басталатын тұтынушылар үшін барлық деректерді сақтай алады және т.б. Бөлшектеу қосымша деректерді жазуға мүмкіндік берсе де, мұндай дерекқорды басқару нағыз қорқынышты: деректерді машиналар арасында теңестіру және қажет болған жағдайда кластерді екі бағытта масштабтау керек. Теориялық тұрғыдан қарапайым болып көрінгенімен, оны дұрыс қабылдау өте қиын.

Реляциялық деректер қорын жақсартуға бола ма?

Менің ойымша, сіз реляциялық дерекқорлар қазіргі әлемде жасалған деректер көлеміне ең қолайлы емес екеніне сендіңіз. Дегенмен, неге әлі ешкім бірнеше машиналарда тиімді жұмыс істей алатын «жақсы» реляциялық дерекқорды жасамағаны туралы сұрақ әлі де болуы мүмкін. Бұл технология жай ғана әзірленбеген сияқты көрінуі мүмкін және таратылған реляциялық деректер базасы жақын арада пайда болады. Әттең, бұлай болмайды. Бұл математикалық тұрғыдан мүмкін емес және бұл туралы ештеңе істеу мүмкін емес. Неліктен бұлай екенін түсіну үшін CAP теоремасы деп аталатын (Бреуер теоремасы) қарау керек. Ол 1999 жылы дәлелденді және онда бірнеше машиналарда жұмыс істейтін үлестірілген деректер қорының келесі үш қасиеті болуы мүмкін екендігі айтылады: Жүйелілік – кез келген оқу әрекеті соңғы сәйкес жазу әрекетінің нәтижелерін қайтарады. Жүйе біркелкі болса, жаңа деректерді жазғаннан кейін ескі, қайта жазылған деректерді оқу мүмкін емес. Қол жетімділік ( Қол жетімділік) - бөлінген жүйе кез келген уақытта кіріс сұрауға қызмет көрсете алады және қатесіз жауап қайтарады. Бөлімге төзімділік - дерекқор кейбір serverлері бір-бірімен уақытша байланыса алмаса да оқу және жазу сұрауларына жауап беруді жалғастырады. Бұл уақытша ақаулық желі қосылымының ақаулығы деп аталады және serverдің баяу жұмысына байланысты физикалық желі ақауларынан бастап желі жабдығының физикалық зақымдалуына дейін әртүрлі факторларға байланысты болуы мүмкін. Бұл сипаттардың барлығы, әрине, ыңғайлы және біз олардың барлығын біріктіретін дерекқорды қалаймыз. Ешқандай саналы әзірлеуші ​​ештеңе алмастан, айталық, қолжетімділіктен бас тартқысы келмейді. Өкінішке орай, CAP теоремасы сонымен қатар барлық үш қасиеттің бір уақытта сақталуы мүмкін емес екенін айтады. Мұны түсіну оңай емес, бірақ мүмкін. Біріншіден, егер бізге таратылған дерекқор қажет болса, ол «ажырасуға төзімді» болуы керек. Бұл тіпті талқыланбайды. Ажыратулар үнемі орын алады және біздің дерекқорымыз осыған қарамастан жұмыс істеуі керек. Енді біз неге бірізділік пен қолжетімділікке қол жеткізе алмайтынымызды түсінейік. Бізде екі машинада жұмыс істейтін қарапайым дерекқор бар деп елестетіңіз: A және B. Кез келген пайдаланушы кез келген құрылғыға жаза алады, содан кейін деректер екіншісіне көшіріледі. Енді елестетіп көріңізші, бұл машиналар бір-бірімен уақытша байланыса алмайды, ал В машинасы А машинасына деректерді жібере алмайды немесе одан деректерді қабылдай алмайды. Егер осы уақыт аралығында В машинасы клиенттен оқу сұрауын алса, оның екі мүмкіндігі бар:

1. Соңғысы болмаса да, жергілікті деректеріңізді қайтарыңыз. Бұл жағдайда қол жетімділікке артықшылық беріледі (кем дегенде кейбір деректерді, тіпті ескіргендерін қайтару үшін).
2. Қайтару қатесі. Бұл жағдайда бірізділікке басымдық беріледі: клиент ескірген деректерді алмайды, бірақ ол ешқандай деректерді мүлде алмайды.

Реляциялық дерекқорлар бір уақытта «үйлесімділік» және «қолжетімділік» қасиеттерін енгізуге ұмтылады, сондықтан таратылған ортада жұмыс істей алмайды. Үлестірмелі жүйеде реляциялық деректер қорының барлық мүмкіндіктерін іске асыру әрекеті не шындыққа жанаспайды, не жай ғана мүмкін емес болады . Екінші жағынан, NoSQL дерекқорлары ауқымдылық пен өнімділікке жоғары баға береді. Оларда әдетте қосылымдар мен транзакциялар сияқты «негізгі» мүмкіндіктер жетіспейді және деректер моделі мүлдем басқа болып шығады, мүмкін, тіпті қандай да бір жолмен шектейді. Мұның бәрі деректердің үлкен көлемін сақтауға және бұрынғыдан да көбірек сұрауларды өңдеуге мүмкіндік береді.

NoSQL дерекқорлары үйлесімділік пен қолжетімділікті қалай теңестіреді?

Сізге NoSQL дерекқорын таңдасаңыз, сіз әрқашан ескірген деректерді немесе кез келген сәтсіздік жағдайында қатені алатындай көрінуіңіз мүмкін. Іс жүзінде қол жетімділік пен жүйелілік қол жетімді жалғыз нұсқа емес. Сіз таңдай алатын көптеген нұсқалар бар. Реляциялық дерекқорларда бұл опциялар жоқ, бірақ NoSQL сұраудың орындалуын ұқсас жолмен басқаруға мүмкіндік береді. Қалай болғанда да, олар NoSQL дерекқорында жазу немесе оқу әрекеттерін орындау кезінде екі параметрді орнатуға мүмкіндік береді: W - кластердегі қанша машина жазу әрекетін орындау кезінде деректерді сақтауды растауы керек . Деректерді жазатын машиналар саны неғұрлым көп болса, келесі оқу әрекетіндегі ең соңғы деректерді оқу оңайырақ болады, бірақ соғұрлым ұзағырақ болады. R – деректерді қанша машинадан оқығыңыз келеді . Бөлінген жүйеде деректерді кластердегі барлық машиналарға тарату біраз уақыт алуы мүмкін, сондықтан кейбір serverлер соңғы деректерге ие болады, ал басқалары артта қалады. Деректер оқылатын машиналар саны неғұрлым көп болса, ағымдағы деректерді оқу мүмкіндігі соғұрлым жоғары болады. Практикалық мысалды қарастырайық. Кластеріңізде бес компьютер болса және деректерді тек біреуіне жазып, содан кейін кездейсоқ таңдалған бір компьютерден деректерді оқуды шешсеңіз, ескі деректерді оқу мүмкіндігі 80% болады. Екінші жағынан, бұл ең аз ресурстарды пайдаланады. Сондықтан егер бұрынғы деректер сізге жақсы болса, бұл жаман опция емес. Бұл жағдайда W және R параметрлері 1-ге тең. Екінші жағынан, NoSQL дерекқорындағы барлық бес машинаға деректерді жазсаңыз, кез келген құрылғыдан деректерді оқуға болады және әр уақытта жаңартылған деректерді алуға кепілдік беріледі. Бірдей операцияны көбірек машиналарда орындау ұзағырақ уақыт алады, бірақ егер сіз үшін жаңартылған деректер маңызды болса, онда бұл опцияны таңдауға болады. Бұл жағдайда W = R = 5. Мәліметтер базасының сәйкестігі үшін қажетті оқу мен жазудың ең аз саны қандай? Мұнда қарапайым формула берілген: R + W ≥ N + 1 , мұндағы N - кластердегі машиналар саны. Бұл бес serverмен R = 2 және W = 4 немесе R = 3 және W = 3 немесе R = 4 және W = 2 таңдауға болатынын білдіреді. Бұл жағдайда деректердің қай машинаға жіберілетіні маңызды емес. жазылған болса, оқу әрқашан жаңартылған деректері бар кем дегенде бір құрылғыдан орындалады. DynamoDB сияқты басқа дерекқорларда әртүрлі шектеулер бар және тек дәйекті жазуға мүмкіндік береді. Әрбір деректер бөлігі үш serverде сақталады және кез келген деректер жазылған кезде ол үш машинаның екеуіне жазылады. Бірақ деректерді оқу кезінде сіз екі нұсқаның бірін таңдай аласыз:

1. Қатаң дәйекті оқу, онда деректер үш машинаның екеуінен оқылады және әрқашан ең соңғы жазылған деректерді қайтарады.
2. Деректерді оқу үшін бір машина кездейсоқ таңдалатын ақырғы дәйекті оқу. Дегенмен, бұл ескірген деректерді уақытша қайтаруы мүмкін.

Неліктен NoSQL дерекқорлары сонша көп?

Егер сіз бағдарламалық жасақтаманы әзірлеу саласындағы соңғы жаңалықтарды бақылайтын болсаңыз, MongoDB, DynamoDB, Cassandra, Redis және басқалары сияқты көптеген әртүрлі NoSQL дерекқорлары туралы естіген боларсыз. Сізді қызықтыруы мүмкін: неге бізге әртүрлі NoSQL дерекқорлары қажет? Себебі қарапайым: әртүрлі NoSQL дерекқорлары әртүрлі мәселелерді шешуге арналған. Сондықтан бәсекелес деректер базаларының саны соншалықты көп. NoSQL дерекқорлары төрт негізгі санатқа бөлінеді:

Құжатқа бағытталған мәліметтер қоры

Бұл дерекқорлар күрделі кірістірілген құжаттарды сақтау мүмкіндігін қамтамасыз етеді, ал реляциялық дерекқорлардың көпшілігі тек бір өлшемді жолдарды қолдайды. Бұл мүмкіндік көптеген жағдайларда пайдалы болуы мүмкін, мысалы, жүйеде бірнеше мекенжайлары бар пайдаланушы туралы ақпаратты сақтау қажет болғанда. Құжатқа бағытталған дерекқорды пайдаланған кезде, бұл жағдайда мекенжайлар массивінен тұратын күрделі нысанды жай ғана сақтауға болады, ал реляциялық дерекқорда екі кестені құру керек болады: біреуі пайдаланушы ақпараты үшін және екіншісі мекенжайлар үшін. Құжатқа бағытталған дерекқорлар нысан үлгісі мен деректер үлгісі арасындағы алшақтықты өтейді . PostgreSQL сияқты кейбір реляциялық дерекқорлар қазір құжатқа бағытталған сақтауды қолдайды, бірақ реляциялық дерекқорлардың көпшілігінде әлі де бұл мүмкіндік жоқ.

Кілт/мән дерекқорлары

Кілт/мән дерекқорлары әдетте ең қарапайым NoSQL үлгісін жүзеге асырады. Негізінде, олар сізге берілген кілтке деректерді жазуға және оны пайдаланып қайта оқуға мүмкіндік беретін бөлінген хэш кестесін береді. Кілт/мән дерекқорлары жоғары масштабталады және басқа дерекқорларға қарағанда айтарлықтай төмен кідіріске ие.

Графикалық мәліметтер базасы

Көптеген тақырыптарды, мысалы, әлеуметтік желілерді немесе фильмдер мен актерлер туралы ақпаратты график түрінде көрсетуге болады. Графикті реляциялық мәліметтер базасының көмегімен көрсетуге болатынымен, ол қиын және ыңғайсыз. Графиктік деректер қажет болса, график туралы ақпаратты бөлінген кластерде сақтай алатын және графиктерде алгоритмдерді тиімді жүзеге асыруға мүмкіндік беретін мамандандырылған графикалық дерекқорды қолданған дұрыс.

Бағаналы деректер қоры

Бағаналы деректер қорының басқа түрлерінен негізгі айырмашылығы - деректердің дискіде сақталу тәсілі. Реляциялық дерекқорлар әрбір кесте үшін файл жасайды және барлық жолдардың мәндерін ретімен сақтайды. Бағаналы дерекқорлар кестелеріңіздегі әрбір баған үшін файл жасайды. Бұл құрылым деректерді біріктіруге және белгілі бір сұрауларды тиімдірек орындауға мүмкіндік береді, бірақ деректердің осындай дерекқорлардың шектеулеріне сәйкес келетініне көз жеткізу керек.

Қай дерекқорды таңдау керек?

Дерекқорды таңдау әдетте көңілсіз мәселе болып табылады және көптеген опциялар қол жетімді болғандықтан, бұл өте қиын тапсырма сияқты көрінуі мүмкін. Жақсы жаңалық - тек біреуін таңдаудың қажеті жоқ. Барлық мүмкіндіктерді жүзеге асыратын және барлық жүйелік деректерге рұқсаты бар жалғыз монолитті қолданбаны жасаудың орнына микросервис деп аталатын басқа заманауи үлгіні пайдалануға болады : қолданбаны тәуелсіз қызметтер жинағына бөлу. Әрбір қызмет өзінің тар мәселесін шешеді және бұл мәселені шешуге ең қолайлы тек өзінің жеке деректер қорын пайдаланады.

Мұның бәрін қалай үйренуге болады?

Көптеген мәліметтер базасымен олардың барлығын үйрену мүмкін емес міндет болып көрінуі мүмкін. Жақсы жаңалық: мұны істеудің қажеті жоқ. NoSQL дерекқорларының бірнеше негізгі түрлері ғана бар және олардың қалай жұмыс істейтінін түсінсеңіз, басқаларын түсіну оңайырақ болады. Сондай-ақ, кейбір NoSQL дерекқорлары басқаларға қарағанда әлдеқайда жиі пайдаланылады, сондықтан күш-жігеріңізді ең танымал шешімдерге шоғырландырған дұрыс. Мұнда ең жиі қолданылатын NoSQL дерекқорларының тізімі берілген, менің ойымша, сізге қарау керек:

1. MongoDB . Нарықтағы ең танымал NoSQL дерекқоры болуы мүмкін. Егер компания реляциялық дерекқорды негізгі деректер қоймасы ретінде пайдаланбаса, ол MongoDB пайдаланады. Бұл жақсы құралдар жиынтығы бар икемді құжаттарды сақтау орны. Өзінің мансабының басында MongoDB кейбір жағдайларда деректерді жоғалту үшін жаман беделге ие болды , бірақ содан бері оның тұрақтылығы мен сенімділігі айтарлықтай жақсарды. Егер сіз көбірек білгіңіз келсе, осы MongoDB курсын қараңыз


2. DynamoDB . Егер сіз Amazon Web Services (AWS) қызметін пайдалансаңыз, DynamoDB туралы көбірек білгіңіз келеді. Бұл өте сенімді, масштабталатын, бай мүмкіндіктер жиынтығы және көптеген басқа AWS қызметтерімен интеграциясы бар кідірісі төмен дерекқор. Ең жақсы бөлігі - оны өзіңіз орналастырудың қажеті жоқ. Мыңдаған сұрауларды өңдей алатын масштабталатын DynamoDB кластерін орнату бірнеше рет басу арқылы жүзеге асады. Егер бұл сізді қызықтырса, осы курсты қарауыңызға болады.


3. Neo4j . Ең көп таралған графикалық мәліметтер базасы. Бұл графикалық деректер үлгісін пайдаланғысы келетіндерге қолайлы масштабталатын және тұрақты шешім. Егер сіз көбірек білгіңіз келсе, осы курстан бастаңыз .


4. Редис . Мұнда сипатталған басқа дерекқорлар негізгі қолданба деректерін сақтау үшін пайдаланылғанымен, Redis негізінен кэштерді жүзеге асыру және көмекші деректерді сақтау үшін пайдаланылады. Көптеген жағдайларда жоғарыда аталған дерекқорлардың бірі Redis-пен бірге пайдаланылады. Қосымша ақпарат алу үшін осы курсты қараңыз .

2018 жылы NoSQL көмегімен

NoSQL деректер базасы кең және жылдам дамып келе жатқан өріс болып табылады. Олар бұрын елестету мүмкін емес көлемдегі деректерді сақтауға және өңдеуге мүмкіндік береді, бірақ ол қымбатқа түседі. Бұл дерекқорларда реляциялық дерекқорларда таныс көптеген мүмкіндіктер жоқ және оларды пайдалану үшін өзіңізді орнату қиын болуы мүмкін. Бірақ олармен танысқаннан кейін сіз оқу және жазу сұрауларының таңғажайып көлемдерін өңдей алатын масштабталатын, таратылатын дерекқорлар жасай аласыз, бұл деректердің үлкенірек және үлкен көлемдері жасалғандықтан өте маңызды болуы мүмкін. Түпнұсқа: https://simpleprogrammer.com/guide-nosql-software-developers/