SPQuery работает с библиотеками ниже порога представления списка, но не выше.

Question

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

Эта веб-часть должна работать со списками, превышающими порог просмотра списка (в настоящее время установленный в 15 000 в рабочей версии), а также на ОЧЕНЬ больших сайтах (50 000–100 000+ документов).

Я следую рекомендациям MS Best для обработки больших списков: http://msdn.microsoft.com/en-us/library/ee557257.aspx

Использование SPquery (без определенного CAML), получение страниц из 2000 элементов и их анализ таким образом.Проблема в том, что веб-часть фактически вызывает тайм-аут на этих очень больших (более 50 тысяч) сайтах.Поэтому я пытаюсь быть немного умнее с моим CAML, извлекая только проверенные элементы:

spQuery.Query = "<Where><IsNotNull>
    <FieldRef Name=\"CheckoutUser\" LookupId=\"TRUE\"/>
</IsNotNull></Where>";
spQuery.RowLimit = 2000;
spQuery.ViewAttributes = "Scope=\"Recursive\"";

я использую CrossListQueryInfo запрос для опроса всей сети с помощью этого же caml, и он прекрасно работает, когда ни один список не превышает LVT.Если да, я перехватываю это исключение и повторяю попытку с «более медленным» SPQuery для каждой отдельной библиотеки.

Судя по всему, что я читаю, пока мой CAML возвращает меньше элементов, чем LVT, он должен работать.Но использование CAML выше приводит к ошибке The attempted operation is prohibited because it exceeds the list view threshold enforced by the administrator быть брошенным, когда SPList.GetItems(spQuery) называется.Поскольку я устанавливаю ограничение на количество строк в 2000, разве этого не должно произойти никогда?MS предлагает выполнить SPQuery вообще без определенного CAML - в основном захватывая все элементы из библиотеки на страницах по 2000.Поэтому я не могу понять, почему мой CAML дает сбой только в списках, превышающих порог просмотра.

Редактировать:После дальнейших исследований я попытаюсь использовать ContentIterator класс, отвечающий моим потребностям (http://msdn.microsoft.com/en-us/library/microsoft.office.server.utilities.contentiterator.aspx).Используя примеры из этого поста: http://extreme-sharepoint.com/2012/07/17/data-access-via-caml-queries/

Я все еще терплю неудачу в контентитераторе с той же ошибкой LVT.

Нужно ли индексировать поле CheckoutUser в каждом списке, к которому мы хотим выполнить этот запрос?

Обновление 2:Это сводится к тому, что поле CheckoutUser не индексируется и пытается выполнить запрос к нему.К сожалению, у нас нет возможности принудительно использовать этот индекс для каждой библиотеки в ферме.Я считаю, что на данный момент мой единственный вариант — реализовать какую-то схему подкачки на очень больших сайтах для пакетной обработки элементов.

Финальное обновление:В качестве решения я решил принудительно индексировать столбец CheckoutUser для библиотек.Это должно значительно улучшить общую производительность веб-части и обеспечить поддержку очень больших сайтов.Сразу после развертывания возникнет небольшая головная боль, так как нам нужно будет вручную установить индекс столбца в списках выше порогового значения представления списка, но в долгосрочной перспективе это будет лучше.

Answer 1

Мое понимание того, как работает порог представления списка, ограничено, однако я подозреваю, что причина сбоя вашего запроса CAML заключается в том, что он фильтрует неиндексированное поле, а RowLimit применяется «после».

Я думаю, что индексирование поля CheckoutUser решит вашу проблему, однако похоже, что у вас много сайтов.

Позвольте мне предложить альтернативный подход — пейджинг.Поскольку столбец идентификатора в каждом списке индексируется, реализуйте запрос CAML, в котором вы фильтруете ПЕРВЫМ (очень важно) столбец идентификатора менее, скажем, 2000, а затем — по полю CheckoutUser.Если этот запрос не возвращает желаемое количество результатов, увеличьте число с 2000 до 4000 и повторите.

Я сам не реализовал это решение, это всего лишь мысль.

Answer 2

Если вы запрашиваете большие списки, вам обязательно следует индексировать поля, по которым вы запрашиваете.Регулирование не происходит, поскольку индексированные поля хранятся в отдельной таблице базы данных.

Я думаю, что этот мой пост в блоге должен помочь:http://vrdmn.blogspot.in/2012/11/sharepoint-list-indexes-under-hood.html