tidb数据库优缺点（tisidb数据库）



HBase凭借其高可用性、高扩展性和强一致性，以及在廉价PC服务器上的低部署成本，广泛应用于大规模数据分析。然而，随着业务需求的变化，HBase在某些功能上显现出不足。针对HBase历史业务场景的核心痛点，腾讯云数据库产品TDSQL MySQL版（TDStore引擎）提供了适配方案，助力业务成功上云，并解决了业务多年来的瓶颈，实现了成本与性能的双重优势。

一、引言

HBase是一个建立在Hadoop之上的分布式KV数据库系统，首个独立版本于2010年2月发布。凭借其高可用性、高扩展性和强一致性，以及在廉价PC服务器上的低部署成本，HBase迅速成为物联网、社交网络和监控数据存储的首选方案，并在大规模数据分析领域得到广泛应用。然而，随着业务需求变化，HBase在某些功能上显现不足，如缺乏二级索引和不支持跨行事务等。与此同时，随着数据库技术不断进步，NewSQL日益崭露头角，TDSQL MySQL版（TDStore引擎）采用了主流NewSQL架构，具备容器化云原生管理能力，并100%兼容MySQL 8.0语法。此外，TDStore支持原生Online DDL，可动态更改表结构，并具备高效的压缩存储能力，降低成本的同时支持海量存储。本文将深入探讨在历史库场景中使用TDStore替换HBase所带来的成本和性能优势。

二、使用HBase的业务场景和痛点

HBase在扩展性以及存储方面具备一定优势，能够满足业务系统的历史库使用需求。在过去的十多年里，许多大型公司和组织使用HBase作为海量数据的首选存储方案。例如，在金融领域，监管机构要求金融机构对交易记录、客户信息等敏感数据进行长期保存，以便在必要时进行追溯和核查。

腾讯金融科技业务系统的历史库也曾广泛采用HBase，但使用HBase后也出现了一些核心痛点。

1）、业务背景

上图是腾讯金融科技的一个充值记录类型业务的架构图：

-通过binlog采集以及DTS传输服务，增量数据消费双写到历史数据的两个HBase集群：一主一备，分布在两个城市，具备跨可用区的容灾能力。

-超出保留时间的数据会从MySQL集群中删除，这些数据保存在HBase中成为静态历史数据。

-在线库热数据的查询占比95%，历史库HBase冷数据的查询占比5%。

-为方便业务开发，统一使用HBase Proxy通过SQL访问历史数据。

-历史数据需要长期保存，不能删除；随着数据的不断增长，使用成本在快速扩张。

2）、业务痛点

-组件多，运维复杂

1.HBase组件众多，支持复杂查询等功能还需引入额外工具，运维复杂。

2.此外，HBase社区发展停滞，促使我们寻找更好的解决方案。

-不支持二级索引

3.业务需要先查询索引表，再查询主表，链路长、延迟高。

-不支持跨行事务

4.只能保证单行的原子性，主表与索引表的一致性无法保证。

-容灾依赖双写

5.跨可用区容灾依赖双写，加大了程序的复杂性，且难以保证主备HBase的数据一致性。

-使用成本

6.主备2套HBase集群，需配置5-6个副本，存储成本高昂。

7.压缩算法默认为Snappy，如使用压缩率更优的ZSTD需依赖Hadoop 3.0，存在Core Dump的概率。

面对业务使用HBase的局限性，TDStore团队主动深入分析业务痛点，最终为其提供了一套更合适的解决方案，采用TDStore替代HBase。

三、迁移后的性能和效率比较

在上述提到的充值记录业务场景中，我们已经成功地将HBase数据（使用Snappy压缩）迁移到了TDStore（使用LZ4+ZSTD压缩）。以下是迁移后性能和效率的对比分析：

1）存储成本大幅降低

结果显示，单副本（不包括索引）的压缩率达到了47%，显著降低了腾讯金融科技业务系统的数据库使用成本。

同时，由于原先需要双写主备两套HBase集群，现在只需一套TDStore实例即可满足跨AZ的高可用。在副本数上两者也有明显差异，将其纳入计算后，成本进一步降低。

2）业务访问延迟降低

迁移前，业务需要先查询HBase的索引表，再查询主表，导致链路较长，平均耗时达到150毫秒。而迁移至TDStore后，平均耗时缩短至37毫秒，执行效率显著提升。

