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

数据库选型——要求根据主键查询,数据量在 150 亿左右

  •  2
     
  •   eric96 · 2021-08-05 11:40:56 +08:00 · 4291 次点击
    这是一个创建于 1198 天前的主题,其中的信息可能已经有所发展或是发生改变。
    目的:根据唯一主键从数据库中查询一行数据,要求 50TPS,延迟在 200ms
    数据库现状:每天新增数据 10 亿行,保留 15 天数据,即数据库基本上稳定在 150 亿行数据(后续会增长到每天新增 30 亿行,即 450 亿行数据)
    对数据库的要求:写入 TPS 至少为 2W,并且可以扩展。读取要求不高,并且为简单的查询场景,只使用唯一主键进行查询,没有其它需要

    使用场景:数据镜像保存,并在需要的时候取出数据
    40 条回复    2021-08-09 09:28:58 +08:00
    liprais
        1
    liprais  
       2021-08-05 11:48:46 +08:00 via iPhone
    hbase 完事
    zoharSoul
        2
    zoharSoul  
       2021-08-05 11:49:24 +08:00
    我觉得 hbase 就很合适
    saytesnake
        3
    saytesnake  
       2021-08-05 11:55:25 +08:00
    假设服务器配置不错的情况,hbase 集群完事 +1,写入很舒适。
    winnie2012
        4
    winnie2012  
       2021-08-05 11:56:15 +08:00
    zmxnv123
        5
    zmxnv123  
       2021-08-05 12:42:05 +08:00
    kv 存储吗,试试 tikv
    sanestays
        6
    sanestays  
       2021-08-05 12:54:27 +08:00
    doris clickhouse
    learningman
        7
    learningman  
       2021-08-05 12:56:07 +08:00 via Android
    唯一主键找 kv 呗
    defage
        8
    defage  
       2021-08-05 12:58:49 +08:00
    hbase 吧,应该是最合适的了
    rekulas
        9
    rekulas  
       2021-08-05 13:02:51 +08:00
    纯 kv 数据库选择就多了 rocksdb 应该是入手最简单又能满足需求的
    blackshow
        10
    blackshow  
       2021-08-05 13:12:45 +08:00
    cassandra
    dusu
        11
    dusu  
       2021-08-05 13:17:53 +08:00 via iPhone
    这个规模要并发、要简单 用 ssdb 多主就 ok 了,ssdb 的主从使用运维体验基本无敌,唯一就是注意业务上分 key 写节点,key 按日期前缀生成,直接扫前缀就能清理
    wzw
        12
    wzw  
       2021-08-05 13:30:44 +08:00
    @dusu ssdb 更新很少了吧, 可以看看 pika 数据库试试
    dusu
        13
    dusu  
       2021-08-05 13:34:34 +08:00 via iPhone
    @wzw (一年多前) pika 在生产环境下集群各种不稳定,也可能是我们 hold 不住,所以换回 ssdb 了,ssdb 虽然不更新但是够用,基本没蹦过
    offswitch
        14
    offswitch  
       2021-08-05 14:06:29 +08:00
    @dusu 试一下 kvrocks,这个更新挺勤的,而且目前已经支持集群了
    eric96
        15
    eric96  
    OP
       2021-08-05 14:19:41 +08:00
    @zmxnv123
    @learningman
    @rekulas
    @dusu
    @wzw
    @offswitch
    数据虽然是用主键来查找的,但是数据列比较多,有 30+列,平均每一行的数据大小在 1.5KB 。
    如果是这种情况下用 kv 存储是否可行,性能能否跟上。
    因为除了 redis,没了解过其它 kv,希望各位能给些意见
    Jface
        16
    Jface  
       2021-08-05 14:19:47 +08:00
    Hbase 吧 或者试试 TiDB?
    huangzxx
        17
    huangzxx  
       2021-08-05 14:25:08 +08:00
    clickhouse
    dog82
        18
    dog82  
       2021-08-05 15:10:03 +08:00
    传统数据库,做分区表,能撑住吗?
    wellsc
        19
    wellsc  
       2021-08-05 15:14:20 +08:00 via iPhone
    @sanestays 确定?
    eric96
        20
    eric96  
    OP
       2021-08-05 15:17:37 +08:00
    @dog82 我设想了一下,估计是撑不住的。
    因为需要类似 ttl 的实现,所以如果使用时间作为分区键的构成之一,会导致写入的热区(所以基本上是撑不住 2WTPS 的写入),并且由于查询的时候,只有主键没有时间信息会导致查询上的性能问题(当然也可以修改目前主键的构成,加上时间信息,后续查询的时候解析出时间信息)。所以即使修改主键的构成,但是依旧无法解决写入的问题
    如果不使用时间信息去做分区,将无法删除旧数据,会导致数据一直膨胀,而且传统的数据库删除数据并不会释放磁盘空间,只有删除库或分区才会释放空间
    rekulas
        21
    rekulas  
       2021-08-05 16:05:55 +08:00
    @eric96 kv 写入是完全没有问题的(渣机都可以跑到 4w+),不过一般的 kv 库都存字符串不支持字段(需要序列化存储),要支持字段只能考虑楼上列的其他非 kv 数据库
    dog82
        22
    dog82  
       2021-08-05 16:58:06 +08:00
    你这种需求好像比较适合时序数据库
    azkaban
        23
    azkaban  
       2021-08-05 17:21:32 +08:00
    aerospike
    shot
        24
    shot  
       2021-08-05 18:32:46 +08:00
    > 目的:根据唯一主键从数据库中查询一行数据,要求 50TPS,延迟在 200ms

    如果没有硬件资源限制的话,任何支持水平线性扩展的分布式数据库都能满足吧。
    数据量再大,性能要求更高,加机器完事。

    Cassandra 完美契合这一需求,参考 Discord 的经验:12 个节点,3 重复制,支撑日均过亿消息,写操作亚毫秒,读操作 5 毫秒。
    https://blog.discord.com/how-discord-stores-billions-of-messages-7fa6ec7ee4c7

    Discord 去年声称迁移到了性能更佳的 ScyllaDB,但是没有看到具体的性能指标。
    https://www.scylladb.com/press-release/discord-chooses-scylla-core-storage-layer/
    shot
        25
    shot  
       2021-08-05 18:36:09 +08:00
    @eric96

    如果只评估传统的关系性数据库的话,那就尝试分区、分表、分库操作吧。

    撑不住 20k tps 写入,可以考虑加一个消息队列做缓冲,批量处理批量写入。
    在对读操作要求不高的场景下,问题应该不大。
    Samuelcc
        26
    Samuelcc  
       2021-08-05 18:38:32 +08:00 via Android
    正是 hbase 发挥武艺的地方
    Maxwe11
        27
    Maxwe11  
       2021-08-05 19:40:28 +08:00
    这需求简直就是按照 hbase 准备的。
    sagaxu
        28
    sagaxu  
       2021-08-05 19:48:46 +08:00 via Android
    mysql 也扛得住,主键改成: 日期+db 实例+序列号,假设 100 个实例,每天 100 张独立的表,每张表 3000 万压力不大。清理的时候直接 drop 对应日期的表。
    ajaxfunction
        29
    ajaxfunction  
       2021-08-05 22:50:00 +08:00   ❤️ 1
    真想看看这种大场面,
    目前维护的数据库里最多的一张业务表也就几千万数据,一个普通索引就够了
    limbo0
        30
    limbo0  
       2021-08-05 23:14:13 +08:00
    主键查询省事很多, 直接 hbase
    shakoon
        31
    shakoon  
       2021-08-06 10:25:00 +08:00
    预算不说一下吗?费用充足 taradata,费用一般 greenplum,费用拮据 hbase
    eric96
        32
    eric96  
    OP
       2021-08-06 10:56:18 +08:00
    @shakoon 现在用的云服务,基本上每个月根据流量情况在 5000 刀-1W5 刀左右。想换掉的目的一个是想拜托对这个云厂商的依赖(其他云没有这个服务,也没有对应开源服务),另一个目的是能省钱最好,省不了钱也能接受
    hjosama200
        33
    hjosama200  
       2021-08-06 17:09:19 +08:00
    @ajaxfunction 真想看看这种大场面呢呜呜呜,这话说的,几千万还不满足吗 QAQ,这边孩子最多的用户表数据 500 不到,咱也想看看大场面呢 QAQ,4 年 java 后端,月薪 4k,美名其曰技术总监... 呜呜呜呜
    hjosama200
        34
    hjosama200  
       2021-08-06 17:09:44 +08:00
    救救孩子吧 QAQ
    ajaxfunction
        35
    ajaxfunction  
       2021-08-06 18:00:12 +08:00
    @hjosama200 你这也太惨了吧,是不是 to b 的啊,要不 500 个用户咋养活公司呢?
    我 to c 随便一场活动 新用户就新增 2000+啊, 但留存不到 15%。
    someonedeng
        36
    someonedeng  
       2021-08-06 23:31:45 +08:00
    @hjosama200 该换工作了兄弟
    aru
        37
    aru  
       2021-08-07 08:30:47 +08:00
    greenplum 绝对满足,多开点硬盘,多搞分区
    makdon
        38
    makdon  
       2021-08-07 10:37:13 +08:00
    @hjosama200 跑路吧孩子,这用户也太少了,每个用户得花多少钱才能养活这公司
    flyingfz
        39
    flyingfz  
       2021-08-07 12:04:53 +08:00
    https://www.taosdata.com/cn/documentation/evaluation#intro

    可以看看 国产的 taos, 从文档来看 还是比较靠谱的 。
    hjosama200
        40
    hjosama200  
       2021-08-09 09:28:58 +08:00
    @ajaxfunction 辣鸡公司哪有 to b 那种大格局呀~ 显然是 to c 呀,用户上线率不到几十个,就是叫人充 vip 的辣鸡 app
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5167 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 34ms · UTC 03:49 · PVG 11:49 · LAX 19:49 · JFK 22:49
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.