V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
fuckyoudolphin
V2EX  ›  数据库

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

  •  
  •   fuckyoudolphin · 2020-09-08 10:15:40 +08:00 · 4007 次点击
    这是一个创建于 1298 天前的主题,其中的信息可能已经有所发展或是发生改变。

    技术选型求助一发

    业务要求:

    MYSQL 里面三张 1000w 级别的表( A:500W B:1000W C:800W )

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

    查询 QPS:小于 100

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

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

    32 条回复    2020-09-10 16:31:14 +08:00
    weizhen199
        1
    weizhen199  
       2020-09-08 10:19:22 +08:00
    可以,整个 clickhouse
    min
        2
    min  
       2020-09-08 10:24:49 +08:00
    1. 不能动索引还谈什么优化
    2. 可以上 olap
    90928yao
        3
    90928yao  
       2020-09-08 10:42:42 +08:00
    clickhouse 更新 还有 join 有点弱
    Sasasu
        4
    Sasasu  
       2020-09-08 11:02:26 +08:00
    clickhouse join 弱的话我不知道什么数据库 join 强,对任何一种 join 来说
    chihiro2014
        5
    chihiro2014  
       2020-09-08 11:08:01 +08:00
    如果是 join 的话,那得考虑大小表的问题,这样提高性能。
    nooper
        6
    nooper  
       2020-09-08 11:08:59 +08:00
    SQL 写的不精炼
    defage
        7
    defage  
       2020-09-08 11:10:37 +08:00
    这都有点像数据仓库了。你全部给它扒下来,binlog 订阅弄到一个大型宽表,或者 es 里面去。
    liprais
        8
    liprais  
       2020-09-08 11:14:06 +08:00
    无脑推 clickhouse 的太可笑了
    newtype0092
        9
    newtype0092  
       2020-09-08 11:14:11 +08:00
    数据全量 copy 过来,每天增量更新,能自己建索引就简单多了吧。
    fuyufjh
        10
    fuyufjh  
       2020-09-08 11:15:47 +08:00
    @Sasasu clickhouse 的 join 是单机的,基本就是鸡肋,他的设计是希望你在 ETL 的时候做好宽表
    dzdh
        11
    dzdh  
       2020-09-08 11:16:08 +08:00
    pgsql 保命
    pangleon
        12
    pangleon  
       2020-09-08 11:31:40 +08:00
    1. ES
    2. 新建表存储负责查询需要的条件,做冗余处理,然后依据索引去各个表拉数据。
    liuhan907
        13
    liuhan907  
       2020-09-08 11:33:10 +08:00 via Android
    为什么不试试 tidb+tiflash+binlog 同步呢?
    sacuba
        14
    sacuba  
       2020-09-08 11:40:01 +08:00   ❤️ 1
    greenplum 可以一试 对你的需求来看比较适合
    encro
        15
    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
        16
    xuanbg  
       2020-09-08 11:48:51 +08:00
    搞个小小的数仓,从数仓出数据就不会慢了。
    sampeng
        17
    sampeng  
       2020-09-08 12:35:11 +08:00
    求各位不要无脑 es 了。。你们算过成本嘛。。几千万的数据上 es 集群。。。成本划算不划算?
    90928yao
        18
    90928yao  
       2020-09-08 12:35:14 +08:00
    @Sasasu ck 的 join 确实不强 尤其是俩个大表
    dog82
        19
    dog82  
       2020-09-08 12:39:08 +08:00
    为什么不能加减索引?
    zhangysh1995
        20
    zhangysh1995  
       2020-09-08 12:59:28 +08:00
    TiDB 考虑一下?
    death00
        21
    death00  
       2020-09-08 13:17:39 +08:00
    统一之前一个人的观点,如果一天动一次,把聚合结果用定时任务专门跑一次,以后直接查聚合结果,应该就会很方便了。
    ren2881971
        22
    ren2881971  
       2020-09-08 13:22:37 +08:00
    建数据仓库,把事实表按照统计维度建立仓库,然后上联机分析工具 直接查询数据仓库数据。 这样快很多。
    momowei
        23
    momowei  
       2020-09-08 13:31:25 +08:00
    oracle 是最好选择
    surfire91
        24
    surfire91  
       2020-09-08 13:46:52 +08:00
    先看看索引能不能解决问题吧,如果能不如弄个从库,从库加索引,就这点数据量搞个数仓成本有点高。
    laminux29
        25
    laminux29  
       2020-09-08 14:48:44 +08:00
    既然不允许动原库索引,你就弄个副本库嘛,在副本库上做各种索引,反正不要求实时。
    jenlors
        26
    jenlors  
       2020-09-08 14:51:39 +08:00
    楼主你需要的是这个,https://github.com/long2ice/synch
    Still4
        27
    Still4  
       2020-09-08 15:23:51 +08:00
    个人经验 mysql 上千万进行聚合查询效率就很差了,就算索引跟查询很契合,架不住联表

    寻找其他数据库是有必要的,是否上分布式就看你们预算了
    rrfeng
        28
    rrfeng  
       2020-09-08 15:47:05 +08:00
    脱离业务谈需求就是 xxx

    没说数据结构,查询条件,没法优化。
    tairan2006
        29
    tairan2006  
       2020-09-08 16:11:46 +08:00
    直接塞 es…你这又不是实时更新,连 binlog 同步都不用,每天 12 点根据 update_time 增量更新一次完事。
    zhengdai1990
        30
    zhengdai1990  
       2020-09-08 17:52:06 +08:00
    es 呗
    blueskea
        31
    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
        32
    jwdstefani  
       2020-09-10 16:31:14 +08:00
    ES 好使
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5395 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 08:58 · PVG 16:58 · LAX 01:58 · JFK 04:58
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.