BaikalDB在同程艺龙的应用实践（二）

2020-07-13 733

本系列文章主要介绍 BaikalDB在同程艺龙的落地实践

作者简介：王勇，同程艺龙架构师，BaikalDB Column Store Contributor，专注于分布式数据库方向的研发工作

欢迎Star关注 BaikalDB (github.com/baidu/BaikalDB) 国内加速镜像库gitee

BaikalDB 高性能和扩展性实践

本系列文章把BaikalDB总结为六个核心特性如下图，上篇文章BaikalDB高可用与HTAP特性实践主要与前两个有关，本篇讨论中间两个，下篇将讨论最后两个。

这也是我们在业务推广中的关注次序，即

首先必须（Must to）业务场景匹配精准（1一致性）和运行平稳（2高可用）
其次最好（Had better）是数据多（3扩展性）与跑的快（4高性能）
最后应该是（Should）使用友好（5高兼容性）与成本节省（6低成本）

简称：稳准多快好省。

本文将会通过介绍业务落地前的两个实际测试案例，来分享总结BaikalDB在性能与扩展性方面的数据。

基于行存OLTP场景的基准测试

测试目标

如果把BaikalDB看成一款产品，基准测试的目的就是加上一份产品规格说明书，在性能测试同学的参与下，我们进行了为期2个月的基准测试，并给BaikalDB这款产品的外包装上写下如下关于规格的信息：

设计的集群最大规模，在 1000 个节点情况下，能支持 18 种数据类型，单节点 1T 数据容量，集群整体1P容量。
在基准数据测试下，集群单点性能达到，write不低于2000 QPS，单次write不超过 50 ms， read性能达到不低于4000 QPS,单次read不超过 20 ms。
对外接口基本兼容MySQL 5.6版本协议。
基于Multi Raft 协议保障数据副本一致性，少数节点故障不影响正常使用。
Share-Nothing架构，存储与计算分离，在线缩扩容对性能影响仅限于内部的数据自动均衡，而对外部透明，新增字段30s生效对集群无影响。

测试范围

性能测试（行式存储，大表104字段，小表63字段，集群总基础数据1TB，2TB，3TB）
- 与mysql基准对比测试
- 表结构字段个数影响（大表104字段，小表63字段）
- 集群总基础数据大小影响（1TB，2TB，3TB）
- 表结构影响（"自增主键"，"片键做全局索引"，"片键做主键"）
带压力的扩展性测试
- 加节点（store）
- 减节点（store）
- 动态加列

测试环境

五台机器混合部署3 meta, 5 db, 5 store获取基准，另有一台机器作为增减节点机动（centos 7.4 32核 2.4GHZ，128G内存 1.5TSSD硬盘）

主要指标说明

最佳容量（KTPS）：
- 定义
  - 系统最大吞吐能力: 每秒dml操作请求数
  - 单位为KTPS（千次操作请求/秒）
- 前置条件：
  - 5台机器配置的集群（3 meta, 5 db, 5 store）
  - 连续两分钟可以稳定支撑的最大吞吐能力
  - 平均读响应时间小于20ms，平均写响应时间小于50ms
响应时间：dml操作从发送到收到返回结果所经过的时间，单位为毫秒
diskIOUtil 磁盘使用率: 一秒中有百分之多少的时间用于 I/O 操作,或者说一秒中有多少时间 I/O 队列是非空的
- 如果接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。
- 大于30%说明I/O压力就较大了，读写会有较多的wait
最佳容量判定方法

绘制系统的性能指标随着并发用户数增加而出现下降趋势的曲线，分析并识别性能区间和拐点并确定性能阈值。

测试结论

性能测试
- 读：片键做主键模式，5节点读容量为72K+TPS，性能比mysql高85%+，瓶颈为CPU
- 写：片键做主键模式，5节点写性能为9.6K+TPS，与mysql相当，为mysql的85%~120%之间，瓶颈为DiskIO
扩展性测试
- 加节点：前端吞吐平稳
- 减节点：减节点操作需要确保集群能力有足够的余量，能承载被减掉节点转移的压力
- 加列： 22秒新列生效（1.25亿基础数据）

性能测试详情

与mysql基准对比测试

表结构字段个数影响

