What’s New RavenDB 4.2

RavenDB provides a lightning-speed service, along with data consistency that usually matches your users’ needs whether their environment is a single server, a distributed cluster or a larger network.

Many environments allow some amount of inconsistency. A client may still comment on an article for example, when a newer version of it has already reached the server. In other cases, perfect consistency is needed even at the expense of immediate availability. This would be the case with concurrent clients that try to rent the same hotel suite for New Year’s Eve: the server must inform them correctly about the suite’s current status, go through the rental procedure with only one of them, and if the reservation isn’t concluded – roll the transaction back and start again with a different client. Data consistency must be perfect.

RavenDB’s Optimistic Concurrency has made the prioritization of consistency over availability possible long ago, within the jurisdiction of a single server. The new Cluster-Wide Transactions feature expands this preference to any transaction within your distributed environment, allowing you to choose consistency over availability in a bigger scale or set high performance above all – as you wish.

Look into the future and become predictive with your data.

The extreme efficiency of Graph support in recognizing relationships between data elements and organizing them into searchable patterns, institutes their ability to manage huge, layered data volumes with intricate webs of relationships that relational databases can no longer handle.

A huge advantage unique to RavenDB is its ability to graph-query your data without forcing you to change its structure one bit. To those acquainted with graph terminology: your existing documents and collections are considered graph nodes, and the edges are inferred from the document contents – which allows both simple and complex edges RavenDB’s indexing mechanism and RQL language integrate effortlessly into the mix, laying the foundations for a solution as simple and intuitive as it is powerful.

Many services are made possible by graph support, including:

• Tracing paths between user profiles, e.g. from a client to a specialist or from a seller to a customer. Paths can then be weighed and measured for various needs.
• Data can be collected from users’ relations, relations’ relations and so on, and used to create accurate, tailor-suit recommendations.
• Related facts can be recognized and collected from distributed origins, enabling fraud-attempts detection and many other behaviors.

Pull Replication makes it easy to keep even the remotest edge units updated.

Many edge units remain offline much of their time, like a ship that has no internet connection while at sea for instance, or a military facility that is usually kept off-grid. How can we reach such a unit to update its database? Simple: let it reach us.

Pull replication is similar to External Replication, only initiated not by the unit that provides the database but by the unit that receives it. When an edge unit (a “sink” in a pull-replication relationship) is online and ready, it sends its central unit (“hub”) a Pull Replication request, and the hub transmits it its database. This way we don’t need to coordinate the right timing and penetrate security layers that may protect the sink.

It takes no more than a few seconds to start an ongoing “sink” task on one server and a “hub” task on the other, and turn a time-consuming burden into another RavenDB autonomous event that requires no intervention, runs effortlessly in the background and kicks in at the right moment.

In a large distributed environment counting can be a very serious matter, as well as extremely handy.

When a million users click “like”, or cast their votes in a 90-seconds time span, RavenDB’s distributed counters let multiple servers handle the aggregate load. Keep running tallies for product-likes, voting systems, online surveys or polls, and post the most up-to-date results at all times.

Distributed counters are perfect little ACID entities you can attach to your documents and update without modifying the documents and hurting performance. Different clients connected to different nodes can update the same counter concurrently, allowing each node to handle the counter locally and keep the load well distributed. All nodes replicate locally-set counter values to all others, to keep them all always capable of providing clients with the updated, aggregated value of each counter.

A simple counters API is at your service, allowing you to modify counter values as much as you like while their documents and RavenDB’s performance remain unhindered.

Fix a database-scope mistake with ease.

How did your database look 20 hours or 4 days ago, just before some of your edge devices started feeding it with corrupted data?

Go back in time to fix things by reverting your entire database to what it looked like before specific events took place. Document changes will be undone, deleted documents restored and new documents removed.

Our existing Revisions feature is like a time tunnel through which you can visit earlier versions of a document and restore a chosen one. The new Revisions Revert feature expands the scope of your time travel to that of the entire database. Once the Revisions feature is enabled, you can revert the entire database to a chosen time point. Reverting documents rather than restoring the whole system also keeps this database-scope revert process as swift as a rhino’s gallop.

Revision Revert is an online operation; You do not need to bring your database down, RavenDB remains alive and well the whole time. It simply behaves like the distributed system it is, reverts the database on one of the nodes and replicates it to the others.

A data subscription is a cooperation between RavenDB and a subscribing client.

• An ongoing search task for documents that the client is interested in, is defined on the server and executed.
• The task retrieves documents that match its query, and sends them to the client for processing.

Subscriptions can be easily created using the Studio or API calls, and used for various needs. An accountant can subscribe for employees’ paychecks for example, get all 50,000 already in the Paychecks collection at first, and then each new paycheck as it’s entered or modified.

Processing stored documents:

As long as matching documents are found in the database, the task retrieves and sends them to the client in batches, one batch at a time.

• The server saves clients an enormous effort by managing ongoing searches for them, keeping track of where they left off and which documents remain to retrieve.
• Batching unifies transactions, minimizes processing complexity on both sides, and makes communications more robust and much less prone to synchronization errors.
• A thorough set of API calls is available for developers, allowing adjustments like setting the size of document batches and choosing to automatically terminate consumed subscriptions.

Processing new documents:

When all stored documents have been processed by the client, the subscription task examines documents as they arrive and forwards matching ones to subscribers immediately.

• Intense data streams can be easily processed in real time
• Immediate actions can be taken when required
  E.g. to inform tax authorities when large sums have been deposited
• Patterns can be recognized and handled properly
  E.g. to identify fraud attempts and trigger proper response