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