Сроки выхода 6-сборки UTM 5.2.1
Сроки выхода 6-сборки UTM 5.2.1
Скажите пожалуйста когда выйдет 6-я сборка UTM 5.2.1? Сейчас сидим на 4-ой и переходить на 5-ю после прочтения отзывов нет никакаго желания. Слишком много косяков.
-
- Сообщения: 1612
- Зарегистрирован: Пт ноя 10, 2006 15:23
-
- Сообщения: 309
- Зарегистрирован: Сб апр 16, 2005 11:44
- Lex
- NetUP Team
- Сообщения: 623
- Зарегистрирован: Ср мар 09, 2005 12:12
- Откуда: НетАП
- Контактная информация:
Что именно не работает? Насколько я знаю, существенных проблем в настоящий момент нет. Если Вы имеете в виду описание нового механизма архивирования, то оно будет доступно после выпуска первого релиз-кандидата.Wishmaster писал(а):давать-то дают, только в ней не работает то, что всем так нужно, а именно, новый принцип хранения списаний... ТП говорит, что заработает в релизной версии... когда будет, неизвестно...
Кстати, первый релиз-кандидат официально выйдет в течение ближайших двух недель - сейчас ведется подготовка сборок и окончательное тестирование.
-
- Сообщения: 309
- Зарегистрирован: Сб апр 16, 2005 11:44
Да, уважаемый Lex, именно нового механизма все и ждут, потому, что вроде, в остальном все более-менее, по крайней мере у меня. Проблема в том, что база растет очень быстро, а сроки от вас туманны, ни техподдержка, ни info не могут сказать даже приблизительно. Вот я как админ сижу и думаю, что мне делать, с таблицами, размер которых за два месяца составил по 50 гигабайт.
От ТП поступило только два варианта - ждать выхода 006 сборки (неизвестно сколько), либо платить деньги, чтобы ваши специалисты сделали то, что должно быть "по-умолчанию".
Поверьте, я не предъявляю претензий, и целиком и полностью осознаю, трудоемкость разработки и тестирования такого продукта, как УТМ. Просто, хотелось бы во-первых, более-менее реальных сроков и второе, более "раскрепощенную" техподдержку, которая не будет отвечать стандарными фразами типа "Это выходит за рамки техподдержки".
Если уж нет возможности выпустить сборку с рабочим механизмом, а вы предлагаете за деньги провести оптимизацию, то нельзя ли описать суть этой оптимизации, не прикрываясь фразами на счет "комплексного анализа" и "модификации исходного кода". Просто скажите, по какому принципу нужно суммировать/удалить записи в таблицах discount_transactions_all и discount_transactions_iptraffic_all, чтобы статистика была с интервалом в сутки. Для меня это более чем достаточно.
Извините, ничего личного, просто наболело.
От ТП поступило только два варианта - ждать выхода 006 сборки (неизвестно сколько), либо платить деньги, чтобы ваши специалисты сделали то, что должно быть "по-умолчанию".
Поверьте, я не предъявляю претензий, и целиком и полностью осознаю, трудоемкость разработки и тестирования такого продукта, как УТМ. Просто, хотелось бы во-первых, более-менее реальных сроков и второе, более "раскрепощенную" техподдержку, которая не будет отвечать стандарными фразами типа "Это выходит за рамки техподдержки".
Если уж нет возможности выпустить сборку с рабочим механизмом, а вы предлагаете за деньги провести оптимизацию, то нельзя ли описать суть этой оптимизации, не прикрываясь фразами на счет "комплексного анализа" и "модификации исходного кода". Просто скажите, по какому принципу нужно суммировать/удалить записи в таблицах discount_transactions_all и discount_transactions_iptraffic_all, чтобы статистика была с интервалом в сутки. Для меня это более чем достаточно.
Извините, ничего личного, просто наболело.
- Lex
- NetUP Team
- Сообщения: 623
- Зарегистрирован: Ср мар 09, 2005 12:12
- Откуда: НетАП
- Контактная информация:
Суммировать ничего не нужно - это неминуемо приведет к потере данных. Суть нового механизма состоит в том, что можно будет разнести данные о списаниях, которые составляют существенную часть объема базы данных по разным таблицам без потери функциональности, т.е. без потери информации в отчетах. При необходимости генерации отчета, который затрагивает данные в нескольких таблицах, ядро будет последовательно выбирать данные из тех таблиц, в которых эти данные хранятся. Данные нужно будет переносить вручную, используя существующие средства СУБД, что позволяет снизить риск того, что по причине возникновения программной ошибки или иного сбоя какие-то данные потеряются. Общие рекомендации и особенности механизма мы опубликуем после выхода релиз-кандидата, но, в принципе, могу сейчас озвучить некоторые из них. В принципе, указанная информация в дальнейшем ляжет в основу соответствующей статьи, так что можно считать это официальной предварительной публикацией (анонсом) и использовать данную информацию на стендовых машинах для проведения подготовки к осуществлению архивации и проверки корректности производимых действий.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. Архивная таблица может не поддерживать транзакции и быть доступна в режиме только чтения.
Это основные моменты, которые пишу на память, если есть что-то ещё важное - дополню завтра.
-
- Сообщения: 309
- Зарегистрирован: Сб апр 16, 2005 11:44
Хм. В общем, впечатляет. Есть вопрос, в дальнейшем, ядро само будет создавать новые таблицы с заданным интервалом, скажем, в месяц? Или это вручную/утилитой делать придется?
И второе, может всетаки есть смысл подумать над методикой переагрегации, для дальних периодов? Ведь нет никакого смысла хранить почасовую статистику за прошедший год...
P.S. Если позволите, несколько нескромный вопрос.. Допустим, с принципом новой методики хранения все ясно. Но не могли бы вы сказать, в чем заключается оптимизация, которую выполняют сотрудники вашей компании за деньги? Как я понимаю, это не имеет отношения к новому механизму хранения списаний..
P.P.S. Во, вспомнил.. А создание новых архивных таблиц и соответственно перенос в них данные можно будет сделать не останавливая ядро? И в дальнейшем, надо ли будет хупать/ребутать ядро, чтобы оно увидело новую архивную таблицу?
И второе, может всетаки есть смысл подумать над методикой переагрегации, для дальних периодов? Ведь нет никакого смысла хранить почасовую статистику за прошедший год...
P.S. Если позволите, несколько нескромный вопрос.. Допустим, с принципом новой методики хранения все ясно. Но не могли бы вы сказать, в чем заключается оптимизация, которую выполняют сотрудники вашей компании за деньги? Как я понимаю, это не имеет отношения к новому механизму хранения списаний..
P.P.S. Во, вспомнил.. А создание новых архивных таблиц и соответственно перенос в них данные можно будет сделать не останавливая ядро? И в дальнейшем, надо ли будет хупать/ребутать ядро, чтобы оно увидело новую архивную таблицу?
Последний раз редактировалось Wishmaster Ср апр 09, 2008 01:26, всего редактировалось 1 раз.
- Lex
- NetUP Team
- Сообщения: 623
- Зарегистрирован: Ср мар 09, 2005 12:12
- Откуда: НетАП
- Контактная информация:
В ближайшие полгода-год мы не будем делать автоматического механизма. Думаю, вполне достаточно существующего механизма, а дальше каждый сам решает, нужно это или не нужно, как часто это следует делать и по какому прниципу.Wishmaster писал(а):Хм. В общем, впечатляет. Есть вопрос, в дальнейшем, ядро само будет создавать новые таблицы с заданным интервалом, скажем, в месяц? Или это вручную/утилитой делать придется
Не думаю, что в этом есть большой смысл. Да и, как показала практика, в общем случае есть большое количество разнообразных моментов. Вплоть до того, что старый механизм переагрегации в общем случае неприменим в принципе. По многим причинам. Учитывая существующие цены на жесткие диски, не вижу смысла тратить ресурс на проектирование, реализацию и отладку нового механизма.Wishmaster писал(а):И второе, может всетаки есть смысл подумать над методикой переагрегации, для дальних периодов? Ведь нет никакого смысла хранить почасовую статистику за прошедший год...
-
- Сообщения: 309
- Зарегистрирован: Сб апр 16, 2005 11:44
Ну, тут я бы поспорил.. Впрочем Ваш ответ более, чем ясен.Lex писал(а):Не думаю, что в этом есть большой смысл. Да и, как показала практика, в общем случае есть большое количество разнообразных моментов. Вплоть до того, что старый механизм переагрегации в общем случае неприменим в принципе. По многим причинам. Учитывая существующие цены на жесткие диски, не вижу смысла тратить ресурс на проектирование, реализацию и отладку нового механизма.Wishmaster писал(а):И второе, может всетаки есть смысл подумать над методикой переагрегации, для дальних периодов? Ведь нет никакого смысла хранить почасовую статистику за прошедший год...
P.P.S. Во, вспомнил.. А создание новых архивных таблиц и соответственно перенос в них данные можно будет сделать не останавливая ядро? И в дальнейшем, надо ли будет хупать/ребутать ядро, чтобы оно увидело новую архивную таблицу?
-
- Сообщения: 21
- Зарегистрирован: Ср мар 26, 2008 07:44
- Lex
- NetUP Team
- Сообщения: 623
- Зарегистрирован: Ср мар 09, 2005 12:12
- Откуда: НетАП
- Контактная информация:
Всё зависит от способа архивирования. Если не создавать препятствий для записи в таблицы discount_transactions_all и discount_transactions_iptraffic_all, то действия по архивированию можно производить и при запущенном ядре. Перезагружать ядро при добавлении новых записей в таблице archives не нужно - данные из этой таблице не кэшируются.Wishmaster писал(а):А создание новых архивных таблиц и соответственно перенос в них данные можно будет сделать не останавливая ядро? И в дальнейшем, надо ли будет хупать/ребутать ядро, чтобы оно увидело новую архивную таблицу?
Да, совсем забыл. В текущей реализации при построении графического отчета по трафику данные из архивных таблиц не используются.