Хранение статистики в больших объёмах - Visavi.net
https://visavi.net/
RSS - Visavi.nethttps://visavi.net/assets/img/images/logo_small.pngRSS - Visavi.net
https://visavi.net/
[email protected] (admin)[email protected] (admin)Sat, 20 Apr 2024 10:55:01 +0300<strong>Муз-ТВ</strong>, ну да, и там есть некие проблемы с типами. Пару недель пилил и изучал, и не подошло... Необходим был LIKE поиск по строкам, чего естественно реализовано небыло, ибо CH не для этого писался
https://visavi.net/topics/43454/695066
Хранение статистики в больших объёмах /7o/loTeH4I1kSat, 25 Feb 2017 23:45:20 +0300Сообщенияhttps://visavi.net/topics/43454/695066Счётчик фиксирует хосты/хиты за текущие сутки. Таблицы хостов и хитов скриптом используются для предотвращения примитивной накрутки и для определения что есть хост, а что хит. <br>
<br>
Отчёты простейшие - статистика хостов/хитов за сегодня, за вчера, всего. Причём все эти циферки кешируются в отдельной таблице. Крон их раз в сутки перезаписывает. <br>
<br>
В общем скрипт изначально попал мне в руки в говнокоде это тяжело сказать. Его собирал какой-то школьник кусками кода из разных скриптов. У меня стояла задача исправить ошибки и по возможности оптимизировать хоть как-то базу. Всё это за минимальную стоимость ибо заказчик просто хотел проверить пойдёт ли сервис в гору или нет. Я предупреждал, что если сервис разрастётся будут проблемы, что и сейчас вышло.<br>
<br>
Вижу, что развивать то, что есть, дальше нет смысла, его просто нужно создавать совершенно в ином варианте. Думаю дальнейшее обсуждение проблемы бессмысленно, так как MySQL тут не помощник.<br>
<br>
Ещё раз всех благодарю за советы.
https://visavi.net/topics/43454/695051
Хранение статистики в больших объёмах ИванSat, 25 Feb 2017 19:04:03 +0300Сообщенияhttps://visavi.net/topics/43454/695051<strong>Ixman</strong>, однозначно дергать этого монстра на каждый чих счетчика это самоубийство. MySQL нужно использовать только в качестве журнала и сбрасывать туда данные раз в день (или в час, как хотите), а сверять все входы нужно через какой нить Redis (благо он перманентный, если будет ЧП, данные не пропадут).<br>
<br>
Все что связано с датойвременем в MySQL очень ресурсоемко, потому лучше вообще исключить выборки по дате.<br>
<br>
В остальном мне было бы хорошо узнать, какие именно данные в виде отчетов предоставляются и что фиксирует счетчик и по каким правилам. Код тяжеловато читать, да и лень )
https://visavi.net/topics/43454/695050
Хранение статистики в больших объёмах АртурSat, 25 Feb 2017 17:20:36 +0300Сообщенияhttps://visavi.net/topics/43454/695050<strong>Башка</strong>, прикрепил файл счетчика. Вы очень опытный программист, думаю из кода вам станет всё понятно. Задача оптимально спроектировать MySQL базу под минимальные нагрузки. Как сейчас там, я понимаю что так нельзя, но как сделать оптимально в данном случае я пока не могу представить.
https://visavi.net/topics/43454/695049
Хранение статистики в больших объёмах ИванSat, 25 Feb 2017 17:10:07 +0300Сообщенияhttps://visavi.net/topics/43454/695049Задачу надо уточнить, чтоб советы какие либо давать.
https://visavi.net/topics/43454/695045
Хранение статистики в больших объёмах АртурSat, 25 Feb 2017 15:44:45 +0300Сообщенияhttps://visavi.net/topics/43454/695045В общем понял только одно, что мускул для таких задач не подходит. А использование других БД для заказчика экономически не выгодно в плане разработки. По необходимости буду оптимизировать то, что сейчас есть под мускул. <br>
<br>
Всех благодарю за ответы и советы. <br>
<br>
P.S. Если ещё кому-то есть что по существу сказать в плане реализации под MySQL. то буду признателен и рад выслушать.
https://visavi.net/topics/43454/695043
Хранение статистики в больших объёмах ИванSat, 25 Feb 2017 14:51:31 +0300Сообщенияhttps://visavi.net/topics/43454/695043ClickHouse с дровами под языки плохо, если юзать http апи то надо обязательно писать сращу тысячи записей иначе будут гиганский просадки по скорости.
https://visavi.net/topics/43454/695037
Хранение статистики в больших объёмах АлександрSat, 25 Feb 2017 01:27:22 +0300Сообщенияhttps://visavi.net/topics/43454/695037Тоже хотел предложить альтернативную БД, но ClickHouse (разработка яндекса, на ней построена метрика). Ну видимо тоже не очень подходит вариант.<br>
MySQL не на столько хорошо работает с огромными объёмами данных, особенно если по ним надо искать, и тем более как-то коллектить (SUM(),AVG(),MAX() и т.д.), а если ещё и сортировать, то вообще беда.<br>
<br>
Вообще Flyd правильно предложил, и это пожалуй единственный доступный выход из ситуации, но возникнут сложности при добавлении новых отчётов.
https://visavi.net/topics/43454/695036
Хранение статистики в больших объёмах /7o/loTeH4I1kSat, 25 Feb 2017 00:39:26 +0300Сообщенияhttps://visavi.net/topics/43454/695036<strong>Flyd</strong>, я тоже думал об этом, постоянно чистить таблицы через определённый интервал, хотя смотря какая статистика будет нужна в будущем. Если собирать переходы на конкретные страницы, то всё же проблема останется.<br>
<br>
<em><span style="font-size:x-small">Добавлено через 00:50 сек.</span></em><br>
<strong>Муз-ТВ</strong>, не думаю что заказчик осилит это финансово. Тем более проект не столь крупный и прибыльный.
https://visavi.net/topics/43454/695034
Хранение статистики в больших объёмах ИванFri, 24 Feb 2017 20:14:27 +0300Сообщенияhttps://visavi.net/topics/43454/695034Time Series database смотри. Например <a href="https://www.influxdata.com/" target="_blank" rel="nofollow">https://www.influxdata.com/</a> пару трилиардов легко осилит.
https://visavi.net/topics/43454/695033
Хранение статистики в больших объёмах АлександрFri, 24 Feb 2017 20:04:50 +0300Сообщенияhttps://visavi.net/topics/43454/695033Хотя нужны для отслеживания перемещений посетителей. Был здесь, зашел сюда, нажал такую- то кнопку, ушел отсюда. Если эта информация не нужна сноси вообще таблицу, пиши уникальных посетителей. Плюс есть смысл хранить логи ограниченное количество времени, затем пересчитывать итоги и хранить уже итоговые значения - столько то посетителей, за такое то время, с таких то устройств
https://visavi.net/topics/43454/695032
Хранение статистики в больших объёмах МихаилFri, 24 Feb 2017 19:26:58 +0300Сообщенияhttps://visavi.net/topics/43454/695032Здравствуйте. В общем встала задача переписать скрипт топ-рейтинга сайтов, а именно по части хранения и обработки всех статистических данных. Как сейчас реализована база в скрипте понимаю, что это всё безнадёжно.<br>
<br>
Сейчас есть таблица сайта там хранятся основные данные за сегодня типа хосты, хиты.<br>
<br>
Две таблицы хосты и хиты. Вот с хитами, простите, полная ***. Там более 2млн записей, вродь как за сутки. Я думаю вообще эта таблица не нужна. По моей логике если это не хост, то это в любом случае хит и зачем его хранить и каждый раз сверять.<br>
<br>
Так вот хочу обратиться к знающим, каким образом спроектировать базу под эти нужды? Как это всё оптимально обрабатывать? Ибо с таким ещё не работал ни разу и пока даже не знаю с чего начать. Сразу хочу, острых на язык, обломать. Мне не нужен готовый скрипт, мне нужна общая схема по которой я бы сам всё реализовал. Буду признателен за любую подсказку, либо ссылку на полезный материал по этой схеме.
https://visavi.net/topics/43454/695018
Хранение статистики в больших объёмах ИванFri, 24 Feb 2017 14:51:48 +0300Сообщенияhttps://visavi.net/topics/43454/695018