Contrasting Hadoop & Apache Cassandra™

Apache Cassandra is a NoSQL database ideal for high-speed, online transactional data, while Hadoop is a big data analytics system that focuses on data warehousing and data lake use cases.

Learn NoSQL Basics At DataStax Academy

What is Hadoop?

Apache Hadoop, an Apache Software Foundation Project, is a big data analytics framework that focuses on near-time and batch-oriented analytics of historical data. Hadoop helps run analytics on high volumes of historical/line of business data on commodity hardware.

There are four fundamental components that make up Hadoop:

Hadoop Distributed File System (HDFS) is a distributed file system that looks like any other file system except than when you move a file on HDFS, this file is split into many small files, each of those files is replicated and stored on (usually, may be customized) 3 servers for fault tolerance constraints. MapReduce is a programming paradigm for processing and handling large data sets. It splits requests into smaller requests which are sent to many small servers to be processed in a parallel manner. As a result, you can process very large data sets very quickly. Common/Core is a package containing libraries and utilities to support Hadoop modules. YARN is a resource management platform included for managing computing resources and scheduling Hadoop tasks.

How does Cassandra complement Hadoop?

As with legacy relational database applications, there is typically a need in modern Web, mobile and IOT applications to have a database devoted to online operations (that includes analytics on hot data) and a batch-oriented data warehouse environment that supports the processing of colder data for analytic purposes.

Apache Cassandra is a perfect database choice for online Web and mobile applications, whereas Hadoop targets the processing of colder data in data lakes, warehouses, etc. This allows a IT organization to effectively support the different analytic “tempos” needed to satisfy customer requirements and run the business.

What about HBase?

HBase is an open-source, NoSQL, distributed database modeled after Google's BigTable and is written in Java. It’s included as part of Apache Software Foundation's Apache Hadoop project and runs on top of HDFS (Hadoop Distributed File System), providing BigTable-like capabilities for Hadoop.

HBase is designed to support data warehouse/lake-styled use cases and is not typically utilized for distributed Web and mobile applications that need a high-performance online database.

How does Cassandra compare to HBase?

HBase is sometimes used for an online application because an existing Hadoop implementation exists at a site and not because it is the right fit for the application. HBase is typically not a good choice for developing always-on online applications and is nearly 2-3 years behind Cassandra in many technical respects.

In comparison to HBase, Cassandra supplies:

  • Higher performance
  • True continuous, “always on” availability with no single point of failure
  • Powerful and easy multi-data center / cloud availability zone support
  • A simpler architecture (masterless) with easier setup and fewer requirements
  • Easier development (SQL-like language with CQL, more)
Icon
Blog
The 5 Features to Look for in a NoSQL Database

NoSQL databases have been around a long time - since the 1960s - but it wasn’t until the early 21st century that companies really started to use them, primarily to handle their big data and real-time web and cloud applications. Since then, the NoSQL database has surged in use and popularity, although relational databases still have their place. But when beginning to search for a NoSQL solution, what should you look for?  Here are the 5 key features to look for in a NoSQL database: 1. Multi-Model Where relational databases require data to be put into tables and columns to be accessed and analyzed, the various data model capabilities of NoSQL databases make them extremely flexible when it comes to handling data. They can ingest structured, semi-structured, and unstructured data with equal ease, whereas relational databases are extremely rigid, handling primarily structured data. Different data models handle specific application requirements. Developers and architects choose a NoSQL database to more easily handle different agile application development requirements. Popular data models include graph, document, wide-column, and key-value. The ideal is to support multiple data models, which allows you to use the same data in different data model types without having to manage a completely different database. 2. Easily Scalable It’s not that relational databases can’t scale, it’s that they can’t scale EASILY or CHEAPLY, and that’s because they’re built with a traditional master-slave architecture, which means scaling UP via bigger and bigger hardware servers as opposed to OUT or worse via  sharding. Sharding means dividing a database into smaller chunks across multiple hardware servers instead of a single large server, and this leads to operational administration headaches. Instead, look for a NoSQL database with a masterless, peer-to-peer architecture with all nodes being the same. This allows easy scaling to adapt to the data volume and complexity of cloud applications. This scalabilty also improves performance, allowing for continuous availability and very high read/write speeds. 3. Flexible Where relational databases require data to be put into tables and columns to be accesses and analyzed, the multi-model capabilities of NoSQL databases make them extremely flexible when it comes to handling data. They can easily process structured, semi-structured, and unstructured data, while relational databases, as stated previously, are designed to handle primarily structured data. 4. Distributed Look for a NoSQL database that is designed to distribute data at global scale, meaning it can use multiple locations involving multiple data centers and/or cloud regions for write and read operations. Relational databases, in contrast, use a centralized application that is location-dependent (e.g. single location), especially for write operations. A key advantage of using a distributed database with a masterless architecture is that you can maintain continuous availability because data is distributed with multiple copies where it needs to be. 5. Zero Downtime The final but certainly no less important key feature to seek in a NoSQL database is zero downtime. This is made possible by a masterless architecture, which allows for multiple copies of data to be maintained across different nodes. If a node goes down, no problem: another node has a copy of the data for easy, fast access. When one considers the cost of downtime, this is a big deal. NoSQL vs. SQL Decision Making Choosing between a NoSQL and a relational database is always going to come down to your company’s particular needs. And there are, of course, situations for which you might want to use both types, as they can often complement each other. If you deal with a lot of data types, and/or you want or need to build powerful web and cloud applications for a distributed and quickly growing user base, then you will need your database to be multi-model, flexible, easily scalable, distributed, and always on, which means you will need a NoSQL database that can handle these requirements. Introduction to the Active Everywhere Database (white paper) READ NOW