3）业务数据规范性大幅提升

HBase作为KV数据库，其数据结构只有键和值两个元素，没有预定义的数据结构，任何可以转换为字节数组的内容都可以存储在HBase的单元格中；这就导致如果执行了错误的PUT操作，HBase会无条件保存数据，并依赖滞后的数据校验程序去发现和校正。

TDStore作为关系型数据库，使用表格形式来组织数据，每个表都有预定义的列，并且每列都有预定义的数据类型。这种结构化的数据组织方式使得数据更加规范，也避免了日常繁杂的数据校验工作。

四、总结

四、总结作为TDSQL新一代引擎，TDSQL TDStore版具有以下的特点：

1）透明分布式

兼容性：兼容原生MySQL 8.0语法，对用户业务层无入侵。

分布式：业务层无须手动分库分表，使用时无需指定分片键，单机MySQL上的业务可以无损迁移到TDStore上。

2）高性能计算+海量存储

计算层：不同于传统的M-S模式，TDStore为多主模式，每个节点均可读写；单实例可支撑千万级QPS，帮助用户应对突如其来的业务峰值压力。

存储层：采用高压缩比的分布式存储引擎，海量数据业务的性价比首选。

3）容器化云原生的弹性扩缩容

基于容器化平台的管控系统具备云原生能力，可根据业务需求弹性扩缩容，支持业务动态负载以及容量弹性伸缩。

4）原生Online DDL支持业务的频繁变化

支持在线加减列操作，支持在线加减索引，支持大部分DDL操作以原生Online方式执行。使用者在业务运行过程中有动态更改表结构的需求时，无须依赖如pt或ghost等外部工具组件。

也是因为TDStore有这些特点，历史库场景下的HBase业务非常适合迁移至TDStore。TDStore与HBase的功能相比，主要具有以下特征：

-长期数据保存：TDStore具有极易扩展性。

-提高数据质量：TDStore具有严格约束，避免问题或错误数据存入库中。从而节省修复数据的时间。

-成本敏感：TDStore具有更高的压缩比，并在满足容灾需求的情况下减少副本数量，从而大幅降低使用成本。

-统一SQL访问：上游数据来自MySQL，业务希望统一使用SQL访问两侧数据库，HBase需要加装phoenix或其他中间件来支持SQL，TDStore原生支持SQL接口，且性能更佳。

-更便捷的运维体验：TDStore自主研发，依托容器化管控平台，在日常运维和升级工作中更为便捷。

TDStore正在快速发展，其在历史库场景中替代HBase的实践仅是成本效益和性能优势的一部分。未来，我们将致力于提升产品性能和用户体验。作为腾讯云数据库长期战略的核心，TDStore将始终以业务需求为导向，专注产品打磨，为用户提供更高效、更稳定的服务。

导语

随着当今业务的高速发展，复杂多表关联的场景越来越普遍。但基于行式存储的数据库在进行复杂查询时性能相对较弱。

在复杂逻辑越来越高频的需求下，这怎么解决呢？这就促使了开发者在实现过程中将一些复杂逻辑变成了分批次的从数据库中取出数据，然后在业务中使用代码去处理的独特现象。或者使用一些数仓产品来去承载此类业务，但是这样子的做法自然就导致了业务架构复杂，逻辑臃肿等诸多问题的发生。

那么到底如何在数据库中解决这些问题呢？腾讯云数据库TDSQL-C推出了只读分析引擎功能，通过扩展的只读实例结合列式存储与计算优化的方案可轻松应对一切复杂查询场景，从容处理在业务中的慢SQL。

只读分析引擎简介

只读分析引擎是TDSQL-C MySQL版支持的全新功能，此功能基于LibraDB引擎实现，通过只读实例提供服务。其可插拔式的引擎设计可以实现灵活的创建以及销毁，同时为用户提供海量数据处理与高效实时的复杂分析能力。使用只读分析引擎，业务完全无需维护复杂的ETL组件，直接开启只读实例即可轻松享受处理复杂查询场景下的极致性能。

高速分析引擎LibraDB

不同于TDSQL-C MySQL版原生基于Innodb引擎升级改造的TXSQL引擎，LibraDB引擎是一款自研的列式存储与计算引擎。Innodb引擎能在读写实例和只读实例中选择使用，但是LibraDB引擎只能在只读实例中被选择。

