这是一个创建于 354 天前的主题，其中的信息可能已经有所发展或是发生改变。
接了个新项目，数据量大概上亿，业务类型主要是订单数据，插入为主，简单的查询和统计，按公司传统的方案要不就是上 mycat,或者用 Sharding-JDBC,这些在公司内部都有一定的使用量的，不过个人想看看其他方案，简单做了一下调研，有几个备选： 1.GreenPlum ，开源，支持 OLTP 和 OLAP ，分布式数据库， 2.TiDB,公司其他项目有使用，据说对磁盘有一定的要求。 3.Oceanbase ，开源 不知道各位有没有相关的建议和使用经验。
 |
1
JIAOSHOUv587 354 天前
Sharding-JDBC 投一票
|
 |
2
RangerWolf 354 天前
你们调研过 clickhouse 嘛？
|
 |
3
opengps 354 天前
数据量达到一定的级别，自然就是硬盘越快越好
|
 |
4
afeiche OP @RangerWolf clickhouse 不是分析的吗，我们就简单查询和统计，写入的时候有事务要求的
|
 |
5
KAKARTTO 354 天前
只是简单的插入和查询, mysql 妥妥够用的.
|
|
7
RangerWolf 354 天前  3
我们这是 mysql + clickhouse
用 mysql 做事务性的写入，然后同步到 clickhouse 蛮多数据的，好几张上亿条数据的表 因为统计分析比较多，mysql 完全扛不住 @afeiche |
|
8
RangerWolf 354 天前 1
我之前用过托管的 TiDB ，反正统计分析性能被 Clickhouse 甩出几条街，其他的不好说，但是都不看好。
还是看你们的需求 |
 |
9
FightPig 354 天前 1
我们用的 pg ，不过有的查询已经挺慢了
|
 |
10
haimianbihdata 354 天前 via Android
用 doris 吧。
|
 |
11
liprais 354 天前 4
你不知道用啥就 postgresql 完事
|
 |
13
adoal 354 天前
几亿的数据量，不复杂，很可能传统的单机数据库用好了就够。
|
|
14
adoal 354 天前
不复杂是说库结构不复杂
|
 |
15
nm1st 354 天前
doris 投一票
|
 |
16
Jack66 354 天前
porlardb
|
 |
17
dululu 354 天前
这种不属于业务问题的头疼问题，自然就找个啥都能干性价比有高的数据库云服务公司甩出去，比如这个： https://apecloud.cn/
|
 |
18
hemingway 354 天前
mysql 或者 postgresql 加上分库分表
postgresql 有成熟的方案 citus |
 |
19
kuituosi 354 天前 3
mycat: 太古老了，而且没人修 bug ，觉得不会出现新 bug 的话偷懒可以用
Sharding-JDBC： 万金油解决方案，开源的首选，没有比这个更好的了。有更好的都是闭源 GreenPlum：貌似偏向分析的，不太推荐 TiDB：太耗机器了，有钱人首选 Oceanbase：没有完全开源，也非常耗机器，有钱人考虑 |
 |
20
xieren58 354 天前
postgresql
|
 |
21
chengquan17 354 天前
Greenplum 没有啥并发能力，不支持 OLTP ，就是个数仓
|
 |
22
seanxx 354 天前
mycat 没问题,用过好几年,没什么大坑
|
 |
23
dobelee 354 天前 1
如果没有频繁复杂查询的话 mysql 毫无压力。
|
 |
24
ddkk1112 354 天前
写入和分析分开，放一起不是自找麻烦吗
上面 mysql+clickhouse 的方案，我现在也在用 mysql 冷热分离，clickhouse 单机 32gb 足够了 |
 |
25
sadfQED2 354 天前 via Android 3
你得说下你具体的查询逻辑啊。你也别小看 MySQL ，上亿数据算啥，我之前在头部前三的商城负责订单业务，就是 MySQL 单表存上亿数据啊
1.如果需要事物，无脑 MySQL Oracle pg 三选一 2.不需要事物，是否需要实时性？需要，ck sr doris 三选一，看你需求。不需要，走离线数仓那一套 3.c 端高 qps 查询，es |
 |
26
rekulas 354 天前
歪一个 其实 mysql 单表不建议上亿是上古时代的说法，现代硬件和数据库版本完全能支撑，我们几千万的表用起来跟普通表基本没什么区别，做好索引就行
|
|
27
afeiche OP @Jack66
@dululu 我们是国企，肯定不能上公有云，得在自己的 IDC 中部署 @haimianbihdata @nm1st doris 看了一眼，OLAP 的，应该不太符合要求 @kuituosi 总结的好 @RangerWolf @ddkk1112 @sadfQED2 感觉可以用 mysql 或者 pg ，按年或者按季度分表，然后汇总到 clickhouse 里面统计查询 |
 |
