Как работает extDB2

Пишу миссию используя iniDB для сохранения/чтения данных. Но понимаю, что iniDB слабовата для более менее корректной работы с большим кол-вом транзакций. Хотел бы включить в проект MySQL. Создал БД, думаю к 3тье нормальной форме ее даже подогнал  . Нашел мод extDB2, но читая документацию как работать с ним запутался ваапще. 

Может кто набросать миссию с минимальным набором операций?:

1) соединение с БД.

2) Отправление запроса на сервер, либо вызов хранимой процедуры.

Ну, а если отправите разбирать exile, wasteland или altislife, то хоть подскажите , где там искать, в каких местах?

Сообщение отредактировал Dupont: 21 December 2015 - 12:34

насколько я помню из опыта работы игр с mysql, innodb легче лечится после крэшей сервера бд, но тормозная. мы для таблиц эккаунтов пользовались ей, а для "оперативных" данных myisam, которые вполне подойдут для игры. единственно в автозапуск надо проверку бд прописать. при 700 игроках мморпг тянула едва-едва на неплохом по тем временам компе. но это было 10 лет назад и неправда.

Зы извини, не правильно тебя понял. сперва подумал, что у тебя движок бд не тянет.

Сообщение отредактировал Snap: 21 December 2015 - 11:56

iniDB - там вообще все в текстовых .ини файлах хранится. Все это дело базой данных трудно назвать. Сама структура хранения инфы и способы ее обработки напрягают. Все таки база данных это база данных. А по поводу резервного копирования и восстановления , дык тут поле не паханное возможностей использования хранимых процедур. С MySQL опыта работы нет, только вот таблички создал, возможно там и свои встроенные средства есть, наподобие Оракловых журналов откатов и повторного выполнения (хотя маловероятно  ). 

 

Зы извини, не правильно тебя понял. сперва подумал, что у тебя движок бд не тянет.

Нее, я просто чем дольше миссию пишу, тем больше понимаю, использование iniDB и текстовых файлов - ваапще не комильфо. Думаю будет очень частое обращение к данным и все таки хочется более традиционным SQL пользоваться и реляционной моделью данных. Была идея на Redis как в эпоч, но чет тоже не туда) Старый, добрый SQL, что может быть лучше...

Сообщение отредактировал vlad333000: 21 December 2015 - 19:00

 

 

Пишу миссию используя iniDB для сохранения/чтения данных. Но понимаю, что iniDB слабовата для более менее корректной работы с большим кол-вом транзакций.

Да ладно!!!

Перед тем как решил это использовать в своём проекте делал тест драйв, всё там путём с корректностями и кол-вом транзакций, 1000 запросов, без задержки, на запись, была обработана за 1 сек.

 

ну как работает, создаеться уникальное соединение:

DBConId = str(round(random(999999)));
_result = call compile ("extDB2" callExtension format["9:ADD_DATABASE_PROTOCOL:nanmedatabase:SQL_CUSTOM_V2:%1:nanmedatabase", DBConId]);
 

(у автора мода есть стандартный пример)

а потом

DBConId  закидываются данный в базу или читаются

MY_EXT_LoadWr ={
private["_data","_query","_result"];
_data = _this;
_query = format["%1:%2:%3",0,DBConId,_data];
_result = call compile ("extDB2" callExtension _query);
(_result select 1) select 0
};

типо такого:

_playerData = format["loadPlayer:%1", _playerUID] call MY_EXT_LoadWr;

а в самом конфиге extDB2, формируеться обычны SQL запрос

[loadPlayer]
SQL1_1 = SELECT Worldspace, Inventory, Uniform, Vest, Backpack, Datestamp, Experience FROM character WHERE PlayerUID = ?
Number of Inputs = 1
SQL1_INPUTS = 1
OUTPUT = 1,2,3,4,5,6-STRING,7-STRIN

 

 

Супер, спс!

Вчера поставил exile, начал его понемногу разбирать. Картинка начинает проясняться.

dos622 вы упомянули пример от автора, не могли бы кинуть ссылку на него, поподробней бы изучить функционал с первоисточника...

