数据库技术选型求助。。。。

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 1535 天前的主题，其中的信息可能已经有所发展或是发生改变。

技术选型求助一发

业务要求：

MYSQL 里面三张 1000w 级别的表（ A：500W B：1000W C:800W ）

没有分库分表，有索引但我不能动（因为是其他部门的库）
列的数量：（ A:30 B：15：C:20 ）
每张表每天新增不超过 1W 条数据
并没有实时查询的需求（每天 12 点更新一次数据即可）
做各种各样的比较复杂的聚合查询（经常加乱七八糟的需求）

查询 QPS：小于 100

现在通过优化 SQL 最复杂的查询速度小于 5s
但现在渐渐扛不住了领导还是觉得太慢

所以现在求助一下
第一个问题继续优化 mysql 还能继续压榨性能吗
第二个问题由于没有实时查询的要求其他部门也愿意导出数据给我找个适合 OLAP 的数据库能解决我现在的问题吗

查询

MySQL

求助

选型

32 条回复 • 2020-09-10 16:31:14 +08:00

weizhen199

2020-09-08 10:19:22 +08:00

可以，整个 clickhouse

min

2020-09-08 10:24:49 +08:00

1. 不能动索引还谈什么优化
2. 可以上 olap

90928yao

2020-09-08 10:42:42 +08:00

clickhouse 更新还有 join 有点弱

Sasasu

2020-09-08 11:02:26 +08:00

clickhouse join 弱的话我不知道什么数据库 join 强，对任何一种 join 来说

chihiro2014

2020-09-08 11:08:01 +08:00

如果是 join 的话，那得考虑大小表的问题，这样提高性能。

nooper

2020-09-08 11:08:59 +08:00

SQL 写的不精炼

defage

2020-09-08 11:10:37 +08:00

这都有点像数据仓库了。你全部给它扒下来，binlog 订阅弄到一个大型宽表，或者 es 里面去。

liprais

2020-09-08 11:14:06 +08:00

无脑推 clickhouse 的太可笑了

newtype0092

2020-09-08 11:14:11 +08:00

数据全量 copy 过来，每天增量更新，能自己建索引就简单多了吧。

fuyufjh

2020-09-08 11:15:47 +08:00

@Sasasu clickhouse 的 join 是单机的，基本就是鸡肋，他的设计是希望你在 ETL 的时候做好宽表

dzdh

2020-09-08 11:16:08 +08:00

pgsql 保命

pangleon

2020-09-08 11:31:40 +08:00

1. ES
2. 新建表存储负责查询需要的条件，做冗余处理，然后依据索引去各个表拉数据。

liuhan907

2020-09-08 11:33:10 +08:00 via Android

为什么不试试 tidb+tiflash+binlog 同步呢？

sacuba

2020-09-08 11:40:01 +08:00

greenplum 可以一试对你的需求来看比较适合

encro

2020-09-08 11:43:04 +08:00

直接建立统计表，这个是精确到天的，可以建立总共，月，周表，我现在是每天更新一次前一天，每 15 分钟更新当天数据。

阿里云 1H1G RDS 满足每天几万单的需求。

CREATE TABLE `stat_store_per_day` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`store_id` int(11) NOT NULL COMMENT '店铺',
`date` date NOT NULL,
`key` smallint(4) NOT NULL COMMENT '统计项',
`value` decimal(10,2) NOT NULL COMMENT '值',
`create_at` datetime NOT NULL COMMENT '创建时间',
PRIMARY KEY (`id`),
UNIQUE KEY `store_id` (`store_id`,`key`,`date`),
KEY `date` (`date`),
KEY `key_date` (`key`,`date`)
) ENGINE=InnoDB;

作为程序员首先要问的是“为什么不能动索引？”：

1，不知道 online ddl 怕影响线上业务？
2，怕优化变慢？没有慢日志吗？

根据我的经验不能动通常是因为当心程序员功力不够，怕动了出灾难，但是不多动几次，怎么学习，团队成员怎么成长？

所以好的团队文化是：可以动，但是要在安全，做好安全措施前提谨慎的动。

xuanbg

2020-09-08 11:48:51 +08:00

搞个小小的数仓，从数仓出数据就不会慢了。

sampeng

2020-09-08 12:35:11 +08:00

求各位不要无脑 es 了。。你们算过成本嘛。。几千万的数据上 es 集群。。。成本划算不划算？

90928yao

2020-09-08 12:35:14 +08:00

@Sasasu ck 的 join 确实不强尤其是俩个大表

dog82

2020-09-08 12:39:08 +08:00

为什么不能加减索引？

zhangysh1995

2020-09-08 12:59:28 +08:00

TiDB 考虑一下？

death00

2020-09-08 13:17:39 +08:00

统一之前一个人的观点，如果一天动一次，把聚合结果用定时任务专门跑一次，以后直接查聚合结果，应该就会很方便了。

ren2881971

2020-09-08 13:22:37 +08:00

建数据仓库，把事实表按照统计维度建立仓库，然后上联机分析工具直接查询数据仓库数据。这样快很多。

momowei

2020-09-08 13:31:25 +08:00

oracle 是最好选择

surfire91

2020-09-08 13:46:52 +08:00

先看看索引能不能解决问题吧，如果能不如弄个从库，从库加索引，就这点数据量搞个数仓成本有点高。

laminux29

2020-09-08 14:48:44 +08:00

既然不允许动原库索引，你就弄个副本库嘛，在副本库上做各种索引，反正不要求实时。

jenlors

2020-09-08 14:51:39 +08:00

楼主你需要的是这个，https://github.com/long2ice/synch

Still4

2020-09-08 15:23:51 +08:00

个人经验 mysql 上千万进行聚合查询效率就很差了，就算索引跟查询很契合，架不住联表

寻找其他数据库是有必要的，是否上分布式就看你们预算了

rrfeng

2020-09-08 15:47:05 +08:00

脱离业务谈需求就是 xxx

没说数据结构，查询条件，没法优化。

tairan2006

2020-09-08 16:11:46 +08:00

直接塞 es…你这又不是实时更新，连 binlog 同步都不用，每天 12 点根据 update_time 增量更新一次完事。

zhengdai1990

2020-09-08 17:52:06 +08:00

es 呗

blueskea

2020-09-08 18:22:28 +08:00 via Android

两点想法供参考。1.参考 kylin 做预计算，结果还存储在 MySQL 中，再配合缓存。成本较低但预计算的逻辑设计比较复杂。2.binlog 实时同步工具 canal, sdc 。离线工具 sqoop, datax 。olap 数据库 kylin clickhouse kudu es, 建议选择有成熟 jdbc 接口的。都建大宽表，空间换时间。

jwdstefani

2020-09-10 16:31:14 +08:00

ES 好使