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

1. Иван (24.02.2017 / 14:51)
Здравствуйте. В общем встала задача переписать скрипт топ-рейтинга сайтов, а именно по части хранения и обработки всех статистических данных. Как сейчас реализована база в скрипте понимаю, что это всё безнадёжно.

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

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

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

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

3. Александр (24.02.2017 / 20:04)
Time Series database смотри. Например https://www.influxdata.com/ пару трилиардов легко осилит.

4. Иван (24.02.2017 / 20:14)
Flyd, я тоже думал об этом, постоянно чистить таблицы через определённый интервал, хотя смотря какая статистика будет нужна в будущем. Если собирать переходы на конкретные страницы, то всё же проблема останется.

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

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

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

6. Александр (25.02.2017 / 01:27)
ClickHouse с дровами под языки плохо, если юзать http апи то надо обязательно писать сращу тысячи записей иначе будут гиганский просадки по скорости.

7. Иван (25.02.2017 / 14:51)
В общем понял только одно, что мускул для таких задач не подходит. А использование других БД для заказчика экономически не выгодно в плане разработки. По необходимости буду оптимизировать то, что сейчас есть под мускул.

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

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

8. Артур (25.02.2017 / 15:44)
Задачу надо уточнить, чтоб советы какие либо давать.

9. Иван (25.02.2017 / 17:10)
Башка, прикрепил файл счетчика. Вы очень опытный программист, думаю из кода вам станет всё понятно. Задача оптимально спроектировать MySQL базу под минимальные нагрузки. Как сейчас там, я понимаю что так нельзя, но как сделать оптимально в данном случае я пока не могу представить.

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

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

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

11. Иван (25.02.2017 / 19:04)
Счётчик фиксирует хосты/хиты за текущие сутки. Таблицы хостов и хитов скриптом используются для предотвращения примитивной накрутки и для определения что есть хост, а что хит.

Отчёты простейшие - статистика хостов/хитов за сегодня, за вчера, всего. Причём все эти циферки кешируются в отдельной таблице. Крон их раз в сутки перезаписывает.

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

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

Ещё раз всех благодарю за советы.

12. /7o/loTeH4I1k (25.02.2017 / 23:45)
Муз-ТВ, ну да, и там есть некие проблемы с типами. Пару недель пилил и изучал, и не подошло... Необходим был LIKE поиск по строкам, чего естественно реализовано небыло, ибо CH не для этого писался

URL: https://visavi.net/topics/43454