+972 52-548-6969
RavenDB & Managed Storage
One of the things that I really wanted with to do with RavenDB is to create something that is really easy to use for .NET developers. I think that I have managed to do that. But the one big challenge that we still had was running everything using managed storage.
As you can imagine, building transactional, crash-safe, data stores isn’t particularly easy, but we actually did that, and now RavenDB can run in managed core. That has other implications, like being able to run completely in memory. Which means that you can test your RavenDB code simply by using:
var store = new DocumentStore { RunInMemory = true; }
And just use this as you normally would. For that matter, you can ask the RavenDB server to run in memory as well (extremely useful for demos):
Raven.Server.exe /ram
As a side note, I am going to be posting a lot about the recent storm of features that were just added to RavenDB.
Comments
Have you tested this on Mono now?
Love this feature, I've been looking forward to this ever since you first mentioned it. Which version of Raven is this in, unstable/stable/commercial?
hopefully one of the "exciting" features will be proper sharding...
from what I've read in docs it's not exactly what I've seen elsewhere (say mongoDB), might be because of Raven's support for transaction which mongoDB lacks...(upon many other things)
as a developer __I don't really want to be thinking in advance about whether my architecture is horizontaly scalable, spreading different docs to different databases and so on... (as suggested by docs). Also it's hard to predict how each document type size will grow in future...
I just want to deploy my application using say one db server and once successful, spread my database __evenly to 3 servers, or 6 or 10...without shutting the app down or changing any application code.
Also the database size "balancing" will be done by DB server itself.
of course there are hundreds of cases where RavenDB sharding might be sufficient, but for me the "invisible problem free sharding" was the selling point of MongoDB for startup companies...
by "proper" sharding I've meant implemented on the server and not on the client (as I believe it is right now) - which isn't ideal (reminds me of RDBMS system implementation).
I __love RavenDB and it definitely have many nice features, just forgetting about horizontal scalability right now (when I'm starting my current project) would be big plus...
Yeah it would be good if the persistence layer didn't leak so much to the developer/app about sharding; it would be nice if it would be automated and self balancing.
@Marcus: I have tested this in Mono. There were some Bugs in Mono that needed to be fixed first (and Marek Safar fixed all of them within a day after I reported them). There are still some Mono-Bugs left, which I currently work around by some minor changes to the Raven code, but it basically works! I've built a simple CRUD-App that ran just fine on Debian/Squeeze with the current Mono HEAD.
While beeing at the .Net Open Space in Leipzig this weekend, I hopefully will find some more time to work on the remaining Mono issues next week (e.g. getting all the unit test pass on Mono).
cowgaR,
RavenDB supports sharding OOTB.
Re-balancing shards on the server introduces a high level of complexity, so I don't think we will do that just yet.
Andrew,
What leakage?
You create a ShardedDocumentStore and then you proceed to work naturally.
Great news!! Do you plan include this manage store in Rhino.Queue for Rhino-ESB?
Fravelgue,
I am going to do a whole new queuing system :-)
can't wait to see your queuing system. Will it work in Silverlight? I hope so. It would be great to see Alexandria in SL
Great news. Would upgrade path be just a drop of new dll's?
Nice! can this also be specified somehow using the connection string property? eg. Url = <memory or something of the short?
Dob,
Yes, it will run in SL.
Jakub,
No, it isn't.
The file format is quite different.
Dan,
As a matter of fact, yes: memory=true
Comment preview