Проектирование БД, какую СУБД выбрать?

Question

[s_pyanov]

Доброго времени суток!
Нужно написать программку для неких своих нужд. Стал обдумывать архитектуру базы данных, хочу сделать именно правильно, а не абы как). Подразумевается, что будет поток данных который состоит из атрибутов user, action. И поле user и action будут являться связанными ключами на другие таблицы.

Каждый пользователь генерит около 20-50 событий в сутки, пользователей со временем может стать очень много (несколько тысяч, возможно более). Наиболее частые запросы будут на выборку:
- Получить все события пользователя в интервале дат(обычно 7 дней).
- Поиск определенного события учитывая пользователя за несколько недель/месяцев.

Смущает меня такой момент: при большом кол-ве записей в таблицу "События" будет просадка по запросам написанным выше, если будет несколько миллионов записей и запросов будет пусть 1к в день к такой таблице - наверно будет высокая нагрузка? Возможно лучше организовать структуру как-то иначе? Как на счёт схем в постгресе? К примеру отдельная схема на пользователя, а таблица actions будет в отдельной схеме доступной всем. Тогда получится несколько тысяч схем. Удобно ли это сопровождать, несет ли это дополнительные накладные расходы или наоборот хороший вариант?
Возможно вообще нужно пойти в сторону баз временных рядов - клик хаус?

В базах данных я прям не специалист, особенно в вопросах расчёта нагрузок и проектированию - поэтому прошу воздержаться от токсичных высказываний, а помочь грамотным советом от специалистов в таком вопросе )

Comments

[Akina]

Ой, да ниачём тут нагрузка. Даже если оно раскочегарится до миллиона событий в день - два индекса накрывают указанные "наиболее частые" запросы до состояния достаточно высокой эффективности, сервер ещё не успел напрячься, а результат уже готов. То есть обе затегованных СУБД, и постгресс, и мускуль, справятся с нагрузкой по щелчку пальцев, и даже на сравнительно слабой машинке.

Гораздо критичнее понимание, что там за BINARY тип данных... надеюсь, это не бинарные строки неограниченной длины? именно тут надо искать оптимизации... или пока не искать, ибо преждевременная оптимизация - зло.

[ThunderCat]

По структуре вроде все норм. Без более конкретных данных сказать сложно, но в целом структура правильная. Нагрузка в 1к в день - смешная. Миллион записей тоже не большая по объему база. Любая современная бд легко справится при наличии правильно прописанных индексов и нормального железа. Имхо среди прочих равных по мускулю просто больше сообщество и база траблшутинга, но и любая другая сойдет, если есть желание поэкспериментировать или обучиться.

1к в день

Хинт как считать нагрузку: Допустим рабочее время - 8 часов, это 28 000 секунд. То есть условно 2 запроса в минуту. Много?

Answer 1

[Михаил]

Ваши нагрузки легко выдержит любая SQL СУБД - MySQL, PostgreSQL.

Преждевременная оптимизация - зло. Начните с простых, давно уже известных вещей. А затем уже, по мере выявления узких мест - оптимизируйте.

Comments

[s_pyanov]

Спасибо! )

Answer 2

[Vitsliputsli]

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