DynamoDB

        本来想写写进程、线程、轻量级线程、goroutine还有协程(coroutine),为什么我把goroutine单独列出来是因为它不是协程,所有翻译成协程的都是偷用概念,把比线程轻量的都叫做协程。算了,先不纠结这个,今天想写写DynamoDB,记录下经历。

        就如官网描述到的,无限扩展,好吧,具体实现也不得而知,但这个无限扩展的前提是诸多限制。在确认DynamoDB是否适口你的项目使用的时候,记得多分析它的限制,否则迟早会成为项目的瓶颈,或者减缓业务的开发。

        首先,DynamoDB统计不友好,想统计它的东西?最好还是放弃这个念头,扫描一遍的代价大得不可思议。在用DynamoDB之前,先弄好你的日志系统。
        其次,它不是缓存,虽然是说SSD搞的,但是连这个东西(HTTPS)的代价不是普通缓存所会做的,就它内部查询性能来看,也是几十上百毫秒级别的。
        再次,不要以为这个东西很容易用,各种SDK各种坑,拿python boto为例子,两个版本的实现,各自残缺,有些功能SDK根本提供不了,你要做好写RESTful requests的准备。
        最后,你要是会看英文且真的想用DynamoDB就别继续往下看了,直接看官网文档各种详尽和指引,以下只是个人心得和坑的摘录。

        第一个坑是数据类型,嗯,不完全符合JSON,也就是说,这个要做点格式转换,前不久才出了List和Map的支持,叫文档类型,官方建议可以把JSON压缩成Binary,这...。一条项目(就是一条record,叫item)最大存储容量为400KB(只是英文文档这样写,中文文档还没更新,依然写着64K,这有点小,除此以外,中文文档残缺不全,不值一嗔),这个还可以。读/写流量限制预设(Provisioned Throughput)是一个最大的坑,以流量限定读写速率和容量。单个读单位可在1秒内读1次且4KB以内的内容,40KB就要10个读单位,同样地,单个写单位每秒可写入1次且1KB以内内容。
        第二个坑来了,就是这个读/写流量限制预设,全局二级索引是和主表分开预设流量计算。最坑在于,倘若你想写入主表,主表的预设流量是够的而全局二级索引预设流量不够,这样就会插不进,报错,这样使得全局二级索引和新建一张表无异,新建一张表还更灵活。预设流量的另一个坑是,你的hashkey(整个数据库以hashkey作为主键,不知道的请到官网中文版补习)必须hash得均匀才能得到预设流量的最大效用。比如说,你预设了1000个读(预设读容量超过10000还需要递表申请),amazon帮你自动分在20个区存放,那么你每个区只会获得50个读的流量,假如你现在急着要读某一类别的数据,并且这一类别的不小心集中在某一区域,不好意思,你的消费将乘以个几倍几十倍(amazon的服务本身就贵)。如果你要强一致性读(默认是不强一致性读的,不懂的自己脑补),那么将会消耗两倍于脏读的读单位。
        第三大坑是索引,上面说到的全局索引是一个坑,还有一种叫二级本地索引也是一个坑,它居然有一条单个hashkey索引内容不超过10G的规定,这个索引内容投影属性*(这个概念请看官网)。这就是说,当你索引加投影单个item有200个字节(200个字节真心不多吧,一个uuid随便都32byte了,当然,你可以选择压缩...),200字节的情况下,该hashkey最多可以包含的条目是5000万条,这个规定直接给人限死了,你不能拿单个hashkey来玩,更别做太多投影。此外,索引是不能添加修改删除的,只能跟随表创建时添加。虽然有10G这个限定,但我觉得它的RangeKey和本地二级索引还是比较独特的,可以解决很大一部分的需求。前提是,最深的索引就是二级,你要做三级四级的索引就要想一下办法了,这个想一下办法也可以再解决一大部分的需求吧。
        第四,别考虑太多事务啊原子操作之类,它做不了,简单的自增还是可以的。
        最后就是SDK,如果你只是简单的使用,python的SDK boto没什么大问题,但你考虑到并发冲突,部分属性修改兼上是否覆盖写入等等的问题的时候,boto压根就不能解决,这就需要又花费一大块精力去手工Restful了,当然,如果你想用上tonado,没有现成的异步模块可用。

        如果你已经跳过上述的坑,相信离DynamoDB符合你的项目需求已经不远了,当然,性能方面我还没做过多测试,准备上线亿级以上条目的项目了,详情敬请期待。


郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。