集群总基础数据大小的影响

表结构影响

扩展性测试详情

不停服增减节点

不停服增加列

不停服加列测试过程曲线图（22秒后所有的带新列的insert语句全部成功，红色曲线代表失败数降为0）

基于列存OLAP场景测试

测试背景

指标监控系统用于实时（定时）监控线上某实时业务数据，生成关于健康状态的相关指标，如果指标超出阈值，则触发报警功能。数据表约50列20亿行，查询sql10余种均为聚合类查询，检索列数不超过4列，查询条件为一定时间区间的范围查询，之前是跑在一款行存的分布式数据库之上，这是一个典型的olap类场景，我们采用baikaldb的列存模式与线上进行了对比测试，测试对象均为线上真实数据，两款DB集群配置相当，测试查询性能的同时，均承担等同的写负载。

测试结果

从测试结果可以看出，在宽表少列与聚合查询的sql查询，使用baikaldb的列式存储，可以有效减少磁盘IO，提高扫表及计算速度，进而提高查询性能，这类查询也是olap场景sql的常见写法。

性能与扩展性总结与思考

性能分析的几个角度

资源瓶颈视角
- CPU : 多发生在读qps过大时（db，store），可监控vars/bthread_count指标
- IO：多发生在写qps过大时（store），可监控io.util指标，及store/rocksdb/LOG日志。
- Mem：
  - io.util满可导致内存刷盘不及时进而引起内存满（store）；
  - 慢查询过多时，会导致查询积压于store，进而引起内存满（store）；相关参数db： slow_query_timeout_s=60s ；
  - store内存建议配置为所在实例的40%以上，因为内存直接影响cache命中率，cache miss过多的话，会增大io.util及sql用时；相关参数：cache_size=64M
  - export TCMALLOC_MAX_TOTAL_THREAD_CACHE_BYTES=209715200 #200M，当大value时，调大可以避免线程竞争，提高性能。
- Disk：
  - io.util满可导致rocksdb的L0层文件压缩不过来，出现快速的空间放大，进而导致磁盘快速被写满。相关参数：max_background_jobs=24
  - rocksdb数据文件不建议超过1T，按照默认配置，超过1T后rocksdb将增加1层，写放大增大10，写放大会导致io.util出现瓶颈。若服务器磁盘远大于1T，建议单机多实例部署。
- NetWork：
  - 查询及事务大小建议控制在10M以内，数据量过大会触发事务及RPC包大小限制；
  - 若需全量导出，用 /*{"full_export":true}*/ select * from tb where id > x limit 1000; 语法。

用户视角

联合主键 vs 自增主键
- BaikalDB是按主键进行分片的，主键的选择影响了数据的物理分布，好的做法是把查询条件落在尽量少的分片上，查询时基于前缀匹配，一般建议按范围从左到右建立联合主键，例如：class表主键可设置为schoolid，collegeid，classid # 学校，学院，班级;
- BaikalDB实现自增主键主要是为了与MySQL兼容，由于全局自增是通过meta单raft group完成，会存在rpc开销及扩展性问题；另外全局自增主键也容易导致数据批量插入时请求集中于最后一个Region节点，容易出现瓶颈。
全局索引 vs 局部索引
- 全局索引与主表不在一起，有自己的分片规则，好处是有路由发现功能，坏处是多了与全局索引的RPC开销，局部索引与主表一起，需要通过主键确定分片，否则需要广播，好处是RPC开销。
- 小表建议用局部索引；
- 大表（1亿以上），查询条件带主键前缀，用局部索引，否则用全局索引。
行存 vs 列存
- 宽表少列（查询列/总列数小于 20%），聚合查询的olap请求用列存
- 其他情况用行存

实现视角

Balance：BaikalDB会周期性的进行Leader均衡与Peer均衡，负载均衡过程中若数据迁移量较大，可能是影响性能，一般发生在：
- 增删节点时
- 批量导入数据时
- 机器故障时
SQL Optimizer：目前主要基于RBO，实现了部分CBO，若性能与执行计划有关，可以使用explain，及 index hint功能调优。

扩展性考虑因素

