Есть ли какое-либо преимущество в чтении результатов запроса в блоках?
У меня есть запрос Entity Framework, который может возвращать ~ 10 000 строк. Это используется для заполнения карты точками.
Есть ли способ вернуть результаты в блоки так же быстро, как прочитать все сразу? Например, если я это сделаю:
.OrderBy(e => e.Id).Skip(offset).Take(1024)
И читать результаты по 1 КБ за раз, это примерно столько же времени, сколько читать все сразу? Или есть другой способ сделать это?
Обратите внимание: это не случай страничной сетки, где я могу сделать один вызов .Skip(x).Take(pageSize) и этого одного вызова достаточно, пока они не перейдут на другую страницу. В этом случае мне нужны все результаты.
Кроме того, в зависимости от используемой базы данных может быть полезно использовать Where(e => e.Id > maxIdFromPreviousBatch) вместо Skip(offset), но вам следует измерить это для вашего конкретного случая.
Используйте Keyset нумерацию страниц
@GuruStron Я давно узнал, что правильно оценить доступ к БД очень и очень сложно. Поэтому я спрашиваю в надежде, что люди, которые знают, как это делать правильно, определят, есть ли в большинстве случаев преимущество чтения блоками. Спасибо
@DavidThielen У меня недостаточно опыта, чтобы дать полный ответ (и вы даже не пометили используемую базу данных, что может иметь огромное значение), но если вы не ожидаете, что у вас будет более 10 тысяч записей - просто загрузите их в одном запросе, а затем посмотрите, есть ли в вашем приложении какие-либо проблемы. Помимо этого, не зная фактической настройки (используемая база данных, схема, размер данных, профили нагрузки, используемые транзакции), было бы очень сложно сказать.
Получение данных порциями всегда будет медленнее и требует больше ресурсов, чем получение всего сразу, но когда вы можете поддерживать свои запросы с помощью правильных индексов, разница достаточно мала. С другой стороны, пейджинг имеет то преимущество, что вы не потребляете все ресурсы сразу. Подумайте о том, чтобы покупать вещи в рассрочку, а не платить все сразу.
Этот вопрос имеет любопытный способ выглядеть как проблема X и Y: почему бы не рассказать о реальной проблеме, которую вы пытаетесь решить, вместо того, чтобы ходить вокруг нее, как кошка вокруг стакана молока. Если вы ищете «равную» производительность, зачем вам разбивать на более мелкие партии, особенно если в конечном итоге вы все равно хотите отобразить все результаты. С точки зрения необработанного SQL-сервера выполнение нескольких OFFSET вместо одного большого, вероятно, будет плохим, потому что запросы OFFSET трудны для индексов (вот почему была предложена пагинация набора ключей)
Ответы 1
Наибольшее влияние на производительность и использование ресурсов лучше всего обеспечить, если вы используете проекцию (Select()) для получения только тех значений, которые вам нужны, или используете запрос AsNoTracking(), если вам действительно нужно загружать объекты. И то и другое гарантирует, что EF не будет утруждать себя чтением или добавлением в кэш отслеживания.
Загрузка 10 тысяч строк идентификаторов, координат и, возможно, имени/метки, например, для заполнения области карты, не должна быть проблемой за один раз, если вам нужны все 10 тысяч элементов. Разбивка на страницы результатов больше связана с необходимостью отображать только страницу значений за раз. Если вам нужно 10 тысяч предметов, загрузка их по 1 тысяче за раз не сэкономит ни ресурсы, ни время. Обновление 10 тысяч элементов (если вы не можете выполнить пакетную операцию) может сэкономить ресурсы, загружая/отслеживая только подмножество за раз, при условии, что вы очищаете кеш отслеживания между страницами.
«И считывание результатов по 1 КБ за раз, это примерно столько же времени, сколько чтение всего сразу?» - Вы пробовали это измерить? В чем проблема прочитать все сразу?