TiDB VS MySQL
作者: Ann_ann 原文来源:https://tidb.net/blog/6035684e
理想型的数据库应该具备的特点
- 强一致性和高可用;
- 高吞吐、高并发、低延迟;
- 标准SQL、支持 ACID 事务;
- 大数据生态友好;
- 有水平扩张能力,并且尽量做到不侵入业务;
数据库架构选型
TiDB与MySQL对比
TiDB 和 MySQL 兼容策略
可参考:https://docs.pingcap.com/zh/tidb/stable/mysql-compatibility
截至 4.0 版本,TiDB 与 MySQL 的区别总结:
对于海量数据及大表的解决方案
- MySQL需要分库分表,业务研发和 DBA 一起配合且略显低效地解决此问题;
- TiDB单表几乎可以理解为无限大的(业界已经存在 100 亿以上的表)。
数据库集群高可用
- MySQL需手动调研部署高可用集群,且不同高可用方案有不同的维护方式;
- TiDB自带高可用架构,自动容灾。
MySQL分库分表 VS TiDB
总结
TiDB 设计的目标就是针对 MySQL 单台容量限制而被迫做的分库分表的场景,或者需要强一致性和完整分布式事务的场景。TiDB的优势是通过尽量下推到存储节点进行并行计算。对于小表(比如千万级以下),不适合 TiDB,因为数据量少,Region 有限,发挥不了并行的优势。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
TIDB监控升级解决panic的漫漫探索之路
原文来源:https://tidb.net/blog/7747fec7 故事背景 上周同事收到tidb生产集群告警,node_exporter组件发生了重启,与同事交流了一下相关历史告警,发现node_exporter组件总是时不时的重启,并触发告警,并且整个集群各个节点都有发生过这个现象。 这里先简单介绍下node_exporter组件相关背景以及它的作用:TiDB 使用开源时序数据库Prometheus作为监控和性能指标信息存储方案,而node_exporter是Prometheus的指标数据收集组件。它负责从目标Jobs收集数据,并把收集到的数据转换为Prometheus支持的时序数据格式。所以在部署集群时,通常会在集群的每个节点都分发并运行node_exporter组件。 经过我们对重启现象的排查确认,认为是node_exporter组件会偶发性的出现panic,导致节点重启,经过与PingCap原厂的工程师反馈这个问题后,建议我们尝试将node_exporter组件的版本进行升级。 我们在本地镜像源里面检查了一下node_exporter组件的版本,发现当前版本是v0.17....
- 下一篇
你踩过这些坑吗?谨慎在时间类型列上创建索引
作者: Zeratulll 原文来源:https://tidb.net/blog/9468d259 MySQL中,一般情况下我们不需要关注有序数据的写入在Innodb的Btree上是否存在热点,因为它能承担的吞吐量是比较大的,在单机的范畴内不太容易达到瓶颈。 但是在TiDB中,写入有序数据很容易导致热点,这个热点与单机数据库不同。如果一个节点成为了热点(只有它在工作,或者所有请求都需要访问它),那整个集群无论增加多少台机器,都对提升数据库的性能容量毫无帮助,纯纯的浪费钱了。这是分布式相对单机额外产生的问题。 一个表包含时间字段(例如订单表、日志表、用户表等等),并且在时间字段上创建一个索引是我们使用MySQL时一种很常见的做法。这些时间字段很多会使用插入或者修改的时间(例如DEFAULT值设为CURRENT_TIMESTAMP或者SQL中使用NOW函数来作为值)。 时间是一种典型的有序数据,那么在使用TiDB时,我们是否可以保持像在MySQL中一样的做法来使用时间字段呢?时间字段是否会产生热点,又该如何避免? 本文将从TiDB的原理来解答上述问题。如果你是内核开发者,也有助于帮助读者进...
相关文章
文章评论
共有0条评论来说两句吧...