Размер файлов btrieve

Clarion, Clarion 7

Модератор: Дед Пахом

Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
Аватара пользователя
finsoftrz
Ветеран
Сообщения: 1162
Зарегистрирован: 06 Ноябрь 2014, 12:48

Размер файлов btrieve

Сообщение finsoftrz » 12 Январь 2019, 21:35

Сравниваю размер файлов одной и той же базы на tps и btrieve. Некоторые файлы близки по размеру, но некоторые у btrieve в 2-3 раза больше. Например, одна большая таблица tps занимает 1.2 ГБ, на btrieve она разбивается на 3 физических файла (2х2 ГБ и небольшой довесок). Btrieve версии 10. Хотел поинтересоваться у коллег, кто работает с btrieve, это нормальное положение вещей или как-то настраивается. И если настраивается, есть ли смысл это делать. Сейчас все настройки btrieve по умолчанию.
Рязань решает.

Аватара пользователя
Игорь Столяров
Ветеран движения
Сообщения: 3981
Зарегистрирован: 07 Июль 2005, 9:19
Откуда: г. Ростов-на-Дону

Размер файлов btrieve

Сообщение Игорь Столяров » 12 Январь 2019, 22:54

1. Btrieve (точнее Microkernel Database Engine) захватывает место на диске листами (Pages);
2. При удалении записей MKDE просто отмечает их как удалённые и потом использует это место (также как и TPS).

Поэтому размер MKDE файла в общем случае - это информация ни о чём. Размер листов можно выставить, а для
физического удаления записей, перестроения индексов и упаковки есть штатная утилита REBUILD. Прогоните через
неё Ваш файл (всё по умолчанию) и посмотрите, что будет с размером …

Что касается максимального размера MKDE файла - то он зависит от версии самого Pervasive.SQL и его варианта.
На сайте разработчика есть сравнительная табличка - посмотрите. Если не ошибаюсь, то для текущей версии
Actian Data Base 13 это значение 64 GByte …

Здесь ещё нужно добавить, что сама структура файлов MKDE тоже имеет несколько версий … совместимость есть,
но при переходе на новую версию PSQL всё же рекомендуется конвертировать и сами MKDE файлы, что были доступны
возможности новых структур файлов. Для этого есть несколько штатных утилит.

Btrieve версии 10 не существует (после 6.15 он был снят с производства и потом возродился сразу в 12-ой версии).
Если речь о P.SQL v.10 - то это что-то совсем ископаемое …
На FTP форума есть P.SQL v.13 и Btrieve v.12 - не отказывайте себе в удовольствии работать с современными версиями.

Если дайджестом - то как-то оно так … :)
«V» значит Вендетта !

Аватара пользователя
finsoftrz
Ветеран
Сообщения: 1162
Зарегистрирован: 06 Ноябрь 2014, 12:48

Размер файлов btrieve

Сообщение finsoftrz » 12 Январь 2019, 23:35

Да, разумеется, имелась ввиду PSQL 10. Насчет более поздних версий (если не считать 11), там сменился владелец, и есть некоторые сомнения по поводу целесообразности.

Файлы сравниваются сразу после конвертации. То есть никаких операций, кроме append и build над таблицами не производились. После перестроения ключей размер файла несколько уменьшается, но не принципиально. У меня подозрение, что не поджимаются конечные пробелы в строковых полях, так как расхождения заметны на таких таблицах. Хотя вроде как btrieve должен выполнять компрессию, как и tps. Я и думаю, что это зависит от настроек. Но, если так стоит по умолчанию, возможно, оптимизировано для скорости работы.

Максимальный размер таблицы у формата 9.5 - 256 Гб. На win32 автоматически разбивает на несколько файлов, работает, как с одной таблицей.
Рязань решает.

Аватара пользователя
finsoftrz
Ветеран
Сообщения: 1162
Зарегистрирован: 06 Ноябрь 2014, 12:48

Размер файлов btrieve

Сообщение finsoftrz » 12 Январь 2019, 23:38

Игорь, я так понимаю, у Вас нет рабочих баз tps/btrieve однотипной структуры со сравнимым количеством записей?
Рязань решает.

Аватара пользователя
Игорь Столяров
Ветеран движения
Сообщения: 3981
Зарегистрирован: 07 Июль 2005, 9:19
Откуда: г. Ростов-на-Дону

Размер файлов btrieve

Сообщение Игорь Столяров » 13 Январь 2019, 0:13

finsoftrz писал(а):
12 Январь 2019, 23:38
Игорь, я так понимаю, у Вас нет рабочих баз tps/btrieve однотипной структуры
На основании какой фразы в моём сообщении Вы сделали такой вывод ? Просто интересна логика мышления. ;)

