Forging a NoSQL Database

RavenDB has been around for a little over a decade and is currently used by thousands of customers, including fortune 500 companies like Toyota and Verizon, but it hasn’t always been smooth sailing. Like any other software, RavenDB has had its growing pains, particularly in the early days when the company was made up of just a handful of developers.

User feedback has always played an important role in our development. Many of RavenDB’s features were added due to popular demand, and our customers have helped us find countless obscure bugs by using our software in ways we never could have imagined.

RavenDB Database Security Methods

How Does RavenDB Succeed in Protecting Your Database Both in Transit and at Rest?

With cybercrime estimated to have cost the global economy over one trillion USD in 2020, database security has never been more relevant.   To properly secure a database, data must be protected both in transit between server and node, and at rest on the server.

Encryption at rest protects the data stored on the server, preventing it from being viewed, stolen, or otherwise accessed by someone with malicious intent. If your disk is lost or stolen, for example, an attacker will have complete access to your data. When encrypted, however, the data will be unreadable and the attacker will see it only as random noise.

Powering Up RavenDB Indexes With NuGet Packages

In RavenDB 5, you can use third-party NuGet packages and load binary data (or "attachments") within your indexes without any additional code deployment necessary.

In this article, I’ll showcase how to use these two features together to index EXIF metadata on images and run ML.NET sentiment analysis offline on product reviews.

Running a RavenDB Cluster With Two Nodes

Recently, we got a couple of questions in the mailing list about running a RavenDB 4.x cluster with just two nodes in it. This was a fairly common topology in RavenDB 3.x days because each of the nodes was mostly independent, but that added a lot of operational complexity to the system. In RavenDB 3.x you had to do a lot of stuff on each of the nodes in the system. RavenDB 4.x has brought us a unified cluster management and greatly simplified a lot of operational tasks. But one of the results of this change is that we now have a cluster rather than just a bunch of nodes.

In particular, in order to be able to operate correctly, a RavenDB cluster needs a majority of the voting nodes to operate successfully. In a typical cluster setup, you are going to have three to five nodes and you’ll need two or three of them to be accessible for the cluster to be healthy.

Computing Spatial Distances in RavenDB Queries

RavenDB has had support for spatial queries for a long time. In RavenDB 4.0 we did a whole bunch of work to make spatial queries better. In particular, we have separate the concepts of searching and ordering for spatial queries. In most cases, if you are doing a spatial query, you'll want to sort the results by their distance. The classic example is: "Give me the Pizza stores within 5 km from me". I'll usually also want to see them listed by their distance. But there are other ways to go about it. For example, if I want to see a concert by Queen, I want to sort them by distance, but I don't want to do any spatial filtering.

It gets interesting when you combine different spatial operations at the same time. For example, consider the following query. Here is how you can search for a house in a particular school district, but want to find the one that is nearest to the office. The two spatial queries aren't related at all to one another.

Making Money From Open Source Software: How We Do It

After my previous two posts on the topic, it is now time to discuss how we make money from Open Source Software. Before I start, I want to clarify what I’m talking about:

  • RavenDB is a document database.
  • It is about a decade old.
  • The server is released under the AGPL/commercial license.
    • We offer free community and developer licenses without any AGPL hindrance.
  • The RavenDB client APIs are licensed under the MIT license.
  • RavenDB (the product) is created by Hibernating Rhinos (the company).

I created RavenDB because I couldn’t not to. It was an idea that had to go out of my head. I looked up the details, and toward the end of 2008, I started to work on it as a side project. At the time I was involved in five or six active open source projects, had just gotten my NHibernate Profiler product to stable ground, and was turning the idea of getting deeper into databases in my head for a while. So I sat down and wrote some code.

Data Modeling With Indexes: Event Sourcing (Part 1)

In this post, I want to take the notion of doing computation inside RavenDB’s indexes to the next stage. So far, we talked only about indexes that work on a single document at a time, but that's just the tip of the iceberg of what you can do with indexes inside RavenDB. What I want to talk about today is the ability to do computations over multiple documents and aggregate them. The obvious example is in the following RQL query:

That is easy to understand — it is simple aggregation of data. But it can get a lot more interesting. To start with, you can add your own aggregation logic in here, which opens up some interesting ideas. Event sourcing, for example, is basically a set of events on a subject that are aggregated into the final model. Probably the classiest example of event sourcing is the shopping cart example. In such a model, we have the following events: