Все участники теории CAP должны работать в MMO. БД не собирается выполнять всю тяжелую работу - серверное приложение столь же важно, если не более того.
Видеоиграм требуется более быстрое время отклика, чем обеспечивает БД. Это не означает, что ИТ-инфраструктура и архитектурные работы не проводятся на всех уровнях для устранения узких мест, где это возможно, но БД является , а не единственным компонентом, отвечающим за бесперебойную работу MMO.
Большая часть работы в процессе сервера MMO, скорее всего, сначала направляется в память, а затем распределяется в БД. Вам не нужно, чтобы ваша БД имела время отклика даже 200 мс, если вы просто собираетесь кэшировать все, что вам нужно для быстрого доступа при запуске приложения. Если вы не выполняете это кэширование, то вы не будете получать 200 мс времени отклика для клиента, независимо от того, насколько быстро или агрессивно работает ваша БД. Память с правильными структурами данных просто быстрее.
При всем этом кэшировании большинство гарантий CAP становятся менее значимыми и менее важными.
Из вики-статья по теореме CAP :
... CAP часто используется для предотвращения согласованности служб, работающих в высокоэластичном первом уровне современной системы облачных вычислений. Эти службы, как правило, должны быть без сохранения состояния или поддерживать только мягкое состояние (кэшированные данные) и должны отвечать на запросы, даже если службы внутреннего уровня временно недоступны ...
Это не соответствует требованиям ММО. Процессы сервера MMO не не сохраняют состояние и не просто содержат мягкое состояние (кэшированные данные). Они будут активно предварительно кэшировать тонны мировых данных, чтобы восполнить неспособность БД обеспечить гарантии почти мгновенного времени отклика.
Примеры того, как ММО будут работать вокруг каждого из них (в основном, кеширование):
C onsistency - Вы можете легко обойти это с локальностью данных. Большинство вещей в мире MMO не будет влиять ни на что другое. Вам не нужно знать, что делает кто-то из половины галактики, не говоря уже о мобах, с которыми они сталкиваются, или о том, что они грабят. Таким образом, вам не нужна БД для ее предоставления. Таким образом, данные могут быть разделены таким образом, что согласованность между несколькими БД не имеет значения. Все, что вам нужно, чтобы оставаться последовательным (не очень много - в основном ваш персонаж / инвентарь / почта / банк / аукционный дом) может оставаться в памяти, поэтому будет иметь высокую согласованность или может пострадать на одной из двух других осей CAP.
A Доступность - Вы можете легко обойти это с агрессивным и алгоритмически инвазивным кэшированием. Некоторые данные важны, и в этом случае вы их кешируете. Другие данные не так важны, и в этом случае вам не всегда нужно, чтобы они были доступны (например, вещи, которые я упомянул в разделе «Согласованность», которые могут потерять доступность).
P artition Tolerance - вы можете легко обойтись без потери доступа к частям данных из-за кэширования. Память всегда доступна, и вы переполните ее чем-нибудь важным. Все, что не важно, чтобы всегда иметь доступ, может пострадать от потери доступа с более низким порогом боли для игроков (например, вещи, упомянутые в разделе «Согласованность»).
Таким образом, согласованность C является наиболее ценной, поскольку доступность и допуск раздела уже будут решаться с помощью сверхагрессивного и алгоритмически инвазивного кэширования. И даже в этом случае согласованность важна только для некоторых фрагментов данных.