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

Технические вопросы по UTM 5.0
Ответить
Utm3_user
Сообщения: 35
Зарегистрирован: Пт мар 18, 2005 07:52
Откуда: Канск

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

Сообщение Utm3_user »

Скажите пожалуйста когда выйдет 6-я сборка UTM 5.2.1? Сейчас сидим на 4-ой и переходить на 5-ю после прочтения отзывов нет никакаго желания. Слишком много косяков.

Anton
Сообщения: 339
Зарегистрирован: Пт июл 01, 2005 10:57

Сообщение Anton »

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

mikkey finn
Сообщения: 1612
Зарегистрирован: Пт ноя 10, 2006 15:23

Сообщение mikkey finn »

к концу апреля какого года?

Аватара пользователя
Chris
Сообщения: 2323
Зарегистрирован: Чт июн 02, 2005 14:08
Откуда: 33 76 77 71 86 37 98

Сообщение Chris »

2mikkey finn: смешно :_)

Аватара пользователя
XoRe
Сообщения: 458
Зарегистрирован: Ср янв 10, 2007 16:04

Сообщение XoRe »

2Utm3_user:
Вроде как дают по запросу в хотлайне.
Т.е. если есть оплаченная техподдержка или тех. сопровождение или что-то типа этого.

Wishmaster
Сообщения: 309
Зарегистрирован: Сб апр 16, 2005 11:44

Сообщение Wishmaster »

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

Аватара пользователя
Lex
NetUP Team
Сообщения: 623
Зарегистрирован: Ср мар 09, 2005 12:12
Откуда: НетАП
Контактная информация:

Сообщение Lex »

Wishmaster писал(а):давать-то дают, только в ней не работает то, что всем так нужно, а именно, новый принцип хранения списаний... ТП говорит, что заработает в релизной версии... когда будет, неизвестно...
Что именно не работает? Насколько я знаю, существенных проблем в настоящий момент нет. Если Вы имеете в виду описание нового механизма архивирования, то оно будет доступно после выпуска первого релиз-кандидата.
Кстати, первый релиз-кандидат официально выйдет в течение ближайших двух недель - сейчас ведется подготовка сборок и окончательное тестирование.

Wishmaster
Сообщения: 309
Зарегистрирован: Сб апр 16, 2005 11:44

Сообщение Wishmaster »

Да, уважаемый Lex, именно нового механизма все и ждут, потому, что вроде, в остальном все более-менее, по крайней мере у меня. Проблема в том, что база растет очень быстро, а сроки от вас туманны, ни техподдержка, ни info не могут сказать даже приблизительно. Вот я как админ сижу и думаю, что мне делать, с таблицами, размер которых за два месяца составил по 50 гигабайт.

От ТП поступило только два варианта - ждать выхода 006 сборки (неизвестно сколько), либо платить деньги, чтобы ваши специалисты сделали то, что должно быть "по-умолчанию".

Поверьте, я не предъявляю претензий, и целиком и полностью осознаю, трудоемкость разработки и тестирования такого продукта, как УТМ. Просто, хотелось бы во-первых, более-менее реальных сроков и второе, более "раскрепощенную" техподдержку, которая не будет отвечать стандарными фразами типа "Это выходит за рамки техподдержки".

Если уж нет возможности выпустить сборку с рабочим механизмом, а вы предлагаете за деньги провести оптимизацию, то нельзя ли описать суть этой оптимизации, не прикрываясь фразами на счет "комплексного анализа" и "модификации исходного кода". Просто скажите, по какому принципу нужно суммировать/удалить записи в таблицах discount_transactions_all и discount_transactions_iptraffic_all, чтобы статистика была с интервалом в сутки. Для меня это более чем достаточно.

Извините, ничего личного, просто наболело.

Аватара пользователя
Lex
NetUP Team
Сообщения: 623
Зарегистрирован: Ср мар 09, 2005 12:12
Откуда: НетАП
Контактная информация:

Сообщение Lex »

Wishmaster писал(а):Да, уважаемый Lex, именно нового механизма все и ждут, потому, что вроде, в остальном все более-менее, по крайней мере у меня. Проблема в том, что база растет очень быстро, а сроки от вас туманны, ни техподдержка, ни info не могут сказать даже приблизительно. Вот я как админ сижу и думаю, что мне делать, с таблицами, размер которых за два месяца составил по 50 гигабайт.

