After all, which one is better NoSQL or SQL? Which is more performative? Which paradigm should I use in my high-performance application? If you have these questions in mind this article is for you, but I can already anticipate that the answer is well known by programmers in general, the famous “It Depends”.
Before any decision, first and foremost I need to analyze the strengths and weaknesses of both sides, and in which use cases each solution fits better. As it is impossible to cover every part of this discussion in high-performance solutions, I will take into account that we are speaking of applications such as multiplayer games (MMO), stock exchange and banks.
Its main advantage for sure is the structuring of the data in the well-known tables, which contains a series of rules and restrictions for each column, being an immense facility in large projects. Apart from this, we can also take into consideration the infamous indexes that are usually forgotten by the developers, but play a key role in the database performance. Indexes are the difference between having a functional database or not. High performance is practically impossible without them, but that’s up for another article.
Whoever has never had problems with ALTER TABLES cast the first stone. This is exactly the biggest “negative” point of a SQL database which, because it contains a series of rules, makes it difficult to change existing databases, making it troublesome to maintain the software.
In NoSQL databases, documents and Blobs (Binary Large Object) are orchestrated with mastery, as this is exactly the exemption of this type of database, which makes them perfect for storing Serialized Game World State, Blobs, etc.
For the sake of better segregation, I will separate the NoSQL databases into 2 families: those of optional structure, and the unstructured ones, because they are totally different types of data storage and have even more distinct use cases.
Optional structured databases
Common examples of optional structure databases would be MongoDB and Cassandra, that just like SQL databases also use indexes and have a search system very similar to SQL, which allows searches in “fields”.
In this type of database, it is possible to create a partial structuring of the files. Partial because it is not guaranteed by the database that this structure will be maintained. MongoDB, for example, stores BJSON, a kind of JSON with a special handling for performance improvements made by the databases itself, giving the developer a freedom to create and delete fields without having to change the structure of a schema, which can lead to a lot of foreign data lost by the database (it’s more common than you think), bearing this in mind, this ends up being a positive or negative point, it all depends on where this technology will be used.
Very well known in the industry as key and value databases, such as Redis – a very popular database-, excellent for caching uses and can maintain the mastery of file manipulation and Blobs of NoSQL databases.
But as life is not always a bed of roses, unstructured databases have some natural disadvantages compared to others. For example, the queries are totally simplified, making the search only possible for a specific key, or perhaps a range, but nothing more elaborate than this.
Much of this discussion about NoSQL and SQL reminds me of the old discussion between strongly typed and weakly typed languages, since both discussions have the same principles, more security at the development or more freedom to allow faster development, and the two discussions are converging on “it depends”.
For a complete explanation, I will give my opinions taking into consideration some examples of using high-performance solutions.
For extreme-risk data storage, such as values on a stock exchange, for example, you would need data consistency to ensure data integrity, and in this respect, the big winner for sure remains SQL databases.
Taking into account also that for this system has some analytics, reporting or some other function that requires much of the database, it is clear that a read-only copy of the database will be necessary to relieve the stress of the main database and consequently not degrade the performance of the database.
Game World State / Archives
Game World State is nothing more than big Blobs, and if you’re paying attention up till here, that is the specialty of NoSQL databases, which creates a perfect environment for this type of solution, and the same is true for documents in general.
Therefore, this is my only indication for NoSQL databases, because the lack of structure could end up compromising critical system data, which would eventually lead to more development team wear, having mores needs into creating rules that already exist in a SQL database to bypass the lack of databases structure, and so wasting time and energy that could easily be undertaken in more important implementations.