28
nothingistrue 354 天前 2
mycat 、Sharding-JDBC 这都是数据库代理/高层封装，不是原生数据库，他们的背后还是 mysql 、postgresql 。
Greenplum 初步看介绍，是大数据平台，它的背后可能是 HDFS 。 TiDB 初步看介绍，它就是 MySQL 的二开。（这货用二阶段提交来做分布式强一致性，实际使用效果真得存疑）。 Oceanbase 就是个黑盒，除了早期版本能明确是 MySQL 魔改外，现在没人知道它是什么。（实际使用起来，它就是个渣滓，你用 Mysql 模式它有 Mysql 旧版本的遗留 BUG ，你用 Oracle 模式它有 Oracle 旧版本的遗留 BUG 。） 你这备选方案，压根就不像再做技术选型。我觉得你应该先做好概要设计，或者技术方案分析之后，再来考虑数据库基础设施选型。如果遵循经验原则，如果你新项目跟旧项目没有明显出入，那么继续使用 mycat 、Sharding-JDBC 才是最优解。如果有出入，或者 mycat 、Sharding-JDBC 已经有明确记录的问题点，那么就应该先把出入点和问题点做出来，然后针对这些点再做后面的选型。 |
|
29
sadfQED2 354 天前 via Android
@afeiche 自己部署的话，你们有 flink olap 运维吗，这一套可不轻，没专业的运维别轻易选。
olap 不能单纯的当成数据库用，没大数据那一套生态，做任何东西都十分难受。而且没专业的运维调优的话，性能天差地别。 |
 |
30
Worldispow 354 天前 1
不考虑成本的话，最好上商业数据库，不为别的，只为早点下班。
|
|
31
afeiche OP @nothingistrue 按旧方案是可以，不过就是想看看其他方案，一方面是扩展一下自己的知识面，另一方面给简历加点内容，哈哈哈
@sadfQED2 这个确实得考虑运维的问题 @Worldispow 公司不太愿意买商业的，除非系统能赚大钱。 |
 |
32
daiv 354 天前
如果 kv 的话, 可以看看 https://github.com/OpenAtomFoundation/pika
|
 |
33
q11391 354 天前
mysql + doris
|
 |
34
mightybruce 354 天前 1
你们的业务是 OLTP 为主， 仅仅是数据量的话，这些方案都不需要，直接建 mysql 分区表，数据量和并发、吞吐量不是一回事。
如果是面向用户的较高并发简单点就是 Sharding-JDBC ，不过依然会存在各种不兼容要修改代码的问题，分库分表的限制也是不少的。 分布式数据库也有很多种选择， 一般分为两类，一类是 NewSQL, 另一类是 PG-XC ，NewSQL 包含 oceanbase, tidb. 可以考虑一些 PG-XC 的数据库，是在传统关系型数据库，增加了切片集群，增加了协调节点，增加了全局时钟,性能比较稳定，也比较接近分库分表。 一般有如下几个 腾讯的 TBase 华为的 GuassDB 300 |
 |
35
zhangxudong 354 天前
mysql 加分区表应该就够了
|
 |
36
brader 354 天前
查询统计 clickhouse 可以
|
 |
38
Gimorocun 354 天前
clickhouse
|
|
39
Gimorocun 354 天前
百亿级别数据没问题
|
 |
40
meeop 354 天前
上亿的话,所有数据库都可以,这并不算大数据
|
 |
41
PythonYXY 354 天前
订单数据这种核心数据就别考虑 TiDB 了。
你们现在的流量不是特别大的话 MySQL 分表足以，相关的成熟方案也很多。 统计分析就通过 binlog 导出到 hive 或者 es 就行。 还是尽量选公司内部相关基建更完善的方案。 |
 |
42
june4 354 天前
我的垃圾 vps 上的 mysql 数据就有上亿，完全没发现任何性能问题
只要索引设计好不搞全表/大范围无效扫描，几亿数据完全没问题 且现在的 nvme ，比以前的硬盘快不知道到哪里去了，别纠结以前的老套路 |
 |
43
coinbase 354 天前
postgresql + citus 千亿都没问题
|
 |
44
guo4224 354 天前
Timescale 看看？
|
 |
