Isn't it possible to scale database servers through virtualization, like forever? I like to keep most of the workload on database server because it optimizes queries and the architecture decreases the bandwidth use between db server and web server. Is there any reason why I shouldn't do it in terms of scalability?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
closed as not a real question by Phil, Marian, Mark Storey-Smith, ypercubeᵀᴹ, Cade Roux Apr 18 '13 at 14:48
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.
Yes, you can make more and more database servers and you can also make a larger and larger database server (but the scale up limit can be reached very quickly), but in the scale out scenario are the servers you mention supposed to cooperate in any way or are they completely independent.
The CAP theorem doesn't just apply to "database" servers, but since web servers aren't really considered as a "write" part of a distributed data store, they are usually considered to be easily scalable by themselves:
The fundamental problem for scalability in database is in the consistency part of the CAP theorem - all those ACID guarantees that databases have.
The reasons you may not want to put extensive processing in your database depend a lot on what your scalability path looks like. It can make sense to put processing in the database instead of shipping a large amount of information out of the database that is simply discarded. But scalability methods can vary from scaling up to scaling out, and even scaling out mechanisms can vary.
Ultimately the answer as to what to do with your architecture is going to depend upon your requirements and problem domain and expected future path, none of which you have given in your question.