либо ещё один вариант - постоянно выдёргивать завершённые сессии и складывать куда-то ещё, в nosql...

А смысл

бд проектировали авторы freeradius, естественно, они на такие запросы не рассчитывали

поэтому я и предлагаю - сделать свою табличку, под свои задачи. И помещать туда то, что нужно вам. А не авторам freeradius

поэтому я и предлагаю - сделать свою табличку, под свои задачи. И помещать туда то, что нужно вам. А не авторам freeradius

Для этого все равно придется теребить табличку авторов. И какой тогда смысл?

есть запрос: explain SELECT username, max(acctstarttime) AS last_session_start , IFNULL(MAX(acctstoptime), 0) AS last_session_end, SUM(acctinputoctets+acctoutputoctets) AS data_usage FROM radacct GROUP BY username ORDER BY max(acctstoptime) ASC;

Запрос обрабатывает все записи из таблицы, нет повода для оптимизации вообще. Так что страдай

придётся ... всем спасибо

придётся ... всем спасибо

а у вас username идет именно строкой? если бы там был userid, есть шанс что группировка шла бы быстрее

строкой ...

придётся завершённые сессии вытаскивать в аггрегирующую таблицу

а у вас username идет именно строкой? если бы там был userid, есть шанс что группировка шла бы быстрее

На 5% ?

есть запрос: explain SELECT username, max(acctstarttime) AS last_session_start , IFNULL(MAX(acctstoptime), 0) AS last_session_end, SUM(acctinputoctets+acctoutputoctets) AS data_usage FROM radacct GROUP BY username ORDER BY max(acctstoptime) ASC;

Кроме того, я не уверен, что запрос правильный. У тебя для сессии начало и конец берутся тупо как min, Max, но записи эти две друг с другом никак не связаны.

На 5% ?

процентов на 20 прирост дать вполне может

покурю насчёт start/stop

процентов на 20 прирост дать вполне может

С 20 сек будет 18? Зашибись результат...

Оптимизация запроса — это ускорение его минимум на порядок.

16

Лучше на 2-3 порядка

Все верно, но ты вообще предложил парню страдать

Так а чёго ему ещё делать?

С такими запросами...

ССЗБ!

Я не знаю, что под капотом у mysql, но в pg я бы посоветовал ему покрывающий индекс по полю группировки и полям агрегации. Ну и активно фризить таблицу.

Какой индек, он ВСЮ ТАБЛИЦУ выбирает!

Покрывающие индексы это вообще зло. Не надо их форсить.

Ксати , нездоровая тенденция последних лет ... блин, лет 5ти

Ненене, покрывающие индексы - это отличная тема.

Каждый форсит покрывающий индекс.

Это гнилая тема.

Почему?

Ты не сделаешь на все запросы покрывающие индексы

Завтра запрос поменяли, добавили одно полюшко — всё, в сад, с копыт.

Потом, покрывающий индекс (В ЭТОМ ЗАПРОСЕ) не сильно и поможет. Может, в 2 раза ускорит. А надо (повторяюсь) на порядки.

Покрывающие индексы хороши для агрегаций. А добавление дополнительного роля агрегации всегда черевато

Почему?

Идеологически покрывающий индекс сродни денормализации. Такая же тупая дебильная технология.

Потом, покрывающий индекс (В ЭТОМ ЗАПРОСЕ) не сильно и поможет. Может, в 2 раза ускорит. А надо (повторяюсь) на порядки.

Кстати, а какого размера таблица, он не говорил?

И бесполезная в 90% случаев

Ладно, это лирика всё

Нет не говорил

Но видимо немаленькая, видимо, лог какого-то девайса.

Если бы таблица была маленькой, он бы сюда не прибежал.

Идеологически покрывающий индекс сродни денормализации. Такая же тупая дебильная технология.

Что-то тебя понесло

Наверное, несколько сот тыщ записей

Это очень долго для нескольких кк записей. Миллионов - да, ещё возможно

Что-то тебя понесло

Несёт —- это когда гонишь, и гонишь туфту... А я ПРАВДУ говорю...

