www.mudconnector.su

Собственно, вопрос такой. Из возможных вариантов хранения данных видно только два. Первый -- "классический" -- использование файлов и записывание туда всех данных в каком-то своем формате (он может быть разным: циркульный файл, XML/YAML или любой другой сериалайз), а при необходимости вынимать все это из файла в память. Либо, можно подключить какую-нибудь внешнюю базу данных, которая сама будет заниматься поиском нужных объектов, записью/считыванием и прочими вещами.
По простоте работы с мне больше нравится идея БД. Можно взять MySQL, SQLite или что-нибудь еще (скулайт буду пробовать в скором времени).
Проблема безопасного сохранения дампов решается регулярными дампами кусков бд. Особенно, если разнести часто меняющуюся информацию (статсы, поинты, координаты, свойства вещей: хозяин, положение и другие, и другие) и "статику": все текстовые поля типа имен, описаний. Если предполагать комнаты абсолютно статичными, то и их тоже. Все эти постоянные величины не нужно дампить часто. Так сэкономится куча места и времени одновременно.
В сериалайзе я вижу проблему геморроя с собственным форматом (или несовместимости при работе с чужим), свой велосипед с поиском и записью. Идея о БД мне не нравится тем, что в маде количество запросов в секунду будет стремится к бесконечности (как минимум -- движение персонажей довольно часто). Думаю, это слишком большая нагрузка, чтобы дергать даже самую крутую базу.
Есть ли еще у предлагаемых решений минусы или, может, пропущенные мной плюсы?
Спасибо.

* Про дампы и их частоту отдельный разговор, просьба не заводить здесь.
* В процессе написания все-таки пришла в голову мысль о нецелесообразности использования отдельной БД в играх. Все-таки лучше иметь в памяти все данные (или активную часть, подгружать при необходимости), которые дампить и читать в каком-нибудь формате.
* Постараюсь протестировать работу мада с SQLite-ом, с MySQL-ем. Интересно, что получится. У руби есть очень простой интерфейс для работы с объектами и ДБ-ами: activerecord. Пробовать надо.

В продолжении темы 'Вопросы по серверам: очередь команд, вывод' , так как разговор
пошел о сериализации и СУБД...

Итак...






Не буду привязываться к словам, СУБД хороший вариант, но я взял и плюсы и минусы
вариантов с СУБД или без и вот что получилось:

Плюсы СУБД : Транзакции, т.е гарантированность корректности данных, при условии, что код
программы написан правильно и не будет левых запросов, достаточная простота реализации,
хотя это зависит от языка программирования, прекрасная скорость работы.
Минусы : зависимость от чужого ПО, необходимость его устанавливать, настраивать и поддерживать.
Если база портится, то она портится целиком.

Плюсы варианта без СУБД : достаточная простота реализации - сериализация в поток это стандартная задача
в программировании. Отличная скорость работы (запись потока идет чуть быстрее чем запись в БД, хотя это некритично).
Нет зависимости от стороннего ПО. Нет необходимости в поддержке этого ПО.
Минусы : нет транзакций, что означает вероятность повредить данные, в случае сбоя или неправильного кода.
Сложную расширяемость и совместимость из-за отсутствия унификации хранения данных в потоке, невозможность поддержки.

Я выбрал средний вариант стандартной сериализации с транзакциями. Это дает вариант скорости с надежностью.
В качестве уникации хранения данных я использую xml. В процессе работы используется оба варианта - для
большей части данных, которые часто меняются - сериализация, для меньшей - xml. При остановке сервера -
все данные сохраняются в xml, а файл сериализации стирается за ненадобностью. В случае проблемы,
остаются данные в файле сериализации. При необходимости - запускается движок, он читает сериализованные данные
и сохраняет их в xml. Так я побеждаю проблему с совместимости сериализованных данных.



Ломаться в процессе работы потихоньку... это как ?
А на счет поломки БД ... тут уж я все же думаю, что проблема решаема...
Как это получится у меня, покажет время

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

