"Склеивание" таблиц списаний из старых сборок

wingman

В старых сборках была такая фича - склеивание таблиц списаний (discount_...), в админке было "дополнительно - оптимизация".
К сожалению, в новых сборках его убрали, заменив новым механизмом архивации. Но как по мне, так лучше бы его вернуть, и применять как раз на заархивированные таблицы; более, чем суточная детализация (нам, по крайней мере) в них не нужна.

Так вот, никто случаем не писал скрипт такого "склеивания"? Поделитесь пожалуйста, если есть у кого. Могу в принципе и сам наваять, но времени совсем нету, а там без бутылки явно не разобраться =)

kirush · Сообщение **kirush** » Ср дек 09, 2009 12:51

viewtopic.php?t=7492

wingman

kirush писал(а):viewtopic.php?t=7492

Спасибо, но я как бы немного не о том. Архивирование у меня итак без проблем работает.
Вопрос в следующем: кто-нибуть реализовывал "склеивание" сходных записей таблиц списаний, так, чтобы, например, вместо тысячи записей трафика за сутки для одного аккаунта была одна запись с общей суммой?
Этот механизм был убран из UTM > 5-2.1.005, но мне бы он очень пригодился для уменьшения веса архивных таблиц.

JAO · Сообщение **JAO** » Ср дек 09, 2009 20:15

Для уменьшения веса на MySQL можно сделать ALTER TABLE ... ENGINE=MyISAM на архивных таблицах, а после попробовать myisampack. При таком эксперименте лучше держать резервную копию исходных таблиц. Это если данные не менять. А если менять, как предложено, то у меня где-то был агрегационный запрос, найду, отпишусь.

wingman

JAO писал(а):Для уменьшения веса на MySQL можно сделать ALTER TABLE ... ENGINE=MyISAM на архивных таблицах, а после попробовать myisampack. При таком эксперименте лучше держать резервную копию исходных таблиц. Это если данные не менять. А если менять, как предложено, то у меня где-то был агрегационный запрос, найду, отпишусь.

Оно давно уже в майисам =) Я неверно выразился: вес непосредственно данных по барабану, но ОЧЕНЬ хочется уменьшить вес индексов, а myisampack их почти не уменьшает. Совсем убирать индексы тоже не катит: довольно часто (до нескольких раз в день) делаются отчеты за достаточно давние периоды, и никуда от этого не деться ;(

JAO · Сообщение **JAO** » Ср дек 09, 2009 20:51

Вес индексов можно уменьшить, выровняв поле discount_date на границу минуты или часа. Существенно уменьшится их размер. Также если у вас в основном идут запросы по конкретному аккаунту, то рассортируйте их физически по account_id (ALTER TABLE ... ORDER BY account_id ASC) и добавьте индекс на это поле, вообще летать все будет.

Этого не стоит делать с рабочими таблицами, разве что индекс на account_id добавить. В новых версиях он там скорее всего есть. А вот с архивными можно так поиграться.

wingman

JAO писал(а):Вес индексов можно уменьшить, выровняв поле discount_date на границу минуты или часа. Существенно уменьшится их размер. Также если у вас в основном идут запросы по конкретному аккаунту, то рассортируйте их физически по account_id (ALTER TABLE ... ORDER BY account_id ASC) и добавьте индекс на это поле, вообще летать все будет.

Этого не стоит делать с рабочими таблицами, разве что индекс на account_id добавить. В новых версиях он там скорее всего есть. А вот с архивными можно так поиграться.

>> выровняв поле discount_date на границу минуты или часа
Но всё же врядли настолько же, как при "оптимизации" (ц) УТМ? =) Там реально на несколько порядков ужимались

Но всё равно большое спасибо; будем пробовать, благо стоит новая машинка под билинг и есть немного времени как раз для таких тестов и тюнинга =)

mikkey finn

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

JAO · Сообщение **JAO** » Чт дек 10, 2009 19:23

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

ppv · Сообщение **ppv** » Ср фев 10, 2010 04:41

