HackerAWS re:Invent 2018: Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB (DAT401)
Amazon Web ServicesYouTube ↗
延伸阅读 1
字幕解读
Houlihan 说明 NoSQL 适合访问模式明确、可预期且规模较大的 OLTP 服务；关系仍然存在，但需把数据按查询需求反规范化到单表、复合键和二级索引中，以减少联接和往返。设计前要列全访问模式、数据生命周期与事务边界，并通过高基数分区键避免热点。演讲以配置、配送和电子书同步服务示范单表设计、版本记录、事务 API、流处理及按需弹性扩缩。
自动字幕 · 引文按字幕原文展示，可点时间戳回看片段。
内容要点
- NoSQL 模型必须从应用访问模式出发：分区键分散负载，排序键与复合键表达层级及范围查询。
- 把相关实体复制到同一表并使用二级索引，可以用一次查询满足多种关系访问；数据越贴合访问模式，模型也越紧耦合。
- 事务应服务于真实的跨项原子更新或版本提交，而不应用来维持关系数据库式规范化模型；流和预计算可把聚合计算移出请求路径。
视频章节 6
- 数据处理演进与 NoSQL 动因
- 分区键、排序键和查询方式
- 从访问模式设计模型
- 流处理与预计算聚合
- 复合键构造层级访问
- 用单表模型支持复杂关系
具体观点与证据 4
NoSQL建模先要列明访问模式；已知、重复的业务查询比临时分析查询更适合此路径。
讲者针对DynamoDB式建模；保留关系数据库用于OLAP和临时查询。
I need to know exactly what the application is doing针对访问模式优化的数据模型会与服务耦合，效率提高不等于模型更灵活。
反对把无固定表结构误解成任何查询变化都便宜。
the more that I tune that data to the access pattern the more tightly coupled to that service I am过滤表达式在读取后剔除结果，不能减少已经读取项目的成本。
演讲对比sort key条件和filter condition；可用状态加日期组合排序键改善选择性。
the filter condition applies after the read so预计算并保存聚合值，可以避免每次读取都重新执行同一聚合。
演讲以加载后不变的时序数据说明，变化数据需维护更新逻辑。
the metric is calculated now it can be read a million times补充字幕原文 2
NoSQL 模型需要预先了解全部访问模式，以便围绕查询需求设计数据布局。
understand every access pattern I need to know单表与索引设计的目标之一，是通过单次查询返回满足应用工作流的多个相关实体。
we want single queries to deliver multiple entities解读边界
内容是 AWS DynamoDB 的实践推介，性能、成本和服务能力的主张主要基于演讲者的客户经验；具体实现受该产品模型和当时功能约束。