RavenDB Setup in enterprise setup with fallback plan

I am thinking/evaluating of using RavenDB for the enterprise application our company is planning to build, My knowledge about this database system is not very wide. So I wonder if someone can help me with following areas,

1. Can RavenDB handle few million records in couple of tables which are related to each other (joins) with reasonable query times?

2. The system will create few thousand entries per day entries couple of tables, there should be a way to bulk move old records in those tables to backup tables (best could be use another data file) so that there is a cap on the number of rows on these key tables. So this db supports bulk data move operations?

3. Does this database is able to take advantage of multiprocessor server?

4. What sort of data recovery options does it provides (is it possible to do hot backups)?

5. If things goes wrong is there a way to switch to another database system without writing entire data layer from the scratch (for example if we use MySQL we could switch开发者_如何学编程 it to oracle without much hassle with NHibernate)?

Overall, my impression is that you are considering building a reporting app that is very row-column oriented. In general, RavenDB is probably not the right technology for such an application, but your mileage may vary.

1. Can RavenDB handle few million records in couple of tables which are related to each other (joins) with reasonable query times?

Yes on the millions of records. Always test to be certain, and consider scaling out, i.e. sharding, to more than one instance to spread the load around.

No on the notion of "related tables and joins". That is not how RavenDB works (and you don't want it to). Read the RavenDB Mythology section on Grokking Document Databases for why this is so. Based on your description, though, you can likely do what you want to do. You'll want to become very familiar with the way RavenDB does indexing.

2. The system will create few thousand entries per day entries couple of tables, there should be a way to bulk move old records in those tables to backup tables (best could be use another data file) so that there is a cap on the number of rows on these key tables. So this db supports bulk data move operations?

It may not be necessary to move the old records. Perhaps leave them where they are and write new ones elsewhere. You can take advantage of sharding in Raven to partition your data into segments based on time if you wish. When you no longer need the older data, remove the shard that contains it (move it to your "backup database").

You could also take advantage of Index Replication and push the results of an index into another store and the Expiration Bundle to delete old documents automatically.

3. Does this database is able to take advantage of multiprocessor server?

Yes.

4. What sort of data recovery options does it provides (is it possible to do hot backups)?

Yes, it is based on Esent and inherits its ability to perform hot backups.

5. If things goes wrong is there a way to switch to another database system without writing entire data layer from the scratch (for example if we use MySQL we could switch it to oracle without much hassle with NHibernate)?

If it is another document database, perhaps. But see point number one above. You will have a very hard time treating a document and relational database as immediately swappable technologies. If you move up a layer of abstraction, persistence is persistence, but I think the way you phrased this question, the answer would be "no".