Каковы рабочие характеристики sqlite с очень большими файлами базы данных? [закрытый]

Поэтому я провел несколько тестов с sqlite для очень больших файлов и пришел к некоторым выводам (по крайней мере, для моего конкретного приложения).

Тесты включают в себя один файл sqlite с одной или несколькими таблицами. Каждая таблица имела около 8 столбцов, почти все целые числа и 4 индекса.

Идея заключалась в том, чтобы вставить достаточно данных, пока размер файлов sqlite не достигнет 50 ГБ.

Single Table

Я пытался вставить несколько строк в файл sqlite. только с одним столом. Когда размер файла составлял около 7 ГБ (извините, я не могу точно сказать, сколько строк) вставки занимали слишком много времени. Я подсчитал, что мой тест для вставки всех моих данных займет около 24 часов, но он не завершился даже после 48 часов.

Это приводит меня к выводу, что у одной очень большой таблицы sqlite будут проблемы с вставками, и, возможно, другие операции.

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

Несколько таблиц

Затем я попытался разбить данные по времени на несколько столы, один стол в день. Данные для исходной таблицы 1 были разделены на ~ 700 таблиц.

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

Вакуумные проблемы

Как указано i_like_caffeine, команда VACUUM является проблема, тем больше файл sqlite. Чем больше будет выполнено вставок / удалений, тем хуже будет фрагментация файла на диске, поэтому цель состоит в том, чтобы периодически VACUUM оптимизировать файл и восстанавливать файловое пространство.

Однако, как указано в документации , полная копия базы данных сделана для создания вакуума, что занимает очень много времени. Таким образом, чем меньше база данных, тем быстрее завершится эта операция.

Выводы

Для моего конкретного приложения я, вероятно, буду разбивать данные по нескольким файлам БД, по одному в день, чтобы получить максимум от вакуума. производительность и скорость вставки / удаления.

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

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

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