От ТП поступило только два варианта - ждать выхода 006 сборки (неизвестно сколько), либо платить деньги, чтобы ваши специалисты сделали то, что должно быть "по-умолчанию".

Поверьте, я не предъявляю претензий, и целиком и полностью осознаю, трудоемкость разработки и тестирования такого продукта, как УТМ. Просто, хотелось бы во-первых, более-менее реальных сроков и второе, более "раскрепощенную" техподдержку, которая не будет отвечать стандарными фразами типа "Это выходит за рамки техподдержки".

Если уж нет возможности выпустить сборку с рабочим механизмом, а вы предлагаете за деньги провести оптимизацию, то нельзя ли описать суть этой оптимизации, не прикрываясь фразами на счет "комплексного анализа" и "модификации исходного кода". Просто скажите, по какому принципу нужно суммировать/удалить записи в таблицах discount_transactions_all и discount_transactions_iptraffic_all, чтобы статистика была с интервалом в сутки. Для меня это более чем достаточно.

Извините, ничего личного, просто наболело.
Суммировать ничего не нужно - это неминуемо приведет к потере данных. Суть нового механизма состоит в том, что можно будет разнести данные о списаниях, которые составляют существенную часть объема базы данных по разным таблицам без потери функциональности, т.е. без потери информации в отчетах. При необходимости генерации отчета, который затрагивает данные в нескольких таблицах, ядро будет последовательно выбирать данные из тех таблиц, в которых эти данные хранятся. Данные нужно будет переносить вручную, используя существующие средства СУБД, что позволяет снизить риск того, что по причине возникновения программной ошибки или иного сбоя какие-то данные потеряются. Общие рекомендации и особенности механизма мы опубликуем после выхода релиз-кандидата, но, в принципе, могу сейчас озвучить некоторые из них. В принципе, указанная информация в дальнейшем ляжет в основу соответствующей статьи, так что можно считать это официальной предварительной публикацией (анонсом) и использовать данную информацию на стендовых машинах для проведения подготовки к осуществлению архивации и проверки корректности производимых действий.

Внимание! Перед выполнением любых действий с БД UTM5 в обязательном порядке следует сделать полную резервную копию БД UTM5 и проверить возможность восстановления данных из этой резервной копии. Дальнейший текст предназначен только для тех, кто понимает что делает и имеет достаточный уровень технических знаний в области работы с СУБД. Вопросы, касательно способов манипуляции данными средствами СУБД останутся без ответа по существу, в том числе и если они будут заданы в hotline. Перед проведением любых действий рекомендуется отработать их на стендовой машине

1. В настоящий момент механизм архивирования распространяет свое действие на таблицы discount_transactions_all и discount_transactions_iptraffic_all. В данных таблицах содержится информация о транзакциях изменения балансов лицевых счетов и транзакциях списаний за трафик. На основании информации, хранящейся в данных таблицах строится основной отчет и отчет по трафику. Также таблица discount_transactions_all хранит некоторую информацию, которая в настоящий момент в формировании отчетов не участвует, но в дальнейшем возможно её использование. Также эта информация бывает полезна при проведении диагностики.
2. Транзакции списаний за трафик являются подмножеством транзакций изменения балансов лицевых счетов, поэтом записи в указанных выше таблицах связаны. Если для записи в таблице discount_transactions_all установлен service_type в значение равное 3, то должна существовать запись с таким же id, discount_date и discount в таблице discount_transactions_iptraffic_all. Невыполнение данного условие считается нарушением логической целостности БД.
3. В сборке 5.2.1-006 введена таблица archives со следующими полями:
id - уникальный идентификатор записи;
archive_id - идентификатор архива, не может быть равен 0, должен быть уникален для каждого типа архивных таблиц
table_type - тип архивной таблицы, 1 для discount_transactions_all, 2 для discount_transactions_iptraffic_all
table_name - имя архивной таблицы
start_date - время, которым датировано первое списание в архиве (UNIX TIMESTAMP)
end_date - время, которым датировано последнее списание в архиве (UNIX TIMESTAMP)
4. Архивные таблицы должны иметь такую же структуру, как и таблица соответствующего типа в установленной сборке.
5. Архивная таблица должна содержать только данные, датированные временем, входящим в диапазон, указанный в соответствующей данной таблице записи в таблице archives.
6. Никакая таблица, кроме той, которая указана в таблице archives не должна содержать записи, датированные временем, указанным в записи таблицы archives.
7. Если для какого-то момента времени записи в таблице archives нет, то эти данные должны содержаться в таблице discount_transactions_all.
8. Если в таблице archives отсутствует запись определенного типа для какого либо времени, то эта списания, датированные данным временем должны храниться в основной таблице с информацией о транзакциях соответствующего типа.
9. Рекомендуется архивировать данные таблиц discount_transactions_all и discount_transactions_iptraffic_all и discount_transactions_iptraffic_all симметрично, т.е. если запись в таблице discount_transactions_all содержится в архивной таблице с определенным идентификатором архива, то и записи в таблице discount_transactions_iptraffic_all должна храниться в архивной таблицы с соответствующим идентификатором архива.
10. Для архивных таблиц следует выбирать имя, которое начинается с имени основной таблицы.
11. Архивная таблица может не поддерживать транзакции и быть доступна в режиме только чтения.

