NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



ravendb: All content tagged as ravendb in NoSQL databases and polyglot persistence

RavenDB Polymorphic Queries Using Multi-Map Indices

There may be a need to query the various kinds of documents as if they were the same. […] One possibility is to execute 3 separate queries (one for each entity type) and then aggregate the result sets for the end user to view. That may work, but it wouldn’t be very efficient nor elegant. Another possibility is to create a multi-map index that could be queried. Let’s take a look at that approach.

Nice feature. I assume something similar could be achieved in NoSQL databases supporting MapReduce by mapping only the items of interest from the various collections in the database.

Original title and link: RavenDB Polymorphic Queries Using Multi-Map Indices (NoSQL database©myNoSQL)


RavenDB HiLo Id Generation for Bulk Imports

Ayende about RavenDB’s HiLO id generator:

this is perfect for most scenarios. Except one very common scenario, bulk import. When you need to load a lot of data into RavenDB, you will very quickly note that most of the time is actually spent just getting new ranges. More time than actually saving the new documents takes, in fact.

But, notice what happens as times goes by (and not that much time) before RavenDB recognizes that you need bigger ranges, and it gives you them.


Original title and link: RavenDB HiLo Id Generation for Bulk Imports (NoSQL database©myNoSQL)


RavenDB HiLo ID Generation: What, How, Why

Following my comments about RavenDB sharding, I had a very interesting email exchange with Matt Warren about RavenDB HiLo id generation. Matt pointed me to Rob Ashton’s post which covers in more details what is behind RavenDB HiLo:

  1. Waiting until SaveChanges to get ids for saved entities makes writing logic against those entities troublesome
  2. Calling SaveChanges every time a new entity is created makes transactions troublesome
  3. Calling SaveChanges to get the entity id means a call across the wire just to get an entity id, which is expensive
  4. Simply assigning a Guid to the Id makes accessing documents via REST an unpleasant experience
  5. You can’t just assign a random integer, because you’d just get collisions as other clients did the same and tried to save their entities
  6. HiLo provides a method of creating incremental integer based ids for entities in a fashion that is safe in concurrent environments

I do agree with points 2 to 5 above, but I see those as consequences or alternatives to the first one. Assuming that the first point represents indeed a real issue, the trade-off of RavenDB HiLo is offering is the following:

  1. one network round trip to get the Hi value
  2. some locking server side to ensure the next Hi value generation is truly atomic
  3. some more locking client side for generating the Lo values

Hopefully I’m missing something as this doesn’t look to me either less complicated or a good trade-off. Or maybe the hypothesis is wrong.

Original title and link: RavenDB HiLo ID Generation: What, How, Why (NoSQL database©myNoSQL)


RavenDB Sharding

Ayende published two articles on implementing sharding with RavenDB: first one using a default round robin strategy here and the second one sharding based on a set of rules here.

What I’ve noticed in these posts:

  1. RavenDB requires defining the actual shard servers in your sharding implementation (i.e. in your source code)
  2. when performing writes there’re a bunch of round trips (for id generation)

    The key to reducing latency is saving round trips

Original title and link: RavenDB Sharding (NoSQL database©myNoSQL)

RavenDB Tutorial: Building an ASP.NET MVC App Using RavenDB as a Backing Store

One of those getting started guides that can be very helpful when first trying new technologies:

Today we are going to look at how we can use it as the only backing store of an ASP.NET MVC application. In this article, we will see how to build an ASP.NET MVC app using RavenDB Embedded and then publish it to a hosted source.

Using RavenDB as a backing store is actually very easy. In a development environment, all you have to do is install using Nuget package manager and start the Raven.Server.exe from the packages folder. However in a production environment, you may or may not be able to run an additional HTTP server for yourself. If you have a hosting provider where your site is shared with multiple other sites, you may not have the access to run a separate HTTP server. Beauty of RavenDB is that even in such a constrained environment, you can easily run RavenDB and not require SQL Server backend. RavenDB has special embedded variant that allows you to run RavenDB in medium trust.

Original title and link: RavenDB Tutorial: Building an ASP.NET MVC App Using RavenDB as a Backing Store (NoSQL database©myNoSQL)


RavenDB in the Cloud: CloudBird

I’ve missed mentioning the private beta RavenDB hosting service CloudBird in the third wave of hosted and managed NoSQL services. For now, I don’t have any other details about their services. Just an email regform.

Original title and link: RavenDB in the Cloud: CloudBird (NoSQL database©myNoSQL)

