For Better DevOps, Proteria Chooses RavenDB November 30, 2022

For Better DevOps, Proteria Chooses RavenDB

by  Shahar Erez
published: November 30, 2022 | updated: December 8, 2022

They get superb stability, cost-efficiency, and a user-friendly testing environment in the package.

About Proteria

Proteria is a leading Scandinavian shipping and customs logistics software company.  With about 14 million documents (3.5M of them handle business transactions), their freight system integrates smoothly with Europe’s most widely used transporters.

What did they use before RavenDB?

While using MySQL in their older solutions, they noticed some weaknesses with system resiliency. Also, creating a working schema in every release cycle took a lot of work. Each new function required lots of repetitive work that isn’t needed with RavenDB. Testing was also tedious, so they wanted an integrated testing environment with an in-memory database. RavenDB offers this for integrated and unit tests. Finally, they did all of their reporting via SQL queries, which became slow as their model grew.

Their freight solution was likely to become their biggest project. They wanted to build it on an ACID database that is easier to scale and develop with and that guarantees fast queries. They read RavenDB Founder Ayende write about his journey creating a fast, highly available, NoSQL, ACID database that solves relational problems like object-relational impedance mismatch. They decided to try RavenDB for their freight solution. They built the solution on RavenDB v3-3.5 but now use RavenDB Cloud for new projects.

When choosing a NoSQL database, they compared RavenDB and MongoDB, but MongoDB’s indexing doesn’t have much of the functionality of RavenDB. At the time, they didn’t offer ACID transaction guarantees either and RavenDB was designed for safe, fast transactions from the beginning.

Benefits of RavenDB and the features used to unlock them

Low-friction developer experience and smooth operations

Development in RavenDB vastly reduces the amount of work needed to achieve any task. Your schema can be flexible, and you do not need to map classes to tables and class properties to table columns.

With our dynamic/auto indexes, there’s no need to anticipate every possible future query to prevent costly, slow queries. RavenDB removes auto indexes that aren’t used.

RavenDB is optimized by default for most situations and adapts automatically. Of course, you can configure these optimizations as needed.

Reduces costs

Many of the same features that make RavenDB so fast also dramatically reduce overall costs. RavenDB vastly reduces trips to the server with its approaches to validated client-side caching, batching ACID requests, and including multiple related documents into one transaction.

NoSQL queries don’t need to traverse multiple joins because most of the information you need is on one JSON document where nested blocks replace external table rows. Thus they are faster than SQL in complex scenarios. Also, RavenDB static indexes are uniquely able to do the computations and aggregations behind the scenes so that queries are much faster. Whenever the data changes, the indexes update themselves and run the computations async. When users query the data, all of this work has already been done by the index, so the query doesn’t have to. Also, if you query an index while it is being updated, RavenDB will not lock the index, but you can define the query to wait for non-stale results in the infrequent cases where this is needed. 

Faster release cycles

RavenDB’s document model liberates developers from the need to accurately predict the schema to be used for years to come. When new data fields are needed, adding them does not cause problems or require much work. You can bulk-insert data from production into a development environment, refine and test your ideas, then plug the polished project into production.

Easier to write integration tests which means fewer bugs

How does RavenDB make testing and debugging more intuitive? You can run full integration tests with RavenDB running in-memory as part of a whole, automated testing ecosystem.

High availability via RavenDB’s automatic failover is unnoticed if a server falls

RavenDB is a distributed database with a master-master topology. Failover between servers/nodes in a cluster is instant and automatic so that your application doesn’t miss a beat. This is by default. There is no need to do anything once you have a cluster of local servers set up, which only takes a few minutes to do securely. RavenDB has you covered on-premise and in the cloud. (Note that default automatic failover is scoped to the local cluster, so to ensure maximum availability, you can set clusters up on different machines with backup power, or in different nearby cloud data centers for when data centers go offline.)

Native, fully-featured search

No need for 3rd party search; RavenDB gives you the same fast, Lucene-powered functionality as Elastic or Solr, with far less integration overhead and complexities. Features such as spatial queries, aggregations, facets, highlights, and suggestions are all part of the package. Results are automatically ranked according to relevancy (and can be boosted.) You can specify search operators, use prefixes and wildcards, get suggestions and similar terms, show text snippets with terms highlighted, and more.

(As of 2022, RavenDB still uses the built-in Lucene engine but will soon offer the option of having the same functionality but dramatically faster performance at the cost of storage space with our in-house engine Corax.)

Difficulties Proteria had with RavenDB and how they solved them

RavenDB has several Safe-by-default configurations that are meant to prevent common mistakes such as calling the server in a loop or bringing back huge amounts of query results when you only need a few. At first, their team was not used to the limitations but was able to configure them when needed. Looking back, in almost every case, the safe-by-default settings were helpful, but they had to get used to working with them.

It was also a mind-shift to embrace the concept of eventually consistent indexes since queries could return stale data because the index was not yet up-to-date. Together with going from a monolith to a message-driven and less tightly coupled system, this meant Proteria had to rethink how they designed their systems. This also means designing the user interface in such a way that users don’t rely on immediate consistency for queries. If needed, we can always define their query to wait for non-stale results.

Woah, already finished? 🤯

If you found the article interesting, don’t miss a chance to try our database solution – totally for free!

Try now try now arrow icon