Форум » LetoDB, HbNetio. » LetoDb fork » Ответить
LetoDb fork
PSP: https://github.com/elchs/LetoDBf https://github.com/elchs/LetoDBf/blob/master/README.md Кто-нибудь пробовал или использует в продакшене?
Pasha: Почитайте эту старую тему: http://clipper.borda.ru/?1-7-0-00000037-000-0-0-1486290536 В режиме No_Save_WA = 0, а этот режим является основным для letodb, сервер не открывает для каждого клиента одну и ту же таблицу, а использует одну и туже pArea, если таблица уже открыта. Соответственно сервер делает не физическую блокировку записи ли таблицы, а логическую. Для No_Save_WA = 1 для каждой команды use с клиента сервер открывает свою копию рабочей области, и соответственно выполняет уже физические блокировки. Этот режим считался в letodb экспериментальным, я сам его никогда не использовал, и не скажу, допилил ли его Александр в конце концов. В letodbf похоже основным сделан режим No_Save_WA = 1. Но точно я не скажу. Так что для меня вопрос: "зачем самый "первый" режим (когда No_Save_WA = 0) нужен" стоит как бы наоборот: "зачем нужен второй ?".
PSP: Pasha пишет: Почитайте эту старую тему: Я читал ее. Но она как-то затухла. Поэтому остались вопросы.
Pasha: В конце концов, смотрим доку: LetoDB: No_Save_WA = 0 - Когда этот режим установлен, при каждом вызове dbUseArea() сервер действительно открывает файл и создает новую рабочую область (workarea) - в режиме по умолчанию каждый файл открывается сервером только один раз и образуется одна реальная рабочая область для этого файла для всех клиентов. Теоретически это режим может увеличить производительность при большом количестве активных клиентов, но он недостаточно тестировался, поэтому для рабочих приложений рекомендуется использовать режим по умолчанию. LetoDBf: No_Save_WA = 1 - server mode of internally handling database tables 1 each dbUseArea() will cause a real file open operation by the OS, identical to what client requested, so workareas at the server are same as at client side. [ WA number, alias, filter conditions, relations ] 0 each table is opened only one time, this workarea 'exchanged' in between client requests. so only one connection will have access to the table at a time. No relations active at server, Alias names at server are different from the client. Recommend '1' if you plan to execute functions at server side ( UDF ).
SergKis: Sergy пишет Не очень понятен смысл примера... Смысл в том, что введенные unique тэги уже являются готовой выборкой, переключив та тэг INDEX ON KODTER ... UNIQUE // реал. список территорий в информации (в справочнике может быть стопятсот тыс. позиций) SetOrdFocus('KODTR') GO TOP tbrowse(...) // связав со справочником территорий и взяв наименование и ... имеем список реальных территорий, где можем поставить галочку\выбрать - для получения списка клиентов этой территории, т.е. INDEX ON KODTER+CLIENT ... UNIQUE // реал. список клиентов на выбранной территории SetOrdFocus('KODTER_CLI') SET SCOPE TO cKodTer, cKodTer GO TOP tbrowse(...) // реал. список клиентов территории, связав со справочником клиентов берем наименование и ... отмечаем галками\выбором нужных клиентов и у нас готовы параметры запроса для тэга INDEX ON KODTER+CLIENT ... // список всех территорий по клиентам в информации вот тут и выполняем запрос по установкам выше. территория+клиенты, помеченные галкой. период я отбросил для упрощения примера. Поэтому мне не очень понятен смысл в 44 тегах/индексах Смысл в том, что нет выборок типа select * from ..., а простыми переключениями тэгов отображаются таблицы в разных разрезах
PSP: Pasha пишет: В конце концов, смотрим доку: LetoDB: No_Save_WA = 0 - Когда этот режим установлен, при каждом вызове dbUseArea() сервер действительно открывает файл и создает новую рабочую область (workarea) - в режиме по умолчанию каждый файл открывается сервером только один раз и образуется одна реальная рабочая область для этого файла для всех клиентов. Сто раз смотрел)) Формулировка уж какая-то нечёткая) Совпадает ли поведение letodb и letodbf при одинаковых установках этого параметра? Как 0 или 1 отражается на выполнении udf? (это "Recommend '1' if you plan to execute functions at server side ( UDF )" применимо к оригиналу?) Нет ли возможности выяснить, допилил ли Александр это?
Sergy: Pasha пишет: В конце концов, смотрим доку: LetoDB: No_Save_WA = 0 - Когда этот режим установлен, при каждом вызове dbUseArea() сервер действительно открывает файл и создает новую рабочую область (workarea) - в режиме по умолчанию каждый файл открывается сервером только один раз и образуется одна реальная рабочая область для этого файла для всех клиентов. Теоретически это режим может увеличить производительность при большом количестве активных клиентов, но он недостаточно тестировался, поэтому для рабочих приложений рекомендуется использовать режим по умолчанию. Сорри, для непонятливых: Для LetoDb (не форк): "Когда режим установлен": No_Save_WA = 1 ?? "Режим по умолчанию": No_Save_WA = 0 ? Для обоих версий: Если No_Save_WA = 0 - в каждый момент времени таблицей может пользоваться только один клиент: so only one connection will have access to the table at a time ??? Зачем такой режим нужен в принципе? Ведь заявлено, что "теоретически может дать прирост производительности при большом количестве клиентов". Получается, что-то типа USE table EXCLUSIVE ? Что-то скорее всего, я не догоняю...
SergKis: Вроде так было: No_Save_WA = 0 - идет оптимизация открытий таблиц, одна таблица, открытая несколькими клиентами открывается один раз в области WA при No_Save_WA = 1 каждый запрос на открытие любой таблицы получает новую область WA А.Кресин занимался доводкой этого режима, кто то сильно тестировал и был положительный результат
PSP: Только Александр Кресин может ответить, видимо...
Sergy: SergKis пишет: Смысл в том, что нет выборок типа select * from ..., а простыми переключениями тэгов отображаются таблицы в разных разрезах Сергей, спасибо за разъяснения. Никогда не пользовался UNIQUE индексами, нужно будет посмотреть на них гораздо пристальнее.
Pasha: PSP пишет: Только Александр Кресин может ответить, видимо... Ну давайте еще раз разжуем режим No_Save_WA. Пусть два клиента открывают одну и ту же таблицу. Как это делается в режиме No_Save_WA = 0 Поток для 1-го клиента выполняет команду use в монопольном режиме. Поток для 2-го не делает use, а разделяет уже открытую таблицу с 1-м потоком. Причем запросы к таблице от обеих клиентов выполняются без задержки, одновременно. В режиме No_Save_WA = 1 поток для 1-го клиента выполняет команду use shared. Поток для 2-го - аналогично, т.е на сервере эта таблица открыта два (несколько) раз. Для letodb 1-й режим - основной, в работе оба режима отличаются способом блокировки: в 1-м выполняется логическая виртуальная блокировка, то есть создаются списки блокированных записей, во втором - блокировка средствами rdd. Ну и во втором режиме поскольку таблицы открыты как shared, их может открыть стороннее приложение. В letodbf основным является 2-й режим, ну и в нем судя по всему реализованы еще дополнительные возможности, я уже упоминал серверные relations. Какой режим лучше - надо тестировать. Я этим не занимался. Ну и вопрос "а нахрена вообще такой-то режим" наверное задавать не стоит. Для нас "мамы всякие нужны, мамы всякие важны". Наверное что-то лучше будет работать в первом режиме, а что-то во втором.
Pasha: Sergy пишет: Сергей, спасибо за разъяснения. Никогда не пользовался UNIQUE индексами, нужно будет посмотреть на них гораздо пристальнее. А есть еще индексы с условием for, тоже удобная штука. Поддерживаются и в ntx, и в cdx
Pasha: Sergy пишет: Не вижу в тексте Leto_ToggleZip(1) Не работает совсем этот Leto_ToggleZip. Тест зависает на первом use В логе найдено: 02.13.2018 10:39:57 INFO: connected 127.0.0.1:51141 test_db.exe CP: EN DF: dd/mm/yy conn-ID 0 02.13.2018 10:40:01 ERROR thread2() leto_SockRec != ulRecvLen 02.13.2018 10:40:01 INFO: disconnect 127.0.0.1:51141 test_db.exe users=(1 : 1 : 1), tables=(0 : 0) Сервер собран с harbour 3.2 + mingw64 Клиент harbour 3.2 + bcc55 letodbf скачивал вчера
PSP: Pasha пишет: Ну давайте еще раз разжуем режим No_Save_WA. Спасибо за разъяснения. Остался один вопрос: доделал ли Кресин режим "1".
Pasha: Pasha пишет: Не работает совсем этот Leto_ToggleZip. Тест зависает на первом use Ага, нашел, где собака порылась: readme.txt BCC55 and maybe also newer ones have a problem with compiling LZ4 compression library, you will get this case slower ZLib compression. This must fit together for client lib and server when you want to use network traffic compression. It is configured by this "{!bcc}" at top in the ".hbp" files.
SergKis: Pasha пишет Ну и во втором режиме поскольку таблицы открыты как shared, их может открыть стороннее приложение. С No_Save_WA = 0 получить режим shared для таблиц можно, поставив в ini Share_Tables = 1, т.е. таблицы может открывать стороннее приложение. А есть еще индексы с условием for, Замечание правильное. В индексных выражениях условие FOR я подразумевал обязательным, т.е. INDEX ON KODTER ... FOR ! Deleted() UNIQUE ... работа с инф. тэга не зависит от режима SET DELETAD ON\OFF подключенного модуля. Что еще добавлять в FOR это уже по ситуации. Наличие тега для доступа к удаленным записям INDEX ON ID ... FOR Deleted() считаю обязательным в таблицах задач.
Pasha: Прогнал тест по сети. LetoDB (клиент bcc, не пересобирал) - 184 сек LetoDBf + mingw32: несжатые пакеты 121 сек сжатые пакеты 110 сек
PSP: Это большая разница.
Pasha: SergKis пишет: Наличие тега для доступа к удаленным записям INDEX ON ID ... FOR Deleted() считаю обязательным в таблицах задач. Я при удалении записи полностью ее очищаю. Так что удаленные записи оказываются по индексу всегда "сверху". И обхожусь без дополнительного тега.
SergKis: Pasha пишет И обхожусь без дополнительного тега. В записи есть поля ID_DTM_ADD, ID_DTM_MOD, ID_DTM_DEL отражающие TimeStamp (C или @ типов), запись никогда не очищается (длительность действия год) как и идентификатор записи - все это государственно отчетные показатели. Организация тэгов, как показано выше, позволила упростить запросы по отчетности (лог журналы тоже есть - они уже для доп. разбирательств). Да и для внутр. исп. тэг по удаленным оказался полезным, начальнику любого уровня глянуть на browse что где наколбасили.
Pasha: SergKis пишет: В записи есть поля ID_DTM_ADD, ID_DTM_MOD, ID_DTM_DEL отражающие TimeStamp (C или @ типов), запись никогда не очищается Это же неиндескные поля, для индекса их значение до лампочки. Может у вас задача другая ? У меня если запись удалена, она просто используется для добавления новых из пула удаленных. Схема простая: go top, если первая запись удалена и индексное выражение пустое - она используется, если нет - то dbAppend
полная версия страницы