Отправлено: 31.01.08 11:36. Заголовок: Leto DB Server

Только что открыл на Sourceforge новый проект - Leto DB Server - https://sourceforge.net/projects/letodb

Это мультиплатформенный ( Windows, Unix/Linux ) сервер баз данных, предоставляющий клиентским программам доступ к dbf/cdx файлам, находящимся на удаленном сервере ( можно и на локальном компьютере запускать - в отладочных целях ). В общем, как ADS :).

Проект - на стадии разработки, не все даже базовые функции еще реализованы, до оптимизации дело еще не дошло. Но работает :).
Крутится у меня на сервере несколько дней, подключал до 15 клиентов, пока не падает. Мои программы работают с ним нормально.

Преимущества по сравнению с обычным файл-сервером:
1) Безопасность - базы могут быть в каталоге, недоступном для клиентских компьютеров - никто их случайно не удалит и не повредит.
2) Поскольку базы открываются серверной программой, а не клиентской, ее целостности ничего не грозит при случайном отключении клиентского компьютера.
3) значительное уменьшение сетевого траффика.
4) Должен быть, по идее, выигрыш в скорости.
5) Возможность контроля за пользователями с помощью утилиты manage ( можно придумать и другие формы контроля ).
6) Можно будет сделать транзакции, stored procedures на Харборе, ... и вообще все в наших руках :).

Кто хочет участвовать в разработке, тестировании - пишите.

 Отправлено: 23.03.08 11:15. Заголовок: Ставлю set deleted o..

цитата:

Ставлю set deleted on, и удаленные записи видны. Не пойму, в чем дело

Если устанавливаете после присоединения, то надо leto_Setdeleted() использовать.

 Отправлено: 23.03.08 13:02. Заголовок: А Ads как делает ? Т..

А Ads как делает ? Там дополнительной команды нет, используется текущая установка клиента
Может все-таки добавим 1 байт к пакету передачи ? Из тех же соображений, что незначительное увеличение размера пакета лучше, чем дополнительный пакет. Да и совместимость с существующим кодом сохранится
У меня к примеру сплошь и рядом встречаются такие конструкции:

Function SeekPers(nTab)
Local lSD := Set(_SET_DELETED, .f.), lR, no := persons->(IndexOrd())

persons->(dbSetOrder(2))
lR := persons->(dbSeek(nTab))
persons->(dbSetOrder(no))
Set(_SET_DELETED, lSD)
Return lR

Это приведет к 2-м дополнительным пакетам для 1-й операции поиска

 Отправлено: 23.03.08 14:48. Заголовок: А Ads как делает ? ..

цитата:

А Ads как делает ?

В ADS RDD специальная технология используется, добавленная David G.Holm именно для таких целей в set-модуль.
В нашем случае, согласен, стоит передать лишний байт, в нем можно, используя битовые функции, передавать и set exact ( сейчас оно вообще не передается ), а для seek поместить и bsoftseek,bfindlast ( сейчас это 2 отдельных байта ).

 Отправлено: 24.03.08 14:17. Заголовок: alkresin пишет: пер..

alkresin пишет:

цитата:

передавать и set exact

set exact нужен для вычисления выражений, а они вычисляются не только для фильтра (3 операции навиации), но и при создании индекса. Значит, надо передавать и для createindex
Смотрим, какие еще установки могут понадобиться на сервере.

_SET_PATH, _SET_DEFAULT - наверное, не нужны

HB_SET_DECIMALS - тоже на сервере нафик не нужен

SET_DATEFORMAT
SET_EPOCH

нужен для вычисления DTOC. Поскольку в битовой струкруре эти установки не помещаются, да и это глобальные установки, которые вряд-ли динамически будут изменяться, можно передать их на сервер отдельной командой

Поскольку в основном то, что было запланировано в начале февраля, уже сделано, предлагаю обсудить дальнейшие направления работ

Мне кажется, можно сделать вот что (перечисляю и малозначительные, и важные пункты)

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

- укаазание в скрипте сборки сервера кодовых страниц, для которых надо выдать Request

- поддержка дополнительных числовых полей: '2', '4', а также полей VFP

- надо переделать PutValue для мемо-полей

