Улучшить процесс зеркалирования базы данных сервера в клиентскую базу данных через JSON?

Ответ 1

Я решил написать свой собственный ответ, обобщая методы и советы, которые я нашел полезными для своей ситуации. Спасибо всем, кто отправил свои ответы.

I. Транспорт

• "Один JSON". Это идея, которую я хочу попробовать. Спасибо @mundi.

• Идея архивирования JSON перед отправкой его клиенту, будь то один пакет JSON или 30 отдельных "одна таблица - один пакет".

II. Настройка отношений основных данных

Я опишу процесс импорта импорта JSON- > CoreData с использованием воображаемой операции большого импорта, как если бы он выполнялся одним способом (я не уверен, будет это так или нет - возможно, я разделил его на логические куски).

Предположим, что в моем воображаемом приложении есть 15 емких таблиц, где "емкий" означает "нельзя держать в памяти сразу, следует импортировать с помощью партий" и 15 не-емких таблиц, каждый из которых имеет 500 записей для пример:

Вместительная:

• города (15k +)
• клиенты (30k +)
• пользователи (15k +)
• события (5k +)
• действия (2k +) ...

Маленький:

• client_types (20 -)
• visit_types (10 -)
• позиции (10-) ...

Представьте себе, что у меня уже есть пакеты JSON, загруженные и проанализированные в составные переменные NSArray/NSDictionary: у меня есть городаJSON, клиентыJSON, usersJSON,...

1. Сначала работайте с маленькими таблицами

Мой псевдо-метод начинается с импорта крошечных таблиц. Возьмем таблицу client_types: итерацию через clientTypesJSON и создание объектов ClientType (подклассы NSManagedObject). Более того, я собираю результирующие объекты в словаре с этими объектами как свои значения и "идентификаторы" (внешние ключи) этих объектов в качестве ключей.

Вот псевдокод:

NSMutableDictionary *clientTypesIdsAndClientTypes = [NSMutableDictionary dictionary];
for (NSDictionary *clientTypeJSON in clientsJSON) {
    ClientType *clientType = [NSEntityDescription insertNewObjectForEntityForName:@"ClientType" inManagedObjectContext:managedObjectContext];

    // fill the properties of clientType from clientTypeJSON

    // Write prepared clientType to a cache
    [clientTypesIdsAndClientTypes setValue:clientType forKey:clientType.id];
}

// Persist all clientTypes to a store.
NSArray *clientTypes = [clientTypesIdsAndClientTypes allValues];
[managedObjectContext obtainPermanentIDsForObjects:clientTypes error:...];

// Un-fault (unload from RAM) all the records in the cache - because we don't need them in memory anymore.
for (ClientType *clientType in clientTypes) {
    [managedObjectContext refreshObject:clientType mergeChanges:NO];
}

В результате у нас есть куча словарей небольших таблиц, каждая из которых имеет соответствующий набор объектов и их идентификаторы. Мы будем использовать их позже без повторной проверки, потому что они маленькие, а их значения (NSManagedObjects) теперь являются ошибками.

2. Используйте словарь кеша объектов из небольших таблиц, полученных на шаге 1, чтобы установить с ними отношения

Рассмотрим комплексную таблицу clients: мы имеем clientsJSON, и нам нужно настроить отношение ClientType для каждой записи клиента, это легко, потому что у нас есть кеш с clientTypes и их идентификаторы:

for (NSDictionary *clientJSON in clientsJSON) {
    Client *client = [NSEntityDescription insertNewObjectForEntityForName:@"Client" inManagedObjectContext:managedObjectContext];

    // Setting up SQLite field 
    client.client_type_id = clientJSON[@"client_type_id"];

    // Setting up Core Data relationship beetween client and clientType
    client.clientType = clientTypesIdsAndClientTypes[client.client_type_id];
}

// Save and persist

3. Работа с большими таблицами - партии

