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

• 資深大佬 : shoaly

  有些标书是乱写的, 让不懂得甲方 觉得你便宜又屌, 选你选你就选你…
  最终实际现场 数据库操作可能 1 秒一次写入

• 資深大佬 : paradoxs

  基本上都是 devops 的需求。

  小厂肯定是干不了的。

• 資深大佬 : az402

  一般招标前 甲方已经对接好厂商了
  标书都是乙方厂商 根据自己功能写的

• 資深大佬 : areless

  现在的 10k 只需要 lua 加 nginx，一台服务器就可以了。假设你使用大牛们的框架以及大牛们的传统的 io，一个机房机器给你用都不够的。

• 資深大佬 : rockyou12

  要扩容是要求数据库都要一键点击扩容，那可能真的只有头部几个公司有这个资源和实力

• 資深大佬 : janxin

  这要求不高的…

• 資深大佬 : find

  以作为一个曾经总体设计落地实施的物联网平台的人来说，你这个不算难

• 資深大佬 : HunterPan

  4 也真敢吹

• 資深大佬 : cominghome

  @areless #4 你整个 helloworld 没准 lua 都用不上…

• 資深大佬 : xsen

  选择合适的数据库方案（如分布式数据库），那容灾、备份、动态扩展直接就支持了（加机器就可以）
  像别的，比如 IOT 设备接入、监控与管理后台，单纯工作量问题而已，没太大的难度

• 資深大佬 : xsen

  10 个人的团队基本是可以。前端要 2-3 个，架构 1-2 个，剩下的就是后台与 devops

• 資深大佬 : j2gg0s

  1w 并发写数据库。日千万成交量的电商，正常下单峰值是不超过 1k 的

• 資深大佬 : jzmws

  @j2gg0s 物联网设备不一样 , 很多定时上报数据的, 到时间点是有很多设备一起上报的 ,没有的话有可能就几台 . 它的上报一般是有周期有规律的

• 資深大佬 : wangyzj

  1w 并发！
  我的天
  淘宝吗？

• 資深大佬 : lidlesseye11

  愿意花钱上 aws 之类的话感觉外包也能做。。

• 資深大佬 : qiyuey

  上阿里云

• 資深大佬 : littlewing

  4 真能吹，10k 毫秒级响应的数据库 TPS 不是那么简单的

• 資深大佬 : gamexg

  目前的经验
  1w 并发不是问题，增加 10 倍单机也能撑得住
  数据库这个适合时序数据库，不过我没线上高负载时序数据库经验。
  线上单机 sql 数据库批量写入的性能记得是 3w 行 /s 。

  技术上看起来问题不大，主要问题是所有需求都实现的话工作量会非常大。

• 資深大佬 : gamexg

  @gamexg #18 对了，毫秒级响应需要具体细节。

• 資深大佬 : jorneyr

  关系型数据库可能比较麻烦，MongoDB 等 NoSQL 的话 10000 的 QPS 写单机就可以实现。

• 資深大佬 : xiaket

  如果可以用云服务厂商, 感觉一个人就可以搞定的样子…

• 資深大佬 : cs419

  乍一看
  1w 并发 碉堡了
  再一看 iot 数据采集 哦不涉及数据修改的竞争

  毫秒级响应 ？？ 响应个啥数据？
  动态扩容 那就 云服务 容器化嘛

• 資深大佬 : love

  @jorneyr 你是怎么产生关系型数据库性能不及 nosql 的错觉的

• 主 資深大佬 : tuine

  @cs419 起初我也认为不是针对 IoT 数据的。
  毫秒级响应 ：虚拟应用服务的系统从读取数据库到刷新用户屏幕的响应时间应在毫秒量级。
  动态扩展：通过服务资源池和服务动态扩展框架，通过简单的增加设备和调整软件部署即可达实现扩容

• 主 資深大佬 : tuine

  @gamexg 之前是 web 开发，就是没时序数据库相关经验~

• 主 資深大佬 : tuine

  @xsen 初级 web 转物联网后端开发~ 架构师和 devops 真的必不可少~

• 資深大佬 : murmur

  按理来说这只是表象，后面的内容应该还有多长时间的维护合同

• 資深大佬 : opengps

  重点是架构和设备，我最早的 gps 就是从零到一自己做的平台，前东家离职的时候已经可以支撑 100 万台设备以上了

• 資深大佬 : xiaket

  你这种就不要和淘宝比了, 时序数据往数据库里面写, 不涉及竞争不涉及 transaction, 甚至我猜测都不需要关系型数据库, 而且要求不高的话直接前面加个队列, 批量往后端写, 更是降低存储的需求.

• 資深大佬 : find

  @HunterPan 我没有吹，我确实做过 百万级别物联网设备 iot，现在的 iot 雏形以及 基础硬件 对于这个事情没有你们想象的那么难 。

• 主 資深大佬 : tuine

  @xiaket 没有对比，只是好奇淘宝的日常并发量级~物联网方面时序数据和淘宝这种业务数据确实没可比性

• 資深大佬 : find

  @opengps 不会我们是同行？

• 資深大佬 : opengps

  @find 握爪。公网环境里的传感器数据采集，这个行业特征太特殊，密集写入，但读出其实没那么多。
  合理的架构，一人负责即可轻松撑起百万甚至更多的负载能力，只不过企业里往往不允许出现这么重要的核心人物，所以才需要把团队规模扩充到 10 人以上
  话说我当初的离职原因也正式因为经历了从零到一，再发现从 10 万到 1 亿里其实没有太多可探索的东西了
