利用流式数据流增强用户体验.pdf

1、1Powering User Experiences with Streaming DataflowAlana MarzoevOverview01Lets set the sceneYour web app starts to get traction DatabaseYour web app starts to get traction DatabaseTime to throw in a cache DatabaseCacheRead-through cache BeforeAfterAfterFor each query,what are the data freshness requi

2、rements?What eviction policy makes the most sense?Are TTLs sufficient?LRU?From there,need to modify code accordingly Cost/benefit analysis Pros:Low latencies Horizontal scaling Cons:App rewrite requiredError-prone Easy to interfere with app semantics Needs tuning to ensure high cache hit rateCould l

3、ead to spiky load on the DBCache Desiderata Same interface as a relational database No app rewritesAutomatic cache maintenance No staleness concerns Insulation from database Cache never makes things worse Demo 14Automatic Database Caching15Partially-Stateful Streaming Dataflow 16Building for Web Sca

4、le17Case Study:Readyset DBCacheCacheCacheReadySetApp ServersHow does this system work?Why does it matter?19Agenda InterfaceLife of a query Cache updates via streaming dataflow Impact/use cases Interface0121Set up as a read replicaSet up as a database read replicaTakes an initial snapshot of tables a

5、t startup Replicates changes to tables,stores in RocksDBPostgres:logical replication MySQL:row-based replication Option to do a partial snapshot based on what queries are cached22Wire-compatibility with existing databasesSupports both the Postgres&MySQL wire protocolsGoal is to interoperate with exi

6、sting database tools(client libs,ORMs,etc)Provide“normal”database connection string to use in applications 23Cache specification languageCaches need to be specified explicitly Can offer suggestions on what to cache(e.g.using slow query logs)SQL extension syntax for cachingConfig based cachingthink o