45
netnr 354 天前 via Android
duckdb 也可以调研一下，支持事物
|
 |
46
xmh51 354 天前
mysql 就好了 sdk 可以使用 shardingsphere 分库分表。
|
 |
47
markyangd 354 天前
数据插入进 MySQL ，然后利用 MaterializeMySQL 同步到 ClickHouse ，查询到 ClickHouse 。
|
 |
48
lujiaxing 354 天前
几个亿而已...
PostgreSQL 了解一下? |
 |
49
ychost 354 天前
才上亿，GP 肯定没问题
|
 |
50
konakona 354 天前 1
简单的数据查询用关系型数据库在这种体量的数据面前显得那么的柔弱……推荐一波 mongodb 。
|
 |
51
MonkeyJon 354 天前
postgresql
|
 |
52
cutchop 354 天前
NoSQL
|
 |
53
happy32199 354 天前 via iPhone
10 亿内 用 mysql 走索引很快的 分库分表都不要
要是多台数据库服务器 就随意了 |
 |
54
fy1993 354 天前
Doris ？
|
 |
55
lycongtou 354 天前
postgresql
|
 |
56
liuhan907 354 天前
我们公司用 TiDB 四年多，单表最多的时候 10E 。还行，运维不算复杂，TiFlash 也能胜任 OLAP ，并且不需要做 ETL 。
唯一的需要注意的点是，这个数据库对硬盘需求相对较高，不过应该说是目前分布式数据库对于硬盘需求因为存储基本都是 rocksdb 以及变种，所以要求都高。如果你们存储节点有 SSD 可选的话，我觉得带 TiFlash 的 TiDB 是个还行的选择。 毕竟 OLTP/OLAP 业务一个数据库包全，官方还提供了 TiUP 做集群自动部署和维护，以及自动备份工具。 |
|
57
liuhan907 354 天前
@nothingistrue TiDB 倒不是 mysql 二开，rust+go 写的东西，怎么可能是 mysql 这个东西的二开呢 -_-
|
 |
58
ZZ74 354 天前
@sadfQED2
不要拿大厂和中小公司比，码农的水平有差距 会导致数据库表现有很大差距。 我经历过一家小公司，MySQL 2KW 的数据查询都慢了 就开始分库分表了。 一看那表结构设计和查询语句 就呵呵呵了 |
 |
59
LeegoYih 354 天前
我们现在项目 MySQL 192g 内存，单表 2 亿数据，索引查询很快， 把数据都读到内存就完事了
|
 |
60
Itesting 354 天前
如果只是数据量的话单机 mysql 够用了，可以看下单机 mysql 能不能扛得住这个写入量，个人觉得不到 1 亿数据没必要因为数据大小来进行复杂的分库分表，配合历史数据归档走就行了。
|
|
61
RangerWolf 354 天前
@afeiche 如果你已经汇总统计好了，感觉更没必要放 clickhouse 了，一般汇总之后数据量小了很多，性能要求不是很变态的话 mysql 应该也可以了
感觉 op 可以先试试看纯 mysql ，mock 生成足量数据，看看是否能满足你们的要求。如果没法满足再多一个 clickhouse |
|
62
dululu 354 天前
@afeiche https://apecloud.cn 这个是支持 IDC 私有化部署的。
|
 |
63
ManjusakaL 354 天前
@nothingistrue 你这算不算验证你的 ID 了 nothingistrue （，TiDB 什么时候变成 MySQL 的二开了，我们这几百 T 的 TiDB 付费集群（本人也业余时间写点 TiDB 的东西），咋没发现 MySQL 的 Codebase 呢，求点内幕消息.jpg
|
 |
64
kanepan19 354 天前 1
一亿订单， 单库单表都顶得住
|
 |
65
unregister 354 天前
感觉 sharding - jdbc 就是会出问题。
|
 |
66
superchijinpeng 354 天前
StarRocks 这么点数据量 MySQL 都行
|
 |
67
lance6716 354 天前 via Android
tidb 可以在 asktug 社区寻求帮助
|
 |
68
iyaozhen 354 天前
提个我之前用过的方案，表分区。
MySQL 有个缺点就是不能自动加分区，需要停机加 |
 |
69
trio 354 天前
tidb
|
 |
70
dddys 354 天前
psql
|
 |
71
me1onsoda 354 天前
做冷热处理，MySQL pg 都行。分库分表妥妥的垃圾
|
 |
