Производительность ClientDataset TBlobfields

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

Открытие точно тех же данных, но преобразование BLOB-полей как Varchar, занимает 1 секунду!

Единственная разница в том, что TQuery (или TsqlQuery) имеет TStringfields вместо TBlobfields. но данные те же. Вся таблица, сохраненная в файл, занимает около 3 МБ. Я получаю те же результаты, используя TsqlQuery или TQuery для подключения к базе данных (firebird).

База данных находится на сервере под управлением Firebird 2.1. Разница исчезла при запуске базы данных на клиенте (обе <1 секунда), поэтому я полагаю, что это должно быть что-то с сетевым трафиком ...

Это становится еще более странным: не имеет значения, действительно ли Clientdataset заполнен BLOB-полями. Итак, если clientdataset имеет только одно постоянное поле (целое число), производительность такая же ...

Эта ошибка (?) - большая проблема для меня ... Надеюсь, кто-нибудь сможет это объяснить ...


performance blob delphi tclientdataset
person Dirk Janssens    schedule 17.03.2012    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Прочтите этот пост на сайте часто задаваемых вопросов по Firebird

В двух словах говорится:

  1. Если вы запрашиваете таблицы с большими двоичными объектами без фактического чтения данных большого двоичного объекта (просто выполняя SELECT *), рекомендуется удалить их из списка столбцов, поскольку для больших двоичных объектов требуется два обращения к серверу (одно для получения идентификатора большого двоичного объекта, а другое - для получения данных. ). В качестве альтернативы вы можете преобразовать BLOB в varchar, чтобы быстрее получить данные:

выберите ..., приведите (my_blob_field как varchar (2000))

Надеюсь это поможет.

person John Easley    schedule 17.03.2012
comment
Спасибо. может быть, в этом и проблема, но падение производительности с 1 секунды до 3 минут за эту 1 дополнительную поездку? Это вероятно? - person Dirk Janssens; 18.03.2012
comment
Я уверен, что это еще не все. Когда я прочитал ваш пост, мой первый вопрос был: с какой стати вы хотите извлекать сразу 3000 капель? Поскольку большие двоичные объекты могут иметь разные размеры и данные, вы никогда не узнаете, что вы получите, если не приведете ... что именно вы храните в полях больших двоичных объектов? - person John Easley; 18.03.2012
comment
Использование хранит форматированный текст. Он не был предназначен для получения такого количества данных, но некоторые из моих клиентов недавно импортировали некоторые внешние файлы с ›10.000 записями, что привело к зависанию программы на 4 минуты. Я просто пытаюсь заставить его работать для них, и, поскольку кастинг делает это за меня, я надеюсь, что он также работает с форматированным текстом в сетке .... - person Dirk Janssens; 19.03.2012

arrow_upward
0
arrow_downward

Итак, взаимодействия примерно такие:

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

Когда вы включаете Blob, обычно BlobID возвращается в блоке, а затем, когда вы действительно запрашиваете в своем приложении доступ к данным, он отключается и выполняет другой конкретный запрос для этого Blob из этой строки. Это синхронный двусторонний переход = задержка. 10К записей = не менее 10К туда и обратно. HIH JAC

person Jason Chapman    schedule 07.02.2017