У меня есть несколько программ, которые отличаются только Dictionary - TPS / MKDE / DBF. Т.е. можно собрать
одну и ту же программу с различным форматом БД и практически идентичной структурой данных (если не брать в
расчёт списки со специфическими типами данных типа BLOB, DECIMAL и т.д.) и конечно можно перегрузить между ними данные.
Т.е. можно получить списки не со сравнимым кол-вом записей, а просто одинаковые, но в разных форматах.
Есть среди списков и такие, с которыми работаете Вы, т.е. только с базовыми типами данных: STRING, REAL, LONG, BYTE.

А чем нам это поможет ? Если Вы хотите спросить "какая БД больше", то ответ: "всегда больше MKDE". Причины я назвал,
подробно всё описано в документации структуры MKDE. Или Вы познаёте мир посредством эксперимента как Майкл Фарадей ? :)

Вот здесь подробно, с формулами - приведён расчёт размера файла MKDE в зависимости от настроек PAGES и версии:
http://docs.actian.com/psql/PSQLv13/ind ... %23ww19543
finsoftrz писал(а):
12 Январь 2019, 23:35
Максимальный размер таблицы у формата 9.5 - 256 Гб.
Не совсем. Есть ещё зависимость от выбора размера листа файла MKDE (и как следствие кол-ва записей на этом листе):
http://docs.actian.com/psql/PSQLv13/ind ... gdb.htm%23
Последний раз редактировалось Игорь Столяров 13 Январь 2019, 7:49, всего редактировалось 1 раз.
«V» значит Вендетта !

Аватара пользователя
RaFaeL
Ветеран
Сообщения: 851
Зарегистрирован: 24 Март 2009, 17:59
Откуда: НН
Контактная информация:

Размер файлов btrieve

Сообщение RaFaeL » 13 Январь 2019, 1:17

finsoftrz писал(а):
12 Январь 2019, 23:35
У меня подозрение, что не поджимаются конечные пробелы в строковых полях, так как расхождения заметны на таких таблицах.
Зачем в базе хранить STRING, есть же CSTRING без всяких конечных пробелов

Developer
Ветеран
Сообщения: 507
Зарегистрирован: 26 Март 2012, 16:18

Размер файлов btrieve

Сообщение Developer » 13 Январь 2019, 2:07

finsoftrz писал(а):
12 Январь 2019, 23:35
Максимальный размер таблицы у формата 9.5 - 256 Гб. На win32 автоматически разбивает на несколько файлов, работает, как с одной таблицей.

Разбиение по желанию возможно отключить :D
Limit 2GB.JPG
С Уважением, Developer

Аватара пользователя
Игорь Столяров
Ветеран движения
Сообщения: 3981
Зарегистрирован: 07 Июль 2005, 9:19
Откуда: г. Ростов-на-Дону

Размер файлов btrieve

Сообщение Игорь Столяров » 13 Январь 2019, 7:45

Developer писал(а):
13 Январь 2019, 2:07
Разбиение по желанию возможно отключить
Проверить не начнём. Но есть большое подозрение, что при размещении БД P.SQL на раздел диска с FAT32 -
эта опция включается автоматически и её нельзя отключить … т.к. там ограничение на размер файла в 4 GByte.
«V» значит Вендетта !

Аватара пользователя
finsoftrz
Ветеран
Сообщения: 1162
Зарегистрирован: 06 Ноябрь 2014, 12:48

Размер файлов btrieve

Сообщение finsoftrz » 13 Январь 2019, 11:23

Игорь Столяров писал(а):
13 Январь 2019, 0:13
finsoftrz писал(а):
12 Январь 2019, 23:38
Игорь, я так понимаю, у Вас нет рабочих баз tps/btrieve однотипной структуры
На основании какой фразы в моём сообщении Вы сделали такой вывод ? Просто интересна логика мышления. ;)
С логикой мышления вроде все очевидно. Потуги сфокусировать внимание на содержимом вопроса.

В принципе, более менее понятно. Спасибо за ссылки. Как и предполагал, есть два варианта хранения данных - с фиксированной длиной записи и с переменной длиной. Во втором случае получаем аналогично tps. С поправкой на возможное изменение размера страницы в btrieve.
В общем, меня сейчас больше интересуют не технические подробности, а общая идеология работы с btrieve применительно к своему проекту. Поэтому решил пообщаться на предмет личного опыта использования, wiki я параллельно тоже читаю... :-)
Рязань решает.

Аватара пользователя
finsoftrz
Ветеран
Сообщения: 1162
Зарегистрирован: 06 Ноябрь 2014, 12:48

Размер файлов btrieve

Сообщение finsoftrz » 13 Январь 2019, 11:27

RaFaeL писал(а):
13 Январь 2019, 1:17
finsoftrz писал(а):
12 Январь 2019, 23:35
У меня подозрение, что не поджимаются конечные пробелы в строковых полях, так как расхождения заметны на таких таблицах.
Зачем в базе хранить STRING, есть же CSTRING без всяких конечных пробелов
CSTRING не родной кларионовский формат. Он привнесен для взаимодействия с внешними библиотеками и sql серверами. STRING в tps хранится без конечных пробелов сам по себе (плюс еще алгоритм упаковки). В btrieve, как выяснили, зависит от настройки - могут быть записи с фиксированной длиной и с переменной длиной.
Рязань решает.

