MongoDB срещу MySQL NoSQL - Защо Mongo е по-добър

Има толкова много системи за управление на бази данни (СУБД), от които да избирате, вариращи от релационни до нерелационни СУБД. През последните години, релационните СУБД, които са по-доминиращи, но с последните тенденции в структурата на данни, нерелационните СУБД стават все по-популярни. Изборът за релационна СУБД е доста очевиден:MySQL, PostgreSQL и MS SQL. От друга страна, MongoDB, нерелационен DBM, се е развил основно поради способността си да обработва голям набор от данни. Всеки избор има своите плюсове и минуси, но вашият избор ще се определя главно от нуждите на вашето приложение, тъй като и двете служат в различни ниши. Въпреки това, в тази статия ще обсъдим предимствата на използването на MongoDB над MySQL.

Предимства от използването на MongoDB над MySQL

1. Скорост и производителност
2. Висока наличност и облачни изчисления
3. Гъвкавост на схемата
4. Трябва да стане по-голям
5. Функция за вграждане
6. Модел на сигурност
7. Данни, базирани на местоположение
8. Поддръжка на богат език за заявки

Скорост и производителност

Това е едно от основните предимства на използването на MongoDB над MySQL, особено когато е включен голям набор от неструктурирани данни. MongoDB по подразбиране насърчава високата скорост на вмъкване пред безопасността на транзакциите. Тази функция не е налична в MySQL, следователно, ако искате да запишете много данни във вашия DBM наведнъж, в случай на MySQL ще трябва да го направите един по един. Но в случая на MongoDB, с наличието на функция insertMany(), можете безопасно да правите множеството вмъквания. Наблюдавайки някои от поведението на заявките на двете, можем да обобщим различните заявки за операции за 1 милион документа в илюстрацията по-долу.

В случай на актуализиране, което е операция на запис, MongoDB отнема 0,002 секунди, за да актуализира всички имейли на ученици, докато MySQL отнема 0,2491 секунди, за да изпълни същата задача.

От илюстрацията можем да заключим, че MongoDB отнема много по-малко време от MySQL за същите операции. MongoDB е основно структуриран така, че документите са основата на съхранението, което насърчава огромни заявки и съхранение на данни. Това означава, че производителността зависи от две ключови стойности, които са дизайнът и мащабирането. От друга страна, MySQL има данни, съхранявани в отделна таблица, следователно в един момент човек трябва да търси цялата таблица, преди да извърши операция за запис.

Висока наличност и облачни изчисления

За нестабилни среди MongoDB предоставя по-добра техника за работа от MySQL. Това е така, защото отнема много по-малко време на активните вторични възли да изберат нов първичен възел, като по този начин лесно администрирането в точката на повреда. Освен това, поради изчерпателни вторични индекси и собствена репликация, създаването на резервно копие за база данни MongoDB е доста лесно в сравнение с MySQL, тъй като последният има интегрирана поддръжка за репликация.

Накратко, настройването на набор от сървъри, които могат да действат като Master-Slaves, е лесно и бързо в MongoDB, отколкото в MySQL. Освен това възстановяването от повреда на клъстера е незабавно, автоматично и безопасно. За MySQL няма ясно официално решение за осигуряване на отказ между главен и подчинен в случай на повреда.

Базираните в облак решения за съхранение изискват данните да се разпространяват плавно в различни сървъри, за да се разширят. MongoDB може да зареди голям обем данни в сравнение с MySQL и с вградено разделяне е лесно да се разделят и разпределят данни на множество сървъри като начин за използване на решение за пестене на разходи според достойнствата за съхранение, базирано на облак.

Гъвкавост на схемата

MongoDB е без схема, така че различните документи в една и съща колекция могат да имат еднакви или различни полета един от друг. Това означава, че няма ограничение за структурата на документа за всяко вмъкване или актуализация, следователно промените в модела на данни няма да имат голямо влияние. Разбира се, има сценарии, които могат да изберат един да използва недефинирана схема, например, ако денормализирате схема на база данни или когато вашата база данни се разраства, но вашата схема е нестабилна. Следователно MongoDB позволява да се добавят различни типове данни според промяната на нуждите.

От друга страна, MySQL е ориентиран към таблица, при което всеки ред трябва да има същите колони като другите редове. Добавянето на нова колона ще изисква да се изпълни операция ALTER, която е доста скъпа по отношение на производителността, тъй като ще трябва да заключи цялата база данни. Това е особено в случая, когато таблицата нарасне над 10 GB, MongoDB няма този проблем.

С гъвкава схема е лесно да се разработи и поддържа по-чист код. Освен това, MongoDB предоставя опцията за използване на JSON валидатор, в случай че искате да гарантирате целостта и последователността на данните за вашата колекция, следователно можете да направите известна проверка преди вмъкване или актуализиране на документ.

