Tutorial on Scalable Cloud-Databases in Research and Practice

Transcription

1 Tutorial on Scalable Cloud-Databases in Research and Practice Norbert Ritter, Felix Gessert

2 Outline Motivation ORESTES: a Cloud- Database Middleware Solving Latency and Polyglot Storage Overview The New Field Cloud Data Management Cloud Database Models Research Challenges Wrap-up

3 Introduction: Which classes of cloud databases are there?

4 Cloud Databases Backend-as-a- Service Managed NoSQL Databases Cloud-only DBaaS-Systems Analytics-asa-Service Orestes Parse SQL Azure Amazon RDS Heroku Pos. Compose Cloudant DynamoDB Google F1 Database-as-a-Service BigQuery EMR Managed RDBMS Platform-as-a-Service Infrastructure-as-a-Service Cloud-Deployment of DBMSs

5 Data Management Data Analytics Architecture Typical Data Architecture: Analytics Reporting Data Mining Data Warehouse The era of one-size-fits-all database systems is over Specialized cloud DBaaS databases Operative Database Applications

6 Database Sweetspots RDBMS General-purpose ACID transactions Parallel DWH Aggregations/OLAP for massive data amounts NewSQL High throughput relational OLTP Wide-Column Store Long scans over structured data Document Store Deeply nested data models Key-Value Store Large-scale session storage Graph Database Graph algorithms & queries In-Memory KV-Store Counting & statistics Wide-Column Store Massive usergenerated content

7 Cloud-Database Sweetspots Realtime BaaS Communication and collaboration Managed RDBMS General-purpose ACID transactions Managed Cache Caching and transient storage Azure Tables Wide-Column Store Very large tables Wide-Column Store Massive usergenerated content Backend-as-a-Service Small Websites and Apps Managed NoSQL Full-Text Search Google Cloud Storage Object Store Massive File Storage Amazon Elastic MapReduce Hadoop-as-a-Service Big Data Analytics

8 Cloud Data Management New field tackling the design, implementation, evaluation and application implications of database systems in cloud environments: Protocols, APIs, Caching Load distribution, Auto-Scaling, SLAs Workload Management, Metering Replication, Partitioning, Transactions, Indexing Application architecture, Data Models Multi-Tenancy, Consistency, Availability, Query Processing, Security

9 Cloud-Database Models unstructured Data Model unstructured Analytics machine image Analytics- as-a- Service Analytics/ ML APIs schemafree NoSQL machine image Managed NoSQL NoSQL Service Database-as-a-Service relational structured RDBMS machine image Managed RDBMS/ DWH RDBMS/ DWH Service Deployment Model

10 Cloud-Deployed Database Database-image provisioned in IaaS/PaaS-cloud IaaS/PaaS deployment of database system IaaS-Cloud Does not solve: Provisioning, Backups, Security, Scaling, Elasticity, Performance Tuning, Failover, Replication,...

11 Managed RDBMS/DWH/NoSQL DB Cloud-hosted database SQL Azure DBaaS-Provider RDBMS DWH NoSQL DB IaaS-Cloud Provisioning, Backups, Google Security, Cloud SQL Scaling, Elasticity, Performance Tuning, Failover, Replication,... Amazon Redshift RDBMS NoSQL DB DWH

12 Proprietary Cloud Database Designed for and deployed in vendor-specific cloud environment Amazon SimpleDB Black-box system Managed by Cloud Provider Cloud Provider s API Google Cloud Datastore Database.com Azure Blob Storage Azure Tables BigTable, Megastore, Spanner, F1, Dynamo, PNuts, Relational Cloud, Openstack Swift Google Cloud Storage Database Object Store

13 Analytics-as-a-Service Analytic frameworks and machine learning with service APIs Provisioning, Data Ingest Analytics Cluster Amazon Elastic MapReduce Azure HDInsight Google BigQuery Google Prediction API Analytics ML Cloud

14 Backend-as-a-Service DBaaS with embedded custom and predefined application logic Authentication, Users, Validation,etc. Maps to (different) databases Backend API Service-Layer Data API AppCelerator Cloud (mobile) BaaS IaaS-Cloud

15 Pricing Models Pay-per-use and plan-based Account Plan-based Pay-per-use Parameters: Allocated Plan (e.g. Parameters: 2 Network, instances Bandwidth, + X GB storage) Storage, CPU, Requests, etc. Payment: Pre-Paid, Post-Paid Variants: On-Demand, Auction, Reserved e.g. Compose e.g. DynamoDB Usage End of month

