数据量较大，数据库选型问题

订单数据这种核心数据就别考虑 TiDB 了。

你们现在的流量不是特别大的话 MySQL 分表足以，相关的成熟方案也很多。

统计分析就通过 binlog 导出到 hive 或者 es 就行。

还是尽量选公司内部相关基建更完善的方案。

我的垃圾 vps 上的 mysql 数据就有上亿，完全没发现任何性能问题
只要索引设计好不搞全表/大范围无效扫描，几亿数据完全没问题
且现在的 nvme ，比以前的硬盘快不知道到哪里去了，别纠结以前的老套路

postgresql + citus 千亿都没问题

Timescale 看看？

duckdb 也可以调研一下，支持事物

mysql 就好了 sdk 可以使用 shardingsphere 分库分表。

数据插入进 MySQL ，然后利用 MaterializeMySQL 同步到 ClickHouse ，查询到 ClickHouse 。

几个亿而已...

PostgreSQL 了解一下?

才上亿，GP 肯定没问题

简单的数据查询用关系型数据库在这种体量的数据面前显得那么的柔弱……推荐一波 mongodb 。

postgresql

NoSQL

10 亿内 用 mysql 走索引很快的 分库分表都不要
要是多台数据库服务器 就随意了

Doris ？

postgresql

我们公司用 TiDB 四年多，单表最多的时候 10E 。还行，运维不算复杂，TiFlash 也能胜任 OLAP ，并且不需要做 ETL 。
唯一的需要注意的点是，这个数据库对硬盘需求相对较高，不过应该说是目前分布式数据库对于硬盘需求因为存储基本都是 rocksdb 以及变种，所以要求都高。如果你们存储节点有 SSD 可选的话，我觉得带 TiFlash 的 TiDB 是个还行的选择。
毕竟 OLTP/OLAP 业务一个数据库包全，官方还提供了 TiUP 做集群自动部署和维护，以及自动备份工具。

@nothingistrue TiDB 倒不是 mysql 二开，rust+go 写的东西，怎么可能是 mysql 这个东西的二开呢 -_-

@sadfQED2
不要拿大厂和中小公司比，码农的水平有差距 会导致数据库表现有很大差距。
我经历过一家小公司，MySQL 2KW 的数据查询都慢了 就开始分库分表了。 一看那表结构设计和查询语句 就呵呵呵了

我们现在项目 MySQL 192g 内存，单表 2 亿数据，索引查询很快， 把数据都读到内存就完事了

如果只是数据量的话单机 mysql 够用了，可以看下单机 mysql 能不能扛得住这个写入量，个人觉得不到 1 亿数据没必要因为数据大小来进行复杂的分库分表，配合历史数据归档走就行了。