Варианты высокопроизводительного SQLite

Question

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

Я хотел бы использовать SQLite для хранения всех этих данных, но, поскольку это файловая система с флеш-памятью, операции записи (INSERTS & UPDATES) выполняются слишком медленно.Я попытался установить синхронный = выкл, и это, безусловно, улучшает производительность, но я нервничаю из-за повреждения базы данных.

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

Я также думал об использовании базы данных SQLite в памяти в качестве основной базы данных и периодически синхронизировал ее сфайловая система, как описано в Синхронизация базы данных sqlite из памяти в файл

Есть ли другие варианты, которые я должен рассмотреть?

Answer 1

При получении пакета данных обязательно выполняйте серии вставок и обновлений в рамках одной транзакции.

sqlite3_exec(handle, "BEGIN TRANSACTION", NULL, NULL, NULL);

for ( ... ) {
    // Do your inserts/updates
}

sqlite3_exec(handle, "END TRANSACTION", NULL, NULL, NULL);

По умолчанию SQLite помещает каждую вставку / обновление в свою собственную транзакцию.Это может сделать SQLite довольно медленным, если базовая файловая система работает медленно.Объявляя свои собственные транзакции, вы можете значительно сократить объем фактической записи, выполняемой в файловой системе, что существенно повышает производительность SQLite.

Answer 2

Я не знаю, насколько велики ваши наборы данных, но если они не слишком велики, то режим WAL может помочь. Вы можете поэкспериментировать с "PRAGMA синхронный = 1" : эта настройка не синхронизируется после каждой транзакции, но время от времени. По умолчанию: при записи 2 МБ новых данных. Документы SQLite говорят, что вы можете потерять несколько последних транзакций, но БД не будет повреждена.