Watch a replay of the webinar: https://www.youtube.com/watch?v=BtzPgLBy56w
451 Research and NuoDB outline the key database criteria for cloud applications. Explore how applications deployed in the cloud require a combination of standard functionality, such as ANSI SQL, and new capabilities specifically required to take full advantage of cloud economics, such as elastic scalability and continuous availability.
Powerpoint exploring the locations used in television show Time Clash
Key Database Criteria for Cloud Applications
1. KEY DATABASE CRITERIA
FOR CLOUD APPLICATIONS
+ Matt Aslett, Research Director, Data Platforms and
Analytics
+ Ariff Kassam, Vice President, Product
2. Copyright (C) 2016 451 Research LLC
2
451 Research is a leading IT research & advisory company
Founded in 2000
300+ employees, including over 120 analysts
2,000+ clients: Technology & Service providers, corporate
advisory, finance, professional services, and IT decision makers
50,000+ IT professionals, business users and consumers in our research
community
Over 52 million data points published each quarter and 4,500+ reports
published each year
3,000+ technology & service providers under coverage
451 Research and its sister company, Uptime Institute, are the two divisions
of The 451 Group
Headquartered in New York City, with offices in London, Boston, San
Francisco, Washington DC, Mexico, Costa Rica, Brazil, Spain, UAE, Russia,
Taiwan, Singapore and Malaysia
Research & Data
Advisory
Events
Go 2 Market
3. Copyright (C) 2016 451 Research LLC
3
A combination of research & data is delivered across fifteen
channels aligned to the prevailing topics and technologies of digital
infrastructure… from the datacenter core to the mobile edge.
4. Copyright (C) 2016 451 Research LLC
• Cloud computing has had a significant role to play in driving down the cost of
storing and processing data, along with delivering additional benefits such as:
• developer and business agility
• faster time to adoption for emerging technologies
• high availability
• reduced infrastructure configuration and management overheads.
• Cloud applications require a database that is able to deliver on the flexibility and
scalability advantages of the cloud, while maintaining the resiliency and
functionality expected of traditional databases.
4
Databases and the cloud
5. Copyright (C) 2016 451 Research LLC
5
Databases and the cloud
Databases on the cloud
• 2008 – Operational
databases on IaaS
• 2009 – Analytic databases
on IaaS
• Existing relational
database products
configured to run on the
cloud.
Database-as-a-service
• The on-demand delivery
of database management
software, consumed by
end users as a service.
• In the very early stages of
adoption, with most data-
related workloads
deployed on-premises.
7. Copyright (C) 2016 451 Research LLC
7
Databases and the cloud
Databases for cloud
applications
• A database designed to
take advantage of and
enable elastic, distributed
architecture that supports
SaaS applications.
• May or may not run in a
public cloud.
Databases on the cloud
• 2008 – Operational
databases on IaaS
• 2009 – Analytic databases
on IaaS
• Existing relational
database products
configured to run on the
cloud.
Database-as-a-service
• The on-demand delivery
of database management
software, consumed by
end users as a service.
• In the very early stages of
adoption, with most data-
related workloads
deployed on-premises.
8. Copyright (C) 2016 451 Research LLC
Phases of cloud adoption
8
• Hybrid is not a trend, it’s reality
9. Copyright (C) 2016 451 Research LLC
Requirement drivers
Social
Mobile
Application
Global
Interactive
Local
9
12. Copyright (C) 2016 451 Research LLC
Limitations of traditional databases
• Enterprise architectures have shifted from a scale-up to a scale-out approach to
make use of distributed hardware.
• Greater scalability demands
• Predictable performance problems
• Traditional relational databases were never designed to cope with modern
application requirements
• Geographic distribution
• Proliferation of cloud
• Multiple data types
• Modern application requirements require a rethink of the relational database
model
12
13. Copyright (C) 2016 451 Research LLC
Key Database Criteria for Cloud Applications
13
Scale-out
across
low-cost
distributed
commodity
architecture
Provision
rapidly and
scale up and
down in
response to
changing
requirements
Always
available,
actively in
multiple
locations and
regions
Easily
monitored,
managed and
integrated with
other
applications
and services
SCALEABLE DYNAMIC RESILIANT SIMPLE
14. Copyright (C) 2016 451 Research LLC
Key Database Criteria for Cloud Applications
14
Public, private,
hybrid cloud.
Combined
operational
and analytic
processing
Able to
support high
performance
workloads, as
required
Supports
security and
access
technologies
and standards
Support for
existing skills
and tools (e.g.
SQL)
Consistent
(tunable if
required)
HYBRID PERFORMANT SECURE PREDICTABLE
15. Copyright (C) 2016 451 Research LLC
• Growing adoption of Databases on the Cloud and DBaaS, but hybrid is not a
trend, it’s reality
• Traditional relational databases were never designed to cope with modern
application requirements.
• Cloud applications require a database that is able to take advantage of and
enable elastic, distributed architecture.
• While also maintaining the performance, resiliency, security and functionality
expected of traditional databases.
Conclusions
15
16. Copyright (C) 2016 451 Research LLC
Thank you
matthew.aslett@451research.com
@maslett
www.451research.com
17. The Elastic SQL Database for Applications in the Cloud
NUODB
November 14, 2016
18. DATABASE FOR CLOUD APPLICATIONS
18
Virtualization,
Commodity & Cloud
Scale out / in
ACID
(consistency)
Existing SQL
skills & code
SQL database
abstraction
What everyone wants: What they don’t want to lose
“Elasticity” “SQL”
“I want to elastically scale my SQL RDBMS to the cloud”
Continuous
Availability
19. NuoDB combines the scale-out simplicity, elasticity, and continuous availability that cloud applications
require with the transactional consistency and durability that databases of record demand.
Agility
Respond to market changes
faster:
+ Dynamically add or remove
servers
+ Deploy on public cloud,
private cloud or on-
premises
+ Modify applications faster
with a consistent SQL API
Total Cost of Ownership
Reduce overall costs:
+ Lower database licensing
costs
+ Better server utilization
+ Reuse existing SQL code
and skillsets
+ Provision servers with
demand – no pre-
provisioning
Time to Market
Bring applications to market
faster:
+ Reuse existing SQL logic
and skills
+ Trust the database for data
management logic
Customer Satisfaction
Improve application
experience:
+ Zero downtime
(including server outages
& rolling upgrades)
+ Consistently better
performance
+ Automated redundancy
and disaster recovery
THE ELASTIC SQL DATABASE
21. KEY IDEA #1: DISTRIBUTED BY DESIGN
21
1.Start with a client-server DBMS
2.Try to turn it into a Distributed
System
1.Start with a Distributed System
2.Deliver database services on this
system
DON’T DO
A single logical database
that scales elastically
Compromise database or application
to achieve scale-out
22. KEY IDEA #2: SEPARATION OF DUTIES
22
Separate transactions from storage
One logical database
+ Both tiers survive failures and rolling upgrades at any peer
+ Allocate servers and server types based on workload
Transactions in memory
+ Working data set in memory
+ No shards / explicit partitioning
+ Scale throughput & clients
on-demand
+ Transparent to applications
Storage is redundant & flexible
+ Durable persistence
+ Automatically replicate to
multiple locations
+ Tunable consistency models
23. TETE TE
SM SM
NuoDB ARCHITECTURE IN PRACTICE
NuoDBdatabase
App App App
+ Fully redundant
+ Elastically scalable
+ Continuously available
Available host
SM Storage Manager (SM)
Transaction Engine (TE)TE
Scale-out adds
+ Active/Active across
single DC or multiple AZ’s
26. NoSQL
Traditional
RDBMS
DBMS OPTIONS FOR CLOUD
26
“Elasticity”
Scaling simplicity, continuous availability
“SQL”
Durability,consistency,recoverability
New
SQL
Cloud
DBMS
“NuoDB was the best
database to support
our need for scaling
up our distributed
network to meet
demand requirements
while maintaining
transactional
consistency and
integrity.”
Bruce Lawler
Co-founder & Chief Product
Officer
Better title?
Existing tech is client-server, and we live in a distributed world – we designed for distributed
Can’t just map existing c-s tech to distributed – won’t be clean / it is a hack
The cloud is distributed – if that isn’t your pain, we aren’t a good fit -
Separating compute from storage – yes, a key concept
Transaction locality is independent of storage locality
Transactions in memory (could run without sms – would lose durability, but not tx consistency)
Transaction coordination is all in memory
Frame similar to #1:
don’t tightly couple tx to disk
Loosely coupled - Scale independently
Respond on demand
Diff servers for diff workloads
Manage storage / backup independent
Run tx in memory
Take advantage of commodity resources, etc.