您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 质量控制/管理 > 亚马逊AWS DynamoDB最佳实践_孙素梅
DynamoDB最佳实践DynamoDB最佳实践JennySun孙素梅AWS解决方案架构师,区域主管JennySun孙素梅AWS解决方案架构师,区域主管议程•为什么选择DynamoDB•什么是DynamoDB•基本知识•数据模型•应用场景和最佳实践•总结为什么选择DynamoDB为什么选择DynamoDB大数据的趋势和特点•大数据(3V):–量大–数据增长速度很快:MB/s很常见;GB/s也越来越普遍–多种数据:日志,性能监控数据,用户指标,安全数据,IoT…•互联用户数目惊人速度增长–预计2020年75billion互联设备•105或者106transactions/s在大数据应用中并不少见GBTBPBZBEB客户需要一个这样的数据库…•稳定的可预测的低延迟响应•灵活的查询和数据模型•支持大规模,能够无限扩展,弹性的吞吐量和存储空间•数据强一致性•内置高可用和容错能力DynamoDB位于大数据的黄金点规模结构速度DynamoDBDynamoDB客户互联网时光机Timehop当下我们的表格已经非常大了,接近100TB,但是性能和第一天搭建时没任何区别什么是DynamoDB什么是DynamoDBAmazonDynamoDB服务单位数ms的响应延迟设计理念•低成本专注于你的业务做两个决定+点几下鼠标=可以开始使用主键每秒并发吞吐量(RCU/WCU)设计理念--使用简单设计理念--稳定的可预测的低延迟响应Docs,SDK's::写:•自动在三个AZ同步复制数据•每个写至少在两个AZ写成功后才会返回•Disk-onlywrites设计理念--高可用和耐久性读:•支持强一致性和最终一致性读•一样的低延迟•最终一致性的成本是强一致性成本的一半设计理念–无缝扩展partitions1..Ntable设计理念--低成本•$0.0065/hfor10WCU(每小时可以支撑多达36,000写)•$0.0065/hfor50RCU(每小时可以支撑多达180,000强一致性读,或者360,000最终一致性读)•First25GBstoredpermonthisfree,$0.25perGB-monththereafter基本知识DynamoDB基本知识表格,项目,属性表格项目属性HashKeyRangeKey必需键-值访问模式,查找:{=}决定数据的分布可选1:N关系模型支持丰富的查询模型Allitemsforahashkey==,,,=,=“beginswith”“between”sortedresultscountstop/bottomNvaluespagedresponsesDynamoDB数据类型•String(S)*•Number(N)*•Binary(B)*•StringSet(SS)•NumberSet(NS)•BinarySet(BS)•Boolean(BOOL)•Null(NULL)•List(L)•Map(M)用于存储JSON文档*可以被用作HashKey或者RangeKey的数据类型预配置的吞吐量•读容量单位(RCU:ReadCapacityUnits)–1RCU=4KB强一致性读–1RCU=8KB最终一致性读•写容量单位(WCU:WriteCapacityUnits)–1WCU=1KB写•每项目操作(包括BatchAPI)–每个Item,读取按4KB取整,写入按1KB•查询和扫描–总量大小,读取按4KB取整,写入按1KB•CreateTable•UpdateTable•DeleteTable•DescribeTable•ListTables•GetItem•Query•Scan•BatchGetItem•PutItem•UpdateItem•DeleteItem•BatchWriteItem•ListStreams•DescribeStream•GetShardIterator•GetRecordsStreamAPIDynamoDBInpreviewDynamoDBAPI扩展和分区•DynamoDB自动扩展分区–可以配置任意数值的吞吐量,无上限限制–可以存储任意数量的项目,每个项目最大400KB•扩展和分区–根据数据存储大小进行扩展:表格的总存储空间;10GB/分区–据读写吞吐量进行扩展:预配置的读写吞吐量•3000RCU:1分区(partition)•1000WCU:1分区(partition)计算分区#分区数目= 10 (表格大小)#分区数目(吞吐量)= 3000 + 1000 分区数目分区数目将来,也可能会发生变化…(表格大小)(吞吐量)分区和吞吐量•每个分区预留相同的吞吐量•一张拥有3个分区的表格,如果预配置的WCU是1500,则会平均分配到每个分区中•留意表的历史配置:避免overprovisioning预配置吞吐量项目和分区•一个项目,一个分区•项目按照hashkey被放置到不同分区中Index选项–GSI和LSI本地二级索引(LSI)相同的hashkey+不同的rangekey索引数据和表格数据位于相同分区全局二级索引(GSI)选择任意属性做新的hashkey和rangekey二级索引对比和选择•全局二级索引(GSIs)–最终一致性–无限扩展–可以选择任意hashkey–支持动态创建和删除索引–独立的预配置吞吐量•本地二级索引(LSIs)–强一致性–最多10GB数据–Hashkey是basetable的Hashkey–在创建表格的时候指定–和basetable共享吞吐量如果一个项目的数据量多于10GB,选择GSI如果业务场景接受数据最终一致性,选择GSI数据模型数据模型1:1关系或者key-values•设计表格或者GSI时候采用Hashkey做主键•采用GetItem或者BatchGetItemAPI例子:指定SSN或者licensenumber,获取属性值UsersTableHashkeyAttributesSSN=123-45-6789Email=johndoe@nowhere.com,License=TDL25478134SSN=987-65-4321Email=maryfowler@somewhere.com,License=TDL78309234Users-Email-GSIHashkeyAttributesLicense=TDL78309234Email=maryfowler@somewhere.com,SSN=987-65-4321License=TDL25478134Email=johndoe@nowhere.com,SSN=123-45-67891:N关系或者父-子•设计表格或者GSI时采用Hashkey+RangeKey做主键•采用QueryAPI例子:指定设备,查询epoch值在X,Y之间的所有读数Device-measurementsHashKeyRangekeyAttributesDeviceId=1epoch=5513A97CTemperature=30,pressure=90DeviceId=1epoch=5513A9DBTemperature=30,pressure=90N:M关系•表格采用Hashkey+RangeKey做主键,并选择反转的Hashkey+RangeKey做GSI•采用QueryAPI例子:指定用户,查询所有参与的游戏;或者指定游戏,查询所有参与的用户。User-Games-TableHashKeyRangekeyUserId=bobGameId=Game1UserId=fredGameId=Game2UserId=bobGameId=Game3Game-Users-GSIHashKeyRangekeyGameId=Game1UserId=bobGameId=Game2UserId=fredGameId=Game3UserId=bob丰富的表达式•Projection表达式–Query/Get/Scan:定义获取的属性•过滤表达式–Query/Scan:#V:num•条件表达式–Put/Update/DeleteItem:attribute_not_exists(#pr.FiveStar)•更新表达式–UpdateItem:setReplies=Replies+:numDynamoDB应用场景和最佳实践DynamoDB应用场景和最佳实践最佳实践1:慎重选择HashKey以实现无限扩展•避免hotkey–好的hashkey取值范围很大;不好的hashkey只能有有限的值–选择能将负载均衡分布到不同分区的hashkey(访问模式)user_id=mzafirst_name=Mattlast_name=Wooduser_id=jeffbarrfirst_name=Jefflast_name=Barruser_id=wernerfirst_name=Wernerlast_name=Vogelsuser_id=simonefirst_name=Simonelast_name=Brunozzi.........好的HashKey的例子大量不同的用户有不同的user_id.负载能够很好的分布在不同的Hashkey也就是不同的partition。status=200date=2012-04-01-00-00-01status=404date=2012-04-01-00-00-01status404date=2012-04-01-00-00-01status=404date=2012-04-01-00-00-01Statuscode取值有限,并且分布是不均匀的,所以会造成不均衡的工作负载分布不好的HashKey的例子MessagesTableMessagesAppDavidSELECT*FROMMessagesWHERERecipient='David'LIMIT50ORDERBYDateDESCInbox例子:MessagingApp最佳实践2:如何存储大项目RecipientDateSenderMessageDavid2014-10-02Bob……48moremessagesforDavid…David2014-10-03Alice…Alice2014-09-28Bob…Alice2014-10-01Carol…如果将信息混合存储(Manymoremessages)DavidMessagesTable50items×256KBeach大的消息体SELECT*FROMMessagesWHERERecipient='David'LIMIT50ORDERBYDateDESCInbox计算inbox查询的成本查询了50条平均项目大小Conversionratio最终一致性读RecipientDateSenderSubjectMsgIdDavid2014-10-02BobHi!…afedDavid2014-10-03AliceRE:The…3kf8Alice2014-09-28BobFW:Ok…9d2bAlice2014-10-01CarolHi!...ct7r把大项目分开存储在另一张表Inbox-GSIMessagesTableMsgIdBody9d2b…3kf8…ct7r…afed…David1.QueryInbox-GSI:1RCU2.BatchGetItemMessages:1600RCU(50separateitemsat256KB)(50sequentialitemsat128bytes)Uniformlydi
本文标题:亚马逊AWS DynamoDB最佳实践_孙素梅
链接地址:https://www.777doc.com/doc-6165088 .html