- оптимизация relations: передача состояния дочерних областей прямо в leto_rec, запись их на клиенте в некую область данных, и затем использование в SELF_RELEVAL вместо передачи на сервер запроса на seek/goto

- сделать leto_CloseAll()

- как делать транзакции ? Для каждого юзера заводить временный dbf/fpt файл для журнала транзакций, и в каждую таблицу добавлять служебное поле, поскольку флаг deleted использовать не удастся
Какой уровень транзакций ? Только read commited ?

- вычисляемые поля. Здесь возникает вопрос, как вычислять на сервере выражения, которые содержат имена алиасов клиента
Ведь на сервере имена алиасов свои. Можно это разрешать имена алиасов поиском "->" и заменой

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

 Отправлено: 24.03.08 15:59. Заголовок: Из базовой функциона..

Из базовой функциональности осталась ( если я не упустил еще что-то ) реализация orderListClear. Несмотря на кажущуюся простоту, там есть неприятные моменты. После этого можно делать поддержку ntx. Думаю, для этого надо прописывать в серверном ini [DATABASE] ( вот к ним и подобрались :) ) и там помечать ее как ntx.

Из перечисленных вами пунктов интересными и приоритетными лично для меня являются транзакции и, в какой-то степени, вычисляемые поля.

leto_closeAll() сделать просто:

{
sendrecv( "close;all';" ); // что-то вроде
bNotSendClose = TRUE; // Глобальная переменная в leto1.c, чтоб метод close не слал запрос на сервер
hb_rddCloseAll();
bNotSendClose = FALSE;
}

Кодовые страницы, наверное, надо указать в .h все - пусть если кто хочет уменьшить вес сервера, убирает ненужные ( а они не много-то и весят ).

А важными для меня целями, кроме транзакций, являются дополнительные процессы, чтоб передавать им на исполнение некоторые задачи ( индексирование, ... ) и server side процедуры.

 Отправлено: 24.03.08 18:35. Заголовок: Реализация транзакци..

Реализация транзакций мне видится следующим образом:
leto_BeginTransaction() просто устанавливает в TRUE какой-нибудь bTransActive.
leto_PutRec(), если bTransActive == TRUE, не посылает изменения на сервер, а добавляет в специальный буфер.
leto_CommitTransaction() отправляет содержимое буфера на сервер и устанавливает bTransActive в FALSE.
Сервер обрабатывает буфер, пишет изменения в таблицы, попутно сохраняя где-то содержимое измененных полей, чтобы в случае чего откатить изменения.

 Отправлено: 24.03.08 20:22. Заголовок: Т.е. read commited Т..

Т.е. read commited
Такая реализация транзакций будет работать очень быстро, надежно, но есть и недостатки
1. Внутри транзакции на клиенте операция seek не сможет учитывать измененные записи, которые еще не переданы на сервер
Ограничение не такое уже и сильное, можно пойти на него
Для операций skip/goto можно сделать просмотр буфера перед посылкой запроса на сервер
2. Как внутри транзакции в этом случае формировать значения ключевых полей, если с одна таблица будет учавствовать в 2-х транзакциях с разных клиентов ?
Это уже более существенно

 Отправлено: 24.03.08 20:39. Заголовок: Внутри транзакции на..

цитата:

Внутри транзакции на клиенте операция seek не сможет учитывать измененные записи, которые еще не переданы на сервер

Я бы даже не назвал это ограничением. Надо просто корректно подготавливать выполнение транзакций: сначала найти все записи, которые будут изменены, заблокировать их, а потом выполнять транзакцию, иначе серверу относительно часто придется выполнять rollback ( если нужную запись не удалось заблокировать ). ADS, например, так и советует делать, они даже ограничивают выполнение блокировок во время транзакций и запрещают разблокировки.

цитата:

Как внутри транзакции в этом случае формировать значения ключевых полей, если с одна таблица будет учавствовать в 2-х транзакциях с разных клиентов ?

Поясните на примере. Я пока не понял, в чем проблема.

 Отправлено: 24.03.08 22:00. Заголовок: Кстати, учитывая то,..

Кстати, учитывая то, что все команды доступа к данным выполняются в настоящий момент последовательно в одном потоке, правильнее определить уровень изоляции как serializable, т.е. самый высокий :).

 Отправлено: 24.03.08 23:50. Заголовок: Я имел в виду одновр..

