Представляю вашему вниманию мою презентацию о MongoDB
Кратко и обо всем, думаю будет полезно новичкам

http://www.slideshare.net/olegkachan/mon…

Tagged with →  

26 Responses to Представляю вашему вниманию

  1. RedSm:

    Познавательно. СтОит добавить про реализацию связей.

  2. EsiRU:

    справедливо

  3. MsdGood:

    Как-то очень совсем уж поверхностно, не?
    Пример с «управлением контентом» — а чем в такой ситуации MySQL с MyISAM не угодил, например? )

  4. RevSwet:

    пример действительно весьма странный и не раскрывает ни разу преемущества монго. И еще в достоинствах почему-то упущен момент с scheme-less фитчей. Очень удобно когда нет последовательностей из пачек миграций и инструкций create table/modify.

  5. Ppoed:

    У монги есть три фичи: map & reduce, sharding & replication и только уже потом вся это документно-ориентированная шняга. Для описанных задач, с таким-же успехом можно использовать всё что угодно, начиная от файлов в json.

    А вот когда восходит вопрос, как нам с наименьшими затратами хранить ебическое количество каких-то данных (например всякие метрики) и не просто хранить, а ещё и агрегировать эти данные, например просчитывая всякие там всякие дневные/недельные/суточные KPI или ещё какую ересь, вот именно тут начинается всё веселье. Начнётся оно примерно в тот момент, когда вы охуеете от того факта, что реплики создаются в два запроса, а шарды за 10 минут. А потом когда вы через пару часов ебли поднимите два вагона серверов, на двух континетах, на которых будет крутиться пачка реплицированных шардов, вы поймёте, что вся эта ебатень с schema-less это пиздец какой приятный бонус, но не самые главные фичи.

    Самым главным сайд-эффектом монги является тот факт, что ей надо неебически дохуя ресурсов: доебени памяти, доебени дискового пространства, доебени цпу для m&r (привет, жабадвигло). А schema-less превращает операцию «бля, нам надо переименовать колонку, щас я быстро ебану в один запрос» в «пиздец, нам надо переименовать поле, кто будет писать фоновую жевалку и как сделать так, чтобы пока она жуёт тридцать террабайт данных всё продолжало работать» и учит вопросу «если я назову аттрибут ohmfuckingattribute сколько гигабайт данных у меня будет просрано под это название» и после первого десятка гигабайт и запроса выполненого за 20 секунд учит делать индексы. А после недели пересчёта индексов учит правильно делать индексы. А после минутного запроса, учит правильно писать запросы, чтобы индексы работали.

    Так что не надо думать что монга это единорог который какает бабочками. В большинстве случаев если вы тупо услышали в интернетиках про монгу, она вам нахуй не нужна. А вот если вы неделю думали как бы эффективно хранить спецификации товаров, да ещё и так, чтобы можно было махом их потом сравнивать и делать хитровыебанные запросы по этим спецификациям или начали писать агрегатор данных, который тупо из бд их сосёт, агрегирует и потом снова запихивает в бд, то вероятно вам стоит на неё посмотреть.

  6. Kkebad:

    вот это я понимаю, познавательно

  7. EsiRU:

    ну вообще-то там schema less и описано, все хранится в одной коллекции, а не в трех таблицах для разного типа контента

  8. EsiRU:

    я сам считаю что для Mongo разработка базы данных — дело куда более ответственное, которому нужно уделить больше времени, чем для SQL-баз данных

  9. 01pSpb:

    лично у меня пока нет ощущения, что нужно все эти nosql юзать в продакшне налево и направо. Очень дохуя непонятных вопросов возникает. Как я вижу — бэкенд для статистики и прочей аналитической херни — клёво, как основное хранилище данных для среднестатистического сайта — пиздец как неудобно. А для бэкенда уж лучше риак заюзать, у него хотя бы m/r нормальный, в отличии от монго.

  10. RevSwet:

    говорят в райке map/reduce как раз медленный и если он частенько нужен лучше про райк не вспоминать. пруф http://lionet.livejournal.com/98362.html

  11. AsaEkb:

    1. А они уже спустили локи до уровня коллекций?
    2. m/r все еще однопоточный?

  12. Ppoed:

    1. Если я правильно понял что ты имеешь ввиду — помоему нет.
    2. Они сейчас переходят на V8, помоему в транке уже можно с ним собраться, но до продакшена далековато.

  13. AsaEkb:

    Я имел ввиду замену глобального дока на локи отдельных коллекций.

  14. Ppoed:

    А, ты имеешь ввиду write lock, которые обычно с fsync используется? Как мне кажется там что-то было в жире на этот счёт. В нашей вотчине это не очень большая проблема, так как есть реплики и залочить на запись реплику ничем страшным не грозит. Надо у нашего dba спросить, он в монге лучше меня разбирается 🙂

  15. Ppoed:

    *залочить на запись ноду в реплике

  16. Ppoed:

    Да, вон тикет в жире. In progress.

  17. AsaEkb:

    Спасибо тебе человече

  18. Ppoed:

    А что ненормального в m/r в монге? То, что его надо не на эрланге писать?. Нет, я конечно понимаю что какойнибудь хадуп или ещё что-то могут быть сильно эффективнее в плане скорости прожевывания m/r. Но их очень неудобно администрировать и они обычно требуют ещё более чем более дохуя ресурсов.

    Ну и да, жабаскрипт в монге это очень удобно.
    Можно например взять фронтэнд разработчика и заставить его написать m/r функции

  19. 01pSpb:

    ну в риаке тоже вполне себе яваскрипт, но он хотя бы многопоточный и асинхронный, в отличии от монго.
    : то, что там у лионета было — сложно назвать типичной ситуацией. у него одна из самых больших инсталляций риака, причем разворачиваемая весьма хаотично, оттуда и куча проблем.
    в плане аналитик всяких риак куда ближе к хадупу, чем к монго. но проигрывает монго по скорости реалтаймовой работы из-за этого.

  20. Wekef:

    Блин, как же ты вовремя! Мне после новогодних выходить работать с этой базой после нескольких лет на SQL. Прям как знак свыше 🙂

  21. LamYes:

    у меня тоько один вопрос — к couchDB вся эта критика насколько применима?

  22. Veaer:

    создатель CouchDB на днях вообще заявил — «всем спасибо, все свободны, я решил писать с нуля новую версию на C++, Erlang оказался медленный». Зовётся теперь это всё Couchbase. Правда те, кто уже вложились в Apache CouchDB(например, Cloudant), не очень этому рады и вроде как хотят взять разработку на себя.

    У MongoDB ситуация более стабильная. От версии к версии они стараются решать вышеописанные проблемы, но хранить бизнес-критикал данные я бы пока не рисковал, именно поэтому у нас вот уже несколько лет как Document-Oriented поверх обычного PostgreSQL.

  23. EsiRU:

    бодрячком! все проще чем кажется )

  24. Rehwhite:

    измение мышление! почитаю.

  25. Ppoed:

    Часть про документно-ориентированные базы (schema-less, ебическая важность индексов и прочего) относится к, сюрприз, любой документно-ориентированной базе, как следствие и к коучу. Про остальное сказать не смогу, увы.

  26. Ppoed:

    Да ладно вам, поднимаете три реплики, одна каждый N минут фигачит дампы, другая как hot swap и можно за данные не боятся 🙂 Учитывая что в монге с репликами проблем вообще нет.

    Кстати, монга — суверенная, демократичная база данных. Когда мастер упал, то все оставшиеся в живых ноды устраивают выборы нового мастера. Как следствие, если после падения мастера ноды останется две, то надо ещё псевдо-ноду арбитра. Главное чурову не говорите, а то все знают кто победит

Добавить комментарий