Choosing The Right Database For Your Cloud Application

Editor's Notes

• #10: Transactions: There are use cases where it isn’t actually possible for users to demand conflicting updates to the same data. Query-only data warehouses for one. But the heart and soul of transaction processing demands the ability to deal with such potential conflicts – financial transactions, resource management, metering and billing. And in a world of multi-platform access the same user can be updating their own data concurrently from multiple devices. SQL Winston Churchill famously described Democracy as the worst possible form of government - except for all the others that had ever been tried. SQL has survived and prospered for decades, in spite of countless competitive solutions, because it offers a powerful, elegant, easy-to-learn way to do things with data. It is not perfect and over the years it has had to grow and adapt, but it is still there and is a widely available skill in the workforce. Even the NoSQL databases quickly realized they needed SQL – all the major players in that world are scrambling to add some kind of SQL support. Scale-out The cost and complexity of traditional relational databases multiplies as the scale increases. They demand larger and larger machines as they scale up. Scale-out databases make use of multiple commodity hardware nodes to scale-out, adding more processing power and data storage by adding cheap computers that are simple to manage and easy to virtualize. This not only breaks the lock in to more an more complex systems, it also removed the ceiling on scale as you add more and more nodes. But equally importantly, in a cloud environment (public or private), it means it is possible to scale back in and save the cost oif unnecessary resources, when demand falls. And many, many use cases have sharp peaks in demand - within a day, a month, a quarter, a year. Scale-out means you can deliver elastic capability to match the elastic demand, Geo-Distributed Users are increasingly distributed around the country, around the world. The same user will want to access their data from multiple locations. And they expect that data to be consistent and equally available wherever they are. Web applications make this possible. Or rather they make it appear possible. If your data is all in one data center, then no matter where the users are, their data access request have to be carried around the world to that one location. With bottlenecks, network latency and vulnerability all inevitable consequences. Geo-distribution is about taking the data to the users so they can access it quickly and delivering locally the processing power to meet local demand. It is about replicating data, for resilience to failure and continued operation under failure. It is about flexibility.
• #12: Transactions: There are use cases where it’s not possible for users to demand conflicting updates to the same data. Query-only data warehouses for one. But the heart and soul of transaction processing demands the ability to deal with such potential conflicts – financial transactions, resource management, metering and billing. And in a world of multi-platform access the same user can be updating their own data concurrently from multiple devices. SQL Winston Churchill famously described Democracy as the worst possible form of government - except for all the others that had ever been tried. SQL has survived and prospered for decades, in spite of countless competitive solutions, because it offers a powerful, elegant, easy-to-learn way to do things with data. It is not perfect and over the years it has had to grow and adapt, but it is still there and is a widely available skill in the workforce. Even the NoSQL databases quickly realized they needed SQL – all the major players in that world are scrambling to add some kind of SQL support. Scale-out The cost and complexity of traditional relational databases multiplies as the scale increases. They demand larger and larger machines as they scale up. Scale-out databases make use of multiple commodity hardware nodes to scale-out, adding more processing power and data storage by adding cheap computers that are simple to manage and easy to virtualize. This not only breaks the lock in to more an more complex systems, it also removed the ceiling on scale as you add more and more nodes. But equally importantly, in a cloud environment (public or private), it means it is possible to scale back in and save the cost oif unnecessary resources, when demand falls. And many, many use cases have sharp peaks in demand - within a day, a month, a quarter, a year. Scale-out means you can deliver elastic capability to match the elastic demand, Geo-Distributed Users are increasingly distributed around the country, around the world. The same user will want to access their data from multiple locations. And they expect that data to be consistent and equally available wherever they are. Web applications make this possible. Or rather they make it appear possible. If your data is all in one data center, then no matter where the users are, their data access request have to be carried around the world to that one location. With bottlenecks, network latency and vulnerability all inevitable consequences. Geo-distribution is about taking the data to the users so they can access it quickly and delivering locally the processing power to meet local demand. It is about replicating data, for resilience to failure and continued operation under failure. It is about flexibility.
• #13: Scale out implies elasticity, to some degree, however speed of elastic scale out is important. If your peak lasts a day and it takes a week to scale up and down, before and after, that might be very problematic – and it’s not viable for unpredictable peaks. And I don’t wish to be unfair, so I should point out that SQL databases do have distribution offerings, most notably sharding and synchronous replication – or two-phase commit. But anyone who has tried to operate one of thes solutions will be well aware of the complexities and limitations And above all I should make it clear that there are use cases, as I have said, that don’t require all these characteristics. Data warehouses, Append only inset applications, loss tolerant applications.
• #18: Our customers have invested in their skills, processes and products. Those are usually based around SQL transactional systems. But now they need to take those products to the cloud. They need them to be continuously available. They need them to operated symmetrically in two or more datacenters. They need them to scale out economically. And accommodate multiple customer instances without breaking the bank in operating costs. Their traditional SQL databases just won’t do this. They have tried sharding, database synchronization, replication… They have complex and brittle DR wqith active passive