Postgres 和 MySQL 应该怎么选？
不知道业务具体情况如何，数据量如何，处在哪一种场景下。小T也是在数据库行业的，我们做的是时序数据库TDengine，主攻物联网、工业互联网等场景下海量爆发的时序数据的处理，对数据库产品还是有一定的研究的。先来讲讲我司专业人士汇总的数据库选型原则，如有不同意见敬请指教：
1、如果是事务的：
单机扛得住的，MySQL/PG 都可以选择
单机扛不住，但是好分片的，同上一条
不好分片，那可以考虑 TiDB 这种分布式事务的 HTAP
2、对于非事务，基本上就是各种 MPP 型的 OLAP：
多维分析为主，不知道自己什么已知维度的分析，就用 ClickHouse/Doris 这种通用的 OLAP
有场景特色的，就选场景通用的，例如 TDengine 做时序场景，Neo4j 做图计算
3、分布式数据库，看几点：
Sharding + Partition 策略：这一点基本上决定了性能的上下限
分布式架构：这一点影响系统的容量上限/瓶颈模块
计算函数：这一点决定好不好用，能不能减轻业务开发的工作量。不然都只有读写没计算，啥计算都自己写肯定是不合适的。
MySQL 和 PostgreSQL 这两款数据库作为 SQL 类数据库，存储结构化数据是很合适的。那如果是时序数据呢，以车联网场景为例，其 GPS 产生的时序数据量级通常都达到了亿级，高效写入、存储和快速查询是最基本的数据处理要求，但在具体实践上这却不是一件容易实现的事情。我们之前就遇到过这样一个案例：
某企业服务端接收存储 GPS 相关数据，按 1 次/30 秒的上传频率，一天的数据条数估计在 1.2 亿条，其想要实现后台的实时监控和历史轨迹查询，如何选用数据库？
我们看一下每秒的写入量：平均 10W/30 = 3333 rows/s，最大值 10W rows/s，由于车联网本身会出现“车机在一段时间内断网补传数据”、“车机上传按时钟定时”等特点，会有一定概率触发最大值写入量，甚至超过最大值。因此选用的数据库必须具备高吞吐能力，而且还得留有余力供后续扩容。用过 MySQL 的开发者都会有体验，在没调优的情况下，这种 2KB 的行写入，1k tps 基本把单个节点打满了。
另外一方面，我们一般都会建立索引，至少建立时间戳的索引用于按时间段查找数据。而当我们用 B+ 树存储索引，在单表数据量达到 2000W 行时，索引的维护会导致写入速度的下降，单从这一点看就很难运维，更不要说在建立更多索引的情况下。
再者，MySQL 的横向扩展只能靠中间件来实现，没有更好的方式了，这种分布式的横向扩展能力也为其打了个折扣。正是基于此，PostgreSQL 才会单独出了一个分支来存储时序数据。但 PostgreSQL 毕竟不是专业的，也并不能很好地实现数据处理要求。以一个真实案例为例：
此前苏州大学为保障全校系统以及网络、服务器硬件、操作系统的可用性、可靠性和安全性，打造了苏州大学智慧运维管理平台，除了要对几千台摄像头进行数据采集加在线检测，其还有 1500 多台交换机和 4000 多台服务器，在数据库的选择上，它需要在扛住如此大量设备 24 * 7 高频长期写入的同时，还要确保相当出色的查询效率。他们原本使用的就是 PostgreSQL，但当数据量达到亿级时，PostgreSQL 查询分析延迟会达到大几秒，压缩率上也不太理想，占用存储空间超过了200GB，无法撑起一个全域一体化运维监控平台的持续运行。
这个数字没有对比大家也可能产生不了太深刻的认知，下面我们就来对比看一下。在集成到TDengine之后，TDengine 存储的大概 2 亿行数据，实际占用存储空间不过 2GB，比起 PostgreSQL 占用的超过 200GB 的空间，几乎可以忽略不计；PostgreSQL 的很多查询都需要几秒返回结果，而TDengine 都是毫秒级别。
