I’ve only ever really used PostgreSQL (as standalone server), so I can’t tell you how it compares to others; what I can tell you is that I’ve been happy with it over the years, it would be a solid choice.
If you ever want to scale stand alone is the only option i guess. imho its also one of the easiest ressource to outsource if the db is a bottleneck. sql/nosql depends usually what kind of data you want to store.
mongo/boot/rest seems a pretty common choice nowadays. dont know if its just a buzz thing or…
It’s by far the easiest clustered DB that I’ve ever set up and run. If you’re going stand-alone, I highly recommend it.
If you need more for clustering than just a shared database (real-time communication between servers, for example), you might want to take a look at Apache Ignite: https://ignite.apache.org/. You can embed it directly in your server as a library, and you can also use it with a traditional RDBMS by implementing the CacheLoader/Writer interfaces. This is the architecture we’re moving onto at MyWorld, and we may end up making much more use of Ignite’s built-in SQL capabilities.
We were using PostgreSQL back in university as it was academic.
I am currently following this tutorial
and the author using MySQL in the course, which made me give it a search and found a bunch of games like Minecraft using it as well.
For game server (note game server is separated from master server) I am using HSQLDB for persisting entity states in ES as it is used by default in ZayES. It is extremely fast because of the in-memory data load. So I thought it might be a good option for the master server as well, but I might be wrong.
On the other hand, seems MongoDB has also gained some interest.
For REST calls that return JSON, it’s hard to recommend anything but mongoDB. It’s literally a JSON based database… even the queries are JSON.
I love mongoDB for REST. 90% of the REST methods end up being stupidly trivial.
For a “real SQL database”, I’m a big fan of PostgreSQL and would never touch mySQL in a million years. Like, why have any of those limitations when postgres is right there? Postgres is a breath of fresh air from either Oracle or mySQL to me.
…but if I’m rolling a new REST service, mongo is what I reach for.
I use a combination of MySql and Apache Cayenne which is an OR mapping tool that also generates HTTP remote access client classes that you can configure to be read only. This allows the client to pull up read only data without the need for spidermonkey. Spidermonkey is reserved for entity management and positional data sync. Cayenne/MySql is also used for retrieving user created assets at runtime (For example, when users design their own ships in game).
I use several different databases for work. I have had amazing luck with postgres. Its performance is hard to beat, and the feature set is has is great. Also, it is very simple to setup. And if you need scalability, it has many options for that.
Not even close to the same thing… it totally misunderstands the fundamental level that Mongo is a JSON database.
…unless postgres lets you query subdocuments from JSON blobs using JSON and I missed it. This didn’t even work properly with XML and XPath last I tried… so I have doubts.
Edit: and don’t get me wrong, I’m a giant postgresql fanboy. It’s my favorite relational database by a long shot. But fitting it to JSON-based (proper) REST calls is a LOT (a lot a lot) more work than mongo.
I personally do not ever do this, I use mostly postgres UDTs to create object oriented databases, and map them to POJOs using pgjdbc-ng SQLData mappings when I need such functionality.
For most applications I just make normal databases and create JPA entities to map them, or even let JPA create the database.
And to re-enforce what @pspeed said, postgres does not have all the same features as mongodb, but personally, I will always choose postgres over mongo after my experiences with maintaining mongo databases. Mongo is not a relational database and should not be used as such, it is great as long as you keep that in mind.
In REST there are 4 resource archetypes:
Document, Collection, Store, and Controller
I can understand what Document, Collection and Controller resources are, also, I can see how the concept of Document and Collection in REST and MongoDB are related. But I do not understand what Store archetype is.
I read that they are client managed resources. But this does not make sense to me. Can someone please explain the Store archetype in a bit more details with an easy to understand example.
Also sorry if this is offtopic/not JME related.