Overview: Relational vs Non-Relational
I thought I might share some of my thoughts on relational vs non-relational databases.
I've worked with a non-relational database, MongoDB, on & off for the past three years and of course have over a decade of relational database experience, primarily with Oracle. So I thought I'm give a brief overview of some of the advantages, and pit-falls of non-relational databases compared to more traditional data stores.
I will provide a disclaimer, the field of non-relational data stores has radically changed over the past five years and continues to change. So while I'll try to give a decent overview, I'm sure I'll do a poor job at spots. Also, at the high level I'll be at, some more salient points will get omitted. I will stress, this is a rich area and it's well worth your time to do further exploration.
So, what is a non-relational database? I'm not sure I could give one solid definition. Just looking at the Wiki page for NoSQL lists out nine types of stores. I'm going to focus on a handful for this overview.
The biggest & most diverse group fall under the broad category of key-value store. Some of the biggest players in this space are Redis & memcached. My limited experience in this area is with Redis. At it's basic level, a key-value store is what it says. It stores keys & associated values. The advantage is they can function as simple map that often times can be all stored in memory. They are optimized primarily for speed. And they tend to be the most stripped down when it comes to rich features of traditional data bases. Other more advanced data stores, most notably graph databases, use key-value stores as their foundation.
Another major group is that of the Document Store. My knowledge here is primarily in MongoDB, but CouchBase & other major players operate here as well. A document store at it's base is a key-value store where a key (id) is used to do fast lookups of a value (document). The big difference is most document stores come with some kind of query language or API that allows searching based on the contents of document (i.e. value) which differentiates it from the more basic key-value store. Document stores are often times thought of as non-relational databases or "No SQL databases". That is because most operate similar to a database where the "document" takes the place of a row. But they lack concrete DDL. So multiple documents in the same location need not (depending on the implementation) have the same set of fields.
And the last one I'm going to cover is Columar Stores. This area I unfortunately am not strong in, having only vaguely dabbled in it. At it's base, it shares some similarities to a document store in so far as, it stores a "document" of data. But it's actually a tuple of "columns" each with a name, value and usually some sort of timestamp or other vectoring to manage stale data. They allow querying to an extent. And while they can be thought of as having a DDL of shorts (by allowing columns to have types like string, etc.) they operate more like a document store being "no SQL" as different data elements need not have the same set of columns.
Later I'll try to do a deeper dive into this topic more by focusing on the NoSQL store I know the most about, which is MongoDB. Assuming the new release of MongoDB 4.0 doesn't completely up-end my knowledge of this area.
I've worked with a non-relational database, MongoDB, on & off for the past three years and of course have over a decade of relational database experience, primarily with Oracle. So I thought I'm give a brief overview of some of the advantages, and pit-falls of non-relational databases compared to more traditional data stores.
I will provide a disclaimer, the field of non-relational data stores has radically changed over the past five years and continues to change. So while I'll try to give a decent overview, I'm sure I'll do a poor job at spots. Also, at the high level I'll be at, some more salient points will get omitted. I will stress, this is a rich area and it's well worth your time to do further exploration.
So, what is a non-relational database? I'm not sure I could give one solid definition. Just looking at the Wiki page for NoSQL lists out nine types of stores. I'm going to focus on a handful for this overview.
The biggest & most diverse group fall under the broad category of key-value store. Some of the biggest players in this space are Redis & memcached. My limited experience in this area is with Redis. At it's basic level, a key-value store is what it says. It stores keys & associated values. The advantage is they can function as simple map that often times can be all stored in memory. They are optimized primarily for speed. And they tend to be the most stripped down when it comes to rich features of traditional data bases. Other more advanced data stores, most notably graph databases, use key-value stores as their foundation.
Another major group is that of the Document Store. My knowledge here is primarily in MongoDB, but CouchBase & other major players operate here as well. A document store at it's base is a key-value store where a key (id) is used to do fast lookups of a value (document). The big difference is most document stores come with some kind of query language or API that allows searching based on the contents of document (i.e. value) which differentiates it from the more basic key-value store. Document stores are often times thought of as non-relational databases or "No SQL databases". That is because most operate similar to a database where the "document" takes the place of a row. But they lack concrete DDL. So multiple documents in the same location need not (depending on the implementation) have the same set of fields.
And the last one I'm going to cover is Columar Stores. This area I unfortunately am not strong in, having only vaguely dabbled in it. At it's base, it shares some similarities to a document store in so far as, it stores a "document" of data. But it's actually a tuple of "columns" each with a name, value and usually some sort of timestamp or other vectoring to manage stale data. They allow querying to an extent. And while they can be thought of as having a DDL of shorts (by allowing columns to have types like string, etc.) they operate more like a document store being "no SQL" as different data elements need not have the same set of columns.
Later I'll try to do a deeper dive into this topic more by focusing on the NoSQL store I know the most about, which is MongoDB. Assuming the new release of MongoDB 4.0 doesn't completely up-end my knowledge of this area.
Comments
Post a Comment