研发与运维对系统多关注的是功能、性能、冗余与稳定性等技术，在公司级考量技术的方法多有局限性与无赖性（指标不全，整体体系弱、系统多而良莠不齐等），如何才能做好系统，可能在实现上因为各种限制性而无法展开或者思路不够。对于大数据，数据库关联的数据工作者来说，除了数据库的实例与系统之外，还需要思考数据存储技术。面对多云计算、多雾计算、多IDC、多系统的环境下，海量、多样、多地的数据情况下，数据存储的发展与技术是非常重要的环节。本主题通过分析与分享现代存储与未来数据存储技术、大环境等因素，给关联数据工作者提供一种思索。
分享大纲如下：
1)现代企业级数据现代企业级数据存储综述；
2)分布式存储技术
3)数据存储容灾技术
4)数据存储容灾系统的删冗技术
5)数据存储容冗余纠删码技术
6)数据存储超融合解决方案
7)数据存储技术与开源生态
8)数据存储的未来之路
成思敏，天翼数字生活科技有限公司、技术专家。 ORACLE 10G OCM，已申请数据库相关专利（发明人）9个（已授权4个），从事数据库专项工作近16年，任公司数据库架构师，技术专家、DBA主管等。擅长数据库整体架构的构建，数据库治理，数据库自动化运维设计，早期介入数据库服务研究，长期从事在云计算下的数据库运行情况难题解决，并长期公司内部 DBA 团队建设培养，对公司内部（研发及DBA）数据库技术，数据库规范，调优培训等，对云计算技术、数据技术、开源生态、系统效能等方向也有比较深刻的经验与理解。
随着 CPU 主频增速的减缓，以及业务数据的爆炸式增长，计算能力开始向专有设备发展，可计算存储(CSD)应运而生。CSD 2000和 CSD 3000是 ScaleFlux 推出的拥有数据透明压缩能力的 PCIe 接口的企业级 SSD。企业级SSD 的一个重要市场就是数据库。传统关系型数据库多是 B+-Tree 模型，设计上有很大的写放大，对 SSD不是很友好。而新兴的基于LSM- Tree 模型的分布式数据库，在这方面就显得更有优势。可计算存储(CSD)的透明压缩能力跟 B+-Tree 模型数据库结合，可以弥补 B+-Tree 数据库相比 LSM-Tree 数据库在数据存储方面的劣势。实际业务实践表明，可计算存储(CSD)可以极大的抑制 B+-Tree 数据库的写放大，降低业务数据在 SSD 内部物理空间大小，提升 SSD 寿命和数据随机读写能力。个别场景下，可计算存储(CSD)还可以对逻辑容量扩容，进一步降低客户的 TCO。CSD 2000 QLC 是市面上少有的 QLC SSD 产品之一，容量更大，性能更低。其透明压缩能力也巧妙的解决了 QLC SSD 的寿命问题。
分享提纲：
a)可计算存储(CSD)的诞生背景。
b)可计算存储(CSD)的透明压缩原理以及跟数据库压缩的区别。
c)可计算存储(CSD)产品功能特性。
d)可计算存储(CSD)在MySQL/PostgreSQL/TiDB/openGauss/DM8等数据库上的测试报告。
e)可计算存储(CSD)的客户案例分享。
分享要点：
首先，首先介绍 SSD 的写放大问题，引出可计算存储(CSD)的透明压缩如何解决写放大，以及带来的实际空间收益和性能收益。
其次，通过 MySQL 数据库的压缩方案跟可计算存储(CSD)透明压缩方案的对比展示可计算存储(CSD)透明压缩的空间压缩和性能提升收益。然后再介绍透明压缩跟数据库压缩原理的区别，以及介绍一下 CSD 2000 的原子写能力。
第三，展示其他关系数据库 PostgreSQL/openGauss/DM8 数据库在可计算存储(CSD)上的测试数据，进一步说明透明压缩给 B+-Tree 数据库带来的空间压缩和性能提升收益。
第四，对于 LSM-Tree 数据库（如 RocksdB 和 TiDB ），在并发读写压力不大数据量很大的场景下，跟 CSD 2000 QLC SSD 结合能够进一步降低大数据的存储成本同时性能也满足业务需求。
13年互联网大厂数据库运维和架构经验，原阿里巴巴数据库架构师，熟悉ORACLE/MySQL/SQL Server/OceanBase 原理、运维和业务架构。2022年加入ScaleFlux，负责可计算存储在数据库场景的研究工作。
内容简介：FastCFS是一款通用的开源分布式文件系统，由FastDFS作者余庆在2020年底推出的，它是一款保证数据强一致性、高性能、高可用，支持百亿级海量文件的通用分布式文件系统，可以作为MySQL、PostgresSQL、Oracle等数据库的后端存储。本次主题将分享集群动态扩容和负载均衡；如何实现靠谱的分布式锁；如何巧妙解决棘手的脑裂问题等。
内容大纲：
1. 分布式文件系统存在的挑战：
1) 同时做到高可靠、高性能和高可用；
2) 支持百亿级海量文件；
3) leader切换或发生脑裂，分布式文件锁如何处理。
2. FastCFS通过架构和实现系统性地解决了这几个挑战：
1) 架构简单高效，代码原生实现：保证CAP理论中的C和A，巧妙解决网络分区导致的脑裂问题；采用比RAFT更加简单高效的数据一致性模型；
2) 文件元数据采用持久化存储+缓存方案：实现了目录结构和KV系统的融合，内存中使用跳表存储目录结构，inode数据以KV格式持久化，其中key为文件inode，value为inode数据。因inode以目录结构方式组织，其数据存储和加载的复杂度远超传统的KV系统；
3) leader切换时将保持已有文件锁，解决leader脑裂问题的方案和1）一样。
本次主题演讲，将重点分享解决以上几个挑战的思路和方案。
3. 分布式存储系统选型建议
超融合或统一存储难免臃肿和复杂，出于简单和高效考虑，如果没有超融合需求，建议直接使用对象存储或分布式文件系统之类的专用存储系统。
分布式文件系统 FastDFS 作者，曾任职于新浪、雅虎中国和阿里巴巴，对分布式架构和高性能编程有着深入的研究和丰富的实践经验，目前是FastCFS的研发创始人。
随着云存储系统上数据的持续增长，对存储系统元数据面临的扩展性提出了更高的要求，比如对象存储通常有PB级的元数据、万亿级的元数据条目、百万级QPS的元数据读写压力，同时对象存储、分布式文件系统对元数据存储系统有分布式事务 、全局二级索引、分布式备份、CDC等需求，需要一个可线性扩展的分布式事务数据库来存放元数据，但是通用数据库往往因为通用性而牺牲了性能，为了解决百度云对象存储BOS、百度云文件系统CFS 元数据面的扩展性问题，我们自研了元数据底座TafDB来支撑BOS、CFS的元数据存储，极大的提升了产品的竞争力。
本次分享，聚焦于大规模元数据存储数据库系统TafDB设计和实践。分享内容包括：云存储元数据面技术演进趋势、云存储元数据底座的技术选型、云存储元数据底座TafDB关键设计和实践、TafDB应用效果
演讲内容重点提纲：
1) 云存储元数据面技术演进趋势
2) 云存储元数据底座的技术选型
3) 云存储元数据底座TafDB关键设计和实践
4) TafDB应用效果
2014年加入百度后一直从事基础架构领域研发，先后负责了百度实时计算平台以及百度云元数据存储平台，带领团队从0到1打造了百度云存储的元数据底座，并在百度云对象存储、文件系统大规模上线，现任百度云存储部架构师、元数据底座TafDB技术负责人。
关于数据库机房界别容灾，一直是企业对数据库架构发展的里程碑目标之一，机房级别的容灾也是一种在资金成本、人力投入成本都是巨大的项目，而其带来的价值也是不言而喻的。但往往每个企业都会有自己的行业特性、架构特性、历史技术债务等特征，这些特征会导致大多数其他企业的成功案例或者方案无法复刻到自身企业，同时伴随着时间、成本不断投入，从0到1的摸索不可规避。 所以企业会希望专业的数据库人员可以在短的时间里掌握整体架构实现，拿捏细节，完成双中心容灾方案的实现。但具备实战经验的人员占比毕竟少数，所以一些有效的实战经验的借鉴在双中心构建的前期、中期、后期是非常重要参考依据。
本次分享，我会通过自身的实战构建双中心的经历，来和大家一起回溯、总结，我是如何在同程旅行面对万级体量的MySQL架构下，从0到1设计、构建双中心架构。在这个过程中我们的架构设计是如何做的、我们的阶段性拆分是为什么、我们遇到了什么问题以及是如何处理解决或规避的，后面我还需要继续做哪些事情等等。希望用自身的经验提炼通用的方法论，在不同方面帮助大家在面对双中心架构时更好的达成目标。
演讲内容重点提纲：
1)构建双中心前的准备工作有哪些
2)同程旅行MySQL双中心架构设计
3)我们遇到了什么样的风险、我们是如何思考和解决
4)同程旅行数据库双中心构建的三步曲
现任同程旅行数据库、运维研发负责人。从事数据库运维研发工作14年，覆盖MySQL、SQL Server、MongoDB、Redis、MongoDB、TiDB相关架构及自动化管理。曾就职于马蜂窝、神州优车、汽车之家等企业，毕业于北京航天航空大学，热爱数据库、热爱开源，致力参与在MySQL 3306π社区，通过社区推动和分享更多数据库知识和方案给大家。