稳定性
- 扩容：从实测情况看，扩容情况下比较平稳
- 缩容：缩容较少发生，但在双中心单中心故障的情况下，相当于缩容一半，此时稳定性还是值得注意与优化的，主要包括：
  - meta，尤其是主meta挂了情况下，将不能提供ddl，主auto incr 挂了情况下，将不能提供自增主键表的insert功能。
  - store读正常，但瞬间一半store leader挂了情况下，写功能需要等到所有leader迁移至健康中心为止。
极限容量：
- 计算逻辑如下
  1. Region元数据=0.2k， Meta20G内存共计可管理的 Region总数 = 20G/0.2k = 100M
  2. Region数据量 = 100M，Store 1T磁盘共可管理的 Region个数每store = 1T/100M = 10k
  3. 共计可以管理的数据量 = Region总数 * Region数据量 = 100M * 100M = 10P
  4. 共计可以管理的store个数 = Region总数 / Region个数每store = 100M/10k = 10k
- 理论上Meta 20G， Store 1T磁盘情况下，预计可管理 10k个store节点， 10P大小数据。
- 实际上百度最大的集群管理了1000个store节点，每store 1T磁盘，共计约1P的集群总空间。
线性
- 固定范围：O（1）
- 可以下推store全量： O(n/db并发度)
- 不可下推store全量： O（n）
- JOIN查询： O（n^2）

后记

本文的性能与扩展性分析数据均来源于实际项目，而非TPCC，TPCH标准化测试，但测试项目据有一定的代表性。
BaikalDB测试数据基于V1.0.1版，最新发布的V1.1.2版又有了较多优化：
- 优化seek性能，实测range scan速度提高1倍；
- rocksdb升级6.8.1，使用Partitioned Index Filters，进一步提高了内存使用效率；
- 增加利用统计信息计算代价选择索引功能（部分）；
- 事务多语句Raft复制拆分执行，提高了Follower的并发度。

下篇预告：BaikalDB 低成本思考，敬请关注~

微信关注我们

原文链接：https://my.oschina.net/BaikalDB/blog/4362070

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

Python 从源码到执行

0.介绍一下常见的编译模型: Java, Python, C 在今天的主题之前，先来了解下几个典型的编译模型。松本行弘先生，在讲解语言处理器构成时列举了一个通用架构。 source code | | \./ ---------- --------- |Compiler| ---mid code---> |Runtime| ---------- --------- /.\ | | --------- | Lib | --------- 处理器主要由三部分组成: 编译器(Compiler)，运行时(Runtime)，库(Lib)。编译器(Compiler): 顾名思义，就是编译源码的程序。通常情况下，它会将源码编译成运行时(Runtime)识别的中间码，但是在极端情况下，如 C 中，因为没有运行时(Runtime)，就直接输出机器码了。编译器(Compiler)在这过程中可能还会自己对源码进行优化，并剔除一些运行不必要的信息，比如注释等。运行时程序(Runtime): 这个程序用于代码的具体执行，最被熟知的是 JVM，所以也可以把它叫做虚拟机好了库(Lib): 库很好理解，就...

2020-07-12

707

在国内dubbo成为很多互联网公司高并发分布式场景下rpc框架的首选，dubbo从开源至今经历过蛮多的过程，从开源到中间的停止维护，经过三年的沉寂，2017年9月，阿里巴巴宣布重启dubbo项目。到2018年2月，阿里将dubbo捐献给Apache基金会，随后dubbo经过孵化后顺利成为apache的顶级项目。当然本文的重点不是介绍dubbo的使用，而是介绍如何利用smart-doc工具来生成dubbo的rpc内部接口文档。smart-doc因为其基于注释和java接口定义自动推导的理念，开源以来受到国内很多开发者的喜爱。在开源之初，smart-doc仅仅支持restful api文档的生成，但是在发展的过程中，不断有开发者询问smart-doc能否支持dubbo rpc接口文档的生成。经过不断努力，在smart-doc 1.8.7版本中我们增加了dubbo rpc接口的支持，下面来看看真正的操作。一、集成smart-doc smart-doc本着使用简单的原则开发了maven插件和gradle，通过插件来降低smart-doc的集成难度和去除依赖侵入性。您可以根据自己使用的依赖构...

2020-07-13

738

资源下载

更多资源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。