Rearchitecture ASP.NET app by replacing SQL Server with NoSQL

Question

We have an ASP.NET app with SQL Server & it is a photo & video sharing site. Details of photos and videos are stored in tables & the files are in the file system.

Database has 75 tables and 225 stored procedures. The app will be ready for production deployment within next 6 months.

Due to longer time growth concerns, we decided to switch to NoSQL (MongoDB) database.

We have few questions regarding the best way to approach this:

• Is it better to deploy the app with SQL Server backend and migrate to NoSQL later?

• OR re-architecture now and rewrite/recreate database, tables, procedures and data layer

• How difficult will it be re-architecture/recode with MongoDB? Any tools or BKMs?

EDIT: Our app is Youtube+Flickr type site where user will share photos and videos with lots of comments, tags and ratings (photo\video & comments).

Is NoSQL a better database to move to? Reason for moving: cost + read query speed

Please help me with you valuable advise.

Thank you very much.

Answer 1

Change is always exponentially more expensive the later it is introduced to a project. This is a core principle of software engineering. You should do this now.

That said, I question your long-term vision. Relational databases, used properly, have a lot of performance in them.

Answer 2

This question raises more questions than answers.

1. Have you benchmarked your current implementation in terms of requests/responses?
2. Why MongoDB out of all possible NoSQL databases? (Don't get me wrong, I love Mongo, but love and hype should not weigh in technology choices)
3. Are you certain you will get the large userbase you're expecting? Why are you so certain?
4. Using stored procs seems to tip off that you aren't using an ORM? Why not?

Generally, I'm against these types of re-architectures. Firstly, you need to get your whole team acclimated to how Mongo affects development. Secondly, your ops team needs to get acclimated to how to deploy and maintain a Mongo installation. More likely than not, this will prevent you from launching in a timeline you want to launch.

I'd say that you should probably launch as is, fix the ORM part if you aren't using one, benchmark your app, benchmark a prototype of your app backed by Mongo and if the performance advantages are so big that it warrants the pain of re-architecture do it.

To your latter question, there aren't any tools right now, as far as I can tell, that'll automate or semi-automate the database import/export from SQL Server to Mongo. There are barely tools to do that for MySQL.