My company uses a NoSQL database (Mongo) for their product. However, their product is incredibly slow - which might be due to either the efficiency of their code, or/and the design of their database. While I wasn't hired as a dev or sysadmin, and am no expert in DB design, I find the latter super interesting and thought it'd be interesting to see how valid or invalid my opinions on their db design are.
The main things that caught my eye are the following:
The database has quite a few different collections. Basically, every kind of different existing "object" in our system has a collection (more or less). To me, this seems very much similar to a SQL-style database, where you only save links between objects and then query from multiple tables at once. However, I thought the benefit of NoSQL was that the more unstructured, all-data-in-one-collection approach would allow for faster query times at the expense of having a kind of messy structure. To come up with a random example: Let's say you had bank accounts in an app, and could have transactions between accounts. SQL-style, for me, would be having two separate tables, one for the accounts and one for the transactions. NoSQL style, I thought, would instead put the relevant transactions directly underneath the appropriate account collection. The actual objects and structures in our codebase are far more complex so I understand the need for more collections, but I was just thinking that perhaps it is too many.
In addition to having separate collections, we seem to be doing a lot of separate queries on those collections, even when they are semantically linked together. Am I right in my assumption that this procedure would be slower than an imitated join request?
More of a general question: The codebase is WAY too big for me to actually get a complete understanding of our systems, especially since I'm not even in a dev role, but are there any things I could do to quickly see where queries might be structured badly?
We have multiple DB servers, one of which is the master, and the other ones replicating the master in order to be a backup in case of failure. We also have tons of copies of our system accessing those same databases (Well, technically different databases, but they are running on the same server). This, at times, creates a ton of simultaneous connections. Wouldn't it be better to split up "which database is the master" between systems, and do the copying of data when load is low? So, for example, let's assume I have 3 DB servers and 3 system instances. At the moment, the 3 systems all access the same master DB, which gets replicated on the two other nodes. Wouldn't it be better to designate one DB server per system as master, so that the connections are split up between servers?
I know that my questions are quite vague, but like I said, the topics interest me although I don't have the means to add a ton of detail to my questions.