16 Database-as-a-Service Approaches to Multi-Tenancy Private OS Private Process/DB Private Schema Shared Schema Virtual Schema Schema Schema Schema Schema Database Database Database Database Database Process Database Process Database Process Database Process VM VM VM VM Hardware Resources Hardware Resources Hardware Resources Hardware Resources e.g. Amazon RDS e.g. Compose e.g. Google DataStore Most SaaS Apps T. Kiefer, W. Lehner Private table database virtualization for dbaas UCC, 2011

17 Multi-Tenancy: Trade-Offs App. indep. Ressource Util. Isolation Maintenance, Provisioning Private OS Private Process/DB Private Schema Shared Schema W. Lehner, U. Sattler Web-scale Data Management for the Cloud Springer, 2013

18 Authentication & Authorization Checking Permissions and Indentity Internal Schemes External Identity Provider e.g. Amazon IAM e.g. OpenID e.g. SAML Federated Identity (Single Sign On) Authenticate/Login Token Authenticated Request Response Authentication Authorization API Database-aa-Service User-based Access Control Role-based Access Control Policies e.g. Amazon S3 ACLs e.g. Amazon IAM e.g. XACML

19 Service Level Agreements (SLAs) Specification of Application/Tenant Requirements SLA Technical Part 1. SLO 2. SLO 3. SLO Legal Part 1. Fees 2. Penalties Service Level Objectives: Availability Durability Consistency/Staleness Query Response Time

20 Service Level Agreements Expressing application requirements Functional Service Level Objectives Guarantee a feature Determined by database system Examples: transactions, join Non-Functional Service Level Objectives Guarantee a certain quality of service (QoS) Determined by database system and service provider Examples: Continuous: response time (latency), throughput Binary: Elasticity, Read-your-writes

21 Service Level Objects Making SLOs measurable through utilities

22 Workload Management Guaranteeing SLAs Typical approach: Maximize: W. Lehner, U. Sattler Web-scale Data Management for the Cloud Springer, 2013

23 Resource & Capacity Planning From a DBaaS provider s perspective Goal: minimize penalty and resource costs Resources Provisioned Resources: #No of Shard- or Replica servers Computing, Storage, Underprovisioning: Network Capacities SLAs violated Usage maximized Actual Expected Load Load Overprovisioning: SLAs met Excess Capacities Time T. Lorido-Botran, J. Miguel-Alonso et al.: Auto-scaling Techniques for Elastic Applications in Cloud Environments. Technical Report, 2013

24 SLAs in the wild Most DBaaS systems offer no SLAs, or only a a simple uptime guarantee Model CAP SLAs SimpleDB Dynamo-DB Azure Tables AE/Cloud DataStore S3, Az. Blob, GCS Table-Store (NoSQL Service) Table-Store (NoSQL Service) Table-Store (NoSQL Service) Entity-Group Store (NoSQL Service) Object-Store (NoSQL Service) CP CP CP 99.9% uptime CP AP 99.9% uptime (S3)

25 Open Research Questions in Cloud Data Management Service-Level Agreements How can SLAs be guaranteed in a virtualized, multi-tenant cloud environment? Consistency Which consistency guarantees can be provided in a georeplicated system without sacrificing availability? Performance & Latency How can a DBaaS deliver low latency in face of distributed storage and application tiers? Transactions Can ACID transactions be aligned with NoSQL and scalability?

26 Location : Santa Clara Submission Deadline: August 30

27 Outline Motivation ORESTES: a Cloud- Database Middleware Two problems: Latency Polyglot Storage Vision: Orestes Middleware Solving Latency and Polyglot Storage Wrap-up

28 Latency & Polyglot Storage Two central problems Goal of ORESTES: Solve both problems through a scalable cloud-database middleware If the application is geographically distributed, how can we guarantee fast database access? If one size doesn t fit all how can polyglot persistence be leveraged on a declarative, automated basis?

29 Problem I: Latency ms 500 ms 1s ms Loading Average: 9,3s -7% Conversions -20% Traffic -9% Visitors -1% Revenue

30 If perceived speed is such an import factor...what causes slow page load times?

31 State of the art Two bottlenecks: latency und processing High Latency Processing Time

32 Network Latency The underlying problem of high page load times I. Grigorik, High performance browser networking. O Reilly Media, 2013.

33 The low-latency vision Data is served by ubiquitous web-caches Low Latency Less Processing

34 The web s caching model Staleness as a consequence of scalability Expiration-based Every object has a defined Time-To-Live (TTL) Revalidations Allow clients and caches to check freshness at the server Stale Data Research Question: Can database services leverage the web caching infrastructure for low latency with rich consistency guarantees?

35 Problem II: Polyglot Persistence Current best practice Research Question: Billing Data Application Layer Nested Application Data Can we automate the Friend network Cached data & metrics data Search Index Session data database Recommendation Engine Files mapping problem? Google Cloud Storage Amazon Elastic MapReduce