Сообщение отредактировал Dupont: 22 December 2015 - 09:38

...

 

...

Ребята, да я не против того, чтобы считать iniDB с .ини файлами СУБД и возможно довольно эффективной.
 

Т.к. опыта в арма программирование крайне мало (нуб лвл), у меня и вопрос соответствующий, косвенно относящийся и к iniDB (хотя, конечно можно было и самому потестить  ):

- Как сервер Армы3 обрабатывает, ну например, событие изменения глобальной переменной (поочередно с каждого клиента или параллельно)? 

      Если  поочередно, то все хорошо.

      Если же нет, то как быть без блокировки источника данных  (если кончено iniDB не предоставляет такого инструментария)?

Сообщение отредактировал Dupont: 22 December 2015 - 10:04

Dupont, 

ну собственно первая

Пожалуйста Войдите или Зарегистрируйтесь чтобы увидеть скрытое содержание

Пожалуйста Войдите или Зарегистрируйтесь чтобы увидеть скрытое содержание

там же в релизе примеры sqf файлов есть.

Пожалуйста Войдите или Зарегистрируйтесь чтобы увидеть скрытое содержание

Кстати, как пример советю еще

Пожалуйста Войдите или Зарегистрируйтесь чтобы увидеть скрытое содержание

Dupont, 

ну собственно первая

Пожалуйста Войдите или Зарегистрируйтесь чтобы увидеть скрытое содержание

в гугле

 

Пожалуйста Войдите или Зарегистрируйтесь чтобы увидеть скрытое содержание

 единственное библиотечки от мелкомягких нужно обновить, там сылка есть6)

 

там же в релизе примеры sqf файлов есть.

 

Пожалуйста Войдите или Зарегистрируйтесь чтобы увидеть скрытое содержание

 

Кстати, как пример советю еще

Пожалуйста Войдите или Зарегистрируйтесь чтобы увидеть скрытое содержание

вариант глянуть

Благодарю!

 

Как сервер Армы3 обрабатывает, ну например, событие изменения глобальной переменной (поочередно с каждого клиента или параллельно)? 

      Если  поочередно, то все хорошо.

      Если же нет, то как быть без блокировки источника данных  (если кончено iniDB не предоставляет такого инструментария)?

Самое смешное в том, что на дворе канун 2016 года, а арма до сих пор 32 бит приложение!). Чего уж говорить о параллельно, до которого арме тоже параллельно!)

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

 

 

Как сервер Армы3 обрабатывает, ну например, событие изменения глобальной переменной (поочередно с каждого клиента или параллельно)? 

      Если  поочередно, то все хорошо.

      Если же нет, то как быть без блокировки источника данных  (если кончено iniDB не предоставляет такого инструментария)?

 

Самое смешное в том, что на дворе канун 2016 года, а арма до сих пор 32 бит приложение!). Чего уж говорить о параллельно, до которого арме тоже параллельно!)

 

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

 

Как я понял, вы запустили цикл с запросами с одного клиента. По поводу скорости обработки или корректной работы транзакции iniDB речь я вообще не вел, возможно не лучшим образом изложил мысли. Меня больше волнует актуальность данных при работе с ними, чуть больше, чем одного клиента.

Попытаюсь объяснить:

Моделируем ситуацию, когда к одному и тому же значению в базе одновременно обращаются несколько клиентов с целью редактирования его. Например клиент №1 читает значение , обрабатывает его и записывает результат в базу, но в момент обработки клиентом №1, клиент №2 тоже считал, обработал, и уже записал свой результат (по каким либо причинам №2 сделал это на порядок быстрей №1, возможно выполнив процедуру над этими данными отличной от процедуры, которую выполнял клиент №1). Получается клиент №1 проигнорировал результат полученный и записанный клиентом №2, и перезаписал его своим, т.к. входящим значением для него было значение еще не измененное клиентом №2.

Но если арма выполняет все операции из очереди, то проблем нет ваапще, такое обращение к источнику вроде как гарантирует актуальность данных.

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

Я правильно понял вас: все операции на сервере выполняются строго из сформированной очереди, последовательно и можно не париться?