Необходимостта да станете по-големи

Мащабирането на бази данни не е лесно начинание, особено с MySQL, може да доведе до влошаване на производителността, когато се надминат 5-10GB памет на таблица. С MongoDB това не е проблем, тъй като човек може да разделя и разделя базата данни с вградената функция за разделяне. След като е посочен ключ за разделяне и е активирано разделянето, данните се разделят равномерно според ключа на сегмента. Ако се добави нов фрагмент, има автоматично повторно балансиране. Разделянето основно позволява хоризонтално мащабиране, което е трудно за изпълнение в MySQL. Освен това MongoDB има вградена репликация, при която наборите реплики създават множество копия на данните. Всеки член на този набор има роля като основен или вторичен във всеки момент от процеса.

Четенията и записите се извършват на първичния и след това се репликират на вторичния. С тази заслуга, в случай на несъответствие на данните или неуспех на екземпляр, може да бъде гласуван нов член, който да действа като основен.

Функция за вграждане

За разлика от MySQL, където не можете да вградите данни в поле, MongoDB предлага по-добра техника за вграждане на свързани данни. Колкото и да можете да направите JOIN за таблици в MySQL, в крайна сметка може да имате толкова много таблици, като някои са ненужни, особено ако не включват толкова много полета. В случая на MongoDB можете да решите да вградите данни в поле за свързани данни или препратка от друга колекция, ако очаквате в бъдеще документът да нарасне над размера на документа JSON.

Например, ако имаме данни за потребители, които искаме да уловим техните адреси и някаква друга информация, в случая с MongoDB можем лесно да имаме проста структура като

{
    id:1,
    name:'George Bush',
    gender: 'Male',
    age:45,
    address:{
        City: 'New York',
        Street: 'Florida',
        Zip_code: 1342243
    }
}

Но в случая с MySQL ще трябва да направим 2 таблици с препратка към идентификатор в този случай. т.е.

Таблица с подробности за потребителите

Таблица с адреси на потребителя

В MySQL ще имате толкова много таблици, с които може да се работи толкова забързано, особено когато е включено мащабиране. Колкото и да може да се направи присъединяване към таблица в една заявка при извличане на тези данни в MySQL, латентността е доста по-голяма в сравнение с MongoDB и това е една от причините, поради които производителността на MongoDB превъзхожда производителността на MySQL.

Модел на сигурност

Администрирането на база данни (DBA) е много важно в MySQL, но не е необходимо в случая на MongoDB. Това означава, че трябва да имате DBA, за да модифицирате схема в случай на MySQL, когато приложение се промени. От друга страна, човек може да направи модифициране на схема без DBA в MongoDB, тъй като е чудесно за устойчивост на класа и клас може да бъде сериализиран в JSON и съхранен. Това обаче е най-добрата практика, ако не очаквате данните да нараснат, в противен случай ще трябва да следвате някои най-добри практики, за да избегнете клопки.

Данни, базирани на местоположение

За да подобри операциите с пропускателна способност, особено операциите за четене, MongoDB предоставя вградени специални функции, които подобряват намирането на подходящи данни от конкретни места, които са точни, като по този начин ускоряват процеса. Това не е възможно в случая на MySQL.

Поддръжка на богат език за заявки

От личен интерес като ентусиаст на MongoDB, получих своето привличане с гъвкавостта относно функцията за заявки на MongoDB. По отношение на рамката за агрегиране в по-късните версии и функцията MapReduce, може да се оптимизира данните за резултатите, за да отговарят на собствените спецификации. Доколкото MySQL предлага и операции като групиране, сортиране и много други, MongoDB е доста обширна, особено с вградени структури от данни. Освен това, както беше споменато по-рано, заявките се връщат с по-малко забавяне в рамката за агрегиране, отколкото когато трябваше да се направи JOIN в случая на MySQL. Например, MongoDB предлага лесен начин за модифициране на схема с помощта на операциите $set и $unset за вградената схема. Но в случая с MySQL човек трябва да изпълни командата ALTER за единствената таблица, в която съществува полето и това е доста скъпо по отношение на производителността.

Заключение

По отношение на достойнствата, обсъдени по-горе, доколкото изборът на база данни абсолютно зависи от дизайна на приложението, MongoDB предлага много гъвкавост в различни линии. Ако търсите нещо, което ще се погрижи за по-добра производителност, като работи със сложни данни, следователно няма нужда от ограничения по отношение на дизайна на схеми, бъдещи очаквания за растеж на базата данни и богата техника на езика на заявките, бих ви препоръчал да изберете MongoDB.