High availability

Enjoy High Availability with a Distributed Database Architecture

RavenDB is a NoSQL Document Database, that allows you to enjoy high availability in a distributed database architecture without increasing complexity.

Putting together a dataset in a relational database often requires the gathering and joining of information from numerous tables. Add to the mix data retrieval from different nodes of a distributed system, and you wind up piling complexity upon complexity.

With a document database you can store and retrieve all your data using a single repository, making for smooth sailing in a distributed environment. Easy approach to additional service points is translated into a user experience of reduced latency, faster performance, assignment failover, and a “Come in, we’re open!” sign for your prospects and customers to see at all times.

A Distributed Database that Makes it Look Easy

Easy Deployment: RavenDB makes distributed computing look easy.

You can get set up and secured in a matter of minutes. Watch RavenDB CEO Oren Eini spin up a 3-node cluster in less time than it takes to run a mile:

RavenDB defaults to a distributed database architecture, operating even a single server as a database cluster of one node. This tactic saves you time and resources, as you can easily deploy a distributed system by scaling out to 3, 5 or more nodes. You don’t have to change anything while your cluster expands.

You can create and secure your data cluster quickly and deploy it in the cloud, on-premise, or in a “hybrid” combination of both.

What You Achieve with High Availability in a Distributed Database Architecture

Replication: A distributed cluster maintains multiple copies of your database and constantly updates them, replicating data between nodes in real time. Should one of the nodes fail, the others are here to keep your information, online presence and services intact. Cluster nodes that a certain database is not yet replicated to, can function as backup nodes for this database. Say you have 5 nodes in your cluster, and one of your databases is replicated to only 3 of them. Should any of these three go down for too long, RavenDB will replicate the database to one of the two remaining nodes. This behavior, one of RavenDB’s “active anti-entropy measures”, insulates your network from unexpected hiccups in your IT infrastructure, your application remains robust, and users see no pause in service.

Assignment Failover: RavenDB nodes share responsibility for the execution of ongoing tasks, so if one node goes down its tasks are redistributed between the remaining ones, assuring that each working node has an optimal workload.

Concurrent Reads and Writes: RavenDB is multi-master. Multiple nodes can accept both read and write requests at any time, making RavenDB perfect for edge deployment schemes. You can easily setup a topology in which end points operate in tandem with the central cluster but also independently in case the network is disrupted. This allows you to shift most of the distributed nature of your system to RavenDB and let it shoulder the burden and handle the details for you.

Concurrent Notifications: If two modifications are being done to the same document at the same time, you will get a notification about the concurrent change and be able to decide and manually control which version is used.

Consistency vs Availability: Is consistency more important, or is availability? Highly distributed environments would always keep this question alive and kicking. Is it more important to prevent concurrent users from potential conflicts, or to grant them as much access as possible?

RavenDB uses the Raft Consensus Algorithm to regulate approach to documents, databases, nodes, clusters, indexes and tasks, and provides the user-customization feature “Cluster-Wide Transactions” to determine a cluster-wide precedence of consistency over availability.

Scale Up with the Click of a Button

RavenDB has a great Management Studio GUI. In a click, you can expand the number of nodes in your cluster. This is ideal for peak traffic times when you need more points of service available to handle more users.

You can also scale back, by eliminating nodes. This comes in very useful on the cloud, when you want to reduce underutilized resources for both usage and costs.