или руками стартануть mysqld

вот руками я и стратую

ну погоди

щя

для этого существует build number

есть релиз, у которого есть статус (alpha, beta, release candidate, general availability), есть уникальный номер, по номеру можно получить раздел в документации со списком изменений. ты на каждый билд намбер и git hash собрался раздел в документации писать?

ох

есть список фич к релизу

они имплементятся, выкатываются, в другой ветке готовится следующий

после этого идут только баг фиксы к этим фичам

после того, как на кандидат нет жалоб, он просто промоутится до релиза

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

и вот тогда в поддержке действительно будет ад

а серьёзно, сколько тебе лет и кем ты работаешь? вот если так, честно. судя по юношескому задору, не больше 25-ти, а судя по экспертным познаниям во всех областях — админ Вася в "Пупкин Телеком". ты бы сказал, я бы просто перестал время тратить

ахаха

давайте все сведем к возрасту

26

старый(

как и все мы

И вообще я разраб. Жаба, жвм, стримы.

я понял. спасибо

Привет! Сорри, что не совсем в тему канала :) 14-го июля в Питере проводим конференцию по мониторингу. Приглашаем всех желающих :) Если есть желание выступить с докладом - будем рады видеть, места еще есть! :) Регистрация тут: https://rossinno.timepad.ru/event/510831/ или тут: https://www.meetup.com/Big-Monitoring-Meetup/events/240837973/ Вопросы по участию или выступлению - через личные сообщения :)

Всем привет! Есть БД пополняемая новыми записями каждые пол часа. Есть софт, который делает выборку из базы каждые 5-10 минут для сбора и отображения статистики за последние сутки от текущего времени с разбивкой по часам. Можно ли сделать представление (view) с привязкой к текущему времени?

Смысл в том, чтобы перенести вычисления и формирование статистики на сервер БД т. к. софт генерит кучу запросов каждый раз и подыисает, пока БД отдаст все данные

можно ли в запросе использовать переменную с текущим временем сервера для формирования представления?

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

короче, попробую объяснить ещё раз. сразу говорю я не профи в БД. есть база в которую в несколько таблиц подгружаются данные скриптами каждые полчаса. ест софтина которая тянет выборки данных за последние сутки с разбивкой по часу. обновляются эти данные каждые 5 минут. т. е. каждые 5 минут имеем кучу запросов: по 24 на каждый элемент статистики, и таких элементов порядка 200.

Т.е. есть желание использовать вью для агрегации данных и тащить оттуда?

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

Т.е. есть желание использовать вью для агрегации данных и тащить оттуда?

Именно

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

А в тех таблицах куда пишутся данные есть поля datetime?

Т.е. я так понимаю, что нужно приходить во вью и получать из неё данные ,допустим за последний час. Правильно?

да есть, и есть еще таймстемп для каждой записи, но важнее привязка к именно дэйттайм

Т.е. я так понимаю, что нужно приходить во вью и получать из неё данные ,допустим за последний час. Правильно?

в идеале во вью должны быть данные за последние 24 часа от сейчас с разбивкой по часу

пока нашел только, что вью обновляется по факту запроса и не ясно как привязатся к текущему времени

в идеале во вью должны быть данные за последние 24 часа от сейчас с разбивкой по часу

Ясно. Не думаю, что не возможно. Скинь структуру нескольких таблиц, попробую помочь

в самом софте весьма замороченная математика с датой и временем для этого

сейчас к сожалению не могу скинуть т. к. с телефона.

Самый простой способ получать данные за последние 24 часа примерно такой: SELECT * FROM table_view WHERE create_time BETWEEN NOW() AND NOW()-INTERVAL 24 HOUR;

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

Самый простой способ получать данные за последние 24 часа примерно такой: SELECT * FROM table_view WHERE create_time BETWEEN NOW() AND NOW()-INTERVAL 24 HOUR;

ого, уже хорошо! а как оно в плане учета минут/секунд?

ого, уже хорошо! а как оно в плане учета минут/секунд?