72
iseki 354 天前 via Android
单机搞定的话，PostgreSQL 。如果是大宽表低频率的分析，再考虑 ClickHouse 单机版这种事
|
 |
73
dayeye2006199 354 天前 via Android
先 scale up 再 scale out ，上来就 scale out 就是自找麻烦。
|
 |
74
securityCoding 354 天前 via Android
读少的场景一个亿数据分啥表，干就完了
|
 |
76
java123 353 天前
oracle ，简单稳定
|
 |
77
shinession 353 天前
亿级上 postgresql 或者 Oracle, 单机都行
|
|
78
coinbase 353 天前
postgresql + citus 吊打 TiDB, 吊打 clickhouse,吊打 Sharding-JDBC
|
 |
79
ShuWei 353 天前
mysql/pg 其实都可以承载的，根据具体场景做一些索引优化、分区分表之类的，再多关注一下 sql 语句的写法，问题不太大一般
|
 |
80
xshell 353 天前
PG
|
 |
81
chunworkhard 353 天前
可以存 mysql 里，来控制事务， 并将业务实时同步到 Clickhouse 中进行查询分析，Clickhouse 开发学习成本很低， 只要会 mysql 轻松应用
|
 |
82
ShinichiYao 353 天前 1
MySQL 跑了十几年了，最大的表 15 亿多数据，稳定性就一句话：操作系统崩了它都没崩
|
 |
83
avalon8 353 天前
doris
|
 |
84
miniliuke 353 天前
简单查询加插入用 PG 库，统计分析数据导到 Doris 里面分析
|
 |
85
ydpro 353 天前
现在阿里云的 RDS MySql 无法支撑单表上亿吗？
|
 |
86
huguang3320 353 天前
@ydpro 我们原单位用的就是阿里云的 RDS ，DRDS 还有 ADS ，还挺好用的
|
 |
87
15342 353 天前
@RangerWolf 你们怎么保证 2 边数据一致的？
|
|
88
nothingistrue 353 天前
@liuhan907 #57
@ManjusakaL #63 https://zh.wikipedia.org/wiki/TiDB 本来二开也没啥丢脸的，你们非要让他往 阿里云 OS 、鸿蒙这一类上面靠。 |
 |
89
QlanQ 353 天前
上亿数据用 MySQL 一点问题都不会有
|
 |
90
bruce0 353 天前
看是否有 ACID 的事务要求, 如果没有, 并且数据可以支持 KV 类型的话, 感觉 基于 rocksdb 开发的很多数据库挺合适的, rocksdb 天生 对于写入友好. 推荐一下 pika, 今年社区发展挺快的, 而且有大公司在用,(360, 微博, 喜马拉雅等) 稳定性相对有保证. 支持集群部署, 几个亿的数据完全不在话下, 现在支持内置内存级别的缓存了, 读性能有了很大的提高, 可以看一下
https://github.com/OpenAtomFoundation/pika @daiv 老哥 pika 群友吗 |
 |
91
luobingit 353 天前
经历过 20 多亿数据用 MySQL 复杂查询用的 ES 没啥压力 就是要注意一下内存
|
|
92
luobingit 353 天前
TiDB 当时技术选型也讨论过 确实很吃资源 而已有些地方跟 MySQL 有冲突 具体看官网文档 后面我们在测试环境试过后 没上生产 生产还是 MySQL 你们场景跟我们当时情况很像 应该没有我们数据多 MySQL 能撑住 再整个读写分离
|
 |
93
Desdemor 353 天前
我们是七楼的方案，同步的时候是批量插入的，ck 好好搞一下，巨快无比的
|
 |
94
dynastysea 353 天前
@afeiche #27 polardb 支持 idc 部署的，可以找阿里云的谈
|
 |
95
jowan 353 天前
我们 MySQL 单表 15 亿 轻轻松松
因为还有复杂的查询 现在改成垂直分表了 |
 |
96
lbunderway 353 天前
mysql 就个主从都没问题，表要分好 我们之前几亿数据量都没什么问题
|
 |
97
huangzhe8263 353 天前 1
@nothingistrue #88
作为看过 MySQL 和 TiDB 代码的来说，TiDB 只是兼容 MySQL 协议，分布式是基于 Google 的 Planner 思想 + Raft 协议去做的，基本可以认为是从头写起的 你要说 PolarDB / TDSQL 那些是二开还差不多 |
 |
100
bthulu 353 天前
才上亿数据, mysql 分区表+主从轻松搞定.
单表一万亿以上, 你再考虑其他方案. |
Select Language