Хранение статистики в больших объёмах

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

Сейчас есть таблица сайта там хранятся основные данные за сегодня типа хосты, хиты.

Две таблицы хосты и хиты. Вот с хитами, простите, полная ***. Там более 2млн записей, вродь как за сутки. Я думаю вообще эта таблица не нужна. По моей логике если это не хост, то это в любом случае хит и зачем его хранить и каждый раз сверять.

Так вот хочу обратиться к знающим, каким образом спроектировать базу под эти нужды? Как это всё оптимально обрабатывать? Ибо с таким ещё не работал ни разу и пока даже не знаю с чего начать. Сразу хочу, острых на язык, обломать. Мне не нужен готовый скрипт, мне нужна общая схема по которой я бы сам всё реализовал. Буду признателен за любую подсказку, либо ссылку на полезный материал по этой схеме.

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

Time Series database смотри. Например https://www.influxdata.com/ пару трилиардов легко осилит.

Flyd, я тоже думал об этом, постоянно чистить таблицы через определённый интервал, хотя смотря какая статистика будет нужна в будущем. Если собирать переходы на конкретные страницы, то всё же проблема останется.

Добавлено через 00:50 сек.
Муз-ТВ, не думаю что заказчик осилит это финансово. Тем более проект не столь крупный и прибыльный.

Тоже хотел предложить альтернативную БД, но ClickHouse (разработка яндекса, на ней построена метрика). Ну видимо тоже не очень подходит вариант.
MySQL не на столько хорошо работает с огромными объёмами данных, особенно если по ним надо искать, и тем более как-то коллектить (SUM(),AVG(),MAX() и т.д.), а если ещё и сортировать, то вообще беда.

Вообще Flyd правильно предложил, и это пожалуй единственный доступный выход из ситуации, но возникнут сложности при добавлении новых отчётов.

ClickHouse с дровами под языки плохо, если юзать http апи то надо обязательно писать сращу тысячи записей иначе будут гиганский просадки по скорости.

В общем понял только одно, что мускул для таких задач не подходит. А использование других БД для заказчика экономически не выгодно в плане разработки. По необходимости буду оптимизировать то, что сейчас есть под мускул.

Всех благодарю за ответы и советы.

P.S. Если ещё кому-то есть что по существу сказать в плане реализации под MySQL. то буду признателен и рад выслушать.

Задачу надо уточнить, чтоб советы какие либо давать.

Башка, прикрепил файл счетчика. Вы очень опытный программист, думаю из кода вам станет всё понятно. Задача оптимально спроектировать MySQL базу под минимальные нагрузки. Как сейчас там, я понимаю что так нельзя, но как сделать оптимально в данном случае я пока не могу представить.

Ixman, однозначно дергать этого монстра на каждый чих счетчика это самоубийство. MySQL нужно использовать только в качестве журнала и сбрасывать туда данные раз в день (или в час, как хотите), а сверять все входы нужно через какой нить Redis (благо он перманентный, если будет ЧП, данные не пропадут).

Все что связано с датойвременем в MySQL очень ресурсоемко, потому лучше вообще исключить выборки по дате.

В остальном мне было бы хорошо узнать, какие именно данные в виде отчетов предоставляются и что фиксирует счетчик и по каким правилам. Код тяжеловато читать, да и лень )