36 Vision Schemas can be annotated with requirements - Write Throughput > 10,000 RPS - Read Availability > % - Scans = true - Full-Text-Search = true - Monotonic Read = true Schema DBs Tables Fields

37 Vision The Polyglot Persistence Mediator chooses the database Application Data and Operations Database Metrics Polyglot Persistence Mediator Annotated Schema Latency < 30ms db 1 db 2 db 3

38 The Big Picture Implementation in ORESTES Polyglot Storage and Low Latency are the central goals of ORESTES Database-as-a-Service Middleware: Unified REST Caching, Transactions, Polyglot Storage Schemas, Standard HTTP Caching API Authorization, Multi-Tenancy Desktop Cache Sketch Mobile Internet Reverse-Proxy Caches Orestes Servers Tablet Content-Delivery- Network

39 Outline Motivation ORESTES: a Cloud- Database Middleware Solving Latency and Polyglot Storage Wrap-up Cache Sketch Approach Caching Arbitrary Data Predicting TTLs Polyglot Persistence Mediator SLA-Approach Database Selection

40 Web Caching Concepts Invalidation- and expiration-based caches Request Path Client Expirationbased Caches Cache Hits Invalidationbased Caches Browser Caches, Forward Proxies, ISP Caches Content Delivery Networks, Reverse Proxies Expiration-based Caches: An object x is considered fresh for TTL x seconds The server assigns TTLs for each object Invalidation-based Caches: Expose object eviction operation to the server Server/DB

41 Invalidation-Minimization Staleness-Minimization The Cache Sketch approach Letting the client handle cache coherence Client Needs Revalidation? Bloom filter Client Cache Sketch Expirationbased Caches Browser Caches, Forward Proxies, ISP Caches at connect Periodic every Δ seconds at transaction begin Request Path Cache Hits Invalidationbased Caches Content Delivery Networks, Reverse Proxies Invalidations, Records Report Expirations and Writes Non-expired Record Keys Counting Bloom Filter Server/DB Needs Invalidation? Server Cache Sketch

42 The End-to-End Path of Requests The Caching Hierarchy Low Latency Reduced Database Load DB.posts.get(id) GET /db/posts/{id} JavaScript Cache-Hit: Return Flash-Crowd Object Higher Cache-Miss HTTP or Protection Revalidation: Return Availability record from Forward Request DB with caching TTL Hit Client- (Browser-) Cache Miss Proxy Caches Miss ISP Caches Miss CDN Caches Miss Reverse- Proxy Cache Miss Orestes Updated by Cache Sketch Updated by the server

43 The Client Cache Sketch Let c t be the client Cache Sketch generated at time t, containing the key key x of every record x that was written before it expired in all caches, i.e. every x for which holds: find(key) key h 1... Client Cache Sketch Hit key GET request no Bits = 1 Cache Miss k hash functions h k m Bloom filter bits yes Revalidation key

44 1 Slow initial page loads Solution: Cached Initialization Clients load the Cache Sketch at connection Every non-stale cached record can be reused without degraded consistency purge(obj) False-Positive Hash- Rate: Browser Functions: CDN Cache With distinct updates and 5% error rate: 11 KByte hasha(oid) hashb(oid) hasha(oid) hashb(oid) Flat(Counting Bloomfilter)

45 2 Slow CRUD performance Client Expirationbased Caches Invalidationbased Caches Server Query Cache Sketch Cache Sketch c t fresh records Cache Hits Revalidate record & Refresh Cache Sketch Fresh record & new Cache Sketch -time t -time t + Δ

46 3 High Abort Rates in OCC Client Begin Transaction Bloom Filter Cache Reads Cache Writes Cache Commit: read- & write-set versions Committed OR aborted + stale objects REST-Server REST-Server REST-Server Writes (Hidden) Read all DB Writes (Public) 5 validation 4 Coordinator prevent conflicting validations

47 TTL Estimation Determining the cache expiration Shorter TTLs Longer TTLs less invalidations less stale reads Higher cache-hit rates more invalidations

48 Performance Northern California Ireland Setup: Client CDN Orestes MongoDB Page load times with cached initialization (simulation): With Facebook s cache hit rate: >2,5x improvement Average Latency for YCSB Workloads A and B (real): 95% Read 5% Writes 5x latency improvement

49 Low Latency If the application Transparent is geographically end-to-end distributed, caching how can using we guarantee the Cache fast database Sketch. access? If one size doesn t fit all how can polyglot persistence be leveraged on a declarative, automated basis?

50 Towards Automated Polyglot Persistence Necessary steps Goal: Extend classic workload management to polyglot persistence Leverage hetereogeneous (NoSQL) databases 1. Requirements 2. Resolution 3. Mediation Tenant specifies requirements as Service- Level-Agreements Find or provision a suitable combination of databases Mediate data and database operations

