Прогресс-4GL - Какой самый быстрый способ суммировать таблицы?(Агрегатные функции: счет, сумма и т. Д.) - OpenEdge 10.2A

Question

Мы используем OpenEdge 10.2A и генерируем сводные отчеты, используя процедуры выполнения.Мы хотим сократить время создания отчетов.

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

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

Позвольте мне привести вам пример.Мы запускаем следующую процедуру:

DEFINE VARIABLE i AS INTEGER NO-UNDO.

ETIME(TRUE).
FOR EACH orderline FIELDS(ordernum) NO-LOCK:
    ASSIGN i = i + 1.
END.
MESSAGE "Count = " (i - 1) SKIP "Time = " ETIME VIEW-AS ALERT-BOX.

Результат:

Count= 330805
Time= 1891

Когда мы запускаем эквивалентный SQL-запрос:

SELECT count(ordernum) from pub.orderline

Время выполнения 141 .

Короче говоря, когда мы сравниваем два результата;Время sql более чем в 13 раз быстрее, чем время процедуры.

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

И мой вопрос состоит из двух частей:

1-) Можно ли получить агрегированные значения, используя процедуры какбыстро, как с помощью SQL-запросов?

2-) Есть ли какой-либо другой метод для получения суммированных значений быстрее, чем использование SQL-запросов в реальном времени?

Answer 1

Механизмы 4gl и SQL используют очень разные подходы к отправке данных клиенту.По умолчанию SQL намного быстрее.Чтобы получить аналогичную производительность от 4gl вам нужно настроить несколько параметров.Я предлагаю:

-Mm 32600                  # messages size, default 1024, max 32600
-prefetchDelay             # don't send the first record immediately, instead bundle it
-prefetchFactor 100        # try to fill message 100%
-prefetchNumRecs 10000     # if possible pack up to 10,000 records per message, default 16

До изменения 11.6 -Mm требуется ОБА и клиент, и сервер.Начиная с версии 11.6, только сервер должен быть изменен.

Для параметров -prefetch * необходим как минимум OpenEdge 10.2b06.

Хотя есть предупреждения (помимо прочего, объединения не принесут пользы)Эти параметры потенциально могут значительно улучшить производительность «запросов NO-LOCK».Простое:

FOR EACH table NO-LOCK:
  /* ... */
END.

может быть значительно улучшено с помощью указанных выше параметров.

Использование списка ПОЛЕЙ также может сильно помочь, поскольку сокращает объем данных и, следовательно,количество сообщений, которые нужно отправить.Поэтому, если вам нужны только некоторые поля, а не вся запись, вы можете написать что-то вроде:

FOR EACH customer FIELDS ( name balance ) NO-LOCK:

или:

FOR EACH customer EXCEPT ( photo ) NO-LOCK:

Вы уже используете FIELDS, и ваш пример запросапростой NO-LOCK, поэтому он должен существенно выиграть от предложенных настроек параметров.

Answer 2

Некоторые дополнительные предложения:

Ваш пример можно записать как

DEFINE VARIABLE i AS INTEGER NO-UNDO.

ETIME(TRUE).
select count(*) into i from orderline.
MESSAGE "Count = " (i - 1) SKIP "Time = " ETIME VIEW-AS ALERT-BOX.

, что должно привести к умеренному увеличению производительности.(Это не использует соединение ODBC. Вы можете использовать подмножество SQL в простых процедур 4GL. Это спорно, если это можно считать хорошим стилем.)

1007 * Там должно быть существенное повышение производительности путем доступа к базе данныхчерез разделяемую память вместо TCP / IP, если вы запускаете код на сервере (что вы делаете), а вы еще этого не делаете (что вы не указали).

Answer 3

Проблема, по-видимому, заключается в том, чтобы «сократить время создания отчетов».

Возникает ряд вопросов:

• Насколько медленны сейчас отчеты и какбыстро ты хочешь их?
• Увеличилось ли время выполнения по сравнению, например, с прошлым годом?
• Увеличился ли объем данных?
• Что-то изменилось?Серверы, хранилище, клиенты и т. Д.

Будет невозможно ответить на ваш вопрос без дополнительной информации.Доступ к данным из ABL, скорее всего, будет достаточно быстрым, если:

• В вашей базе данных установлены правильные индексы (индексы).
• У вас есть "хорошие" запросы.
• У вас достаточно системных ресурсов (память, процессор, дисковое пространство, скорость диска)
• У вас есть база данных, работающая с достойной настройкой (параметры -spin, -B и т. Д.).

Время, необходимое для простой команды, такой как FOR EACH <table> NO-LOCK: или SELECT COUNT(something) FROM <somewhere>, может не указывать, насколько быстро или медленно может выполняться ваш очень сложный запрос.