真的受够了。
每次在聊到IoT数据这个情况的时候，所提及的内容就是“海量、高并发、成本”这些方面，这样的讲述听得人耳朵都起茧了。
不过，唯有那些真切地被MySQL写入操作致使陷入堵塞困境，且被硬盘的高额花费折磨到心疼肉痛的人，才能够明白那种绝望滋味。
不是所有数据，都配叫“时序数据”。
你以为的痛点，只是冰山一角
每秒十万级写入，真的只是门槛。
更为令人作呕的，即为那些以杂乱顺序抵达的数据包，网络稍微抖动一下，传统的库便陷入了茫然不知所措的状态。
要么丢数据，要么性能直接给你表演高台跳水 。
还有那个“高基数”问题。
通常来讲，要是你的设备数量越多，并且标签维度越繁杂，就像有着100亿条时间线那样，那么Prometheus这种类型的库就会直接呈现出让你看得目瞪口呆的状况。
别把“选型”搞成“相亲”
很多人选数据库像相亲——只看优点。
MySQL温柔，但扛不住事。
MongoDB看上去好像随和，然而存得时间久了，那存储成本会把CFO气得进入重症加强护理病房的。
开源的那些？
InfluxDB开源版本的单个节点，一旦出现流量急剧增长的情况，你将找不到可以哭泣的地方。
你需要的不是“完美情人”，是个能干重活的“农民工”。
存储压缩比低于10:1的，直接Pass。
写入不支持水平扩展的，看都别看。
查找超出500毫秒的，于工业现场而言此项无异于灾难——生产线已然停止运作，而你竟然仍处于加载状态？
昨天跟一个搞风电的朋友聊。
他讲，风机组在一秒钟的时间里，能够生成二百万条数据，以往运用HBase的时候，查询历史趋势，就得准备泡一杯茶出来备好，然后等待着。
“泡茶都变成一种讽刺了”，他苦笑。
比性能更烧脑的，是“运维债”
很多技术负责人选型只看TPS、QPS。
然而却忽视了那最为隐秘的成本，在半夜三点的时候，被报警电话给叫醒，随后竟然发觉自己没办法看懂监控面板。
运维复杂度这一事物，恰似房贷，年轻时觉着能够承受，待年纪渐长后才晓得究竟有多令人窒息。
真正的轻量化，是安装包几十兆，扩容点几下鼠标。
不是让你去研究K8s编排、研究第三方组件高可用。
我们是来搞数据的，不是来给开源项目做免费测试员的。
其实，大家要的很简单。
不是要一个“万能的数据库”。
而是要一个“懂IoT的数据库”。
会断网进而要有个东西叫“边缘协同”因为懂设备，有冷热之分所以得是分层存储，是有这关于这样一些数据并且懂它，人很懒所以需要依靠内置这个AI去进行主动的发现异常，而不是等着人去进行查找。
别信“银弹”，信“匹配”
或许你曾见过TSBS的压测报告，TDengine相较某些库要快出十几倍。
或许有人听闻过，IoTDB于国家级电网相关的案例里，其压缩比能够达成31比1。
数字很性感，但你要清醒。
没有绝对的“最强”，只有“最匹配”。
若你所面对的场景属于智能家居范畴，其中设备数量达到千万级别，并且具备查询简便的特点，那么轻量级以及超级表模型对于你而言就是合适的选择。
倘若属于工业制造范畴，呈现出乱序情况较多，并且需要深度剖析，那么在这种情形下，树状模型以及乱序处理引擎则必须占据主导地位。
写在最后
选型这件事，本质上是在给未来三年的自己选“战友”。
别让战友在关键时刻掉链子，也别让战友太娇贵养不起。
性能、成本、运维，这铁三角永远在博弈。
能不能在这三者相互间寻觅到那个能让你夜里得以安稳入眠的平衡状态之处，这便是属于你的“最优解”了。
最后送大家一句话：
切勿运用战术层面之上的勤奋，即疯狂地去测试性能，以此来遮掩战略方面的懒惰，也就是不去考量长久的运维成本。
愿你的数据，永远在线，永不丢。
Comments NOTHING