Choosing The Right Database For Your Cloud Application
•Download as PPTX, PDF•
1 like•1,023 views
This document discusses choosing a database for cloud applications and introduces NuoDB as a solution. It notes that traditional databases do not scale well in the cloud while NoSQL databases lack transactions. NuoDB is presented as fixing this problem by being transactional, scalable, geo-distributed, and using SQL while running on commodity hardware and cloud platforms. Customer stories show how NuoDB provided benefits like continuous availability, ease of migration and management, and scalable performance. The document provides a high-level overview of NuoDB's architecture including its transaction engine, storage manager, and ability to elastically scale out across data centers.
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (17)
Similar to Choosing The Right Database For Your Cloud Application
Similar to Choosing The Right Database For Your Cloud Application (20)
More from NuoDB
More from NuoDB (12)
Recently uploaded
Recently uploaded (20)
Choosing The Right Database For Your Cloud Application
- 1. Copyright © 2015 NuoDB Choosing a database for cloud applications
- 2. Topics What is the cloud database problem? Lift and shift right? Not quite. OldSQL + complexity + compromise NoSQL + revolution + skills shortage – transactions Why does NuoDB fix it? Who says so? What we are learning from our customers How does it do that? A little peek under the hood Copyright © 2015 NuoDB ✗ ✗
- 3. What is the cloud database problem? Copyright © 2015 NuoDB
- 4. Traditional Application Scaling Users Application Database Storage ✓cloud friendly Web Servers scale out App Servers scale out “OldSQL” Servers don’t scale out Storage Servers scale out ✗ ✓cloud friendly ✓cloud friendly
- 6. Critical database dimensions *with apologies to Winston Churchill multiple users update multiple records - without getting in a mess “the worst data language - except for all the others that have been tried”* for elasticity, for cloud, for scale! Resilient, available, “local everywhere” Transactional Geo-distributed Scale-out SQL
- 8. Database characteristics 12 OldSQL NewSQL NoSQL ACID Transactional SQL Scale Out Geo-distributed Elastic Sharded/ Shared Nothing Synchronous Replication
- 9. Customer Stories Copyright © 2015 NuoDB
- 10. What our customers tell us: Case Study III Situation U.S. ISV. Customers across N America, S America and Europe. Deployed on dedicated equipment in customer data centers. Issue Customers increasingly want cloud-friendly products. Management of DR and upgrade complex & challenging. Why NuoDB Continuous Availability. Geo-Distribution. Ease of Management. Benefits Active/Active/Acti ve True multi-data center operation offers richer customer experience and better roaming experience. Rolling Upgrades A torturous upgrade process that carries real risk of outage, hugely simplified. Ease of Migration Rich SQL support in NuoDB supports a straight forward and swift migration.
- 11. What our customers tell us: Case Study III Situation European ISV Innovative mobile product. Piloted in emerging markets. Issue Appliance deployment not attractive in major markets. Performance not sufficient for major markets. Why NuoDB Cloud deployment. Scale-out performance. Benefits Cloud Offering Attractive pricing and packaging for target markets. Scale-out performance Ability to deliver in target markets. Ease of Migration Simple migration achieved improved performance on like-for-like kit.
- 12. What our customers tell us: Case Study III Situation Global cloud solutions provider. Built/acquired cloud technology stack. White-labeled by private cloud providers. Issue Current management database inadequate. No DBaaS operational database offering. Why NuoDB Active/Active Geo-distribution Elastic scale-out performance Strong SQL capability Benefits Scalable cloud management Geo-distributed scalable solution for namespace, compute management, metering, etc. Operational simplicity Ease of management & flexibility Attractive SQL offering Deliver customers familiar platform and tools with swift migration
- 13. What Our Customers Tell Us Copyright © 2015 NuoDB • Geo-distributed • Elastic Scale Out • Transactions • SQL • Existing skills They want to get They don’t want to lose
- 14. What is NuoDB distributed, transactional, SQL database, engineered for the cloud Copyright © 2015 NuoDB because single data center is not enough; active-active-active, geo-distribution is becoming table stakes because ACID is vital for many critical use cases because tools and skills are in place; re-engineering and re-skilling costs are prohibitive scale out elastic continuously available low administration
- 15. Management Storage Transaction brokers/agents NuoDB Architecture : Multi-tiered Database Archives Transaction EngineTransaction Engine Storage ManagerStorage Manager
- 16. brokers/agents TETE SMSM NuoDB Architecture : Elastic scale out Database Archives TE TE
- 17. TETE SMSM NuoDB Architecture : Distributed Database Archives TE TE brokers/agents
- 18. TETE SMSM NuoDB Architecture : Continuously Available Database Archives TE TE brokers/agents
- 19. TETE SMSM NuoDB Architecture : Distributed Cache Database Archives TE TE brokers/agents AA A A ✗✓
- 20. Copyright © 2015 NuoDB A Q &
- 21. Engineered for the cloud Copyright © 2015 NuoDB Scale-out SQL Database
Editor's Notes
- 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.
- 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.
- 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.
- 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