What’s New RavenDB 6.0

Database Sharding is a solution to the challenge many corporations face: dealing with a gigantic database so extensive that it exceeds the capacity of a single machine. RavenDB 6.0 delivers server-side sharding by splitting your database into shards and distributing them on separate servers. But we do much more than that, We made an extreme effort to keep Sharding implementation self-contained, preventing leakage of any implementation details into your data access layer. The operational aspects of a sharded database were also addressed, minimizing complexity by enabling semi-autonomous operations. We are proud to offer you Seamless Sharding

Since the inception of RavenDB, Lucene.net has been a reliable and fast indexing engine that has served your queries. Over the years, we introduced numerous optimizations and tweaks to it, but its architecture remained the same. After two years in development, RavenDB version 6.0 comes with a new indexing engine. Corax exists in parallel with Lucene, and you can choose on a per-index basis which one to use. Corax brings faster indexing of your data and faster queries, especially on the cold run, with some of the queries being magnitude faster than Lucene. Additionally, Corax allocates less memory compared to Lucene, which overall means you will get more performance on the same hardware, postponing scaling up as your dataset grows
Best of all, Corax is a drop-in replacement for Lucene, which means that you do not have to change your code to feel the benefits of faster indexes, faster queries, and lower memory usage.

Completing support for Kafka even streams, RavenDB version 6.0  can read events from one or more  Topics and store them in collections. Once you set up Sink in a low-code manner, Kafka Topics will be streamed directly into your database. Such synchronization is automated, resilient, and reliable. This way, you can provide permanent storage for Kafka Events or leverage a powerful map/reduce indexing mechanism to aggregate events and provide new insights.

The database is just as essential as other components within your distributed system. Until now, RavenDB could send messages to other subsystems via RabbitMQ. In version 6, your database becomes capable of consuming them, too. With a low-code setup, RavenDB 6 can dequeue messages from one or more RabbitMQ queues in a reliable and resilient way. These messages are transformed into documents and stored in a database. From there, you can use RavenDB features like Subscriptions and Indexing to react to these new documents.

Not all documents are created equal. Some of them are more relevant, some of them are less relevant, and some of them are not relevant anymore for the queries you execute in your database. Version 6 brings an option to mark documents with a date for automatic archiving. Such documents will not change their collection. They will remain where they are but be marked as archived and excluded from indexing. This can dramatically reduce your database’s computation load and make indexing and querying faster.

The ability to test the index during development will speed up your development cycle. Imagine working on a new index. You define a mapping, save the index, going to the query window, execute a query, examine its results, and then return to modify your index. With the ability to test the index in version 6, you can perform a test run of the index in parallel with development.