MongoDB — это современная нереляционная документо-ориентированная БД. В её развитии разработчики делают упор на легкую масштабируемость и высокую производительность.
В некотором смысле, её можно считать «золотой серединой» между реляционными БД (как MySQL) и чистыми хранилищами «ключ-значение» (как memcached). Вот её основные качества:
документо-ориентированность (нет жестко заданной схемы, документы хранятся в формате типа JSON),
индексы по любому атрибуту (или нескольким),
удобная репликация с автоматическим фейловером,
автомагический шардинг,
богатый язык запросов,
быстрые in-place апдейты (в отличие от append only движков),
Map / Reduce,
GridFS (подсистема хранения файлов любого размера).
Не «много», а «монго». (Не дибил, а диби…) =) MongoDB — это NoSQL-база, хранит хеши, ну в смысле вообще объекты с произвольным набором полей/вложенных структур данных (типа JSON). Был на небольшом кусочке, услышал в основном про автоматический шардинг — то есть масштабирование БД на набор серверов. Заключение — ну, оно это умеет и умеет прекрасно.
В первом рассказывалось про прелести MongoDB. Для своего класса задач — отличная штука. Класс задач, рассмотренный в докладе, можно описать как: «много линейных данных и обработка ложится в Map/Reduce с прозрачным масштабированием». Конкретно у докладчика на Mongo крутится популярное приложение для ВКонтакте, в котором можно отвечать на какие-то вопросы (я не сильно в курсе, но некоторые в зале по описанию поняли о чем речь).
Докладчик очень четко расставил все точки над i. Я раньше уже слушал несколько докладов про NoSQL, но только после этого доклада сильно проникся и многое осознал. Советую посмотреть запись, когда Стас ее выложит.
Слушал не с начала. Мой интерес к этой теме — представлять уровень развития NoSQL баз данных, их назначение — с тем, чтобы, возможно, начать применять в проектах. В общем, не секрет, что собственно реляционные возможности в реляционной базе данных во многих проектах используются ограниченно. Но их выбирают из-за высокого быстродействия в целом, а также из-за развитых механизмов управления транзакциями, резервного копирования, восстановления, репликаций. И NoSQL базы данных, обеспечив преимущество по скорости за счет своей более простотой организации сейчас наполняются теми механизмами, которые в реляционных БД, например, в Oracle — есть. Уровень зрелости сложно оценить по книгам, тут удобнее доклады тех людей, которые реально используют в своих проектах.
MongoDB очень удобно для прототипирования. Обеспечивает изменение структуры на лету. А еще можно использовать для динамических данных, настраиваемых при конфигурировании продукта. Например, сайт с опросами или CMS. По его оценке сайт для опросов — пара таблиц и 1200 строк, с mysql будет больше.
Очень быстрый доступ по keyvalue. Но не только так — есть 15-20 операций чтобы строить запросы, включая существование элемента в массиве, соответствие всех элементов заданному множеству и т.п. Для конкурентной работы — команда find and modify — документ ищем и сразу меняем, что задано. База данных — кластерная. И в кластер сразу заложено, что есть мастер и дубль, который в случае чего подхватит. А еще есть журнал и лог транзакций — на случай падения. Из инструментов отладки — встроенный профилятор, плюс логирование запросов. К сожалению, есть ограничение — 16М на документ.
При проектирвоании важно правильно расшарить данные, это ключ к масштабированию. Shard key — идентифицирует данные в кластере, он не изменяется — только копирование, а если для коллекции — надо сохранить на диск и загрузить, только так. Пример — user по email. Другой пример — пусть есть ленты пользователей. Можно расшаривать по постам (событиям). А можно — по пользователям. В первом случае лента — распределенная, запрос ленты пользователя пойдет на много серверов. А при падении сервера получается лента с дырками. Во втором случае — вся лента с одного сервера, это эффективно по нагрузке. При проблемах — система не работает с одного сервера. Еще пример с фотками. timestamp в ключе фотки приведет к тому, что все фотографии, загруженные в один момент времени, ложаится в один кластер — не эффективно, потому лучше timestamp+user или timestamp+hash.
Наращиваются механизмы фоновой оптимизации. Например, балансировка чанков в фоновом режиме. Был интересный пример, как сжать таблицу без остановки — включаем вторую ноду-реплику, перелдиваем, сжимаем, переливаем изменения мастера, мастер выключаем.
Рекомендации по быстродействию — в целом понятные, известные и по реляционным базам данных.
Когда делаете начальный импорт, лучше заранее сделать нужное количество чанков — чтобы это не делать в динамике на импорте.
Cached Counter. Атрибуты-массивы, но нет операции, выдающей длину. Патерн — храним с каждым списокм counter.
Covered index — чтобы быстро получать данные из индекса.
специальные индексы — для более быстрого доступа именно к последним данным.
Держать часть документов (временные) только в памяти.
Индексация документов при записи: больше индексов — медленнее.
Интересно, что бывает использование совсем не по назначению — просто Server side jscript…
Еще одна документо-ориентированная СУБД. Про возможности можно почитать на официальном сайте. Докладчик особый упор сделал на архитектуру развертывания, балансировку, примеры выбора shard key.
Интересный рассказ про MongoDB, продвинутую NoSQL базу. У автора доклада на ней крутиться приложение типа [1] для ВКонтакте, в пике — несколько сотен запросов в секунду.
Возможности хранилища
Документо-ориентированная
нет схемы
формат храненич — JSON
Server-Side JavaScript — «легкие» преобразования перед выдачей/сохранением
Индексы
составные
покрывающие
уникальные
разреженные
— создание индекса, однако, блокирует таблицу
Map/Reduce
GridFS — подсистема хранения файлов произвольного размера
JOIN’ов нет — нужно денормализовать.
Нет транзакций, только атомарные обновления документов
И, конечно, все это хорошо масштабируется и отказоустойчиво, примем без дополнительного конфигурирования.
Аппаратное
Живет все это дело на двух серверах с 48 гигабайтами оперативной памяти каждый.
MongoDB — современная нереляционная документо-ориентированная база данных. Eё можно считать золотой серединой между реляционными DB и чистыми хранилищами key-value (как memcached).
Основные качества:
Документо-ориентированность (документы хранятся в JSON-подобном формате)
Индексы по любому или нескольким атрибутам
Удобная репликация с автоматическим failover
Богатый язык запросов
Поддержка Map/Reduce
Подсистема хранения файлов любого размера — GridFS
Автоматический sharding
Масштабирование:
Автоматическое (нужно выбрать shard key)
Определить распределение данных
Трудно изменить ключ после назначения
Данные разбиваются на блоки (chunks) размером < 64Mb или 100000 объектов. В фоновом режиме работает балансировщик.
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
— создание индекса, однако, блокирует таблицу
JOIN’ов нет — нужно денормализовать.