【论文】cloud dbms:architectures and tradeoffs

这个文章在选型本地/远端，优化关注并发/还是语句解析，冷热缓存，等给了实践上真实的差距，给我们看的目的是坚定利用低成本在网速10G的发展下存储部分 用底层本共享保证可靠性的共享存储，替代自己做多备份posix保证一致性，且用便宜的对象存储+超快的本地易失缓存替代块存储（存储上的硬件用起来也是飞一般比如redshift的NVME非易失性只需要内存满同步s3没价格也是double）。云上的计算存储分离/orc数据共享（这么看存储和HA还有什么可做的呢，关注点是否要移到计算上？）。文末也说明这篇是OLAP的场景。对OLAP了解的不多，而转移到OLTP上这篇文章并不能说服我，权当关注下趋势了，读完了做个笔记而已吧。

• 背景
  为了可扩展基本都是计算和存储分离了。容错，热数据管理，软件更新。可扩展等等
  对于存储，对象存储比如S3（共享对象存储 我们的OSS），
  非持久本地存储 EC2(计算节点)+EBS(远端块存储，更快，更贵)。
  本地缓存在带宽不断增大后，优势变小（10G后）
  本文考虑系统选取，冷热cache影响，存储选取，计算cost，数据格式通用，等方面对比分析常见OLAP服务。用TCP-H（https://yq.aliyun.com/article...）做验证。
• 结论
  便宜的对象存储比贵的EBS性价比高，（性能在2倍以内，价格在4倍以上差距）
  本地物理存储比EBS性能高，但是双倍价格
  使用ORC等通用格式
  水平扩展
  垂直扩展

存储

AWS的常见选择：
InS 快速易失
EBS 虚拟块存储，内存挂了可以将这个EBS绑定到其他机器
S3 高可扩展，高一致性，比EBS延迟和吞吐都差
介质选择：这种小钱大家都不在乎了，基本上都是SSD了

OLAP系统

1.启动时长

athena一直在线。redshifts要把远端数据载入本地NVME。带S3的要重新初始化，ebs的重新绑定到EC2

查询性能：

• 小IO
  冷热缓存，除了redshift在查询解析上的缓存使得cache有用，其他基本无差别，因为IO比较少（事实上也有1G的扫描啊），VeticaS3即使内存中有也会把数据再写入node attached storage，其他的不会。
  IO大小，在小IO下对查询性能优化对性能影响很大。
  
  redshift的架构会对请求并发处理，这就在查询解析和其他处理上做性能权衡，
• 大IO下 S3的性能
  
  对比Vertica的EBS和Presto的S3。HIVE的EBS，S3版本。尤其是presto的S3。单独看存储的disk reads Vertica的EBS是1000M对比与Presto的500M。

价格，数据格式

扩展

• 水平扩展
  在redshift这种解析很占用时间的，水平扩展并没什么好处，因为要重新解析语句，其他都是更好的
  
• 垂直扩展
  一般是不好的，因为S3会有网络阻塞，在node已经是中型下够用了，presto例外因为内存满了才写磁盘？

对这些OLAP的系统理解比较少。但是这些都是高计算耗时的，所以remote影响更小（NVME的redshift也要3-5s，对于OLCP新ob的100万/s[60,880,800 tpmC(每分钟内系统处理的新订单个数）]。时序的千万/s。远程还是RT影响的量级还是不一样的。我想我们在思考本地raft/posix还是远端OSS这篇文章还是不够的。OLAP还是可以的。