How to MongoDB

Databases: Difference between Relational Database, NoSQL database, and Columnar database

You might have heard about these terms, but you might be wondering what is the difference between these 3 types of databases. I’ll try to explain my understanding of each and when to use them.

Relational Database

Relational database is such database that stores related data. For example, you own a show and keep a record about your clients and items they bought. We can draw two tables one that stores Users and second one stores Items. So, to store transactions we logically draw relationship between these 2 unrelated data. That’s why RDBMS is called relational database, because there is certain relationship between separate pieces of information. Example of relational databases are: MySQL, PostgreSQL, Oracle Database and so on. When you put data into this kind of database, you will need to plan relationship between the data before using database.

Ex of Relational data:

Relational Database Design

NoSQL database

NoSQL database is complete opposite of Relational Database. This kind of database allows you to simply put the data that you want to store. This is quite useful in this cases:

  1. You are rapidly developing your app. The beauty of NoSQL is that you don’t need to spend time about all the relationships between data that you want to store. You just simply store your data.
  2. When you primarily want to store data. For example, you have some sensor data and you want to store it.

Above two are the ones comes to my mind. There should be other uses too. Examples of NoSQL database is MongoDB and Cassandra. The difference between the two is that MongoDB is document based, meaning it stored objects as documents. Document here is some sort of logical representation of data. MongoDB uses JSON to store data. Casandra however, just stores key and value pair.

Ex of NoSQL data:

Columnar Database

Columnar database stores all the data as a sequence of data points. This is quite useful to perform aggregation operations such as summing. Since the data is stored sequentially, it’s easier for db to perform operations, because it doesn’t have to scan the rows of data like in a relational database, it just needs to read data by knowing it’s offset. Some of the example of columnar database is AWS Redshift

Ex of columnar data:

So here we go, the only difference between these 3 database types is the way how they store data. Of course, each of them have their own usages, so using one over another gives some benefits.


Note to self: the importance of choosing a correct tech stack

Recently, I decided to use embedded MongoDB instead of using H2 SQL based in-memory database for my personal pet project . However, migration was not as easy as expected.

Initially, I thought that I just need to comment out the dependencies for the H2 and include MongoDB. However, turns out that I was wrong. H2 currently, tightly coupled with the code, and effort to change to MongoDB is larger.

Lessons learned: proper planning has to be done before development starts. Familiarity with the tech does not guarantee the best result, however, proper planning and tech selection give a better result. After all, tech can be learned along the development process especially if the project is small.


Why .(dot) is a bad idea for key name in mongodb

I find that I like mongodb. In my student years, I had trouble understanding why RDBMS are structured the way they are structured. And why you can’t just save whatever the data we want to save? In RDBMS we always had to design everything before hand. While designing databases is good, sometimes it’s difficult to move forward because you are tied to specific design. However, mongodb is not like that. You can always just save the document the way it is. Actually, what happens in reality it really accelerates development, because db is just on less worry now, when using mongodb. I’ve decided that I will be sharing some interesting things that I find about mongodb.

The first thing that I’d like to share about mongodb is that don’t use .(dot) as your key name!

The reason is that .(dot) will create subdocuments!

So, imagine that you want to save this id:

What happens when you pass that id, mongodb will save it apac being it’s root, id it’s child and 123 child of id!

Same goes for the $ sign.


What are the advantages of constructor autowiring over normal autowiring or property autowiring?

Constructor autowiring has advantages in that you can make the wired in fields final (particularly useful if your bean will be called from multiple threads as threadsafety is easier to analyse with finals). And you can ensure that the bean is always constructed in a valid way (although you can always implement InitializingBean and use the afterPropertiesSet method to achieve the same if you’re wiring in properties).

One of them is that when testing, doing a mock over a constructor is easy, but over properties it’s a little bit hard

ule of thumb: stick to constructor injection. Why? A constructor specifies the required dependencies of the class being instantiated. With setter/field injection on the other hand, you always have to look them up (by looking at the source code). You may run into troubles (eg NPE’s) because an instance misses some required dependencies. Have a look at

How to

How to delete nested object from MongoDB collection

Sometimes, we write data into our mongodb collection by accident.

I can share interesting case that happened not so long ago.

My colleague passed id that has .(dot) in it to my API. Then on the backend mongodb saved the id. But when it saved the id, because of the dot, it got saved in the nested way. Ex: GET /api/bar?

So, this is what I can see in the database:




Meanwhile other records are just stored like 456, or 555 or 123. Means as a single entry.

And this is an issue, because when we try to retrieve the data, nested object cannot be properly mapped back to model that I pass to fronted. The whole controller stops working, because of one invalid record that fails to be mapped properly.

That’s why you should:

  1. Validate the id
  2. Or clean up the id

So, in order to make the API work again, I needed to delete the invalid record from DB. This is how it can be done from mongodb terminal

db.getCollection('a.bcd').update({foo:"bar",_id:ObjectId("XXX")},{$unset:{"":""}},{ multi: true })

Note that your collection can be sharded, so you need to specify, your shard key in the first part of the update. For example, in my case shard key is foo.

The code above will delete the xyz

Hope, this saves time for someone and will be useful.

So, the lesson is, always validate the inputs )

Git GitHub How to

Git Rebase

Rebase is useful when you want to get the latest changes from the master branch into your branch. The benefit is that you will save time when merge into the master branch and you can use latest code added by your team mate.

To do rebase:

git checkout master
git pull

git checkout feature_branch
git rebase master
git push -f


Profile page in React

Finally, profile page is more or less complete. Moved from JSP and JavaScript to pure React.

New profile page is available here:

I’ve noticed that once the terminal is closed the app will stop too. So to prevent app from stopping start with this command:

nohup npm start > output.log &


Move findmydoctor’s front end to react

it’s time re-develop front end of my app at to use React instead of JSP.

Jsp, tiles and handlebars provides cool templates. But React has more appealing component approach that I find more flexible.

Not sure how long it will take to move whole ui, but this move seems meaningful move to do.


added ssl cert to my blog

GitHub How to Java EE

New app

checkout my new app under development: