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

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

  •  1
     
  •   changdy · 111 天前 · 3273 次点击
    这是一个创建于 111 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    欢迎补充。
    waytodelay
        32
    waytodelay   108 天前
    @encro ES 有什么学习资料推荐吗?最近想学习这个
    encro
        33
    encro   107 天前
    @waytodelay

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

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

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