Курсы MongoDB для разработчиков и архитекторов баз данных из 10 поколение , компания, стоящая за MongoDB. Итоговый экзамен отправлен на проверку и мне хотелось бы поделиться впечатлениями от курса и полученной информацией, рассказать о плюсах и минусах MongoDB.
Общее впечатление от курса
Я записался сразу на два курса, для администраторов баз данных и для разработчиков.В целом нагрузка была не слишком большой; в неделю уходило 3-4 часа на просмотр видео и 1-2 часа на выполнение домашних заданий в очень неторопливом темпе.
При желании, думаю, временные затраты можно сократить вдвое.
В целом впечатления положительные.
Несмотря на то, что большую часть информации, представленной на курсах, можно почерпнуть из официальной документации, осваивать материал на курсах гораздо интереснее.
Я слышал о MongoDB раньше и пару раз пробовал, что это такое, но после курсов я получил более глубокое понимание возможностей и области применения этой базы данных.
Поначалу были какие-то заминки.
Было несколько проблем с формулировкой вопросов, которые предполагали неоднозначные ответы, но, возможно, это были проблемы с пониманием английского языка.
Потом было пару проблем со сбросом результатов и некоторые сбои из-за урагана Сэнди.
Был забавный вопрос, который я назвал «Миссия невыполнима», в котором нужно было выбрать один из трех вариантов ответа.
При этом на ответ на вопрос обычно дается три попытки.
Сильные стороны
Репликация ( руководство )
Репликацию настроить легко: запускаются серверы с указанием имени реплики, настраивается конфиг, участники реплики выбирают ПЕРВИЧНЫЙ сервер, остальные становятся ВТОРИЧНЫМИ серверами.При этом можно настроить приоритеты для каждого сервера, можно вообще запретить серверу становиться ПЕРВИЧНЫМ.
ПЕРВИЧНЫЙ сервер позволяет выполнять операции записи-чтения; со ВТОРИЧНЫХ серверов можно только читать.
При сбое сервера есть много нюансов, в зависимости от того, упал сервер ВТОРИЧНЫЙ или ПЕРВИЧНЫЙ, была ли сделана запись на ПЕРВИЧНЫЙ сервер после того, как он стал недоступен и был выбран новый ПЕРВИЧНЫЙ сервер и т.д. Но в целом в большинстве случаев , восстановление работы реплики автоматизировано и не потребует ручного вмешательства, кроме поднятия упавшего сервера.
Шардинг ( руководство )
Если у вас большой объем данных в коллекции и она не помещается на одном сервере, ее можно распределить по нескольким серверам, и работа с этой коллекцией на уровне приложения не потребует изменений.Для шардинга выбирается ключ, и по этому ключу составляются диапазоны для каждого шарда.
Причем, если я правильно помню, решардинг при смене диапазонов происходит автоматически в горячем режиме.
Однако есть нюанс: после того, как коллекция была распределена по серверам, изменить ключ для шардинга автоматически нельзя.
Географические индексы ( руководство )
Сейчас много стартапов или соц.сети используют такой функционал, как: найти что-то на расстоянии не дальше Х км от пользователя.
Для такой функциональности вы можете использовать географические индексы в MongoDB.
бессхемный
На мой взгляд, отсутствие схемы в MongoDB позволяет ускорить разработку проекта.Нет необходимости на начальном этапе детально прорабатывать структуру базы данных, беспокоиться об реализации связей, а затем, когда проект расширится и станет более детализированным, разрабатывать план миграции данных и т. д. В MongoDB, наоборот, на на этапе «прототипа» можно быстро запустить проект, создавая «путаницу и шатание» в базе данных, затем, когда проект начнет разрастаться, он оформится во что-то более осязаемое и возникнет необходимость привести базу данных в более осязаемое состояние.
более нормализованная форма.
Ограниченные коллекции ( руководство )
При создании таких коллекций необходимо указать количество записей, которые могут храниться в коллекции.Если при вставке коллекция уже заполнена, самая старая запись будет перезаписана.
Это можно сравнить с письмом по часовой стрелке по кругу, имеющему определенное количество сегментов.
Полезная подборка, если вам нужно хранить самую свежую, актуальную информацию, но вас не интересует старая информация.
Структура агрегирования ( руководство )
С помощью этого фреймворка можно формировать выборки из исходных данных с помощью группировки, суммирования, подсчета записей и т.д. По сути это реализация конструкций GROUP BY, COUNT, HAVING и т.д. в SQL. Исходные данные проходят через массив так называемых каналов, которые преобразуют данные и отправляют их в следующий канал.Очень похоже на консольные команды, такие как: «cat file | большие сиськи | grep -v маленький.
"
Уменьшение карты ( руководство )
Если возможностей Aggregation Framework недостаточно, вы можете использовать функционал MapReduce. Данные поступают на вход функции карты, преобразуются и подаются на вход функции сокращения.
Подводные скалы
Ограничение составных индексов
Если у вас есть запись вида: {a:[1, 2], b:[1, 2]}, вы не сможете создать индекс {a:1, b:1}.Собственно, как вставить подобную запись с полями, которые проиндексированы.
Подробнее здесь найдите «Составные многоключевые индексы могут включать только одно поле массива».
Разреженный индекс и уникальность ( руководство , Разреженные индексы)
Допустим, у нас есть записи в коллекции: { "_id": ObjectId("50caeec479705c3852e9e61b"), "a": "1" } { "_id": ObjectId("50caeeeb79705c3852e9e61d"), "a": "2", 'b': 1 } { "_id": ObjectId("50caefb179705c3852e9e621"), "a": "3" } и мы хотим, чтобы свойство «b» документов было уникальным.Невозможно будет создать обычный уникальный индекс; первая и третья записи будут считаться b:null и это нарушает уникальность.
Но мы можем создать уникальный разреженный индекс, и тогда записи, не имеющие буквы «b», не будут включены в этот индекс.
Казалось бы, все хорошо, индекс создан, уникальность есть.
Но! Если мы скажем, что просим выбрать все записи из нашей коллекции и попросить их отсортировать их по полю b, MongoDB будет использовать созданный нами разреженный индекс, в котором нет записей без «b».
В результате мы получим в выводе только одну запись.
Зависимость от интерфейсов приложений
В курсе неоднократно отмечалось, что MongoDB удобен для хранения документов так же, как они используются для вывода.Допустим, у вас есть блог, есть комментарии.
Имя и адрес электронной почты автора отображаются рядом с комментарием.
Информацию об авторе удобно хранить в объекте, хранящем комментарий.
Соответственно, если что-то изменится в этом плане, есть вероятность, что вам нужно будет изменить место хранения данных.
В принципе, это не совсем подводный камень и вероятность такого развития событий невелика, но что-то мне в этом высказывании не особо понравилось.
Не могу изменить шард-ключ
После публикации коллекции автоматически сменить ключ не получится.Поэтому выбор ключа – очень важная операция.
Подробнее 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 #NoSQL #NoSQL #mongodb
-
Какие Закономерности Находят Нейронные Сети?
19 Oct, 24 -
Хабра-Интервью С Майклом Видениусом (Mysql)
19 Oct, 24 -
Как Вы Держите Свою Нокию?
19 Oct, 24 -
О Реформе Авторского Права
19 Oct, 24 -
Корпоративный Nas — Synology Ds409
19 Oct, 24
