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

[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 考虑一下？