Рассмотрим большой clientsJSON, имеющий в нем 30k + клиентов. Мы не перебираем все clientsJSON, а разбиваем на куски соответствующего размера (500 записей), так что [managedObjectContext save:...] вызывается каждые 500 записей. Также важно обернуть операцию с каждой записью 500 записей в @autoreleasepool block - см. Сокращение издержек памяти в руководстве по производительности основных данных

Будьте осторожны - шаг 4 описывает операцию, применяемую к пакету 500 записей, а не целому числу clientsJSON!

4. Работа с большими таблицами - настройка отношений с большими таблицами

Рассмотрим следующий метод, который мы будем использовать в один момент:

@implementation NSManagedObject (Extensions)
+ (NSDictionary *)dictionaryOfExistingObjectsByIds:(NSArray *)objectIds inManagedObjectContext:(NSManagedObjectContext *)managedObjectContext {
    NSDictionary *dictionaryOfObjects;

    NSArray *sortedObjectIds = [objectIds sortedArrayUsingSelector:@selector(compare:)];

    NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] initWithEntityName:NSStringFromClass(self)];

    fetchRequest.predicate = [NSPredicate predicateWithFormat:@"(id IN %@)", sortedObjectIds];
    fetchRequest.sortDescriptors = @[[[NSSortDescriptor alloc] initWithKey: @"id" ascending:YES]];

    fetchRequest.includesPropertyValues = NO;
    fetchRequest.returnsObjectsAsFaults = YES;

    NSError *error;
    NSArray *fetchResult = [managedObjectContext executeFetchRequest:fetchRequest error:&error];

    dictionaryOfObjects = [NSMutableDictionary dictionaryWithObjects:fetchResult forKeys:sortedObjectIds];

    return dictionaryOfObjects;
}
@end

Рассмотрим пакет clientsJSON, содержащий партию (500) записей Client, которые нам нужно сохранить. Также нам нужно установить связь между этими клиентами и их агентствами (Agency, внешний ключ agency_id).

NSMutableArray *agenciesIds = [NSMutableArray array];
NSMutableArray *clients = [NSMutableArray array];

for (NSDictionary *clientJSON in clientsJSON) {
    Client *client = [NSEntityDescription insertNewObjectForEntityForName:@"Client" inManagedObjectContext:managedObjectContext];

    // fill client fields...

    // Also collect agencies ids
    if ([agenciesIds containsObject:client.agency_id] == NO) {
        [agenciesIds addObject:client.agency_id];
    }        

    [clients addObject:client];
}

NSDictionary *agenciesIdsAndAgenciesObjects = [Agency dictionaryOfExistingObjectsByIds:agenciesIds];

// Setting up Core Data relationship beetween Client and Agency
for (Client *client in clients) {
    client.agency = agenciesIdsAndAgenciesObjects[client.agency_id];
}

// Persist all Clients to a store.
[managedObjectContext obtainPermanentIDsForObjects:clients error:...];

// Un-fault all the records in the cache - because we don't need them in memory anymore.
for (Client *client in clients) {
    [managedObjectContext refreshObject:client mergeChanges:NO];
}

Большая часть того, что я здесь использую, описана в этих руководствах Apple: Производительность основных данных, Эффективный импорт данных. Итак, сводка для шагов 1-4 следующая:

• Поверните объекты в неисправности, когда они сохраняются, и поэтому их значения свойств становятся ненужными, поскольку операция импорта идет дальше.

• Создайте словари с объектами как значениями и их ids как ключи, поэтому эти словари могут служить в качестве поисковых таблиц при построении отношений между этими объектами и другими объектами.

• Используйте @autoreleasepool при повторении через большое количество записей.

• Используйте метод, похожий на dictionaryOfExistingObjectsByIds, или метод, который Том ссылается в своем ответе, Эффективно импортировать данные - a метод, который имеет SQL IN предикат за ним, чтобы значительно сократить количество выборок. Прочтите ответ Tom и обратитесь к соответствующему руководству Apple, чтобы лучше понять эту технику.

Хорошее чтение по этой теме

