Как выбрать архитектуру и БД для высоконагруженной системы?

Question

[Айдар Хаятов]

Добрый день! Хотел посоветоваться с опытными бэкэнд программистами.
Встала задача создать высоконагруженный проект (Типо кассового решения). В базе данных через 1-2 года планируется , около 150млн записей у основной сущности (продажа).

Соответсвенно периодически людям нужно будет снимать отчеты, то есть нужно максимально быстрое чтение этих данных. Но большим плюсом является что эти 150млн записей - разделены примерно на 1000-5000 разных пользователей, и выборка нужна в рамках одного пользователя только. Как лучше хранить такие данные? в одной таблице? или можно разделить по разным таблицам, и держать связку какой пользователь в какой базе хранит.

Изучаю сейчас вопрос выбора БД. Сам пишу на mysql - потянет ли он такие объемы, на нормальном железе. Или нужно смотреть в сторону других БД? Если думать о масштабирумеости (увеличении кол-во записей)

Спасибо!

Answer 1

[stratosmi]

Добрый день! Хотел посоветоваться с опытными бэкэнд программистами.
Встала задача создать высоконагруженный проект (Типо кассового решения). В базе данных через 1-2 года планируется , около 150млн записей у основной сущности (продажа).

150 миллионов записей - это ерунда, а не высоконагруженное решение.
У меня 5 000 записей в секунду создается на довольно дохлом (что-то около 500 рублей в месяц стоит хостинг) сервере VDS/VPS
Два года? 150 миллионов - это за ... 9 часов.
И да, я не считаю это решение высоконагруженным.
Нагруженным - да.

то есть нужно максимально быстрое чтение этих данных

Нет.
Людям не нужно снимать отчеты со всех данных сразу. Только часть данных интересует их.

Если всё же нужны все данные сразу (ну какая-то общая статистика) - то на основании первичных данных выполняется агрегация (например, по ночам) и тогда отчеты будут строится вообще - мгновенно.

Но большим плюсом является что эти 150млн записей - разделены примерно на 1000-5000 разных пользователей, и выборка нужна в рамках одного пользователя только.

Вот только если ваши 1000-5000 пользователей будут постоянно получать данные - только тогда это и можно назвать нагруженным решением.

Как лучше хранить такие данные? в одной таблице? или можно разделить по разным таблицам, и держать связку какой пользователь в какой базе хранит.

Это зависит от того что за данные.
Что именно за данные.

Сам пишу на mysql - потянет ли он такие объемы, на нормальном железе. Или нужно смотреть в сторону других БД?

MySQL довольно быстр.
Например, PostgreSQL более функционален. Но насчет скорости - не обязательно.

потянет ли он такие объемы, на нормальном железе

А в официальную документацию заглянуть?
https://dev.mysql.com/doc/refman/8.0/en/limits.html
150 млн. записей для современных СУБД и современных компьютеров (даже не на "нормальном железе") - это тьфу, а не нагрузка.

P.S.:
Для высоконагруженных систем формирования отчетов есть различные решения:

1. Предварительная (ночная) агрегация данных
   
2. Master-slave, где master только обновляет данные, а slave - только для отчетов.
   
3. Специализированные, заточенные под конкретный вид данных СУБД (InfluxDB, Redis-Tarantool-Aerospike, ClickHouse пр.)
   

Comments

[Айдар Хаятов]

Огромное спасибо за развернутый ответ, будем использовать php+mysql.
На самом деле Ваша критика по поводу моих высказываний касательно "высоконагруженности" очень меня успокоила :)

Вот на конкретном примере, Вы бы хранили данные о продажах - Вы бы хранили это все на 1 таблице в рамках 1 БД? И начинаю думать по поводу необходимого железа для этой задачи

[stratosmi]

Айдар Хаятов,

Вот на конкретном примере, Вы бы хранили данные о продажах - Вы бы хранили это все на 1 таблице в рамках 1 БД? И начинаю думать по поводу необходимого железа для этой задачи

От задач зависит.
Если очень ответственные данные - дубль в обычных текстовых файлах + СУБД.
Если большая скорость записи - СУБД Tarantool с движком vinyl, возможно через прокси-MQ.
Если нужна различная аналитика в различных разрезах - классическая реляционная СУБД MySQL/PostgreSQL удобнее.

О 150 миллионах я бы вообще не парился. Тут главное - индексы правильные чтобы были.

P.S.:
Сейчас глянул (это не та VPS/VDS за 500 рублей, что я выше описывал, а другая СУБД, как раз где много аналитики-отчетов) - 17 миллиардов записей -
Реализовано в виде 2-х таблиц.
В одной - все продажи.
В другой - свернутые (агрегированные, суммированные) данные по интересующим менеджеров разрезам данных.
СУБД PostgreSQL.

[stratosmi]

stratosmi,

17 миллиардов записей

Железо серверное - очень хорошее.

По меркам 15 летней давности.

[Айдар Хаятов]

Огромное спасибо, что дали советы направили в нужную сторону - будем изучать