MongoDB

Вторую неделю экспериментирую с MongoDB . Для тех кто не знает — это такая экспериментальная база данных ориентированное на хранение в виде документов (document-based), похожая на CouchDb по идеологии и по принципам работы.

По результатам впечатления смешанные.

С одной стороны к плюсам можно отнести то что:

  • MongoDb существенно быстрее чем CouchDb, и в части записи, и в части чтения
  • гораздо удобнее хранить бинарные файлы и блоки так как вместо JSON используется формат BSON ориентированный как раз на двоичные данные.
  • индексирование работает на любом уровне иерархии внутри объектов. А то есть если есть объект документ и внём подэлементы разделов и внутри их подъэлементы заголовков то можно построить индекс прямо по этим заголовкам.  Выглядеть это будет примерно так coll.ensure_index(‘document.topics.title’, 1)
  • сервер вполне тянет базу в несколько миллионов объектов — я лично прогружал до миллиона и с базой до 3 гигабайт.
  • простота маштабирования: примеры с несколькими экземплярами и распределением данных идут прямо в поставке
  • подробная и качественная документация, большое число примеров и драйверов под все популярные языки: Java, CPP, Python, Perl, Ruby

Но, выявились и весьма существенные минусы:

  • полнотекстовое индексирование отсутствует. Можно пойти путём описанном в вики проекта, а можно настроить внешний индексатор вроде того Sphinx через xmlpipe, но в любом случае требуются лишние существенные усилия.
  • интеграция с тем же Sphinx’ом и рядом других приложений усложняется тем что по умолчанию в MongoDb все идентификаторы — это блок в 12 байт и нужно, либо заменять все ID на int32 у объектов, или добавлять свои параллельно.
  • цена производительности MongoDB — надежнность. В частности при холодной перезагрузке компьютера во время записи в базу MongoDB вероятность что она потом читаться не будет очень высока. Лично столкнулся с этим когда мой ноутбук перегрелся и отключился во время одного из экспериментов — в результате база в несколько гигабайт пришла в неработоспособное состояние. Спасло лишь то что есть команда на восстановление, но для базы в 3 гигабайта выполняется она порядка 30 минут
  • … ещё одно последствие упавшей базы  в том что после восстановления как минимум у части объектов сменились уникальные ID. В результате там где в связках таблиц использовались они — нарушение связей и спасти тут может лишь использование собственных ключей.

Как резюме — инструмент интересный и полезный, но использовать его следует с оглядкой на проблемы выше.

About This Author

  • http://twitter.com/chertov Chertov Max

    Здравствуйте! Вы не пробовали использовать C++ либу клиента.
    Я собирал свой проект, компилит нормально, при линковке какая-то хрень. Причем, насколько я понял, это только линковщик Visual Studio 2008 что-то не корректно собирает.
    Вы пробовали собирать клиента на С++ под виндой с помощью VS2008?
    Спасибо!

    • http://ivan.begtin.name Ivan Begtin

      Я C++ клиентом вообще не пользовался. Попробуйте задать вопрос в их списке рассылки на Google Groups http://groups.google.com/group/mongodb-dev

  • kristina1

    (I work on MongoDB. I read this using Google Translate, so I might have misunderstood parts of your post.)

    A lot of users have requested better durability, so we're working on make 1.2 better at recovering from crashes. We didn't do this initially as MongoDB is intended to be used on big server setups, where the main concerns are eventual disk corruption/failure, not the machine suddenly shutting down.

    • http://ivan.begtin.name Ivan Begtin

      Hi, Kristina.

      Thanks for answer.

      Durability is just one of the problems. Another one is 2.5 GB limitation for 32-bit servers. I understand that it's result of mmap limitation, but for horisontal scaling using low level Amazon EC2 servers it's not good. For example right now I have lot's of EC2 servers of «Small» type. It's 32-bit servers, so I have to launch up to 5 MongoDb instances and to use custom sharding.

      • Kristina

        Yeah, sorry, you can't really get around that one. We assume people are running 64-bit servers in production.

  • Guest

    Yeah, sorry, you can't really get around that one. We assume people are running 64-bit servers in production.

  • http://twitter.com/sergey_shepelev Sergey Shepelev

    Иван, спасибо вам за полезный пост. Чужой опыт всегда очень ценен. :)

    Мы использовали Mongo 0.8 из питона и наткнулись на жуткие тормоза при попытке достать из базы большое количество объектов (тысячи, десятки тысяч). Разработчики сказали, что запрос отрабатывается очень быстро, и потом почему-то очень большие тормоза на доставке результатов в питон. И небольшой гемор с Java тогда ещё был. Сейчас нет.

    Ещё видел пост (сейчас почему-то не смог найти), где рассказывают, что delete лочит не то всю коллекцию, не то всю базу. Можно отнести в минуса, если приложение часто удаляет объекты.

    Странно, что FTS для вас существенный минус. Внешний индексатор типа Xapian справится же намного лучше. Чем делать 10 фич в одном проекте, лучше если люди сделают одну, но хорошо, правда?

  • http://twitter.com/apetrushin Alexey Petrushin

    мой небольшой проектик на монго company.4ire.net
    фултекст поиск солром можно сделать, я делал работает нормально, правда из0за кучи багов на которые щас нет времени временно выключил :).

Яндекс.Метрика