Postgres Слишком Хорош. Окончание
Начало
Скрытая стоимость «специализированных» инструментов
Помимо собственно платы за каждый специализированный сервис, есть много скрытых расходов на них.
Операционные расходы
- Мониторинг, обновления и отладка разных сервисов;
- Разные шаблоны масштабирования и режимы сбоев;
- Необходимость поддержки нескольких конфигураций;
- Раздельные процедуры резервного копирования и аварийного восстановления;
- Разные аспекты безопасности для каждого сервиса.
Сложности разработки
- Разные клиентские библиотеки и шаблоны подключения;
- Координация развёртываний нескольких сервисов;
- Несогласованность данных между системами;
- Сложные сценарии тестирования;
- Разные подходы к настройке производительности.
Если вы размещаете сервер самостоятельно, добавьте управление сервером, исправления безопасности и неизбежные сеансы отладки, когда Redis решает израсходовать всю вашу память, и т.п. Postgres делает всё это в одном сервисе, которым вы уже управляете.
Единая масштабируемая БД
Большинство людей не осознаёт, что один экземпляр Postgres может справиться с огромными объёмами данных. Речь идёт о миллионах транзакций в день, терабайтах данных и тысячах одновременных подключений. Вся магия кроется в архитектуре Postgres. Она невероятно хорошо масштабируется вертикально, а когда вам наконец понадобится горизонтальное масштабирование, у вас есть проверенные решения, такие как:
- Реплики чтения для масштабирования запросов;
- Партиционирование для больших таблиц;
- Организация пулов подключений для конкурентности;
- Логическая репликация для распределённых конфигураций.
Большинство компаний никогда до этого не доходят. Вас, вероятно, устроит один экземпляр, пока вы не начнёте обслуживать миллионы пользователей или сложные аналитические задачи. Сравните это с управлением отдельными сервисами, каждый из которых масштабируется по-разному.
Остановите оверинжиниринг с первого дня
Главная ловушка современной разработки — архитектурная астронавтика. Мы проектируем системы для задач, которых у нас нет, с трафиком, которого мы никогда не видели, для масштаба, которого, возможно, никогда не достигнем.
Начните с простого, с Postgres. Отслеживайте реальные узкие места, а не воображаемые. Масштабируйте конкретные компоненты, когда достигаете реальных ограничений. Добавляйте сложность только тогда, когда это решает реальные проблемы. Пользователям не важна ваша архитектура. Им важно, работает ли ваш продукт и решает ли он их проблемы.
Postgres может быть вашей основной БД, кэшем, очередью, поисковой системой и системой реального времени одновременно. И всё это с поддержкой ACID-транзакций во всех областях:
-- Одна транзакция, несколько операций
BEGIN;
INSERT INTO users (email) VALUES ('user@example.com');
INSERT INTO job_queue (job_type, payload)
VALUES ('send_welcome_email', '{"user_id": 123}');
UPDATE kv_store SET value = '{"last_signup": "2024-01-15"}'
WHERE key = 'stats';
COMMIT;
Итого
Postgres может быть слишком хорош сам по себе. Он настолько мощен, что делает большинство других сервисов ненужными для 90% приложений. Индустрия убедила нас, что нам нужны специализированные инструменты для всего, но, возможно, мы просто усложняем задачу.
Ваш стартап не должен быть витриной распределённых систем. Он должен решать реальные проблемы для реальных людей. Postgres позволяет вам сосредоточиться на этом. Поэтому в следующий раз, когда кто-то предложит добавить Redis «для производительности» или MongoDB «для гибкости», спросите: «Вы попробовали сначала сделать это в Postgres?»
Источник: https://dev.to/shayy/postgres-is-too-good-and-why-thats-actually-a-problem-4imc