Это очень долго для нескольких кк записей. Миллионов - да, ещё возможно

Я не понял реплику.

Ладно, не важно. Автор пусть либо колется, либо страдает.

У меня был проект, где денормолизация и покрывающие индексы были в одном флаконе и прирост был колоссальный, как и профит от этого

Я не понял реплику.

Автозамена

Все зависит от данных и как их использовать

А так ему нужно ловить в таблице окончания сессий и отваливать в отдельную таблицу последних сессий сессии по юзерам. Тогда будет быстро

Но это ему уже сказали.

У меня был проект, где денормолизация и покрывающие индексы были в одном флаконе и прирост был колоссальный, как и профит от этого

Эх, был у меня проект....

Кстати, а какого размера таблица, он не говорил?

По explain же видно 5.5 миллионов

А ну тогда вообще трындец.

по имени таблицы radacct видно, что это radius accounting, грубо говоря - логи пользователей, которые через radius-сервер приходят

По explain же видно 5.5 миллионов

Партицирование таблицы и преагрегацию порезанных кусков уже советовали?

Прикольно, когда старт сессии в одной партиции, а окончание в другой ??

Прикольно, когда старт сессии в одной партиции, а окончание в другой ??

если это лог то почему нет

проблема будет в извлечении

Партицирование таблицы и преагрегацию порезанных кусков уже советовали?

Да не выдумывай.

проблема будет в извлечении

Действительно, что это я. Надо улучшить одну проблему, чтобы получить еще и другую

Разработчики freeradius не могут предусмотреть всех "хотелок" тех, кто будет пользоваться их продуктом. Лет 10 назад, когда в компании, где я работал, прикручивали freeradius к биллингу, создали дополнительно еще несколько таблиц, для тех задач, которые нужны были биллингу, но не предусмотрены были во freeradius.

Прикольно, когда старт сессии в одной партиции, а окончание в другой ??

А если партицировать по хешу пользователя?

Правда это убивает идею преагрегации

А если партицировать по хешу пользователя?

Проще сделать ELT агрегаты в новой таблице

А если партицировать по хешу пользователя?

Денис, ты не идеи толкай, а полностью изложи мысль. ЕСЛИ мы сделаем то-то и то-то, ТО будет то-то И запрос будет работать ТАК. Я уверен, что когда ты дойдёшь до конца таких рассуждений, идеи отпадут

Правда это убивает идею преагрегации

Нахрена предагрегировать старые сессии, если ему нужны ПОСЛЕДНИЕ ?

Нахрена предагрегировать старые сессии, если ему нужны ПОСЛЕДНИЕ ?

Кстати, а что вообще ему нужно?

Чтобы ближе был...

есть запрос: explain SELECT username, max(acctstarttime) AS last_session_start , IFNULL(MAX(acctstoptime), 0) AS last_session_end, SUM(acctinputoctets+acctoutputoctets) AS data_usage FROM radacct GROUP BY username ORDER BY max(acctstoptime) ASC;

Кстати, а что вообще ему нужно?

О!, с этого и нужно начинать...

Если я правильно понимаю, это по факту таблица логирования. При таких объемах и требуемой скорости по ней real time аналитику не построишь. Значит, нужна ещё одна таблица, где у каждого пользователя будут апсертиться последние данные о сессии, чтобы сколько уникальных пользователей, столько и строк. Ну и агрегацию делать по ней

Ну это уже высказывали в обсуждении.

Ну тогда все правильно сказали, тут нужно архитектуру менять

Как посмотреть статистику заполнения таблспейсов в оракл

?

/stat@combot

combot.org/chat/-1001045152752

Как посмотреть статистику заполнения таблспейсов в оракл

dba_hist_tbspc_space_usage?

угу, направление примерно понятно, что делать. займусь ...

https://huntflow.ru/insight/article/recruting-in-tinder

годный мануал тутешним HR

Ты чатик не попутал?

Ненуашо

ой

не то )))

у ХР есть отдельные чаты

помницо эту хрюшу я тоже вежливо посылал. она мне java предлагала

хаха )))

Хрюша )) Надо запомнить

а я не хочу джаву.