Hi,
This is really interesting, but as far as i know from ravendb it still
stores for now its data/indexes to the local filesystem - and because
of this it is unable to run in azure, let me explain:
Despite numerous similarities, azure instance management is not
designed like amazon ec2 : you don't explicitly allocate named
instances in azure, you only can ask for "give me N instances for this
role".
So from there it is almost impossible to have a controlled sharding
strategy. But things are worst:
azure cloud design delivers global availability of your services by
redounding instances and automatically restore them in case of
failure. And by restoring we mean a blank, fresh local file system,
probably on a different virtual machine -> say by bye to anything
stored locally
Hence as long as ravendb cannot write its data/indexes to one the
azure persistent storage subsystems (blobs/tables/queues/sql), it WILL
fail on azure.
disclaimer : i am not stating that either azure or ravendb are badly
designed - only that there is a strong incompatibility between the
two, for now. And the problem is exactly the same with mongodb.
On 30 juil, 16:30, Mark Rendle <
m...@markrendle.net> wrote:
> Hi.
>
> After a bit of struggling, I have succeeded in getting RavenDB to run
> on a Worker role in Windows Azure.
>
> Worker roles don't allow HttpListener, so I forked the project and
> added a TCP-based implementation of Ayende's IHttp* abstractions.
> Fortunately, thanks to those abstractions, I didn't have to make
> changes anywhere other than the HttpServer.
>
> There is an instance running (as at 30 July 2010) athttp://
ravenworker.cloudapp.net:8080/raven/index.htmlwhich I'll leave
> active until I need the role for something else.
>
> My fork of RavenDB, with the Cloud project in the Samples solution, is
> athttp://
github.com/markrendle/ravendb