ошибка objc.io # 4: импорт больших наборов данных

Ответ 2

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

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

Вместо этого я обнаружил, что загрузка всего JSON за один раз была намного быстрее. Я не знаю, сколько данных у вас есть, но я тестировал s > 100 000 записей и 40 МБ + JSON-строку, это работает очень быстро, поэтому узким местом являются только вставки Core Data. С пулом @autorelease это даже выполнило приемлемо на iPad первого поколения.

Держитесь подальше от SQLite API - вам потребуется больше года (при высокой производительности), чтобы реплицировать оптимизацию производительности, которую вы получаете из коробки с помощью Core Data.

Ответ 3

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

Я бы рекомендовал делать ваши выборки партиями, с размером партии, соответствующим размеру партии для обработки новых объектов. Например, при создании новых записей Agency выполните следующие действия:

• Убедитесь, что текущая партия Agency сортируется по city_id. (Я объясню, почему позже).

• Получите идентификатор City для каждого Agency в пакете. В зависимости от того, как структурирован ваш JSON, это, вероятно, однострочный (так как valueForKey работает с массивами):

  NSArray *cityIDs = [myAgencyBatch valueForKey:@"city_id"];
  

• Получите все экземпляры City для текущего прохода в одной выборке, используя идентификаторы, найденные вами на предыдущем шаге. Сортировка результатов city_id. Что-то вроде:

  NSFetchRequest *request = [NSFetchRequest fetchRequestWithEntityName:@"City"];
  NSPredicate *predicate = [NSPredicate predicateWithFormat:@"city_id in %@", cityIDs];
  [request setPredicate:predicate];
  [request setSortDescriptors:@[ [NSSortDescriptor sortDescriptorWithKey:@"city_id" ascending:YES] ]];
  NSArray *cities = [context executeFetchRequest:request error:nil];
  

Теперь, у вас есть один массив Agency и еще один из City, отсортированный по city_id. Сопоставьте их, чтобы настроить отношения (проверьте city_id, если все не соответствует). Сохраните изменения и перейдите к следующей партии.

Это значительно сократит количество загрузок, которые вам нужно выполнить, что должно ускорить процесс. Подробнее об этом методе см. В Реализация эффективного поиска или создания в документах Apple.

Еще одна вещь, которая может помочь, - "разогреть" внутренний кэш Core Data с помощью объектов, которые вам нужны, прежде чем вы их начнете. Это позволит сэкономить время позже, потому что получение значений свойств не потребует поездки в хранилище данных. Для этого вы бы сделали что-то вроде:

NSFetchRequest *request = [NSFetchRequest fetchRequestWithEntityName:@"City"];
// no predicate, get everything
[request setResultType:NSManagedObjectIDResultType];
NSArray *notUsed = [context executeFetchRequest:request error:nil];

.., а затем просто забудьте о результатах. Это поверхностно бесполезно, но изменит внутреннее состояние Core Data для более быстрого доступа к экземплярам City позже.

Теперь, что касается ваших других вопросов,

• Использование SQLite напрямую вместо Core Data не может быть ужасным выбором для вашей ситуации. Выгода будет заключаться в том, что вам не нужно будет устанавливать отношения, поскольку вы можете использовать поля использования, такие как city_id, как внешние ключи. Итак, быстрый импорт. Недостатком, конечно же, является то, что вам придется выполнять свою собственную работу по преобразованию объектов модели в/из записей SQL и, возможно, переписать довольно много существующего кода, который предполагает Core Data (например, каждый раз, когда вы будете следовать отношениям, которые вы сейчас нужно искать записи по этому внешнему ключу). Это изменение может устранить проблемы с производительностью импорта, но побочные эффекты могут быть значительными.

• JSON, как правило, очень хороший формат, если вы передаете данные как текст. Если вы можете подготовить хранилище основных данных на сервере и , если, вы должны использовать этот файл как есть вместо того, чтобы пытаться объединить его в существующее хранилище данных, тогда почти наверняка ускорит ситуацию. Ваш процесс импорта будет запускаться один раз на сервере, а затем никогда больше. Но это большие "если", особенно второй. Если вы доберетесь до того, где вам нужно объединить новое хранилище данных сервера с существующими данными, вы вернетесь туда, где вы сейчас находитесь.

