Developing an iOS/Android/WP real time game.
Server side stuff will be done in Javascript using Node.js.
It will be a trivia with 8-players rooms + an admin site made in Python with Flask (for stats, account management, adding questions… It will also provide an API to get user profiles).
Basically I will have to fetch around ~10 questions/game (I will be checking if users already answered them or not so I can avoid redundancies too).
I was wondering if my project would really benefit from a nosql db.
I have never used one but wouldn't mind learning if it is relevant.
Player data : classic account infos, score, answered questions…
Questions data : questions + translation, answers, stats (times asked, correct/wrong answers count)…
RDMS choice would be psql.
Any thoughts?
Thank you
Best Answer
The short answer is that NoSQL, NewSQL, OODB or just plain SQL are all options, but SQL is probably the most viable. Many NoSQL implementations can be configured for ACID compliance at the cost of performance/scalability, but they will most likely still scale beyond most reasonable SQL implementations. Another option is to use application sharded SQL to get scalable SQL with minimal effort/cost, and in many cases is very viable. Generally the architecture and testing is more critical than the data store, the most scalable data store may fall flat on its rear with the wrong architecture.
For a startup, getting the product out is often the primary consideration, and SQL is generally the quickest to market due to it being a known entity and experienced developers have the most experience with it. The biggest problem is usually your available resources, do they have the knowledge and experience with NoSQL? Or do you have the time to test, configure, test again?
pSQL is relatively known, its limitations are known. NoSQL has 10s of viable options, and 100s in some state of development. Finding the right one and understanding its limitations is a pretty significant project by itself. NewSQL is very new, in 3-5 years it may very well be the defacto DB for large scale projects. Any small shop should probably stay away until it gets more significant production usage by larger companies that have the resources to diagnose and work around the inevitable problems.