Няколко истини за MongoDB

През последната година MongoDB става все по-популярна база данни и колегите започва да я използват все повече. Факт е, че има сериозни преимущества пред релационните си събратя.

Заедно с добре подготвените и компетентни презентации и документации започнаха да се появяват и много подвеждащи такива. Което е в реда на нещата – нещо става модерно и веднага се появяват купчина специалисти, които дори не са си направили труда да прочетат документацията (а тя е доста интересна и полезна).

 Днес ми попадна една презентация, направена от хора, които взимат пари за да обучават по темата. Похвално, че си правят труда да образоват хората! Въпреки, че курса им е платен младежите от SoftAcad не са дочели документацита, а явно личи и че никога не са ползвали MongoDB в production environment.

От Screen-а в ляво можете да видите нещо доста интересно “Cons: no atomic operations, no validation”. След което хвърлете око на този документ.

MongoDB притежава едни от най-мощните и оптимизирани atomic операции!

Явно от SoftAcad са пропуснали, че в MongoDB е НЕ релационна база данни (което включва и липсата на релация между самите документ в една колекция) – много ме озадачава, че едно от основните преимущества на MongoDB е в графата “Const”!

От презентацията личи си, че младежите от SoftAcad са хора с опит в релационни бази данни, но без опит с не релационните - направили са си труда да направят презентация и да правят обучения, за които взимат пари, но за съжаление не са си направили труда да прочетат документацията.

Презентация е пълна с неточности, които могат да объркат представите на хората за MongoDB и като цяло за noSQL.

От презентацията става ясно, че “mongodb няма никакви сторед процедури”, е тук един линк е повече от достатъчен.

 

Мразя да хейтвам, но не понасям такива некадърни неща!

Свързани и подобни постове:

