Future-Proof Your Data Platform

Is NoSQL right for you? Your data platform should deliver continuous availability and provide real-time contextual data at scale — it’s the difference between today’s successful modern applications and those that fail. The demands of modernization have led to the rise of NoSQL as the most viable database option for highly available and distributed modern applications.

Trading up to a NoSQL database will help you stay ahead of your data demands.

The top determining requirements to help you understand if it’s the right time to trade up to an enterprise-grade NoSQL database:

DataStax Enterprise Makes It Easy

DSE is built on Cassandra to provide best-in-class support for modern application requirements that signal the need for a high-performance NoSQL data platform.

Relational and NoSQL Capabilities Compared

Relational Databases
NoSQL Databases
Master-slave architecture Masterless architecture
Moderate velocity data High velocity data (time-series data from devices, sensors, etc.)
Data coming in from one/few locations Data coming in from disperse geographic locations/many locations
Primarily structured data Structured, with semi-unstructured
Always strongly consistent Tunable consistency (eventual to strong)
Complex/nested transactions Lightweight/simple transactions
Protect uptime via failover/log shipping Protect uptime via distributed and fault-tolerant architecture
High availability Continuous availability
Deploy app central location/one server Deploy app everywhere/many servers/any cloud/microservices/serverless
Primarily write data in one location Write data everywhere/anywhere
Primary concern: scale reads Scale writes and reads
Scale up for more users/data Scale out for more users/data
Maintain data volumes with purge High data volumes; retain forever; horizontal scalability without boundaries
Transaction workloads Mixed workloads of transactions and analytics
One data center or cloud region Multi-data center, multi-cloud region, or hybrid cloud
Relational data Multi-model (tabular, key/value, document, graph)

DataStax Data Management

Distributed databases built for modern applications on premises and in the cloud.

Icon
Whitepaper

Modernizing with NoSQL from Relational Data Platforms

Most IT analysts agree that NoSQL will dominate new software stack spending for years to come—but how do you know when to make the move away from legacy database software? In this whitepaper, you’ll learn the criteria to watch out for, and the keys to success when it comes time to migrate from a legacy relational database to a NoSQL platform built to support digital, mobile, and cloud applications that run everywhere.

Learn More
Icon
Blog

How To Get Started with NoSQL and Apache Cassandra™

DataStax Enterprise (DSE) is built on Apache Cassandra, the distributed database behind a vast array of applications that you likely engage with every day. The open source database powers apps for some of the world’s biggest brands that require zero downtime, high availability, and scaling to accommodate massive data volumes. Cassandra is ideal for applications that demand the highest data resiliency, like ecommerce or IoT apps, where uptime and scale—whether on premises or in the cloud—are essential.  DSE provides a distributed, highly available, and fault-tolerant data management platform at scale, and with tunable consistency. Leading brands depend on DSE to power their business-critical applications,  including Capital One, Cisco, Comcast, Condé Nast, Delta Airlines, eBay, Macy’s, McDonald’s, Safeway, and Sony. Developing on Cassandra is in demand with more than 40,000 job listings searching for engineers with Cassandra and NoSQL skills on LinkedIn.  Given the high demands of today’s applications, we believe Cassandra has a bountiful future. But don’t just take our word for it. The 2019 Dice Tech Report found the rewards of learning Cassandra to be greater than others like MongoDB, MySQL, Postgres, Redis, and DynamoDB, and Cassandra placed among the top five technologies to know. Fast-Track Skills Acquisition: Model. Code. Go.  Building your apps on Cassandra not only brings resilience for your data, but also the benefits of streamlining performance bottlenecks and simplifying the data management complexity that can come with developing apps for multiple legacy systems and data stores on mainframes or relational database management systems (RDBMS).  Get started with Cassandra via DataStax Academy, where you can choose a learning path to plot your journey; learn how to develop, administer, or architect with DataStax and Cassandra; or specialize in graph, search, or analytics. Our Academy courses range from walk-throughs to hands-on coding lessons on topics like data modeling, advanced data types, connecting to drivers, replication and consistency, and the best CQL (Cassandra Query Language) or Gremlin commands for your queries. When you complete a DataStax Academy learning path, you’ll receive a Certificate of Completion—an accomplishment worth sharing on your LinkedIn profile!   At DataStax Academy, you can also learn how to use DSE with Apache Kafka, Docker, and Kubernetes, as well as DataStax’s high-performance, pre-built connectors and production Docker images. You can also ramp up on DataStax graph technology for use cases that get you higher value from connected data in real time such as fraud detection, supply chain management, social network analysis, customer analytics, and recommendation engines.  Connecting the Dots from Relational to NoSQL The big benefits in shifting from relational to Cassandra include a more elastically scalable and resilient data platform than relational databases and legacy technology—it minimizes time spent on downtime, transforming your data, and modeling complexity.  “With a conventional database, we’d have to be really in the trenches, or completely re-architecting how we absorb that data. But because we had Apache Cassandra, we knew we’d have to add a few additional nodes to the cluster, at most, and without having to fundamentally re-architect our solution. That Apache Cassandra can scale with us with minimal hiccups is a great relief.” — Harry Robertson, tech lead at Ooyala One of the concerns that developers and data engineers often have when bridging the gap from familiar relational concepts like tables and SQL is relating them to NoSQL, CQL, and Cassandra models—but it’s easier than you think.  Get Started Today Whether you’re deploying on premises or in the cloud, we’ve made things easier with a few simple steps that can help, and choosing DataStax Enterprise to accelerate your journey with Cassandra is a great place to start.  We’ve also created a guide that covers all the comparisons, considerations, similarities, and key differences between Cassandra and relational databases:Getting Started with NoSQL and Apache Cassandra: Accelerating the Transition from Relational to NoSQL With our new training mantra, “model, code, and go,” tools, and simplified approach to getting started, it’s the right time to sign up to DataStax Academy, pick a learning track, start running DataStax distributed databases, and get certified.  What are you waiting for? Model. Code. Go.

