Очень большой NSDictionary против Core Data против SQLite для поиска только для чтения на iPhone?

Question

Я работаю с приложением для iPhone, в котором я использую структуру DAWG для поиска анаграмм из определенного пользователем банка слов в режиме реального времени по мере того, как пользователь вводит текст.Эта часть работает хорошо.Поскольку слова идентифицированы, я хочу получить конкретную информацию о каждом слове, которое у меня есть на данный момент, в файле plist (с ключом по слову).Эта информация должна быть импортирована и доступна при запуске приложений.

При запуске я легко могу подготовить plist в объект NSDictionary с помощью initWithContentsOfFile, но при этом создается словарь с ~ 200 000 пар ключ / значение.Я предполагаю, что это не лучший подход, поскольку файлы plist в форматах txt, bin и xml имеют размер 2,8 МБ, 3,9 МБ и 7,5 МБ соответственно.

Должен ли я использовать Core Data или SQLite?Мой главный приоритет - производительность, так как я хотел бы искать информацию о десятках тысяч результатов в режиме реального времени, когда пользователь вводит их, если это возможно.

Спасибо

Answer 1

Вы можете ответить на вопросы о производительности, только попробовав подходы и профилирование (используйте Instruments.app).Тем не менее, существует много базовых данных, которые выполняют функции управления графами объектов, которые не соответствуют вашим потребностям.Если то, что вы действительно хотите, это хранилище значений ключей, то использование NSDictionary имеет смысл.Вы должны сравнить со стеком базовых данных, используя постоянное хранилище в памяти.Нет особых оснований обращаться к SQLite или к постоянному хранилищу Core Data на диске, если ваша цель - максимальная производительность чтения и вы можете поместить весь набор данных в память.

Answer 2

Sqlite может столкнуться с некоторыми узкими местами производительности, когда миллионы строк имеют индексы.Это может быть излишним, но в некоторых ситуациях одним из возможных способов взлома является просто разбить основной стол на 3/4 меньших стола.Например, в зависимости от вашего дизайна базы данных, вы можете разбить слова на несколько дБ.

ae.sqlite fl.sqlite mz.sqlite

тогда, когда вы выполняете поиск, вы можете динамически переключать оператор SELECT, чтобы выбрать соответствующий дБ.