How RavenDB indexes documents and how it differentiates itself from another NoSQL document databases, MongoDB, as well as the relational database PostgreSQL.
Join the DZone community and get the full member experience. In this article we’ll discuss how RavenDB indexes documents and how it differentiates itself from MongoDB, another NoSQL document database, as well as the relational database, PostgreSQL. When it comes to indexing, RavenDB favors “eventual consistency” which means that it optimizes for high throughput read and write scenarios and attempts to return results to queries as fast as it can. These results may be “stale” until the index incrementally rebuilds to catch up to any new document changes. In RavenDB, you may also explicitly wait for non-stale results. On the other hand both MongoDB and PostgreSQL favor consistency (unless read on a secondary replica) but this means indexes impact read/write performance. In RavenDB, one key differentiator is that all queries are backed by indexes. They are the only way to query data. It’s worth clarifying that when we say “query” we are specifically talking about finding and filtering documents by properties other than their key. Document lookup and writes using keys are ACID-compliant transactions in RavenDB even across a cluster. This design stands in contrast to most databases where indexes are a way to optimize queries. This means that by default you are getting sub-optimal performance out-of-the-box in most databases since creating indexes is always a manual design choice. RavenDB offers both “auto indexes” and “static indexes”. Auto Indexes are generated indexes whenever you issue a query that doesn’t specify a static index. This means that you are always getting performant queries by default. If we had a fresh RavenDB database without any indexes, we could safely issue the following query to get all Employees by a specific department key: This query will generate an auto index named “Auto/Employees/ByDepartment” if it doesn’t yet exist and will start building it. For a new auto index, initially RavenDB will perform a quick indexing operation to try and return results immediately after which it will fully rebuild the index. This is what it means to be “stale” or “eventually consistent” from the perspective of an application. Normally, auto indexes are optimized well enough that you will not need to customize them but for full control, you can promote them to static indexes to customize the way it is built. Static indexes can be specified for queries like so: By specifying a second generic argument, we’ve told RavenDB to specifically use the EMPLOYEES_BYDEPARTMENT static index which we now have defined in our codebase. In MongoDB and PostgreSQL, indexes are only used when the query engine determines an index can serve the results of a query. This means you must use the query explanation or analyzer functions to profile each query and determine whether or not it needs to use an index. It also makes debugging difficult as a seemingly small change to a query, such as adding a new condition, will change the way it is executed leading to possibly unexpected performance degradation. In RavenDB, index definitions can be written in C# or JavaScript. It is expected you will define indexes in your codebase so they are versioned and deployed along with your application. You may also create them through the Studio interface. In MongoDB, indexes are defined as JSON objects and can be deployed through code or through MONGOD. Indexes are created through the ENSUREINDEX command where you specify the column(s) to index and any other options.
