1
shoaly 2020-04-19 11:58:04 +08:00
有些标书是乱写的, 让不懂得甲方 觉得你便宜又屌, 选你选你就选你...
最终实际现场 数据库操作可能 1 秒一次写入 |
2
paradoxs 2020-04-19 12:00:58 +08:00
基本上都是 devops 的需求。
小厂肯定是干不了的。 |
3
az402 2020-04-19 12:04:41 +08:00 2
一般招标前 甲方已经对接好厂商了
标书都是乙方厂商 根据自己功能写的 |
4
areless 2020-04-19 12:17:30 +08:00 via Android 1
现在的 10k 只需要 lua 加 nginx,一台服务器就可以了。假设你使用大牛们的框架以及大牛们的传统的 io,一个机房机器给你用都不够的。
|
5
rockyou12 2020-04-19 12:28:28 +08:00
要扩容是要求数据库都要一键点击扩容,那可能真的只有头部几个公司有这个资源和实力
|
6
janxin 2020-04-19 13:20:06 +08:00
这要求不高的...
|
7
find 2020-04-19 14:08:09 +08:00 via iPhone
以作为一个曾经总体设计落地实施的物联网平台的人来说,你这个不算难
|
8
HunterPan 2020-04-19 14:08:34 +08:00 via iPhone
4 楼也真敢吹
|
9
cominghome 2020-04-19 14:17:37 +08:00
@areless #4 你整个 helloworld 没准 lua 都用不上...
|
10
xsen 2020-04-19 14:22:50 +08:00
选择合适的数据库方案(如分布式数据库),那容灾、备份、动态扩展直接就支持了(加机器就可以)
像别的,比如 IOT 设备接入、监控与管理后台,单纯工作量问题而已,没太大的难度 |
11
xsen 2020-04-19 14:24:50 +08:00
10 个人的团队基本是可以。前端要 2-3 个,架构 1-2 个,剩下的就是后台与 devops
|
12
j2gg0s 2020-04-19 15:04:38 +08:00
1w 并发写数据库。日千万成交量的电商,正常下单峰值是不超过 1k 的
|
13
jzmws 2020-04-19 15:30:29 +08:00
@j2gg0s 物联网设备不一样 , 很多定时上报数据的, 到时间点是有很多设备一起上报的 ,没有的话有可能就几台 . 它的上报一般是有周期有规律的
|
14
wangyzj 2020-04-19 15:31:11 +08:00
1w 并发!
我的天 淘宝吗? |
15
lidlesseye11 2020-04-19 16:10:41 +08:00
愿意花钱上 aws 之类的话感觉外包也能做。。
|
16
qiyuey 2020-04-19 16:23:18 +08:00 1
上阿里云
|
17
littlewing 2020-04-19 16:30:53 +08:00
4 楼真能吹,10k 毫秒级响应的数据库 TPS 不是那么简单的
|
18
gamexg 2020-04-19 16:48:48 +08:00
目前的经验
1w 并发不是问题,增加 10 倍单机也能撑得住 数据库这个适合时序数据库,不过我没线上高负载时序数据库经验。 线上单机 sql 数据库批量写入的性能记得是 3w 行 /s 。 技术上看起来问题不大,主要问题是所有需求都实现的话工作量会非常大。 |
20
jorneyr 2020-04-19 16:53:38 +08:00
关系型数据库可能比较麻烦,MongoDB 等 NoSQL 的话 10000 的 QPS 写单机就可以实现。
|
21
xiaket 2020-04-19 16:57:10 +08:00 1
如果可以用云服务厂商, 感觉一个人就可以搞定的样子...
|
22
cs419 2020-04-19 17:08:28 +08:00
乍一看
1w 并发 碉堡了 再一看 iot 数据采集 哦不涉及数据修改的竞争 毫秒级响应 ?? 响应个啥数据? 动态扩容 那就 云服务 容器化嘛 |
24
tuine OP @cs419 起初我也认为不是针对 IoT 数据的。
毫秒级响应 :虚拟应用服务的系统从读取数据库到刷新用户屏幕的响应时间应在毫秒量级。 动态扩展:通过服务资源池和服务动态扩展框架,通过简单的增加设备和调整软件部署即可达实现扩容 |
27
murmur 2020-04-19 17:53:03 +08:00
按理来说这只是表象,后面的内容应该还有多长时间的维护合同
|
28
opengps 2020-04-19 18:43:03 +08:00 via Android
重点是架构和设备,我最早的 gps 就是从零到一自己做的平台,前东家离职的时候已经可以支撑 100 万台设备以上了
|
29
xiaket 2020-04-19 18:46:11 +08:00
你这种就不要和淘宝比了, 时序数据往数据库里面写, 不涉及竞争不涉及 transaction, 甚至我猜测都不需要关系型数据库, 而且要求不高的话直接前面加个队列, 批量往后端写, 更是降低存储的需求.
|
30
find 2020-04-19 19:13:47 +08:00 via iPhone
@HunterPan 我没有吹,我确实做过 百万级别物联网设备 iot,现在的 iot 雏形以及 基础硬件 对于这个事情没有你们想象的那么难 。
|
33
opengps 2020-04-19 19:47:50 +08:00 via Android
@find 握爪。公网环境里的传感器数据采集,这个行业特征太特殊,密集写入,但读出其实没那么多。
合理的架构,一人负责即可轻松撑起百万甚至更多的负载能力,只不过企业里往往不允许出现这么重要的核心人物,所以才需要把团队规模扩充到 10 人以上 话说我当初的离职原因也正式因为经历了从零到一,再发现从 10 万到 1 亿里其实没有太多可探索的东西了 |
34
fiht 2020-04-19 20:01:52 +08:00
1w 并法到 MQ(Kafka)
后面该怎么搞就怎么搞了 |
35
levon 2020-04-19 20:12:25 +08:00 via iPhone
时序数据库
|
36
find 2020-04-19 20:16:30 +08:00
@opengps 都是一样的,我之前是主要负责人实现人,从 0 到 1 自己写 gateway ,存储 ,计算 都是我负责. 不过我也离职了,可以交流交流
|
37
Bijiabo 2020-04-19 20:17:59 +08:00
如果只是实现后台功能,对产品易用性要求不高的话在物联网行业 3 个人就够了:一个产品兼职项目经理、一个前端、一个后端。
楼上可能很多人把并发想的难度太大了,这个要看具体什么场景谈并发: 一般情况是属于设备上报、控制之类的处理,这些有通用的平台服务,基本不需要自己操心,无非是后续的统计分析,买个队列服务消费处理就好了,之前看实际项目,大学毕业有一年经验就可以做了。 另外招标这个事情,不要当真。当时我在的公司对外给出的方案,反正我自己不敢眼睛直视着客户吹 😂 |
38
wangxiyu191 2020-04-19 20:19:23 +08:00
找个 tsdb 就完事了。如果可以依赖云服务的话直接用云服务相关团队都省了。你提的这些要求现在云服务厂商提供的 tsdb 基本都全能实现。
|
39
Bijiabo 2020-04-19 20:21:03 +08:00
其实我觉得这个真正的门槛主要是 2 方面:
1. 客户关系做到位,具体人员、组织利益达成共识 2. 配套的硬件设备接入服务做到位,可以 hold 住各方参差不齐的水平最终把东西交付出去,一般要替客户主导整件事情的落地 这方面能做的还是比较少的,项目成员在这个过程中也很大概率扛不下来跑路,还见到行业里有一些奇葩公司通过锁定年终奖之类的方式来保证人员稳定性。 |
40
Bijiabo 2020-04-19 20:22:23 +08:00
这里的一万并发是至少一万个 IoT 设备在线接入吧 =_=...
|
41
xuanbg 2020-04-19 20:27:30 +08:00
数据库要支持 1 万并发写还是很费钱的……别的都是小 case
|
42
sioncheng 2020-04-19 20:30:34 +08:00
如果项目支持 1w+的 iot 设备在线,且每个 iot 设备提交数据的量>=1/s,那么可以说整个系统是需要按照 1 万 qps 来设计的;同时,又有健壮性和弹性要求;小规模团队还是用各种云服务比较靠谱。
|
43
opengps 2020-04-19 21:21:40 +08:00 via Android
|
44
woscaizi 2020-04-19 21:21:57 +08:00 via iPhone
设备的实时状态全部存 redis,同时通过 kafka 将历史数据写数据库,数据库做集群,做分库分表。大概的思路是这样。时序数据库没有实际用过,或许用它会更加简单。扩容的话可以直接上 haproxy,后面加机器就 ok 。
|
45
opengps 2020-04-19 21:24:01 +08:00 via Android
|
46
Sasasu 2020-04-19 22:01:24 +08:00
传感器数量基本固定,采集周期固定,要求低延迟。不知道中间串联消息队列并联缓存究竟是什么想法,造网站么...
市面上有现成的时序数据库:1 亿次写入 6 块钱,一小时 60 元,一天 1440 元。数据免费存一年。 |
47
GKLuke 2020-04-19 22:04:39 +08:00
标书啊,3 楼正解。
甲方爸爸写商务,乙方儿子写技术 |
48
noparking188 2020-04-19 22:19:00 +08:00
@woscaizi 熟悉的配方,我们公司目前就这样,原始数据先缓存 redis,然后调中间件接口入 kafka,排队消耗存到 mysql
|
49
AtmoicG 2020-04-19 22:21:31 +08:00
这种 IOT 的不需要关系型数据库吧?直接 opentsdb,1 万不是随便写啊。
|
50
encro 2020-04-19 22:31:39 +08:00
物联网设备 1 万并发,是指一万个连接,这个问题不大吧。
一个城市的交通一个行政区的交通摄像头,同时写入数据,分别写到不同的磁盘,这个难度也不大吧。 所以脱离业务场景,去谈这些都是扯淡。 普通物联网: 一个 mqtt+一个队列+时序数据库+磁盘阵列+分流。 物联网 1 万并发,难度不如一个 500rps 的电商。 |
51
naizhao 2020-04-19 23:24:53 +08:00
为什么会觉得很难? bdb 每个 CPU 核心每秒写入可以到 1000 万,随便写。有时候老旧的东西未必就比新东西差
|
52
nicebird 2020-04-19 23:39:26 +08:00
1w 很容易搞吧
|
53
outoftimeerror 2020-04-19 23:41:12 +08:00
做过类似的物联网项目:f5->netty->kafka->(hbase/redis)
|
54
wivwiv 2020-04-20 08:53:31 +08:00 via iPhone
动态扩容好搞,缩容难搞;大部分有现成方案了,组合组合,其他手撸。
|
55
bzzhou 2020-04-20 09:36:09 +08:00
如果是非互联网大厂、非专业的数据库团队;那么 99.9%是拿一个开源的系统给你搭建一套;容灾、备份、动态扩容这些都不在话下。
而且 IOT 场景,数据库应该是选择时序数据库,现在主流的解决方案支持这个并发应该没啥问题。 |
56
Marmot 2020-04-20 09:59:51 +08:00
我怎么感觉这是我做过的项目....
|
57
surfire91 2020-04-20 10:46:33 +08:00
1w 并发 和 1w QPS 是两个概念吧
|
58
piao5109 2020-04-20 12:17:53 +08:00
说到 iot 就直接时序数据库。真的做过具体项目吗?
只提 1w 并发写数据库其实意义不大。计算机对于顺序写入的数据是很高效的。与什么数据库关系不大。传感器数据也不复杂,仅仅是写,用 mysql 也问题不大。只是 iot 除了写传感器数据之外,还有很多业务逻辑,会有事物需求和有复杂的查询报表需求。所以可以考虑 sql +nosql 数据库一起来。 其实这个需求难度都不在数据库。现在的互联网技术,处理这些数据库的压力都有成熟方案。 难度在于: 1 、接入设备管理。要保证接入、安全、产品售后维护等。会有一定的工作量。 2 、devops 。大概甲方希望做到图形化运维,点点按钮可以做到动态扩缩容之类的,那这也有工作量和难度。 3 、业务逻辑。比如按照区域、职级等做权限管理。 加上开发、调试、运维工具。这种需求还是需要 10 个人的团队的。 楼上说一个人可以搞定的几个兄弟,你打算自己慢慢搞啊,就算你能做到,就算企业也接受,甲方等得起? |
59
tuine OP @piao5109 赞同,目前没有 devops,作为后端开发真的是搞不来,确实涉及到很多业务逻辑,所以 IoT 数据和业务数据肯定要分开处理( pgsql+cassandra )。初步接触物联网相关开发,还没有架构师 devops~~ 😌
|
60
RubyJack 2020-04-20 14:55:14 +08:00
选 tidb 直接就全搞定了
|
61
gemini767 2020-04-20 15:08:28 +08:00
评论都是大佬 那请问一下有人搞过广告场景么?广告监控统计,也是 tsdb ?
|