CODEWITHSUNDEEP
c#sqlsql-servermongodbdatabase
Shaul Zuarets
Shaul Zuarets

Reputation: 849

How to model data using MongoDB

We have a relative large scale application that uses relational DB (MSSQL). After a lot of reading I've decided that I want to examine using MongoDB and not MSSQL, mainly because performance and scale issues.

I read and study about Mongo and couldn't figure out the answer for the following questions:

  1. Should we do it? Bare in mind we have the time to invest, the only question is "is it good for us?"
  2. How to model our data?

My problem with mongo is that we have a lot of one to many relations in our DB. After reading this great post (and the second part as well), I've realized a good practice will be to divide the decision into 3 scenarios:

  1. 1 to few
  2. 1 to many
  3. 1 to squillions.

In our db, most of the times we use one-to-many, but the problem is that most of the times it's the same "one".

For example, we have users and transactions tables. Each user can perform a transaction, so basically what I should do is to model the user as following:

{ "name": "John", ..., "Transactions" : [ObjectId("..."), ObjectId("..."),...] }

So far it's fine, the problem is that we have a lot more than just transactions, for example we could have: posts, requests and many more features like transactions, and then, my users collection becomes huge (more then 25 "columns"). And also when I want to retrieve a data set I have to do several queries unlike MSSQL in which I'm just using Join statement.

Another issue is that I'll have to save a lot of extra data, for example, for each transaction I have to save the terminal ID, and in the report I'll have to show the terminal name, in that case (as for my understanding) I have 2 choices, the one is to do 2 queries and the other is to save the terminal name as well. In relational DB this is a simple join.

So maybe for schemes like ours, Mongo(or any other document based DB) is not the best choice?

Thanks in advance!

Upvotes: 3

Views: 809

Answers (1)

Vasyl Zvarydchuk
Vasyl Zvarydchuk

Reputation: 3839

You can face with some serious issues while modeling your data with 2 and 3 approaches:

  1. For One to many you may face with data inconsistency or/and eventual consistency. Here, you store inside document an index (array of references) to external documents. So, for your example to add a new transaction you need two requests: create a transaction and add its reference to a user (update document). Mongo DB has ACID transactions only on document level, so for your case application for some reason can create a transaction but doesn’t add its reference to user. It can be app failures, network problems, bugs and so on. Of course, you can simulate db transaction in app with try/catch block making data cleanup when an error occurs. It will help but not in fully because app can fall down between requests. So, if your app is high loaded after some time you can have some number of “dad” transactions which are not linked to any user. It couldn’t be a big problem if your app doesn’t query transactions directly – only via users, you will have only useless data in db. Otherwise you will have data inconsistency. To fix that you need to create background job which will make proper cleanup. So, some period of time your data can be inconsistent – eventual consistency. For some applications, it can be ok, for another – not. The same problem you can face while deleting transactions. I agree, that a document with 25 arrays of references (columns) looks not very good. Working with such objects manually will be harder (testing, manual data fixes and so on.

  2. One to squillions doesn’t have this affect but you need indexes to query efficiently. For large and shared db you can have bad performance.

In general, I’d like to say document dbs are pretty good if your app works mostly with one document (aggregate) and don’t have a lot of references to another docs and you don’t need transactions between docs. Denormalization can also be a source of inconsistency.

Key-value data is very easy to scale. Document dbs – it’s one step closer to key-value data-store. Column-oriented dbs are even more closed to key-value and so they can be scaled even better.

Also, I recommend you to consider the next measures to improve your SQL Server db performance:

  1. Caching – perhaps you can cache some your app aggregates instead of gathering (making joins) them in SQL db all the time. For instance, Stack Overflow uses SQL Server db and Redis for caching aggregates (questions with answers, comments and so on).

  2. Tune query performance within indexes, db structure, demoralization and so on.

  3. If your db is hosted in on premise SQL Server then additional memory, SSD disk, table partitioning, data compressions, replication can help. As a rule, SQL Server gives a good performance with these approaches for dbs up to 1 TB.

  4. CQRS approach.

  5. Consider storing your app data in different databases. Every type of dbs has its own strong and weak sides. Document DB is good for storing aggregates, SQL db – for relational data and so on. Complex apps as a rule use a few db types.

Upvotes: 2

Related Questions