**Disclaimer... I've never worked on a MMORPG.**
MySQL / SQL in general is waning in usage in the game industry from what I gather.
I have been spending a fair amount of time getting up to speed on modern server programming / containers. I'm just going to throw out thoughts as things are likely very dependent on the type of data that needs to be saved and amount of read vs write concerns when it comes to choice of particular solutions and accompanying trade-offs.
First off these days everything should be done with containers (Docker / rkt, etc.) and some sort of orchestration platform (I've chosen Kubernetes as there is a lot of momentum). I'd like to use rkt, but it's a bit light on tooling still as it's more framework than platform like Docker. Self hosted in the cloud or one could use Google Container Engine
and other services of this nature.
If you're going Java on the server side two architectures worth looking at are Scala / Akka
/ actors (probably light on tooling for MMO applications) and the other I'd look at is Aeron
. If using Aeron I'd also combine that with the Disruptor
. Between Akka or Aeron / Disruptor the goal is to setup pipelines that are event driven. You might for instance use an in memory DB for some things, but to make sure things can be brought back from some failure you'd also journal / save all of the events flowing through the system, so that state can be rebuilt from periodic snapshots (also useful for debugging). Periodically (say twice a minute) for character players the current state of the in memory DB would be punted out likely over the wire to another container / DB for longer term storage or perhaps Amazon S3 or other cloud storage. Perhaps there is no in memory DB at all though I'd gather all of the really big MMOs have some sort of in memory DB as part of the pipeline. For DBs in general I'd look at Riak
, but there are many options here. For high throughput everything stays as a binary blob; IE JSON / strings or XML is not desirable in high throughput pipelines, but in others it's fine. I gather in general there is some NoSQL going on for quite a bit of the data modeling / storage though I wouldn't be surprised if Blizzard or any other large game company rolls there own DB versus using off the shelf options. Here is a blog article on Pokemon Go
that indicates Couchbase was used for certain parts of the architecture. From there I suppose it really depends on what your game back-end has to do. Perhaps Apache Spark
is involved at some point for data analytics. No matter what though analytics at some level needs to be involved to detect problems, scaling issues, and any failures.
I'm sure you've heard about microservices
. I guess the nice thing or the bane for documentation / maintenance is theoretically any particular one could be the best stack for the problem at hand including choice of language / DB which would only store the data specific to the microservice (say lobbies / chatting for a game / or user profiles). Instead of a more monolithic server things are broken down as separate stacks for very particular and limited purposes.
I'd suggest looking up articles on Pokemon Go architecture for a game that had to scale rather quickly. There should be plenty out there.