【论文】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仍是能够的。