Хм

Вообще про подписчиков на данные мне вспомнились оракловые очереди

Ну тут нет никаких очередей. Есть отправители и получатели. И что угодно может быть и тем и этим и одновременно обоими.

Хм

А что, на кипре хорошо что ли

Отлично)

Отлично)

Отлично от чего?

@dedipur будет жить. Поприветствуем!

Отлично от чего?

Отлично от СПб и Мск

В мск жепа в электричке и метро. Как сардины в банке.

Если сдвинуться от часов пик очень даже неплохо. А в МЦК так всегда хорошо

Отлично)

Ну ... как бы не супер.

Отлично)

А там же на какой-тр одной половине только быть можно

Как можно жить, когда тебя не везде пускают? Интересно же

В мск жепа в электричке и метро. Как сардины в банке.

Это да. Я правда наоборот начал к часам пик сдвигаться, хотя работка теперь ближе

В мск жепа в электричке и метро. Как сардины в банке.

++ , поэтому хорошо работать не по стандартному графику: попозже приходить, часам к 11

Можно быть на любой стороне, но с турецкой стороной некоторые нюансы)

@crestoff будет жить. Поприветствуем!

++ , поэтому хорошо работать не по стандартному графику: попозже приходить, часам к 11

Хорошо вообще из дома работать.

из дома в тёплых странах - особенно актуально осенью, зимой и весной)

++ , поэтому хорошо работать не по стандартному графику: попозже приходить, часам к 11

Так это, даже к 11 уже и пробки и толпень кругом. В 7-8 в метро вообще заходить страшно

Хорошо вообще из дома работать.

Это мечта

Дома работать уныло и скучно

Так это, даже к 11 уже и пробки и толпень кругом. В 7-8 в метро вообще заходить страшно

Ездила к 11, всегда сидя ехала) и это по ужасной перегруженной фиолетовой ветви)

Дома работать уныло и скучно

Кому как ))

Я интррверт мне ваще норм

Ездила к 11, всегда сидя ехала) и это по ужасной перегруженной фиолетовой ветви)

Я вот как раз в метро спускаюсь, сейчас посмотрим что там))

Так это, даже к 11 уже и пробки и толпень кругом. В 7-8 в метро вообще заходить страшно

В 7-8 -кошмар в метро

Я вот как раз в метро спускаюсь, сейчас посмотрим что там))

?

из дома в тёплых странах - особенно актуально осенью, зимой и весной)

Из тайланда на пляже)

Можно быть на любой стороне, но с турецкой стороной некоторые нюансы)

Ну вот, нюансы) то есть некоторая несвобода

Без возможности обсудить что-нибудь интересное с более опытным товарищем? Ну нет

А там же на какой-тр одной половине только быть можно

Можно быть в обоих. Но на тебя просто будут не так смотреть в другой половине. (на юго-западе греки, на северо-востоке турки, соотношение 2:1, Левкосия/Никосия -- пополам.)

Добрый день, уважаемые специалисты! Есть такая таблица статистики посещений (InnoDB в MySQL 7):

с такими индексами

за сутки в ней набирается до 1м записей, вот таких

Для вывода статистики делаем подобные запросы, только с разной группировкой (по часам, дате, IP, referer и тд) SELECT SUM(visit_amount) AS raws, COUNT(visit_amount) AS uniques, SUM(click_amount) AS clicks, ROUND(SUM(click_amount)/SUM(visit_amount)*100) AS prod, SUM(is_bot) AS bots, SUM(is_proxy) AS proxies, SUM(is_no_cookie) AS nocookies, FROM_UNIXTIME(TIME, "%H") AS hour FROM `log_visit` WHERE `time` BETWEEN 1539129600 AND 1539215999 GROUP BY `time` ORDER BY `hour` DESC, `raws` DESCполучаем подобные результаты:

в общем то всё прекрасно если бы не время выполнения запросов к примеру за прошлые сутки около 2х секунд, или если брать группировку по датам за неделю - это около 30 секунд.

результат профилирования

Больше программист чем специалист по DB, поэтому вопрос тривиальный - "Как можно оптимизировать таблицу/запрос/итд" чтобы запросы выполнялись бысрее:) ?

интерфейс, чтобы было понятно что требуется в статсе

Для вывода статистики делаем подобные запросы, только с разной группировкой (по часам, дате, IP, referer и тд) SELECT SUM(visit_amount) AS raws, COUNT(visit_amount) AS uniques, SUM(click_amount) AS clicks, ROUND(SUM(click_amount)/SUM(visit_amount)*100) AS prod, SUM(is_bot) AS bots, SUM(is_proxy) AS proxies, SUM(is_no_cookie) AS nocookies, FROM_UNIXTIME(TIME, "%H") AS hour FROM `log_visit` WHERE `time` BETWEEN 1539129600 AND 1539215999 GROUP BY `time` ORDER BY `hour` DESC, `raws` DESCполучаем подобные результаты:

