Таблица под highload?

Question

[Troodi Larson]

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

Comments

[Sanes]

Статистика разной бывает. Что за данные, как их можно каталогизировать?

[Troodi Larson]

Ссылка, страна, время входа

[Sanes]

Troodi Larson, партицирование не подходит?

[Troodi Larson]

Sanes, я читал про это, но тут вопрос такой, это же не поможет в случае если надо сделать такую проверку. 100 млн. записей из них надо проверить заходил ли сегодня уже пользователь или нет. То есть эту задачу надо выполнить как можно быстрее, чтобы дальше определить, что делать с ним.

[sim3x]

Опишите
поля
запросы
RPS на вставку и на получение
возможная задержка перед появлением данных в БД

Answer 1

[xmoonlight]

1. Добавляете данные ОДНОВРЕМЕННО сразу в 2-е таблицы: в одну общую историческую таблицу (или можно создавать новую таблицу раз в месяц, пол-года, год) и в таблицу за последний короткий промежуток времени (например, за месяц).
2. Раз в сколько там хотите удаляйте устаревшие данные из таблицы короткого периода: "подрезайте хвост" после сортировки по timestamp-полю.

Таким образом, будет возможность оперативной работы со свежими данными и более длительной работы с архивными данными.

UPD:

100 млн. записей из них надо проверить заходил ли сегодня уже пользователь или нет. То есть эту задачу надо выполнить как можно быстрее, чтобы дальше определить, что делать с ним.

Банально: LastLogon (timestamp) в одном из полей таблицы пользователей.

Answer 2

[boss_lexa]

Troodi Larson, сделайте шардинг данных по пользователю, храните данные одного пользователя в одной таблице

а лучше используйте Clickhouse

тут все найдете
highload.guide/blog
https://www.youtube.com/user/profyclub

Answer 3

[Дмитрий Телепнев]

Либо смотрите в сторону партицирования. Партицию за сегодняшний день вытаскивает на ССД, остальные(архив) на хдд.

Comments

[Сергей Горностаев]

В данной таблице ведётся поиск по нескольким атрибутам.

Шардинг при наличии вторичных ключей - это боль.

Answer 4

[Кирилл Кудрявцев]

Можно использовать InfluxDB, она больше подходит под эту задачу.