MySQL到TiDB：Hive Metastore横向扩展之路( 四 ) _MySQL

文章插图
针对不同执行计划的特性，整理了以下对比点：

文章插图
在实际生产中元数据基本都是按天分区为主，每天增长大概有26w左右，且范围查询的使用场景较多，使用idx_PART_KEY_VAL索引查询的执行计划不太适合线上场景，故该索引需不适合添加到线上环境。
4.3 TiDB内存突增导致宕机问题在刚上线TiDB服务初期，曾数次面临TiDB内存溢出的问题，每次出现的时间都随机不确定，出现的时候内存突增几乎在一瞬间，若期间TiDB的内存抗住了突增量，突增部分内存释放在很长时间都不会得到释放，最终对HMS服务稳定性带来抖动。

文章插图
通过和TiDB开发、DBA联合分析下，确认TiDB内存飙高的原因为用户在使用Dashboard功能分析慢查询引起；在分析慢查询过程中，TiDB需要加载本地所有的slow-query日志到内存，如果这些日志过大，则会造成TiDB内存突增，此外，如果在分析期间，用户点击了取消按钮，则有可能会造成TiDB的内存泄漏。针对该问题制定如下解决方案：

使用大内存机器替换原小内存机器，避免分析慢查询时内存不够
调大慢查询阈值为3s，减少日志产生
定时mv慢查询日志到备份目录

4.4 locate函数查询不走索引导致TiKV负异常在HMS中存在部分通过JDO的方式去获取分区的查询，该类查询的过滤条件中用locate函数过滤PART_NAME数据，在TiDB中通过函数作用在字段中是不会触发索引查询的，所以在该类查询会加载对应表的所有数据到TiDB端计算过滤，TiKV则需不断扫描全表并传输数据到TiDB段，从而导致TiKV负载异常。

文章插图
然而上述的查询条件可以通过like方式去实现，通过使用like语法，查询可以成功使用到PARTITIONS表的UNIQUEPARTITION索引过滤，进而在TiKV端进行索引过滤降低负载。

文章插图
通过实现将locate函数查询转换为like语法查询，有效降低了TiKV端的负载情况。在HMS端完成变更后，TiKV的CPU使用率降低了将近一倍，由于在KV端进行索引过滤，相应的io使用率有所上升，但网络传输则有明显的下降，由平均1G降低到200M左右。

文章插图
除TiKV负载有明显的降低，TiDB的整体性能也得到明显的提升，各项操作耗时呈量级降低。以下整理了TiDB增删改查的天平均耗时情况：

文章插图
4.5 get_all_functions优化随着hive udf的不断增长， HMS的get_all_functions api平均耗时增长的也越来越久，平均在40-90s，而该api在hive shell中首次执行查询操作时会被调用注册所有的udf，过长的耗时会影响用户对hive引擎的使用体验，例如执行简单的show database需要等待一分钟甚至更久才能返回结果。

文章插图
导致该api耗时严重的主要原因是HMS通过JDO方式获取所有的Function ，在获取所有的udf时后台会遍历每条func去关联DBS、FUNC_RU两个表，获取性能极低。而使用directSQL的方式去获取所有udf数据，响应耗时都在1秒以内完成，性能提升相当明显。以下为directSQL的SQL实现逻辑：

select FUNCS.FUNC_NAME,DBS.NAME,FUNCS.CLASS_NAME,FUNCS.OWNER_NAME,FUNCS.OWNER_TYPE,FUNCS.CREATE_TIME,FUNCS.FUNC_TYPE,FUNC_RU.RESOURCE_URI,FUNC_RU.RESOURCE_TYPEfrom FUNCSleft join FUNC_RU on FUNCS.FUNC_ID = FUNC_RU.FUNC_IDleft join DBS on FUNCS.DB_ID = DBS.DB_ID

五、总结我们从2021年7月份开始对TiDB进行调研，在经历数个月的测试于同年11月末将MySQL引擎切换到TiDB 。由于前期测试主要集中在兼容性和性能测试上，忽略了TiDB自身可能潜在的问题，在上线初期经历了数次因慢查询日志将TiDB内存打爆的情况，在这特别感谢我们的DBA团队、平台运营团队及TiDB官方团队帮忙分析、解决问题，得以避免该问题的再次发生；与此同时，由于当前HMS使用的版本较低，加上大数据的组件在不断的升级演进，我们也需要去兼容升级带来的变动，如HDFS升级到3.x后对EC文件读取的支持，SPARK获取分区避免全表扫描改造等；此外由于TiDB的latin字符集支持中文字符的写入，该特性会导致用户误写入错误的中文分区，对于此类型数据无法通过现有API进行删除，还需要在应用层去禁止该类型错误分区写入，避免无用数据累积。