云存储

云上的数据存储

数据库

随着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: 就是集群