Мы используем вот такое поле для регистрации времени записи

`insert_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP

ого, уже хорошо! а как оно в плане учета минут/секунд?

вплоть до секунд

а нужно по часаМ?

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

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

т. е. есть поля типа: id, name, type, result1, result1, starttime, endtime, timestamp

нужно группировать по name и учитывать как starttime так и endtime

Самый простой способ получать данные за последние 24 часа примерно такой: SELECT * FROM table_view WHERE create_time BETWEEN NOW() AND NOW()-INTERVAL 24 HOUR;

Тут я ошибся немного. Правильно вот так: SELECT * FROM table_view WHERE create_time BETWEEN NOW()-INTERVAL 24 HOUR AND NOW();

для результата либа sum либо count либо max

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

Подтверждаю, работает и для полей типа datetime

нужно группировать по name и учитывать как starttime так и endtime

тут нужно больше подроьностей и примерный результирующий вид

тогда попробую помочь

на первый взгляд трудностей не должно быть

по крайней мере по условие - за последние 24 часа

например есть набор записей с одинаковым полем name, starttime и endtime произвольные. нужно выбирать сумму или количество по полю result за каждый час с (х):00:00 по (х+1):00:00 за период сейчас-24 час до сейчас

геморой именно в отсечке по часу и привязке к 0 минут 0 секунд.

в поинципе можно привязываться именно к starttime

результат нужен в виде таблицы: период(час) /результат за период

понял

читаю про функции времени мускула - есть функция HOUR вроде она должна возвращать количество часов и есть EXTRACT которая выдает из дэйттайм год/месяц/день/час/минуту/секунду

Примерно вот так мы вибираем записи за неделю -- Понедельник прошлой недели SET @_from_date = STR_TO_DATE(DATE_FORMAT(CURDATE() - INTERVAL 1 WEEK - INTERVAL DAYOFWEEK(CURDATE()) - 2 DAY, '%Y-%m-%d 00:00:00'), '%Y-%m-%d %H:%i:%s'); # по -- Воскресенье прошлой недели SET @_to_date = STR_TO_DATE(DATE_FORMAT(CURDATE() - INTERVAL 1 WEEK - INTERVAL DAYOFWEEK(CURDATE()) - 2 DAY + INTERVAL 6 DAY, '%Y-%m-%d 23:59:59'), '%Y-%m-%d %H:%i:%s');

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

лучше глядеть на это в одну строку

)

соответственно условие имеет вид: WHERE datetime BETWEEN @_from_date AND @_to_date

соответственно условие имеет вид: WHERE datetime BETWEEN @_from_date AND @_to_date

ну такие запросы у меня есть уже в софте - формируются для каждого часа пачками. Вся магия в подсчёте from_daye и end_date

а как можно сравнить нагрузку на сервер между кучей простых запросов и таким замороченным вью? может оно того и не стоит?

смотрите показатели LA

утилизацию процессора, озу

чтение с дисков

собственно все

смотрите показатели LA

можно для тупых, я пользуюсь phpmyadmin - куда смотреть?

или смотреть в тор на машине?

linux?

да ubuntu server lts

htop

будет понятнее

ок

а можно собрать вью из других вью?

и как они будут тогда обновляться?

iostat -xt 1 для диска

iostat - Report Central Processing Unit (CPU) statistics and input/output statistics for devices, partitions and network filesystems (NFS).

вью не хранит данные

при обращении ко вью (только SELECT)

выполняются те запросы, которые вы туда накидаете

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

вложенность вью допускается?

а что мешает вместо вью сделать хранимую процедуру и привязаться ко времени?

а что мешает вместо вью сделать хранимую процедуру и привязаться ко времени?

я вообще не против. просто про хранимые процедуры не в курсе

это не сложнее представления, нисколечка

можете хоть простой пример дать для понимания?

я так понял что хранимые процедуры это удобные обертки для sql запросов

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

ну можно ещё собрать в процедуру несколько запросов как я понял

можно