Почему моя база данных Firebird настолько велика для объема данных, которые она хранит?

Question

В последнее время я занимаюсь программированием баз данных и заметил кое-что немного тревожное.

Я взял двоичный плоский файл, сохраненный в проприетарном, несжатом формате, который содержит несколько разных типов записей, построил схемы для представления одних и тех же записей и загрузил данные в базу данных Firebird. Оригинальный плоский файл был около 7 МБ. База данных более 70 МБ!

Я могу понять, что есть некоторые издержки для описания самих таблиц, и у меня есть несколько минимальных индексов (в основном, PK) и FK на разных таблицах, и все это займет некоторое пространство, но фактор 10 кажется немного смешным. У кого-нибудь есть идеи относительно того, что может так сильно раздуть эту базу данных, и как я могу уменьшить размер?

Answer 1

Gstat - это инструмент для проверки размеров таблиц и т. Д., Возможно, он даст вам несколько советов о том, что использует пространство.

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

Answer 2

Заполнение страниц Firebird в некоторых случаях не заполнено. например Страница БД может содержать 70% данных и 30% свободного места для ускорения будущих обновлений записей, удаляет без перехода на новую страницу БД.

CONFIGREVISIONSTORE (213)
    Primary pointer page: 572, Index root page: 573
    Data pages: 2122, data page slots: 2122, average fill: 82%
    Fill distribution:
         0 - 19% = 1
        20 - 39% = 0
        40 - 59% = 0
        60 - 79% = 79
        80 - 99% = 2042

То же самое для индексов.

Вы можете увидеть, насколько реально размер БД, когда вы выполняете резервное копирование и восстановление с опцией

-USE_ALL_SPACE

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

как "Петр Григорьевич" скажем - база данных гораздо больше, чем обычный файл и оптимизирована для ускорения работы.

и, как сказал "Harriv", вы можете получить подробную информацию о файле базы данных с помощью gstat

использовать команду как gstat - вот подробности о его выводе

Answer 3

Из FAQ Firebird :

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

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

Если для вас критично место на диске, вы можете получить его обратно, выполнив резервное копирование, а затем восстановив его.Поскольку вы делаете резервное копирование для восстановления сразу, разумно использовать переключатель «запретить сборку мусора» или «не использовать сборку мусора» (-G в isql), что сделает резервное копирование ОЧЕНЬ БЫСТРОМ.Сборка мусора используется для очистки вашей базы данных, и поскольку это задача обслуживания, она часто выполняется вместе с резервным копированием (так как резервное копирование должно пройти через всю базу данных в любом случае).Однако вы скоро выбросите этот файл базы данных, и нет необходимости его очищать.