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

[afeiche]

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

[test817]

clickhouse 一票，不过 doris 好像更好..但是没用过

[gejigeji]

为啥不分表或分区？

[tyler1128]

投 PG 一票 单表一亿 索引做好 问题不大 实在不行做个分区表
硬盘的话使用 ssd 内存给大点 性能还是很不错的 不是以前机械硬盘的时代了

[RangerWolf]

@15342 只能做到最终一致性，不过延时一般不是很大。
就是自己写个脚本，把数据从 MySQL 导入 Clickhouse 里面，也不是很难写

[BQsummer]

v 站数据库水平...

[luobingit]

@weijancc 单表 20G 左右

[noparking188]

@nothingistrue #28 https://github.com/pingcap/tidb#architecture

[nothingistrue]

@huangzhe8263 #96
@noparking188 #107
你要真是程序员，不应该不懂「 Mysql 兼容」是什么意思。

[liuhan907]

@nothingistrue
我想问一下，MySQL 是个 C++ 开发的数据库，那请问 TiDB 在什么地方有 C++ 代码呢？
你不会想说 TiFlash 吧？

[huangzhe8263]

@nothingistrue 你自己去看看两边的代码，都是完全开源的，懒得说了

[ManjusakaL]

@nothingistrue TiDB 也只是做了 MYSQL 大部分协议兼容，但是有很多 MySQL 东西因为无法引用 MySQL 的 codebase （ License 问题），导致也没法做到 100%兼容 https://docs.pingcap.com/zh/tidb/stable/mysql-compatibility

而且你自己给的 wiki 你自己都不会看的吗？页面里的原文

> 对于应用程序来说，TiDB 的行为就如同一个 MySQL 5.7 服务器。用户可以继续使用所有现有的 MySQL 客户端库。因为 TiDB 的 SQL 处理层是从头开始构建的，而不是一个 MySQL 分支，所以它的兼容性不是 100%，[9]而且 MySQL 和 TiDB 之间存在已知的行为差异

[ManjusakaL]

@nothingistrue

> 你要真是程序员，不应该不懂「 Mysql 兼容」是什么意思。

https://github.com/pingcap/tidb/tree/master/pkg/parser

https://github.com/pingcap/tidb/tree/master/pkg/planner

https://github.com/pingcap/tidb/tree/master/pkg/expression

要是是程序员，大家直接点，直接拿着代码出来指出来哪些是引用 MySQL codebase 就行了。反正根据我们数百 T 数据规模的集群用了几年下来以及我自己做 TiDB 的一些经验（非 PingCAP 的人），Parser ，Planner ，Analyzer ，Storage ，TiDB 和 MySQL 都是完全不一样的路线

你要真是程序员，就别搞莫须有了

[KJR5OR04CnCiWf02]

@afeiche 啥项目，我带学生一起做过，一起搞一搞啊！ dnggY2hlbnhvZmhpdA== （ base64 ）

[keshawnvan]

建议试试 PolarDB ，亿级数据的 OLTP 需求承接很简单。如果有复杂查询需求，加一个列存节点就行了，对 OLAP 场景支持的也不错。

[jjshare123]

@afeiche 上亿数据，MySQL 很轻松。。
@RangerWolf MySQL 从表做分析统计

[dzdh]

cockroachdb
postgresql

[Rorysky]

大道至简， 选 sqlite

[dorothyREN]

@liprais yugabyte 可以试试, 分布式的 pg ，类似 tidb

[Hozzz]

上面不懂装懂的人太多了，先问问楼主要不要支持事务；
不要，推荐 doris/starrocks 之类 OLAP 数据库，用主键模型，查询速度碾压 ck （特别是多表聚合查询）；
要，没钱 tidb 社区版（加个 tiflash ，htap ）；有钱 oceanbase （别用社区版，BUG 多）；
Sharding-JDBC/proxy/mycat 这种早点丢了，没必要弄多个组件折腾自己

[hw191]

@KAKARTTO #5 够用，我们有几个表有 10 亿行，不过查起来是有点慢就是了

[nothingistrue]

@ManjusakaL #111 你要觉得照着别人的代码，用其他语言另写一套不算二开，你高兴就好。

[Hozzz]

@nothingistrue 太典了，哥，真的；头一次看到拿源码贴脸上还在说 tidb 二开 mysql 的人，hhhhh
有空建议去读下 tidb 的优化器 和 mysql 优化器源码，不丢人

[mysterycai]

@nothingistrue 知道为啥好多人反驳你，而且没有人帮你说话吗？ 多研究研究再来对线比较好。如果说 tidb 是直译 mysql 代码，那没得说。关键是 tidb 只是兼容了 MySQL 协议而已，懂吗

[zoharSoul]

才上亿, mysql 轻轻松松

[mayerer]

@kuituosi #19 全面全能

[Exception615]

Doris 投一票

[ManjusakaL]

@nothingistrue DB 最关键的 planner ，优化器，存储之类的都是完全独立的路线了，还搁这“照着别人的代码，用其他语言另写一套”呢。笑死了

[rrdssb]

@q11391 doris 你们是怎么解决高并发统计分析类查询的，不是点查哦

[nothingistrue]