Это основные моменты, которые пишу на память, если есть что-то ещё важное - дополню завтра.

Wishmaster
Сообщения: 309
Зарегистрирован: Сб апр 16, 2005 11:44

Сообщение Wishmaster »

Хм. В общем, впечатляет. Есть вопрос, в дальнейшем, ядро само будет создавать новые таблицы с заданным интервалом, скажем, в месяц? Или это вручную/утилитой делать придется?

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

P.S. Если позволите, несколько нескромный вопрос.. Допустим, с принципом новой методики хранения все ясно. Но не могли бы вы сказать, в чем заключается оптимизация, которую выполняют сотрудники вашей компании за деньги? Как я понимаю, это не имеет отношения к новому механизму хранения списаний..

P.P.S. Во, вспомнил.. А создание новых архивных таблиц и соответственно перенос в них данные можно будет сделать не останавливая ядро? И в дальнейшем, надо ли будет хупать/ребутать ядро, чтобы оно увидело новую архивную таблицу?
Последний раз редактировалось Wishmaster Ср апр 09, 2008 01:26, всего редактировалось 1 раз.

Аватара пользователя
Lex
NetUP Team
Сообщения: 623
Зарегистрирован: Ср мар 09, 2005 12:12
Откуда: НетАП
Контактная информация:

Сообщение Lex »

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

Wishmaster
Сообщения: 309
Зарегистрирован: Сб апр 16, 2005 11:44

Сообщение Wishmaster »

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

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

master_weba
Сообщения: 21
Зарегистрирован: Ср мар 26, 2008 07:44

Сообщение master_weba »

А в урфа-клиенте появятся команды для осуществления архивирования?

Аватара пользователя
Lex
NetUP Team
Сообщения: 623
Зарегистрирован: Ср мар 09, 2005 12:12
Откуда: НетАП
Контактная информация:

Сообщение Lex »

Wishmaster писал(а):А создание новых архивных таблиц и соответственно перенос в них данные можно будет сделать не останавливая ядро? И в дальнейшем, надо ли будет хупать/ребутать ядро, чтобы оно увидело новую архивную таблицу?
Всё зависит от способа архивирования. Если не создавать препятствий для записи в таблицы discount_transactions_all и discount_transactions_iptraffic_all, то действия по архивированию можно производить и при запущенном ядре. Перезагружать ядро при добавлении новых записей в таблице archives не нужно - данные из этой таблице не кэшируются.

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

Аватара пользователя
Lex
NetUP Team
Сообщения: 623
Зарегистрирован: Ср мар 09, 2005 12:12
Откуда: НетАП
Контактная информация:

Сообщение Lex »

master_weba писал(а):А в урфа-клиенте появятся команды для осуществления архивирования?
Я писал выше, что средств автоматического архивирования не будет в ближайшее время, следовательно и URFA-функции, выполняющей нужные действия тоже не будет.

Ответить