Хранение статистики в больших объёмах - Visavi.net https://visavi.net/ RSS - Visavi.net https://visavi.net/assets/img/images/logo_small.png RSS - 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/loTeH4I1k Sat, 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/695043 ClickHouse с дровами под языки плохо, если юзать 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/loTeH4I1k Sat, 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/695034 Time 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