Вы, возможно, помните как несколько лет назад стремительно стали набирать популярность NoSQL-базы данных (MongoDB, DynamoDB и другие). Многие пророчили смерть классических реляционных баз данных, торжество новых парадигм и всеобщее счастье в мире. И вы, возможно, в курсе того, как в последний год (или около того) наблюдается откат этой эйфории — выходят статьи типа «Broken by Design: MongoDB Fault Tolerance» и Why You Should Never Use MongoDB. Народ
Все 3 очевидных варианта — «Использовать реляционную БД», «Использовать NoSQL-БД», «Выбирать БД по задачам проекта» мне не нравятся по причине, высказанной в заголовке статьи.
Я приведу пример. Вот представьте себе: старт нового большого проекта, начальство собирает всех разработчиков и говорит «Так, нам нужно сейчас сесть и решить, какие контейнеры мы будем использовать в коде — массивы, векторы, списки, ну или может быть деревья». Стоп! Что это за вопрос такой? Проект же ещё не начался — откуда мы знаем? Да и вообще — скорее всего, в разных местах кода будет использоваться то одно, то другое — ну, где что эффективнее будет. «Нет-нет» — говорит начальство — «нужно прямо сейчас выбрать и утвердить, например, односвязный список в качестве единственного используемого в коде контейнера». Что за бред ?! Зачем ?! «Ну вот так надо». Занавес.
Вы уже ощутили абсурдность этого примера? А теперь давайте вернёмся к нашим базам данных. У классических реляционных баз данных, типа MySQL есть известные преимущества:
- Реляционность (спасибо, Кэп)
- Несовершенный, но всем знакомый и всеми поддерживаемый SQL
- Честные транзакции на обновление нескольких таблиц
И у NoSQL-баз (я сейчас говорю о документ-ориентированной их части) есть свои преимущества:
- Быстрый поиск документа по ключу
- Гибкость в изменении структуры документа
- Более простая репликация и шардинг
При этом хорошо видно, что преимущества одного типа баз данных являются недостатками другого типа. Так скажите же мне — почему на этапе старта проекта я должен выбирать между «мыть руки с мылом или пить чай с сахаром»? Я хочу и того и другого!
У меня есть данные, которые нельзя испортить или потерять ни в коем случае — это данные о пользователях, финансовые транзакции, что-то специфическое для моего сервиса. Это будет лежать в MySQL, защищаться транзакциями, бекапиться проверенными утилитами. Пускай операции изменения этих данных будут работать чуть дольше — пользователь подождёт лишних полсекунды, зато в 100% случаев увидит свои деньги зачисленными на счёт.
У меня есть данные, которые нужно искать\отображать быстро, а также гибко менять. Это какие-нибудь лайки, комментарии, метаданные. Я не умру, если вместо в поле «лайков у этой фотки» вместо «4358» вдруг будет отображено «4357», из-за того, что где-то, в одном случае на миллион, лажанулась транзакционность Монги. Зато у всех этих 4357(8) людей данное поле отобразилось на полсекунды раньше, из-за того, что документ, описывающий данную фотку, лежал в Монге и нашелся при выборке быстрее.
Так почему бы просто при старте любого проекта (масштабами покрупнее «домашней страницы моего кота Васьки») не поднимать оба типа баз данных? Это что ли долго или дорого — поднять обе базы?
Для каждого набора данных вы сможете на лету решать, куда его положить. Одна из баз не пригодилась совсем? Ну, погасите её в конце разработки. Неверно решили, куда положить какой-то набор данных? Ну, переложите — обе базы доступны в любой момент времени. Можно хранить две копии данных, получая, когда нужно, преимущество скорости, а когда нужно — надёжности.
Не буду приписывать себе авторство этой идеи (даже в вышеуказанном вопросе на тостетре эта мысль высказывалась). Я бы хотел лишь слегка снизить страх перед сложностью данной задачи, показать, что две разных базы — это не так страшно. В современном проекте вполне могут применяться несколько языков программирования, много разных по стилю библиотек, целый зоопарк паттернов — так почему не может быть несколько типов баз?
В общем, мне кажется, в будущем мы неизменно будем видеть смешанное применение разных типов баз данных в проектах среднего и крупного масштаба. Лично я предлагаю перестать страдать уже прямо сейчас — берите лучшее от обоих типов, избегайте недостатков обоих типов.