Заканчиваются курсы по MongoDB для разработчиков и архитекторов баз данных от 10gen, компании разработчика MongoDB.
Финальный экзамен отправлен на проверку и хотелось бы поделиться впечатлениями от курса и полученной информации, рассказать о плюсах и «минусах» MongoDB.
Я записался сразу на два курса, для DBA и для разработчиков. В целом нагрузка не слишком большая, в неделю уходило 3-4 часа на просмотр видео и 1-2 часа на домашнее задание в очень неспешном темпе. При желании я думаю временные затраты можно сократить раза в два.
В целом впечатления положительные. Несмотря на то, что большинство информации, которое представлено на курсах можно почерпнуть из официальной документации, осваивать материал через курсы гораздо интереснее. Я и раньше слышал о MongoDB и пару раз «щупал» что это такое, но после курсов появляется более глубокое понимание возможностей и сферы применения этой базы данных. Поначалу были кое-какие накладки. Несколько моментов были связаны с формулировками вопросов, которые подразумевали неоднозначные ответы, но воможно это была проблема с пониманием английского языка. Затем было пару проблем с обнулением результатов, и кое-какие накладки из-за урагана Сэнди. Был веселый вопрос, который я назвал «Mission Impossible», в котором надо было выбрать один из трех вариантов ответа. При этом для ответа на вопрос дается обычно три попытки.
Репликация настраивается легко: запускаются серверы с указанием имени реплики, настраивается конфиг, участники реплики выбирают PRIMARY сервер, остальные становятся SECONDARY серверами. При этом можно настроить приоритеты для каждого сервера, можно вообще запретить серверу становиться PRIMARY. PRIMARY сервер позволяет производить операции запись-чтение, с SECONDARY серверов можно только читать.
При падении сервера есть много нюансов, в зависимости от того, SECONDARY или PRIMARY сервер упал, была ли запись в PRIMARY сервер после того как он стал недоступен и был выбран новый PRIMARY сервер и т.п. Но в целом в большинстве случаев восстановление работы реплики автоматизировано и не потребует ручного вмешательства, кроме как поднять упавший сервер.
Если у вас большой объем данных в коллекции и она не вместится на один сервер — ее можно разнести на несколько серверов, при этом работа с этой коллекцией на уровне приложения не потребует изменений. Для шардинга выбирается ключ, по этому ключу составляются диапазоны для каждого шарда. При этом если я правильно помню, решардинг при изменении диапазонов происходит автоматически в горячем режиме. При этом есть нюанс, после того как колекция была разнесена по серверам сменить ключ для шардинга в автоматическом режиме нельзя.
Сейчас многие стартапы или соц. сети используют функционал вида: найти что-то, не дальше чем X км от пользователя. Вот для такого функционала в MongoDB можно использовать географические индексы.
На мой взгляд отсутствие схемы в MongoDB позволяет ускорить разработку проекта. Не надо детально прорабатывать структуру базы данных на начальном этапе, заботиться о реализации связей, потом когда проект расширяется, детализируется — разрабатывать план миграции данных и т.п. В MongoDB наоборот, на этапе «прототипа» можно быстро запустить проект, устраивая в базе «разброд и шатание», потом уже когда проект начнет расти, оформится во что-то более осязаемое и появится необходимость — приводить базу данных в более нормализованный вид.
При создании таких коллекций необходимо указать количество записей, который могут храниться в коллекции. При вставке, если коллекция уже заполнена — будет перезатерта самая старая запись. Можно сравнить с записью по часовой стрелке на окружности, в которой есть определенное количество сегментов. Полезная коллекция, если необходимо хранить самую последнюю, актуальную информацию, а старая информация не интересует.
С помощью данного фреймворка можно из исходных данных формировать выборки с группировкой, суммированием, подсчетом записей и т.п. По сути это реализация GROUP BY, COUNT, HAVING и т.п. конструкций в SQL. Исходные данные проходят через массив так называемых pipe, которые преобразовывают данные и отдают их в следующий pipe. Очень похоже на консольные команды вида: «cat file | grep boobs | grep -v small».
Если возможностей Aggregation Framework недостаточно, можно использовать MapReduce функционал. На вход map функции подаются данные, преобразуются и подаются на вход reduce функции.
Если у вас есть запись вида: {a: [1, 2], b: [1, 2]} — создать индекс {a: 1, b: 1 } не получится. Собственно как и вставить подобную запись с полями, которые проиндексированы. Подробнее тут, ищите «Compound Multikey Indexes May Only Include One Array Field»
Допустим у нас есть записи в коллекции:
{ "_id": ObjectId(«50caeec479705c3852e9e61b»), «a»: «1» }
{ "_id": ObjectId(«50caeeeb79705c3852e9e61d»), «a»: «2», 'b': 1 }
{ "_id": ObjectId(«50caefb179705c3852e9e621»), «a»: «3» }
и мы хотим чтобы свойство «b» у документов было уникальным. Создать обычный уникальный индекс не получится, первая и третья запись будет считаться что b: null и это нарушает уникальность.
Но мы можем создать уникальный sparse индекс, и тогда записи, которые не имеют «b» будут не включены в этот индекс. Казалось бы все хорошо, индекс создали, уникальность есть. Но! Если допустим мы попросим выбрать все записи из нашей коллекции и попросим их отсортировать по полю b, MongoDB использует созданный нами sparse индекс, в котором отсутствуют записи без «b». В результате на выходе мы получим только одну запись.
В курсе неоднократно отмечалось, что в MongoDB удобно хранить документы, так, как они используются для вывода. Допустим у вас есть блог, там комментарии. Рядом с комментарием выводится имя автора и email. Удобно в объекте, который хранит комментарий также хранить информацию об авторе. Соответственно если у вас что-то поменяется в этом плане — есть вероятность, что надо будет изменять место хранения данных. В принципе это не совсем уж подводный камень и вероятность такого развития событий мала, но что-то в этом утверждении мне не особо понравилось.
После того, как коллекция была разнесена, поменять ключ автоматически не получится. Поэтому выбор ключа очень важная операция. Подробнее docs.mongodb.org/manual/faq/sharding/#faq-change-shard-key
Операция над одним документом атомарна, а вот для нескольких докуметов предлагается использовать транзакции на уровне приложения docs.mongodb.org/manual/tutorial/perform-two-phase-commits
Отличные курсы. MongoDB подкупает своей гибкостью и простотой, ее использование в различных ситуациях весьма и весьма оправдано.
Если у кого возникло желание пройти курсы, 21 января курсы стартуют еще раз. Так же 25 февраля стартуют курсы для Java-разработчиков. https://education.10gen.com/
Финальный экзамен отправлен на проверку и хотелось бы поделиться впечатлениями от курса и полученной информации, рассказать о плюсах и «минусах» MongoDB.
Общее впечатление от курса
Я записался сразу на два курса, для DBA и для разработчиков. В целом нагрузка не слишком большая, в неделю уходило 3-4 часа на просмотр видео и 1-2 часа на домашнее задание в очень неспешном темпе. При желании я думаю временные затраты можно сократить раза в два.
В целом впечатления положительные. Несмотря на то, что большинство информации, которое представлено на курсах можно почерпнуть из официальной документации, осваивать материал через курсы гораздо интереснее. Я и раньше слышал о MongoDB и пару раз «щупал» что это такое, но после курсов появляется более глубокое понимание возможностей и сферы применения этой базы данных. Поначалу были кое-какие накладки. Несколько моментов были связаны с формулировками вопросов, которые подразумевали неоднозначные ответы, но воможно это была проблема с пониманием английского языка. Затем было пару проблем с обнулением результатов, и кое-какие накладки из-за урагана Сэнди. Был веселый вопрос, который я назвал «Mission Impossible», в котором надо было выбрать один из трех вариантов ответа. При этом для ответа на вопрос дается обычно три попытки.
Сильные стороны
Репликация (manual)
Репликация настраивается легко: запускаются серверы с указанием имени реплики, настраивается конфиг, участники реплики выбирают PRIMARY сервер, остальные становятся SECONDARY серверами. При этом можно настроить приоритеты для каждого сервера, можно вообще запретить серверу становиться PRIMARY. PRIMARY сервер позволяет производить операции запись-чтение, с SECONDARY серверов можно только читать.
При падении сервера есть много нюансов, в зависимости от того, SECONDARY или PRIMARY сервер упал, была ли запись в PRIMARY сервер после того как он стал недоступен и был выбран новый PRIMARY сервер и т.п. Но в целом в большинстве случаев восстановление работы реплики автоматизировано и не потребует ручного вмешательства, кроме как поднять упавший сервер.
Шардинг (manual)
Если у вас большой объем данных в коллекции и она не вместится на один сервер — ее можно разнести на несколько серверов, при этом работа с этой коллекцией на уровне приложения не потребует изменений. Для шардинга выбирается ключ, по этому ключу составляются диапазоны для каждого шарда. При этом если я правильно помню, решардинг при изменении диапазонов происходит автоматически в горячем режиме. При этом есть нюанс, после того как колекция была разнесена по серверам сменить ключ для шардинга в автоматическом режиме нельзя.
Географические индексы (manual)
Сейчас многие стартапы или соц. сети используют функционал вида: найти что-то, не дальше чем X км от пользователя. Вот для такого функционала в MongoDB можно использовать географические индексы.
Schemaless
На мой взгляд отсутствие схемы в MongoDB позволяет ускорить разработку проекта. Не надо детально прорабатывать структуру базы данных на начальном этапе, заботиться о реализации связей, потом когда проект расширяется, детализируется — разрабатывать план миграции данных и т.п. В MongoDB наоборот, на этапе «прототипа» можно быстро запустить проект, устраивая в базе «разброд и шатание», потом уже когда проект начнет расти, оформится во что-то более осязаемое и появится необходимость — приводить базу данных в более нормализованный вид.
Capped коллекции (manual)
При создании таких коллекций необходимо указать количество записей, который могут храниться в коллекции. При вставке, если коллекция уже заполнена — будет перезатерта самая старая запись. Можно сравнить с записью по часовой стрелке на окружности, в которой есть определенное количество сегментов. Полезная коллекция, если необходимо хранить самую последнюю, актуальную информацию, а старая информация не интересует.
Aggregation framework (manual)
С помощью данного фреймворка можно из исходных данных формировать выборки с группировкой, суммированием, подсчетом записей и т.п. По сути это реализация GROUP BY, COUNT, HAVING и т.п. конструкций в SQL. Исходные данные проходят через массив так называемых pipe, которые преобразовывают данные и отдают их в следующий pipe. Очень похоже на консольные команды вида: «cat file | grep boobs | grep -v small».
Map-Reduce (manual)
Если возможностей Aggregation Framework недостаточно, можно использовать MapReduce функционал. На вход map функции подаются данные, преобразуются и подаются на вход reduce функции.
Подводные камни
Ограничение составных (compound) индексов
Если у вас есть запись вида: {a: [1, 2], b: [1, 2]} — создать индекс {a: 1, b: 1 } не получится. Собственно как и вставить подобную запись с полями, которые проиндексированы. Подробнее тут, ищите «Compound Multikey Indexes May Only Include One Array Field»
Sparse индекс и уникальность (manual, Sparse Indexes)
Допустим у нас есть записи в коллекции:
{ "_id": ObjectId(«50caeec479705c3852e9e61b»), «a»: «1» }
{ "_id": ObjectId(«50caeeeb79705c3852e9e61d»), «a»: «2», 'b': 1 }
{ "_id": ObjectId(«50caefb179705c3852e9e621»), «a»: «3» }
и мы хотим чтобы свойство «b» у документов было уникальным. Создать обычный уникальный индекс не получится, первая и третья запись будет считаться что b: null и это нарушает уникальность.
Но мы можем создать уникальный sparse индекс, и тогда записи, которые не имеют «b» будут не включены в этот индекс. Казалось бы все хорошо, индекс создали, уникальность есть. Но! Если допустим мы попросим выбрать все записи из нашей коллекции и попросим их отсортировать по полю b, MongoDB использует созданный нами sparse индекс, в котором отсутствуют записи без «b». В результате на выходе мы получим только одну запись.
Зависимость от интерфейсов приложения
В курсе неоднократно отмечалось, что в MongoDB удобно хранить документы, так, как они используются для вывода. Допустим у вас есть блог, там комментарии. Рядом с комментарием выводится имя автора и email. Удобно в объекте, который хранит комментарий также хранить информацию об авторе. Соответственно если у вас что-то поменяется в этом плане — есть вероятность, что надо будет изменять место хранения данных. В принципе это не совсем уж подводный камень и вероятность такого развития событий мала, но что-то в этом утверждении мне не особо понравилось.
Нельзя сменить shard key
После того, как коллекция была разнесена, поменять ключ автоматически не получится. Поэтому выбор ключа очень важная операция. Подробнее docs.mongodb.org/manual/faq/sharding/#faq-change-shard-key
Отсутствие транзакций в пределах нескольких документов
Операция над одним документом атомарна, а вот для нескольких докуметов предлагается использовать транзакции на уровне приложения docs.mongodb.org/manual/tutorial/perform-two-phase-commits
Вывод
Отличные курсы. MongoDB подкупает своей гибкостью и простотой, ее использование в различных ситуациях весьма и весьма оправдано.
Если у кого возникло желание пройти курсы, 21 января курсы стартуют еще раз. Так же 25 февраля стартуют курсы для Java-разработчиков. https://education.10gen.com/
