Есть ли fill factor для sqlite3?

Question

[kuza2000]

Для MS SQL есть такая штука, как Fill Factor.
Есть ли подобное для sqlite?

У меня есть база данных, в которую только добавляются записи, удаления и обновления нет. Смотрю файл базы данных - в страницах очень много нулей, словно заполняет не полностью. Вообще, так и должно быть, когда fill factor не 100%. Для MS SQL я бы просто сделал Fill Factor = 100%. А для sql lite что-то подобную настройку не найду.

Для sqlite много есть про настройку vacuum. Но, как я понял, она про другое, про упаковку после удаления. А мне нужно, что бы просто листовые страницы B-дерева заполнялись полностью, как у ms sql с fill factor = 100. То есть, максимально плотное заполнение базы данных, когда идет просто построчная вставка.

Comments

[Константин Цветков]

Как "специалист": коэффициент заполнения не имеет отношения к данным. Это для индексов: статья.

[kuza2000]

Константин Цветков, ну так данные же в кластерном индексе и лежат.

[Константин Цветков]

Файловое строение SQLite, Внутренние таблицы SQLite.

[kuza2000]

Спасибо, полезная информация. Но ответа на вопрос я там не нашел.

Answer 1

[kuza2000]

Разобрался. Fill Factor мне не нужен. Проблема в другом. Новый вопрос тут: Создаю таблицу в sql lite в обычном варианте, и в ...

По Fill Factor и почему не нужен.
В MS SQL по умолчанию Fill Factor = 100%. И используется он только при перестройке индексов и кластеризованных таблиц.

При заполнении он применяться не может, это невозможно. Страница всегда заполняется до конца, потом делится. Делить страницу раньше бессмысленно. Это не выгодно, никогда.

В SQL LITE, судя по всему, такой настройки нет. Скорее всего тоже 100% заполняет страницы при перестройке, но я не проверял.

Answer 2

[mayton2019]

Но, как я понял, она про другое, про упаковку после удаления. А мне нужно, что бы просто листовые страницы B-дерева заполнялись полностью, как у ms sql с fill factor = 100. То есть, максимально плотное заполнение базы данных, когда идет просто построчная вставка.

Ты напомнил анекдот когда женщина приша к урологу и жалуется что у мужа дескыть "одно яичко ниже другого. Непорядочек.."

Вобщем перфекционизм хорош в меру. Если ты читал об организации индексов на основе B+Tree (практически везде) во всех DBMS, то ты должен был читать о том что среднее заполнение листовых блоков обычно равно 75% от размера блока. Это связано с возможностью оперативно делать insert новых ключей и значений. Если ты, используя какие-то утилиты специально выровнял заполнение блоков - то индес становится медленным для будущих вставок. Каждая вставка продуцирует операцию split (тяжелая операция) и пока не посплитятся все листы - перформанс будет плохой.

Comments

[kuza2000]

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

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

[mayton2019]

kuza2000, вы занялись очень плохим и неподходящим для баз данных делом. А именно - экономией места. Т.к. вы неоднократно упоминаете "компактность" и "максимально плотное заполнение". Обычно базы данных - не про это. Если у вас - особый кейс - то возможно вам не нужен SQLite а стоит программировать свою собственную (key-value или document-oriented) систему где вы сможете хоть сжимать gzip-пом поля хоть делать column-oriented структуры. Короче я хочу сказать что база данных будет сопротивлятся вашему стремлению ее ужать. Такова ее природа. И многие механики баз данных очень не любят всякие "ужатия".

Но если вы хотите сильно - то попробуйте разбить таблицу на серии. Поскольку у вас загрузка идет сериями - то пускай каждая серия создает табличку. Вы ее уплотняете. И переводите как-бы в Read/Only. В этом случае результат вашего уплотнения хотя-бы сохряняется. В остальных случаях он будет потерян для индексов точно.

[kuza2000]

mayton2019, сжатие уже сделано, причем выбирается один из трех поддерживаемых алгоритмов сжатия :)

Все работает достаточно хорошо, и я точно не буду писать свою БД)) Хотя до последней версии был мой специализированный движок, но я все же решил отказаться от него, так как sqlite идет в составе стандартной библиотеке питона и достаточно неплохо работает с blobs. Хотя все-же чуть медленне собственного, процентов на 10.

Все, что я хочу - это поиграть fill factor, если он есть у sqlite, о чем, собственно и вопрос. Есть мнение, что fill factor = 100 в данном кейсе использования позволит уменьшить размер базы и немного ускорить ее работу.

Вот проект, если интересно https://github.com/hal9000cc/live_trading_indicators
Вот про прошлый движок статья: https://habr.com/ru/post/706074/

[mayton2019]

kuza2000, в твоей активности в топике нету никакого Acceptance Criteria. Тоесть ты не задаешся конкретной целью а просто играешся. В этом случае мы цели никогда не достигаем а просто проводим время в беседе.

Я не специалист именно по SQlite но я тебе хочу сказать что не стоит завязываться на какую-то стандартную библиотеку питона. И то что ты написал по стилю разработки (jupiter/pandas) это не мобильное и не встраиваемое приложение а вполне себе серверное. Значит нечего там экономить на спичках. А SQLite он потому и лайт потому-что изначально делался для in-memory и мобил. А сегодня по нелепой случайности в него грузят терабайты. И всем пофиг. Один я удивляюсь.

[kuza2000]

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

У меня другое мнение. Если по всем критериям подходит стандартная библиотека - зачем использовать что-то еще? Тем более, чем меньше зависимостей, тем лучше.

А SQLite он потому и лайт потому-что изначально делался для in-memory и мобил.

Там вполне себе нормальный серьезный движок, на B-деревьях со всеми вытекающими. С терабайтами данных он управляется так же легко, как и, к примеру, MS SQL.
Там другие ограничения - в частности, по уровням изоляции транзакций и гранулярности блокировок. То есть, он не предназначен для многопользовательской работы. А объем данных ему не важен. Собственно, по всем параметрам это то, что мне нужно.
А еще я поковырял двоичную структуру листьев кластеризованной таблицы, и мне понравилось, как там сделана упаковка данных :)

У вас есть хотя бы один реальный аргумент против sql lite?

[mayton2019]

kuza2000, я не против SQLite. Мне просто надо вникнуть в суть вашей задачи и понять какой класс запросов там бегает. И только после этого я смогу что-то точнее сказать. А пока... берите SQLite.

Да кто-ж вам запретит-то хоссподи...