《MySQL 容器化部署实践》 演讲者／王晓波 背景 ■ 同程旅游早期的数据库都以单库的MySQL。 ■ MySQL的单库，导致TPS最终还是会成为一个瓶颈。 ■ MySQL+DB中间件解决水平拆分问题。 ■ MySQL水平拆分的引入会使数据库实例数量大幅上升,传统运维手段维护成本高,交付能力差。 MySQL数据库为何要Docker化 1.MySQL数据库迅速爆炸式增长后，服务器规模不断增大，快速部署是个问题。 题。 3.大量数据量小的数据库系统也单独部署在物理机，浪费问题突出。 4.DBA的数据库自动化标准化运维的需求。 5.Docker在同程的大规模使用，应用部署环境100%容器化，有Docker丰富的经验 。 让数据库的部署点单化开启 2核4G 4核4G 4核8G 8核8G 8核16G 16核16G 16核64G 32核64G 32核128G 一主一从 分片集群 一主多从 SATA-SSD

clickhouse数仓应用实践 演讲人：朱元 日期： 2019-10-20 所遇问题 目录 CONTENTS 现状背景 应用实践 01 数据链路长 现状 即席查询性能差 数据压缩率低 需求响应慢 02 数据架构 数据同步ck 01 1，基于公司对数据要求为T+1 2. 基于现有开发人员水平及成本 因此采用可视化同步工具kettle. 先将oracle数据平台维

云 原 生 社 区 M e e t u p 第 五 期 成 都 站 云原生社区Meetup成都站 2021/07/03 基于 TiDB 的云原生数据库实践 演讲人：王天宜 PingCAP 云 原 生 社 区 M e e t u p 第 四 期 成 都 站 目录 为什么云原生数据库要拥抱 Kubernetes 什么是云原生数据库 TiDB 在 AWS 上的最佳实践 1

AGI趋势下的云原生数据计算系统 演讲人：徐阳 拓数派：大模型数据计算系统先行者 l 拓数派（ OpenPie）是立足于国内的基础数据计 算领域高科技创新机构； l 拥有强大的数据库内核研发团队、数据科学家团 队和数字化转型团队； l 国内虚拟数仓和eMPP技术提出者，不断在数据 计算引擎方向进行创新，全面拥抱AI技术趋势。 企业介绍 云原生数据计算系统 围绕数据组织云原生计算系统，

全球敏捷运维峰会 广州站 基于ClickHouse+StarRocks 构建支撑千亿级数据量的高可用查询引擎 演讲人：蔡岳毅 全球敏捷运维峰会 广州站 1. 为什么选择ClickHouse/StarRocks； 2. ClickHouse/StarRocks的高可用架构； 3. 如何合理的应用ClickHouse的优点，StarRocks 如何来补充ClickHouse 的短板；

信仰开源，做分布式数据库的，叫 TiDB（好像还蛮火的） TiDB 是分布式的，PingCAP 这个公司也是分布式的（北京、上海、广州、深圳、成 都、杭州、新加坡、东京、硅谷） We're hiring! 今天的演讲内容来自我最近的一个真实经历。。。。 一个真实的故事 老板：怎么应用那么卡？ 前端开发：是不是你网络不行 老板：换了个网还是一样 前端开发：找到原因了，这个 REST API 卡了几秒返回

Greenplum运维常用命令  Greenplum日常检查和故障处理  Greenplum项目经验分享 目录  Greenplum运维常见问题  Greenplum运维常用命令  Greenplum日常检查和故障处理  Greenplum项目经验分享 内核参数  通常情况下，内核参数按照GPDB安装手册配置，如需要增加连接数支持，以下参数需要增大 系统表（pg_class,pg_attribute）太大，影响系统工作效率 – 系统元数据检查pg_checkcat等工具运行时间比较长 物理模型经验分享 物理模型对于系统性能有很大影响，因此需要我们特别关注。 以下来自于在某大型银行的使用经验： 行存储和列存储： • 避免过多使用列存储的原因是防止小档数过多。 • 列存储能够提升查询性能，对于更新和全字段类操作性能反而会下降 ，这个可以提高关联条件的命中率，减少关联时数据重分布 （主要对大表） • 选用分布键同时考虑数据平均分布（一个例子，日志号不是最好的分布键，大量的空值导致资料倾斜） 物理模型经验分享（续） 分区表使用： • 不建议使用二级分区，二级分区不便于管理，而且Parser效率较低； • 二级分区可以用一级分区+Bitmap方式替代，例如按照“发生日期”做分区，然后在机构字段上将bitmap索引

