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

彭于晏们 , 我来套一个数据库的选型方案

  •  1
     
  •   changdy · 2021-08-12 00:14:46 +08:00 · 3592 次点击
    这是一个创建于 542 天前的主题,其中的信息可能已经有所发展或是发生改变。

    我想把现有 ERP 系统的查询功能进行优化

    目前的情况是有 4 张主表, 每张表大概有 1500w 条数据 ,每天大概增加 3w 条数据, 每张表都有 100 多个字段,其中不乏有 varchar(200)这种字符串.

    查询时 4 张表还会进行 join,算上其他表总的关联表大概有 10 张左右.并且查询条件也比较多变,聚合索引难以覆盖所有场景,但一般会基于一个时间段再搭配其他三四个灵活的字段进行查询.

    目前的想法是把这几张表的数据进行聚合,筛选出比较重要的字段(大概有 70 个)单独存放到一个数据库中 , 以下是我的一些需求

    • 首要的是查询效率高,能满足多变的组合查询条件
    • 不是冷数据,有低频更新的需求 每秒三十次左右
    • 格式较为固定 , 很少添加或者修改字段
    • 由于已经是聚合后的数据所以不需要 join 操作
    • 无事务要求
    • 基本上只做即时查询 ,没有对数据进行二次挖掘和处理

    目前是把数据放到了 MongoDB ,加上索引后大概占了 20GB 左右,查询效率一般, 所以想知道对于我这种场景有没有比 MongoDB 更合适的数据库, PostgreSQL ClickHouse Cassandra ?

    第 1 条附言  ·  2021-08-14 13:53:06 +08:00
    首先感谢各位彭于晏 , 前几天加班较多没有太多精力思考大家的解决思路.另外其实我也在想,怎么从产品层面怎样优化.

    对于技术选型 我还有一点疑惑 , 我看到好多人都提到了 ES ,但是我只知道 ES 是个搜索引擎,那么 ES 适合我这种查询条件多变并且不需要分词查询的场景吗?

    其次也有不少人投票了 ClickHouse ,其实我自己也有些心动 ,但是想了想 目前对这个的了解也比较少,大部分文档也来自于各种贩卖焦虑的微信公众号 , 所以也只能暂时搁置了,不过我还是很想知道大家使用 ClickHouse 的真实效果

    目前首选应该是以日期月份做水平分表 , 但是有个问题 ,如果在月初的时候我想差最近七天的数据 ,这个就涉及到了跨物理表 ,这种场景下查询效率会不会降低很多?

    再次感谢各位的回复.
    35 条回复    2021-08-18 13:58:10 +08:00
    jmone
        1
    jmone  
       2021-08-12 02:37:27 +08:00
    以前我们使用 mongo,2000 万左右的数据,索引后,数据查询时平均 500ms 的响应时间,然后就放弃使用 mongo 了
    pengtdyd
        2
    pengtdyd  
       2021-08-12 06:22:28 +08:00
    这么多表 join 应该考虑重构
    lixm
        3
    lixm  
       2021-08-12 08:45:19 +08:00
    ES 啊
    changdy
        4
    changdy  
    OP
       2021-08-12 08:51:56 +08:00
    @pengtdyd 已经再重构 查询逻辑了 ,帖子中已经描述了,但问题在于重构后数据应该放到那种数据库中.
    changdy
        5
    changdy  
    OP
       2021-08-12 08:53:09 +08:00
    @jmone 我在网上也看到了 .这种 schema free 的 数据库查询效率都不高....
    encro
        6
    encro  
       2021-08-12 08:57:53 +08:00   ❤️ 2
    没有必要 mongodb 吧,mongodb 只是一个文档型数据库,并不会帮你提高性能。

    看你对实时性要求和查询范围,
    pg 有物理视图和聚合,是否能满足要求?

    我们有一个项目也是几千万数据。
    我是限制了默认查询时间,在时间上加了索引,比如只查询最近一天或者一周的。这样数据也就几万几十万,还是很快的,一般 50MS 能出来。
    对于复杂的,要查询 2 个月以上的,都走统计表,统计表为增量,每 5-15 分钟执行一次,所以不是实时的。如果你团队人力比较充沛,可以用自动聚合,做成实时的。
    JKeita
        7
    JKeita  
       2021-08-12 09:17:49 +08:00
    一张表 100 多个字段,这个设计真是鬼才。。。
    JKeita
        8
    JKeita  
       2021-08-12 09:30:43 +08:00
    感觉 ES 就够了吧
    wangyzj
        9
    wangyzj  
       2021-08-12 10:08:16 +08:00
    数据库不要变
    ERP 这种强关系型还得用关系型数据库
    可以做一个同步到 es 的作业
    只做查询
    mongo 不合适
    speedofstephen
        10
    speedofstephen  
       2021-08-12 10:12:52 +08:00
    时间段是多长呢,如果一天就 3 万,只某一天 或者更小的区间搜索。直接用时间段过滤 然后用 java 的 stream 做筛选。应该不会超过 100ms 把。
    Pursue9
        11
    Pursue9  
       2021-08-12 10:18:43 +08:00
    可以把包含 json 的字段丢到另一张表中去, 然后主键还用原来表的主键
    例如 user (主键是 useruid) 表拆分成 user 和 user_detail 两个表, 主键都是 useruid,什么时候用到 user_detail 的数据时候,再去查 user_detail 的数据
    vone
        12
    vone  
       2021-08-12 10:28:35 +08:00
    早呀,彦祖。
    42is42is42
        13
    42is42is42  
       2021-08-12 10:54:29 +08:00
    Get More Row
    victorywangzhcn
        14
    victorywangzhcn  
       2021-08-12 11:34:46 +08:00
    如果没有大量模糊查询的需要,无脑选 ClickHouse,可以测一测。个人感觉 ES 比 ClickHouse 更难运维,而且如果你有 Aggregate 相关操作,ES 非常硬盘 IO emmmm
    Mithril
        15
    Mithril  
       2021-08-12 11:46:37 +08:00   ❤️ 1
    既然一般会基于时间查询,说明你这数据本身就是时序数据,可以考虑时序数据库。
    如果要用 ES 的话需要考虑两点,一是你的字符串内容要做分词检索吗?二是你要做聚合统计吗?
    如果都不要,只是把 ES 当成速度快一点的数据库的话,那么意义不大。因为你还要考虑 ES 本身的那些问题,得不偿失。
    所以现在的首要问题是,你是真的需要用 ES 去加速检索,还是想办法优化你的 MySQL 。

    至于其它的,你用 MySQL 和 Mongo 解决不了的问题,不要指望 Pg 和 Cassandra 能解决。时序型数据库的话,还是要考虑上面 ES 那段里提到的问题。你需要做聚合统计吗?还是只做数据检索。
    xx6412223
        16
    xx6412223  
       2021-08-12 15:51:19 +08:00
    你这个场景的时间段好像不太适用时序数据库。
    这样呢:
    按年份或者其他周期分成不同的表,保障单表的数据量
    nekoneko
        17
    nekoneko  
       2021-08-12 16:42:13 +08:00
    分区分表吧,不用考虑 es,mongo 什么的了
    才 20G,直接 redis 好吧
    有钱的话上 hana
    windyboy
        18
    windyboy  
       2021-08-12 17:37:40 +08:00
    有超长字符串的就不合适做关系数据库
    初步就是改文档型
    当然只是纯粹查询的需求直接上 ES 更好
    MarksGui
        19
    MarksGui  
       2021-08-12 18:20:11 +08:00
    100 多个字段,确实牛逼
    hayhong123
        20
    hayhong123  
       2021-08-12 20:17:33 +08:00
    感觉 ClickHouse 和 ES 都能满足呀
    sytnishizuiai
        21
    sytnishizuiai  
       2021-08-12 21:31:26 +08:00
    我的人生中超过 2 30 个的都没见过。。。学习了、、、
    zibber
        22
    zibber  
       2021-08-12 22:44:20 +08:00
    1. 如果有关联查询, 写入到 es 的数据按需要重新整合, es 关联查询性能不行
    2. 还有一个更简单的方式, 买阿里云的 analyticd, 同步一份, 多核大内存硬查, 选个 16c, 32c 绝对够用
    jwangkun
        23
    jwangkun  
       2021-08-13 09:37:19 +08:00
    ClickHouse
    zlo309618100
        24
    zlo309618100  
       2021-08-13 09:59:48 +08:00
    塞到 es 的一个索引里面,然后用主表的 id 作为 documentid.
    然后所有的查询打到 es,查出 id 之后再去数据库里面拉
    这样就把问题从条件查询转为 id 查询。
    不过有坑的点是,es 是 real time,刚插入的数据不能在 100ms 级查出来。
    strict
        25
    strict  
       2021-08-13 16:13:10 +08:00
    当然是 clickhouse

    - 首要的是查询效率高,能满足多变的组合查询条件
    > clickhouse 支持超多内置函数&自定义函数

    基本上只做即时查询 ,没有对数据进行二次挖掘和处理
    > 计算速度快

    其余条件
    > 全都满足
    Brentwans
        26
    Brentwans  
       2021-08-13 19:09:40 +08:00
    4 张 1kw 的表之间还要 join ? n 比 n 的 join 吗?
    changdy
        27
    changdy  
    OP
       2021-08-14 13:05:55 +08:00
    @Brentwans 不是 1 对 2,3 这种. 也有点类似于垂直分表了
    changdy
        28
    changdy  
    OP
       2021-08-14 13:17:16 +08:00
    这个查询既有实时性要求 同时也不能把查询范围定的太死,
    但是对于时间范围较大的查询,基本上不做聚合操作, 过滤后的数据基本上只有五六条
    @encro
    changdy
        29
    changdy  
    OP
       2021-08-14 13:20:25 +08:00
    @wangyzj
    @JKeita
    @windyboy
    请问下 我并不需要 es 的分词检索 , 这种情况 es 的性能会比其他数据库的查询性能更高吗?
    changdy
        30
    changdy  
    OP
       2021-08-14 13:24:30 +08:00
    @nekoneko 嗯 正在考虑用 shardingsphere 实现分区分表 .不过 redis 就不太行了 单纯的 key value .涉及到条件查询还需要加载到内存中过滤
    encro
        31
    encro  
       2021-08-14 17:27:11 +08:00   ❤️ 1
    同等配置下,es 性能不会比 mysql 高,预热过后加载到内存中的 es 才性能高。

    es 性能高的主要原理是:
    1,index 分区;
    2,内存预热;
    3,搜索引擎倒排索引;

    欢迎补充。
    waytodelay
        32
    waytodelay  
       2021-08-14 20:52:17 +08:00
    @encro ES 有什么学习资料推荐吗?最近想学习这个
    encro
        33
    encro  
       2021-08-15 09:42:22 +08:00
    @waytodelay

    官方文档,没记错有中文的。

    补充 es 性能高还有一点当然是:
    容易集群;
    encro
        34
    encro  
       2021-08-17 09:18:26 +08:00
    按日期查询,
    那么 ES 比较合适的一种选择吧,
    可以按年月建立 index,然后查询。

    不过,ERP 一般都是依赖数据库,通过触发器,物理视图,统计表之类的提高查询性能。
    whajcf
        35
    whajcf  
       2021-08-18 13:58:10 +08:00
    ClickHouse 慎用, 出现错误数据时删除特别麻烦, 现在云版报表模块咬牙改数据, 本地版已经拉出分支来在换库实现 ...
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   实用小工具   ·   556 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 50ms · UTC 18:18 · PVG 02:18 · LAX 10:18 · JFK 13:18
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.