Btrieve и clarion

[kreator]

При постраничной загрузке броуз дёргается и ползунок прокрутки себя ведёт неправильно. И плюс происходит постоянное дёргание сервака, что не есть хорошо.

Как вы себе представляете пофайловую загрузку например справочника контрагентов на 5 тыс позиций? Или товаров на 10 тыс? Я уж молчу о журналах первички... лет так за 10

Неужели у Вас MS SQL 5-10 тысяч записей оперативно не выдаст? У меня на трикотажной фабрике как раз около 5 тысяч наименований изделий (может, сейчас побольше). И дерево, и просто список, вообще, без задержек. Но это SA. На FB есть список ~120тыс. записей. 3-4 секунды. Но это, конечно, уже чересчур. Ползунок не работает даже. Нужна предварительная фильтрация. В общем, как и во всех больших списках.

[RaFaeL]

Неужели у Вас MS SQL 5-10 тысяч записей оперативно не выдаст?

Если нужно вывести только поля запроса (который опять же весь на простых джойнах, без курсоров), то может и выдаст. Только вот броузы, они же много информации содержат, у нас не вся логика на сервер перенесена, частично заполняется по старинке на ValidateRecord и т.п., так что несколько секунд будет думать все это как минимум. А лукап на выбор контрагента надо мгновенно открывать

[kreator]

Я привёл время фактически по одной таблице. ValidateRecord не пользую, фильтрация на сервере. В сложных случаях использую хранимки. А в последнее время использую CTE (Common Table Expressions). Кстати, в С6.3 с CTE проблемы, я так понимаю.

[Игорь Столяров]

Кстати, если коснулись вопроса тиражируемости приложений Clarion с различными БД, то ещё хуже ситуация с IP Driver.
C SQL хоть сисадмины знакомы на местах. Он им понятен. IP Driver - неведомая зверушка.
Это хорошо только, если юзаешь его своей конторе или сам можешь устанавливать и обслуживать у пользователя.

Даже не знаю, можно ли в принципе, создать какой-то инсталяционный пакет для развёртывания системы с IP Driver.
Зачастую пользователи даже не знают, где у них вообще находится сервер ...

[finsoftrz]

Кстати, если коснулись вопроса тиражируемости приложений Clarion, то ещё хуже ситуация с IP Driver.
C SQL хоть сисадмины знакомы на местах. Он им понятен. IP Driver - неведомая зверушка.
Это хорошо только, если юзаешь его свой конторе или сам можешь устанавливать и обслуживать у пользователя.

Да там ничего админить не надо. Подготовил на своем компьютере, проверил работу. Потом просто копируешь каталог ClarionDataServer на тот же диск клиенту, запускаешь ipsrvmgr.exe и жмешь кнопку установки сервиса. Ну можешь еще джаву инстальнуть, если очень хочется, чтобы админку их запускать. Для работы она не нужна. Порт открыть, чтобы доступен был по входящим соединениям. И все вроде. В приложении адрес для коннекта прописать. В общем, делов на 5 минут...

[finsoftrz]

Как художник советовал, можно инструкцию в комиксах сделать...

[Игорь Столяров]

И все вроде. В приложении адрес для коннекта прописать.

Ну в общем-то уже список не слабый, тем более что решения надо принимать по обстановке …
Правильно ли я понял, что если копировать папку ClarionDataServer , то установку с серийником проводить не надо,
и DLL тоже регистрировать не надо ?

[finsoftrz]

Да.

[Игорь Столяров]

Да.

Спасибо. Это в корне всё меняет … надо пробовать !

[finsoftrz]

А смысл? Все равно с терминалами не дуется от слова совсем. А лицензия на tsplus на 4 рабочих места $70, любая мелкая контора может себе позволить, если лицензионная чистота для нее критична.

[finsoftrz]

Вот еще нюанс всплыл при работе с btrieve. Если используется memo поле, то оно сохраняется в отдельном файле (кроме варианта single, которое возможно при записях переменной длины). Имя файла определяется как первые 5 символов имени файла основной таблицы и символов "mem". То есть, если у нас в словаре объявлены 2 таблицы с memo полями, первые 5 символов имени которых совпадают, то получаем кашу. Например, fsLogTr.dat и fsLogArhTr.dat будут ссылаться на один файл с memo fsLogMem.dat. Выход не допускать, чтобы такие файлы имели одинаковые первые 5 символов, либо использовать Single. Последнее вроде не очень рекомендуют. Я, в своем случае, изменил имя fsLogArhTr.dat на fsArhTr.dat, благо оно назначалось динамически. В других таблицах memo поля я практически не использую.

[finsoftrz]

