Какая СУБД достаточно быстра для онлайн-игры (несколько тысяч игроков)? [закрыто]

В настоящее время я делаю MMORPG-игру, в которой одновременно могут участвовать несколько тысяч игроков (вероятно, нет; просто желаемое за действительное). Сначала мы хотели использовать MySQL, но я слышал, что он недостаточно быстр для такого масштаба.

Какая СУБД достаточно быстрая? Насколько он похож на SQL Server (как я изучил SQL Server в школе)?

Это действительно сложный вопрос. Вы можете взять самую быструю платформу баз данных в мире, разработать ужасную схему, написать дурацкое приложение вокруг нее, а затем испытать искушение обвинить платформу баз данных. В то же время вы можете воспользоваться бесплатным SQL Server Express и, с правильным дизайном, логикой приложения и подходом к разумной масштабируемости (например, масштабирование операций чтения с помощью кэширования данных и т. Д.), Вы можете написать приложение, которое обрабатывает тысячи У пользователей нет проблем.

Верю ли я, что SQL Server может обслуживать тысячи пользователей? Абсолютно. Верю ли я, что Oracle и DB2 могут это сделать? Безусловно. MySQL? Не уверен, не хватает опыта там. Доступ? Вероятно, не мудрый выбор вообще. Если вы знакомы с SQL Server, то я полагаю, что вы выбираете именно этот путь, просто имейте в виду, что ваш выбор СУБД сам по себе не будет определять успех или неудачу.

Позвольте мне сказать это так, помните GameSpy Arcade начала / середины 2000-х годов? Он запускал тысячи игр, и все они работали на SQL Server и поддерживали десятки тысяч пользователей одновременно (да, у нас было несколько SQL-серверов, выполнявших различные операции). Это все о дизайне базы данных и о том, как вы используете систему. Сделайте это правильно, и ваш проект будет успешным, сделайте это неправильно, и ваш проект потерпит неудачу.

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

Так получилось, что кто-то задал этот вопрос для конкретной платформы в StackOverflow около 1,5 лет назад.

Будь то MySQL, SQL Server, Oracle, PostgreSQL или какая-либо другая СУБД, вы должны быть очень креативны с инфраструктурой базы данных. Если у вас есть открытая чековая книжка для аппаратного обеспечения и промышленная СУБД, Oracle для вас (если так, Oracle RAC будет более желательным). Если вы разрабатываете с использованием IIS и среды Microsoft, то это SQL Server. Если у вас есть проблемы с бюджетом и вам нужен внешний вид Oracle, выручите PostgreSQL. Если у вас есть бюджетные проблемы, живое воображение и вы хотите микроуправлять Storage Engine по своему вкусу, чтобы обеспечить соответствие требованиям ACID, высокоскоростное чтение и различные архитектуры репликации, я бы с вредом сказал, что MySQL.

СУБД должна быть наименьшей из ваших забот с MMORPG. Проблемы программирования всегда представляют большую рыбу для жарки. Итак, примите решение разумно и разумно, потому что какую бы СУБД вы ни выбрали, вам придется с этим жить (так же, как FaceBook должен жить с MySQL ).

Это не правильный вопрос. Производительность вашей игры будет зависеть от выбранной вами архитектуры и стека технологий, а также от того, как она реализована. СУБД является лишь одним из компонентов стека. Я бы рискнул предположить, что СУБД вряд ли будет ограничивать производительность, если вы не очень плохо разбираетесь в архитектуре. Уровень вашего домена, кеширование и то, как вы распределяете и масштабируете сайт, скорее всего, будут более важными проблемами.

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

Я думаю, у вас есть два вопроса в одном. Во-первых, «какие СУБД способны эффективно сохранять игровые данные». (субъективно, imho) Второй: «Как мне масштабировать эту СУБД для работы с тысячами пользователей?»

Многие онлайн-сервисы нашли комбинацию MySQL и Memcached, чтобы обеспечить отличную производительность и масштаб. Однако наступает момент, когда это решение тоже падает. Тем не менее, это может быть именно то, что вам нужно.

Все больше и больше онлайн-сервисов внедряют решения NoSQL в свою архитектуру. У меня есть некоторый опыт работы с CouchBase, и я считаю его полезным.

Код, дизайн и ваши диски (для записи) определяют производительность в целом. Не платформа.

Вы могли бы взглянуть на CUBRID . Это СУБД с открытым исходным кодом, которая сейчас очень популярна в Южной Корее. Предполагается, что он работает лучше всего / очень быстро для веб-приложений с большим количеством пользователей (говорят, 50k или что-то в этом роде).

Я думаю, что любая из основных баз данных может справиться с нагрузкой, если хорошо спроектирована. К сожалению, я бы оценил, что менее 1% всех баз данных спроектированы хорошо. (Я лично имел дело с данными из буквально тысяч различных баз данных, выполняющих широкий спектр функций, поэтому я думаю, что у меня есть хорошее представление о нехватке качества, существующей в реальном мире.)

Я настоятельно рекомендую вам приобрести несколько книг по настройке производительности для выбранной вами базы данных и внимательно прочитать их, прежде чем приступить к разработке. Есть много вещей, которые помогут вашей базе данных работать лучше, которые должны быть разработаны с самого начала. Знание того, как писать производительные запросы и индексы дизайна, имеет решающее значение для получения хорошего дизайна. Этот тип обучения и заданная производительность не являются преждевременной оптимизацией. Нет никакой причины использовать известные методы убийства производительности в дизайне. Базы данных должны быть спроектированы для обеспечения производительности с самого начала.

У нас есть мобильные игры с тысячами игроков, и мы увидели огромное падение нагрузки, перейдя к постоянным пулам соединений IIS / .NET mysql. MySQL 5.1

Подумайте о том, чтобы хранить данные «только для записи» где-то еще, чтобы уменьшить нагрузку на любую выбранную вами базу данных Cassandra или даже системный журнал. Подумайте о том, как сохранить быстро изменяющиеся, быстро меняющиеся, но восстанавливаемые данные в таких файлах, как memcache, riak и т. Д.