RavenDB 3.0 New Stable Release
RavenDB 3.0 New Stable Release
We have just released build 3785 of RavenDB 3.0. This release includes about 3 months of bug fixes, performance improvements and the like.
Join the DZone community and get the full member experience.Join For Free
RavenDB vs MongoDB: Which is Better? This White Paper compares the two leading NoSQL Document Databases on 9 features to find out which is the best solution for your next project.
We have just released build 3785 of RavenDB 3.0. This build has quite a bit of changes (for the full gory details, see the pull request).
This release includes about 3 months of bug fixes, performance improvements and the like. We have been testing this on our own systems for a few weeks now, as well as on multiple live production sites, and the results have been nothing but encouraging.
- Voron &map/reduce optimizations. We have done major work to optimize how RavenDB uses map/reduce on Voron. As a result, map/reduce performance on Voron has improved tremendously. However, this require a migration step during the first startup. If you have a large RavenDB database using Voron, and you are making heavy use of map/reduce, take into account that on first start, RavenDB will need to perform an internal migration, which can take a while.
- Lucene & memory allocation reduction on queries. We have drastically reduced the amount of memory that is allocated per query, and improved the performance of queries substantially.
- Many small perf optimizations, memory allocations reductions, object pooling, etc. Drastic reduction in memory allocations on common code paths.
- Better handling of buffer allocations in websockets, reduces memory fragmentation.
- Better handling of Take() / Skip() inside an index.
- Allow only a single index to use the fast precomputation optimization at a time (reduce memory usage if multiple medium sized indexes are changed concurrently).
- Better handling of concurrent addition of multiple indexes to large databases, will now run in the same set of indexing batches, instead of each having their own.
- Re-implemented memory statistics checks using native calls to avoid expensive allocations.
- Provide more detailed information when an index is corrupted.
- Adding endpoint for stopping / starting just reduce work.
- Less aggressive changes to the batch size at scale, being more cautious gives us a bit slower perf but more stable system under load.
- Optimized Voron recovery code heavily to support slow I/O systems on large databases.
- Allow to mark individual databases as development / staging /production.
- Better handling of Lucene file usage, using mmap to avoid all allocations when querying the indexes. Significant improvements to both memory usage and querying speeds.
- Don’t update a side by side index if it already exits.
- Allow to update a side by side index while it is still running.
- Fixing index compilation error on .NET 4.6 using “new string”.
- Fixed an NRE when the index definition was removed forcibly when using dynamic queries.
- Fixed error handling during disposal causing an exception to escape thread boundary and crashing.
- Fixed FIPS licensing issue on embedded dbs.
- Admin logs are not capturing logs protected by IsDebugEnabled statement
- Fixed a finalizer usage bug causing us to try to read from a closed handle.
- Prevent corrupted index warning when creating a map-reduce index and indexing is disabled.
- Preventing code from trying to use disposed internal transactions.
- Installed fix - check and revoke URL reservation options when Use existing website is selected.
- Properly dispose of timer instance when shutting down a database using expiration bundle.
- Prevent an error loading ICSharpCode.NRefactory from killing RavenDB client startup.
Published at DZone with permission of Oren Eini, CEO RavenDB , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.