LibraDB引擎支持以非常低的执行时延从海量数据中完成复杂查询分析，让您的业务分析系统可以及时高效地获取到有用的信息。LibraDB引擎支持向量化引擎、大规模并行执行等针对分析类查询的加速特性，无论是在超大表的多表JOIN、数据聚合和排序，还是复杂嵌套SQL等查询场景，LibraDB引擎都能提供出色的性能体验。更加详细关于LibraDB引擎的计算能力文章可参考：LibraDB计算引擎设计与思考（技术干货丨TDSQL列存引擎LibraDB计算模型的设计与思考）

灵活开关的分析引擎

只读分析引擎兼容MySQL协议和语法，用户无需修改业务代码，可直接将复杂的查询语句放置于只读分析引擎中执行，同时亦可根据业务的实际情况选择是否开启只读分析引擎，并且在无需分析加速的时候，可随时关闭只读分析引擎，以达到控制成本的目的。

实时列存数据加载能力

通过只读分析引擎内置的数据加载组件，可快速将TDSQL-C MySQL版中的数据加载至只读分析引擎中。同时在完成数据加载后，亦可实时同步在读写实例中对数据的所有变更，使行列数据变得实时一致。另外，针对传统列式存储在高并发数据UPDATE与DELETE的场景中数据变更低效的问题，LibraDB引擎也提供了在高并发数据更新场景下的列式存储能力，可以支撑实时的数据同步，以达到数据实时同步的效果。

指定数据加载能力

作为传统的只读实例而言，所有的主库数据均需要同步到从库中。但是对于只读分析引擎而言，可以支持指定对象加载到分析引擎中，而不是一定要求所有的对象。用户可以指定需要使用只读分析引擎加速的库表，或者有数据分析价值的库表加载到只读分析引擎中进行数据分析，灵活控制只读分析引擎所占用的磁盘大小。

超高数据压缩率

基于列式存储的结构，提供超高数据扫描性能的同时，还能够同时提供至少50%的压缩率，大幅度降低存储的成本。

完善的云上托管能力

无需运维复杂的ETL逻辑，无需关心数据库的后端运维，通过全托管的产品设计，让您获得开箱即用的数据分析能力体验。同时，通过全面监控功能，从TXSQL到分析引擎，从链路层到存储层，精心筛选出核心指标，为您去繁化简，让您能迅速通过关键指标了解实例健康情况，为业务系统的使用提供有效的优化指引。除此之外，您还可以自定义阈值告警，提前防范可能出现的异常情况。

适用场景

只读分析引擎旨在为用户提供实时的高性能数据分析，以帮助用户解决自行构建ETL工具同步数据的复杂运维难题。通过只读分析引擎的功能，用户可以轻松地一键化地构建数据分析实例，以作为业务决策的依据，充分发挥数据的价值。

报表分析、实时看板

面向企业内部分析和管理者的报表系统，可以及时、实时地查看到业务系统线上的运行情况；或者面向业务运营的数据分析业务。此类业务场景中的查询SQL复杂，且查询模式不固定，需要较高的吞吐，同时线上数据较多，使用只读分析引擎可满足业务在此类场景下的实时性与高性能。

用户画像、行为分析

在广告业务、游戏运营场景下，经常会需要针对用户行为、用户画像进行深度分析，分析后的结果用于实时的经营决策。此类场景数据量大、需要及时返回数据分析结果，查询QPS较高，使用只读分析引擎，用户可以在此类场景中快速获得需要分析的数据，用于用户行为分析，以作为精准推送相关业务的决策依据。

实时数据仓库

在电商大促订单的数据分析、物流行业的运单分析、金融行业的绩效分析、指标计算、直播质量分析、广告推送分析、智能驾驶舱、探针分析场景下亦可使用只读分析引擎以获取超高的复杂查询性能。

大数据对账、批量计算

在一些在线业务中，特别是与金钱有关的业务场景中需要定时对数据进行统计合并的对账计算，在传统的行式数据中进行数据批量计算对账效率低，资源消耗高。无法快速的达到业务预期。通过借助只读分析引擎的超强并发计算能力可以以极高效率的完成业务需求。

未来展望

只读分析引擎本期即将在云原生数据库TDSQL-C MySQL版中正式开启内测，后续只读分析引擎亦会在云数据库MySQL等MySQL系列产品中陆续上线。使用相关产品的伙伴可敬请期待。

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/sjkxydsj/21599.html