【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
同样是利用分布式协议保证数据的一致性，
tidb的写入流程相对MySQL的MGR有哪些优势
区别很大哦，本质上mgr还是主备的数据库，只是做到了高可用，tidb是分布式数据库，随着集群规模的增大写入支持并发越高
tidb是region复制 mgr是回放
tidb自动将数据分片并均匀分布到多个节点上，从而实现高并发写入。mgr建议使用单主模式，这种模式只在主节点写入数据
在实现一致性上，MGR用的Paxos，好像TiDB有讲过为什么没有选择Paxos
话说mgr是不是也能多主读写？
mysql是传统数据库，肯定不会有tidb性能好的。
tidb分布式协议作用于region，真正操作的还是leader，不会直接操作follower，mgr的分布式协议作用于事务需要冲突检测，在写入的时候肯定要慢一些。
优势很大，tidb是为了分布式而产生的。
你看这篇文。mysql的架构和postgresql是一样的。优缺点一样
TiDB、PostgreSQL和MongoDB是三种不同类型的开源数据库，它们各自具有独特的优势和劣势，适用于不同的业务场景。
- TiDB 是一个分布式关系型数据库，它支持在线事务处理与在线分析处理（HTAP），具备以下特点：
-
强一致性和高可用性，采用多副本存储和Raft协议保证数据一致性。
-
存储计算分离架构，允许按需对计算和存储分别进行在线扩容或缩容。
-
兼容MySQL协议和生态，易于从MySQL迁移。
-
云原生设计，支持自动化部署。
-
适用于金融行业、海量数据OLTP场景、实时HTAP场景等。
-
PostgreSQL 是一个功能丰富的开源关系型数据库，具有以下优势：
-
强大的数据完整性保证，支持ACID事务。
-
支持多种数据类型和表继承、分区等高级功能。
-
拥有庞大的社区支持和丰富的文档资源。
-
MongoDB 是一个基于分布式文件存储的文档数据库，属于NoSQL数据库，具有以下特点：
-
面向集合和模式自由，存储数据非常方便。
-
分布式文件系统，支持水平扩展和分片集群。
-
高可用性，提供自动故障转移。
-
支持二进制数据和大型对象，具有强大的索引支持。
在选择数据库时，应考虑以下因素：
- 业务需求：例如，如果业务需要处理大量实时交易数据，TiDB的高并发写入和实时HTAP能力可能更合适。
- 技术栈兼容性：对于已在使用MySQL的技术栈，TiDB的强MySQL兼容性可以减少迁移的工作量。
- 数据模型：对于需要复杂查询和事务处理的关系型数据，PostgreSQL或TiDB可能是更好的选择。而对于模式自由的文档数据，MongoDB可能更加合适。
- 扩展性：TiDB的分布式架构提供了良好的水平扩展能力，适合需要处理海量数据的场景。
- 社区和支持：PostgreSQL拥有庞大的社区和文档资源，而TiDB和MongoDB也各自拥有活跃的社区和第三方支持。
最终的选择应基于对这些因素的综合考量，以及对特定业务场景的技术需求和未来扩展的预期。
说一下我自身的选择。我曾经有段时间和阿里巴巴一起出来的唐成，唐总一起维护postgresql的业务。
我们当时在公司。postgresql在公司里面负责数据分析业务。当时在去oracle。整体数据量有40t-100t的数据。
而postgresql又没有oracle那样的extdata一体机。用起来就很麻烦。
整个浙江省分成11个城市。杭州、湖州、嘉兴、绍兴、宁波、舟山、衢州、金华、台州、丽水、温州。在pg里面对应就是11个postgresql单机数据库。部署在单台服务器上。因为数据库需要高可用。就杭州为湖州的备份，湖州为杭州的备份。还有一个总库浙江
这就遇到了第一个问题。
分库不均衡
。杭州的数据是其他10个省的数据加起来总和都多。数据百分百倾斜。杭州这台服务器经常cpu100%。如果用tidb不会有这种情况。
传统数据库无法做到存储分离
杭州的超大规模又遇到第二个情况。杭州整个库需要20t的磁盘。单机无法挂载这么多磁盘.我们用pg的表空间挂载了20多块远程ceph磁盘。用hash分片的方式每个礼拜对数据做重新均衡。远程磁盘解决了单机磁盘容量过小的问题
我们先打造下环境；创建两个表空间
postgres=# CREATE TABLESPACE tsp01 OWNER lottu LOCATION '/data/pg6000/tsp01';
CREATE TABLESPACE
postgres=# CREATE TABLESPACE tsp02 OWNER lottu LOCATION '/data/pg6000/tsp02';
CREATE TABLESPACE
查看数据库默认表空间
postgres=# \c lottu lottu
You are now connected to database "lottu" as user "lottu".
lottu=> select d.datname,p.spcname from pg_database d, pg_tablespace p where d.datname='lottu' and p.oid = d.dattablespace;
datname | spcname
---------+------------
lottu | pg_default
(1 row)
接下来我们在表空间tsp01建表tbl_lottu
lottu=> create table tbl_lottu(id int primary key, info text) TABLESPACE tsp01;
CREATE TABLE
lottu=> insert into tbl_lottu select generate_series(1,1000) ,md5(random()::text);
INSERT 0 1000
lottu=> \d tbl_lottu
Table "lottu.tbl_lottu"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
id | integer | | not null |
info | text | | |
Indexes:
"tbl_lottu_pkey" PRIMARY KEY, btree (id)
Tablespace: "tsp01"
而表tbl_lottu数据文件的位置
lottu=> select pg_relation_filepath('tbl_lottu');
pg_relation_filepath
---------------------------------------------
pg_tblspc/90618/PG_12_201909212/24750/90620
(1 row)
3|1 3.1、alter table
将表从一个表空间移到另一个表空间
lottu=> ALTER TABLE tbl_lottu SET TABLESPACE tsp02;
ALTER TABLE
我们再查看表；已经成功移动表空间tsp02
lottu=> \d tbl_lottu
Table "lottu.tbl_lottu"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
id | integer | | not null |
info | text | | |
Indexes:
"tbl_lottu_pkey" PRIMARY KEY, btree (id)
Tablespace: "tsp02"
lottu=> select pg_relation_filepath('tbl_lottu');
pg_relation_filepath
---------------------------------------------
pg_tblspc/90619/PG_12_201909212/24750/90629
(1 row)
不足之处：在alter table这个过程中是锁表的；若是大表；执行时间久，在这个时间内表在dml操作一直处在等待。那有没有不锁表，或者锁表的时间极短的方法呢？
传统数据库无法做到计算均衡
电力营业厅查询电费的时候每周一经常遇到业务卡死的问题。
为什么因为计算无法均匀分布。全集中在第一台服务器
传统数据库无法做到不依赖网络
因为需要速度快，整个业务上了100t ssd磁盘。ceph三副本 几十台物理机器。放在电力自己的机房内。磁盘容量解决了但又遇到第三个问题磁盘带宽。
受限于硬件条件 只有100g 导致杭州库上监控到的最大带宽只有8g多。由于是网络磁盘，磁盘性能差，导致了查询盘，营业厅查不出数据。
总库浙江经常查不出数据
因为架构决定了性能，最大的杭州库已经查不出数据了。浙江库就更查不出数据了。postgresql天生有各种问题，又没有oracle extdata这种软硬件一体机的措施，所以11台物理机比不过oracle一台机器
而tidb属于第四代数据库。不存在postgresql的这种问题
同样是数据分片。因为tidb的数据是均衡的。查询杭州库的时候11台服务器同时受力，一起抗压力，查询速度快
分库均衡
tidb存储分离
tidb做到了存储分离，计算不够加计算，存储不够加存储。而且存储机器参与计算，性能翻倍。不像postgresql+ceph架构。ceph的cpu完全无法参与计算。
计算均衡
tidb的所有节点都参与计算
tidb不依赖网络
tidb总共11台机器 他就用1100g带宽是pg的11倍
tidb有专门应对统计的数据库
pg的tp数据库只做ap计算。存在各种性能瓶颈。因为现有的pg无法做tp业务。数据还是先落入oracle再落入postgresql 最后倒入到hadoop。需要无数数据库去完成不同的事情。比如数据异常监控。盗窃电力用户的发现。电费汇总，电费计算。用户数据分析。
而tidb一个架构能复用做到了完全替代oracle
题外话为啥oracle一体机那么牛逼
oracle extdata是一体机柜。软硬件结合的形式他完成了单机数据库的性能极限。
https://cn.pingcap.com/joint-solution/distributed-database-aio-based-on-tidb-and-kuntai/
tidb也有
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。