{"id":1799,"date":"2011-07-12T20:02:41","date_gmt":"2011-07-12T19:02:41","guid":{"rendered":"http:\/\/www.gamlor.info\/wordpress\/?p=1799"},"modified":"2021-08-24T13:27:12","modified_gmt":"2021-08-24T12:27:12","slug":"ravendb-queries-and-indexes","status":"publish","type":"post","link":"https:\/\/www.gamlor.info\/wordpress\/2011\/07\/ravendb-queries-and-indexes\/","title":{"rendered":"RavenDB: Queries and Indexes"},"content":{"rendered":"

So far we\u2019ve covered the very basics<\/a> and the document database nature<\/a> of RavenDB. This time we take a look at the queries and indexes. I\u2019ve already mentioned that RavenDB behaves different than most other databases in this matter.<\/p>\n

Queries Go Hand in Hand with Indexes<\/h2>\n

On what do we define an index in most databases? In most databases we put our index on the stored piece of data. For example we put it on a column in a relational database or on a field in document and object databases. Then a query may utilizes an index to speed up the processing. In most real applications we need an index, otherwise the query is just too slow.<\/p>\n

In RavenDB indexing works differently. RavenDB indexes the query instead of the fields in documents. Basically RavenDB takes our query, analyses it and extracts an index which can answer the query. Such indexes are called \u2018dynamic indexes\u2019. Every query we run builds or reuses a dynamic index. RavenDB tries to be smart about the indexes it builds. When a query is executed over and over again the index will become a permanent index. Less regular used queries only build a temporary index. All put together in RavenDB queries are just a way to create a new \u2018dynamic\u2019 index. Because of this behavior RavenDB nearly always talks about indexes and not queries. Also in this blog series I now will refer to \u2018indexes\u2019 most of the time.<\/p>\n

\"Queries<\/a>

Queries Always Go Via an Index<\/p><\/div>\n

When Is Stuff Indexed?<\/h2>\n

Another difference is when RavenDB indexes a document. Most databases index data when it is inserted or updated. That also implies that indexes slow down the update and insert process.<\/p>\n

RavenDB indexes the document in the background. When we store or update a document RavenDB puts it in a queue. Then a background tasks picks it up and updates all the existing indexes. However this implies also that an index (and remember, a query always uses an index) might return a stale result. When we store a document and then use an index the document is maybe not in there yet.<\/p>\n

\"RavenDB<\/a>

RavenDB Indexes in the Background<\/p><\/div>\n

<\/h3>\n

Deal With the Stale Results<\/h2>\n

Now we have to deal with the potential stale results on an index. First, we actually can force RavenDB to return an accurate result. That means we wait until our last write has been indexed and then get the results. This can be achieved in two ways. We can turn it on for a particular query with the \u2018WaitForNonStaleResultsAsOfLastWrite\u2019 option. There are additional options available, which you can explore yourself.
\n<\/p>\n

Alternatively we can change the default consistency level for the session or even for document store.
\n<\/p>\n

\"Force<\/a>

Force The Most Current Index<\/p><\/div>\n

Choose the Right Consistency<\/h2>\n

Well now you probably think: \u2018Well I just use a highest consistency level possible for all my queries\/indexes\u2019. Of course then we also pay the much higher costs of waiting for the index to be updated. It\u2019s much better to think about which parts of our application can deal with stale results and which parts not.<\/p>\n

\"Staleness<\/a>

Staleness in the Right Places<\/p><\/div>\n

Let\u2019s look at an example. We build a simple blog \/ news site. Now let\u2019s think about the consistency here. On the public website stale results shouldn\u2019t be an issue. Why? Because you as a visitor can\u2019t tell the difference between the \u2018super-latest\u2019 articles and the one published a few seconds ago. When an article shows up a few seconds later it makes no difference to you. Of course we also have an \u2018administration\u2019 backend. For the website administrator which is editing articles the story is different. He has just edited an article and wants to see his changes immediately. If he would encounter a stale content he would probably think that his changes are lost. What\u2019s the conclusion? Well we use the \u2018QueryYourWrites\u2019 consistency for administration-backend, while we allow stale results on the public website. That makes also a lot of sense performance wise. Most traffic will be from visitors and there we don\u2019t spend any time ensuring that there\u2019s not stale result. Only for the few website administrators we spend a little more time getting the most recent stuff.<\/p>\n

Permanent Indexes<\/h2>\n

Now so far we only used dynamic indexes, which are created when we are running a regular query. RavenDB also allows creating permanent and named indexes. Such an index is stored and maintained on the server until it is explicitly removed. We can create these permanent queries, give them a name and later on use them directly. First we create an index definition in a class like this:
\n
\nAfter that we tell RavenDB that there are index definitions in our assembly. RavenDB will include all our defined indexes of that assembly:
\n<\/p>\n

The index definition can contain all kinds of details. It can be a simple query like above or a complex map-reduce operation. I\u2019m not going into details here due to lack of expertise and to keep the blog post short =). After we\u2019ve created such an index we can use it:
\n<\/p>\n

Permanent indexes are certainly useful for very advanced index tuning. Or when we want to define some \u2018view\u2019 which returns certain data of our database. By the way when a dynamic index is used enough times RavenDB will promote it to a permanent index which we can treat like any other permanent index.<\/p>\n

\"Permanent<\/a>

Permanent Indexs<\/p><\/div>\n

<\/h2>\n

Conclusion<\/h2>\n

Now we\u2019ve covered how queries and indexes work in RavenDB. Most of the time we just can query RavenDB like any other database, but we never have to fear that a query runs slow because of a missing index. On the other hand we need to be aware of stale results. Next time we look at another important design detail of RavenDB, which protects the database from killing itself due to programming mistakes. Stay tuned =).<\/p>\n","protected":false},"excerpt":{"rendered":"

So far we\u2019ve covered the very basics and the document database nature of RavenDB. This time we take a look at the queries and indexes. I\u2019ve already mentioned that RavenDB… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_links_to":"","_links_to_target":""},"categories":[126,231],"tags":[21,296],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/posts\/1799"}],"collection":[{"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/comments?post=1799"}],"version-history":[{"count":20,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/posts\/1799\/revisions"}],"predecessor-version":[{"id":3904,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/posts\/1799\/revisions\/3904"}],"wp:attachment":[{"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/media?parent=1799"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/categories?post=1799"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/tags?post=1799"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}