http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Andrew, That depends on the mode that you use. If you use sharding, it will split data among the shards, and it can handle add nodes dynamically. Removing nodes (or node failures) requires replication to be able to recover that, which is something that Raven does. http://ayende.com/4499/why-raven-db#comment56http://ayende.com/4499/why-raven-db#comment56Sat, 15 May 2010 08:57:45 GMTAyende, I am interested in how Raven DB handles failure, and adding/removing new nodes to scale? Thanks! http://ayende.com/4499/why-raven-db#comment55http://ayende.com/4499/why-raven-db#comment55Sat, 15 May 2010 03:04:15 GMT@Paul why would that be? I'm not an expert, but MySql is just a plain ordinary GPL license, nothing in there specifically for OS usage etc :) http://ayende.com/4499/why-raven-db#comment54http://ayende.com/4499/why-raven-db#comment54Fri, 14 May 2010 14:36:01 GMTSteve, Yes, it is possible, just not exposed by default, I'll add that. http://ayende.com/4499/why-raven-db#comment53http://ayende.com/4499/why-raven-db#comment53Fri, 14 May 2010 13:54:23 GMTLopes, Re: Mono, right now, it won't run there, and running there is a low priority item. Re: why I wrote RavenDB, see the post :-) http://ayende.com/4499/why-raven-db#comment52http://ayende.com/4499/why-raven-db#comment52Fri, 14 May 2010 13:53:19 GMTLooks great Oren ... started testing it yesterday. Got a few questions: - Is it possible to 'disable' the help pages in the server ?(removed from the HTTP UI + prevent them being stored inside the database itself) - Why is there already a ~100 Mb hit taken by the server after 1st initialization (might have an impact for embedded scenario). - I got a crash when using a TransactionScope around a session ... will send u small test case about it. On top of what was already said, it looks amazingly cheap to do Domain-Driven oriented prototyping using RavenDB. Also, can't wait to test it paired with NServiceBus. http://ayende.com/4499/why-raven-db#comment51http://ayende.com/4499/why-raven-db#comment51Fri, 14 May 2010 13:16:03 GMTHi Ayende, First, thanks for answering this question properly and with much details. I am keen to say it looks good on paper but a few features are not yet ready. Still I believe they will. I know you are a devoted developer. I still have 2 concerns about the project. They affect developers like me but probably not most of the others. - Is the project going to be cross platform ? I do like C# and .Net but I do develop mostly on Mac and target platforms from Linux to Windows. So, I switched to Mono for .Net which open cross platform opportunities. - I know a bit about Tokyo, Redis, Couch but I settled for MongoDB. To be fair, I use it with Python not with .Net (not even IronPython). Still, this project like many others have been around for a while and are field tested with a big community support and several commiters, sometimes with big names using them. Often they originated from one of those big .com. My concern here is about real life usage. RavenDB is brand new and doesn't really have this background. Still I understand there is a lack of a .Net friendly option, but I believe you could have contributed an elegant solution to reduce the amount of friction .Net developers have with the others. There is always a possibility to build on top of the low-level APIs these stores provide. That said, I wish I could work on such a project. There is a lot of great problems to solve here and hours of fun. Cheers. http://ayende.com/4499/why-raven-db#comment50http://ayende.com/4499/why-raven-db#comment50Fri, 14 May 2010 11:08:59 GMT@Rob - ISTM you have to pay for it if you install it on a Windows Server http://ayende.com/4499/why-raven-db#comment49http://ayende.com/4499/why-raven-db#comment49Fri, 14 May 2010 09:10:20 GMTkudos for System.Transactions support http://ayende.com/4499/why-raven-db#comment48http://ayende.com/4499/why-raven-db#comment48Fri, 14 May 2010 08:30:55 GMT@Jason - it's a misconception that Mysql has to be paid for to use it commercially http://ayende.com/4499/why-raven-db#comment47http://ayende.com/4499/why-raven-db#comment47Fri, 14 May 2010 06:31:57 GMTJason, If you distribute your code, including if you put it on a server, you need to make it OSS. Yes, there will be a commercial version, under pretty standard commercial license. We will announce it all on the 18th http://ayende.com/4499/why-raven-db#comment46http://ayende.com/4499/why-raven-db#comment46Fri, 14 May 2010 06:03:41 GMTSo your main license is AGPL - does that mean everything built with it has to be open source? You can't even build a utility or tool without releasing the source? Or is it more like LGPL where things can be closed source, but only if they just link to the library. I am not familiar with AGPL. Are you planning to release a commercial version? Under what terms? It seems to me that most open source projects that try a commercial version don't really do that well. I mean some do, but MySql probably has 1000 users who use it commercially illegally for every one paying user. Maybe that is ok. I like the concepts you have here. Definitely love the .Net 4 and task library concepts. These are things that will set you apart. http://ayende.com/4499/why-raven-db#comment45http://ayende.com/4499/why-raven-db#comment45Fri, 14 May 2010 04:13:43 GMTJoel, Please join the mailing list and give me some more information about what you ned. http://ayende.com/4499/why-raven-db#comment44http://ayende.com/4499/why-raven-db#comment44Thu, 13 May 2010 22:28:18 GMTGuillaume, What Mongo did is to create a shared database, which is probably going to hurt them, when the mongos server dies. It is simpler on the face of it, because you don't have to deal with a lot of things, but it also mean that you introduced a single point of failure. OSS is AGPL, Commerical is pretty standard commercial license. I am not quite sure what you are actually asking here. http://ayende.com/4499/why-raven-db#comment43http://ayende.com/4499/why-raven-db#comment43Thu, 13 May 2010 22:27:35 GMTMaybe I haven't looked at the right part of the source code, and I'm just missing it, but it would be really nice if the client library exposed Begin/End methods that forward to the Begin/End methods on WebRequest. I know that these methods are a pain to use from C#, but they could be trivially transformed into async workflows in F# for some elegant code that doesn't tie up any ThreadPool threads while waiting for a response from the DB server. http://ayende.com/4499/why-raven-db#comment42http://ayende.com/4499/why-raven-db#comment42Thu, 13 May 2010 19:37:00 GMTAyende, How about 999 internet kudos points instead :) Seriously though, high-perf, scalable comet / web socket servers are all the rage now, that I don't think you would have too hard a time commercializing it. Apply a pluggable API for custom application events/notifications and you've got yourself a product! Make it horizontally scale and you got even more products! We've developed a custom-specific c# windows service at work (to handle all of mflow's notifications), but it uses long-polling so pretty in-efficient, next implementation will be node.js + web sockets ftw! @Paul, btw in-case you didn't know your blog is down :( http://ayende.com/4499/why-raven-db#comment41http://ayende.com/4499/why-raven-db#comment41Thu, 13 May 2010 17:05:46 GMTPaul, Only if someone would pay for it http://ayende.com/4499/why-raven-db#comment40http://ayende.com/4499/why-raven-db#comment40Thu, 13 May 2010 16:43:53 GMTCan't disclose the chat server as it's client confidential, but my point still holds as my chat test client *was" a server; i.e. it was sending out requests to the chat server, listening for the responses, and then performing one or more actions involving sending different traffic. Apart from the fact that the RFC is a mess, I thought at the time that a nice C# implementation of a chat server would be a good idea - Oren's next project? ;-) http://ayende.com/4499/why-raven-db#comment39http://ayende.com/4499/why-raven-db#comment39Thu, 13 May 2010 16:41:08 GMT@Paul Hatcher >>This is easily achieved in C# as the underlying I/O competition ports implemention of the Windows O/S is exposed to the C# Socket class. >>A little while ago I had to write a chat server test client and I could quite easily simulate 100K clients on a single PC using this technique and CPU never went above 10% Those are very good client numbers, though I imagine the high-performance server handling the load on the other end would've been more difficult to implement. What was the chat server software like, i.e. was it native? as those single-server numbers are very impressive? Otherwise it may be time to do some benchmarking of my own to compare against the leading node.js chat servers. Do you know of any open source high-performance chat servers available that are using this technique? Could prove very insightful and make a good blog entry :) http://ayende.com/4499/why-raven-db#comment38http://ayende.com/4499/why-raven-db#comment38Thu, 13 May 2010 15:55:49 GMTSounds awesome, can you port it to Ruby ;) http://ayende.com/4499/why-raven-db#comment37http://ayende.com/4499/why-raven-db#comment37Thu, 13 May 2010 15:40:38 GMTDemis >> Now we all know that you are a very accomplished developer but the managed .NET runtime will not allow even you to match the speed >> of a high-performance network server written in C which lets you access low-level event-based async IO This is easily achieved in C# as the underlying I/O competition ports implemention of the Windows O/S is exposed to the C# Socket class. A little while ago I had to write a chat server test client and I could quite easily simulate 100K clients on a single PC using this technique and CPU never went above 10% http://ayende.com/4499/why-raven-db#comment36http://ayende.com/4499/why-raven-db#comment36Thu, 13 May 2010 15:28:58 GMTAyende, The overall published benchmarks for Redis are maintained here: [http://code.google.com/p/redis/wiki/Benchmarks](http://code.google.com/p/redis/wiki/Benchmarks) Although these numbers don't mean much unless you're doing an apples-to-apples comparison against a competing solution. It is easy enough to test though because redis comes with a redis-benchmark utility to measure the performance you can get in your environment. The different supported server platforms will be a problem though since RavenDB is supported to run on windows and Redis is supported to *NIX servers. I host unsupported 32bit windows builds here but they use Cygwin so would not be a fair comparison: [code.google.com/.../RedisWindowsDownload](http://code.google.com/p/servicestack/wiki/RedisWindowsDownload) The best benchmark will probably need to have the same server dual-booting into a vanilla windows and linux distro (as they are the expected production platforms): You should be able to easily configure redis to a similar setup in how RavenDB operates as everything is configurable in a simple redis.conf file. I actually think comparing against RavenDB will prove to be an interesting exercise - I will be curious of the results as well! http://ayende.com/4499/why-raven-db#comment35http://ayende.com/4499/why-raven-db#comment35Thu, 13 May 2010 14:45:25 GMTDemis, Do you have any numbers? http://ayende.com/4499/why-raven-db#comment34http://ayende.com/4499/why-raven-db#comment34Thu, 13 May 2010 14:28:38 GMT@Ayende >>When I am talking about transactions, I am talk about never losing writes. >>Redis' append only format sounds similar, but I haven't been able to find any mention of the perf hit that this cause. >>To give you an idea, Raven's approach is fsync after every command. And I as well, in addition to data integrity. Redis supports multiple configurable modes including 'fsyncalways' so you never lose a write as well as 'fsync when one run in the event loop exists' - so that can potentially write tens of commands at once. Although its heavily optimized, this obviously has a perf hit (ou would experience as well) since it needs multiple sync-hits to disk depending on your configuration but its a necessary trade-off for consistency. http://ayende.com/4499/why-raven-db#comment33http://ayende.com/4499/why-raven-db#comment33Thu, 13 May 2010 14:25:33 GMTThis is intriguing to me. I'm just now jumping on the NoSQL movement and love what I'm seeing. The performance aspect is really what's got me sucked it. I see a a method of using the document DB as the real-time data store for the web application and running a background process that pulls the data into a SQL DB for the reporting team to use (SQL reporting services). I think this is the best of bother worlds. From what I've seen the performance can be so good that I may be able to eliminate a good deal of data caching. I'm hoping RavenDB's read performance is on par with MongoDB (my current NoSQSL favorite). I'd love to see some bechmarks to compare. It will also be important to compare the write speeds considering RavenDB is transactional, but MongoDB isn't. Great work and thanks for sharing it! http://ayende.com/4499/why-raven-db#comment32http://ayende.com/4499/why-raven-db#comment32Thu, 13 May 2010 14:11:58 GMTDemis, When I am talking about transactions, I am talk about never losing writes. Redis' append only format sounds similar, but I haven't been able to find any mention of the perf hit that this cause. To give you an idea, Raven's approach is fsync after every command. And no, the chat server isn't OSS, commercial work for an old client. The embedded version requires no privileges. http://ayende.com/4499/why-raven-db#comment31http://ayende.com/4499/why-raven-db#comment31Thu, 13 May 2010 14:05:48 GMT@Ayende I've noticed on the tweet-osphere that you've been AFK for 4 hours during NHibernate talk, congratz I heard it was successful. So I'll wait for you to catch up to replying to all the comments before replying. >>I can do thousands of writes per second, _transactionally_. >>Your examples are all for software that gets data and save it to memory, flushing to disk on the background, if at all, totally different requirement and problem set. Just in-case its implied CouchDB, MongoDB and Redis all support atomic operations, while Redis supports custom atomic transactions (with optional command pipe-lining) albeit maybe not as flexible as RavenDB but suitable for a large class of application, high-level application locking can achieve the rest. Also because it was mentioned Redis supports a recoverable Append-only file mode and trivial replication in addition async background saves. Agreed they are targeting 2 different ends of the NoSQL solution spectrum, but there are still some overlapping problem sets. >>I wrote a .NET chat server that supported 20,000 connected clients easily. >>It is really not that hard, and yes, I used async IO for pretty much everything. Sounds awesome, looks like it will still be very relevant today - it's not open source by any chance? :) >>It would be trivial to add support to that for any platform that can make HTTP calls. ... >>The client is communicating with the server using HTTP+REST, there isn't any secret backdoor for .NET only stuff. Ok I didn't know that - it makes sense I guess, which means you must have some cool LINQ 2 REST projection going on under the covers - sounds cool. Even though it may be _trivial_ it is really not an option for alternate application platform developers unless a supported client exists. This is one of the things you've given up by going your own route. Hopefully RavenDB will be hugely successful and you will get external developers donating rich client support. Although I suspect the .NET IDIOMS which is a benefit here may also be a disadvantage for 'foreign clients'. Tell you the truth, the embedded option sounds very compelling in which case you stand a very good chance at succeeding in db4o's embedded persistence space, so I hope you look to fully support this feature. Will it require admin privileges? http://ayende.com/4499/why-raven-db#comment30http://ayende.com/4499/why-raven-db#comment30Thu, 13 May 2010 13:48:43 GMTGlad to hear there are plans for replication support. High Availability is something our DocumentDb needs! http://ayende.com/4499/why-raven-db#comment29http://ayende.com/4499/why-raven-db#comment29Thu, 13 May 2010 13:45:03 GMTJason, Yes, that is one of the major reasons, but not the only one. Flexible data model, querying capabilities and schema less nature means that it is suitable for a lot of other tasks. By default, no. Raven allows you to customize it, though. http://ayende.com/4499/why-raven-db#comment28http://ayende.com/4499/why-raven-db#comment28Thu, 13 May 2010 13:35:17 GMTGuillaume, What do you mean, Mongo doesn't scale? My reading says that it is very scalable. Raven currently writes to disk before returning to the user. I am thinking of adding untransactional writes, but I am not sure that I want them http://ayende.com/4499/why-raven-db#comment27http://ayende.com/4499/why-raven-db#comment27Thu, 13 May 2010 13:33:28 GMT