Ошибка при открытии реестра бизнес-объекта "с большим" объемом данных

Вопросы и ответы Проблемы при работе с платформой
, , ,
1

В бизнес-объекте храниться более 70 млн записей.

image

При открытии реестра выдает сообщение с ошибкой вида

An error occurred while executing the command definition. See the inner exception for details.

В детализации ошибки

System.Data.Entity.Core.EntityCommandExecutionException: An error occurred while executing the command definition. See the inner exception for details. —> Npgsql.NpgsqlException: Exception while reading from stream —> System.IO.IOException: Unable to read data from the transport connection: Operation on non-blocking socket would block. —> System.Net.Sockets.SocketException: Operation on non-blocking socket would block at System.Net.Sockets.Socket.Receive (System.Byte buffer, System.Int32 offset, System.Int32 size, System.Net.Sockets.SocketFlags socketFlags) [0x00016] in :0 at System.Net.Sockets.NetworkStream.Read (System.Byte buffer, System.Int32 offset, System.Int32 size) [0x00065] in :0 — End of inner exception stack trace — at System.Net.Sockets.NetworkStream.Read (System.Byte buffer, System.Int32 offset, System.Int32 size) [0x000ac] in :0 at Npgsql.NpgsqlReadBuffer+<>c__DisplayClass34_0.g__EnsureLong|0 () [0x00252] in <3d1c653e222242cb971134634b2a23a5>:0 — End of inner exception stack trace — at Npgsql.NpgsqlReadBuffer+<>c__DisplayClass34_0.g__EnsureLong|0 () [0x00371] in <3d1c653e222242cb971134634b2a23a5>:0 at Npgsql.NpgsqlConnector+<>c__DisplayClass160_0.g__ReadMessageLong|0 (Npgsql.DataRowLoadingMode dataRowLoadingMode2, System.Boolean readingNotifications2, System.Boolean isReadingPrependedMessage) [0x00452] in <3d1c653e222242cb971134634b2a23a5>:0 at Npgsql.NpgsqlDataReader.NextResult (System.Boolean async, System.Boolean isConsuming) [0x008c6] in <3d1c653e222242cb971134634b2a23a5>:0 at Npgsql.NpgsqlDataReader.NextResult () [0x0001f] in <3d1c653e222242cb971134634b2a23a5>:0 at Npgsql.NpgsqlCommand.ExecuteReaderAsync (System.Data.CommandBehavior behavior, System.Boolean async, System.Threading.CancellationToken cancellationToken) [0x0031a] in <3d1c653e222242cb971134634b2a23a5>:0

Ограничения по времени, которые регулируются в конфигах или bi в целом не может открывать реестры с таким объемом записей ?

2

БО запрос рдбмс? или хранимый? так как ссылки на объект видно поля, то делает много джойнов. по-этому отчасти может не успевать отработать до таймаута.
если рдбмс то он получает все 70млн сразу и потом только выдаёт порцию клиенту. то есть еще дольше и меньше шансов получить ответ.

3

БО с типом хранилища Реляционная СУБД

4

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

5

bi в целом не может открывать реестры с таким объемом записей

Гипотетически может, но не стоит рассчитывать на то, что без тюнинга будет хорошая производительность для такого количества строк. Здесь нужно исследовать каждый случай индивидуально.

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

6

ссылки на объект видно поля, то делает много джойнов

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

В новом просмотровщике данных (который готовится к выпуску в экспериментальном виде) для ссылочных полей используется обычный join, который более хорошо оптимизируется движком СУБД.

7

для работы с таким количеством строк рекомендуется использовать новый просмотрщик. Он оптимизирован читать больше объемы, за что лишен возможности записывать данные.
image