- PVSM.RU - https://www.pvsm.ru -
Недавно я узнал, что Red Hat удаляет поддержку MongoDB из Satellite [1] (говорят, из-за изменений лицензии). Это заставило меня задуматься, что в последние несколько лет я видел кучу статей, как ужасна MongoDB и что никто никогда не должен её использовать. Но за это время MongoDB стала гораздо более зрелым продуктом. Что же случилось? Действительно ли вся ненависть объясняется ошибками в начале маркетинга новой СУБД? Или люди просто применяют MongoDB не там, где нужно?
Если вам вдруг кажется, что я защищаю MongoDB, пожалуйста, прочитайте дисклеймер [2] в конце статьи.
Я работаю в софверной индустрии больше лет, чем прилично говорить, но всё равно на мою долю пришлась лишь малая часть трендов, которые ударили по нашей отрасли. Я был свидетелем роста 4GL, AOP, Agile, SOA, Web 2.0, AJAX, блокчейна… список бесконечный. Каждый год появляются новые тенденции. Некоторые быстро угасают, а другие принципиально меняют способы разработки ПО.
Вокруг каждого нового тренда создаётся некое всеобщее волнение: люди или сами прыгают в лодку, или видят шум, генерируемый другими — и идут за толпой. Этот процесс кодифицирован компанией Gartner в цикле хайпа [3]. Хотя и спорный, но этот график примерно описывает, что происходит с технологиями, прежде чем они в итоге станут полезными для использования.
Но время от времени появляется (или случается второе пришествие, как в данном случае) новая инновация, движимая лишь одной конкретной её реализацией. В случае NoSQL хайп был сильно обусловлен появлением и стремительным подъёмом MongoDB. Не MongoDB запустила этот тренд: на самом деле в крупных интернет-компаниях начались проблемы с обработкой больших объёмов данных, которые и привели к возвращению нереляционных БД. Общее движение стартовало с таких проектов, как Bigtable от Google и Cassandra от Facebook, но именно MongoDB стала самой известной и доступной реализацией базы данных NoSQL, к которой имели доступ большинство разработчиков.
Примечание: вы можете подумать, что я смешиваю документные БД с колоночными БД, хранилищами ключей/значений или любым из многочисленных других типов хранилищ данных, которые попадают под общее определение NoSQL. И вы правы. Но в то время царил хаос. Все помешались на NoSQL, всем оно стало абсолютно необходимо, хотя многие не видели различий в разных технологиях. Для многих MongoDB стала синонимом NoSQL.
И разработчики набросились на неё. Была довольно заманчивой идея базы данных без схемы, которая магически масштабируется для решения любой проблемы. Около 2014 года казалось, что везде, где ещё год назад использовалась реляционная база данных, такая как MySQL, Postgres или SQL Server, стали разворачивать базы MongoDB. На вопрос почему, вы могли получить ответ от банального «это масштаб веба» до более продуманного «мои данные очень слабо структурированы и хорошо вписываются в базу данных без схемы».
Важно помнить, что MongoDB и базы данных документов в целом решают ряд проблем с традиционными реляционными базами данных:
Потенциальные преимущества MongoDB были огромны, особенно для определённых классов проблем. Если прочитать вышеприведённый список без понимания контекста и не имея опыта, то может сложиться впечатление, что MongoDB действительно революционная СУБД. Единственная проблема заключалась в том, что перечисленные выше преимущества сопровождались рядом оговорок, некоторые из которых указаны ниже.
Справедливости ради, никто в 10gen/MongoDB Inc. не скажет, что названное далее неправда, это просто компромиссы.
Многие разработчики, которые обратились к MongoDB, не очень понимали компромиссы, и часто ныряли с головой, устанавливая её в качестве основного хранилища данных. После такого зачастую было невероятно сложно вернуться назад.
Не все прыгали головой вперед и врезались в дно. Но немало проектов устанавливали базу MongoDB туда, куда она просто не подходила — и им придётся жить с ней ещё немало лет. Если бы эти организации потратили некоторое время и методично обдумали выбор технологий, то многие сделали бы иной выбор.
Как выбрать подходящую технологию? Было несколько попыток создать систематический фреймворк для оценки технологий, такие как «Фреймворк для внедрения технологий в софтверные организации» [5] и «Фреймфорк для оценки программных технологий» [6], но мне кажется, что это излишняя сложность.
Многие технологии можно разумно оценить, задав всего два основных вопроса. Проблема заключается в поиске людей, которые могут ответственно на них ответить, потратив время на поиск ответов и без предвзятости.
Если вы не сталкиваетесь с какой-то проблемой, вам не нужен новый инструмент. Точка.
Если вы не сталкиваетесь с какой-то проблемой, вам не нужен новый инструмент. Точка. Не нужно искать решение, а затем придумывать проблему. Если вы не столкнулись с проблемой, которую новая технология не решает значительно лучше, чем ваша существующая технология, то здесь нечего обсуждать. Если вы рассматриваете возможность использования этой технологии, потому что видели, как её используют другие, то подумайте, с какими проблемами они сталкиваются, и спросите, есть ли у вас такие проблемы. Легко принять технологию, потому что её используют другие, трудность заключается в понимании, сталкиваетесь ли вы с теми же проблемами.
Это, безусловно, более трудный вопрос, потому что придётся копаться и хорошо понять как старую, так и новую технологию. Иногда вы не можете по-настоящему понять новую, пока не построите что-то с её помощью или у вас не появится сотрудник, имеющий такой опыт.
Если у вас нет ни того, ни другого, то имеет смысл подумать о минимально возможных инвестициях для определения ценности этого инструмента. И если вы сделаете инвестиции, насколько трудно будет отменить решение?
Пытаясь ответить на эти вопросы как можно беспристрастнее, помните одну вещь: вам придётся бороться с человеческой природой. Существует ряд когнитивных искажений, которые необходимо преодолеть, чтобы эффективно оценить технологию. Вот лишь несколько:
Объективная оценка даётся непросто, но понимание основных когнитивных искажений поможет принять более рациональные решения.
Когда появляется некая инновация, нужно с большой осторожностью ответить на два вопроса:
Если вы не можете уверенно ответить на эти два вопроса, сделайте несколько шагов назад и подумайте.
Так была ла MongoDB вообще правильным выбором? Конечно, да; как и в большинстве инженерных технологий, это зависит от множества факторов. Среди тех, кто ответил на эти два вопроса, многие извлекли пользу из MongoDB и продолжают её извлекать. Кто же этого не сделал, надеюсь, получили ценный и не слишком болезненный урок о движении по циклу хайпа.
Хочу уточнить, что я не испытываю ни любви, ни ненависти к MongoDB. Просто у нас не было таких проблем, для решения которых лучше всего подходит MongoDB. Я знаю, что 10gen/MongoDB Inc. поначалу действовала очень смело, установив небезопасные значения по умолчанию и продвигая MongoDB везде (особенно на хакатонах) в качестве универсального решения для работы с любыми данными. Вероятно, это было плохое решение. Но оно подтверждает описанный здесь подход: эти проблемы можно было обнаружить очень быстро даже при поверхностной оценке технологии.
Автор: m1rko
Источник [10]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/mysql/313214
Ссылки в тексте:
[1] Red Hat удаляет поддержку MongoDB из Satellite: https://www.redhat.com/en/blog/red-hat-satellite-standardize-postgresql-backend
[2] дисклеймер: #1
[3] цикле хайпа: https://en.wikipedia.org/wiki/Hype_cycle
[4] EAV: https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model
[5] «Фреймворк для внедрения технологий в софтверные организации»: http://www.wohlin.eu/spi96.pdf
[6] «Фреймфорк для оценки программных технологий»: https://pdfs.semanticscholar.org/4268/30dd5dd944d3b75ec56b2a3b151c18afbaf9.pdf
[7] Эффект присоединения к большинству: https://en.wikipedia.org/wiki/Bandwagon_effect
[8] Эффект новизны: https://mindmodeling.org/cogsci2015/papers/0177/index.html
[9] Эффект положительных характеристик: https://pigeon.psy.tufts.edu/avc/dittrich/fepef.htm
[10] Источник: https://habr.com/ru/post/446180/?utm_source=habrahabr&utm_medium=rss&utm_campaign=446180
Нажмите здесь для печати.