51 Step I - Requirements Expressing the application s needs Tenant annotates schema with his requirements Tenant 1. Define schema 2. Annotate Database Table Field Table Field Field Field annotated Inherits continuous annotations Annotations Continuous non-functional e.g. write latency < 15ms Binary functional e.g. Atomic updates Binary non-functional e.g. Read-your-writes 1 Requirements

52 Step II - Resolution Finding the best database The Provider resolves the requirements RANK: scores available database systems Routing Model: defines the optimal mapping from schema elements to databases Capabilities for available DBs 1. Find optimal Provider Either: Refuse or Provision new DB 2a. If unsatisfiable RANK(schema_root, DBs) through recursive descent using annotated schema and metrics 2b. Generates routing model Routing Model Route schema_element db transform db-independent to dbspecific operations 2 Resolution

53 Step II - Resolution Ranking algorithm by example Annotations Schema DBs = { MongoDB, Riak, Cassandra, CouchDB, Redis, MySQL, S3, Hbase } RANK Algorithm Linearizability Availability Read latency ECommerceDB database Customers Table ShoppingBasket List<String> UserName String Database MongoDB Redis No annotation Cassandra, Availability CouchDB, Redis, recursive descent to child 99% % 0.05 Binary requirement 1. Exclude DBs that do not support 99.9% 0.9 it 2. Recursive descent MySQL 94% 0.04 HBase DBs = { MongoDB, Riak, MySQL, S3, Hbase } Latency 10ms 1 1ms 1 40ms ms 0.1 Continuous requirement databases calculate

54 Step II - Resolution Ranking algorithm by example Annotations Linearizability Availability Read latency Schema ECommerceDB database Customers Table ShoppingBasket List<String> UserName String DB RANK Algorithm Score MongoDB 0.9 Redis MySQL 0.12 HBase 0.5 Binary requirement 1. Exclude DBs that do not support it 2. Recursive descent 3. Pick DB with best total score and add it to routing model Routing Model: Customers MongoDB

55 Step III - Mediation Routing data and operations The PPM routes data Operation Rewriting: translates from abstract to database-specific operations Runtime Metrics: Latency, availability, etc. are reported to the resolver Primary Database Option: All data periodically gets materialized to designated database Report metrics Application 1. CRUD, queries, transactions, etc. Polyglot Persistence Mediator Uses Routing Model Triggers periodic materialization 2. route db 1 db 2 db 3 3 Mediation

56 Evaluation: News Article Prototype of Polyglot Persistence Mediator in ORESTES Scenario: news articles with impression counts Objectives: low-latency top-k queries, highthroughput counts, article-queries Article Counter

57 Evaluation: News Article Prototype built on ORESTES Scenario: news articles with impression counts Objectives: low-latency top-k queries, highthroughput counts, article-queries Mediator Counter updates kill performance

58 Evaluation: News Article Prototype built on ORESTES Scenario: news articles with impression counts Objectives: low-latency top-k queries, highthroughput counts, article-queries Mediator No powerful queries

59 Evaluation: News Article Prototype built on ORESTES Scenario: news articles with impression counts Objectives: low-latency top-k queries, highthroughput counts, article-queries Article ID Title Document Imp. Imp. ID Sorted Set Found Resolution

60 Outline Motivation ORESTES: a Cloud- Database Middleware Current/Future Work Summary Putting ORESTES into practice Solving Latency and Polyglot Storage Wrap-up

61 Outlook: Real-Time Combining Query Caching, Continuous Queries, Polyglot Queries Continuous Queries (Websockets) Create Update Delete ORESTES Polyglot Views Fresh Caches Fresh Cache Sketch Pub-Sub Pub-Sub

62 Summary Cache Sketch: web caching for database services Consistent (Δ-atomic) expiration-based caching Invalidation-based caching with minimal purges Bloom filter of stale objects & TTL Estimation Polyglot Persistence Mediator: 1. SLA-annotated Schemas 2. Score DBs and choose best 3. Route data and operations Requirements Resolution Mediation

63 Team: Felix Gessert, Florian Bücklers, Hannes Kuhlmann, Malte Lauenroth, Michael Schaarschmidt 19. August 2014

64 0,6s 3,0s 5,0s 5,7s 7,2s 0,7s 0,5s 1,8s 2,8s 3,6s 3,4s 0,5s 1,8s 1,5s 1,3s 2,4s 2,9s 4,0s 4,7s 5,7s Page-Load Times What impact does the Cache Sketch have? CALIFORNIEN FRANKFURT TOKYO +156% [WE RT] 0,5s SYDNEY FRANKFURT

65 Backend-as-a-Service Tutorial on the BaaS paradigm from app perspective

66 Thank you orestes.info, baqend.com