2015-11-02 3 views
3

Я использовал SQLCipher для шифрования базы данных sqlite в своем приложении. Все в порядке, но мое приложение работает медленно во время извлечения базы данных. Я изменил PRAGMA kdf_iter до 4000, и он все еще медленный. Перед шифрованием у меня нет никаких проблем.Как оптимизировать производительность SQLcipher?

-(NSError *) openDatabase { 

    NSError *error = nil; 
    NSString *databasePath = [self getDatabasePath]; 

    const char *dbpath = [databasePath UTF8String]; 
    int result = sqlite3_open_v2 (dbpath, &db , SQLITE_OPEN_READWRITE , NULL); 
    if (result == SQLITE_OK) { 

     sqlite3_exec(db, [@"PRAGMA kdf_iter = '4000';" UTF8String], NULL, NULL, NULL); 
     sqlite3_exec(db, [@"PRAGMA key = 'password'" UTF8String], NULL, NULL, NULL); 

     NSLog(@"Password is correct , Database is Activated"); 
     sqlite3_exec(db, [@"PRAGMA cipher = 'aes-256-cfb';" UTF8String], NULL, NULL, NULL); 

    } 
    else { 
     NSLog(@"Incorrect password!"); 
    } 
    if (result != SQLITE_OK) { 
     const char *errorMsg = sqlite3_errmsg(db); 
     NSString *errorStr = [NSString stringWithFormat:@"The database could not be opened: %@",[NSString stringWithCString:errorMsg encoding:NSUTF8StringEncoding]]; 
     error = [self createDBErrorWithDescription:errorStr andCode:kDBFailAtOpen]; 

    } 

    return error; 
} 

ответ

0

Почему вы используете режим CFB (aes-256-cfb) вместо CBC?

Я не верю, что аппаратное шифрование поддерживает AES CFB, поэтому он, вероятно, будет использовать шифрование программного обеспечения, которое может быть в 500 раз меньше.

Из документов:

SQLCipher использует AES-256-CBC в качестве шифра и режима работы по умолчанию. Можно изменить это, хотя в целом не рекомендуется

+0

Здравствуйте, zaph, я изменил режим только для проверки. Ты прав! но он все еще медленный, даже без режима CFB. – iSibDev

+0

Является ли доступ db медленным без шифрования? Является ли db большим? – zaph

+0

нет. db отлично поработал без какого-либо отставания до шифрования. Таблица моего db содержит строку около 2000. – iSibDev

2

Наконец я мог бы оптимизировать производительность SQLCipher с Ник Паркер полезным руководством.

Как он сказал:

Есть несколько очень важных принципов для обеспечения оптимальной производительности SQLCipher:

  • Не повторяйте открывать и закрывать соединения, так как ключевой вывод очень дорого, по дизайну. Частое открытие/закрытие соединения с базой данных (например, для каждого запроса) является очень распространенной причиной проблем с производительностью, которые обычно можно легко разрешить с использованием одноточечного соединения с базой данных.
  • Используйте транзакции для переноса операций вставки/обновления/удаления. Если не выполняется в области транзакции, каждая операция будет происходить внутри собственной транзакции, которая замедляет работу на несколько порядков
  • Убедитесь, что ваши данные нормализованы (т. Е. С использованием передового опыта для разделения данных на несколько таблиц для устранения избыточности). Ненужное дублирование данных приводит к раздуванию базы данных, что означает, что для работы с SQLCipher требуется больше страниц
  • Убедитесь, что индексируются все столбцы, которые используются для поиска или условия объединения. Если вы этого не сделаете, SQLCipher нужно будет выполнить полное сканирование базы данных по большому количеству страниц
  • Вакуумных периодически для обеспечения база данных компактны, если вы делаете большие удалений, обновление и т.д.

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

Если вы не уверены в том, какие запросы плохо работают, SQLCipher включает в себя прагму под названием cipher_profile, которая позволяет выполнять профилирование запросов и их соответствующее время выполнения в миллисекундах.

Это является Reference Link

Большое спасибо Ник Паркер.

Также этот blog был очень полезен для меня.

Смежные вопросы