• 資深大佬 : fiht

  1w 并法到 MQ(Kafka)
  后面该怎么搞就怎么搞了

• 資深大佬 : levon

  时序数据库

• 資深大佬 : find

  @opengps 都是一样的,我之前是主要负责人实现人,从 0 到 1 自己写 gateway ,存储 ,计算 都是我负责. 不过我也离职了,可以交流交流

• 資深大佬 : Bijiabo

  如果只是实现后台功能，对产品易用性要求不高的话在物联网行业 3 个人就够了：一个产品兼职项目经理、一个前端、一个后端。

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

  另外招标这个事情，不要当真。当时我在的公司对外给出的方案，反正我自己不敢眼睛直视着客户吹

• 資深大佬 : wangxiyu191

  找个 tsdb 就完事了。如果可以依赖云服务的话直接用云服务相关团队都省了。你提的这些要求现在云服务厂商提供的 tsdb 基本都全能实现。

• 資深大佬 : Bijiabo

  其实我觉得这个真正的门槛主要是 2 方面：
  1. 客户关系做到位，具体人员、组织利益达成共识
  2. 配套的硬件设备接入服务做到位，可以 hold 住各方参差不齐的水平最终把东西交付出去，一般要替客户主导整件事情的落地

  这方面能做的还是比较少的，项目成员在这个过程中也很大概率扛不下来跑路，还见到行业里有一些奇葩公司通过锁定年终奖之类的方式来保证人员稳定性。

• 資深大佬 : Bijiabo

  这里的一万并发是至少一万个 IoT 设备在线接入吧 =_=…

• 資深大佬 : xuanbg

  数据库要支持 1 万并发写还是很费钱的……别的都是小 case

• 資深大佬 : sioncheng

  如果项目支持 1w+的 iot 设备在线，且每个 iot 设备提交数据的量>=1/s，那么可以说整个系统是需要按照 1 万 qps 来设计的；同时，又有健壮性和弹性要求；小规模团队还是用各种云服务比较靠谱。

• 資深大佬 : opengps

  https://www.opengps.cn/blog/view.asps?id=687&from=v2ex
  我刚刚啰嗦了一篇博文，欢迎大家点评下
  @find 来看看，指导下

• 資深大佬 : woscaizi

  设备的实时状态全部存 redis，同时通过 kafka 将历史数据写数据库，数据库做集群，做分库分表。大概的思路是这样。时序数据库没有实际用过，或许用它会更加简单。扩容的话可以直接上 haproxy，后面加机器就 ok 。

• 資深大佬 : opengps

  更正地址，手打的出错了
  https://www.opengps.cn/blog/view.aspx?id=687&from=v2ex
  我刚刚啰嗦了一篇博文，欢迎大家点评下

• 資深大佬 : Sasasu

  传感器数量基本固定，采集周期固定，要求低延迟。不知道中间串联消息队列并联缓存究竟是什么想法，造网站么…

  市面上有现成的时序数据库：1 亿次写入 6 块钱，一小时 60 元，一天 1440 元。数据免费存一年。

• 資深大佬 : GKLuke

  标书啊，3 正解。
  甲方爸爸写商务，乙方儿子写技术

• 資深大佬 : noparking188

  @woscaizi 熟悉的配方，我们公司目前就这样，原始数据先缓存 redis，然后调中间件接口入 kafka，排队消耗存到 mysql

• 資深大佬 : AtmoicG

  这种 IOT 的不需要关系型数据库吧？直接 opentsdb，1 万不是随便写啊。

• 資深大佬 : encro

  物联网设备 1 万并发，是指一万个连接，这个问题不大吧。

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

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

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

  物联网 1 万并发，难度不如一个 500rps 的电商。

• 資深大佬 : naizhao

  为什么会觉得很难？ bdb 每个 CPU 核心每秒写入可以到 1000 万，随便写。有时候老旧的东西未必就比新东西差

• 資深大佬 : nicebird

  1w 很容易搞吧

• 資深大佬 : outoftimeerror

  做过类似的物联网项目：f5->netty->kafka->(hbase/redis)

• 資深大佬 : wivwiv

  动态扩容好搞，缩容难搞；大部分有现成方案了，组合组合，其他手撸。

• 資深大佬 : bzzhou

  如果是非互联网大厂、非专业的数据库团队；那么 99.9%是拿一个开源的系统给你搭建一套；容灾、备份、动态扩容这些都不在话下。

  而且 IOT 场景，数据库应该是选择时序数据库，现在主流的解决方案支持这个并发应该没啥问题。

• 資深大佬 : Marmot

  我怎么感觉这是我做过的项目….

• 資深大佬 : surfire91

  1w 并发 和 1w QPS 是两个概念吧

• 資深大佬 : piao5109

  说到 iot 就直接时序数据库。真的做过具体项目吗？

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

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

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

  上说一个人可以搞定的几个兄弟，你打算自己慢慢搞啊，就算你能做到，就算企业也接受，甲方等得起？

• 主 資深大佬 : tuine

  @piao5109 赞同，目前没有 devops，作为后端开发真的是搞不来，确实涉及到很多业务逻辑，所以 IoT 数据和业务数据肯定要分开处理（ pgsql+cassandra ）。初步接触物联网相关开发，还没有架构师 devops~~

• 資深大佬 : RubyJack

  选 tidb 直接就全搞定了

• 資深大佬 : gemini767

  评论都是大佬 那请问一下有人搞过广告场景么？广告监控统计，也是 tsdb ？