8 Responses to “Няколко истини за MongoDB”

  1. Станислав Георгиев says:

    Тъй като съм един от хората организирали този семинар, държа да отбележа, че семинара беше безплатен и отворен за хора, който искат да се запознаят с темата и се проведе в зала на ФМИ при СУ.

    По никакъв начин не са взимани пари за това. Както казах, това беше отворен семинар и в учебен център SoftAcad не са се провеждат платени курсове по темите MongoDB, CouchDB и като цяло за документно ориентирани бази данни.

    Колкото до допуснатите неточности, всички в екипа на SoftAcad сме отворени към позитивна критика. Така че благодарим за забележката. Все пак, семинара беше доста успешен и получихме много позитивни отзиви от хората които присъстваха на това БЕЗПЛАТНО събитие.

    Може би е добре, следващия път и вие да четете “документацията” в сайта, касаеща конкретното събитие.

    Поздрави,
    Станислав Георгиев.

  2. Danail Aleixev says:

    Първо – семинарът беше безплатен, а обучения по Document Oriented Databases не сме предлагали.
    Второ – след като ще хейтваш поне си направи труда да прегледаш докрай нещата. Около 15 пъти беше повторено, че липсват атомични операции в СМИСЪЛ НА ACID ТРАНЗАКЦИИТЕ ОТ RDBMS, но кой да си направи труда да изслуша. Уточнено беше също така, че Mongo гарантира, че един документ винаги ще бъде променен атомично. Относно stored процедурите – в началото на представянето на Mongo беше уточнено, че могат да се пишат каквито и както се намери на добре благодарение на JavaScript API, предлаган от Mongo.
    Обожавам хора, които дори не са си направили труда да погледнат нещо в детайли, но веднага му намират кусурите, изваждайки отделни изречения и изрази извън контекста.

    И за да ти върна услугата – явно не си прочел документацията на Монго докрай, защото ако беше никога нямаше да напишеш следното – “Явно от SoftAcad са пропуснали, че в MongoDB е НЕ релационна база данни (което включва и липсата на релация между самите документ в една колекция)”. Като отявлен специалист в Mongo би трябвало да знаеш, че съществува DBRef(collection, attribute), което е начин да се направи референция към документ от друга колекция – прилагам и документация – http://www.mongodb.org/display/DOCS/Database+References.

    Критиката е полезно нещо, това те кара да се развиваш и да дърпаш напред. Трябва, обаче, тя да е конструктивна, добре изказана и да е цялостна, не на различни парчета, чиито смисъл е изваден от контекста.

  3. Марто says:

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

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

    В презентацията ви има твърдение, че няма транзакции, което както ви писах не е вярно – има, но наистина не са във формата, която масово хората познават. И пак ще повторя – това е от една от най-силните страни на монго.

    Относно процедурите – хем твърдите, че ги няма, хем твърдите, че ги има? Последно? В крайна сметка, това е един от най-мощните инструменти в noSQL света!

    Относно DBRef вече става голям смях. DBRef е от значение само на ниво ДРАЙВЕР за MongoDB. Тоест няма нищо общо с релации на ниво сървър база данни. Не може да се сравнява нещо, което се прави при клиента, с нещо което се прави от страна на сървъра!

    Можем да си вадим от двевет гьола вода по темата, но истината е, че на мен не ми харесва отрицателното ви отношение към тази база данни, което усещам в презентацията ви. Да, MongoDB има много минуси от погледа на девелопър правещ малък сайт, но за компании с размера на Google, Foursquire, Sourceforge и една купчина други (http://www.mongodb.org/display/DOCS/Production+Deployments), при които размера на базата е наистина от значение, MongoDB е оценен подобаващо. Не е създаден за да си правите училищните сайтове с нея (за което SQL решенията с повече от подходящи), а за високи натоварвания и решаване на сериозни проблеми.

    Ако гледате от страна на това какви проблеми решава или ви се наложи да ги решавате, няма да има такова негативно мнение, напротив ще се радвате, че девелопърите на mongo са избрали да има такива atomic operations, както и липсата на релации (на ниво база, а не на драйвер).

  4. Yanko says:

    Здравей Марто,

    Нямам намерение да те “атакувам”, но след като твърдиш, че MongoDB “има сериозни преимущества пред релационните си събратя.” , а също така, че се използва за “решаване на сериозни проблеми” ми се иска да ти задам два въпроса:

    1. Кои са тези толкова сериозни проблеми, които според теб не биха могли да се решат посредством релационните бази от данни?

    2. Кои са сериозните разработки въз основата на MongoDB (до момента), заради които си заслужава човек да инвестира време и усилия в овладяването на MongoDB?

    Преди да ми отговориш, прегледай линка по-долу. :)

    http://punchcard.wordpress.com/2010/06/05/relational-dbms-vs-document-oriented-key-value-stores/

  5. Марто says:

    Yanko, например в ситуация, при която ти трябва да създаваш по няколко десетки хиляди записа в базата в секунда. Реализирано с MongoDB, например, това може да стане с едва няколко машини с шардинг. Конфигурирането на шардинга става за няколко минути, но дали с релационна база данни (например MySQL) това време ще ти стигне за да напишеш софтуер, който да праща записите към различни машини или пък да менажираш primary key по всички тези машини? Все неща, които излизат от кошничката на базата отиват на главата на програмиста.

    По втория въпрос изписах доста неща нагоре в темата и не ми се повтарят. Въпреки това ще резюмирам с няколко думи: не релационни бази данни са подходящи при голям обем данни и не особено структурирани данни. Ако те интересува потърси информация защо sourceforce избраха noSQL – там е един добър пример.

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

    Ето ти и един линк от мен:
    https://blog.gregbrockman.com/2012/05/high-availability-with-mongodb-for-fun-and-profit/

  6. Здравей, Янко

    MongoDB дава много преимущества, особено при работа върху мащабни проекти с голяма натовареност. През последните 10 год съм работил с най-различни бази данни (MySQL, MSSQL, Postgres). Сега имам удоволствието да се занимавам с изработване на сравнително голям проект, за който избрах да използвам MongoDB поради следните причини:
    1) Заявките в MongoDB са по-бързи (в моя случай, а и в много други виж тук например отговора, който е маркиран като верен http://stackoverflow.com/questions/9702643/mysql-vs-mongodb-1000-reads), защото вземам цялата информация за 1 обект с 1 заявка. При релационните бази нещата са малко по сложни заради нормализацията. В моя случай работя по социална мрежа. Вземайки данните за потребител, за да визуализирам неговия профил трябва да направя JOIN с доста други таблици (поне 10) ако използвам релационна база. Съответно това означава обхождане на още поне 10 индекса, като някои от които не са clustered index (предполагам, че знаеш какво означава това).
    2) Качване на промени по сайт – с MongoDB е много лесно, защото няма схема – няма нужда от сложни скриптове за добавяне/премахване на колони или смяна на тип на колона (когат това се налага), както и от мигриране на данните към новата схема. При MongoDB просто си качваш кода и не мислиш за базата, защото знаеш, че просто работи!!!!! (аз лично съм имал неприятен опит със грешки по LIVE сайт, защото нещо в схемата на базата не е обновено както трябва). Поне докато работих в Телерик преди години (а и не самотам) обновявахме сайта обикновено, когато не е натоварен през седмицата или в неделя. И имаше винаги кратък прериод от време, когато сайта показва “Under Maintenance” съобщение, докато променяме базата/базите данни. С MongoDB това не се налага, защото може 2 документа в дадена колекция (да се чете 2 реда в една таблица ако става дума за релационна база данни) да имат съвършенно различни полета (колони) без проблеми.

    3) Най-голямото предимство на MongoDB е това, че е създадена изцяло с идеята да е лесна за Horizontal Scaling. (http://docs.mongodb.org/manual/core/sharded-clusters/) – Когато имаш голямо натоварване много write и много read опреации MongoDB се справя безупречно.
    http://www.youtube.com/watch?v=b1BZ9YFsd2o <- доста полезно видео за начинаещи
    http://oreillynet.com/pub/e/1722

  7. Yanko says:

    Павел,

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

    Поздрави,
    Янко Манолов

  8. Здравей, Янко

    Подписал съм NDA, който ми забранява да издавам детайли за проекта на този етап – мога само да кажа, че е социална мрежа предназначена за спортисти. В момента все още е в затворена бета и се тества от хора в Дания и САЩ предимно. Ако се вълнуваш от подробности пиши на me [at] pavelnikolov [dot] net. Ще се постарая да отговоря на въпросите ти стига да мога.

    ~Павел
    Последнот от Павел Николов: Hello World!

Leave a Reply

CommentLuv badge