Сроки выхода 6-сборки UTM 5.2.1

Magnum72

Wishmaster писал(а):
Lex писал(а):
Wishmaster писал(а):И второе, может всетаки есть смысл подумать над методикой переагрегации, для дальних периодов? Ведь нет никакого смысла хранить почасовую статистику за прошедший год...
Не думаю, что в этом есть большой смысл. Да и, как показала практика, в общем случае есть большое количество разнообразных моментов. Вплоть до того, что старый механизм переагрегации в общем случае неприменим в принципе. По многим причинам. Учитывая существующие цены на жесткие диски, не вижу смысла тратить ресурс на проектирование, реализацию и отладку нового механизма.
Ну, тут я бы поспорил.. Впрочем Ваш ответ более, чем ясен.

P.P.S. Во, вспомнил.. А создание новых архивных таблиц и соответственно перенос в них данные можно будет сделать не останавливая ядро? И в дальнейшем, надо ли будет хупать/ребутать ядро, чтобы оно увидело новую архивную таблицу?

Клево

далее делаем табличку с типом федератед и в ней ссылка на реальные архивные данные

Wishmaster

Lex писал(а): id - уникальный идентификатор записи;
archive_id - идентификатор архива, не может быть равен 0, должен быть уникален для каждого типа архивных таблиц
table_type - тип архивной таблицы, 1 для discount_transactions_all, 2 для discount_transactions_iptraffic_all

Вот такой момент уточните пожалуйста.

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

пример.

есть временной промежуток от А до Б, соответственно,
есть таблица типа 1 (А-Б) и типа 2 (А-Б), у них id будут к примеру 4 и 5. А вот archive_id у них должен быть к примеру, 7 и 7(т.е. равный) или 7 и 8?

XoRe · Сообщение **XoRe** » Чт апр 10, 2008 05:45

2Lex:
А может все-таки придумаете механизм аггрегации без потерь данных?
У вас есть все для этого: знание всех внутренних форматов БД, поддержка транзакций, программисты, и т.д.

Когда я запускаю отчет по трафику за неаггрегированный месяц, на обработку одного пользователя уходит 40-50 секунд.
1000 пользователей = 40 000 секунд = 11 часов.
После аггрегации с периодом в 1 час на одного пользователя уходит около 5 секунд.
Т.е. отчет формируется за 1,5 часа.
С таким подходом, какой предлагаете вы, отчет за пол года я имею шанс просто не дождаться.
Админка вывалится по таймауту раньше, чем завершатся все подсчеты.
Дело-то не только в жестком диске, а в процессоре и оперативной памяти.
А оперативной памяти много не поставишь на x86 платформе.
Фактически, можно было и раньше сделать такие преобразования с БД.
Возможно кто-то уже такое сделал и просто делает отчеты своими средствами.
Данное нововведение просто позволит ядру "знать", где можно взять данные за прошлые периоды.
И это только полезно для нескольких отчетов.

Так может просто почините тот функционал, который имеется?

mikkey finn

я вот думаю, а нет ли смысла повесить триггер, который будет срабатывать в 3:00 в новом месяце и выпихивать в архив данные старше позапрошлого месяца?..

XoRe · Сообщение **XoRe** » Чт апр 10, 2008 10:58

Да перепихать данные - не проблема.
Хоть триггером, хоть кроном, хоть ручками запускать ежемесячно.
Суть в том, что основные мольбы по поводу таблиц discount_transactions_* связаны с низким быстродействием при формировании отчетов.
Предлагаемый подход быстродействие никак не улучшит.
Хотя... если делать новые таблицы каждый день, то в этом случае быстродействие должно быть получше )
Вот только осилит ли биллинг столько таблиц?

2Lex:
Не могли бы вы сказать, осилит ли биллинг большое число таблиц с данными за короткий промежуток?
Например, 5000 таблиц с данными за 1 час?

Сообщение **Lex** » Чт апр 10, 2008 11:20

Wishmaster писал(а):
Lex писал(а): id - уникальный идентификатор записи;
archive_id - идентификатор архива, не может быть равен 0, должен быть уникален для каждого типа архивных таблиц
table_type - тип архивной таблицы, 1 для discount_transactions_all, 2 для discount_transactions_iptraffic_all
Вот такой момент уточните пожалуйста.

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

пример.

есть временной промежуток от А до Б, соответственно,
есть таблица типа 1 (А-Б) и типа 2 (А-Б), у них id будут к примеру 4 и 5. А вот archive_id у них должен быть к примеру, 7 и 7(т.е. равный) или 7 и 8?

Требование следующее - пара archive_id, table_type должна быть уникальна. Остальное - рекомендации, которым можно следовать а можно и не следовать.

