Я работаю над многопользовательской игрой в реальном времени, для которой потребуется база данных (для таких функций, как профили игроков, друзья, разблокировка, новости и т. Д.). Это стандартная игра для ПК (не на основе браузера), в которой будет использоваться клиент-сервер. архитектура. Я новичок в использовании баз данных и провел несколько исследований за последние несколько дней, когда наткнулся на горячие дебаты: RDBMS vs NoSQL. В настоящее время я склоняюсь к NoSQL, но после прочтения об использовании для каждого (RDBMS и NoSQL), я испытываю желание использовать оба. Я знаю, что это может показаться странным, но позвольте мне объяснить мою ситуацию:
У моей команды есть общий пакет веб-хостинга, который предлагает неограниченное хранилище mySQL и пропускную способность, единственное предостережение в том, что мы можем открыть только 25 соединений одновременно (правило общего хостинга). Я собираюсь использовать это для своего веб-сайта (типичное использование, без сомнения), чтобы публиковать новости, поддерживать функции сообщества (например, комментарии, загружать фан-арт и т. Д.) И тому подобное. Это все хорошо и хорошо - но! это то, где все становится интересным ... Я хочу показать ту же информацию, которая размещена на моем сайте, в игре. Это означает использование mySQL как для моего сайта, так и для моей игры. В дополнение к новостным сообщениям и тому подобному я планирую использовать его в игре для таких вещей, как чат и список серверов. Меня больше всего беспокоит это правило 25 соединений.
Что заставляет меня задать вопрос № 1: будет ли это работать и есть ли лучшая альтернатива?
Теперь, кроме этого, я прочитал о том, насколько хорошо NoSQL работает и подходит для игр в реальном времени (я могу ошибаться, я прошел через огромную войну RDBMS против NoSQL, чтобы попасть сюда и, вероятно, сгорел). По сути, я хотел бы использовать MongoDB для всех моих данных игровых объектов.
И снова, будет полезно, если я предоставлю некоторый контекст: я нашел хост (MongoLab), который предлагает бесплатный пакет MongoDB на 240 МБ, который я собираюсь использовать до тех пор, пока не понадобится обновление. Учитывая 240 МБ, я рассчитал, что смогу хранить примерно 60 000 игроков (если каждый игрок имеет примерно 4 КБ, и мы игнорируем другие вещи, которые могут быть сохранены). Место для хранения и необходимость платить больше в будущем (если наша игра будет успешной) не является проблемой. Единственная причина, по которой я сейчас собираюсь использовать MongoDB для всех моих данных игровых объектов, заключается в том, как часто к этим данным игровых объектов будут обращаться (например, когда игрок убит, берет предмет, стреляет из пистолета и т. Д.), Я также как прямые документы без схемы (которые упрощают отображение данных игровых объектов). Я должен отметить, что когда-то
Я намерен использовать тот же MongoDB на своем веб-сайте для отображения информации профиля игрока (меня не интересует полная согласованность, некоторая задержка с обновлениями в игре - это нормально). Что приводит меня ко второму вопросу, Вопрос № 2: это хорошая идея или есть что-то лучшее, что я должен сделать?
У игры будет опыт запуска, подобный этому:
- Клиент входит в систему (MongoDB)
- Клиент находится на домашней странице игры с чатами (MySQL)
- Клиент идет в список серверов (MySQL)
Клиент подключается к серверу и играет на нем
Сервер передает обновления для всех игроков (MongoDB)
Это просто способ, которым я представлял, что это будет работать. Вам это нравится, или у вас есть предложения по улучшению этого плана?
Ответы:
Я предлагаю, чтобы ваша игра связывалась с созданным вами веб-сервисом, который сам занимается запросом к базе данных. В этот момент очень просто попробовать разные типы баз данных, «переключив» реализации веб-сервисов (интерфейс вашего веб-сервиса всегда остается неизменным, чтобы ваша игра не ломалась), и решить, какая из них вам подходит.
Также намного безопаснее не выставлять свою базу данных напрямую в Интернет.
источник
Этого более чем достаточно для вашей игры. Проблема в том, что если ваш сайт использует несколько подключений, вы можете исчерпать. Вам необходимо настроить свой веб-сервер так, чтобы он использовал только небольшое их количество, а остальное оставалось для игрового сервера. Вашему игровому серверу на самом деле не нужно более одного соединения, но может быть полезно иметь несколько.
Это немного ложный аргумент, потому что ни одна из систем не является достаточно быстрой, чтобы использовать ее в качестве основного хранилища для динамичной игры в реальном времени - вам действительно нужно хранить значения в памяти и манипулировать ими. Таким образом, вы попадаете в базу данных только тогда, когда это абсолютно необходимо, что может быть связано с тем, чтобы сохранять весь символ время от времени (например, раз в минуту), после чего различия в скорости становятся незначительными.
Самое смешное, что, если вы настроите MongoDB для максимальной скорости, вы можете просто довести его до уровня, при котором он будет достаточно быстрым для выполнения синхронных записей из достаточно динамичной игры, но это будет стоить целостности данных, потому что записи буферизируются. Это означает, что вы теряете эти данные в случае сбоя, поэтому было мало смысла выполнять запись вообще, и это все еще медленнее, чем если бы вы просто выполнили редактирование в памяти и сохранили его позже, так что вы получите худшее из обоих миров ,
Спросите себя, зачем вам нужно писать в базу данных, когда игрок стреляет из пистолета. Почему это не может быть обработано в памяти на игровом сервере? Если ваша игра вылетает, а затем перезапускается, и игрок узнает, что у него на 3 пули больше, чем он ожидал, это критическая проблема для бизнеса?
Это гораздо лучшая причина для выбора подхода NOSQL, чем проблема производительности.
Это хорошо и разумно. Позже вы, возможно, захотите использовать отдельный экземпляр, чтобы чтение по сети не конкурировало с чтением и записью игры, но эту проблему решить тривиально по сравнению с проблемой становления достаточно популярной, чтобы это стало проблемой.
Лично я бы просто выбрал одну из двух баз данных, на основе которой одна из них была бы для меня менее полезной, и стандартизировал бы ее, но нет никаких причин, по которым вы не можете использовать две, если хотите.
источник
Все данные в реальном времени должны храниться в памяти приложения, все остальное было бы глупо.
Хранение данных для входа в систему, статистика и т. Д. Является довольно легкой задачей, поэтому я буду смелым и скажу, что вы можете использовать практически все, что захотите. Хотя вы, возможно, захотите быть осторожными с веб-сайтом, такие вещи, как списки пользователей, могут снизить производительность базы данных, если вы не создадите правильную систему кэширования.
И, как сказал Буммзак, вы должны хранить все в одной сети. Вдобавок ко всему, остерегайтесь бесплатных вещей, 240 МБ свободного места для хранения базы данных звучат хорошо, но, поскольку машина, вероятно, разделена между большим количеством бесплатных пользователей, обслуживание может быть довольно медленным.
источник
Вы доверяете своим 60 000 пользователей на базу данных? Если нет, вам следует отказаться от идеи «доступ к базе данных из клиента», если только ваш уровень знаний в области безопасности программного обеспечения для баз данных не является первоклассным, и вы не уверены, что сможете решить любые возникающие проблемы.
источник