Очистка/фрагментация SQLite и снижение производительности

Допустим, я периодически вставляю данные в базу данных SQLite, затем очищаю первые 50% данных, но не очищаю их.

У меня теперь есть что-то вроде обнуленных страниц для первых 50% файла? Если я добавлю еще одну порцию данных, заполню ли я эти обнуленные страницы?

В руководстве упоминается фрагментация данных:

Частые вставки, обновления и удаления могут привести к фрагментации файла базы данных, когда данные для одной таблицы или индекса разбросаны по всему файлу базы данных.

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

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

Есть ли заметный прирост производительности для данных на строго смежных страницах? Могу ли я ожидать «ужасной» производительности от базы данных с большим количеством фрагментированных данных?


person Calpau    schedule 08.11.2014    source источник


Ответы (1)


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

Фрагментированные страницы могут привести к снижению производительности, только если

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

Есть только один способ узнать, так ли это для вашего приложения: измерить его.

person CL.    schedule 08.11.2014
comment
Да, но не так, как вы предполагали. - person CL.; 27.01.2015
comment
Комментарий был бы уместен, чтобы запросить некоторые пояснения к ответу, но порядок записи кэша страниц не имеет ничего общего с чтением фрагментированных страниц с диска. Если у вас есть вопрос, задайте вопрос. - person CL.; 28.01.2015