2015-06-29 5 views
0

Я поддерживаю и разрабатываю существующее приложение Objective-C iOS, которое содержит контактную информацию около 100 тыс. Человек. Теперь мы хотели бы представить стратегию сегментации, которая ограничит видимость этих 100 тыс. Записей. Стратегия сегментации должна быть гибкой и будет управляться такими вещами, как текущий зарегистрированный пользовательский уровень (& подразделение компании) и некоторые фильтры тегов (покажите всем, у кого есть тег «Горячий проспект» или «Большой спайдер» 'или' Likes Boats ').Производительность данных ядра iOS с большими наборами данных

Итак, я созерцаю пометку всех контактов 100k по нескольким тегам. Это позволит мне запускать сложные поиски, где я хочу, чтобы кто-то называл «Джон» ярлыком «Горячий проспект», который «Любит лодки». Etc и т. Д. Пользователи смогут сами определять и добавлять теги.

Мой вопрос в том, что с контактами 100k и, скажем, 10 тегов на контакт, у меня будут записи тегов 1M в моем главном графике объектов данных. Теги будут проиндексированы. Я собираюсь поразить проблемы с производительностью? Являются ли основные данные на iPad mini под управлением iOS8, чтобы бороться с этим, или я могу начать разработку/построение стратегии сегментации, не заботясь о производительности (предполагая, что я правильно ее кодирую)? Является ли моя стратегия тегов надежной, причем каждый контакт имеет отношение 1-много к нескольким тегам?

+0

Извините, если это педантично, но связь с тегами должна быть много-много, а не 1-много. Мало того, что каждый контакт имеет много тегов, но каждый тег будет применяться ко многим контактам. Количество тегов будет намного меньше, чем 1M (я предполагаю!), Но количество строк в таблице соединений может быть в 1M. Хотя ничто из этого не влияет на ваш вопрос. – pbasdf

+0

Ты не педантичен, ты просто прав! Это действительная точка :) – Journeyman

ответ

0

Я думаю, что трудно оценить поведение во время работы в самом начале. Это скорее опытная догадка, чем инжиниринг. И Дональд Кнут был прав.

Однако поведение во время выполнения для такого набора данных будет в значительной степени зависеть от того, может ли CD напрямую сопоставить ваши предикаты с SQL. В этом случае реальная работа выполняется внутри SQLite и загружается меньше данных. Вероятно, это сработает. Если компакт-диск не может сопоставить предикат с SQL, данные должны быть загружены, и это замедлит работу вашего приложения.

Итак, что бы я сделал: построил минимальную схему тестирования для вашего прецедента и попытался выполнить предикаты, которые вы хотите выполнить.

  • Будет ли эта работа или CD отвергать эти предикаты?
  • Если он принимает предикаты, включите подробный режим работы с компакт-диском и посмотрите на команды SQL (в сложном режиме CD выдает команды) и проверьте, являются ли они разумными.
Смежные вопросы