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?
asked Apr 18, 2013 at 14:22
-
2Huh? Scaling data for reads is easy - especially if the data can be a bit stale. Scaling data for writes, on the other hand, is a pretty complicated problem. There is no magic "web scale" button for any RDBMS.– Aaron BertrandApr 18, 2013 at 14:29
-
4The main reason not to do this is that you're paying DB licensing costs for any CPU capacity you use on that system. If you run app code that doesn't need to be there you're paying 1-2 orders of magnitude over the money for your CPU capacity.– ConcernedOfTunbridgeWellsApr 18, 2013 at 14:30
Add a comment
|
1 Answer
"Isn't it possible to scale database servers through virtualization, like forever?"
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:
http://en.wikipedia.org/wiki/CAP_theorem
The fundamental problem for scalability in database is in the consistency part of the CAP theorem - all those ACID guarantees that databases have.
"Is there any reason why I shouldn't do it in terms of scalability?"
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.
