Выбор СУБД для разработки сервиса

[ktan]

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

 

[sanchozu]

Например PostgreSQL имеет отвратительную систему хранения, при которой каждая отдельная запись храниться в виде отдельного файла.

Во первых это неправда, каждая таблица, индексы таблицы да отдельные файлы, но не записи. Во вторых, что в этом отвратительного, лол.
Почитайте какие сервисы поднимали на PostgreSQL и какие нагрузки она держит.
Правильный вопрос содержит половину ответа, а тут хуй пойми что. Если на то пошло то для больших нагрузок обычно стараются использовать NoSQL БД где это возможно.

 

[MrCrutch]

Я бы начал с того, что выбор СУБД зависит не столько от предполагаемого количества запросов, сколько от характера нагрузки: соотношения чтения и записи, сложности запросов, объёма данных, требований к консистентности и масштабированию.

Кстати, насчёт PostgreSQL есть небольшая неточность: каждая запись там не хранится отдельным файлом. Данные организованы в страницах внутри файлов отношений, а для управления версиями строк используется MVCC. Это действительно создаёт определённые накладные расходы, например необходимость VACUUM, но само по себе не делает систему хранения плохой.

Лично я для большинства коммерческих сервисов рассматривал бы PostgreSQL как основную СУБД. Причины — ACID, развитая система индексов, сложные SQL-запросы, JSONB, репликация и зрелая экосистема.

Если предполагается высокая нагрузка, я бы не спешил выбирать экзотическую СУБД. Гораздо важнее сначала правильно спроектировать схему данных, индексы, пул соединений и архитектуру приложения. PostgreSQL в связке с Redis для кеширования и, при необходимости, ClickHouse для аналитики может закрыть весьма серьёзные нагрузки.

При этом высокая нагрузка — понятие относительное. 50 тысяч простых запросов на чтение и 5 тысяч сложных транзакций в секунду — совершенно разные задачи.

Поэтому главный вопрос: какая именно нагрузка ожидается, какой объём данных, что преобладает — чтение или запись, и какие требования к задержкам? Без этого выбор СУБД будет скорее вопросом личных предпочтений, чем инженерным решением.