# 云存储

## 云上的数据存储

### 数据库

随着nosql和newsql的发展，近十来年涌现了适配各个场景的数据库。

* 1.功能针对性高
* 2.可扩展性强
* 3.成本和性能平衡
* 4.新硬件的发展

长期来看，会存在多款产品。

### 云上数据的黏性

* 1.数据存储就会收费，公有云黏性强
* 2.各家都限制公网带宽，进行客户锁定
* 3.但是对于内网，且多个节点并发访问不同文件，速度无上限

### 数据计算，移动数据

* 1.优先select object
* 2.在云服务商的内网计算
* 3.分发到离客户近的点（CDN等）

无轮如何,都应在近的节点先进行数据的计算。

### 数据缓存

同上面的正好相反。 但是这里需要拿到有需要缓存，一级级向上移动。 再加上本机的硬盘，内存，等

### 分析型的数据

* 1.便宜，如果打算数据不删除，对象存储已经提供了近乎于成本的价格，还有冷存等
* 2.可靠谱性
* 3.对象存储已经事实成为标准

如果没有在线服务的需求，基本上对象存储已经成为正确且唯一的选择。

### 基于对象存储的数据分析

* 1.Iceberg, Delta Lake, Hudi 等新的支持upsert/delete操作
* 2.spark,hadoop等基于文件的数据分析已经验证了
* 3.新式的存储结构或者基于文件的存储，并没有完全基于对象存储的，只是把对象存储当面冷备份

这里是不是有可能性，完全基于对象存储的数据分析应该是一个有趣的选择。

### 对象存储性能

* 1.对于64M的数据，可以99分位，做到30ms返回。
* 2.对于对象存储，支持select，可以进一步做数据筛选

### 数据的一致性

* 1.基于log is database的，搞一个单独的消息队列存
* 2.本地先同步准备wal，再整理数据上传对象存储，写成功 （这里还是依赖于单机的节点）

无轮如何，如果不额外依赖于消息队列，如果对象存储写入的性能不够，都是要在本地缓存积累一定的量，才能写入成功。

### 如何让对象存储支持一致性

* 1.如果不是AP,且对象存储在磁盘上，支持一致性操作，就一定要引入一个额外的存储
* 2.如果是AP系统，可以探索写入时，数据直接放对象存储中

### 让一致性维护在meta和对象存储中

* 1.Meta存储保存着所有的数据对象列表
* 2.对象存储保存着所有数据
* 3.本地写入的数据直接上传对象存储来达到成功
* 4.多个节点写入，都以meta为准

### 事务

* 1.通过meta的事务可以保证多表的数据一致
* 2.单表通过文件的meta就可以保证数据一致
* 3.整个系统是以meta为中心设计
* 4.基于meta可以实现乐观锁和悲观锁

### 读取一个10G对象，并在1秒，计算完后返回

* 并发读取，每个计算节点恰好用满时间的带宽，来保证副本大小
* 通过多个节点并发的算力，来保证每个节点的计算时间严格控制
* 留足汇总计算的时间

### 新式的OLAP架构

* duckdb,dafuison，palar等，基于arrow可以做到olap操作足够快
* 抛弃hadoop，spark的百台机器的软件栈
* 用户的数据也不要求一次计算在几百台机器上，可以时间区间切分，分批次计算
* 导致架构变简单，单机加载内存计算
* faas 上分块计算

### 两种查询

* 海量的数据就只查一次 用select object ,无缓存设计
* 反复的数据查询 先筛选出只够小的数据集，且有多级分别缓存数据

反复的数据查询才是重点 如果只查一次，在对对象存储的优化变得无意义 随着查询次数，数据离用户越来越近

## 最终结论

Interactivity: 查询1\~2秒返回，且无慢查询 Multiple Functions:同时支持很多个F来进行数据的读取和计算 Cloud: 云端数据计算尽量下推 Basic Partitions: 要支持数据分区 Advanced Partitions: 根据查询和业务推断出分区 Container: 需要有状态的计算节点，可能本地或者协调节点,需要一个中心结点做shuffle，和调度，要不然sql 就是支持不全的 meta: 就是集群