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

有没有推荐的时序数据库或者其他数据库?

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

    背景:

    公司有 30W 台设备,高峰时 6W 台在线,每隔 5s 上传一次数据,一年大概只有 6 个月左右工作.大概整个生命周期内 100W 条数据(每条数据算 64 个监控点),每年预计 10W 新设备增长,数据永久保存(最大到 100W 台设备).

    现在使用单机 InfluxDB,总记录 600 亿左右,硬盘占用 4T,高峰时内存经常用满128G导致重启.

    写多读少.

    需求:

    1. 免费;
    2. 内存,硬盘占用少(新机器只能分配 128G 内存和 15T 的 SSD);
    3. 数据永久保存的情况下(每个设备 50W~100W 的数据量)近期数据的查询时间在 10s 内;
    4. 支持少量乱序写入.

    最近调研了几个数据库:

    1. TDengine:

      a. 数据和表删除不会释放空间,只能 keep 设置的数据到期才会删除(企业版支持数据重组),而且乱序写入好像还会占用额外空间?

      b. 性能还行,单表 1 亿的情况下也能在 10s 内,百万数据的话 1s 内(1W 个表,就一个表 1 亿数据,其他表只有 1W 数据).

    2. IoTDB:

      a. 性能还行,没多测;

      b. 内存,硬盘按他给的算法,占用很多.

    3. QuestDB:

      a. 数据量一亿的情况下性能还行,占用跟 TDengine 差不多;

      b. 数据量上到 10 亿后,查询性能下降非常多,写入也慢(吃 CPU,不过够用).

    前几天看到站内的VictoriaMetrics/Prometheus+Thanos还没测,不知道具体咋样.

    大家有没有什么好的推荐?

    13 条回复    2024-05-28 12:07:15 +08:00
    codegenerator
        1
    codegenerator  
       180 天前
    为什么不试试 mongdb ?
    GooMS
        2
    GooMS  
       180 天前 via Android
    先优化
    hhhzccc
        3
    hhhzccc  
       180 天前
    1 、TimescaleDB 试试。2 、Prometheus 接 ck 试试。
    hahawode
        4
    hahawode  
       180 天前
    @codegenerator #1 mongodb 的时序 对比别的数据库有优点吗
    yjhatfdu2
        5
    yjhatfdu2  
       180 天前
    算了一下,一年应该不超过 4000 亿,这个情况用 clickhouse ,认真设计一下表结构尤其是编码方式,应该是可以满足的,而且 CH 可以设置把老数据自动丢到对象存储,降低成本
    me1onsoda
        6
    me1onsoda  
       180 天前
    6w 在线,5 秒上报一次,差不多 10k qps ,居然把内存 128g 打满了???
    txhwind
        7
    txhwind  
       180 天前
    为啥不加内存?内存钱不比迁移成本低吗
    wxf666
        8
    wxf666  
       180 天前
    需求是这样吗:每秒最多写入 (100W 在线设备 / 5s/条) = 20W 条数据,每条 (4 << 40) / 6e10 = 73 字节?

    没用过太高大上的数据库,只有点朴素的想法。

    1. 每小时的数据,存在内存里(需 20W * 3600 * 100 / 2 ^ 30 = 67 GB 内存)
    2. 数据库 ID 设计为(时间戳_年~小时 + 设备 ID + 时间戳_分~秒)
    3. 整点后,按 (设备 ID, 时间) 顺序,写入这一小时数据,至数据库。(顺序写入,很快的)
    4. 如果怕丢失数据,接收到上报信息后,也同步写入到 csv 文件里。
     (也是顺序写入,很快的。如果只是《时间戳,设备 ID 》信息,每秒顺序写入 (10 + 1 + 6 + 1) * 20W / 2 ^ 20 = 3.43 MB 数据而已)

    这样搞下来,数据库相当于《读多写少》了。正好可以考虑 SQLite 、DuckDB 等。。

    试了下,对于 SQLite ,如果只是存上述主键的话,一小时 7.2 亿数据,需要 10GB 文件,写了 5 分钟。。(平均每秒 200W ,还行)

    前几天回帖过,SQLite 可以 0.1 秒,在 1 亿数据里,找什么设备,什么时候离线超过 24 小时(每台设备每分钟上报一次)。

    当然,这是缓存了 1 GB 内存的结果。在固态上,完全无缓存,需要几秒钟。

    具体要啥查询,题主也没写。。只能联想到前几天,有点相关的场景了。。

    如果换 DuckDB ,应该能更快。我没试过。
    lovelylain
        9
    lovelylain  
       180 天前
    @wxf666 SQLite 不一般是客户端使用的单机甚至单应用使用的数据库吗,能用在后台大数据场景?
    RedisMasterNode
        10
    RedisMasterNode  
       180 天前
    VictoriaMetrics contributor here ,调研时有相关问题可以私信问我,很乐意探讨 :) 并且安利一下它,我们是从 Prometheus + thanos 迁移过来的
    RedisMasterNode
        11
    RedisMasterNode  
       179 天前
    以及一些 case ,上面有用户具体的数据量和规模可以参考: https://victoriametrics.com/case-studies/grammarly/
    xueling
        12
    xueling  
       179 天前
    时序性数据库可以考虑 VictoriaMetrics ,TimescaleDB ,hbase 等方案。我不知道你说的数据查询场景都有什么场景。如果大部分是分钟、小时、天等粒度的指标查询,可以不依赖时序数据库,而依赖流式统计来实现,因为时序性数据要对存储到磁盘的数据进行计算汇总后再返回结果,这个查询效率其实并不非常高,而流式统计其实更适合。技术方案可以变更为:1 、使用时序性数据库存储原始数据,作为备用,2 、使用流式统计服务提供数据指标查询功能。这样流式统计服务可以分担很大的数据查询压力。可以考虑一下我的开源项目: https://github.com/xl-xueling/xl-lighthouse
    Desdemor
        13
    Desdemor  
       179 天前
    用 ck , 先 redis 缓存处理,然后批量插入到 ck 里面,如果有别的需求,可以单独用物化视图
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2698 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 09:57 · PVG 17:57 · LAX 01:57 · JFK 04:57
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.