Какую базу данных в отношении теоремы о кепке следует использовать для mmo?

Question

Предположим, что mmo создавалось с возможностью просмотра от первого лица, с одним миром, в котором все играют (например, в канун онлайн), и игрой в песочницу. Какая база данных лучше всего подойдет в терминах теоремы о пределе? CA, AP, CP и почему?

Answer 1

Все участники теории CAP должны работать в MMO. БД не собирается выполнять всю тяжелую работу - серверное приложение столь же важно, если не более того.

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

Большая часть работы в процессе сервера MMO, скорее всего, сначала выделяется из памяти, а затем распределяется в БД. Вам не нужно, чтобы ваша БД имела время отклика даже 200 мс, если вы собираетесь кэшировать все, что вам нужно для быстрого доступа при запуске приложения. Если вы не выполните это кэширование, то вы не получите 200 мс времени отклика для клиента, независимо от того, насколько быстрым или агрессивным является ваша БД. Память с правильными структурами данных просто быстрее.

При всем этом кэшировании большинство гарантий CAP становятся менее значимыми и менее важными.

Из вики-статьи о теореме CAP:

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

Это не соответствует требованиям ММО. Процессы MMO-сервера не являются объектами без сохранения состояния и не содержат просто soft-state (кэшированные данные). Они будут активно предварительно кэшировать тонны мировых данных, чтобы восполнить неспособность БД обеспечить гарантии почти мгновенного времени отклика.

Примеры того, как ММО будут работать вокруг каждого из них (в основном, кэширование):

• Cсогласованность - вы можете легко обойти это с локальностью данных. Большинство вещей в мире MMO не повлияет ни на что другое. Вам не нужно знать, что делает кто-то из половины галактики, не говоря уже о мобах, с которыми они сталкиваются, или о том, что они грабят. Таким образом, вам не нужна БД для ее предоставления. Таким образом, данные могут быть разделены таким образом, что согласованность между несколькими БД не имеет значения. Все, что вам нужно, чтобы оставаться последовательным (не очень много - в основном ваш персонаж / инвентарь / почта / банк / аукционный дом) может оставаться в памяти, поэтому будет иметь высокую согласованность или может пострадать на одной из двух других осей CAP.

• AДоступность - Вы можете легко обойти это с агрессивным и алгоритмически инвазивным кэшированием. Некоторые данные важны, и в этом случае вы их кешируете. Другие данные не так важны, и в этом случае вам не всегда нужно, чтобы они были доступны (например, вещи, которые я упоминал в разделе "Согласованность", которые могут потерять доступность).

• Partition Tolerance - вы можете легко обойтись без потери доступа к частям данных из-за кэширования. Память всегда доступна, и вы переполните ее чем-нибудь важным. Все, что не важно, чтобы всегда иметь доступ, может пострадать от потери доступа с более низким порогом боли для игроков (например, вещи, упомянутые в разделе "Согласованность").

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