Как оптимизировать запрос Core Data для полнотекстового поиска

Ответ 1

Я сделал обходное решение. Я думаю, что это похоже на этот пост. Я добавил исходный код амальгамы в проект Core Data, а затем создал полнотекстовый класс поиска, который не был подклассом управляемого объекта. В классе FTS я #import "sqlite3.h" (исходный файл) вместо структуры sqlite. Класс FTS сохраняет другой файл .sqlite, чем постоянное хранилище Core Data.

Когда я импортирую свои данные, объект Core Data хранит rowid связанного объекта FTS как целочисленный атрибут. У меня есть статический набор данных, поэтому я не беспокоюсь о ссылочной целостности, но код для поддержания целостности должен быть тривиальным.

Для выполнения FTS я MATCH запрашивает класс FTS, возвращая набор rowids. В моем классе управляемых объектов я запрашиваю соответствующие объекты с помощью [NSPredicate predicateWithFormat:@"rowid IN %@", rowids]. Я избегаю общения с такими отношениями "многие-ко-многим".

Улучшение производительности является драматическим. Мой набор данных - 142287 строк, включающий в себя 194 МБ (основные данные) и 92 МБ (FTS с удалением стоп-слов). В зависимости от частоты поискового запроса мои поисковые запросы длились от нескольких секунд до 0,1 секунды для нечастых терминов (< 100 ударов) и 0,2 секунды для частых терминов (более 2000 просмотров).

Я уверен, что с моим подходом есть множество проблем (раздувание кода, возможные конфликты пространства имен, потеря некоторых функций Core Data), но, похоже, он работает.

Ответ 2

Чтобы следить за этим вопросом, я обнаружил, что запрос - медленная работа с использованием Core Data. Я поцарапал себе голову на это много часов.

Как и в примере SQL в моем вопросе, есть два объекта: textTable и слова, в которых слова содержат каждое слово, оно индексируется, и между textTable и словами существует многозначное отношение. Я заполнил базу данных всего за 4000 слов и 360 объектов textTable. Предположим, что отношение textTable к объекту слов называется поисковым словом, тогда я могу использовать предикат для объекта textTable, который выглядит как

predicate = [NSPredicate predicateWithFormat:@"ANY searchWords.word BEGINSWITH %@", query];

(Я могу добавить конъюнкции этого предиката для нескольких терминов запроса.)

В iPhone этот запрос занимает несколько секунд. Ответ на мой ручной код SQL с использованием большего набора тестов был мгновенным.

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

Естественно, что тогда полный текст будет игнорировать исходный атрибут, как в примере выше, но отфильтрованный запрос ограничит поиск определенным значением источника. Это, казалось бы, простое изменение требует SUBQUERY. Например, это не работает:

ANY searchWords.word BEGINSWITH "foo" AND ANY searchWords.source = 3

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

SUBQUERY(searchWords, $x, $x.word BEGINSWITH "foo" AND $x.source = 3)[email protected] > 0

Я обнаружил, что эти подзапросы, возможно, не удивительно, медленнее, чем предикаты, использующие "ЛЮБОЙ".

В этот момент мне очень любопытно, как программисты Cocoa эффективно используют Core Data для полнотекстового поиска, потому что меня обескураживают как скорость оценки предикатов, так и выразительность NSPredicates. Я подбежал к стене.

Ответ 3

Погрузитесь.

Вот один из способов:

• Поместите свои записи в постоянное хранилище основных данных.
• Используйте NSFetchedResultsController для управления набором результатов на ваших объектах Word (эквивалент Core Data с таблицей слов SQL)
• Используйте UISearchDisplayController для применения NSPredicate в результирующем наборе в режиме реального времени

Как только у вас есть результирующий набор через NSFetchedResultsController, довольно просто применить предикат. По моему опыту, он тоже будет отзывчивым. Например:

if ([self.searchBar.text length]) {
    _predicate = [NSPredicate predicateWithFormat:[NSString stringWithFormat:@"(word contains[cd] '%@')", self.searchBar.text]];
    [self.fetchedResultsController.fetchRequest setPredicate:_predicate];
}

NSError *error;
if (![self.fetchedResultsController performFetch:&error]) {
    // handle error...
}
NSLog(@"filtered results: %@", [self.fetchedResultsController fetchedObjects]);

будет фильтровать результирующий набор [self.fetchedResultsController fetchedObjects] на лету, делая поиск без учета регистра на Word.

Ответ 4

После борьбы с этой же проблемой я столкнулся с серией сообщений, в которых у автора была такая же проблема, и придумал это решение, Он сообщает об улучшении от 6-7 секундного поиска до 0,13-0,05 секунды.

Его набор данных для FTS составлял 79 документов (размер файла 175k, 3600 дискретных токенов, 10000 ссылок). Я еще не пробовал его решения, но думал, что отправлю как можно скорее. См. Также часть 2 его сообщений для его документации по проблеме и Часть 1 для его документации по набору данных.