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

作者： tidb 狂热爱好者原文来源：https://tidb.net/blog/180837de

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

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

TiDB、PostgreSQL 和 MongoDB 是三种不同类型的开源数据库，它们各自具有独特的优势和劣势，适用于不同的业务场景。

1. 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 TABLESPACEpostgres=# CREATE TABLESPACE tsp02 OWNER lottu LOCATION '/data/pg6000/tsp02';CREATE TABLESPACE

查看数据库默认表空间

postgres=# \c lottu lottuYou 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 TABLElottu=> insert into tbl_lottu select generate_series(1,1000) ,md5(random()::text);INSERT 0 1000lottu=> \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 排在第一了。因为性能的确好。市场会大浪淘沙，开源软件的力量不可挡。