If a server, data center, or cloud provider network fails, the data must be restored as quickly as possible. Disasters such as earthquakes, fires, power failures, or hardware damage can interrupt services and corrupt data center data. A disaster tolerance solution can minimize such impact by restoring applications and data within a business-reasonable amount of time after a disaster. Aleksandr Volochnev from DataStax explains how NoSQL databases raise failure tolerance to a higher level.
New Requirements In The Data Age
How long are we willing to wait for the app to work again? More than three seconds? Fifty-three percent of mobile web visitors did not accept that much. They expected the page to load faster and stop, Google’s DoubleClick found out back in 2016. In today’s data age, according to an IDC study, the global data volume will increase to 175 zettabytes by 2025, and up to 49 percent will be stored in clouds every tenth of a second. Data must always be available without delays.
Today, internationally active companies also want to quickly start an instance of their service directly in the USA or, for example, in Australia. An architecture based on relational databases does not offer enough for this. Because it only gives companies the choice to keep their data in a single location, which means they have to wait for their customers. The second variant would be a double database operation, which at some point could hardly be managed.
NoSQL Database: Globally Available Data And Scalable Apps
The alternative we are looking for is NoSQL. Such a database system makes the data globally available by storing it on servers and distributing it across different regions to different cloud providers. There are no additional costs. At most, there is a specific latency. Apache Cassandra is a distributed open-source database management system that implements the NoSQL database schema precisely in this sense – i.e., without the relational description of the data – for disaster tolerance.
Previously, Apache Cassandra was known as a column-oriented and Java-based NoSQL database for other scenarios. It can process vast amounts of data for big data applications and is suitable as real-time data storage for online applications with a wide range of transactions. This includes exceptionally scalable real-time applications for which database performance can easily be increased. To duplicate, for example, you add as many nodes as the cluster already contains during operation.
NoSQL Database: Rules For Distributed Data
The main reason why the NoSQL database can now establish a new standard for failure tolerance is that it implements the CAP or Brewer’s theorem. This describes the relationship between consistency (C), availability (A), and partition tolerance (P) and goes back to Eric Allen Brewer, a computer science professor and vice president for infrastructure at Google. It regulates all questions for distributed data and assumes that only two of the three requirements (C, A, P) can be well coordinated.
CP and AP systems are of practical relevance because they are not susceptible to inevitable network failures. In CP optimization, a database is consistent and partition-tolerant but less resilient. However, it becomes highly available and partition-tolerant in the AP configuration, which is only possibly consistent. The best-known AP system is the global Domain Name System (DNS): It is incredibly fail-safe and survives network partitioning without any problems. In this application scenario, Apache Cassandra remains flexible, can define the query position, and configure the query behavior from CP to AP.
Peer Nodes Proactively Replicate Data
According to the CAP theorem, all single points of failure (SPOF) must be eliminated. If these fail, nothing works in the system either. Every master node of a relational database is a SPOF. However, with Apache Cassandra, you build a masterless architecture in which the nodes are on an equal footing. So every node in Apache Cassandra can process a request, regardless of whether it should read or write.
If one of these nodes fails, its data must be available at another location – without a backup because that would take too long. The solution: Instead, the data is temporarily replicated before anyone needs it. Cassandra creates a kind of SQL database that defines the replication factor to replicate each data element in the desired number of nodes. This requires additional storage space. However, this costs little compared to a possible loss of reputation, lost orders, and long-term economic damage. The fact that an Apache Cassandra cluster can restore itself also makes a significant contribution to the failure tolerance.
NoSQL Database: Use A Disaster-Tolerant System
Setting up and maintaining an Apache Cassandra cluster requires specialist knowledge and is time-consuming. However, this will pay off for companies that do not want to keep their data on a single server but instead want to distribute it geographically. The disadvantages of neither restricting the data model nor carrying out cascade operations are compensated for by their fast reading and writing NoSQL database.
Administrators can configure the entire cluster so that a quickly distributed, disaster-tolerant system is created that is precisely tailored to their situation. In the meantime, many well-known top companies have implemented Apache Cassandra or its commercial version, DataStax Enterprise. Apple, Netflix, Twitter, Sony, eBay, Walmart, FedEx, and many others trust the flagship cloud database. It turns out that a fail-safe database that does not “fill up” is relevant for many companies in different industries.
Also Read: Oracle Accelerates MySQL HeatWave Queries With Machine Learning