Сообщение **Lex** » Чт апр 10, 2008 11:23

XoRe писал(а):Не могли бы вы сказать, осилит ли биллинг большое число таблиц с данными за короткий промежуток?
Например, 5000 таблиц с данными за 1 час?

Потенциально проблем быть не должно, однако я не вижу в этом особого смысла.

Magnum72

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

1) Добавить в список таблицы в порядке важности :
dhs_sessions_log
balance_history
invoice_entry invoice_entry_details
user_log

2) добавить в таблицу arhives еще одно поле "название базы" в которой искать эти таблицы, это весьма важно иметь возможность держать данные в другой базе данных на этом же сервере, упростится механизм бекапирования и не будет разрастатся список таблиц в основной базе данных

Magnum72

Еще большая просьба к релизу поправить форматы таблиц:

например: user_log будет замечательно смотрется и работать в таком виде:

Код: Выделить всё

CREATE TABLE IF NOT EXISTS `user_log` &#40;
  `user_id` SMALLINT&#40;5&#41; UNSIGNED NOT NULL,
  `date` INT&#40;10&#41; UNSIGNED NOT NULL,
  `who` TINYINT&#40;4&#41;  NOT NULL,
  `what` varchar&#40;30&#41; default NULL,
  `comment` varchar&#40;170&#41; default NULL,
  KEY `user_id` &#40;`user_id`&#41;
&#41; ENGINE=InnoDB  DEFAULT CHARSET=utf8;

А если потом в ежемесячную оптимизацию воткнуть еще команду:

Код: Выделить всё

ALTER TABLE `user_log` ORDER BY `user_id`

будет еще чуточку быстрее выбиратся

atdp03 · Сообщение **atdp03** » Чт апр 10, 2008 13:49

Magnum72 писал(а): 2) добавить в таблицу arhives еще одно поле "название базы" в которой искать эти таблицы, это весьма важно иметь возможность держать данные в другой базе данных на этом же сервере, упростится механизм бекапирования и не будет разрастатся список таблиц в основной базе данных

Категорически присоединяюсь.

Сообщение **Lex** » Чт апр 10, 2008 17:04

Magnum72 писал(а):можно несколько критичных просьб к механизму архивирования, лучше это сделать счас пока прогррамисты держат этот код в голове, и на мой взгляд это не потребует серьезных переделок:

1) Добавить в список таблицы в порядке важности :
dhs_sessions_log
balance_history
invoice_entry invoice_entry_details
user_log

2) добавить в таблицу arhives еще одно поле "название базы" в которой искать эти таблицы, это весьма важно иметь возможность держать данные в другой базе данных на этом же сервере, упростится механизм бекапирования и не будет разрастатся список таблиц в основной базе данных

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

Magnum72

Lex писал(а):других отчетах. Что же касается другой базы данных, то, насколько я помню, запись вида <имя базы данных>.<таблица> по крайней мере у нас на стендах.

Я в шоке, премию разработчику и программерам выпишите... Молодцы, не просто прислушались и сделали но по своему, а сделали лучше и так как надо.

JAO · Сообщение **JAO** » Пт апр 11, 2008 09:31

Разработчикам.

Я вот в самописной статистической системе сделал почасовую агрегацию на лету, вместо имен сайтов поставил их идентификаторы, чем сделал во всех таблицах статическую длину ряда, потом вынес в отдельную таблицу суммарный трафик по сайтам за каждый час, все имена сайтов сложил в отдельную таблицу... и до кучи саму статистику разложил по схеме "один IP - одна таблица"

Чего я достиг всем этим? А вот чего: отчеты равно и легкие и тяжеловесные (типа десятки самых используемых сайтов по трафику за один год), выполняются за вполне приемлемое время на среднем железе. По крайней мере отчеты за годовой период дольше пяти минут не делались. Да и сама база со статистикой шести сотен ребят за два года весит всего 668 мегабайт.

Это так, информация для размышления. Про пользу временных таблиц при построении сложных отчетов я где-то уже говорил.

ТЗ не было. Сам творю по ходу дела. Начитался умных статей и повертел со всех сторон базу UTM.

Magnum72

Я вот в самописной статистической системе сделал почасовую агрегацию на лету, вместо имен сайтов поставил их идентификаторы, чем сделал во всех таблицах статическую длину ряда, потом вынес в отдельную таблицу суммарный трафик по сайтам за каждый час, все имена сайтов сложил в отдельную таблицу... и до кучи саму статистику разложил по схеме "один IP - одна таблица"

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

JAO · Сообщение **JAO** » Пт апр 11, 2008 15:01

Эта система пока не запущена в дело. Поэтому местами не отработана еще. Но вот что касается отчетов - изложил как есть.