На прошлой неделе я посетил
конференцию MongoDB London
в Лондоне. Теперь меня интересует данная технология и я понимаю, что
она может дать своим пользователям. Но проблема в людях! Все они
говорят, следуя следующему сценарию:
- Была некоторая проблема с реляционными базами данных, которой на самом деле не существует (или не существовало долгое время).
- MongoDB.
- Успех!
К примеру, первый докладчик, которому не нравятся нормализованные данные, потому что у них “плохая локальность”.
Забудем на секунду о разнице между
логической и физической моделями данных и существовании
нормальных форм — если вы обнаруживали, что узким местом в соединениях было
время поиска,
можно было предварительно выполнить необходимые вычисления и обновлять
их, когда происходили какие-нибудь изменения, используя, например
материализованное представление в Oracle (1996),
постоянный запрос и
кэш результатов.
И это вдобавок к тому, что кэш буфера блоков и оптимизатор запросов уже тогда отлично справлялись со своими функциями.
Кроме того, докладчик упомянул о
вложенных таблицах
и заявил, что в “базах данных SQL” их использовать невозможно. По
утверждениям, MongoDB более гибкая, поскольку не привязывает вас к
таблицам. Просто таблицы — недостаток технологии, а используем мы
реляционную модель, потому что у нее есть логическая математическая
подоплека, что отображено в технологии. Можно ли сказать то же самое о
модели MongoDB?
По мнению другого докладчика, намного лучше, если
каждое приложение обладает собственной базой данных и отображает свои данные через
веб-сервисы.
Идея, вроде, неплохая, но теперь понадобится иная технология, каталог
для поиска этих данных (поскольку они являются не просто именами таблиц
или хранимыми в одном месте именами процедур), система управления и
контроля за доступом.
И если вам нужно изменить данные нескольких сервисов, необходим инструмент для координирования этого процесса. Назовем его
средством обработки транзакций. Докладчик опустил эти важные условия. Подобных примеров было много.
Еще одна тема, не дававшая покоя участникам мероприятия — обновление
некой организацией аппаратного обеспечения и модификация архитектуры,
один из компонентов которой предполагал развертывание MongoDB, однако
рост производительности приписывали последней.
Например, разделить OLTP и OLAP и ввести задержку в несколько минут
между поступлением данных и моментом, когда они будут доступны для
отчета. Таким образом можно добиться внушительного роста
производительности в любой базе данных! Разумеется, если вы способны
смириться с задержкой.
В следующей версии пообещали поддержку восстановления на определенный
момент времени (point-in-time recovery). У Oracle такая опция появилась
в 1988 году.
В любом случае, учитывая, что MongoDB — свободная система с открытым
исходным кодом, стоит ее оценить и посмотреть, подходит ли она вам.
Просто помните, эти люди считают, что решают проблемы, которые IBM и
другие решили до того, как они появились на свет, и необходимые функции
уже присутствуют в существующей базе данных/стеке технологий (я
использовал Oracle в своих контраргументах, поскольку лучше всего в ней
разбираюсь. Полагаю, о SQL Server и DB/2 можно сказать то же самое).
Поговорите со своим знакомым администратором баз данных.
К сожалению, огромное количество разработчиков использует MongoDB,
поскольку слишком ленятся правильно использовать реляционные СУБД.
источник 
Имидж техиндустрии может показаться таким же идеальным и
блестящим, как и выпускаемые ею продукты, но как известно многим из нас, гик не
всегда синоним крутости. Более того, некоторые технические профессии вызывают
жалость: калечащая работа на заводе, отупляющая работа в службе поддержки и
должности в розничной торговле, колеблющиеся от постыдных до эксплуататорских.
Есть еще профессии, связанные с серьезной физической опасностью. 