@Hozzz #122 第一，二开不丢人。第二，二开不是抄袭，就是要在基础上做修改的，而多次修改之后共同的痕迹会越来越少，这时候不能再用源代码对比来做反证。

@mysterycai #123 第一，请溯源看看我的第一个回复，那只是在对回答楼主。第二，就按对线算吧，在二开这一点上，利益无关、没目的、不求认同、闲着无事随性恢复，这是立于不败位置的（你们要是揪着「二阶段提交效果存疑」这一点，或者后面的 Oceanbase 来对线，那还有赢的可能）。


最后跟所有拿源码说事的人来个总回复：
一，完全屏蔽原软件的代码、文档即其他任何开发资料，只靠其对外演示功能做开发，这是静室开发。
二、在许可或者不许可的情况下，在原软件的开发资料基础上做开发，是二次开发。
三、遵循开源协议，在源代码的基础上拉分支直接做开发，这也是二次开发，不过会将其更精确的叫做开源项目分叉。
四、当你再说 Mysql 兼容的时候，别说重头开发，就是静室开发一个跟 Mysql 兼容的数据库，好好想想这个难度有多大，再好好想想就算难度能克服，那跟「照着 Mysql 画瓢（ Mysql 又允许你画瓢）」相比是否又有必要。
五、二次开发不丢人，二次开发了还不承认就丢人了，这相当于牛顿说自己是自立而不是站在巨人肩膀上的。

[q11391]

@rrdssb 高并发的统计分析，这个应该需要 Kylin 或者 druid 吧？按楼主的情况 mysql 当事务数据库用，doris 当简单的数仓做数分用，没问题的

[mightybruce]

@nothingistrue 有点搞笑，那么多人都说了， 你怎么还这么头铁。tidb 是 newsql ， 其设计是在 google spanner F1 论文的实现 来对关系事务做支持。
tidb mysql 兼容的 mysql 传输的协议 和 sql 语法，而不是什么二开。
另外 tidb 设计理念就和 mysql 没有关系，
存储引擎层用 rust 写的 tikv, TiKV 的 KV 存储模型和 SQL 中的 Table 无关
查询层则是用 golang 写的。

[Hozzz]

@nothingistrue 那你拿出二开的证据啊，说了一大堆理论，证据在哪，别扯大道理；兼容很难？只要表现一样，底层实现可以完全不同；照你神逻辑，ob 企业版也是 oracle 二开的咯？

[Hozzz]

@nothingistrue 你以为国产数据库啥都是 opengauss 那样，拿个 pg 源代码不停改改改？

[MuSeCanYang]

sql server 一亿跟闹着玩似的。

[flmn]

查询不复杂的话，mysql 或者 pg 能够应付了，上 ssd 盘

[lenmore]

推荐 Oceanbase ，4.2 版本，运维能力强的就用社区版，完全够用了。
对 MySQL 协议的兼容、运维工具等都比 TiDB 好。配置要求也不恐怖，对比 TiDB 友好很多。

[liuhan907]

@nothingistrue
第一次见到源码贴脸还这么嘴硬的。那我再给贴脸一下，MySQL 这个单机数据库是要如何照抄一个分布式存储和事务的 TiDB 出来？你可别给我说 X-A 协议，笑掉大牙的事情。

[sxyclint]

区区过亿，连表都不用分，我们在客户环境，pg 单表 5 个亿，加上索引，一点问题都没有

[nothingistrue]

@Hozzz #132 你要真对薄公堂的话那我就废功夫去找证据。现在这种场景，就当我阴谋论吧，没必要再浪费功夫了，这根楼主的主题已经偏好远了。

@liuhan907 #137 你赢了。

@mightybruce #131 你的第一句话不予评论。后面的是到现在那么多对话中唯一的干货。

[sngxx]

预估一下数据量，mysql 或 mysql+分库分表就可以了。简单的查询和统计，走从库够用吧。
TiDB 聊胜于无的东西。
大规模数据，比如有几十张表要联合分析你再上 clickhouse ，用 canal 工具把数据同步到 kafka 再到 clickhouse 。

[ZSeptember]

如果觉得以后业务量较大，直接上 Tidb 吧，当然用 PostgreSQL 和 MySQL 问题也不大，只是如果以后扛不住了，迁移麻烦。

[liuhan907]

@nothingistrue
您这逆风就跑路啦？怎么不找点证据来证实一下呢，还是你一开始就只是口嗨其实啥都没研究过？

[noparking188]

@nothingistrue #129 我真是程序员，我还是个 PingCAP Certified TiDB Professional ，不过没啥用，之前公司用我就简单学了下原理实现。 TiDB 是 Share Nothing ，底层存储是 TiKV ，基于 RocksDB 开发的，TiFlash 是借鉴 ClickHouse 开发的。
简单讲，TiDB 底层数据结构是 LSM-Tree ，MySQL 是 B+Tree ，二开不了。
再告诉你个好玩的，他们一开始打算用 HDFS 做底层纯属引擎，用 Java 吭哧吭哧写入半年，然后删库重写。

[noparking188]

我的经验是，不要分库分表，其他都好说

[9113946]

@coinbase 吊打 clickhouse ？兄弟，你有用过吗？

[zzmark06]

建议裸表直接干，扔掉分库分表中间件

真上亿了，有压力了，你会不知道咋优化？