Худший случай поведения для обновлений с использованием SQLite PRAGMA synchronous = OFF и journal_mode = MEMORY в iOS

Question

Используя опции synchronous = OFF и journal_mode = MEMORY, я могу уменьшить скорость обновления от 15 мс до 2 мс, что является важным улучшением производительности. Эти обновления происходят по одному, поэтому многие другие оптимизации (например, использование транзакций о связке из них) неприменимы.

Согласно документации SQLite, БД может «испортиться» в худшем случае, если есть отключение питания какого-либо типа. Однако не самое страшное, что может случиться, что данные будут потеряны или, возможно, часть транзакции, которая будет потеряна (что, я думаю, является формой коррупции). Действительно ли возможно, что произвольная коррупция может произойти с любым из этих вариантов? Если да, то почему?

Я не пользуюсь никакими транзакциями, поэтому частично написанные данные от транзакций не являются проблемой, и я могу обрабатывать потери данных один раз в голубой луне. Но если «коррупция» означает, что все данные в БД можно случайным образом изменить непредсказуемым образом, это будет серьезная причина не использовать эти параметры.

Означает ли кто-нибудь, что может быть в самом худшем случае для iOS?

Answer 1

Таблицы организованы как B-деревья с ключом rowid. Если некоторые записи теряются, а SQLite обновляет древовидную структуру, вся таблица может стать нечитаемой. (То же самое может произойти с индексами, но их можно просто отбросить и воссоздать.)

Данные организованы на страницах (обычно 1 КБ или 4 КБ). Если некоторое обновление страницы теряется, когда какое-то дерево реорганизуется, все данные на этих страницах (то есть некоторые случайные строки из таблицы с близлежащими значениями rowid) могут стать развращенными.

Если SQLite необходимо выделить новую страницу, и эта страница содержит правдоподобные данные (например, удаленные данные из одной таблицы), а запись этой страницы теряется, тогда у вас есть неверные данные в таблице, без способность обнаруживать его.