ax2009 Оптимизация производительности на больших объемах данных

[jeky]

Помогите советом:
может есть некое резюме на форуме или у кого-то лично
1. шаги оптимизации кода, в т.ч. при больших объёмах данных
т.е. какие есть рекомендации в принципе по оптимизации производительности, что-то вроде:
- убрать транзакцию внутрь цикла,
- не использовать внутри цикла find, кот вытаскивает все поля таблицы, а использовать select с упоминанием только необходимых полей
- для группы (не группировки) данных использовать цикл с сортировкой и анализировать изменение значения поля, которое используется в условии селекта, например из предыдущего пункта, т.е. делать очередной select только при возникновении ситуации со сменой значения, используемого в условии
2. советы по оптимизации технической: обрезание данных (какая периодичность)
разбиение заказов, строк накладных, слияние строк накладных/заказов с одинаковой номенклатурой.

[S.Kuskov]

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

Отсутствие подходящих индексов замедляет чтение данных, злоупотребление индексами замедляет редактирование данных.

Встречал ситуации когда выгодным было даже временное создание нужного индекса. Т.е. время на индексацию таблицы + само выполнение запроса с использованием подходящего индекса было много меньше чем время выполнение запроса без такого индекса. Оставлять такой индекс на постоянной основе или нет это уже второй вопрос, касающийся не скорости чтения а скорости записи данных.

[Maximin]

Цитата:

Сообщение от jeky

...
2. советы по оптимизации технической: обрезание данных (какая периодичность)
разбиение заказов, строк накладных, слияние строк накладных/заказов с одинаковой номенклатурой.

Вот это должно называться "регламентом по обращению с историческими данными". И продумываться еще при старте проекта внедрения, в соответствии с реальными бизнес-требованиями. Чтобы через год-полтора после начала эксплутации не ходить по граблям и долгим согласованиям между отделами и департаментами.
Заодно, при каждом архитектурном решении надо задавать вопрос: "А что будет через год?". Видел не одно такое внедрение, когда через полгода работы оказывалось, что размер базы под несколько терабайт, все тормозит, как удав по стекловате, а тётушки из какого-нить отдела кричат: "А нам все данные за все года нада!"
А там строки розничных чеков, непонятно, вообще, нафига они в Аксапте - лежат в одной табле. И логирование каких-нить проводок в ГК включено. И до кучи, кластерный индекс по натуральному ключу с разной номерной серией в разных компаниях из какого-нить самописного казначейства имеется.