1w 并发写数据库,毫秒级响应,支持接入 IOT 设备,要求容灾、备份,支持通过调整软件和加设备动态扩容,系统图形化配置管理,实时系统监控等,这的技术要求大概需要什么样的团队? - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
请不要在回答技术问题时复制贴 AI 生成的内容
tuine
V2EX    程序员

1w 并发写数据库,毫秒级响应,支持接入 IOT 设备,要求容灾、备份,支持通过调整软件和加设备动态扩容,系统图形化配置管理,实时系统监控等,这的技术要求大概需要什么样的团队?

  •  
  •   tuine 2020-04-19 11:51:21 +08:00 8352 次点击
    这是一个创建于 2053 天前的主题,其中的信息可能已经有所发展或是发生改变。
    看到一个标书的描述,感觉大厂才能搞的样子~
    第 1 条附言    2020-04-19 17:14:40 +08:00
    刚开始以为普通关系数据库,刚发现描述是:具备每秒 10000 条以上的并发事件写入历史数据库的能力,应该指时序数据库了吧
    第 2 条附言    2020-04-19 17:25:08 +08:00
    这里 10k 并发应该是针对实时数据,如果针对业务数据存储是不是两者不在一个层级?不清楚淘宝日常并发大概有多少
    61 条回复    2020-04-20 15:08:28 +08:00
    shoaly
        1
    shoaly  
       2020-04-19 11:58:04 +08:00
    有些标书是乱写的, 让不懂得甲方 觉得你便宜又, 选你选你就选你...
    最终实际现场 数据库操作可能 1 秒一次写入
    paradoxs
        2
    paradoxs  
       2020-04-19 12:00:58 +08:00
    基本上都是 devops 的需求。

    小厂肯定是干不了的。
    az402
        3
    az402  
       2020-04-19 12:04:41 +08:00   2
    一般招标前 甲方已经对接好厂商了
    标书都是乙方厂商 根据自己功能写的
    areless
        4
    areless  
       2020-04-19 12:17:30 +08:00 via Android   1
    现在的 10k 只需要 lua 加 nginx,一台服务器就可以了。假设你使用大牛们的框架以及大牛们的传统的 io,一个机房机器给你用都不够的。
    rockyou12
        5
    rockyou12  
       2020-04-19 12:28:28 +08:00
    要扩容是要求数据库都要一键点击扩容,那可能真的只有头部几个公司有这个资源和实力
    janxin
        6
    janxin  
       2020-04-19 13:20:06 +08:00
    这要求不高的...
    find
        7
    find  
       2020-04-19 14:08:09 +08:00 via iPhone
    以作为一个曾经总体设计落地实施的物联网平台的人来说,你这个不算难
    HunterPan
        8
    HunterPan  
       2020-04-19 14:08:34 +08:00 via iPhone
    4 楼也真敢吹
    cominghome
        9
    cominghome  
       2020-04-19 14:17:37 +08:00
    @areless #4 你整个 helloworld 没准 lua 都用不上...
    xsen
        10
    xsen  
       2020-04-19 14:22:50 +08:00
    选择合适的数据库方案(如分布式数据库),那容灾、备份、动态扩展直接就支持了(加机器就可以)
    像别的,比如 IOT 设备接入、监控与管理后台,单纯工作量问题而已,没太大的难度
    xsen
        11
    xsen  
       2020-04-19 14:24:50 +08:00
    10 个人的团队基本是可以。前端要 2-3 个,架构 1-2 个,剩下的就是后台与 devops
    j2gg0s
        12
    j2gg0s  
       2020-04-19 15:04:38 +08:00
    1w 并发写数据库。日千万成交量的电商,正常下单峰值是不超过 1k 的
    jzmws
        13
    jzmws  
       2020-04-19 15:30:29 +08:00
    @j2gg0s 物联网设备不一样 , 很多定时上报数据的, 到时间点是有很多设备一起上报的 ,没有的话有可能就几台 . 它的上报一般是有周期有规律的
    wangyzj
        14
    wangyzj  
       2020-04-19 15:31:11 +08:00
    1w 并发!
    我的天
    淘宝吗?
    lidlesseye11
        15
    lidlesseye11  
       2020-04-19 16:10:41 +08:00
    愿意花钱上 aws 之类的话感觉外包也能做。。
    qiyuey
        16
    qiyuey  
       2020-04-19 16:23:18 +08:00   1
    上阿里云
    littlewing
        17
    littlewing  
       2020-04-19 16:30:53 +08:00
    4 楼真能吹,10k 毫秒级响应的数据库 TPS 不是那么简单的
    gamexg
        18
    gamexg  
       2020-04-19 16:48:48 +08:00
    目前的经验
    1w 并发不是问题,增加 10 倍单机也能撑得住
    数据库这个适合时序数据库,不过我没线上高负载时序数据库经验。
    线上单机 sql 数据库批量写入的性能记得是 3w 行 /s 。

    技术上看起来问题不大,主要问题是所有需求都实现的话工作量会非常大。
    gamexg
        19
    gamexg  
       2020-04-19 16:49:51 +08:00
    @gamexg #18 对了,毫秒级响应需要具体细节。
    jorneyr
        20
    jorneyr  
       2020-04-19 16:53:38 +08:00
    关系型数据库可能比较麻烦,MongoDB 等 NoSQL 的话 10000 的 QPS 写单机就可以实现。
    xiaket
        21
    xiaket  
       2020-04-19 16:57:10 +08:00   1
    如果可以用云服务厂商, 感觉一个人就可以搞定的样子...
    cs419
        22
    cs419  
       2020-04-19 17:08:28 +08:00
    乍一看
    1w 并发 碉堡了
    再一看 iot 数据采集 哦不涉及数据修改的竞争

    毫秒级响应 ?? 响应个啥数据?
    动态扩容 那就 云服务 容器化嘛
    love
        23
    love  
       2020-04-19 17:18:39 +08:00 via Android
    @jorneyr 你是怎么产生关系型数据库性能不及 nosql 的错觉的
    tuine
        24
    tuine  
    OP
       2020-04-19 17:20:35 +08:00
    @cs419 起初我也认为不是针对 IoT 数据的。
    毫秒级响应 :虚拟应用服务的系统从读取数据库到刷新用户屏幕的响应时间应在毫秒量级。
    动态扩展:通过服务资源池和服务动态扩展框架,通过简单的增加设备和调整软件部署即可达实现扩容
    tuine
        25
    tuine  
    OP
       2020-04-19 17:27:11 +08:00
    @gamexg 之前是 web 开发,就是没时序数据库相关经验~
    tuine
        26
    tuine  
    OP
       2020-04-19 17:33:53 +08:00
    @xsen 初级 web 转物联网后端开发~ 架构师和 devops 真的必不可少~
    murmur
        27
    murmur  
       2020-04-19 17:53:03 +08:00
    按理来说这只是表象,后面的内容应该还有多长时间的维护合同
    opengps
        28
    opengps  
       2020-04-19 18:43:03 +08:00 via Android
    重点是架构和设备,我最早的 gps 就是从零到一自己做的平台,前东家离职的时候已经可以支撑 100 万台设备以上了
    xiaket
        29
    xiaket  
       2020-04-19 18:46:11 +08:00
    你这种就不要和淘宝比了, 时序数据往数据库里面写, 不涉及竞争不涉及 transaction, 甚至我猜测都不需要关系型数据库, 而且要求不高的话直接前面加个队列, 批量往后端写, 更是降低存储的需求.
    find
        30
    find  
       2020-04-19 19:13:47 +08:00 via iPhone
    @HunterPan 我没有吹,我确实做过 百万级别物联网设备 iot,现在的 iot 雏形以及 基础硬件 对于这个事情没有你们想象的那么难 。
    tuine
        31
    tuine  
    OP
       2020-04-19 19:14:33 +08:00
    @xiaket 没有对比,只是好奇淘宝的日常并发量级~物联网方面时序数据和淘宝这种业务数据确实没可比性
    find
        32
    find  
       2020-04-19 19:15:09 +08:00 via iPhone
    @opengps 不会我们是同行?
    opengps
        33
    opengps  
       2020-04-19 19:47:50 +08:00 via Android
    @find 握爪。公网环境里的传感器数据采集,这个行业特征太特殊,密集写入,但读出其实没那么多。
    合理的架构,一人负责即可轻松撑起百万甚至更多的负载能力,只不过企业里往往不允许出现这么重要的核心人物,所以才需要把团队规模扩充到 10 人以上
    话说我当初的离职原因也正式因为经历了从零到一,再发现从 10 万到 1 亿里其实没有太多可探索的东西了
    fiht
        34
    fiht  
       2020-04-19 20:01:52 +08:00
    1w 并法到 MQ(Kafka)
    后面该怎么搞就怎么搞了
    levon
        35
    levon  
       2020-04-19 20:12:25 +08:00 via iPhone
    时序数据库
    find
        36
    find  
       2020-04-19 20:16:30 +08:00
    @opengps 都是一样的,我之前是主要负责人实现人,从 0 到 1 自己写 gateway ,存储 ,计算 都是我负责. 不过我也离职了,可以交流交流
    Bijiabo
        37
    Bijiabo  
       2020-04-19 20:17:59 +08:00
    如果只是实现后台功能,对产品易用性要求不高的话在物联网行业 3 个人就够了:一个产品兼职项目经理、一个前端、一个后端。

    楼上可能很多人把并发想的难度太大了,这个要看具体什么场景谈并发:
    一般情况是属于设备上报、控制之类的处理,这些有通用的平台服务,基本不需要自己操心,无非是后续的统计分析,买个队列服务消费处理就好了,之前看实际项目,大学毕业有一年经验就可以做了。

    另外招标这个事情,不要当真。当时我在的公司对外给出的方案,反正我自己不敢眼睛直视着客户吹
    wangxiyu191
        38
    wangxiyu191  
       2020-04-19 20:19:23 +08:00
    找个 tsdb 就完事了。如果可以依赖云服务的话直接用云服务相关团队都省了。你提的这些要求现在云服务厂商提供的 tsdb 基本都全能实现。
    Bijiabo
        39
    Bijiabo  
       2020-04-19 20:21:03 +08:00
    其实我觉得这个真正的门槛主要是 2 方面:
    1. 客户关系做到位,具体人员、组织利益达成共识
    2. 配套的硬件设备接入服务做到位,可以 hold 住各方参差不齐的水平最终把东西交付出去,一般要替客户主导整件事情的落地

    这方面能做的还是比较少的,项目成员在这个过程中也很大概率扛不下来跑路,还见到行业里有一些奇葩公司通过锁定年终奖之类的方式来保证人员稳定性。
    Bijiabo
        40
    Bijiabo  
       2020-04-19 20:22:23 +08:00
    这里的一万并发是至少一万个 IoT 设备在线接入吧 =_=...
    xuanbg
        41
    xuanbg  
       2020-04-19 20:27:30 +08:00
    数据库要支持 1 万并发写还是很费钱的……别的都是小 case
    sioncheng
        42
    sioncheng  
       2020-04-19 20:30:34 +08:00
    如果项目支持 1w+的 iot 设备在线,且每个 iot 设备提交数据的量>=1/s,那么可以说整个系统是需要按照 1 万 qps 来设计的;同时,又有健壮性和弹性要求;小规模团队还是用各种云服务比较靠谱。
    opengps
        43
    opengps  
       2020-04-19 21:21:40 +08:00 via Android
    https://www.opengps.cn/blog/view.asps?id=687&from=v2ex
    我刚刚嗦了一篇博文,欢迎大家点评下
    @find 来看看,指导下
    woscaizi
        44
    woscaizi  
       2020-04-19 21:21:57 +08:00 via iPhone
    设备的实时状态全部存 redis,同时通过 kafka 将历史数据写数据库,数据库做集群,做分库分表。大概的思路是这样。时序数据库没有实际用过,或许用它会更加简单。扩容的话可以直接上 haproxy,后面加机器就 ok 。
    opengps
        45
    opengps  
       2020-04-19 21:24:01 +08:00 via Android
    更正地址,手打的出错了
    https://www.opengps.cn/blog/view.aspx?id=687&from=v2ex
    我刚刚嗦了一篇博文,欢迎大家点评下
    Sasasu
        46
    Sasasu  
       2020-04-19 22:01:24 +08:00
    传感器数量基本固定,采集周期固定,要求低延迟。不知道中间串联消息队列并联缓存究竟是什么想法,造网站么...

    市面上有现成的时序数据库:1 亿次写入 6 块钱,一小时 60 元,一天 1440 元。数据免费存一年。
    GKLuke
        47
    GKLuke  
       2020-04-19 22:04:39 +08:00
    标书啊,3 楼正解。
    甲方爸爸写商务,乙方儿子写技术
    noparking188
        48
    noparking188  
       2020-04-19 22:19:00 +08:00
    @woscaizi 熟悉的配方,我们公司目前就这样,原始数据先缓存 redis,然后调中间件接口入 kafka,排队消耗存到 mysql
    AtmoicG
        49
    AtmoicG  
       2020-04-19 22:21:31 +08:00
    这种 IOT 的不需要关系型数据库吧?直接 opentsdb,1 万不是随便写啊。
    encro
        50
    encro  
       2020-04-19 22:31:39 +08:00
    物联网设备 1 万并发,是指一万个连接,这个问题不大吧。

    一个城市的交通一个行政区的交通摄像头,同时写入数据,分别写到不同的磁盘,这个难度也不大吧。

    所以脱离业务场景,去谈这些都是扯淡。

    普通物联网: 一个 mqtt+一个队列+时序数据库+磁盘阵列+分流。

    物联网 1 万并发,难度不如一个 500rps 的电商。
    naizhao
        51
    naizhao  
    &nbs;  2020-04-19 23:24:53 +08:00
    为什么会觉得很难? bdb 每个 CPU 核心每秒写入可以到 1000 万,随便写。有时候老旧的东西未必就比新东西差
    nicebird
        52
    nicebird  
       2020-04-19 23:39:26 +08:00
    1w 很容易搞吧
    outoftimeerror
        53
    outoftimeerror  
       2020-04-19 23:41:12 +08:00
    做过类似的物联网项目:f5->netty->kafka->(hbase/redis)
    wivwiv
        54
    wivwiv  
       2020-04-20 08:53:31 +08:00 via iPhone
    动态扩容好搞,缩容难搞;大部分有现成方案了,组合组合,其他手撸。
    bzzhou
        55
    bzzhou  
       2020-04-20 09:36:09 +08:00
    如果是非互联网大厂、非专业的数据库团队;那么 99.9%是拿一个开源的系统给你搭建一套;容灾、备份、动态扩容这些都不在话下。

    而且 IOT 场景,数据库应该是选择时序数据库,现在主流的解决方案支持这个并发应该没啥问题。
    Marmot
        56
    Marmot  
       2020-04-20 09:59:51 +08:00
    我怎么感觉这是我做过的项目....
    surfire91
        57
    surfire91  
       2020-04-20 10:46:33 +08:00
    1w 并发 和 1w QPS 是两个概念吧
    piao5109
        58
    piao5109  
       2020-04-20 12:17:53 +08:00
    说到 iot 就直接时序数据库。真的做过具体项目吗?

    只提 1w 并发写数据库其实意义不大。计算机对于顺序写入的数据是很高效的。与什么数据库关系不大。传感器数据也不复杂,仅仅是写,用 mysql 也问题不大。只是 iot 除了写传感器数据之外,还有很多业务逻辑,会有事物需求和有复杂的查询报表需求。所以可以考虑 sql +nosql 数据库一起来。


    其实这个需求难度都不在数据库。现在的互联网技术,处理这些数据库的压力都有成熟方案。
    难度在于:
    1 、接入设备管理。要保证接入、安全、产品售后维护等。会有一定的工作量。
    2 、devops 。大概甲方希望做到图形化运维,点点按钮可以做到动态扩缩容之类的,那这也有工作量和难度。
    3 、业务逻辑。比如按照区域、职级等做权限管理。

    加上开发、调试、运维工具。这种需求还是需要 10 个人的团队的。

    楼上说一个人可以搞定的几个兄弟,你打算自己慢慢搞啊,就算你能做到,就算企业也接受,甲方等得起?
    tuine
        59
    tuine  
    OP
       2020-04-20 14:44:52 +08:00
    @piao5109 赞同,目前没有 devops,作为后端开发真的是搞不来,确实涉及到很多业务逻辑,所以 IoT 数据和业务数据肯定要分开处理( pgsql+cassandra )。初步接触物联网相关开发,还没有架构师 devops~~
    RubyJack
        60
    RubyJack  
       2020-04-20 14:55:14 +08:00
    选 tidb 直接就全搞定了
    gemini767
        61
    gemini767  
       2020-04-20 15:08:28 +08:00
    评论都是大佬 那请问一下有人搞过广告场景么?广告监控统计,也是 tsdb ?
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     929 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 28ms UTC 20:25 PVG 04:25 LAX 12:25 JFK 15:25
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86