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