Почему исторически пришли к использованию нескольких баз данных на одном проекте?

Лет 10 назад (а может уже и больше) я написал довольно сложный SQL запрос, который ежедневно вытягивал информацию заказчику об израсходованных пользователями ресурсах. Сам запрос отрабатывал просто замечательно, пока данных не перевалило за 50M. Последующий тюнинг запроса и создание индексов хоть и улучшили ситуацию, но лишь отложили неминуемую проблему.

И уже тогда я задавался вопросом - неужели нельзя как-то иначе структурировать данные в СУБД, чтобы можно было и правильно хранить, соблюдая первые нормальные формы, и читать их также эффективно.

Как оказалось - нельзя 🙂

Это все равно, что решить две диаметрально противоположные проблемы на чтение и запись данных - одним и тем же способом.

Поэтому решение, к которому мы тогда пришли и которое сейчас уже повсеместно встречается везде (и которое кажется абсолютно логичным, но не тогда казалось нам!) - это использование нескольких СУБД. Но как и любое другое решение, оно имеет свои плюсы и минус - и это надо помнить.

Например:
- одна для обработки live данных пользователей
- вторая для быстрого поиска по этим live данным
- третья для аналитики и отчетов

Обычно, для каждого варианта используются разные СУБД, которые выполняют свои функции лучше всего. Например, для первого кейса PostgreSQL, для второго Elasticsearch, для третьего BigQuery.

Но нужно помнить, что это вполне нормально и даже более правильно начинать с одной СУБД и только со временем добавлять другие, если в этом есть или предвидется необходимость в скором времени - YAGNI!

PS. Фото - это я решил покормить лемуров на Кипре. Но их было также много, как и баз данных сейчас у меня в Google 😅