Ответ 4

У вас есть контроль над сервером? Я спрашиваю, потому что это звучит так, как из следующего абзаца:

"В первый раз выполняется полная синхронизация (первое время запуска приложения). Выполняйте выборку всех данных базы данных, например, в одном архивированном файле (что-то вроде дампа базы данных), а затем каким-то образом импортируете его в целом Земля CoreData".

Если отправка дампа возможна, почему бы не отправить файл Core Data непосредственно? Основные данные (по умолчанию) поддерживаются базой данных SQLite - почему бы не создать эту базу данных на сервере, не закрепить ее и не отправить через провод?

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

Ответ 5

• Для каждой строки в таблице должен быть столбец timestamp. Если его нет, вы должны добавить его.
• В первый раз и каждый раз, когда вы извлекаете дамп базы данных, вы сохраняете последнюю дату и время обновления.
• В следующий раз вы укажете базе данных, чтобы вернуть только те записи, которые были изменены или обновлены со времени предыдущей операции загрузки. Для удаления исчезнувших записей также должен быть флаг "deleted".
• Тогда вам нужно только обновить некоторые соответствующие записи, экономя время на всех фронтах.

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

• Загрузите файлы JSON вручную.
• Поместите их в свой проект.
• Где-то в конфигурации проекта или файлах заголовка обратите внимание на дату и время загрузки.
• В первом запуске найдите и загрузите указанные файлы, затем продолжайте, как вы их обновляете.
• Если есть сомнения, обратитесь к руководству.

Пример:

NSString *filePath = [[NSBundle mainBundle] pathForResource:@"cities" 
                                            ofType:@"json"];
NSData *citiesData = [NSData dataWithContentsOfFile:filePath];
// I assume that you're loading an array
NSArray *citiesSeed = [NSJSONSerialization JSONObjectWithData:citiesData 
                       options:NSJSONReadingMutableContainers error:nil];

Ответ 6

Здесь у вас есть мои рекомендации:

• Используйте magicalrecord. Это оболочка CoreData, которая сэкономит вам много шаблонов кода, плюс она поставляется с очень интересными функциями.
• Загрузите все JSON по одному запросу, как и другие. Если вы можете вставить первый JSON-документ в приложение, вы можете сохранить время загрузки и начать заполнять базу данных сразу при первом открытии приложения. Кроме того, с magicalrecord довольно легко выполнить эту операцию сохранения в отдельном потоке, а затем автоматически синхронизировать все контексты. Это может улучшить оперативность вашего приложения.
• Кажется, что вам нужно реорганизовать этот уродливый метод, как только вы решите первую проблему импорта. Опять же, я бы предложил использовать magicalrecord для легкого создания этих объектов.

Ответ 7

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

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

• Измерьте, сколько времени потребуется, чтобы вставить эти записи в текущее состояние.
• Пропустите настройку отношений между этими объектами в целом, а затем измерьте производительность вставки.
• Создайте простую базу данных SQLite и оцените ее производительность. Это должно дать вам очень хорошую базовую оценку того, сколько времени потребуется для выполнения фактических вставок SQL, а также даст вам хорошее представление о накладных расходах Core Data.

Несколько вещей, которые вы можете попробовать с места в карьер для ускорения вставок:

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

Чтобы получить более полное представление о том, что действительно происходит под капотом, включите Отладку основных данных SQL и просмотрите выполняемые SQL-запросы. В идеале вы хотите увидеть много INSERT и несколько UPDATE. Но если вы встретите слишком много SELECT и/или UPDATE, то это знак того, что вы слишком много читаете или обновляете объекты.

Используйте инструмент профилировщика Core-Data, чтобы получить более качественный обзор того, что происходит с Core Data.