обновление cxDBgrid

есть ПО в котором на главной форме в cxDBgrid отображается список карточек и периодически в 5 секунд происходит REFRESH QUERY для актуализации записей на экране.
софт подвисает в момент REFRESH QUERY. записей в базе 500 тыс (и растет), данные отображаться ан экране должны за текущие сутки
вопрос как избежать подвисания в момент REFRESH?
1. сделать таблицу ARH (где хранить все записи) и DAY (где хранить только текущего дня). При создании записи сохранять ее в DAY и писать по триггеру в ARH
2. ограничить кол-во отбираемых столбцов при REFRESH(ибо есть те которые для отображения карточек на экране не нужны)
3. сделать REFRESH (c запросом ко всей таблице и отбирая только за текущий день) в потоке
4. добавить индекс по дате (для ускорения REFRESH)
5 делать CLOSE/OPEN QUERY (но думаю это мало повлияет на скорость)


заранее благодарен за любой совет.

0

Не могу себе представить пользователя, которому вываливается 500 тыс. записей. Что он с ними будет делать??
Если клиент выводит по 500 тыс записей, то в этом месте надо реализовывать фильтр или какой-то другой способ уменьшения количества записей (например, выводим последние сто).
Поэтому для начала, я бы советовал пересмотреть требования клиентской части. Зачем там 500 тыс записей??!

Серверная часть.... Нужно начать с плана запроса. Что показывает план?? В чем узкое место?? Не применяется индекс? Дохлое физическое хранилище? Не делается вакуум?? В общем без анализа ситуации можно гадать и выдумывать сколько угодно.

По вашему плану.
1. По правильному - это называется партиционирование данных (и никаких триггеров). Но будут некоторые затраты на создание / удаление / содержание партиций. Что выберите Вы, решать вам. Я бы сразу делал по правильному. Если, конечно, вообще нужны партиции, что должно быть продиктовано поступающим объемом данных во времени и их необходимым анализом для построения отчетов.
2. Это правильно. По хорошему можно сделать представление, чтобы держать готовый текст запроса для выборки нужных данных. Тогда на клиенте можно делать выборку из этого представления. В случае изменения схемы данных (таблиц) представление поможет сохранить интерфейс взаимодействия клиента и сервера.
3. no comments
4. если сейчас в таблице хранятся все даты и нет индекса по дате, то вообще не знаю, как все работает. проверка эффективности использования индексов - одно из первых, на что обычно смотрят в планах запросов при выборке конкретных данных из таблиц.
5. не знаю, что стоит за open/close query у вас в клиенте. если курсоры то да, желательно чтобы курсоры бесцельно не висели открытыми. вычерпали его и закрыть.

как-то так для начала.

0

спасибо за отчет
500 тыс записей это всего, а за сутки попадает гдето 3-4 тыс...
зачем столько отображать? клиент хочет группировать по разным критериям данные и смотреть их глазками.
навеяло мысль......
в памяти клиента создать таблицу структуры с которой работаем и в ней:
1. при запуске софта таблица заполняется данными за сутки
2. в процессе работы удаляются из этой таблицы данные за больше суток
3. таймером в 5 секунд считывать таблицу изменений и берем записи больше штампа времени (который храним в памяти) и производить действия с таблицей в памяти
4 штамп времени сохраняем последний который считали
таблица изменений...
id
id_z ID записи в которой были изменения
type_op тип операции (удаление, новая запись, редактирование)
timestamp штамп времени

получится вся таблица рабочая за сутки будет жить в памяти и работать с ней будем в памяти
это выход из положения?

выяснено... в существующей модели запрос быстро отрабатывается... просто долго заново весь грид прорисовывается

0

Сообщение от nik1971 это выход из положения?

да, в каком-то смысле это вариант.
только я не очень понимаю зачем для этого делать еще одну таблицу.
1. запросили суточный образ при запуске (первый тяжелый запрос, который возвращет на клиент много данных).
2. из полученных данных организовали очередь
3. по таймеру делаем два действия
3.1. удаляем из головы столько записей, сколько ушло в прошлые сутки
3.2. в хвост добавляем из базы записи, которые по дате больше даты хвоста (ожидается очень небольшой объем данных).

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

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

0