Correction: In a comment, Justin Crites points out, correctly, that Simple DB does not offer ‘relational’ database functionality, in the sense that it is not an RDBMS. While this is true, I think Simple DB clearly offers functionality which many people get, perhaps inappropriately, from a relational database system.
Amazon continue to expand their excellent infrastructure web services. Simple DB – relational databases in the cloud. I’m definitely going to have a look at this – clustering/replicating databases for resilience and performance was extraordinarily difficult when I was developing and supporting enterprise systems a couple of years ago. In fact, more often than not, we’d cluster and load-balance all the layers in the enterprise stack except for the database, and then just rely on a singe very expensive box running Oracle Enterprise 9i or whatever the equivalent is nowadays.
Like the other Amazon infrastructure services (S3, EC2 you pay for what you use. Linear costs. Simple. Brilliant.
> Simple DB – relational databases in the cloud.
Simple DB is actually very different from a relational database! It is unstructured and schemaless, something like CouchDB, but supporting more structure than a key-value pair database would (like Berkeley DB). You can insert any arbitrary data you want without having to specify the structure in advance, or explain how records relate to one another.
While SimpleDB supports some simple query operators, if you look at what is provided, it is very different from relational operators: “QUERY your data set using this simple set of operators: =, !=, =, STARTS-WITH, AND, OR, NOT, INTERSECTION AND UNION”. SimpleDB has no concept of tables, nor joins between them, which are fundamental parts of (SQL) relational DB theory.
SimpleDB will have very good performance, but it is not the kind of service (being a web service, after all) that will be able to match a local database. A high performance system might use SimpleDB as the authoritative information store, fronted by some local caches on machines that would otherwise query it.
Hope this helps!
Justin,
thanks for the very useful comments. To clarify my point about replication/resilience: it was the simpler, high-order entity/lookup type operations which I remember wanting to replicate especially – the sort of data which was being used again and again in various applications. For the application-specific persistence, we had started to examine using data stores embedded into the applications for simplicity, performance and manageability. This tended to push relational operations out of the data store and up into the application layer. The alternative was using an Oracle DB to provide the simplest database functionality which was a good example of the proverbial sledgehammer….
I take your point that Simple DB does not provide relational database functionality. But clearly, we might consider using it where once we defaulted to a local MySQL instance or similar. And surely much of the relational logic in SQL is designed to implement set operators like ‘UNION’ and ‘INTERSECTION’?
You point out also that Simple DB is ‘schema-less’ which is something I hadn’t consciously noted. This would seem to be a significant difference from the RDBMS model. But we’ve been developing web applications for years now where the model is actually managed in the application rather than the DB.
Your definition of the high performance system would seem to match the sorts of developments going on with cutting-edge web application development – the authoritative datasource fronted by layers of caching – even as far as the local PC with Google Gears for example.
Thanks again for the comments.
Paul
Hi Paul,
You might as well check Brainwave Platform which has a schemaless database called Poseidon packed along with its complete development and deployment suite.
-Syd