Ты хочешь ПО ЧАСУ времени сгруппировать ? Или по времени? Боюсь, тут ошибка в запросе, надо было GROUP BY FROM_UNIXTIME(TIME, "%H")

конечно же я делал такую группировку время выполнения запроса увеличивает в 2.5-3 раза

Почему агрегаты не собирать хоть в ту же вертику, зачем насиловать mysql?

Я об этом написал в другой группе. Он везде одно и то же понакидал)

Почему агрегаты не собирать хоть в ту же вертику, зачем насиловать mysql?

Пока интересно решение/совет на mysql, если же совсем ничего не поделать, будем думать о переносе

1) сожми колонки 2) разбей на партиции А вообще задача конечно для колоночной бд

3) закажи железо помощнее ))))

NVME, буфер пул на весь размер бд, и номр даже так будет?

партиции не спасут, срез данных большой, все равно seq scan какой-то будет

делал партиции по датам

не помогло

есть предположение, что плохо делал

сколько дней в таблице хранится?

30 дней

конечно же я делал такую группировку время выполнения запроса увеличивает в 2.5-3 раза

Ну, СНАЧАЛА запрос должен быть ПРАВИЛЬНЫМ. Потом -- быстрым.

это точно)

Почему агрегаты не собирать хоть в ту же вертику, зачем насиловать mysql?

Ну какой-то вшивый мильон и Мускль сагрегирует.

конечно же я делал такую группировку время выполнения запроса увеличивает в 2.5-3 раза

Ты скажи вот мне.

мильён он быстро делает

а за недельку, за месяц уже плохо ему

как-то я уже лояльно настроен на перенос данных в вертику, адаптер для yii2 даже есть (проект на yii2). конечно придётся поебаться, чувствую...

агрегаты и в мускуле можно хранить

конечно же я делал такую группировку время выполнения запроса увеличивает в 2.5-3 раза

Скажи что вот это всё значит Почему время -- int ? WHERE time BETWEEN 1539129600 AND 1539215999 это какой интервал (в часах) и сколько в него попадает записей? GROUP BY time Это видимо unixtime в чистом виде. Ну, точно, у тебя запрос неверный. Ты просто гонишь лажу какую-то а не данные.

агрегаты и в мускуле можно хранить

да, но там у него декартово произведение получается чуть ли не во всю таблицу) 250 стран умножить на n браузеров умножить на m устройств...

агрегаты и в мускуле можно хранить

Не баламуть. Если это логи, то нахер их предагрегировать? Записал, снял статистику за день, и удалил нахрен. И всё.

как-то я уже лояльно настроен на перенос данных в вертику, адаптер для yii2 даже есть (проект на yii2). конечно придётся поебаться, чувствую...

Кликхаус бери, он писался под анализ логов всё-таки.

Скажи что вот это всё значит Почему время -- int ? WHERE time BETWEEN 1539129600 AND 1539215999 это какой интервал (в часах) и сколько в него попадает записей? GROUP BY time Это видимо unixtime в чистом виде. Ну, точно, у тебя запрос неверный. Ты просто гонишь лажу какую-то а не данные.

верно это unixtime с округлением до часа

Пока интересно решение/совет на mysql, если же совсем ничего не поделать, будем думать о переносе

Погоди. А выше с лисьей мордой это тоже ты?

Погоди. А выше с лисьей мордой это тоже ты?

Да

не решена проблема с временем

выполнения

а за недельку, за месяц уже плохо ему

А сколько записей за неделю, месяц?

ща

Скажи что вот это всё значит Почему время -- int ? WHERE time BETWEEN 1539129600 AND 1539215999 это какой интервал (в часах) и сколько в него попадает записей? GROUP BY time Это видимо unixtime в чистом виде. Ну, точно, у тебя запрос неверный. Ты просто гонишь лажу какую-то а не данные.

Ты на вопросы ответь

примерно 1м в сутки

ща

^

примерно 1м в сутки

Ye 30 млн это не шибко много, но уже да, многовато чтобы просто так вот на шару агрегировать...

Скажи что вот это всё значит Почему время -- int ? WHERE time BETWEEN 1539129600 AND 1539215999 это какой интервал (в часах) и сколько в него попадает записей? GROUP BY time Это видимо unixtime в чистом виде. Ну, точно, у тебя запрос неверный. Ты просто гонишь лажу какую-то а не данные.

900к записей например в промежутке который ты указал

900к записей например в промежутке который ты указал

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

как раз этот промежуток не так долго выполняется, т.к. это 1 день.

но когда берём неделю и тд, это уже долго

но когда берём неделю и тд, это уже долго

Ну это совсем разные случаи, неделя и месяц и день

Короче.

случаи разные - количество обрабатываемых данных увеличивается.

короче чо оптимальнее click хаус или вертика?

я понял уже что проще перенести таблицу

Без возможности обсудить что-нибудь интересное с более опытным товарищем? Ну нет

По мессенджерам или скайп

Погоди. А выше с лисьей мордой это тоже ты?

Спалил