Размер файлов btrieve
Модератор: Дед Пахом
Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4688
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 10 раз
- Поблагодарили: 37 раз
Размер файлов btrieve
Сравниваю размер файлов одной и той же базы на tps и btrieve. Некоторые файлы близки по размеру, но некоторые у btrieve в 2-3 раза больше. Например, одна большая таблица tps занимает 1.2 ГБ, на btrieve она разбивается на 3 физических файла (2х2 ГБ и небольшой довесок). Btrieve версии 10. Хотел поинтересоваться у коллег, кто работает с btrieve, это нормальное положение вещей или как-то настраивается. И если настраивается, есть ли смысл это делать. Сейчас все настройки btrieve по умолчанию.
C6/C11, ШВС, tps/btrieve.
- Игорь Столяров
- Ветеран движения
- Сообщения: 7447
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 16 раз
- Поблагодарили: 51 раз
Размер файлов btrieve
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 - не отказывайте себе в удовольствии работать с современными версиями.
Если дайджестом - то как-то оно так …
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 - не отказывайте себе в удовольствии работать с современными версиями.
Если дайджестом - то как-то оно так …
За теми кто отстал - не возвращаться. (С) Кодекс
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4688
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 10 раз
- Поблагодарили: 37 раз
Размер файлов btrieve
Да, разумеется, имелась ввиду PSQL 10. Насчет более поздних версий (если не считать 11), там сменился владелец, и есть некоторые сомнения по поводу целесообразности.
Файлы сравниваются сразу после конвертации. То есть никаких операций, кроме append и build над таблицами не производились. После перестроения ключей размер файла несколько уменьшается, но не принципиально. У меня подозрение, что не поджимаются конечные пробелы в строковых полях, так как расхождения заметны на таких таблицах. Хотя вроде как btrieve должен выполнять компрессию, как и tps. Я и думаю, что это зависит от настроек. Но, если так стоит по умолчанию, возможно, оптимизировано для скорости работы.
Максимальный размер таблицы у формата 9.5 - 256 Гб. На win32 автоматически разбивает на несколько файлов, работает, как с одной таблицей.
Файлы сравниваются сразу после конвертации. То есть никаких операций, кроме append и build над таблицами не производились. После перестроения ключей размер файла несколько уменьшается, но не принципиально. У меня подозрение, что не поджимаются конечные пробелы в строковых полях, так как расхождения заметны на таких таблицах. Хотя вроде как btrieve должен выполнять компрессию, как и tps. Я и думаю, что это зависит от настроек. Но, если так стоит по умолчанию, возможно, оптимизировано для скорости работы.
Максимальный размер таблицы у формата 9.5 - 256 Гб. На win32 автоматически разбивает на несколько файлов, работает, как с одной таблицей.
C6/C11, ШВС, tps/btrieve.
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4688
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 10 раз
- Поблагодарили: 37 раз
Размер файлов btrieve
Игорь, я так понимаю, у Вас нет рабочих баз tps/btrieve однотипной структуры со сравнимым количеством записей?
C6/C11, ШВС, tps/btrieve.
- Игорь Столяров
- Ветеран движения
- Сообщения: 7447
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 16 раз
- Поблагодарили: 51 раз
Размер файлов btrieve
На основании какой фразы в моём сообщении Вы сделали такой вывод ? Просто интересна логика мышления.
У меня есть несколько программ, которые отличаются только Dictionary - TPS / MKDE / DBF. Т.е. можно собрать
одну и ту же программу с различным форматом БД и практически идентичной структурой данных (если не брать в
расчёт списки со специфическими типами данных типа BLOB, DECIMAL и т.д.) и конечно можно перегрузить между ними данные.
Т.е. можно получить списки не со сравнимым кол-вом записей, а просто одинаковые, но в разных форматах.
Есть среди списков и такие, с которыми работаете Вы, т.е. только с базовыми типами данных: STRING, REAL, LONG, BYTE.
А чем нам это поможет ? Если Вы хотите спросить "какая БД больше", то ответ: "всегда больше MKDE". Причины я назвал,
подробно всё описано в документации структуры MKDE. Или Вы познаёте мир посредством эксперимента как Майкл Фарадей ?
Вот здесь подробно, с формулами - приведён расчёт размера файла MKDE в зависимости от настроек PAGES и версии:
http://docs.actian.com/psql/PSQLv13/ind ... %23ww19543
Не совсем. Есть ещё зависимость от выбора размера листа файла MKDE (и как следствие кол-ва записей на этом листе):
http://docs.actian.com/psql/PSQLv13/ind ... gdb.htm%23
Последний раз редактировалось Игорь Столяров 13 Январь 2019, 7:49, всего редактировалось 1 раз.
За теми кто отстал - не возвращаться. (С) Кодекс
- RaFaeL
- ✯ Ветеран ✯
- Сообщения: 1379
- Зарегистрирован: 24 Март 2009, 17:59
- Откуда: НН
- Благодарил (а): 7 раз
- Поблагодарили: 1 раз
- Контактная информация:
- Игорь Столяров
- Ветеран движения
- Сообщения: 7447
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 16 раз
- Поблагодарили: 51 раз
Размер файлов btrieve
Проверить не начнём. Но есть большое подозрение, что при размещении БД P.SQL на раздел диска с FAT32 -
эта опция включается автоматически и её нельзя отключить … т.к. там ограничение на размер файла в 4 GByte.
За теми кто отстал - не возвращаться. (С) Кодекс
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4688
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 10 раз
- Поблагодарили: 37 раз
Размер файлов btrieve
С логикой мышления вроде все очевидно. Потуги сфокусировать внимание на содержимом вопроса.Игорь Столяров писал(а): ↑13 Январь 2019, 0:13На основании какой фразы в моём сообщении Вы сделали такой вывод ? Просто интересна логика мышления.
В принципе, более менее понятно. Спасибо за ссылки. Как и предполагал, есть два варианта хранения данных - с фиксированной длиной записи и с переменной длиной. Во втором случае получаем аналогично tps. С поправкой на возможное изменение размера страницы в btrieve.
В общем, меня сейчас больше интересуют не технические подробности, а общая идеология работы с btrieve применительно к своему проекту. Поэтому решил пообщаться на предмет личного опыта использования, wiki я параллельно тоже читаю...
C6/C11, ШВС, tps/btrieve.
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4688
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 10 раз
- Поблагодарили: 37 раз
Размер файлов btrieve
CSTRING не родной кларионовский формат. Он привнесен для взаимодействия с внешними библиотеками и sql серверами. STRING в tps хранится без конечных пробелов сам по себе (плюс еще алгоритм упаковки). В btrieve, как выяснили, зависит от настройки - могут быть записи с фиксированной длиной и с переменной длиной.
C6/C11, ШВС, tps/btrieve.
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4688
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 10 раз
- Поблагодарили: 37 раз
Размер файлов btrieve
Сейчас уж fat32 мало где используется. Вопрос, что практичнее, в одном файле или в нескольких? Когда-то я читал, что в postgreSQL деление на файлы преподносится как оптимизация. Если там посмотреть физическое хранение базы данных, то это куча подкаталогов и файлов с цифровыми именами. А в ms sql, sybase, firebird, насколько я знаю, никто не парится - все в одном большом файле держат.Игорь Столяров писал(а): ↑13 Январь 2019, 7:45Проверить не начнём. Но есть большое подозрение, что при размещении БД P.SQL на раздел диска с FAT32 -
эта опция включается автоматически и её нельзя отключить … т.к. там ограничение на размер файла в 4 GByte.
C6/C11, ШВС, tps/btrieve.
- Игорь Столяров
- Ветеран движения
- Сообщения: 7447
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 16 раз
- Поблагодарили: 51 раз
Размер файлов btrieve
Думаю, что лучше в одном файле, если нет ограничений на размер файла в файловой системе.
Поясню. Например, в PSQL12 с помпой преподносилась опция фоновой дефрагментации и упаковки БД во время простоя.
Очевидно, что эти процессы более эффективны, если внутри одного файла доступна вся информация.
За теми кто отстал - не возвращаться. (С) Кодекс
-
- ✯ Ветеран ✯
- Сообщения: 5025
- Зарегистрирован: 28 Май 2009, 15:54
- Откуда: Москва
- Благодарил (а): 7 раз
- Поблагодарили: 22 раза
Размер файлов btrieve
В больших базах есть возможность разбить хранилище на несколько файлов. Типа хранение данных и индексов отдельно, что улучшает производительность. Вроде где-то читал такое. Хотя сейчас больше актуально всё засунуть в память или в кэш.
We are hard at work… for you.
- Игорь Столяров
- Ветеран движения
- Сообщения: 7447
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 16 раз
- Поблагодарили: 51 раз
Размер файлов btrieve
Это безусловно да - и кстати, потому традиционные кларионовские DAT работают побыстрей иновационного TPS …
Но это не наш случай - здесь просто идёт сегментирование образа БД, примерно как при архивации с разбитием на тома.
За теми кто отстал - не возвращаться. (С) Кодекс
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4688
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 10 раз
- Поблагодарили: 37 раз
Размер файлов btrieve
Такое можно получить пожалуй только при прямом сканировании по записям set/next. Я давно уже не работаю с dat, но, насколько помню, тесты с выборочным чтением по первичному ключу были в пользу tps. Главная проблема при работе с dat - это жутко тормозные транзакции.Игорь Столяров писал(а): ↑13 Январь 2019, 14:47Это безусловно да - и кстати, потому традиционные кларионовские DAT работают побыстрей иновационного TPS …
Вообще, производительность работы значительно зависит от самого приложения. Актуальный случай, немного не в тему. В сети розничных супермаркетов на сервере используем приложение, изначально разработанное для опта. Сейчас, когда число магазинов подросло и прошло пару лет с начала работы, наблюдается серьезная деградация в производительности. Причина, в общем, понятна. Используется парционный учет по методу ФИФО. А розница - это зеркало опта. В ней много приходов. Если считать приблизительно 40 накладных и 25 магазинов, то получаем 900 приходов в день. Плюс еще приличная доля пересорта, в результате чего партии не закрываются и накапливаются. А когда считаем распределение продаж по закупкам, то получаем огромную кьюшку в памяти, в результате чего начинается своп на диск и тормоза. И пока у меня складывается мнение, что никакими ухищрениями ситуацию не выправить, надо переходить на учет по средним ценам, отказавшись от ФИФО. Благо программа построена так, что переключиться можно точечной доработкой в функционале.
C6/C11, ШВС, tps/btrieve.