Develop on the Cloud, for the Cloud

Cloud-Based App Development Tools

Subscribe to Cloud-Based App Development Tools: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Cloud-Based App Development Tools: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Cloud Development Tools Authors: Yeshim Deniz, Pat Romanski, Elizabeth White, AppNeta Blog, Carmen Gonzalez

Related Topics: Cloud Computing, Java Developer Magazine, Cloud Development Tools, Big Data on Ulitzer

Blog Post

NoSQL: Filling the Gaps By @MapR | @CloudExpo [#Cloud #BigData]

Today's web based apps demand databases that are flexible, high performing, and easily scalable.

NoSQL: Filling the Gaps in Your Traditional Relational Database

With the many different characteristics of NoSQL databases available today, it's not always clear how to best categorize the different NoSQL offerings. Typically, though, NoSQL databases are labeled according to the associated data model, most commonly: key-value, wide-column, document, and graph. But more important than the differences between them are the reasons why they are growing in popularity as a whole. In general, NoSQL databases are meant to fill some of the capability gaps found in traditional relational database management systems (RDBMS).

Today's web-based applications are highly demanding, so the databases that hold their vast stores of information are not only expected to be very flexible in nature (supporting various data formats), but also to manage extreme performance and scaling. Enterprise architects have many great technology choices today, and it makes more sense than ever to spend the time to assess application requirements thoroughly before suggesting an appropriate database.

Initially promoted as a departure from, and improvement upon, the traditional RDBMS model, NoSQL is considered an independent and specialized database technology to support complex business needs. But NoSQL advantages don't necessarily represent an opportunity for outright replacement of RDBMSs. An enterprise architect's recommendation of RDBMS versus NoSQL comes down to the nature of the operational requirements, in other words, particular use cases. In some cases, an RDBMS is more appropriate, and sometimes quicker, for specific data management tasks compared to NoSQL, and the use of NoSQL could be problematic for the application as well as for the business. A look at some of the fundamental features of database technologies will lay the groundwork for a general understanding of how NoSQL and RDBMSs differ, and how the former can fill in the gaps of the latter.

RDBMS: transactional, consistent

RDBMSs have been around for decades and have become the foundation for many business applications today. They can guarantee good performance with a volume of thousands of transactions per second which, decades ago, was enough. They also support multi-update transactions, known by computer scientists as "ACID transactions." The ACID transaction principles--atomicity, consistency, isolation, and durability--ensure data integrity even when multiple data elements are updated together. But modern internet applications - especially those operating in real time, such as fraud detection, risk analysis, advertising, and gaming - involve millions of transactions per second, and typically don't need multi-update transactional guarantees. RDBMSs struggle to manage the sheer volume of these newer online transaction processing (OLTP) applications. RDBMS vendors are investing time, money, and effort into overcoming these issues, but for now the gap remains.

Another strength of RDBMSs is the implementation of SQL ("Structured Query Language") as the de-facto standard for data processing tasks like data query, data definition, data manipulation, etc. SQL, and thus RDBMSs, require a predefined tabular structure entailing rows and columns to ensure that data is stored in a consistent and expected format. The widespread knowledge of SQL along with the consistency of the data model make RDBMSs well-suited for business intelligence analysts. Any application that requires multi-element updates, such as those dealing with financial data, and that takes advantage of the power and ubiquity of SQL, should use an RDBMS.

NoSQL: scalable, flexible

Most NoSQL databases give up on multi-row ACID transaction capabilities to achieve cost-effective scalability and performance. For a certain class of use cases, this tradeoff is perfectly acceptable, especially when the data set has records that are independent of one another, so there is no requirement to make updates that require additional immediate updates. And with regard to the data model, NoSQL databases, in contrast with RDBMSs, use different formats to store data. This flexibility lets application developers store heterogeneous record formats in the same database, which is often needed for large-scale data sets loaded from numerous distinct sources. The most popular NoSQL data formats are key-value, wide-column, and document (like JSON). Among them, the key-value databases are the simplest, while wide-column databases provide the closest data model to RDBMS tables. NoSQL databases bypass some of the hard constraints used in RDBMS architectures to achieve data storage flexibility, scalability, and performance.

Use cases: NoSQL suitability over RDBMS

There are many applications for which the traditional ACID-driven RDBMS model is not the easiest or best option. Here's another look at what NoSQL can do:

  • A key-value database is ideal if your application requires only the storage of data for the purposes of a quick lookup. In this situation, an RDBMS is unnecessarily complex, and a key-value database will be more than sufficient to meet your application's needs. The value itself can be as simple or as complex as you require.
  • A wide-column database is ideal if your data is structured like an RDBMS table but the columns might be different across rows. This means that different types of records can be stored in the same table, and existing rows can be easily updated to accommodate new columns.
  • A document database is ideal if your data entails hierarchical objects. RDBMSs could accomplish this with the help of object relational mapping (ORM) tools, but the work is often complex, and it's not worth complicating matters when NoSQL solutions are available.
  • A graph database is ideal if your application deals with connected networks of entities or large trees. Graph databases are good at quickly identifying linkages between related entities.

Major influencing factors: scaling and performance

RDBMSs were not originally designed for horizontal scaling - in other words, adding more hardware servers to the mix -- so they get overwhelmed when the load and data increase beyond expectations. RDBMSs are not great at distributing data across servers, in the process known as "sharding." Either they don't have the ability to automatically shard, thus requiring application-level coding to distribute data, or the scale-out architecture is expensive.

Here, NoSQL solutions have an advantage. A NoSQL database does not have to break up records into distinct pieces across servers. They are always logically stored in a single place, thus simplifying the distribution process. And since there is no referential integrity required between these logical entities, NoSQL is easily able to perform automatic data sharding. Though NoSQL solutions have certain limitations when compared to the relational model, they were designed with the intention of providing high scalability. A NoSQL solution can scale horizontally over a distributed environment and support high availability.

Overall performance depends largely on the selection of appropriate technology (NoSQL or RDBMS) for a specific use case. Thus, if NoSQL is selected for the wrong use case, it can hurt the performance of the application. Apart from factors like network, caching, and disk I/O, performance is dictated by the data and its allocation across the distributed storage - and NoSQL is capable of handling large volumes of data in a clustered environment, boosting performance as a result.

It's important to remember that NoSQL is not a substitute for traditional RDBMSs, but an alternate solution to address a different set of use cases for which RDBMSs were not designed. Many NoSQL technologies exist on the market today, and if your NoSQL requirements include enterprise-grade reliability, high performance, and fast responsiveness, a production-proven NoSQL database worth investigating is MapR-DB by MapR Technologies.

More Stories By Dale Kim

Dale is Director of Industry Solutions at MapR. His technical and managerial experience includes work with relational databases, as well as non-relational data in the areas of search, content management, and NoSQL. Dale holds an MBA from Santa Clara University, and a BA in Computer Science from the UC Berkeley.