Какая база данных для моего конкретного случая использования

Question

Моя голова взрывается от чтения о базах данных. Я понимаю, что тот, который вы выбираете, зависит от конкретного варианта использования. So is mine:

• У меня есть webapp. Игра.
• Это на основе уровня, вы можете идти только вперед. Но вы можете продолжать играть на каждом уровне. Например. Вы завершаете Level2, а затем играете Level3. Затем вы снова запустите Level3 и сохраните его как Level3b. Теперь вы можете продолжить работу с Level3 и Level3b.
• Только один уровень может быть воспроизведен в любое время.
• Три массива данных хранятся на сервере: «прогресс», «выбор» и «варны»
• Они изменены, когда вы играете на уровне, а затем помещаете в холодное хранилище, когда можете начать с них ,

установки MySQL на данный момент реализована такая:

• таблица «сохраняет» хранит метаданные для каждого сохранений, что особенно важно в saveID и идента он принадлежит.
• Каждый из массивов данных имеет соответствующую таблицу.

• Если игрок делает выбор, вставка выглядит следующим образом:

  INSERT INTO choices VALUES saveid=:saveid, choice=:choice 
  

• Таким образом, массив может быть восстановлен, делая

  SELECT * FROM choices WHERE saveid=:saveid 
  

• Когда уровень закончен, массивы данных помещаются в холодное хранилище, сериализуя их и сохраняя их в таблице «saves», которая имеет 3 столбца, посвященные этому.
• Их значения очищаются от трех других таблиц.
• Если игрок начинает уровень 4 с уровня 3b, сериализованные массивы извлекаются из таблицы «saves», несериализуются и помещаются обратно в соответствующие таблицы, хотя и с новым значком saveID уровня 4.

Я надеюсь, что это несколько понятно. Я считаю, что:

• Там будет много больше, чем пишет читает
• мне не нужна консистенция, если я понимаю, что правильно, так как игроки могут только когда-либо управлять своими собственными данными
• Я не» я думаю, что буду делать (m) любые JOINS, так как каждая таблица должна быть прочитана индивидуально, чтобы заполнить свой соответствующий массив данных.
• Так что я не думаю, что мне будет очень нужно на пути реляционной базы данных

• Должна быть действительно легкая нагрузка для БД большей частью w ay, так как вставки небольшие

• Datastorage должен быть надежным! Я не думаю, что игроки будут придерживаться нас, если мы начнем регулярно проигрывать свои savegames. Хотя я думаю, что Redis для флеша на диск каждую секунду будет достаточно, так как здесь мы не имеем дело с критически важным материалом. Если игра забудет последнее действие или два игрока, это не так, просто не забудьте полностью сохранить игру.

Можете ли вы дать мне совет по БД для моего прецедента? Я начал с MySQL, теперь я читал о CouchDB, MongoDB, Riak, Cassandra. Я думаю, что у Редиса нет картины, так как этот, кажется, плохо ухудшается, когда набор данных перерастает вашу оперативную память. Но я открыт для всего. Я также открыт для людей, говорящих: придерживайтесь MySQL или goto PostgreSQL.

И я также буду принимать критику в отношении того, как я настроил хранилище. Если вы скажете: выберите Кассандру и сохраните ее так, я буду слушать.

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

О да, приложение написано на Javascript, связь с сервером осуществляется через PHP.

Answer 1

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

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