Здравствуйте.

В новых версиях билинга убрали - "Дополнительно" - "Оптимизация".

- Раньше, выполнялась "Оптимизация" (или агрегирование) по старому месяцу, средствами UTM ("Дополнительно" - "Оптимизация");
- Затем этот месяц архивировался в отдельные таблицы:
discount_transactions_all_xxxxxxxxxx
discount_transactions_iptraffic_all_xxxxxxxxxx
скриптом (viewtopic.php?t=5853 - пост 5);
- Далее эти таблицы паковались myisampack'ом.

Основные таблицы (discount_transactions_all, discount_transactions_iptraffic_all) - отпимизировались через MySql.

Чем можно заменить этап "Дополнительно" - "Оптимизация" сейчас?

Было упоминание про утилиту: utm5_optimizer. Где брать и подойдет ли она?

Pulse · Сообщение **Pulse** » Ср фев 10, 2010 12:58

единственно правильный и актуальный вариант на 5.2.1-007 update 10
http://www.netup.ru/UTM5/articles/archive_table.php

andrew.rbe

Pulse писал(а):единственно правильный и актуальный вариант на 5.2.1-007 update 10
http://www.netup.ru/UTM5/articles/archive_table.php

Это правильно и понятно. До 6й сборки у нас скрипт "оптимизации" висел в кроне, выполнявшийся рано утром. Он агрегировал данные по часу за прошлую неделю. Ну хоть убейте но я не понимаю зачем пользователю 5ти минутная детализация трафика. Данные за прошлый месяц вообще можно агрегировать с интервалом в 4 часа.

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

ppv · Сообщение **ppv** » Чт фев 11, 2010 07:48

Про статью про архивирование - понятно. Оно не убралось и чуть видоизменилось.

Но чем можно заменить:

- "Оптимизация" (или агрегирование) по старому месяцу, средствами UTM ("Дополнительно" - "Оптимизация"),

которое было раньше и которое убрали. Оно перестало быть допустимым этапом?

У нас оно выполнялось перед архивированием и оно существенно уменьшало количество строк в таблицах (~ в 10 раз).
Может есть какие нить самописные скрипты выполняющие то же самое?

Ведь просто архивирование в другую таблицу, как рекомендуется (http://www.netup.ru/UTM5/articles/archi ... e.php#type) + упаковка через myiasmpack уменьшит размер данных только ~ на 25%.

ppv · Сообщение **ppv** » Пт фев 12, 2010 03:24

andrew.rbe писал(а): До 6й сборки у нас скрипт "оптимизации" висел в кроне, выполнявшийся рано утром.

Нашел utm5_optimizer в старой версии UTM. Речь идет о нем?
Есть ли его аналог на новую сборку UTM, может кто нить свой скрипт написал?

Подскажите, каким скриптом проводилась оптимизация (агрегирование), где его взять?

Можно ли его модифицировать под новую сборку UTM (если он на Perl, например)? Там же формат таблиц:
discount_transactions_all,
discount_transactions_iptraffic_all
- не сильно изменился.
Или это просто бинарник от UTM, который изменить нельзя?

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

ppv · Сообщение **ppv** » Пт фев 12, 2010 09:02

Еще момент.

В новой версии UTM таблицы:
discount_transactions_all,
discount_transactions_iptraffic_all
- отличаются от старой отсутствием некоторых полей (is_canceled, cancel_id и др., думаю они были убраны за ненадобностью).

Без этих полей утилита со старой сборки utm5_optimizer, по новой базе не работает. Вылетает на попытках обращения к несуществующим полям в базе.

Если эти поля добавить в базу (естественно с default значениями), утилита со старой сборки utm5_optimizer - выполняется нормально по новой базе.
После ее выполнения эти поля можно убрать.

Вопрос к тем кто глубоко знает UTM:
насколько безопасны такие манипуляции и можно ли доверять результатам работы старой сборки utm5_optimizer с новой базой, после таких манипуляций?

Как можно проверить корректность результатов оптимизации?