Learn More
Icon
Whitepaper

DBA's Guide to NoSQL

A DBA’s life is full of surprises – some more pleasant than others. As a DBA you’re pretty much “on it” 24-7-365: putting out fires, checking alerts, training people, keeping test databases in sync with production, debugging, and praying your developers are writing halfway decent code. If you’re swinging over to the NoSQL side (the “dark” side?), or considering it, then you’ll want to read this white paper, The DBA’s Guide to NoSQL. It’s essentially a NoSQL bible, sans orders from God -- or Darth Vader.

Learn More
Video

A Relational Data Safari: Migrating Transactional Data to DataStax / Cassandra

Many applications are built with relational data structures in mind. What happens when that structure gets out of control? In this talk we take you on a tour of migrating a travel application to a lightning-fast DataStax/Cassandra data architecture. We look at challenges of denormalizing transactional data, designing a UI for hundreds of fields, and how our data model evolved to keep us on track.

Learn More
Icon
Blog

Do I Have the Right Type of NoSQL Database?

Relational database management systems are flexible and often very performant; they ruled the database scene throughout the 1980s and 1990s. But like many tools, there are limits to what they can do. NOSQL database began to pop up in the 2000s to fill the gaps left by a relational database management system. The moniker “NoSQL” originally started as a hashtag, and while it’s the de facto name for this style of systems, the term “non relational” is more accurate, as many NoSQL databases embrace SQL (Structured Query Language) because it is such a well understood, declarative language. While all NoSQL databases hold in common the fact that they offer features that are difficult to accomplish using a traditional relational database management system, NoSQL databases can be differentiated into one of the following categories: 1) Key Value Stores Key value stores offer a simple lookup of a value by its key. Think of a dictionary. Data is arranged by words (the keys) and you can easily get to each word’s definition (the value). Because of the simplicity of their structure, key value stores are relatively easy to distribute and scale out; they are also highly performant for equality-based searches with simple payloads. 2) Wide Columnar Stores A wide columnar store takes the idea of a key value store to the next level. Data is still distributed by a key, but the value is a structured set of rows and columns. This tabular payload allows for storage of more complex, structured data. Depending on the implementation, there may or may not be a strict schema applied to this payload. Wide columnar stores offer many of the semantics of relational databases but support the ability to distribute and scale the system. 3) Document Databases Taking the concept of the key value store yet another step further, document databases organize data by a key but allow the payload to be a “document.” This document offers a lot of flexibility. It can be a highly defined structure such as a JSON (Javascript Object Notation) document, or it can be a very flexible structure containing binary data or free-form text or anything else that might need to be stored. Because of the flexibility in structures, developers often like working with document databases because they can match the payload stored in the database to the specific objects that they interact with in their code; this allows them to avoid the “impedance mismatch” often experienced with mapping the tabular data stored in databases into the in-memory objects used by applications. 4) Graph Databases The use of the term “relational” in a relational database management system does not refer to the fact that two things are related; instead, it refers to the fact that a relational database management system is based on relational algebra. A mathematical “relation” is a set of “tuples”—basically synonymous with tables. While a relational database management system can be used to relate tables together through the use of joins, a graph database takes this concept to the next level. Graph databases are based on mathematical graph theory, and they represent data as a set of vertices and edges (terms borrowed from geometry). Data stored in a graph database can be thought of as “pre joined” because all the connections between entities are laid out ahead of time. Graph databases excel at handling use cases where there is great value in how the data is related. Examples include fraud detection, network analysis, and web connectivity (Google’s founder Larry Page famously created the PageRank algorithm based on graph connectivity). Because of their highly related nature, graph databases are the hardest of the NoSQL types to distribute across multiple nodes. Which NoSQL Database is Right for Me? Choosing the right NoSQL database involves understanding the capabilities of each tool and matching those capabilities to the requirements of the application. The idea of “polyglot persistence”—using a variety of tools to store a system’s data based on the specific needs of the application—has become prominent, especially in systems that demand extreme performance at extreme scale. Having a toolbelt full of NoSQL databases and the know-how to use the right one for the right job is a powerful concept.

Learn More
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

Learn More