Может мне кто обьяснить КАК использование транзакционных рамок (LOGOUT/COMMIT) влияет на РАЗМЕР файла!?
Имеем обычный цикл копирования из одного файла в другой (новый):
Код: Выделить всё
Create(NewFile); Open(NewFile)
Open(OldFile)
Convert.Init(...)
Set(OldFile)
Loop While Convert.LoopStep()
Next(OldFile); if ErrorCode() then Break.
NEW:Record = OLD:Record
NEW:Notes = OLD:Notes
Add(NewFile)
.
Convert.Kill()
W2kRus + SP3
Microkernel Database Engine v6.15.430
'/MEMO=SINGLE/PAGESIZE=4096/COMPRESS=OFF'
Размер результирующего файла:
- без транзакции ~8.5 метров
- с транзакцией ~7.7 метров
Файл-менеджер битрива показывает одинаковую инфу по обоим результирующим файлам.
P.S.
Блин! Вообще какая-то "каша" получается!
Сейчас попробовал разбить одну транзакцию на куски по 1000 записей. В результате получил файл БОЛЬШИЙ чем без транзакции!
Итого:
- без транзакции ~8.5 метров
- с единой транзакцией ~7.7 метров
- с "кусочной" транзакцией ~9.6 метров
Правда, последний вариант самый быстрый:
- на ~30% быстрее чем без транзакции
- на ~5% быстрее чем с единой транзакцией.
P.P.S.
Поставил PervasiveSQL 8.5 в локальном режиме.
Т.е. работа не с SQL-движком а с одиночным файлом через обычный битрив-драйвер.
Скорость обработки - бешенная!
TPS-драйвер практически везде проигрывает:(
~100000 записей:
- обычный Next/Previous - одинаково.
- хаотичная выборка через Get - ~50% медленнее
- массовое добавление записей - ~100% медленнее
- массовое изменение записей - ~100% медленнее
В последних двух тестах TPS-драйвер использовал транзакцию. Без транзакции - полная ж...па.
Использовал единую транзакцию, что на больших обьемах ОЧЕНЬ НЕ рекомендуется делать из-за большого времени финишного сброса данных в файл и, соответственно, сильно возрастающем риске "убить" файл при аппаратном сбое.
При "кусочной" транзакции - отставание еще сильнее - 3-5 раз!
А вот на битрив транзакция практически не влияет.
Даже наоборот - при некоторых условиях скорость без транзакции чуть выше чем в режиме транзакции.
Кстати, не заметил особого влияния на скорость обработки аттрибута /COMPRESS. Даже иногда компрессированный файл чуть быстрее.
Да, был-бы битрив типа остальных форматов - все в одном, без необходимости установки доп. софта - цены бы ему не было!
Кстати, может кто ТОЛКОВО и по пунктам обьяснить - что и как необходимо ставить на файловый сервер и на рабочие сетевые станции при условии работы через обычный (не SQL) битрив-драйвер!?
И можно-ли на рабочих станциях обойтись без инсталляции - просто "бросить" в один каталог с приложением нужные либы и все? Ну, максимум, перед запуском приложения запускать рекорд-менеджер и что-то еще. Хотя, насколько я понял, он и так автоматом подгружается при запуске приложения. По крайней мере так у меня - после инсталляции первасива и если не загружать при старте Винды его движок.
=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru
(Добавление)
Слушай, Олег, я малость не в тему - но... А чего ты вцепился в первасив сейчас? Новелл уже не такое частое явление как раньше - т.е. нужно на серваке или на клиентах ставить манагера. А если так - то формат уже очень не самостоятельный. А раз так - то какой смысл использовать именно его, а не нормальный нетяжелый сиквел типа MS SQL?
Более того - если нужна локальная работа или работа с небольшим числом подключеных юзеров - вообще можно MSDE использовать. Ставиться на клиента просто (если знать как). А по возможностям и скоркострельности сам понимаешь - бетрив давно не дуется с современными сиквелами.
--
Best regards,
Vadim mailto:vadim@softcreator.com
ICQ: 82308757
Обижаешь уважаемый. Задача , как я понял , не требует sql , хотя в некоторых случаях pervasive sql работает БЫСТРЕЕ MS SQL и как расхваливается tps (правда иногда писали "повалился tps , что делать ?") . Даже не представляю чтоб писали "повалился pervasive , что делать ?".сам понимаешь - бетрив давно не дуется с современными сиквелами.
Уважаемый Руденко хочет устанавливать свой продукт не присутствуя при этом лично. Я бы попробовал скопировать ветку реестра и файлы pervasive навалом без документации и прочего.
Vasiliev B <soft2@mail.redcom.ru>
Пожалуй это может быть только в одном случае - если памяти на машине, где крутиться сервер и клиент очень мало. Но это уже другая тема - а в нормальных условиях сейчас бетрив уже не конкурент сиквелу.Обижаешь уважаемый. Задача , как я понял , не требует sql , хотя в некоторых случаях pervasive sql работает БЫСТРЕЕ MS SQL и ...
Я тоже как-то не встречал случаев жалоб на падеж баз MS SQL.... как расхваливается tps (правда иногда писали "повалился tps , что делать ?") .
Даже не представляю чтоб писали "повалился pervasive , что делать ?".
MSDE ставиться при помощи небольшого WISE-скрипта абсолютно без участия человека - именно так мы поставляем демо-вариант программы - инсталлятор ставит сервер, аттачит базу, инсталлячит саму программу, настривает привязку к серверу.Уважаемый Руденко хочет устанавливать свой продукт не присутствуя при этом лично.
--
Best regards,
Vadim
(Добавление)
Слушай чего тебя так беспокоит размер файла? Там страничная организация данных, пусть сам драйвер "думает", сколько ему надо. Поверь, с оптимизацией там все впорядке. Кстати - не забывай, что драйвер периодически выделяет в файле новые страницы под данные. И может резервировать до 5% от текущего объема файла. Так что забудь, в общем случае эти тесты не показатель. При повторном прогоне можешь получить другой размер.Может мне кто обьяснить КАК использование транзакционных рамок (LOGOUT/COMMIT) влияет на РАЗМЕР файла!?
Проигрывает, на что в том числе и мной указывалось неоднократно на протяжении нескольких лет.TPS-драйвер практически везде проигрывает:(
Для btrieve что открыта транзакция, что нет - побоку. При открытой транзакции он модифицируемые страницы файла сохраняет в файл транзакции, и в случае отката их восстанавливает обратно.Даже наоборот - при некоторых условиях скорость без транзакции чуть выше чем в режиме транзакции.
Все зависит от того, какая структура файла. При использовании MEMO=64000Кстати, не заметил особого влияния на скорость обработки аттрибута /COMPRESS. Даже иногда компрессированный файл чуть быстрее.
COMPRESS=ON очень даже существенно повлияет на размер файла.
Если знать КАК, то и btrieve можно ставить БЕЗ установки.Да, был-бы битрив типа остальных форматов - все в одном, без необходимости установки доп. софта - цены бы ему не было!
Если PERVASIVE - то папка PVSW + реестр. Если BTRIEVE - то папка BTI + реестр.Кстати, может кто ТОЛКОВО и по пунктам обьяснить - что и как необходимо ставить на файловый сервер и на рабочие сетевые станции при условии работы через обычный (не SQL) битрив-драйвер!?
Можно. Для клиента 6.15 WBTRV32.DLL хватает. И больше ничего запускать не надо.И можно-ли на рабочих станциях обойтись без инсталляции - просто "бросить" в один каталог с приложением нужные либы и все? Ну, максимум, перед запуском приложения запускать
С уважением, Ставич Олег
Укрсиббанк г.Харьков
oldstav@ukrsibbank.com
Написал: ClaList(2)