NoSQL vs. RDBMS 3 differences in power and performance
When we think of a database, we traditionally envision a relational database management system (RDBMS). This is a repository of structured data organized by schemas, tables, columns, and rows. Data is stored persistently, and is resident on the system if the database application is restarted. RDBMS data is organized through tables and indexes and by applying data constraints. There are more advanced features, but those are often underutilized by applications. The RDBMS development life cycle is often time-consuming. Organizations want agile development in order to adapt to the market more quickly. Moreover, with the advent of e-commerce and web applications, there is a need to handle multi-structured data sets. There is a constant need to increase performance, capacity, flexibility, and 24/7 availability of applications. In order to meet these requirements, RDBMS needs high-end infrastructures that are expensive and have high licensing costs.
As a result, today’s organizations are considering various alternatives to legacy RDBMS, be they analytical applications or operational applications. And companies are moving away from RDBMS and toward technologies like Hadoop and NoSQL.
A NoSQL database is a non-relational database designed for fast performance with high volumes of data. It does not depend on SQL as the default query language, but that is not to say that it cannot use SQL to query data. A NoSQL database often has a scale-out architecture, compared with scale-up architecture in a RDBMS. Multiple servers can be added to a NoSQL cluster to distribute the workload, also known as a distributed array. The hardware and licensing requirements are less expensive, plus it can be deployed on commodity hardware. Users can develop and deploy their applications faster and more easily than before. Also, the learning curve for a NoSQL database is much shorter than for a relational database.
In this blog post I will brief three data models a NoSQL database can have
, including the different strengths of each.
4.Key-Value and Wide-Column Database
Examples: HBase, Redis, Azure Table Storage
Key-value stores are the most basic type of non-relational database. Every item in the database is stored as an attribute name or a key and its value. All or part of the data model may be expressed as a collection of tuples <attribute name, value>; each element is an attribute-value pair. Data modeling efforts when using key-value databases focus on the access patterns. These systems provide the ability to retrieve and update data based only on a single key or a limited range of primary keys. For querying on other values, we have to build and maintain additional indexes. To perform an update in these systems, multiple round-trips may be necessary: first find the record, then update it, then update the index. In these systems, the update may be implemented as a complete rewrite of the entire record irrespective of whether a single attribute or the entire record has changed. Key-value stores and wide-column stores provide a single means of accessing data: by primary key. This can be fast, but these databases offer very limited query functionality and may impose additional development costs and application-level requirements to support anything more than basic query patterns.
A column is the basic unit in a wide-column database and consists of a key and value pair. For example, a column might have the key “name,” and the value could be a string representing a name.
A column family is the equivalent of a table – each row in the column family has a unique identifier key, and then as many columns as it needs to hold the information. There is no requirement for every row to have the same columns, but the family itself must be declared before it’s used because column families typically represent how data is actually saved to disk.
In the above example of a column family, the first row contains two columns, the first called “Name” and a second called “Address,” but the second row contains an extra column called “Email.” Different rows can have different arrangements of columns – this is where the flexibility of this type of database comes from.
2. Document Store Database
Examples: CouchDB, MongoDB
Document-oriented databases are inherently a subclass of the key-value store. The difference lies in the way the data is processed; in a key-value store the data is considered to be inherently opaque to the database, whereas a document-oriented system relies on internal structure in the document order to extract metadata that the database engine uses for further optimization.
Document databases provide the ability to query on any field within a document. Some products, such as MongoDB, provide a rich set of indexing options to optimize a wide variety of queries, including text indexes, geospatial indexes, compound indexes, sparse indexes, time to live (TTL) indexes, unique indexes, and others. Furthermore, some of these products provide the ability to analyze data in place, without needing it to be replicated to dedicated analytics or search engines. MongoDB, for instance, provides both the Aggregation Framework for providing real-time analytics (along the lines of the SQL GROUP BY functionality) and a native MapReduce implementation for other types of sophisticated analyses. To update data, MongoDB provides a find-and-modify method so that values in documents can be updated in a single statement to the database rather than requiring multiple round-trips.
Below is an example of how data can be represented as a document:
3. Graph Database
Examples: Neo4j, sones
A graph database is a database that uses graph structures for semantic queries with nodes, edges, and properties to represent and store data. Relationship-type analysis tends to be very efficient in these systems, whereas other types of analysis may be less optimal. As a result, graph databases are rarely used for more general-purpose operational applications.
- Nodes are nothing but a way to represent entities, like people, places, businesses, For example, take the statement, “John is a friend of Sally.” Here “John” and “Sally” are nodes.
- Edges are the relationships between two nodes. In our example “is a friend” is the relationship.
- Properties are additional information related to Nodes, e.g., John is 25 years of age.
Examples of graphs:
When compared with RDBMS, many NoSQL systems share several key characteristics, including a more flexible data model, higher scalability, and superior performance. But most of these NoSQL databases differ when it comes to data models, data constraints, data consistency, and the use of query languages.
We can help you decide which NoSQL system is best for your business. Contact us to learn more.