В недавнем выступлении на MongoDB Live 2021 технический директор Apostrophe, Том Бутелл, поделился тем, как найти правильное сочетание базы данных и CMS. Важными словами здесь являются наиболее подходящие. Так что это не пост о том, что такое лучшая база данных или лучшая CMS в этом отношении (хотя у нас есть некоторые мысли на этот счет). Это история о том, что происходит, когда вы принимаете решение, основываясь на правильных критериях.
Иногда вы делаете неправильный выбор
Проще говоря, в 2009 году мы выбрали не ту базу данных. Проблема заключалась в том, что в то время мы не знали, как оценить свой выбор. Если вы плохо спланируете, может потребоваться много времени, чтобы осознать, что вы сделали неправильный выбор, и распутывание его может быть болезненным. В это время мы запускали Apostrophe как собственную CMS с открытым исходным кодом. Выбор базы данных был одним из самых сложных вызовов, которые нам пришлось сделать в начале. Уважая и прислушиваясь к мнению пользователей и сообщества открытого исходного кода, мы знали, что некоторые люди будут недовольны независимо от того, какую базу данных мы выберем. В конце концов усталость, известность и популярность стали скрытыми критериями нашего выбора. Определенно не так, как вы хотите принять решение.
Правильные критерии выбора
Конечно, мы добились прогресса. Мы сделали первоначальный выбор в соответствии с нашими потребностями, но мы знали, что нам нужно лучшее соответствие. Поэтому, когда на сцене появился Node.js, мы воспользовались возможностью внести смелые изменения. Для этого нам нужно было выбрать базу данных на основе правильных критериев.
- Пример использования: подходит ли эта база данных конкретно для наших нужд?
- Открытый исходный код: это было нашим первоначальным требованием, но в чем заключалась основная потребность? (См. раздел об устойчивости ниже)
- Низкий уровень инструментов: выбор базы данных с нужными функциями из коробки снижает потребность в инструментах, которые придают ей вид чего-то другого.
- Устойчивость: сохранится ли база данных, будет ли она иметь справедливую цену и будет ли она достаточно знакома разработчикам, чтобы они могли ее принять? Публичная лицензия MongoDB на стороне сервера помогает гарантировать это, наряду с их предложением Atlas.
- Скорость: достаточно ли быстро, чтобы обслуживать страницы в спешке?
- Безопасность: будет ли просто обеспечить безопасность?
Определение нашего варианта использования
- На основе JavaScript: устраняет необходимость переключения кода и позволяет программисту продолжать писать код на выбранном им языке.
- Вложенные виджеты: страницы состоят из дерева редактируемых пользователем виджетов и столбцов виджетов («областей»). База данных должна напрямую понимать эти структуры данных.
- Деревья документов: позволяют нам представлять отношения между страницами.
- Локализация: позволяет переводить веб-сайты.
Войдите в MongoDB
Это позволило разработчикам, использующим Apostrophe, полностью работать с JavaScript как на интерфейсе, так и на сервере, используя один язык в течение всего дня, к большой радости разработчиков во всем мире. MongoDB использовала эту силу, сделав JavaScript родным языком базы данных.
Важным фактором успеха применения MongoDB на раннем этапе для нас было то, что страница и ее вложенные виджеты составляют единый документ в MongoDB. Это преимущество усугубляется тем, что MongoDB на самом деле понимает, что это вложенные документы.
Четкое представление того, как выглядит страница в MongoDB
Видите, как main содержит массив items? «Области», такие как main, позволяют пользователю добавлять столько «виджетов» в эту часть страницы, сколько они считают нужным. А поскольку MongoDB допускает вложенные структуры данных, мы даже можем создавать «виджеты макета», которые содержат дополнительные вложенные области и виджеты, например:
Виджеты в MongoDB
В завершение наших критериев варианта использования был простой способ отображения деревьев страниц. Это правда, что мы могли бы выбрать базу данных графов, чтобы сделать это изначально. Но, в конце концов, мы обнаружили, что можно просто представить дерево, просто включив материализованное свойство пути, а также свойства уровня и ранга. При таком простом представлении, даже если каким-то образом возникнет состояние гонки, режимы отказа будут намного безопаснее, чем алгоритм вложенных множеств, который мы применяли ранее. И разработчикам по-прежнему легко понять, что они видят:
Деревья страниц в MongoDB
устойчивость
Как давние разработчики с открытым исходным кодом, мы тщательно оценили общедоступную серверную лицензию MongoDB после выпуска. Хотя мы стремимся к открытому исходному коду для Apostrophe, мы не хотели основывать наш процесс принятия решений строго на том, соответствует ли базовая база данных строгим стандартам открытого исходного кода. Что нам действительно было нужно, так это база данных, которая будет существовать долгое время. После обсуждения мы пришли к выводу, что публичная лицензия на стороне сервера — это правильный баланс между свободой, ценностью для сообщества и гарантией того, что компания, стоящая за базой данных, останется здоровой в долгосрочной перспективе.
Небольшой экскурс в Atlas, полностью управляемую облачную базу данных MongoDB, здесь. Мы большие фанаты и используем его для большинства крупных проектов. Хотя бесплатная загружаемая версия для сообщества полезна для проекта с одним сервером, мы считаем, что цены на более крупные проекты в Atlas вполне разумны и оправдывают вложения средств для достижения лучшей масштабируемости, надежности и доступности при одновременном снижении эксплуатационных расходов.
Представление
MongoDB изначально обеспечивает очень высокую производительность благодаря отсутствию синтаксического анализа SQL и конструкции механизма хранения WiredTiger. Но возможность представить всю страницу как единый документ, сохраняя при этом смысл структур данных внутри, на практике значительно повышает производительность, потому что мы не полагаемся на множество уровней соединений SQL только для получения текущей версии текущей страницы.
Безопасность
Когда дело доходит до безопасности, мы обнаружили, что MongoDB является немедленным облегчением в этой области. Поскольку запросы являются реальными структурами данных и не анализируются как строки, атаки, подобные атакам с внедрением SQL, просто невозможны. Это не означает, что система абсолютно безошибочна. Атаки типа «отказ в обслуживании» все еще возможны, если такие функции, как регулярные выражения, используются неправильно. Но главное здесь помнить, что нужно применять функции MongoDB по назначению. MongoDB безопасна при правильном использовании ее функций. И даже когда это не так, это намного безопаснее, чем SQL.
Другие решающие факторы
Интегрированный поиск — текстовые запросы MongoDB можно смешивать и сопоставлять с другими критериями прямо в одном объекте запроса. Это означает, что они компонуемые, и вы никогда не пытаетесь создать болезненное соединение между двумя разными типами баз данных.
Компонуемость — объекты запросов MongoDB могут быть объединены непосредственно в более крупные запросы с использованием операторов $and и $or без объединения строк. Это позволяет отдельным функциям вносить проверки разрешений, проверки типов и проверки диапазона в один и тот же запрос без дополнительных затрат.
Агрегация. Хотя мы не являемся компанией, занимающейся большими данными, мы по-прежнему используем функции агрегации MongoDB для таких задач, как создание более мощной замены метода distinct, который имеет возможность возвращать счетчики для всех отдельных значений свойства.
Хороший выбор, отличная технология
Итак, это история о том, как MongoDB позволила нам повысить производительность ApostropheCMS и снизить сложность нашего кода, а также приветствовать наших разработчиков в обетованной земле написания одного языка в течение всего дня. Если у вас есть задачи CMS, вы можете избежать некоторого собственного переключения кода, используя CMS, встроенную в предпочитаемую вами базу данных.