Get the Blog
Icon
Blog
The Evolution of NoSQL

For years, organizations have relied on relational databases management systems (RDBMSs) to store, process, and analyze critical business information. The idea originated in a paper written in 1970 by a computer scientist named Edgar Codd, who thought to archive information in tables containing rows and columns. The concept was a major leap forward from the slow and inefficient flat file systems that businesses were using at the time, although these systems did work in conjunction with pre-relational model databases. The Rise of SQL Shortly after, IBM developed the SQL language to scan and manipulate sets of transactional data sets stored within RDBMSs. With SQL, it became possible to quickly access and modify large pools of records without having to create complex commands. SQL essentially enabled one-click access to sets of data. The idea took off, and the RDBMS eventually emerged as the most widely used data management system. Today, most organizations are still using RDBMSs one way or another. RDBMSs, however, have one major limitation: They are only capable of efficiently processing relatively small amounts of structured data—like names and ZIP codes. The NoSQL Imperative When the era of big data hit, a new kind of database was required. The real driver for NoSQL was the sheer shift in data volumes that the Internet brought. Prior to the internet, and in its early days, relational databases only had to deal with the data of a single company or organization. But when faced with the millions of Internet users that could discover a company's service in waves, the RDBMS model either broke or became very challenging to shard correctly. Relational databases also required a tremendous amount of maintenance. A database of a few thousand objects may handle things decently, but as you scale up, performance declines. This is a big problem—especially considering the massive volume of unstructured data that is being generated on a daily basis. According to 451 Research, 63% of enterprises and service providers today are managing storage capacities of at least 50 petabytes—and more than half of that data is unstructured. The concept of NoSQL has been around for decades. Believe it or not, businesses have been using non-relational databases to store and retrieve unstructured data since the 1960s. The technology, however, wasn’t referred to as NoSQL until developer Carlo Strozzi created the Strozzi NoSQL Open Source Relational Database in 1998. Strozzi’s database, though, was really just a relational database that didn’t have an SQL interface. It wasn’t until 2009 that we saw a true departure from the relational database model and the first working NoSQL application. NoSQL databases offer several advantages over relational databases. Most importantly, they can handle large volumes of big data. Other advantages include: Elastic scalability. Unlike relational databases, NoSQL databases can scale outward into new nodes instead of upward. This strategy is much more flexible, efficient and affordable than scaling with traditional legacy storage systems. Lower operating costs. One of the biggest downsides to using an RDBMS is the fact that you will have to deal with expensive servers. Since NoSQL databases leverage commodity server clusters, you can process and store larger data volumes at a lower cost. Reduced management. NoSQL databases are much easier to install and maintain as they are simpler and come with advanced auto-repair capabilities. While it’s not completely hands-off, NoSQL is much easier for network teams to manage on a daily basis. Bridging RDBMS With NoSQL Right now, NoSQL databases only account for about 3% of the $46 billion database market, but  they are quickly gaining traction and on pace to become a legitimate long-term market disruptor. But while NoSQL is heating up and the RDBMS market is experiencing a significant slowdown, this doesn’t mean that businesses are running out and abandoning their RDBMS systems altogether. RBDMSs, after all, are still great at managing transactional workloads, which are heavily used today. The best solution often involves finding a way to use your legacy technology to support your new applications, and this means getting an enterprise data layer. What’s an enterprise data layer? It’s a way to connect your systems of record with your systems of engagement. Essentially, it’s a data management layer that precludes you from having to go through a painfully expensive and time-consuming “rip and replace” process, and it allows you to salvage your legay tech and put it to good use. You may still be stuck in the relational age, but that doesn’t mean you can’t take full advantage of the NoSQL revolution. The Architect’s Guide to NoSQL (white paper) READ NOW

