|
On 07/14/2012 09:21 AM, B Sreejith
wrote:
Sounds like your client / boss has a case of buzz-word-itis. "Scalability" means lots of different things: - How well it copes with growth of data sizes - How well it copes with growth of query rates / activity - How well it copes with larger user counts (may not be the same as prior) - Whether it's easily sharded onto multiple systems - Whether it has any locking choke-points that serialize common operations - .... Perhaps most importantly, your database is only as scalable as your application's use of it. Two apps can use exactly the same database structure, but one of them can struggle massively under load another one barely notices. For example, if one app does this (pseudocode): SELECT id FROM customer WHERE .... FOR attribute IN customer SELECT :attribute.name FROM customer WHERE id = :customer.id IF attribute.is_changed THEN UPDATE customer SET :attribute.name = :attribute.new_value WHERE id = :customer.id END IF and another just does: UPDATE customer SET attribute1 = value1, attribute2 = value2, attribute3 = value3 WHERE .... The first will totally melt down under load that isn't significantly different from idle as far as the second one is concerned. That's a ridiculously bad example for the first app, but real examples that aren't much better arise from badly tuned or badly written object relational management systems. The classic "N+1 selects" problem and massive inefficient multiple left outer joins are classics. Thus, you can't really evaluate the scalability of the database under load separately from the application that's using it and the workload. -- Craig Ringer |
