MongoDB *

По катом будет совсем небольшое сравнение производительности MongoDB в случаях использования $or и $in логических операций в запросах. Надеюсь, что данная заметка сэкономит кому-нибудь рабочее время.

На тему «использование MongoDB вместо memcached» гуглится немало историй успеха. Такое ощущение, что есть широкий класс задач, для которых идея работает неплохо: прежде всего это проекты, где интенсивно используется тэгирование кэша. Но если вы попробуете, то заметите, что в MongoDB не хватает функции удаления из кэша записей, которые читаются реже всего (LRU — Least Recently Used). Как поддерживать размер кэша в разумных рамках? LRU — это, кстати, «конек» memcached; вы можете писать в memcached, не задумываясь о том, что ваш кэш переполнится; но как же быть с MongoDB?

Раздумывая над этим, я написал на Python небольшую утилиту CacheLRUd (выложена на GitHub). Это демон для поддержки LRU-удаления записей в различных СУБД (в первую очередь, конечно, в MongoDB). Ферма таких демонов (по одному на каждой MongoDB-реплике) следит за размером коллекции, периодически удаляя записи, к которым доступ на чтение производится реже всего. Отслеживание фактов чтения той или иной записи кэша происходит децентрализовано (без единой точки отказа) по протоколу, основанному на UDP (почему так? потому что «наивный» вариант — писать из приложения в мастер-базу MongoDB при каждой операции чтения — плохая идея, особенно если мастер-база окажется в другом датацентре). Читайте подробности чуть ниже.

Но зачем?

     Доброго времени суток, уважаемые читатели. В этом посте я хотел бы описать несколько примеров развертки mongoDB, отличия между ними, принципы их работы. Однако больше всего хотелось бы поделиться с вами практическом опытом шардирования mongoDB. Если бы этот пост имел план, он бы выглядел скорее всего так:

1. Вступление. Кратко о масштабировании
2. Некоторые примеры развертки mongoDB и их описание
3. Шардинг mongoDB

    Пункты 1 и 2 — теоретические, а номер 3 претендует на практическое руководство по поднятию кластера mongoDB и больше всего подойдет тем, кто столкнулся с этим в первый раз.

Поискал на хабре схожие статьи, нашел только Morphia — легкий ORM для MongoDB, управляемый аннотациями, ничего по связке Spring Data + MongoDB не нашлось, в связи с этим решил написать пост из раздела «для самых маленьких» по настройке и использованию связки Spring + MongoDB.

История

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

Окей, значит людям это нужно. На этом можно даже заработать денег. И единственная причина, по которой люди до сих пор этим не пользуются: вы не реализовали свою идею. Пока не реализовали.

И наконец, в один прекрасный день вы решили: “Сделаем это!”. И вот вы уже пытаетесь разобраться как реализовать бизнес-логику своего приложения, ту киллер-фичу, которая будет двигать продукт вперед. У вас есть идея как это сделать, и вы знаете, что способны на это. И вот вы говорите: “Готово! Работает!” У вас есть успешный прототип! Осталось только упаковать его в веб приложение.

“Окей, сделаем сайт,” говорите вы.

А только потом вы понимаете, что для этого нужно выбрать язык программирования; нужно выбрать (современную) платформу; нужно выбрать какие-то (современные) фреймворки; нужно настроить (и купить) хранилище, базы данных и хостинг; нужно обеспечить интерфейс для администрирования; нужно обеспечить контроль доступа и систему управления контентом.

Перед вами десятки и десятки архитектурных решений, которые необходимо принять. И вы не хотите ошибиться: требуются технологии, которые позволят вести быструю разработку, поддерживают постоянные итерации, максимальную эффективность, скорость, устойчивость и многое другое. Вы хотите быть бережливым (lean) и гибким (agile). Вы хотите использовать технологии, которые помогут вам быть успешным как в краткосрочной, так и в долгосрочной перспективе. А выбрать их далеко не всегда так просто.

“Я перегружен”, говорите вы и чувствуете себя перегруженным. Энергия уже не та, что была в начале. Вы пытаетесь собраться с мыслями, но работы слишком много. Прототип медленно блекнет и умирает.

Недавно я столкнулся с одной довольно тривиальной задачей, где мне нужно было случайным образом выбирать из базы посты, написанные пользователями сайта. Проект написан на Rails с использованием MongoDB в качестве базы данных и джем mongoid для работы с ней. Не то что бы задача была сложной для выполнения, но в то же время, на удивление, нет абсолютно простого решения на подобие sort_by_random или вроде того. Под катом пару примеров как это можно решить.

Внимание: тег «юмор».

