Недавно я узнал, что Red Hat удаляет поддержку MongoDB из Satellite (говорят, из-за изменений лицензии). Это заставило меня задуматься, что в последние несколько лет я видел кучу статей, как ужасна MongoDB и что никто никогда не должен её использовать. Но за это время MongoDB стала гораздо более зрелым продуктом. Что же случилось? Действительно ли вся ненависть объясняется ошибками в начале маркетинга новой СУБД? Или люди просто применяют MongoDB не там, где нужно?
Если вам вдруг кажется, что я защищаю MongoDB, пожалуйста, прочитайте дисклеймер в конце статьи.
Я работаю в софтверной индустрии больше лет, чем прилично говорить, но всё равно на мою долю пришлась лишь малая часть трендов, которые ударили по нашей отрасли. Я был свидетелем роста 4GL, AOP, Agile, SOA, Web 2.0, AJAX, блокчейна… список бесконечный. Каждый год появляются новые тенденции. Некоторые быстро угасают, а другие принципиально меняют способы разработки ПО.
Вокруг каждого нового тренда создаётся некое всеобщее волнение: люди или сами прыгают в лодку, или видят шум, генерируемый другими — и идут за толпой. Этот процесс кодифицирован компанией Gartner в цикле хайпа. Хотя и спорный, но этот график примерно описывает, что происходит с технологиями, прежде чем они в итоге станут полезными для использования.
Но время от времени появляется (или случается второе пришествие, как в данном случае) новая инновация, движимая лишь одной конкретной её реализацией. В случае 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 туда, куда она просто не подходила — и им придётся жить с ней ещё немало лет. Если бы эти организации потратили некоторое время и методично обдумали выбор технологий, то многие сделали бы иной выбор.
Как выбрать подходящую технологию? Было несколько попыток создать систематический фреймворк для оценки технологий, такие как «Фреймворк для внедрения технологий в софтверные организации» и «Фреймфорк для оценки программных технологий», но мне кажется, что это излишняя сложность.
Многие технологии можно разумно оценить, задав всего два основных вопроса. Проблема заключается в поиске людей, которые могут ответственно на них ответить, потратив время на поиск ответов и без предвзятости.
Если вы не сталкиваетесь с какой-то проблемой, вам не нужен новый инструмент. Точка. Не нужно искать решение, а затем придумывать проблему. Если вы не столкнулись с проблемой, которую новая технология не решает значительно лучше, чем ваша существующая технология, то здесь нечего обсуждать. Если вы рассматриваете возможность использования этой технологии, потому что видели, как её используют другие, то подумайте, с какими проблемами они сталкиваются, и спросите, есть ли у вас такие проблемы. Легко принять технологию, потому что её используют другие, трудность заключается в понимании, сталкиваетесь ли вы с теми же проблемами.
Это, безусловно, более трудный вопрос, потому что придётся копаться и хорошо понять как старую, так и новую технологию. Иногда вы не можете по-настоящему понять новую, пока не построите что-то с её помощью или у вас не появится сотрудник, имеющий такой опыт.
Если у вас нет ни того, ни другого, то имеет смысл подумать о минимально возможных инвестициях для определения ценности этого инструмента. И если вы сделаете инвестиции, насколько трудно будет отменить решение?
Пытаясь ответить на эти вопросы как можно беспристрастнее, помните одну вещь: вам придётся бороться с человеческой природой. Существует ряд когнитивных искажений, которые необходимо преодолеть, чтобы эффективно оценить технологию. Вот лишь несколько:
Объективная оценка даётся непросто, но понимание основных когнитивных искажений поможет принять более рациональные решения.
Когда появляется некая инновация, нужно с большой осторожностью ответить на два вопроса:
Если вы не можете уверенно ответить на эти два вопроса, сделайте несколько шагов назад и подумайте.
Так была ла MongoDB вообще правильным выбором? Конечно, да; как и в большинстве инженерных технологий, это зависит от множества факторов. Среди тех, кто ответил на эти два вопроса, многие извлекли пользу из MongoDB и продолжают её извлекать. Кто же этого не сделал, надеюсь, получили ценный и не слишком болезненный урок о движении по циклу хайпа.
Хочу уточнить, что я не испытываю ни любви, ни ненависти к MongoDB. Просто у нас не было таких проблем, для решения которых лучше всего подходит MongoDB. Я знаю, что 10gen/MongoDB Inc. поначалу действовала очень смело, установив небезопасные значения по умолчанию и продвигая MongoDB везде (особенно на хакатонах) в качестве универсального решения для работы с любыми данными. Вероятно, это было плохое решение. Но оно подтверждает описанный здесь подход: эти проблемы можно было обнаружить очень быстро даже при поверхностной оценке технологии.
Если вам вдруг кажется, что я защищаю MongoDB, пожалуйста, прочитайте дисклеймер в конце статьи.
Новый тренд
Я работаю в софтверной индустрии больше лет, чем прилично говорить, но всё равно на мою долю пришлась лишь малая часть трендов, которые ударили по нашей отрасли. Я был свидетелем роста 4GL, AOP, Agile, SOA, Web 2.0, AJAX, блокчейна… список бесконечный. Каждый год появляются новые тенденции. Некоторые быстро угасают, а другие принципиально меняют способы разработки ПО.
Вокруг каждого нового тренда создаётся некое всеобщее волнение: люди или сами прыгают в лодку, или видят шум, генерируемый другими — и идут за толпой. Этот процесс кодифицирован компанией Gartner в цикле хайпа. Хотя и спорный, но этот график примерно описывает, что происходит с технологиями, прежде чем они в итоге станут полезными для использования.
Но время от времени появляется (или случается второе пришествие, как в данном случае) новая инновация, движимая лишь одной конкретной её реализацией. В случае NoSQL хайп был сильно обусловлен появлением и стремительным подъёмом MongoDB. Не MongoDB запустила этот тренд: на самом деле в крупных интернет-компаниях начались проблемы с обработкой больших объёмов данных, которые и привели к возвращению нереляционных БД. Общее движение стартовало с таких проектов, как Bigtable от Google и Cassandra от Facebook, но именно MongoDB стала самой известной и доступной реализацией базы данных NoSQL, к которой имели доступ большинство разработчиков.
Примечание: вы можете подумать, что я смешиваю документные БД с колоночными БД, хранилищами ключей/значений или любым из многочисленных других типов хранилищ данных, которые попадают под общее определение NoSQL. И вы правы. Но в то время царил хаос. Все помешались на NoSQL, всем оно стало абсолютно необходимо, хотя многие не видели различий в разных технологиях. Для многих MongoDB стала синонимом NoSQL.
И разработчики набросились на неё. Была довольно заманчивой идея базы данных без схемы, которая магически масштабируется для решения любой проблемы. Около 2014 года казалось, что везде, где ещё год назад использовалась реляционная база данных, такая как MySQL, Postgres или SQL Server, стали разворачивать базы MongoDB. На вопрос почему, вы могли получить ответ от банального «это масштаб веба» до более продуманного «мои данные очень слабо структурированы и хорошо вписываются в базу данных без схемы».
Важно помнить, что MongoDB и базы данных документов в целом решают ряд проблем с традиционными реляционными базами данных:
- Строгая схема: с реляционной базой данных, если у вас динамически сформированные данные, вы вынуждены либо создать кучу случайных «разных» столбцов данных, впихнуть туда блобы данных или использовать конфигурацию EAV… у всего этого значительные недостатки.
- Трудность масштабирования: если данных настолько много, что они не помещаются на один сервер, MongoDB предлагала механизмы, позволяющие масштабировать их на нескольких машинах.
- Сложные модификации схемы: никаких миграций! В реляционной базе данных изменение структуры БД может стать огромной проблемой (особенно когда данных становится очень много). MongoDB смогла значительно упростить процесс. И сделало его настолько лёгким, что вы можете просто обновлять схему на ходу и очень быстро двигаться дальше.
- Производительность записи: производительность MongoDB была хорошей, особенно при грамотной настройке. Даже конфигурация MongoDB из коробки, за которую её часто критиковали, демонстрировала некоторые впечатляющие показатели производительности.
Все риски на вас
Потенциальные преимущества MongoDB были огромны, особенно для определённых классов проблем. Если прочитать вышеприведённый список без понимания контекста и не имея опыта, то может сложиться впечатление, что MongoDB действительно революционная СУБД. Единственная проблема заключалась в том, что перечисленные выше преимущества сопровождались рядом оговорок, некоторые из которых указаны ниже.
Справедливости ради, никто в 10gen/MongoDB Inc. не скажет, что названное далее неправда, это просто компромиссы.
- Потеря транзакций: транзакции являются основной особенностью многих реляционных баз данных (не всех, но большинства). Транзакционность означает, что вы можете выполнять несколько операций атомарно и можете гарантировать, что данные останутся согласованными. Конечно, с базой данных NoSQL транзакционность может быть в рамках одного документа или вы можете использовать двухфазные коммиты, чтобы получить транзакционную семантику. Но вам придётся самому реализовать эту функциональность… что может быть сложной и трудоёмкой задачей. Часто вы не сознаёте проблемы, пока не увидите, что данные в БД попадают в недопустимые состояния, потому что невозможно гарантировать атомарность операций. Примечание: многие мне сообщили, что в прошлом году в MongoDB 4.0 появились транзакции, но с рядом ограничений. Вывод из статьи остаётся прежним: оцените, насколько технология соответствует вашим нуждам.
- Потеря реляционной целостности (внешние ключи): если в ваших данные есть отношения, то вам придётся применять их в приложении. Наличие БД с соблюдением этих отношений снимет значительную часть работы с приложения и, следовательно, с ваших программистов.
- Отсутствие возможности применять структуру данных: строгие схемы иногда становятся большой проблемой, но это также и мощный механизм хорошего структурирования данных, если грамотно их использовать. Документные БД, такие как MongoDB, обеспечивают невероятную гибкость схемы, но эта гибкость снимает ответственность за сохранение данных в чистоте. Если вы не позаботитесь о них, то в конечном итоге придётся писать в приложении много кода для учёта данных, которые хранятся не в той форме, какую вы ожидаете. Как часто говорят в нашей компании Simple Thread… приложение когда-нибудь перепишут, а данные будут жить вечно. Примечание: MongoDB поддерживает проверку схемы: она полезна, но не предоставляет те же гарантии, что в реляционной БД. Прежде всего, добавление или изменение проверки схемы не влияет на существующие данные в коллекции. Вы сами должны убедиться, что обновляете данные в соответствии с новой схемой. Решайте сами, достаточно ли этого для ваших нужд.
- Собственный язык запросов / потеря экосистемы инструментов: появление SQL стало абсолютной революцией, и с тех пор ничего не изменилось. Это невероятно мощный язык, но и довольно сложный. Необходимость конструировать запросы к БД на новом языке, состоящем из фрагментов JSON, расценивается как большой шаг назад людьми, имеющими опыт работы с SQL. Существует целая вселенная инструментов, которые взаимодействуют с базами данных SQL: от IDE до инструментов отчётности. Переход к базе данных, которая не поддерживает SQL, означает, что вы не можете использовать большинство этих инструментов или вам нужно перевести данные в SQL, чтобы их использовать, а это может оказаться сложнее, чем вы думаете.
Многие разработчики, которые обратились к MongoDB, не очень понимали компромиссы, и часто ныряли с головой, устанавливая её в качестве основного хранилища данных. После такого зачастую было невероятно сложно вернуться назад.
Что можно было сделать иначе?
Не все прыгали головой вперед и врезались в дно. Но немало проектов устанавливали базу MongoDB туда, куда она просто не подходила — и им придётся жить с ней ещё немало лет. Если бы эти организации потратили некоторое время и методично обдумали выбор технологий, то многие сделали бы иной выбор.
Как выбрать подходящую технологию? Было несколько попыток создать систематический фреймворк для оценки технологий, такие как «Фреймворк для внедрения технологий в софтверные организации» и «Фреймфорк для оценки программных технологий», но мне кажется, что это излишняя сложность.
Многие технологии можно разумно оценить, задав всего два основных вопроса. Проблема заключается в поиске людей, которые могут ответственно на них ответить, потратив время на поиск ответов и без предвзятости.
Если вы не сталкиваетесь с какой-то проблемой, вам не нужен новый инструмент. Точка.
Вопрос 1: Какие проблемы я пытаюсь решить?
Если вы не сталкиваетесь с какой-то проблемой, вам не нужен новый инструмент. Точка. Не нужно искать решение, а затем придумывать проблему. Если вы не столкнулись с проблемой, которую новая технология не решает значительно лучше, чем ваша существующая технология, то здесь нечего обсуждать. Если вы рассматриваете возможность использования этой технологии, потому что видели, как её используют другие, то подумайте, с какими проблемами они сталкиваются, и спросите, есть ли у вас такие проблемы. Легко принять технологию, потому что её используют другие, трудность заключается в понимании, сталкиваетесь ли вы с теми же проблемами.
Вопрос 2: Чего я лишаюсь?
Это, безусловно, более трудный вопрос, потому что придётся копаться и хорошо понять как старую, так и новую технологию. Иногда вы не можете по-настоящему понять новую, пока не построите что-то с её помощью или у вас не появится сотрудник, имеющий такой опыт.
Если у вас нет ни того, ни другого, то имеет смысл подумать о минимально возможных инвестициях для определения ценности этого инструмента. И если вы сделаете инвестиции, насколько трудно будет отменить решение?
Люди всегда всё портят
Пытаясь ответить на эти вопросы как можно беспристрастнее, помните одну вещь: вам придётся бороться с человеческой природой. Существует ряд когнитивных искажений, которые необходимо преодолеть, чтобы эффективно оценить технологию. Вот лишь несколько:
- Эффект присоединения к большинству — все о нём знают, но всё равно с ним трудно бороться. Просто убедитесь, что технология действительно соответствует вашим реальным потребностям.
- Эффект новизны — многие разработчики склонны недооценивать технологии, с которыми работали в течение длительного времени, и переоценивать преимущества новой технологии. Не только программисты, все подвержены этому когнитивному искажению.
- Эффект положительных характеристик — мы склонны видеть то, что есть, и упускаем из виду то, что отсутствует. Это может привести к хаосу в сочетании с эффектом новизны, поскольку вы не только по своей сути переоцениваете новую технологию, но и игнорируете её недостатки.
Объективная оценка даётся непросто, но понимание основных когнитивных искажений поможет принять более рациональные решения.
Резюме
Когда появляется некая инновация, нужно с большой осторожностью ответить на два вопроса:
- Этот инструмент решает реальную проблему?
- Хорошо ли мы понимаем компромиссы?
Если вы не можете уверенно ответить на эти два вопроса, сделайте несколько шагов назад и подумайте.
Так была ла MongoDB вообще правильным выбором? Конечно, да; как и в большинстве инженерных технологий, это зависит от множества факторов. Среди тех, кто ответил на эти два вопроса, многие извлекли пользу из MongoDB и продолжают её извлекать. Кто же этого не сделал, надеюсь, получили ценный и не слишком болезненный урок о движении по циклу хайпа.
Дисклеймер
Хочу уточнить, что я не испытываю ни любви, ни ненависти к MongoDB. Просто у нас не было таких проблем, для решения которых лучше всего подходит MongoDB. Я знаю, что 10gen/MongoDB Inc. поначалу действовала очень смело, установив небезопасные значения по умолчанию и продвигая MongoDB везде (особенно на хакатонах) в качестве универсального решения для работы с любыми данными. Вероятно, это было плохое решение. Но оно подтверждает описанный здесь подход: эти проблемы можно было обнаружить очень быстро даже при поверхностной оценке технологии.
