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

[fuckyoudolphin]

技术选型求助一发

业务要求：

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

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

查询 QPS：小于 100

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

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

[weizhen199]

可以，整个 clickhouse

[min]

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

[90928yao]

clickhouse 更新 还有 join 有点弱

[Sasasu]

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

[chihiro2014]

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

[nooper]

SQL 写的不精炼

[defage]

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

[liprais]

无脑推 clickhouse 的太可笑了

[newtype0092]

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

[fuyufjh]

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

[dzdh]

pgsql 保命

[pangleon]

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

[liuhan907]

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

[sacuba]

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

[encro]

直接建立统计表，这个是精确到天的，可以建立总共，月，周表，我现在是每天更新一次前一天，每 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]

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

[sampeng]

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

[90928yao]

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

[dog82]

为什么不能加减索引？

[zhangysh1995]

TiDB 考虑一下？

[death00]

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

[ren2881971]

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

[momowei]

oracle 是最好选择

[surfire91]

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

[laminux29]

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

[jenlors]

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

[Still4]

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

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

[rrfeng]

脱离业务谈需求就是 xxx

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

[tairan2006]

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

[zhengdai1990]

es 呗

[blueskea]

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

[jwdstefani]

ES 好使