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

几亿的数据量，不复杂，很可能传统的单机数据库用好了就够。

不复杂是说库结构不复杂

doris 投一票

porlardb

这种不属于业务问题的头疼问题，自然就找个啥都能干性价比有高的数据库云服务公司甩出去，比如这个： https://apecloud.cn/

mysql 或者 postgresql 加上分库分表
postgresql 有成熟的方案 citus

mycat: 太古老了，而且没人修 bug ，觉得不会出现新 bug 的话偷懒可以用
Sharding-JDBC： 万金油解决方案，开源的首选，没有比这个更好的了。有更好的都是闭源
GreenPlum：貌似偏向分析的，不太推荐
TiDB：太耗机器了，有钱人首选
Oceanbase：没有完全开源，也非常耗机器，有钱人考虑

postgresql

Greenplum 没有啥并发能力，不支持 OLTP ，就是个数仓

mycat 没问题,用过好几年,没什么大坑

如果没有频繁复杂查询的话 mysql 毫无压力。

写入和分析分开，放一起不是自找麻烦吗
上面 mysql+clickhouse 的方案，我现在也在用
mysql 冷热分离，clickhouse 单机 32gb 足够了

你得说下你具体的查询逻辑啊。你也别小看 MySQL ，上亿数据算啥，我之前在头部前三的商城负责订单业务，就是 MySQL 单表存上亿数据啊

1.如果需要事物，无脑 MySQL Oracle pg 三选一
2.不需要事物，是否需要实时性？需要，ck sr doris 三选一，看你需求。不需要，走离线数仓那一套
3.c 端高 qps 查询，es

歪一个 其实 mysql 单表不建议上亿是上古时代的说法，现代硬件和数据库版本完全能支撑，我们几千万的表用起来跟普通表基本没什么区别，做好索引就行

@Jack66
@dululu 我们是国企，肯定不能上公有云，得在自己的 IDC 中部署

@haimianbihdata
@nm1st doris 看了一眼，OLAP 的，应该不太符合要求


@kuituosi 总结的好
@RangerWolf
@ddkk1112
@sadfQED2 感觉可以用 mysql 或者 pg ，按年或者按季度分表，然后汇总到 clickhouse 里面统计查询

mycat 、Sharding-JDBC 这都是数据库代理/高层封装，不是原生数据库，他们的背后还是 mysql 、postgresql 。
Greenplum 初步看介绍，是大数据平台，它的背后可能是 HDFS 。
TiDB 初步看介绍，它就是 MySQL 的二开。（这货用二阶段提交来做分布式强一致性，实际使用效果真得存疑）。
Oceanbase 就是个黑盒，除了早期版本能明确是 MySQL 魔改外，现在没人知道它是什么。（实际使用起来，它就是个渣滓，你用 Mysql 模式它有 Mysql 旧版本的遗留 BUG ，你用 Oracle 模式它有 Oracle 旧版本的遗留 BUG 。）

你这备选方案，压根就不像再做技术选型。我觉得你应该先做好概要设计，或者技术方案分析之后，再来考虑数据库基础设施选型。如果遵循经验原则，如果你新项目跟旧项目没有明显出入，那么继续使用 mycat 、Sharding-JDBC 才是最优解。如果有出入，或者 mycat 、Sharding-JDBC 已经有明确记录的问题点，那么就应该先把出入点和问题点做出来，然后针对这些点再做后面的选型。

@afeiche 自己部署的话，你们有 flink olap 运维吗，这一套可不轻，没专业的运维别轻易选。

olap 不能单纯的当成数据库用，没大数据那一套生态，做任何东西都十分难受。而且没专业的运维调优的话，性能天差地别。

不考虑成本的话，最好上商业数据库，不为别的，只为早点下班。

@nothingistrue 按旧方案是可以，不过就是想看看其他方案，一方面是扩展一下自己的知识面，另一方面给简历加点内容，哈哈哈

@sadfQED2 这个确实得考虑运维的问题


@Worldispow 公司不太愿意买商业的，除非系统能赚大钱。

如果 kv 的话, 可以看看 https://github.com/OpenAtomFoundation/pika

mysql + doris

你们的业务是 OLTP 为主， 仅仅是数据量的话，这些方案都不需要，直接建 mysql 分区表，数据量和并发、吞吐量不是一回事。
如果是面向用户的较高并发简单点就是 Sharding-JDBC ，不过依然会存在各种不兼容要修改代码的问题，分库分表的限制也是不少的。
分布式数据库也有很多种选择， 一般分为两类，一类是 NewSQL, 另一类是 PG-XC ，NewSQL 包含 oceanbase, tidb.

可以考虑一些 PG-XC 的数据库，是在传统关系型数据库，增加了切片集群，增加了协调节点，增加了全局时钟,性能比较稳定，也比较接近分库分表。
一般有如下几个
腾讯的 TBase
华为的 GuassDB 300

mysql 加分区表应该就够了

查询统计 clickhouse 可以