master 架构业界一直 有所争论。 从功能上而言 master 节点是对外服务的入口，用户所有的请求都必须 先经过 master，所以 master 节点的可用性直接关系到集群的稳定， 但从实践经验来看，由于 master 节点只存元数据，只负责 SQL 的解析、 分发以及最终计算结果的展现，所以承担的负载一般都非常小，故障 率也极低，在我们维护阿里 Greenplum 集群 3 年的时间里，以及接触 卡（单块 RAID 卡的 cache 大小 1GB 以上，并带有掉电保护 功能，RAID 卡应为多通道，目前接触的硬件厂商中，单通道支持的最 大磁盘数为 16 块） ·硬盘尽量选 用 SAS 盘，从实践经验看，硬盘故障是 Greenplum 集群中最为常见的故障类型，而 SAS 盘相比 SATA 盘在性能和稳定 性上都明显的高于 SATA 盘 。 ·RAID 卡一定要带 cache，否则做完 RAID 维护加上完善的软硬件监控，才是真正保证企业级数据仓库成功实 施关键。 Big Date2.indd 28 16-11-22 下午3:38 Greenplum 精粹文集 29 四、Greenplum 实施经验谈 近两年，国内的大数据市场逐渐成熟，有真实的大数据处理需求的企 业数量呈现爆炸性的增长，从传统的数据库产品往 MPP 数据库转型 的增长势头十分迅猛。Greenplum 作为 MPP 产品的领头羊，具有较

资源，具体的比例需要根据数据库的适用场景进行综合评估。例如在生产环境，每个 Instance 所在的主机配置了 2 个 16 Core 的 CPU，可根据不同的场景，配置 4 ~ 12 个不等的 Primary，这个数字的选择需要由富有经验的专业技术支持人员进行评估， 每个 Instance 所在主机配置的 Primary 越多，响应并发的能力越弱，但单个任务的 处理能力越强(这也不是绝对的，当 Primary 数量多到，即便运行单个任务时都会出 pg_hba.conf 文件控制着客户端连接到 GP 系统的认证。 在 Instance 上也存在 pg_hba.conf 文件，通常此文件已经被正确配置为允许从 Master 访问。不过根据以往的经验来看，也出现过配置错误的情况，该情况会导致 gpexpand 之类的操作报错失败。通常来说，Instance 是不需要接受外部客户端连 接的(如果需要，必须通过 Utility 模式连接)，不太有必要去修改 实用意义，忘记这个事情就好了， 好好使用ZSTD就对了。 在列上设置压缩 注意：编者不希望读者浪费很多时间来学习这部分的知识，所以，先把观点列出来，编 者根据10年的经验判断，除了作为一块知识来学习外，可能永远也不需要在每个字段 上设置压缩，因为那是极其多余和毫无意义的。在真实的使用环境中，往往列存储的选 择都应该是极其少见的，因为列存储的选择需要满足多方面条件，选择列存的往往是那

Group Replication原理解析与实践经验 徐春阳 MGR原理 MGR vs SEMI-SYNC MRG实践经验 • 支持多节点并发执行事务。如何保证从各个节点并发执行 的事务在每个节点以相同的顺序被应用/执行.------paxos协 议的功能。 • 自动地事务冲突检测。节点之间不能”同时”操作主键相同 记录,如果冲突，只有一个节点成功。------冲突检测。 inspected */! }! ! delete packet;! ��incoming������ ���/packet! MGR原理 MGR vs Semi-Sync MRG实践经验 MGR vs Semi-sync����! Semi-sync! MGR! ����� mysql5.7! refman! MGR vs Semi-Sync� �! �������� primary���MGR���� ����������������! MGR�������������� ����������! MRG原理 MGR vs Semi-Sync MGR实践经验 Group_replication_bootstrap_group参数须谨慎 DDL操作注意事项 当心secondary节点变成可写节点 规避大事务 Secondary��������