Сообщение отредактировал Dupont: 23 December 2015 - 08:21

Dupont, даже если не последовательно будет исполняться, то кто мешает эту последовательность искусственно создать?
1. Клиенты отправляют запросы
2. Сервер же при получение запроса не выполняет его, а записывает в какой-нибудь массив в самый его конец
3. На сервере крутится скрипт который будет выполнять действие стоящие в начале массива, а потом удалять его из массива и т д

vlad333000, костыли? Но постойте. Со слов SteelRat:  Самое смешное в том, что на дворе канун 2016 года, а арма до сих пор 32 бит приложение!). Чего уж говорить о параллельно, до которого арме тоже параллельно!)   если я все правильно понял, из примера выше получается, что клиент №1 отработает свою функцию, в то время как клиент №2 будет ждать его.

P.S.

Проект на ранней стадии, можно без проблем выбрать другую СУБД, например MySQL с использованием WRITE LOCK. Вопрос в целесообразности этого. 

Сообщение отредактировал Dupont: 23 December 2015 - 14:23

WRITE LOCK

ну вообще ext может и лочить

а можно просто в клиенте сделать проверку, если используется данные объекта А, объектом Б. то остальных объектов слать лесом, и просить подождать, выпить пива, и расслабиться)

 

WRITE LOCK

ну вообще ext может и лочить

а можно просто в клиенте сделать проверку, если используется данные объекта А, объектом Б. то остальных объектов слать лесом, и просить подождать, выпить пива, и расслабиться )

 

Ну да, write как и read lock MySQL команда, а в сам конфиг extDB2 как я понял, можно любые команды и запросы поддерживаемые СУБД помещать. На мой взгляд правильней все же , что касается обработки данных, реализовывать на стороне самой СУБД и ее функционалом специально для данных целей заточенным, для максимальной разгрузки клиента. В идеале, если все таки остановлюсь на extDB2 и MySQL, все обработки реализую в хранимых процедурах и функциях. Пущай СУБД блокирует, клиент ждет, пока не отработает ну или , что то в этом роде ..., так надежней.

Dupont, а вам собственно зачем ждать пока какой-то левый клиент что-то вычислит? И что это за вычисление, которое требует такого времени? Ты там число ПИ собрался вычислять?

Да не Пи) Просто, если есть хоть какая та вероятность получить не актуальные данные, ее надо исключать. В своей миссии, пытаюсь реализовать некое скуднейшее подобие экономики...

Сообщение отредактировал Dupont: 23 December 2015 - 18:57

WRITE LOCK

ну вообще ext может и лочить
а можно просто в клиенте сделать проверку, если используется данные объекта А, объектом Б. то остальных объектов слать лесом, и просить подождать, выпить пива, и расслабиться )

Ну да, write как и read lock MySQL команда, а в сам конфиг extDB2 как я понял, можно любые команды и запросы поддерживаемые СУБД помещать. На мой взгляд правильней все же , что касается обработки данных, реализовывать на стороне самой базы данных и ее функционалом специально для данных целей заточенным, для максимальной разгрузки клиента. База блокирует, клиент ждет, пока не отработает ну или , что то в этом роде ...

Dupont, а вам собственно зачем ждать пока какой-то левый клиент что-то вычислит? И что это за вычисление, которое требует такого времени? Ты там число ПИ собрался вычислять?

Да не Пи) Просто если есть хоть какая та вероятность получить не актуальные данные, ее надо пресекать. В своей миссии, пытаюсь реализовать некое подобие экономики...

Сообщение отредактировал vlad333000: 23 December 2015 - 18:51

 

 

 

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

 

Думаю не будет никаких серьезных временных затрат на выполнение обработок (не те объемы баз, в мегафоне терабайты таблицы весят  ), но все же вероятность получить ошибку описанную в примере, без блокировки данных есть, хочется все по уму сделать. К тому же, вижу несколько значимых плюсов в использование MySQL сравнению iniDB:

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

- язык управления данными;

- и конечно весь инструментарий СУБД (без реализации костыльного метода средствами армочки великолепной  );

P.S.

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

Сообщение отредактировал Dupont: 23 December 2015 - 19:25