First some background on the questions. I have never used ravedb before and I’m evaluating it for an upcoming project. The project is very document centric and seems like a great fit so far in my “quick and dirty” test project.
The app itself has very little data, SQLite on a 486 would probably suffice for our database needs. It does have a lot of large image data though, and we would be using ravendb for image storing and as as an image cache. So here’s a few questions:
-
Each document can be used by one or more divisions. We store a list of divisions (ints) on each document and query against it. Is this considered best practice or should this information be in metadata?
-
We will need to make use of replication and sharding. As our data is small I was thinking of replicating all of it to various shards and only sharding on the image data, is this possible?
-
Is it possible to store data in more than one shard? If a document was accessible be Divisions 1,2 and 3 and our sharding was that granular we would like to push the document to the shard the user will be accessing for everything else.
-
Does sharding work just as easily with attachments?
-
I mentioned we would store cached image data (resized images etc). Is it advisable that this be put into a separate database?
Flukus,
Sharding does NOT work for attachments.
You can mix & match replication and sharding, but usually we treat them separately. One database for the sharded data, one database for the replicated data on all the nodes.