Get the Blog
Icon
Blog
How to Tap Into the Power of a NoSQL Database

For years, organizations have relied on relational databases management systems (RDBMSs) to store, process, and analyze critical business information. The idea originated in a paper written in 1970 by a computer scientist named Edgar Codd, who thought to archive information in tables containing rows and columns. The concept was a major leap forward from the slow and inefficient flat file systems that businesses were using at the time, although these systems did work in conjunction with pre-relational model databases. The Rise of SQL Shortly after, IBM developed the SQL language to scan and manipulate sets of transactional data sets stored within RDBMSs. With SQL, it became possible to quickly access and modify large pools of records without having to create complex commands. SQL essentially enabled one-click access to sets of data. The idea took off, and the RDBMS eventually emerged as the most widely used data management system. Today, most organizations are still using RDBMSs one way or another. RDBMSs, however, have one major limitation: They are only capable of efficiently processing relatively small amounts of structured data—like names and ZIP codes. The NoSQL Imperative When the era of big data hit, a new kind of database was required. The real driver for NoSQL was the sheer shift in data volumes that the Internet brought. Prior to the internet, and in its early days, relational databases only had to deal with the data of a single company or organization. But when faced with the millions of Internet users that could discover a company's service in waves, the RDBMS model either broke or became very challenging to shard correctly. Relational databases also required a tremendous amount of maintenance. A database of a few thousand objects may handle things decently, but as you scale up, performance declines. This is a big problem—especially considering the massive volume of unstructured data that is being generated on a daily basis. According to 451 Research, 63% of enterprises and service providers today are managing storage capacities of at least 50 petabytes—and more than half of that data is unstructured. The concept of NoSQL has been around for decades. Believe it or not, businesses have been using non-relational databases to store and retrieve unstructured data since the 1960s. The technology, however, wasn’t referred to as NoSQL until developer Carlo Strozzi created the Strozzi NoSQL Open Source Relational Database in 1998. Strozzi’s database, though, was really just a relational database that didn’t have an SQL interface. It wasn’t until 2009 that we saw a true departure from the relational database model and the first working NoSQL application. NoSQL databases offer several advantages over relational databases. Most importantly, they can handle large volumes of big data. Other advantages include: Elastic scalability. Unlike relational databases, NoSQL databases can scale outward into new nodes instead of upward. This strategy is much more flexible, efficient and affordable than scaling with traditional legacy storage systems. Lower operating costs. One of the biggest downsides to using an RDBMS is the fact that you will have to deal with expensive servers. Since NoSQL databases leverage commodity server clusters, you can process and store larger data volumes at a lower cost. Reduced management. NoSQL databases are much easier to install and maintain as they are simpler and come with advanced auto-repair capabilities. While it’s not completely hands-off, NoSQL is much easier for network teams to manage on a daily basis. Bridging RDBMS With NoSQL Right now, NoSQL databases only account for about 3% of the $46 billion database market, but  they are quickly gaining traction and on pace to become a legitimate long-term market disruptor. But while NoSQL is heating up and the RDBMS market is experiencing a significant slowdown, this doesn’t mean that businesses are running out and abandoning their RDBMS systems altogether. RBDMSs, after all, are still great at managing transactional workloads, which are heavily used today. The best solution often involves finding a way to use your legacy technology to support your new applications, and this means getting an enterprise data layer. What’s an enterprise data layer? It’s a way to connect your systems of record with your systems of engagement. Essentially, it’s a data management layer that precludes you from having to go through a painfully expensive and time-consuming “rip and replace” process, and it allows you to salvage your legay tech and put it to good use. You may still be stuck in the relational age, but that doesn’t mean you can’t take full advantage of the NoSQL revolution. The Architect’s Guide to NoSQL (white paper) READ NOW

Get the Blog