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

2024-01-11 16:11:06 +08:00
 afeiche

接了个新项目,数据量大概上亿,业务类型主要是订单数据,插入为主,简单的查询和统计,按公司传统的方案要不就是上 mycat,或者用 Sharding-JDBC,这些在公司内部都有一定的使用量的,不过个人想看看其他方案,简单做了一下调研,有几个备选: 1.GreenPlum ,开源,支持 OLTP 和 OLAP ,分布式数据库, 2.TiDB,公司其他项目有使用,据说对磁盘有一定的要求。 3.Oceanbase ,开源 不知道各位有没有相关的建议和使用经验。

17800 次点击
所在节点    数据库
146 条回复
chengquan17
2024-01-11 16:35:55 +08:00
Greenplum 没有啥并发能力,不支持 OLTP ,就是个数仓
seanxx
2024-01-11 16:46:03 +08:00
mycat 没问题,用过好几年,没什么大坑
dobelee
2024-01-11 16:49:31 +08:00
如果没有频繁复杂查询的话 mysql 毫无压力。
G64q9J89mN5KSgmE
2024-01-11 16:50:48 +08:00
写入和分析分开,放一起不是自找麻烦吗
上面 mysql+clickhouse 的方案,我现在也在用
mysql 冷热分离,clickhouse 单机 32gb 足够了
sadfQED2
2024-01-11 16:56:43 +08:00
你得说下你具体的查询逻辑啊。你也别小看 MySQL ,上亿数据算啥,我之前在头部前三的商城负责订单业务,就是 MySQL 单表存上亿数据啊

1.如果需要事物,无脑 MySQL Oracle pg 三选一
2.不需要事物,是否需要实时性?需要,ck sr doris 三选一,看你需求。不需要,走离线数仓那一套
3.c 端高 qps 查询,es
rekulas
2024-01-11 17:00:34 +08:00
歪一个 其实 mysql 单表不建议上亿是上古时代的说法,现代硬件和数据库版本完全能支撑,我们几千万的表用起来跟普通表基本没什么区别,做好索引就行
afeiche
2024-01-11 17:06:37 +08:00
@Jack66
@dululu 我们是国企,肯定不能上公有云,得在自己的 IDC 中部署

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


@kuituosi 总结的好
@RangerWolf
@ddkk1112
@sadfQED2 感觉可以用 mysql 或者 pg ,按年或者按季度分表,然后汇总到 clickhouse 里面统计查询
nothingistrue
2024-01-11 17:16:13 +08:00
mycat 、Sharding-JDBC 这都是数据库代理/高层封装,不是原生数据库,他们的背后还是 mysql 、postgresql 。
Greenplum 初步看介绍,是大数据平台,它的背后可能是 HDFS 。
TiDB 初步看介绍,它就是 MySQL 的二开。(这货用二阶段提交来做分布式强一致性,实际使用效果真得存疑)。
Oceanbase 就是个黑盒,除了早期版本能明确是 MySQL 魔改外,现在没人知道它是什么。(实际使用起来,它就是个渣滓,你用 Mysql 模式它有 Mysql 旧版本的遗留 BUG ,你用 Oracle 模式它有 Oracle 旧版本的遗留 BUG 。)

你这备选方案,压根就不像再做技术选型。我觉得你应该先做好概要设计,或者技术方案分析之后,再来考虑数据库基础设施选型。如果遵循经验原则,如果你新项目跟旧项目没有明显出入,那么继续使用 mycat 、Sharding-JDBC 才是最优解。如果有出入,或者 mycat 、Sharding-JDBC 已经有明确记录的问题点,那么就应该先把出入点和问题点做出来,然后针对这些点再做后面的选型。
sadfQED2
2024-01-11 17:18:19 +08:00
@afeiche 自己部署的话,你们有 flink olap 运维吗,这一套可不轻,没专业的运维别轻易选。

olap 不能单纯的当成数据库用,没大数据那一套生态,做任何东西都十分难受。而且没专业的运维调优的话,性能天差地别。
Worldispow
2024-01-11 17:19:35 +08:00
不考虑成本的话,最好上商业数据库,不为别的,只为早点下班。
afeiche
2024-01-11 17:26:37 +08:00
@nothingistrue 按旧方案是可以,不过就是想看看其他方案,一方面是扩展一下自己的知识面,另一方面给简历加点内容,哈哈哈

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


@Worldispow 公司不太愿意买商业的,除非系统能赚大钱。
daiv
2024-01-11 17:29:42 +08:00
如果 kv 的话, 可以看看 https://github.com/OpenAtomFoundation/pika
q11391
2024-01-11 17:30:58 +08:00
mysql + doris
mightybruce
2024-01-11 17:35:38 +08:00
你们的业务是 OLTP 为主, 仅仅是数据量的话,这些方案都不需要,直接建 mysql 分区表,数据量和并发、吞吐量不是一回事。
如果是面向用户的较高并发简单点就是 Sharding-JDBC ,不过依然会存在各种不兼容要修改代码的问题,分库分表的限制也是不少的。
分布式数据库也有很多种选择, 一般分为两类,一类是 NewSQL, 另一类是 PG-XC ,NewSQL 包含 oceanbase, tidb.

可以考虑一些 PG-XC 的数据库,是在传统关系型数据库,增加了切片集群,增加了协调节点,增加了全局时钟,性能比较稳定,也比较接近分库分表。
一般有如下几个
腾讯的 TBase
华为的 GuassDB 300
zhangxudong
2024-01-11 17:44:37 +08:00
mysql 加分区表应该就够了
brader
2024-01-11 18:00:26 +08:00
查询统计 clickhouse 可以
kingmo888
2024-01-11 18:04:56 +08:00
@afeiche postgresql 单表 10 亿,没啥毛病
Gimorocun
2024-01-11 18:19:52 +08:00
clickhouse
Gimorocun
2024-01-11 18:21:41 +08:00
百亿级别数据没问题
meeop
2024-01-11 18:25:43 +08:00
上亿的话,所有数据库都可以,这并不算大数据

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1007852

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX