For many decades now, we are much used to relational database management systems or the RDBMS systems. These are SQL based which stores and retrieves data is a well-structured manger. On the other hand, the new-generation non-relational database (which is there is practice for more than a decade now) is the kind of database management system that does not use any traditional tabular schema as rows and columns in the case of relational database systems. Instead of this table form, the non-relational DBs have a unique storage model, which is optimized for the requirement of the specific types of data it stores. For example, data can be stored in simple key/value pairs as a JSON document or the graphical data form of vertices and edges.
Considering non-relational databases and NoSQL databases, even though fundamentally different, what these two types of data stores have in common is that neither uses any relational model for data storage. Adding to these factors, these tend to be more or less specific in data types they can support and how these data can be queried. For example, the time-series data stores will be query optimized over the time-based data sequences. In contrast, the graphical data stores are optimized to explore the weighted relationships among the entities. Neither of these formats will generalize the tasks of transactional data management.
NoSQL is a term that refers to the data stores that do not use any SQL querying practices. Instead, they use other common programming languages to query the database. In actual practice, “NoSQL” may mean “non-relational” even though many of the non-relational DBMS is compatible with SQL queries too. But the strategy for underlying query execution remains different from how the traditional RDBMS may execute similar SQL queries. Further, in this article, we will describe the basic categories of non-relational and NoSQL DBs.
Non-relational and NoSQL databases
-
Document data stores
These data stores help manage a custom set of string fields, object-centered data values in a document. These types of data stores can keep data in JSON document formats. Each of the database fields can be kept as a scalar item like a number, compound elements, the list with the parent-child collection, etc. Data in these document fields can be easily encoded in different ways as XML, JSON, YAML, BSON, or can be stored as just plain test. All the different fields within these documents are also exposed to storage management systems by enabling the DB applications to do querying and filtering of the stored data using various field values.
In standard document data stores, the given document will contain the whole data for a given entity. The items that constitute an entity is typically related to the application specifics. Say, for example, an entity may contain the customer details of a business, order details, or both in a logical combination. Any given document may contain the information, which may further spread across various relational database management tables in the RDBMS. The document store may not require all these documents to have the same structure. Such a form-free architecture will offer a higher degree of flexibility and also help increase the speed. In this approach, applications can effectively store various data types in a document by responding to a change in business needs.
-
Columnar data stores
Columnar data stores or column-family stores typically organize the data in the forms of rows and columns. In the simplest form, column-family stores of data may appear as the same as the relational databases at the conceptual level. However, any given column-family data store’s actual power is in the denormalized approach of structuring sparse data, which further stems from its column-oriented approach of data storage. On being doubtful about remote DBMS service, you can consult RemoteDBA.
You may also think of a column-family data store as something which holds tabular data in columns and rows; however, the columns further get divided into the groups called column families. Each column family may hold a unique set of columns related logically and edited or retrieved as a unit. Other data sets that are accessed separately may be stored in different column families. In a given column family, we can dynamically add more columns, and the rows can also be sparse, whereas a row may not need to have a unique value for each column.
Unlike the key/value data store or the document mentioned above database, the column-family DBs store data in key order physically than by computing the hash. The primary index is the row key, enabling access through a given key or a set of keys. Some key-value implementations also let you form a secondary index over the specific columns in the family. The secondary key/value indexes will help you retrieve data by the column values than the row keys.
All the columns in the given column family will be stored together in a file with a specific number of rows in each given file on the storage disk. Having a larger data set, this approach will further create performance benefits as it helps reduce the overall amount of data that needs to be accessed from the disk. At the same time, only a limited number of columns are queried at a time. Also, the read and write activities for any given row are processed atomically within the given column family even though some specific implementations may offer atomicity across the complete row by spanning various column families.
-
Key/value stores
It is typically a larger hash table. Each data value in the key/value store is associated with a unique key, and this key is used to store data using a hashing function. The majority of the key/value stores may support only simple querying, insert, and delete operations. To a value, the application has to overwrite the data existing for the entire value. Ins standard database implementations, writing or reading a single value can be considered an atomic operation. As the value gets larger, writing or reading may take more time.
You can find various other database models too in non-relational and NoSQL databases. As compared to relational DBMS, non-relational databases are known to offer more flexibility and scalability, but the choice has to be made with careful consideration of your database requirements.
