Мен мұны жақында білдім (лицензияның өзгеруіне байланысты дейді). Бұл мені ойлантты, өйткені соңғы бірнеше жылда мен MongoDB қаншалықты қорқынышты және оны ешкім ешқашан пайдаланбауы керек туралы көптеген мақалаларды көрдім. Бірақ осы уақыт ішінде MongoDB әлдеқайда жетілген өнімге айналды. Не болды? Барлық жек көрушілік шынымен жаңа ДҚБЖ ерте маркетингіндегі қателіктерге байланысты ма? Немесе адамдар MongoDB-ті дұрыс емес жерлерде қолданады ма?
Егер сіз мені MongoDB қорғайтындай сезсеңіз, оқыңыз мақаланың соңында.
Жаңа тренд
Мен бағдарламалық қамтамасыз ету саласында көп жылдар бойы жұмыс істеп келемін, бірақ мен әлі де біздің салаға әсер еткен тенденциялардың аз ғана бөлігіне ұшырадым. Мен 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain өсуінің куәсі болдым... тізім шексіз. Жыл сайын жаңа трендтер пайда болады. Кейбіреулер тез жоғалып кетеді, ал басқалары бағдарламалық жасақтаманы жасау тәсілін түбегейлі өзгертеді.
Әрбір жаңа тренд жалпы толқуды тудырады: адамдар бортқа секіреді немесе басқалар тудырған шуды көріп, көпшіліктің соңынан ереді. Бұл процесс Gartner компаниясында кодификацияланған . Қарама-қайшылық болса да, бұл уақыт шкаласы технологиялар пайдалы болғанға дейін не болатынын шамамен сипаттайды.
Бірақ мезгіл-мезгіл жаңа инновация пайда болады (немесе бұл жағдайда екінші рет келеді) тек бір ғана нақты енгізуге негізделген. NoSQL жағдайында хайпқа MongoDB-тің пайда болуы мен метеорлық көтерілуі себеп болды. MongoDB бұл тенденцияны бастамады: шын мәнінде, ірі интернет-компаниялар деректердің үлкен көлемін өңдеуде қиындықтарға тап бола бастады, бұл реляциялық емес мәліметтер базасының қайтарылуына әкелді. Жалпы қозғалыс Google-дың Bigtable және Facebook-тің Cassandra сияқты жобаларымен басталды, бірақ бұл MongoDB болды, ол көптеген әзірлеушілер қол жеткізе алатын ең танымал және қол жетімді NoSQL дерекқорын іске асыру болды.
Ескерту: Құжат дерекқорларын бағаналы дерекқорлармен, кілттер/мәндер қоймаларымен немесе жалпы NoSQL анықтамасына жататын деректер қоймаларының кез келген басқа түрлерімен шатастырып жатырмын деп ойлауыңыз мүмкін. Ал сіз дұрыссыз. Бірақ сол кезде хаос билеген. Барлығы NoSQL-ге құмар, ол бәріне айналды мүлдем қажет, дегенмен көпшілігі әртүрлі технологиялардағы айырмашылықтарды көрмеді. Көптеген адамдар үшін MongoDB болды синонимдер NoSQL.
Ал әзірлеушілер оған төтеп берді. Кез келген мәселені шешу үшін сиқырлы түрде масштабталатын схемасыз дерекқор идеясы өте қызықты болды. Шамамен 2014 жылы, бір жыл бұрын MySQL, Postgres немесе SQL Server сияқты реляциялық дерекқорды пайдаланған барлық жерде MongoDB дерекқорларын қолдана бастағандай көрінді. Неліктен деп сұрағанда, сіз «бұл интернеттің ауқымы» деген қарапайым жауаптан «менің деректерім өте еркін құрылымдалған және схемасыз дерекқорға жақсы сәйкес келеді» дегенге жауап ала аласыз.
MongoDB және жалпы құжаттық дерекқорлар дәстүрлі реляциялық дерекқорлармен бірқатар мәселелерді шешетінін есте ұстаған жөн:
- Қатаң схема: Реляциялық дерекқормен, егер сізде динамикалық түрде жасалған деректер болса, сіз кездейсоқ «әртүрлі» деректер бағандарының шоғырын жасауға, онда деректер блоктарын жылжытуға немесе конфигурацияны пайдалануға мәжбүрсіз. ...осының бәрінің елеулі кемшіліктері бар.
- Масштабтау қиындығы: Бір серверге сыймайтындай көп деректер болса, MongoDB оны бірнеше машиналарда масштабтауға мүмкіндік беретін механизмдерді ұсынды.
- Күрделі схема модификациялары: көші-қон жоқ! Реляциялық дерекқорда дерекқор құрылымын өзгерту үлкен мәселе болуы мүмкін (әсіресе деректер көп болған кезде). MongoDB процесті айтарлықтай жеңілдете алды. Және бұл өте оңай болды, сондықтан сіз өте жылдам қозғала отырып, схеманы жаңарта аласыз.
- Жазу өнімділігі: MongoDB өнімділігі жақсы болды, әсіресе дұрыс конфигурацияланғанда. Тіпті жиі сынға ұшыраған MongoDB конфигурациясы да әсерлі өнімділік сандарын көрсетті.
Барлық тәуекелдер сізде
MongoDB әлеуетті артықшылықтары, әсіресе мәселелердің белгілі бір кластары үшін өте үлкен болды. Егер сіз жоғарыда келтірілген тізімді контекстті түсінбей және тәжірибесіз оқысаңыз, MongoDB шынымен революциялық ДҚБЖ екендігі туралы әсер аласыз. Жалғыз мәселе жоғарыда аталған артықшылықтар бірқатар ескертулермен бірге келді, олардың кейбіреулері төменде келтірілген.
Әділ болу үшін, 10gen/MongoDB Inc-те ешкім жоқ. төмендегілер дұрыс емес деп айтпаймын, бұл жай ғана ымыраға келу.
- Жоғалған транзакциялар: Транзакциялар көптеген реляциялық дерекқорлардың негізгі мүмкіндігі болып табылады (барлығы емес, бірақ көпшілігі). Транзакция бірнеше әрекеттерді атомдық түрде орындай алатыныңызды және деректердің тұрақты болуын қамтамасыз ете алатыныңызды білдіреді. Әрине, NoSQL дерекқорымен транзакциялық бір құжаттың ішінде болуы мүмкін немесе транзакциялық семантиканы алу үшін екі фазалық міндеттемелерді пайдалануға болады. Бірақ бұл функцияны өзіңіз жүзеге асыруыңыз керек болады... бұл қиын және көп уақытты қажет ететін тапсырма болуы мүмкін. Дерекқордағы деректердің жарамсыз күйде аяқталуын көрмейінше, сіз жиі мәселе бар екенін түсінбейсіз, себебі операциялардың атомдылығына кепілдік берілмейді. Ескерту: Көптеген адамдар маған MongoDB 4.0 өткен жылы транзакцияларды енгізгенін айтты, бірақ кейбір шектеулер бар. Мақаладан алынған нәтиже өзгеріссіз қалады: технология сіздің қажеттіліктеріңізге қаншалықты сәйкес келетінін бағалаңыз.
- Қатынас тұтастығын жоғалту (шетелдік кілттер): Деректеріңізде қарым-қатынастар болса, оларды қолданбада қолдануыңыз керек. Осы қарым-қатынастарды құрметтейтін дерекқорға ие болу қосымшаның, демек, сіздің бағдарламашыларыңыздың көп жұмысын алады.
- Деректер құрылымын қолдану мүмкіндігінің болмауы: Қатаң схемалар кейде үлкен мәселе болуы мүмкін, бірақ олар сонымен қатар дұрыс пайдаланылған жағдайда деректерді жақсы құрылымдаудың қуатты механизмі болып табылады. MongoDB сияқты құжат дерекқорлары схеманың керемет икемділігін қамтамасыз етеді, бірақ бұл икемділік деректерді таза ұстау жауапкершілігін жояды. Егер сіз оларға қамқорлық жасамасаңыз, сіз күткен пішінде сақталмаған деректерді есепке алу үшін қолданбаңызда көп код жазасыз. Simple Thread компаниямызда жиі айтатынымыздай... қолданба бір күні қайта жазылады, бірақ деректер мәңгі өмір сүреді. Ескерту: MongoDB схеманы тексеруді қолдайды: ол пайдалы, бірақ реляциялық дерекқордағыдай кепілдіктерді бермейді. Ең алдымен, схеманы тексеруді қосу немесе өзгерту жинақтағы бар деректерге әсер етпейді. Деректерді жаңа схемаға сәйкес жаңартуды қамтамасыз ету сізге байланысты. Бұл сіздің қажеттіліктеріңізге жеткілікті ме, жоқ па, өзіңіз шешіңіз.
- Ана сұрау тілі / құрал экожүйесін жоғалту: SQL-тің пайда болуы абсолютті революция болды және содан бері ештеңе өзгерген жоқ. Бұл керемет күшті тіл, бірақ сонымен бірге өте күрделі. JSON фрагменттерінен тұратын жаңа тілде дерекқор сұрауларын құру қажеттілігі SQL-мен жұмыс істеу тәжірибесі бар адамдар үшін артқа жасалған үлкен қадам ретінде қарастырылады. IDE-ден есеп беру құралдарына дейін SQL дерекқорларымен өзара әрекеттесетін құралдардың бүкіл әлемі бар. SQL тілін қолдамайтын дерекқорға көшу бұл құралдардың көпшілігін пайдалана алмайтыныңызды білдіреді немесе оларды пайдалану үшін деректерді SQL тіліне аудару керек, бұл сіз ойлағаннан да қиын болуы мүмкін.
MongoDB-ге жүгінген көптеген әзірлеушілер айырбастарды шынымен түсінбеді және көбінесе оны негізгі деректер қоймасы ретінде орнатуға кірісті. Осыдан кейін қайтып оралу өте қиын болды.
Басқаша не істеуге болар еді?
Бәрі де басынан секіріп, түбіне тиген жоқ. Бірақ көптеген жобалар MongoDB-ны жай сәйкес келмейтін жерлерде орнатты - және олар онымен көптеген жылдар бойы өмір сүруге мәжбүр болады. Егер бұл ұйымдар біраз уақыт өткізіп, өздерінің технологиялық таңдауларын әдістемелік тұрғыдан ойластырса, көпшілігі әртүрлі таңдаулар жасаған болар еді.
Дұрыс технологияны қалай таңдауға болады? сияқты технологияларды бағалаудың жүйелі негізін құруға бірнеше әрекет жасалды и , бірақ маған бұл қажетсіз күрделілік сияқты.
Көптеген технологияларды тек екі негізгі сұрақ қою арқылы ақылды түрде бағалауға болады. Мәселе оларға жауап бере алатын адамдарды табуда, жауаптарды іздеуге уақыт бөлуде және біржақтылықсыз.
Егер сізде ешқандай проблема болмаса, сізге жаңа құрал қажет емес. Нүкте.
1-сұрақ: Мен қандай мәселелерді шешуге тырысамын?
Егер сізде ешқандай проблема болмаса, сізге жаңа құрал қажет емес. Нүкте. Шешімін іздеп, содан кейін мәселені ойлап табудың қажеті жоқ. Жаңа технология бұрыннан бар технологияға қарағанда әлдеқайда жақсырақ шешетін мәселеге тап болмасаңыз, мұнда талқылайтын ештеңе жоқ. Егер сіз осы технологияны басқалардың қолданып жатқанын көргендіктен пайдалануды ойласаңыз, олар қандай мәселелерге тап болып жатқанын ойлап, сізде сол мәселелердің бар-жоғын сұраңыз. Технологияны қабылдау оңай, өйткені оны басқалар пайдаланады, мәселе сізде бірдей мәселелерге кезігетінін түсіну.
2-сұрақ: Маған не жетіспейді?
Бұл, әрине, қиынырақ сұрақ, өйткені сізге ескі және жаңа технологияны тереңірек білуге және жақсы түсінуге тура келеді. Кейде сіз онымен бірдеңе құрастырмайынша немесе осындай тәжірибесі бар біреу болмайынша, жаңасын шынымен түсіне алмайсыз.
Егер сізде екеуі де жоқ болса, онда бұл құралдың құнын анықтау үшін ең аз мүмкін болатын инвестиция туралы ойлану керек. Инвестиция жасағаннан кейін шешімді қайтару қаншалықты қиын болады?
Адамдар әрқашан бәрін бұзады
Бұл сұрақтарға мүмкіндігінше бейтарап жауап беруге тырысқанда, бір нәрсені есте сақтаңыз: адам табиғатымен күресуге тура келеді. Технологияны тиімді бағалау үшін еңсеру керек бірқатар когнитивті бейімділіктер бар. Мұнда бірнешеу ғана:
- - ол туралы бәрі біледі, бірақ онымен күресу әлі де қиын. Тек технологияның нақты қажеттіліктеріңізге сәйкес келетініне көз жеткізіңіз.
- — Көптеген әзірлеушілер ұзақ уақыт бойы жұмыс істеген технологияларды бағаламауға және жаңа технологияның артықшылықтарын асыра бағалауға бейім. Бұл жай ғана бағдарламашылар емес, әркім бұл когнитивті бейімділікке бейім.
- – Біз не барын көріп, не жетіспейтінін ұмытып кетеміз. Бұл жаңашылдық әсерімен үйлескенде хаосқа әкелуі мүмкін, өйткені сіз жаңа технологияны жоғары бағалап қана қоймай, оның кемшіліктерін де елемейсіз..
Объективті бағалау оңай емес, бірақ негізгі когнитивтік қисынды түсіну сізге ұтымды шешімдер қабылдауға көмектеседі.
Резюме
Жаңалық пайда болған кезде екі сұраққа өте мұқият жауап беру керек:
- Бұл құрал нақты мәселені шеше ме?
- Біз айырбастарды жақсы түсінеміз бе?
Осы екі сұраққа сенімді түрде жауап бере алмасаңыз, бірнеше қадам артқа шегініп, ойланыңыз.
Сонымен, MongoDB дұрыс таңдау болды ма? Әрине, иә; Көптеген инженерлік технологиялар сияқты, бұл көптеген факторларға байланысты. Осы екі сұраққа жауап бергендердің ішінде көпшілігі MongoDB-тің пайдасын көрді және оны жалғастыруда. Олай болмағандар үшін сіз хайп циклі арқылы өту туралы құнды және тым ауыр емес сабақ алдыңыз деп үміттенемін.
Ескерту
Мен MongoDB-мен махаббат та, жек көрушілік те жоқ екенін түсіндіргім келеді. Бізде MongoDB шешуге ең қолайлы проблемалар болған жоқ. Мен 10gen/MongoDB Inc. бастапқыда өте батыл болды, қауіпті әдепкі мәндерді орнатып, MongoDB-ті кез келген деректермен жұмыс істеуге арналған әмбебап шешім ретінде барлық жерде (әсіресе хакатондарда) алға тартты. Бұл дұрыс емес шешім шығар. Бірақ бұл мұнда сипатталған тәсілді растайды: бұл проблемаларды тіпті технологияны үстірт бағалау кезінде де тез анықтауға болады.
Ақпарат көзі: www.habr.com