A Student’s Limited View of Non-Relational Databases

I’m nearing the end of module 2 at the Turing School of Software & Design and one of the biggest differences between this module and the previous is that there’s a possible illusion of control. It might not be full control, but now you know stuff versus just absorbing everything thrown at you. There was a little bit of downtime with the lesser number of evaluated projects, and with that downtime many students try to find time to learn other things.

With my free time, I’ve done some dabbling in React Native, Swift, SASS, and most recently I was introduced to the idea of non-relational databases. I haven’t done much work in implementing anything, but also decided it would be a good topic to start investigating.

In module 2, we start with storing data in yml files (which are basically glorified text files), move to sqlite for a short period of time, and finally onto PostgreSQL with Rails (so we’re able to publish on Heroku). There’s a good amount of time spent explaining normalization of databases and best practices, but with Turing being an accelerated program, “good amount of time” usually means 3-ish days covering the same topic.

We were taught the basics of storing individual pieces of data in each table and using other tables to create more complex relationships. The idea of foreign keys and join tables because more familiar, and creating these relationships within a Rails app made me wish I could redo my Black Thursday project with a database instead of loading CSV files into ruby objects. (I’ve heard that my wish will be granted in module 3)

A developer friend of mine that works for a local media outlet asked me if Turing teaches about non-relational databases. He stated that places like FaceBook (they actually use both relational and non-relational), Instagram, Twitter, and Netflix use non-relational databases.

The main difference (from my short amount of research) is that Non-Relational databases don’t conform the the traditional primary key / foreign key / join table structure.

The idea alone is a tough thing to digest after having been taught about normalization methods for the past week (maybe it was just a couple of days, time runs together while you’re here). The main benefits to systems like NoSQL and MongoDB are speed and scalability. MongoDB accepts data in JSON and stores that data in BSON (Binary JSON) behind the scenes that allows for non-conforming types of data. Things like:

{ name: “Mark”, status: “student” }

can be stored next to data like:

{ name: “John”, status: “teacher”, years_of_experience: 3 }

These nodes or documents would be accessed singularly and not dependent on any other tables in order to retrieve any other relating data.

Scaling is also somewhat different between relational and non-relational databases. Relational dbs have to be scaled-up before the are scaled-out. Scaled-up means the machines that carry them must be improved, and once a single machine is at capacity for the amount of requests it is receiving, then it can be scaled-out across multiple servers.

NoSQL databases scale-out primarily to clusters of machines that are able to read from the database at any given time.

Companies like Intuit, Foursquare, Forbes, and eBay are all said to be using MongoDB