Implementing Auto Saves Using RavenDB: NoSQL Tutorials

[…] implementing Auto Save in the RDBMS system could be a problem because of multiple reasons:

  • The schema and overall logic changes to save versioned data in the RDBMS system will be non-trivial
  • There might be validation checks that fail because users kept didn’t fill out some fields at that point.
  • Making periodic (30 second) transactional updates to any live system is not good for overall performance.

A work around would be saving your Object Model to RavenDB directly and if user visits the document after a time out, load both Transactional Data and Object data, compare the timestamp and use the freshest set of data.

By far the best document database usecase I have read about in quite a while.

Original title and link: Implementing Auto Saves Using RavenDB: NoSQL Tutorials (NoSQL database©myNoSQL)


Introducing RavenDB for ASP.NET Developers: NoSQL Tutorials

RavenDB still has a weakness that prevents it from becoming the instant choice of all green-field (a project starting fresh) ASP.NET MVC web projects. Most reporting solutions today work best off RDBMS systems and NoSQL databases are just getting their feet wet with respect to Reporting system connectivity.

So if you are building a system that doesn’t require traditional reporting systems to hook in and retrieve data, RavenDB is the perfect choice. More often that not, that’s not the case (specially Line of Business applications) and hence we tend to fallback on SQL Server/MySQL/Oracle etc.

Leaving aside the (very) short bullet point definition of RavenDB, the conclusion sounds confusing. It makes me wonder if the majority of ASP.NET projects are mostly about reporting.

Original title and link: Introducing RavenDB for ASP.NET Developers: NoSQL Tutorials (NoSQL database©myNoSQL)


6 Ways to Handle Relations in RavenDB and Document Databases

Daniel Lang presents 6 solutions for dealing with relations in RavenDB:

If you’re coming from the sql world, chances are you will be confused by the lack of relations in document databases. However, if you’re running RavenDB you’ve got plenty of options to address this trade-off. I personally cannot think of any situation where I’d wish back SQLServer because of this (there could be other reasons).

Two not recommended:

  • go to the database twice
  • include one document inside the other

Two RavenDB specific solutions:

  • implement a read trigger to do server-side joins
  • implement a custom responder

Two recommended solutions:

  • use the .Include<T>() method
  • denormalize your references

Couple of comments:

  • the difference between “include one document inside the other” and “denormalize your references” is very subtle—the latter suggests including only the information needed for the presentation layer.
  • I think one should consider both “include one document inside the other” and “denormalize your references” and choose one of them depending on the chances of the embedded documents being updated often vs the chances of having the presentation layer changing often
  • except RavenDB, all other document databases seem to offer only two options: “go to the database twice” and “denormalize your references”
  • when Redis will release its version embedding server-side Lua, that could be used as a form of stored procedure

Original title and link: 6 Ways to Handle Relations in RavenDB and Document Databases (NoSQL database©myNoSQL)


RavenDB: Debugging and Troubleshooting

Given that this is something new and an open source project you may find yourself searching for help and more guidelines. 


  • Use RavenDB REST interface with curl
  • RavenDB operations are logged on the console app
  • RavenDB indexing is a background process so there is a gap between a write and index update
  • RavenDB can run in embedded mode

I bet Ayende has more tricks up his sleeves so hopefully he’ll jump in to share.

Original title and link: RavenDB: Debugging and Troubleshooting (NoSQL database©myNoSQL)


Data Modeling for Document Databases: An Auction and Bids System

Staying with data modeling, but moving to the world of document databases, Ayende has two great posts about modeling an auction system: part 1 and part 2. They are great not only because it’s not the Human-has-Bird-and-Cat-and-Dogs example, but also because he looks at different sets of requirements and offers different solutions.

That is one model for an Auction site, but another one would be a much stronger scenario, where you can’t just accept any Bid. It might be a system where you are charged per bid, so accepting a known invalid bid is not allowed (if you were outbid in the meantime). How would we build such a system? We can still use the previous design, and just defer the actual billing for a later stage, but let us assume that this is a strong constraint on the system.

Original title and link: Data Modeling for Document Databases: An Auction and Bids System (NoSQL database©myNoSQL)

NoSQL Screencast: Building a StackOverflow Clone With RavenDB

Ayende and Justin pair to model a StackOverflow website clone with RavenDB. And they cover:

  • Map/Reduce indexes
  • Modelling tags
    • Root aggregates
    • Metadata
    • Active tags
  • Facets
  • Performance:
    • Built-in caching
    • Lazy loading
    • Aggressive caching
  • RavenDB profiler