Я имел в виду одновременное получение значения ключа:

dbGoBottom()
nKey := Key + 1
begin transaction
dbAppend()
Field->Key := nKey
...

Может случиться коллизия, когда 2-й клиент получит такое же значение ключа, пока 1-й не закончил транзакцию

 Отправлено: 25.03.08 01:17. Заголовок: Не забудьте сделать ..

Не забудьте сделать еще запуск letodb.exe как службу !!!
А то замучишься потом его запускать самостоятельно.

А вообщето неплохо бы сделать прогу, которая занимая мало место в памяти на сервере, слушала бы Port = 2812
указанный в letodb.ini и при обращении к этому порту с любого клиента, поднимала бы сам letodb.exe
А в самом letodb.exe предусмотреть выгрузку из памяти если все клиенты прекратили работу с БД.
И тогда удаленно можно было бы редактировать letodb.ini

 Отправлено: 25.03.08 09:06. Заголовок: Я имел в виду одновр..

цитата:

Я имел в виду одновременное получение значения ключа: ...

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

 Отправлено: 25.03.08 20:46. Заголовок: Добавил поддержку DB..

Добавил поддержку DBFNTX.
Чтобы сервер работал с этим драйвером, надо написать в letodb.ini: DEFAULT_DRIVER = NTX
В самом ближайшем будущем добавлю в ini [DATABASE], чтобы устанавливать ntx не для всех данных, а для определенных каталогов.

 Отправлено: 26.03.08 10:44. Заголовок: Теперь можно писать ..

Теперь можно писать в ini:
[DATABASE]
DataPath = /some_db
Driver = NTX

чтобы определить каталог с данными /some_db, файлы в котором надо открывать через DBFNTX

Сегодня, если не обнаружатся вдруг ошибки, выложу новый build.

 Отправлено: 26.03.08 14:12. Заголовок: alkresin пишет: выл..

alkresin пишет:

цитата:

выложу новый build

Выложил готовую к использованию полную сборку LetoDB build 0.5 по адресу:

http://minigui.mylivepage.ru/file/?fileid=4909

Результаты тестов для этой сборки:

Test 1 Finished in 83.43 seconds
Test 2 Finished in 0.55 seconds
Test 3 Finished in 8.08 seconds
Test 4 Finished in 7.96 seconds

Расшифровка тестов:
1) добавление 200 000 записей и их заполнение произвольными данными
2) индексирование по числовому полю
3) позаписное перемещение через всю базу без использования индексов
4) позаписное перемещение через всю базу с использованием индекса

Итоговый размер базы: 11,2 МБ

Все тесты проводились на виртуальном (RAM) диске

 Отправлено: 26.03.08 14:17. Заголовок: Фантастика! У вас та..

Фантастика!
У вас там робот автоматом отслеживает релизы и делает сборки ?
Я только несколько минут назад файлы выложил ...

 Отправлено: 26.03.08 16:08. Заголовок: gfilatov пишет: Вс..

gfilatov пишет:

цитата:

Все тесты проводились на виртуальном (RAM) диске

Не совсем понятно !
Что на сервере был создан виртуальный диск и на нем тестировалось ?
Тогда это не есть хорошо ... Это не реальная ситуация !
Нужно тестировать на реально-работающем сервере, когда 10-15 клиентов сидят не только в этой задачи, но и в других.

 Отправлено: 26.03.08 16:21. Заголовок: Andrey пишет: Что н..

Andrey пишет:

цитата:

Что на сервере был создан виртуальный диск и на нем тестировалось ?

Все тесты проводились на виртуальном (RAM) диске на локальной машине

Andrey пишет:

цитата:

Тогда это не есть хорошо ... Это не реальная ситуация !

Согласен. Но никто и не будет на сервере добавлять 200 тысяч записей за один раз, как в 1-м тесте

 Отправлено: 26.03.08 21:03. Заголовок: Я попробую, чуть поп..

Я попробую, чуть попозже !

 Отправлено: 26.03.08 23:21. Заголовок: Для xHarbour-пользов..

Для xHarbour-пользователей прийдется пересобрать билд, так как надо добавить функцию hb_strncpyLower