5 ms·
All valid points if compared against a single-instance RDBMS. Except that modern RDBMS used in any large scale web service will also be guilty of these points.
by jsjenkins168 18y ago
All valid points if compared against a single-instance RDBMS. Except that modern RDBMS used in any large scale web service will also be guilty of these points. When you shard/cluster your data across various master/slave DB instances you essentially lose the ability to store your data in a non-atomic normal form, just like SimpleDB. In both a sharded RDBMS and SimpleDB your data is denormalized.
With a DB setup like this (and all major web sites are) you cannot feasibly join, group by (or do associated aggregations), or order by anymore anyway. Constraints are not really a good idea either. It would be nice if SQL was still useful in a situation like this but it just is not.
The days of hugely massive single machine databases is coming to and end if not already dead. Even if you are reporting on massive amounts of data and need to do aggregations across large datasets, then OLAP is increasingly becoming the way to go (again, with fact tables and cube partitions sharded across multiple instances to increase query performance).
- mechanical_fish 18y agoYour argument is good, but it also serves to advance the argument that using SimpleDB for a new web app is premature optimization. Yeah, when your app has millions of users and massive amounts of data you might need to adopt sharding or clustering, perhaps giving up the advantages of a huge single-machine database relative to SimpleDB. And, once you have this problem, it might be a good time to contemplate rearchitecting your entire system around something like SimpleDB. But few web apps start off with millions of users and massive amounts of data, and to deliberately avoid using SQL tools just because they won't scale to Facebook-esque levels of traffic is the very definition of "premature optimization".