Думаю с СУБД скорость больше, ведь можно делать update только того, что нужно...

Да, апдейт, удаление и добавление будут быстрее работать. Меня сомневает только апдейт координат плеера со скоростью раза четыре в секунду. Но тут как с веб-сайтом, надо отделять статику от динамики, подключить кэширование и проблем быть не должно.

А что вы имеете ввиду под "портиться вся сразу"?

Транзакции нужны, в общем-то, только в одном случае: при переводе денег от А к Б. Ну или при любом перекачивании нематериальной субстанции от одного объекта к другому. В случае передачи вещей мы просто меняем owner_id у этой веши.

К сожалению практика показывает, что либо добавление быстро, либо апдейт и удаление.
И то и се, "ну никак".

Транзакции нужны к сожалению.
Вообще это большой вопрос, как лучше все организовать. В том числе зависит от реализации СУБД... к сожалению.
Выж не хотите иметь список всех вещей мада с ownerid и исправлять там ? Боюсь немного медленно будет, учитывая, что в список войдут все вещи игроков в ренте...

Редкосрабатывающий сценарий, который чтото портит может быть и в варианте с СУБД...
Сама СУБД никак не спасает от этого...



Сомнительно, что СУБД будет быстрее... В сериализации - нужно только сохранить данные подряд в один единственный файл, без какой либо подготовки этих данных... а в варианте с СУБД - 1) подготовить данные 2) сформировать запрос, 3) запустить его, 4) СУБД должна его выполнить, а это запись уже в несколько файлов - в таблицу, индексный файл и т.д. Тут нужно сравнивать на практике оба варианта... Как правило заточенные вещи под конкретную задачу работают лучше и быстрее всего.



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

я не против СУБД, но прикинув во что выливается ее использование, а что я получаю взамен, я решил от нее отказаться... я по сути получаю только один большой плюс - транзакции, но и сериализацию тоже можно сделать с поддержкой транзакций....

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

При сериалайзе достаточно сохранять только тех игроков(объекты, мобов), у которых чтото изменилось.
Сохранять всех сразу смысла нет. Используя кэширование, можно сильно сократить частоту записи на диск.
Хотя определенно,то, что приходиться сохранять целиком всего перса,- это минус, но с другой стороны это плюс. С такими данными просто работать.

А у СУБД есть другое слабое место. Если не хранить данные мира в памяти сервера, а брать только из СУБД, то это очень сильно нагрузит СУБД, и не факт что она будет успевать выполнять все запросы.
А если держать данные в памяти сервера и переодически выгружать их в базу... то тут придется следить за
синхронизацией данных в памяти и базе (у нас 2 копии одних и тех же данных). Малейшая ошибка в коде, и синхронизация нарушится, и при этом это не сразу будет заметно. Это скорее всего проявится при ретстарте сервака, когда будут закачиваться данные из базы. Т.е. база будет битой - это потерянные вещи, деньги, а то и чары и т .д . Еще неудобство в том - что этот эдакий отложенный баг будет очень
нелегко локализовать в коде программы.

В общем, стоило только начать и сразу возникла некоторая проблема.
Мне хотелось, используя СУБД, избавится от хранения какой-либо инфы в памяти самого сервера, но -- хаха -- это невозможно, так как мобы, например, должны иметь свой кусок динамической памяти для хранения своих квестов, запоминания обидчиков и т.п. Как вариант можно посмотреть в сторону загрузки объектов из БД в память, использование их и сохранение всех изменений в БД, но тогда теряется много смысла.
Остается простой, но тупой, вариант: загрузка всего (нужного/активного) в мозги серверу, создание там всяких поисков и т.п. А дампы могут происходить периодически, может, кусками. Так примерно.

Вы что, прямо так сразу планируете не писать это все на случай перезагрузки ?
Там-же и храните, где прочую информацию...