И в заключение. Мы пришли к выводу, что MySQL — это прекрасная база данных для нашего сайта. Вопросы?

Да, у меня есть вопрос. Почему вы не использовали MongoDB? MongoDB — это горизонтально масштабируемая база данных, она не использует SQL или JOINы, поэтому обладает высокой производительностью.

Это прекрасный вопрос. Мы изучили несколько NoSQL баз данных и поняли, что все варианты пока ещё незрелы для применения на работающих проектах. MySQL — это проверенная база данных, которая используется во всём мире и имеет все необходимые нам функции.

Но она не масштабируется. Все знают, что реляционные базы данных не масштабируются, потому что они используют JOINы и записывают на диск.

Продолжение, начало здесь.

Эксперимент II: Index

Для этого эксперимента мы создали индексы на полях id и floatvalue (текстовые поля опустили, тему полнотекстового индекса затрагивать не будем, так как это материал для отдельной статьи). В качестве запросов использовались выборки из диапазонов:

• 10 000 < id < 100 000
• 200 000 < floatvalue < 300 000

Но для начала, необходимо оценить, насколько упала скорость вставки после добавления индексов. Для этого добавим еще по 250 000 записей в MongoDB и POstgreSQL.

Не так давно встала необходимость самостоятельно оценить производительность и ресурсоёмкость всё более набирающей популярность noSQL СУБД MongoDB. Для наглядности решил заодно сравнить её с производительностью PostgreSQL, которая также небезызвестна и активно используется.

Хотим «phpMyAdmin» (читай web GUI) для ноды

Отсутствие универсальных веб-интерфейсов для управления распространенными СУБД, несколько усложняет освоение Node.js, а разворачивать рядом другой веб-сервер и другой язык с инфраструктурой, ой как не хочется. Открывать порты и управлять базами, подключаясь с другого сервера или со своего рабочего компьютера — это и неудобно и есть соображения безопасности. Поэтому мы решили включить такой инструмент в платформу для веб-приложений Impress, которую анонсировали, о которой я немного писал и которая доступна в открытом коде для всеобщей пользы. Задумка такая: реализовать простой и удобный унифицированный интерфейс для СУБД, которые чаще всего применяются в связке с Node.js, позаботиться о быстром развертывании (просто скопировать папку) и независимости от среды. В бета-версии уже поддерживаются MySQL, MongoDB и в скором времени очередь дойдет до PostgreSQL и Oracle.

В интернете не так много статей о производительности GridFS, вот одна из них Serving files out of GridFS которая показывает, что отдача файлов из GridFS медленнее чем с диска в 6 раз.
Но в той статье есть недочет — в тестировании обращение идет к одному файлу, а при этом файл кешируется на уровне nginx либо файловой системы что дает отрыв по сравнению с GridFS. Да и неплохо проверить свежий GridFS, 3 года прошло как никак.
Поэтому я решил провести собственное тестирование, с обращением по разным именам файлов.

Есть 52 тыс файлов — постеры к фильмам, общий объем 2Гб, средняя картинка весит 40кб. Копия файлов на ext4, копия в GridFS.
Виртуалка 512Мб с 1 ядром. Ubuntu server 12.04 LTS 64bit, настройки Nginx/1.4.1 стандартные.
Тест рассчитан на low-cost сервер, для мощных серверов результаты будут другие.

Способы отдачи файлов:
1) Nginx — статика
2) Gevent через nginx
3) 2 x Gevent через nginx (балансировка)
4) Gevent напрямую
5) Gevent через nginx (unix socket)
для пунктов 2-5 использовался http сервер на Python + Gevent который отдавал файлы из GridFS

Способы нагрузки:
1) ol, t2 — Обращение к одному url, 2 потока
2) ol, t10 — Обращение к одному url, 10 потоков
3) t2 — Обращение к разным url, 2 потока
4) t10 — Обращение к разным url, 10 потоков

Впервые столкнувшись с MapReduce, я продолжительное время искал реальные примеры применения. Пресловутый поиск слов в тексте, встречающийся в каждой второй статье о MapReduce, искомым примером считать не будем. Наконец, на двух курсах по Big Data на Coursera, я нашёл не только живые примеры, но теоретическую подоплёку для более глубокого понимания происходящего. Возможность применить полученный багаж знаний не заставила себя долго ждать.

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

В последнее время набирает популярность семейство подходов и методологий обработки данных, объединенных общими названиями Big Data и NoSQL. Одной из моделей вычислений, применяемых к большим объемам данных, является технология Map-Reduce, разработанная в недрах компании Google. В этом посте я постараюсь рассказать о том, как эта модель реализована в нереляционной СУБД MongoDB.