@afeiche postgresql 单表 10 亿，没啥毛病

clickhouse

百亿级别数据没问题

上亿的话,所有数据库都可以,这并不算大数据

订单数据这种核心数据就别考虑 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

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

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

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

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

@afeiche 如果你已经汇总统计好了，感觉更没必要放 clickhouse 了，一般汇总之后数据量小了很多，性能要求不是很变态的话 mysql 应该也可以了

感觉 op 可以先试试看纯 mysql ，mock 生成足量数据，看看是否能满足你们的要求。如果没法满足再多一个 clickhouse

@afeiche https://apecloud.cn 这个是支持 IDC 私有化部署的。

@nothingistrue 你这算不算验证你的 ID 了 nothingistrue （，TiDB 什么时候变成 MySQL 的二开了，我们这几百 T 的 TiDB 付费集群（本人也业余时间写点 TiDB 的东西），咋没发现 MySQL 的 Codebase 呢，求点内幕消息.jpg

一亿订单， 单库单表都顶得住

感觉 sharding - jdbc 就是会出问题。

StarRocks 这么点数据量 MySQL 都行

tidb 可以在 asktug 社区寻求帮助

提个我之前用过的方案，表分区。
MySQL 有个缺点就是不能自动加分区，需要停机加

tidb

psql

做冷热处理，MySQL pg 都行。分库分表妥妥的垃圾

单机搞定的话，PostgreSQL 。如果是大宽表低频率的分析，再考虑 ClickHouse 单机版这种事

先 scale up 再 scale out ，上来就 scale out 就是自找麻烦。

读少的场景一个亿数据分啥表，干就完了

@afeiche 加好索引，简单查询是没什么问题

oracle ，简单稳定

亿级上 postgresql 或者 Oracle, 单机都行

postgresql + citus 吊打 TiDB, 吊打 clickhouse,吊打 Sharding-JDBC

mysql/pg 其实都可以承载的，根据具体场景做一些索引优化、分区分表之类的，再多关注一下 sql 语句的写法，问题不太大一般

PG

可以存 mysql 里，来控制事务， 并将业务实时同步到 Clickhouse 中进行查询分析，Clickhouse 开发学习成本很低， 只要会 mysql 轻松应用

MySQL 跑了十几年了，最大的表 15 亿多数据，稳定性就一句话：操作系统崩了它都没崩

doris

简单查询加插入用 PG 库，统计分析数据导到 Doris 里面分析

现在阿里云的 RDS MySql 无法支撑单表上亿吗？

@ydpro 我们原单位用的就是阿里云的 RDS ，DRDS 还有 ADS ，还挺好用的

@RangerWolf 你们怎么保证 2 边数据一致的？

@liuhan907 #57
@ManjusakaL #63

https://zh.wikipedia.org/wiki/TiDB

本来二开也没啥丢脸的，你们非要让他往 阿里云 OS 、鸿蒙这一类上面靠。

上亿数据用 MySQL 一点问题都不会有

看是否有 ACID 的事务要求, 如果没有, 并且数据可以支持 KV 类型的话, 感觉 基于 rocksdb 开发的很多数据库挺合适的, rocksdb 天生 对于写入友好. 推荐一下 pika, 今年社区发展挺快的, 而且有大公司在用,(360, 微博, 喜马拉雅等) 稳定性相对有保证. 支持集群部署, 几个亿的数据完全不在话下, 现在支持内置内存级别的缓存了, 读性能有了很大的提高, 可以看一下

https://github.com/OpenAtomFoundation/pika

@daiv 老哥 pika 群友吗

经历过 20 多亿数据用 MySQL 复杂查询用的 ES 没啥压力 就是要注意一下内存

TiDB 当时技术选型也讨论过 确实很吃资源 而已有些地方跟 MySQL 有冲突 具体看官网文档 后面我们在测试环境试过后 没上生产 生产还是 MySQL 你们场景跟我们当时情况很像 应该没有我们数据多 MySQL 能撑住 再整个读写分离

我们是七楼的方案，同步的时候是批量插入的，ck 好好搞一下，巨快无比的

@afeiche #27 polardb 支持 idc 部署的，可以找阿里云的谈

我们 MySQL 单表 15 亿 轻轻松松
因为还有复杂的查询 现在改成垂直分表了

mysql 就个主从都没问题，表要分好 我们之前几亿数据量都没什么问题

@nothingistrue #88

作为看过 MySQL 和 TiDB 代码的来说，TiDB 只是兼容 MySQL 协议，分布式是基于 Google 的 Planner 思想 + Raft 协议去做的，基本可以认为是从头写起的

你要说 PolarDB / TDSQL 那些是二开还差不多

@afeiche #6 额,我们一般单表 1 亿挺正常的. 就算归档保留半年都有 5 亿左右数据

@luobingit #91 这么多数据, 运行 MySQL 的机器资源要多少

才上亿数据, mysql 分区表+主从轻松搞定.
单表一万亿以上, 你再考虑其他方案.