NoSQL: Leaving Schema Behind (Part 1)

Posted By: Nick Floyd

Recently at Fellowship Tech we deployed a new feature that takes advantage of a new type of data store called NoSQL. Specifically we used MongoDB as the backing data store for this feature. During this process we have learned a whole lot about NoSQL through our development and testing that I feel merits sharing.

New data store design: NoSQL

In recent months there has been a lot of chatter about this new way of storing data called NoSQL. NoSQL is currently defined by the community as data stores that are schemaless and non-relational. There are two types of NoSQL databases.

Key-Value Stores

Key-value stores work just as you would think. You store a bunch of key-value pairs that are grouped similar to a row in a relational database. For example, one row can have FirstName=Jesse,LastName=Dearing and the next can have FirstName=John,MiddleInitial=Q,LastName=Public. Some key value stores include Redis, Amazon’s SimpleDB, and Tokyo Cabinet.

Document Stores

A document store works similarly to key-value pair stores, but you can store documents within documents. I know that sounds confusing. Basically you have a concept of a document which is similar to a row in a relational database and this document can have any number of fields, that can be multiple types of data, but keys can point to arrays and other documents. I’ll give you an example in JSON:

    "FirstName": "Jesse",
    "LastName": "Dearing",
            {"Name": "Ozzie", "Age": 3},
            {"Name": "Lady", "Age": 3},
            {"Name": "Zoot", "Age": 5}
    "Age": 26,
    "CarsMileage": 87982.8

So you can see what we’ve done is included multiple types of data (Age is an integer, CarsMileage is a floating point decimal, FirstName and LastName are strings) and we’ve included an array of documents within our document. Document stores give you the ability to nest documents which makes complex data structures easier to serialize.

Through With Your Schema-ing Ways

The great thing about NoSQL is that you are not tied to a set schema and this gives you the freedom to be able to just persist your data without having to build a schema. You have the ability to add indexes in most NoSQL databases so you can query on a field and retrieve data quickly.

While you get the power of not needing a schema, you want to make sure that your implementation warrants a schemaless approach.

NoSQL != Anti-SQL

Just because the NoSQL movement is advocating data stores without schema and not using SQL (the language) to query the data does not mean that NoSQL is about replacing relational databases. Out of the box NoSQL solutions do not provide ACID guarantees. Most NoSQL data stores provide weak consistency through eventual consistency and atomic transactions around a single key (that is if I update a field, only that field is locked). Because of this weak consistency, consider your implementation.

NoSQL is not the answer to all database problems, but it does make some problems easier and more manageable.

This is part one of a 2 part series. In part 2 I will dive into how we used MongoDB here Fellowship Tech.

Jesse Dearing is a Developer for Fellowship Technologies.  Currently he is focused on DevOps which is where the needs of the infrastructure meet the development of the software.  He likes learning about new technologies and languages (especially ones that are used on the web) as well as learning about new trends and practices in software development.  He is passionate about software development and helping other developers.

Posted In: News,

No one has commented yet. Be the first!
Commenting is not available in this channel entry.


Previous Posts:

Subscribe to the RSS feed!