Что касается будущего нереляционных баз вообще и технологии Map-Reduce в частности, то на эту тему можно спорить до бесконечности, и пост совершенно не об этом. В любом случае, знакомство с альтернативными традиционным СУБД способами обработки данных является полезным для общего развития любого программиста, так же как, к примеру, знакомство с функциональными языками программирования может оказаться полезным и для программистов, работающих исключительно с императивными языками.

Нереляционная СУБД MongoDB представляет данные в виде коллекций из документов в формате JSON и предоставляет разные способы обработки этих данных. В том числе, присутствует собственная реализация модели Map-Reduce. О том, насколько целесообразно применять именно эту реализацию в практических целях, будет сказано ниже, а пока ограничимся тем, что для ознакомления с самой парадигмой Map-Reduce эта реализация подходит как нельзя лучше.

Итак, что же такого особенного в Map-Reduce?

Суть проблемы

Бывают ситуации когда документы имеют много различных полей и необходимо иметь эффективные запросы по ним. Например есть документ описывающий человека:

{
    _id: 123,
    firstName: "John",
    lastName: "Smith",
    age: 25,
    height: 6.0,
    dob: Date,
    eyes: "blue",
    sign: "Capricorn",
    ...
}

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

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

В данной статье будет рассмотрена одна из новых возможностей MongoDB версии 2.4 — полнотекстовый поиск. Большая часть этой статьи будет вольным переводом документации, которая, к слову, очень подробная, но разрозненная. Здесь все будет собрано вместе. Так как этого для полноценной статьи мне показалось мало, я решил сравнить МонгоДБ с другой популярной программой для текстового поиска — Sphinx. Мое сравнение будет очень поверхностным, так как со Сфинксом я раньше не работал. Создам таблицу с 16 000 000 записей и посмотрю, кто быстрее.

Сегодня состоялся релиз финальной версии MongoDB 2.4. Одна из новых возможностей — поддержка полнотекстового поиска с морфологией и стоп-словами. Правда, пока только в экспериментальном режиме. Среди 15 поддерживаемых языков есть и русский, что очень радует.

Ещё одно заметное изменение — смена движка javascript. Вместо SpiderMonkey теперь используется V8. Довольно логичный шаг, теперь было бы неплохо посмотреть сравнительные тесты map-reduce.

Также можно отметить улучшения в индексировании и выборке гео-данных.

И ещё одно крупное изменение: добавление ролей пользователей и привилегий(read, readWrite, dbAdmin, clusterAdmin и т.д.). Посмотрим, что из этого выйдет.

Полный список изменений

Меня порадовало, что вместе с основным релизом вышла новая версия драйвера для C# с поддержкой новых возможностей.

Драйвер C#

Перевод этой статьи уже есть на хабре, но он ужасен и содержит ложную информацию.

Приветствую, искатели приключений! Путешествуя по территории индексации MongoDB хотя бы некоторое время, вы, возможно, познакомились с таким правилом: если ваш запрос содержит сортировку/порядок (orderby) – добавьте сортируемое поле в конец индекса который используется для запроса.

Во многих случаях когда запрос содержит равенство (то есть поиск конкретного значения, например, {“name”: “Charlie”}) данная мантра бывает весьма полезной.

Запрос

db.drivers.find({"country": {"$in": ["A", "G"]}}).sort({"carsOwned": 1})

Индекс

{"country": 1, "carsOwned": 1}

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

system.indexes

• Предисловие
• Настройка Amazon EC2
• Установка MongoDB
• Настройка репликации
• Что почитать

local.abstract

В этой статье я расскажу о том, как максимально безболезненно организовать репликацию MongoDB на базе Amazon EC2. Несомненно, существует отличная документация как по работе с Amazon EC2, так и по настройке MongoDB в целом и репликации в частности. Но, как известно, дьявол живёт в мелочах. И в этой статье я выделю те “мелочи”, которые более всего донимали меня.

23 января 2013 года будет создана первая в Украине MongoDB User Group. Мы хотим, чтобы больше людей изучили и полюбили более гибкую, масштабируемую, документо-ориентированную СУБД «MongoDB».

Зачем это необходимо? Мы создадим теплую и ламповую обстановку для задушевных технических бесед, каждый раз будут новые лица как среди докладчиков, так и среди участников, будем готовить действительно интересные презентации по MongoDB. Одним словом, регулярные мероприятия, на которые тратить время можно и нужно.

Первая встреча организована при поддержке внутреннего движение по свободному обмену знаниями Ciklum Practice Leaders, но это только начало.

UPD: для всех желающих организована прямая трансляция докладов на сайте сообщества http://mongoua.tk/
Вопросы докладчикам можно задавать с хеш-тегом #MongoUA