Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
I've mentioned before that I really don’t like the Abstract Factory pattern, and in particular, code like this:
static IGUIFactory CreateOsSpecificFactory()
{
string sysType = ConfigurationSettings.AppSettings["OS_TYPE"];
if (sysType == "Win")
{
return new WindowsFactory();
}
else
{
return new MacFactory();
}
}
One of the comments mentioned that this might not be ideal, but it is still better than:
This is an article from DZone's 2022 Database Systems Trend Report.
For more:
Read the Report
It is somewhat of a cliché to consider the data in your systems as far more valuable than the actual applications that compose it. Those applications are updated, mutated, retired, and replaced, but the data persists. For many enterprises, that data is their most important asset. It used to be simple. You had the database for the organization. There was only one place where everything the organization did and knew was stored, and it was what you went to for all needs. One database to administer, monitor, optimize, backup, etc. — to rule the entire organization’s data needs.
RavenDB has been around for a while. The first production deployment (the backend for monitoring bird migration patterns in Norway) went live on Nov 2010. After a decade of working on the database, I thought that I had a pretty good idea about the kind of features that RavenDB has and what is the direction the project is going.
Archimedes famously said “δῶς μοι πᾶ στῶ καὶ τὰν γᾶν κινάσω”. That probably doesn’t make sense to you, since he spoke in Ancient Greek. But you can probably guess, since this is one of the most famous sayings in the world: “Give me one firm spot on which to stand, and I shall move the earth”. In the same sense, a couple of minor new features in RavenDB have been instrumental to open up a huge leap in the capabilities of RavenDB.
An extendible hash is composed of a directory section, which points to leaf pages, and the leaf pages point to where the actual data resides.
My current implementation is incredibly naïve though. The leaf page has an array of records (two int64 values, for key and value) that we scan through to find a match. That works, but it works badly. It means that you have to scan through a lot of records (up to 254, if the value isn't found). At the same time, we also waste quite a bit of space here. We need to store int64 keys and values, but the vast majority of them are going to be much smaller.
Full-text search is a really interesting topic that I have been dipping my toes into again and again over the years. It is a rich area of research, and there has been quite a few papers, books, and articles about the topic. I read a bunch of projects for doing full-text search, and I have been using Lucene for a while.
I thought that I would write some code to play with full text search and see where that takes me. This is a side project, and I hope it will be an interesting one. The first thing that I need to do is to define the scope of work:
We got a bug report recently about RavenDB messing up a query. The query in question was:
from index TestIndex where Amount < 0
I recently got a comment that included this:
…this "making code faster" series is pretty useless for the average developer working on the usual application.
And I couldn’t disagree more.
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.
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.
One of the changes that we made in RavenDB 4.2 is a pretty radical one, even if we didn’t really talk about it. It is the fact that RavenDB now contains C code. Previously, we were completely managed (with a bunch of P/Invoke) calls. But we now we have some C code in the project. The question is why?
The answer isn’t actually about performance or the power of native C code. We are usually pretty happy with the kind of assembly instructions that we can get from C#. The actual problem was that we needed a proper abstraction. At this moment, RavenDB is running on the following platforms: