Для MS SQL есть такая штука, как Fill Factor.
Есть ли подобное для sqlite?
У меня есть база данных, в которую только добавляются записи, удаления и обновления нет. Смотрю файл базы данных - в страницах очень много нулей, словно заполняет не полностью. Вообще, так и должно быть, когда fill factor не 100%. Для MS SQL я бы просто сделал Fill Factor = 100%. А для sql lite что-то подобную настройку не найду.
Для sqlite много есть про настройку vacuum. Но, как я понял, она про другое, про упаковку после удаления. А мне нужно, что бы просто листовые страницы B-дерева заполнялись полностью, как у ms sql с fill factor = 100. То есть, максимально плотное заполнение базы данных, когда идет просто построчная вставка.
Но, как я понял, она про другое, про упаковку после удаления. А мне нужно, что бы просто листовые страницы B-дерева заполнялись полностью, как у ms sql с fill factor = 100. То есть, максимально плотное заполнение базы данных, когда идет просто построчная вставка.
Ты напомнил анекдот когда женщина приша к урологу и жалуется что у мужа дескыть "одно яичко ниже другого. Непорядочек.."
Вобщем перфекционизм хорош в меру. Если ты читал об организации индексов на основе B+Tree (практически везде) во всех DBMS, то ты должен был читать о том что среднее заполнение листовых блоков обычно равно 75% от размера блока. Это связано с возможностью оперативно делать insert новых ключей и значений. Если ты, используя какие-то утилиты специально выровнял заполнение блоков - то индес становится медленным для будущих вставок. Каждая вставка продуцирует операцию split (тяжелая операция) и пока не посплитятся все листы - перформанс будет плохой.
Я не только читал про B+Tree, я их делал и точно знаю что мне нужно. В эту базу идет только запись, последовательными сериями ключей, причем время записи не критично. Нужно обеспечить максимальную компактность и скорость чтения.
Мне не кажется это перфекционизмом. Если для ощутимого улучшения можно просто изменить одну настройку, то почему бы это не сделать? На скорость выборки ее изменение тоже влияет в лучшую сторону в данной ситуации (из-за уменьшения объема читаемой информации).
kuza2000, вы занялись очень плохим и неподходящим для баз данных делом. А именно - экономией места. Т.к. вы неоднократно упоминаете "компактность" и "максимально плотное заполнение". Обычно базы данных - не про это. Если у вас - особый кейс - то возможно вам не нужен SQLite а стоит программировать свою собственную (key-value или document-oriented) систему где вы сможете хоть сжимать gzip-пом поля хоть делать column-oriented структуры. Короче я хочу сказать что база данных будет сопротивлятся вашему стремлению ее ужать. Такова ее природа. И многие механики баз данных очень не любят всякие "ужатия".
Но если вы хотите сильно - то попробуйте разбить таблицу на серии. Поскольку у вас загрузка идет сериями - то пускай каждая серия создает табличку. Вы ее уплотняете. И переводите как-бы в Read/Only. В этом случае результат вашего уплотнения хотя-бы сохряняется. В остальных случаях он будет потерян для индексов точно.
mayton2019, сжатие уже сделано, причем выбирается один из трех поддерживаемых алгоритмов сжатия :)
Все работает достаточно хорошо, и я точно не буду писать свою БД)) Хотя до последней версии был мой специализированный движок, но я все же решил отказаться от него, так как sqlite идет в составе стандартной библиотеке питона и достаточно неплохо работает с blobs. Хотя все-же чуть медленне собственного, процентов на 10.
Все, что я хочу - это поиграть fill factor, если он есть у sqlite, о чем, собственно и вопрос. Есть мнение, что fill factor = 100 в данном кейсе использования позволит уменьшить размер базы и немного ускорить ее работу.
kuza2000, в твоей активности в топике нету никакого Acceptance Criteria. Тоесть ты не задаешся конкретной целью а просто играешся. В этом случае мы цели никогда не достигаем а просто проводим время в беседе.
Я не специалист именно по SQlite но я тебе хочу сказать что не стоит завязываться на какую-то стандартную библиотеку питона. И то что ты написал по стилю разработки (jupiter/pandas) это не мобильное и не встраиваемое приложение а вполне себе серверное. Значит нечего там экономить на спичках. А SQLite он потому и лайт потому-что изначально делался для in-memory и мобил. А сегодня по нелепой случайности в него грузят терабайты. И всем пофиг. Один я удивляюсь.
Я не специалист именно по SQlite но я тебе хочу сказать что не стоит завязываться на какую-то стандартную библиотеку питона.
У меня другое мнение. Если по всем критериям подходит стандартная библиотека - зачем использовать что-то еще? Тем более, чем меньше зависимостей, тем лучше.
А SQLite он потому и лайт потому-что изначально делался для in-memory и мобил.
Там вполне себе нормальный серьезный движок, на B-деревьях со всеми вытекающими. С терабайтами данных он управляется так же легко, как и, к примеру, MS SQL.
Там другие ограничения - в частности, по уровням изоляции транзакций и гранулярности блокировок. То есть, он не предназначен для многопользовательской работы. А объем данных ему не важен. Собственно, по всем параметрам это то, что мне нужно.
А еще я поковырял двоичную структуру листьев кластеризованной таблицы, и мне понравилось, как там сделана упаковка данных :)
У вас есть хотя бы один реальный аргумент против sql lite?
kuza2000, я не против SQLite. Мне просто надо вникнуть в суть вашей задачи и понять какой класс запросов там бегает. И только после этого я смогу что-то точнее сказать. А пока... берите SQLite.
Да кто-ж вам запретит-то хоссподи...
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
