专栏 - 我当初为什么选择了tidb抛弃了postgresql

自学24小时--我当初为什么选择了tidb抛弃了postgresql

在数据库技术的广阔天地中，每一种数据库都有其独特的优势和局限性，选择哪一种数据库往往取决于具体的业务需求和场景。在我个人的职业生涯中，曾经面临过这样的选择：在维护PostgreSQL业务的过程中，我逐渐意识到了其在某些方面的局限性，特别是在处理大规模数据和高并发场景时。经过深入的考量和评估，我最终选择了TiDB作为解决方案。以下是我做出这一选择的详细分析和理由。

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|13.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也有

总结来说，TiDB作为新一代的分布式关系型数据库，以其出色的水平扩展能力、存储计算分离架构、以及对MySQL协议和生态的兼容性，成功解决了我在维护PostgreSQL时遇到的一系列问题。特别是在处理大规模数据、高并发查询、以及数据均衡分布等方面，TiDB展现出了其独特的优势。此外，TiDB的云原生设计和不依赖网络的特性，也使其在现代云基础设施中更具灵活性和可靠性。

通过这次选择，我深刻体会到了选择合适的数据库对于业务发展的重要性。TiDB不仅满足了当前的业务需求，更为未来可能的扩展提供了坚实的基础。我相信，随着技术的不断进步和业务需求的不断演变，TiDB将继续展现出其作为现代数据库解决方案的巨大潜力。

最后，值得一提的是，TiDB的快速发展和日益壮大的社区支持，也为用户带来了更多的信心和便利。随着PingCAP等公司的进一步推动，TiDB及其相关产品和服务将更加完善，为更多企业的数字化转型提供强有力的支持。

结尾再附图，为什么用户选择慢慢的TIDB排在第一了。因为性能的确好。市场会大浪淘沙，开源软件的力量不可挡。