Такую ситуацию наблюдаю. После перезапуска сервиса btrieve, когда очищен кэш, скорость построения отчетов очень низкая. То есть само чтение с диска происходит медленно. Запустил товарную оборотку по всей номенклатуре за 5 месяцев, молотило примерно 1.5 часа. После этого, когда данные уже зашли в кэш, оборотка по всей номенклатуре за любой из месяцев того же периода формируется немного больше 1 мин. При отборе по товарам верхней группы уже 20-30 сек, по нижним группам в районе 10 сек.

В основной таблице движения товаров примерно 17 млн записей, объем около 10ГБ (точнее, физически разделено на 2 таблицы, обработка затрагивает обе). Записи без сжатия. То есть, когда информация зашла в кэш, все хорошо. Но вот 1.5 часа при прямом чтении с диска как-то непонятно. Может, какие настройки на этот счет есть? Кэш операционной системы не используется. Я его пытался включать, но что-то особой разницы не заметил...

[finsoftrz]

Пообщался с админом. У них под "сервер" самосбор примерно 4 летней давности. Один процессор i5 с 4 ядрами 3.3 ГГц и медленный винт. Операционка windows7 prof 64 разряда. А оперативки 16ГБ. Видимо, надо постепенно железо и ось поднимать. Пока на утро поставим оборотку за полгода в автомат, чтобы кэш прокачивала.

В связке с ip-драйвером (через интернет) btrieve пока нормально работает. Визуально, немного побыстрее, чем связка ip-драйвера и tps.

[Игорь Столяров]

оборотку по всей номенклатуре за 5 месяцев, молотило примерно 1.5 часа

Я уже ранее как-то рассказывал, что в таких случаях (заказная программа, большой объём данных) можно использовать
смешанный доступ. Т.е. работаем через Btrieve, но на те же самые MKD файлы добавляем описание DDF и делаем запросы
уже через Pervasive.SQL. В этом случае вообще всю обработку можно перенести на сторону сервера в хранимые процедуры и
получать только результирующий список … Просто как вариант ускорить обработку на 2 порядка …

[finsoftrz]

Нет, работа вся локально происходит. Там диск медленный на 5400. Когда кэш прокачан, то работает быстро. А если не прокачан, то сомневаюсь, что sql чем-то поможет. Там в основном все ускорение тоже на кэшировании построено.

Насчет 2 порядков, это реальные цифры? Я не очень понимаю, за счет чего может быть такой прирост. Пакетное чтение, фильтрацию на сервере и ограничение получаемых полей можно и средствами api делать. Разница, что по одной таблице. Версии actian zen, начиная с psql10, если не ошибаюсь, всякие справочники умеют кэшировать локально. То есть мы считываем отфильтрованный диапазон записей из основной большой таблицы, остальное все уже должно быть локально. Разница в скорости может быть, если на sql сервере хранится уже готовый результат запроса, который актуализируется по мере изменений в базе данных. Тогда он просто отдаст готовый результат. Насколько я понимаю, actian zen уступает другим известным sql серверам по производительности из-за того, что сложно поддерживать такое кэширование и обеспечивать параллельную прямую работу с записями. Поэтому они сейчас сделали репорт инжину. То есть это вторая база, которая поднимается на отдельном сервере и автоматически синхронизируется с основной. С этой второй уже работа осуществляется только через sql запросы.

Опять таки, по моим сведениям, приложения на actian zen (буду так называть, чтобы обобщить с предыдущими версиями), которые работают с большими объемами данных, используют так называемые server job. Это утилита, которая крутится на сервере, и выполняет различные функции, в том числе те, которые делает sql сервер. Клиент не работает напрямую с базой по сети при построении ресурсоемких отчетов, а шлет задания или забирает задания, выполненные по расписанию, с server job.
Еще одна разновидность оптимизации скорости работы - это кэширование отчетов. При построении какого-то отчета в специальной системной таблице сохраняются его параметры и какой пользователь в какой нити создал его. Если кто-то пытается сформировать подобный отчет, то программа проверяет и предлагает выбрать готовый результат. Такое в кларионовских приложениях подключается легко. Просто шаблон, в котором перечисляются сохраняемые реквизиты и реквизиты, которые отключают такое сохранение. Остальное автоматически. Самые сложные отчеты получаются за несколько секунд. Правда, если пользователи формируют одинаковые отчеты.

У меня несколько другие приоритеты, я ориентируюсь на централизованные вычисления. В этом случае actian zen нужен прежде всего для обхода ограничений tps на размер таблиц. Он также может потребоваться, если один сервер не справляется с объемами работы и надо делать ферму терминальных серверов и выделенный сервер под базу данных. Сомневаюсь, что такое потребуется. Например, указанная конфигурация в предыдущем примере "сервера" спокойно тянет с десяток терминальных подключений плюс около 30 периодических подключений через интернет, использующих ip драйвер. А чтобы дойти до ограничений размеров базы на tps, надо чтобы 60-70 пользователей работали на ввод в течении всего дня. У большинства же на вводе сидит порядка 20-25% сотрудников, остальные заняты анализом информации. То есть это либо крупная компания, либо сетевая структура.