Impressions of using RavenDB
Just over a year ago, the problem of choosing NoSQL solution for a project arose. There were a number of specific requirements.
After a long search and comparisons, the choice fell on RavenDb . I was a little surprised that not many publications were devoted to this product. After a year of communication with this NoSQL solution, I decided to share my impressions. I see no point in rewriting documentation, everything is very well described on the project website and in official groups. As well as the blog developer Ayende blog .
Ease of deployment. You can use both the solution built into the project, Windows service and the console application.
')
Never lost data. Considering the constant bullying and experiments with the base, I consider it a merit.
Ease of transition to the new version. You just need to stop Raven and throw a new build into the working folder of the server. In the project, everything costs by updating the NuGet package.
Extensibility There are many opportunities to embed its functionality on the server side. Moreover, the code can be written in .NET. We have everything from triggers to changing data and indexes to creating our own extensions to enrich the server API.
Indices lucene.net. Good, well-known solution. It is possible to use your own analysis classes. Working with full-text search is simple and straightforward.
Debug mode. By running in this mode, you can view all the processed requests and the time of their execution in the console, which is quite convenient.
Built-in caching functionality. Quite a handy thing, allows you to specify in the code which requests should be cached on the server side.
Rapid response in the community to emerging issues. A couple of times I encountered bugs, fixes appeared almost online.
The ability to form queries using both LINQ and the lucene syntax.
Scripted Patch API. Quite a powerful tool that allows you to send requests for changes to the document using javascript scripts. It is possible to shovel the document as you like using javascript.
Description of indexes in the code. It is very convenient when you can create a separate .NET assembly with a description of the indexes. When starting the application, the presence of indexes and the relevance of their description will be checked. In case of a mismatch, the indices will be rebuilt.
Transaction support Everything is quite simple and clear, using TransactionScope.
Working with POCO is very convenient. If necessary, you can easily add new fields to the document object. For old documents, the fields will be filled with default values.
Ability to set priorities for processing indexes. If we have a set of indexes and some of them should work online, and the other can wait, then we can set their modes of operation. Normal - changes are made immediately. Idle - changes are made when there is no more work. Disable - the index is not rebuilt. Abandoned - changes are made when there is no work for a long time.
Administration interface Written in Silverlight, which I wouldn’t refer to pluses. In general, it works stably, but small jigs constantly appear. This is a bit annoying. For example, the state of the index can be displayed as stale, but if you open the studio again or in parallel in another browser, it will show that the index is up to date.
Automatic bringing descriptions of indexes up to date. If there is little data and indices, then everything works fine, but with the growth of stored information, this process becomes more mysterious. Sometimes there is a rebuilding of unchanged indexes, and the most complex ones. This makes it necessary to spend some time waiting, which is a little annoying.
There is support for asynchronous access, but only one asynchronous request can be executed in a session. That is, it is impossible to execute several requests in parallel in one connection.
Bad stats. When you need to analyze the performance of the index, you have practically nothing. There is a map reduce time per serving, but this is not enough.
HTTP Rest API. Connection is only via http, data is transferred to JSON, which affects performance. I would like to be able to connect on by http.
Patch API does not support transactions. It is insulting and sometimes it is very lacking.
Indexing speed The work of indexing threads is not very clear. Sometimes they eat almost all the resources, and at some point, with the presence of work, everything seems to freeze. I would like more information about their work.
The speed of execution of requests. Also not very clear. I will not compare it with other NoSql solutions, but sometimes it seems that it could work faster.
In general, the product is quite interesting. It is a pity that he paid little attention. Raven is constantly evolving, new functionality appears regularly. There are downsides, but at the moment .NET NoSql solutions are quite few. Therefore, if someone faces the choice of NoSql for their .NET project, I would dare to recommend looking at RavenDb.
- Expandability (triggers, stored procedures);
- Full text search;
- Availability provider for .NET;
- POCO support;
- Ability to deploy on a Windows platform;
- Desirable support for lucene.net;
- Preferably transaction support;
- Desirable support for asynchronous requests;
- Preferably map reduce;
- Presence of documentation and community of developers is desirable.
After a long search and comparisons, the choice fell on RavenDb . I was a little surprised that not many publications were devoted to this product. After a year of communication with this NoSQL solution, I decided to share my impressions. I see no point in rewriting documentation, everything is very well described on the project website and in official groups. As well as the blog developer Ayende blog .
Like
Ease of deployment. You can use both the solution built into the project, Windows service and the console application.
')
Never lost data. Considering the constant bullying and experiments with the base, I consider it a merit.
Ease of transition to the new version. You just need to stop Raven and throw a new build into the working folder of the server. In the project, everything costs by updating the NuGet package.
Extensibility There are many opportunities to embed its functionality on the server side. Moreover, the code can be written in .NET. We have everything from triggers to changing data and indexes to creating our own extensions to enrich the server API.
Indices lucene.net. Good, well-known solution. It is possible to use your own analysis classes. Working with full-text search is simple and straightforward.
Debug mode. By running in this mode, you can view all the processed requests and the time of their execution in the console, which is quite convenient.
Built-in caching functionality. Quite a handy thing, allows you to specify in the code which requests should be cached on the server side.
Rapid response in the community to emerging issues. A couple of times I encountered bugs, fixes appeared almost online.
The ability to form queries using both LINQ and the lucene syntax.
Scripted Patch API. Quite a powerful tool that allows you to send requests for changes to the document using javascript scripts. It is possible to shovel the document as you like using javascript.
Description of indexes in the code. It is very convenient when you can create a separate .NET assembly with a description of the indexes. When starting the application, the presence of indexes and the relevance of their description will be checked. In case of a mismatch, the indices will be rebuilt.
Transaction support Everything is quite simple and clear, using TransactionScope.
Working with POCO is very convenient. If necessary, you can easily add new fields to the document object. For old documents, the fields will be filled with default values.
Ability to set priorities for processing indexes. If we have a set of indexes and some of them should work online, and the other can wait, then we can set their modes of operation. Normal - changes are made immediately. Idle - changes are made when there is no more work. Disable - the index is not rebuilt. Abandoned - changes are made when there is no work for a long time.
I do not like
Administration interface Written in Silverlight, which I wouldn’t refer to pluses. In general, it works stably, but small jigs constantly appear. This is a bit annoying. For example, the state of the index can be displayed as stale, but if you open the studio again or in parallel in another browser, it will show that the index is up to date.
Automatic bringing descriptions of indexes up to date. If there is little data and indices, then everything works fine, but with the growth of stored information, this process becomes more mysterious. Sometimes there is a rebuilding of unchanged indexes, and the most complex ones. This makes it necessary to spend some time waiting, which is a little annoying.
There is support for asynchronous access, but only one asynchronous request can be executed in a session. That is, it is impossible to execute several requests in parallel in one connection.
Bad stats. When you need to analyze the performance of the index, you have practically nothing. There is a map reduce time per serving, but this is not enough.
HTTP Rest API. Connection is only via http, data is transferred to JSON, which affects performance. I would like to be able to connect on by http.
Patch API does not support transactions. It is insulting and sometimes it is very lacking.
Strange
Indexing speed The work of indexing threads is not very clear. Sometimes they eat almost all the resources, and at some point, with the presence of work, everything seems to freeze. I would like more information about their work.
The speed of execution of requests. Also not very clear. I will not compare it with other NoSql solutions, but sometimes it seems that it could work faster.
Conclusion
In general, the product is quite interesting. It is a pity that he paid little attention. Raven is constantly evolving, new functionality appears regularly. There are downsides, but at the moment .NET NoSql solutions are quite few. Therefore, if someone faces the choice of NoSql for their .NET project, I would dare to recommend looking at RavenDb.
Source: https://habr.com/ru/post/201550/
All Articles