TiDB官方
(TiDB 官方)
62
TiCheck 是否支持慢查询报告和每日备份报告？
1 个赞
说到这个话题，非常想来吐槽一下。我自己用虚拟机搭的测试用集群，存了1.3亿条结构化日志数据，本来想用TiDB做一下分析，但可惜稍微复杂一点的SQL就跑不出结果来，不是TiFlash timeout就是TiKV OOM，再不然就是跑20分钟不出结果。因此写了不少代码来协助统计，还把部分数据导出然后用HiveSQL跑了一部分分析任务。虽然部署环境打不到官方建议，但相同的虚拟机集群用HiveSQL就能跑出结果来，而且还能显示MapReduce的进度。这次对TiDB有点失望。
在处理技术的过程中，遇到技术问题是非常常见的事实~
asktug 也欢迎你来发帖咨询
数据小黑
(数据小黑)
68
最近测了一个数据，对比给你看一下，我从线上环境里面抓取了一个三表关联SQL，一个事实表数据三千七百万，两个维表数据几千，三个部署实例上查询时间分别为：41秒，2.4秒，2.8秒
案例1，41秒是在TiDB上测试，3+3+3,9台16C32G的配置的虚拟机
案例2，2.4秒也是在TiDB上测试，3+3+3，混合部署在三台16C32G的虚拟机上
案例3，2.8秒是在StarRocks上测试的，跟案例2混合部署在一起
从这个数据上来看，我特别想吐槽，怎么给的硬件越多越慢，这是什么神仙数据库，
后来找了一下原因，
- 底层磁盘IO不一样，案例1机器：8k大页 写 729 kB/s 读 24.6 MB/s，案例2和案例3：8k大页 写 2.6 MB/s 读 67.7 MB/s
- 案例1是5.4.0，事实表按月分区+tiflash 1副本；案例2是6.0.0，事实表按月分区+tiflash 1副本，开动态剪裁，开分区表MPP
列这些数据其实想说一个事，硬件不一样，版本不一样，参数不一样，结果千差万别，您描述的那些问题，有没有找找硬件、参数等等方面的问题调整一下，我个人感觉，没有万能的数据库，也没有一无是处的产品，从沙利文的2021年中国分布式数据库市场报告来看，TiDB处于领导者象限，头部厂商，TOP3，应对个1.3亿的小表应该问题不大。
2 个赞
我的测试集群5台4c8g虚拟机，数据也是业务产生的同一份历史数据，专门用于测试选型，硬件完全一样，不同的数据库引擎可以分别启动，不互相影响，而且没有其它工作负载，我得到的测试结果对于我们自己的业务更有价值。针对您给出的建议，我也谈谈我的看法。
- 硬件和参数优化的空间都很大，但这么点数据就要到了需要优化硬件和参数的地步了吗？是否优化、怎么优化是个代价的问题。如果数据量确实特别大，如果硬件确实成了瓶颈，那做优化是值得的。在查询结果集远远小于任何一台虚拟机内存的情况下还会出现OOM的情况本身就说不过去。还有不可解释的查询超时，十分钟已经足够把这些数据全表扫描四五遍了，这种情况下还有优化的必要吗？我觉得最需要优化的不是参数，而是执行引擎本身。
- 我还遇到过TiKV OOM，一个存算分离架构的存储节点竟然会OOM，这本身就是一个很可笑的问题。
- TiDB确实不是一无是处，我谈的缺点都是OLAP方面的，因为我对TiDB在OLTP方面的表现没有疑问。
- 排名别光看中国的，也看看国际的。
宣传很美好，我听了宣讲，考了认证，然后做测试本想用TiDB把所有HTAP的所有任务都统一到一个集群，那样省心又省力。但测试结果很骨感，TiDB目前在OLAP领域只是个入门参赛选手。至少我是绝对不会建议任何人用TiDB去做OLAP任务的。
另外多说几句关于MapReduce+HDFS的话。在测试TiDB之前我对MapReduce+HDFS还没有特别的感受，但测试完TiDB更加深刻地认识到MapReduce+HDFS的计算模型有什么好处了。虽然MapReduce任务效率低，每个任务都需要遍历全表，但每个map task只处理128MB数据，然后对中间结果进行持久化，这种计算模型几乎不存在OOM的可能性，也不会要求至少32G内存，还可以借助HiveSQL和SparkSQL又提升了开发效率。虽然ClickHouse、StarRocks、TiDB在很多分析任务上比Hadoop生态快得多，但我目前还没听说能够完全替代Hadoop的产品。
dba-kit
(张天师)
70
同意你的观点，没有万能的数据库，只有合适的数据库，要针对应用场景而言。
TiDB对纯OLAP的应用场景确实并不是最好的架构，这点其实在官方文档- TiDB 简介里也明确指明了，TiDB最适合的场景还是OLTP，其次是对实时性要求高的Real-time HTAP。
对纯OLAP而言，TiDB所需的资源会比基于Hadoop的框架更多，性能也要求更高，否则是达不到理想性能的。
dba-kit
(张天师)
71
不过你遇到的TiKV OOM问题，其实大概率还是参数问题，TiDB并不是常见的Hadoop生态那种完全计算、存储分离的架构，为了尽快将结果计算出来，TiDB更倾向于将算子下推到TiKV节点，这样在TiDB Server的计算节点需要汇总的数据最小，网络传输也更少，可以更快的响应服务请求。这样TiKV也会有一个Bufferpool，再加上TiKV内部使用的RocksDB来进行存储，RocksDB也有自己的Bufferpool，两者默认都是按照百分比来设置的，本来就需要仔细计算，并给一定的buffer。由于你用的虚拟机只有4C8G，确实很容易OOM。
TiDB对资源要求高这一点，确实对纯试用的用户不太友好
我知道TiKV为什么会OOM，但这是种本末倒置的表现。就好像从硬盘读数据的时候硬盘报了个错，告诉你缓存不够用一样的情况。做优化、做算子下推的前提是能够完成基本的功能，现在好了，为了优化连数据都给不出来，不是本末倒置吗。
对资源要求高本身就是一种计算引擎优化不够的一种表现。我用4c8g遇到了OOM，换成40c80g没有OOM了，但这只是掩盖了问题而已，当我的数据规模也乘10之后照样还会遇到OOM。所以我在做测试的时候会用比单机内存大，但不超过集群内存总数的数据规模，这样能看出数据库对资源的利用效率做的优化够不够。实际上我测试的时候最终结果集至多十几万条，这样还是OOM，就不是优化参数能解释的问题了。事实上TiDB已经被我踢出OLAP的考虑范围了。
dba-kit
(张天师)
73
这个还真不是简单的乘法问题，你得给TiDB冗余的空间，巧妇难为无米之炊。4C8G会OOM，但是你数据量乘以10倍，TiKV节点给到32C64G即便在默认配置不调优的情况下，有90%以上的概率不会OOM。
不过看你描述的，对你而言OLAP不用TIDB可能还真是基于成本的明智选择。什么时候你需要考虑并发、考虑Latency、考虑事务时候，再选择TiDB吧
我上一个回复说“这只是掩盖了问题而已”，现在你成功掩盖了90%以上的问题。上面没细说我为什么得到这么个结论，这回掰开详细说说。
-
为什么会出现OOM异常？
OOM有两种情况，一种是执行引擎检测到某个查询所需要的内存超过了配置中的限制，从而主动抛出OOM异常；另一种是执行引擎申请的内存数量超过操作系统可用物理内存，从而被OS杀掉进程，这是种被动OOM。很不幸的是我在TiDB中这两种OOM都遇到过，前者是“Out Of Memory Quota!”，在这个讨论 TiDB 5.4面对业务方超级复杂的大SQL，直接Out Of Memory Quota! - TiDB / 部署&运维管理 - TiDB 的问答社区 (asktug.com)中我表明了观点。而后者被动OOM则是代码内存管理缺陷，没有节制地分配内存，并且没做好缓存的淘汰策略导致的问题。
-
为什么说出现OOM是执行引擎不够优化的表现？
举例来说，如果我要排序的数据有1G，可以直接申请1G内存，用快速排序，这种代码在绝大多数电脑上都能搞定。但如果我要排序的数据有10G，在8G内存的电脑上就会OOM了。如果我的代码多考虑一些情况，在检测到内存不够用的时候将中间结果先保存到硬盘，用外排序算法，那么只用几十MB的内存就能完成任务，代码再优化一些1T数据也能搞定。
你的建议是用升级到64G内存，如果我的业务中99%的任务排序都不超过60G数据，那升级确实解决了99%的问题。但是大数据时代有一个基本的前提：数据是无法在单独一台服务器中存储并计算的。或者说，数据规模增长的速度远高于硬件性能增长的速度。不管你64G甚至是256G，都远远小于数据规模。分布式数据库的理念就是为了解决这个矛盾：一台存不下我存到多台，一台内存不够用我就同时利用多台的内存。数据太大就加CPU、加内存的理念是IOE（IBM、Oracle、EMC）解决方案的典型观点，几TB的内存只是小型机的门槛，这在某些领域仍然适用，但不是分布式数据库解决扩展性问题的思路。
TiDB很好地解决了分布式系统存储容量问题以及存取性能问题，但OOM的问题反应了TiDB还没有解决单节点内存不够用的问题。也就是说，TiDB存在单点内存瓶颈。这在大数据时代OLAP领域是个硬伤。
再说点乐观的话题。TiDB目前存在的OOM问题不是架构上的问题。相反，TiDB的存算分离与MPP架构是我最看好的分布式数据库架构。OOM问题是完全可以解决，也是以后一定要解决的问题。在这方面MapReduce和Spark都是很好的参考。
讲了这么多，最后再总结一下我的核心观点：OOM反映的本质问题是TiDB的OLAP引擎需要优化，而硬件、配置的优化只能解决一部分问题，但解决不了单点内存瓶颈这一本质问题。
运维工作中部分事情必须使用代码完成 尤其是量的 后期又需频繁的处理的 太值得使用代码了 即高效又能保证质量
yukai701
(Yukai701)
79
以前用shell搞过一些运维工具，目前在学python+ Django