Аватара пользователя
finsoftrz
Ветеран
Сообщения: 1162
Зарегистрирован: 06 Ноябрь 2014, 12:48

Размер файлов btrieve

Сообщение finsoftrz » 13 Январь 2019, 11:35

Игорь Столяров писал(а):
13 Январь 2019, 7:45
Developer писал(а):
13 Январь 2019, 2:07
Разбиение по желанию возможно отключить
Проверить не начнём. Но есть большое подозрение, что при размещении БД P.SQL на раздел диска с FAT32 -
эта опция включается автоматически и её нельзя отключить … т.к. там ограничение на размер файла в 4 GByte.
Сейчас уж fat32 мало где используется. Вопрос, что практичнее, в одном файле или в нескольких? Когда-то я читал, что в postgreSQL деление на файлы преподносится как оптимизация. Если там посмотреть физическое хранение базы данных, то это куча подкаталогов и файлов с цифровыми именами. А в ms sql, sybase, firebird, насколько я знаю, никто не парится - все в одном большом файле держат.
Рязань решает.

Аватара пользователя
Игорь Столяров
Ветеран движения
Сообщения: 3981
Зарегистрирован: 07 Июль 2005, 9:19
Откуда: г. Ростов-на-Дону

Размер файлов btrieve

Сообщение Игорь Столяров » 13 Январь 2019, 11:54

finsoftrz писал(а):
13 Январь 2019, 11:35
Вопрос, что практичнее, в одном файле или в нескольких
Думаю, что лучше в одном файле, если нет ограничений на размер файла в файловой системе.
Поясню. Например, в PSQL12 с помпой преподносилась опция фоновой дефрагментации и упаковки БД во время простоя.
Очевидно, что эти процессы более эффективны, если внутри одного файла доступна вся информация.
«V» значит Вендетта !

kreator
Ветеран
Сообщения: 3234
Зарегистрирован: 28 Май 2009, 14:54
Откуда: Москва

Размер файлов btrieve

Сообщение kreator » 13 Январь 2019, 14:36

В больших базах есть возможность разбить хранилище на несколько файлов. Типа хранение данных и индексов отдельно, что улучшает производительность. Вроде где-то читал такое. Хотя сейчас больше актуально всё засунуть в память или в кэш.
We are hard at work… for you. :)

Аватара пользователя
Игорь Столяров
Ветеран движения
Сообщения: 3981
Зарегистрирован: 07 Июль 2005, 9:19
Откуда: г. Ростов-на-Дону

Размер файлов btrieve

Сообщение Игорь Столяров » 13 Январь 2019, 14:47

kreator писал(а):
13 Январь 2019, 14:36
Типа хранение данных и индексов отдельно, что улучшает производительность.
Это безусловно да - и кстати, потому традиционные кларионовские DAT работают побыстрей иновационного TPS …
Но это не наш случай - здесь просто идёт сегментирование образа БД, примерно как при архивации с разбитием на тома.
«V» значит Вендетта !

Аватара пользователя
finsoftrz
Ветеран
Сообщения: 1162
Зарегистрирован: 06 Ноябрь 2014, 12:48

Размер файлов btrieve

Сообщение finsoftrz » 13 Январь 2019, 15:20

Игорь Столяров писал(а):
13 Январь 2019, 14:47
kreator писал(а):
13 Январь 2019, 14:36
Типа хранение данных и индексов отдельно, что улучшает производительность.
Это безусловно да - и кстати, потому традиционные кларионовские DAT работают побыстрей иновационного TPS …
Такое можно получить пожалуй только при прямом сканировании по записям set/next. Я давно уже не работаю с dat, но, насколько помню, тесты с выборочным чтением по первичному ключу были в пользу tps. Главная проблема при работе с dat - это жутко тормозные транзакции.

Вообще, производительность работы значительно зависит от самого приложения. Актуальный случай, немного не в тему. В сети розничных супермаркетов на сервере используем приложение, изначально разработанное для опта. Сейчас, когда число магазинов подросло и прошло пару лет с начала работы, наблюдается серьезная деградация в производительности. Причина, в общем, понятна. Используется парционный учет по методу ФИФО. А розница - это зеркало опта. В ней много приходов. Если считать приблизительно 40 накладных и 25 магазинов, то получаем 900 приходов в день. Плюс еще приличная доля пересорта, в результате чего партии не закрываются и накапливаются. А когда считаем распределение продаж по закупкам, то получаем огромную кьюшку в памяти, в результате чего начинается своп на диск и тормоза. И пока у меня складывается мнение, что никакими ухищрениями ситуацию не выправить, надо переходить на учет по средним ценам, отказавшись от ФИФО. Благо программа построена так, что переключиться можно точечной доработкой в функционале.
Рязань решает.

Ответить