@nivalxer 我是每个传感器一个表，返回的文档长度不超过 16M 吗，有更好的方案可以分享一下。
@hd10180 他格式没有这么多，就是固定的 data 数组，要么 50,100,200 ，是根据采样率来定的。传感器也没有 uuid 全靠自己编。
@yyt6801 data 数组就是 50 或者 100 或者 200 个浮点数，每秒的数据都是这样。
@sagaxu 是的，我现在只统计了每秒的最大值，最小值，平均值，读取起来还不算太费劲。正常来说我们只关注十分钟这个节点，还有每分钟数据，这个都还算好用处理。文件确实，主要是读取文件比较麻烦，文件目录不固定，没有很好的索引方式。
@kivmi 是的，但是我们的数据也不算大，就是多，频繁，每秒都有，直接查询原始数据出来也是为了做进一步处理，比如取出每一分钟的最大值，最小值，均值，方差这一些。

@sagaxu 查询画图展示，长时间的我会额外查询宿友再处理，比如每十分钟提取一个最大值，汇聚所有的值返回。但是归根到底我还是要查询这些时间范围的数据。
@aloxaf 前端查询数据主要是展示，会有额外的需求，不过我还是要单独查询出这些范围的数据做进一步的加工。原始数据是传感器就固定每秒会有数据，传感器一多，每小时打包就不方便了，有时需要上半段，有时候需要下半段，每秒是最好的处理方法。数据会查询很久之前的，需要保持。时序数据库我还在找，发现挺多不怎么合适，总有一两项让我退步🤣

@MoYi123 内存溢出是 node 的问题好像，我试过查询去年某一段时间的数据，他就查询内存栈溢出了。
@sagaxu 数据总量很多，每天 86400 条 json 存入，每次查询返回不定期，就是得根据前端传回的时间范围作为查询条件，有时候会查询去年某一段时间的数据，慢的时候主要是等待很久，数据库的每个集合的 timestamp 字段有做索引。查询代码如下：
// 获取 MongoDB 原生数据库连接
const db = mongoose.connection.db;
// 获取指定的集合
const collection = db.collection(collectionName);
// 构建查询条件
const query = {};
const timestampInt = parseInt(timestamp, 10);
query.timestamp = timestampInt;
// 查询数据
const result = await collection.find(query).toArray();
if (result.length <= 0) {
ctx.status = 200;
ctx.body = { message: 'no data', data: [] };
return;
}

@Oldletter 代码相对来说比较简单，就是传入集合名字，时间范围，就去对应的结合查询，查询代码如上，后端用的 node ，koa 框架，但是我发现 Mongo 的数据迁移不太方便，比如说我要把 a 服务器的某一个库的所有数据转移到 b 服务器的 Mongo 实例中，就不太方便了。

@skallz 范围也大，会查询去年某一个月的所有数据，前端处理不太现实，现在文件跟业务都在一个服务器。
@chihiro2014 我之前看过这个，但是他对 json 格式数据不太友好，部署相对麻烦。
@xiaofsu 看了部分时序数据库，发现部分接口、迁移、数据格式不太方便。
@daxin945 我查查这个数据库看看效果。

好久没上来，向各位前端大佬问好，大学那会粗粗学习过前端三件套，现在工作页面只会改小地方，大框架还是整不来，拉去的模板东西又是太多，整的很难受。这段时间找了一个大佬帮忙写了一下，至少现在完成交差了。前端变化太多了，系统学习起来有点费精神，我也不是很爱钻研的人哈哈哈。现在我转头拥抱会传统的三件套了，让大佬帮忙搭架子，我在里面加东西。确实一点最难的就是 css ，我主要给体制内干活，他们对好看要求比较高，对实用性考虑没那么高，懂得都懂哈哈哈。现在 ai 对小东西改动确实挺好用，不过架子就搭的不好看了。现在整体市场都不好，也流出来很多大佬出来兼职帮忙。非常感谢！！！还得让自己多学习才行，小弟在小公司，什么活都自己干，哭。。。

@linwuhi 是的，前端更新的也快，轮子比后端多好多。
@66beta ui 框架内容太多了，我不要那么多，拿他们改起来费劲。
@ggvoking 是的，后端业务逻辑性好点，特别是物联网，把协议对接好，数据就来了。加上我没啥设计细胞。
@yagamil 是的，兼容性问题，版本问题，各种包的问题。
@hyh0u0 特别要设计的好看，这个更加烦人。
@hefish 前端的框架问题很多，不好说，拉下来按照步骤跑还是有问题，后端的东西拉下来基本都能跑，而且改起来也快。
@vipfts 给的，但是不能太贵了，我需求真的简单，感觉大佬一下午就能搞完。
@mixuxin 我搜索看看，能截图生产这么强的吗。
@AlexHsu 能学习多点好事情，但是学起来很痛苦就烦恼了，后端我只考虑接口，响应设计好，其他就剩优化了。前端页面真的让我难受了。
@eraserrain 我搜索看看。

@yxlcareme 好的，已经添加。
@meteor957 我现在也发现了，前端的模板东西太多了，改起来也很费劲。
@heqingpan 谢谢大佬，我学习学习。
@npe 好，我多看看。
@guanzhangzhang 是的，我看到前端的模板就头大了，里面的内容写的天花乱坠，很多根本用不上呀。
@Heisenberg66 羡慕大佬。
@ybz 我是废了，哈哈哈。
@DongDongProMax 上手了，还要改动，我哭。

@mumbler 好的，我去搜搜看。
@rogwan 确实是强上了，没办法，着急要。
@donaldturinglee 现在我是看 vue3 ，他的坑也不少。react 还没接触过，你有空再请教你。
@tabc2tgacd 是的，css 比较难，特别是要求好看的前提。
@yxlcareme 大佬，最近你有时间吗，我要赶工个项目，几个页面。

现在看市场上也是很多老前端大哥，新人好像不是很多，小弟也是去年刚毕业，干了一年多的后端，一直想学习一下前端，奈何实在难受，有前端大佬有空指教的话，小弟也可以付费咨询学习一下，感谢各位大佬！！！

@tkfe 是的，心态重要，准备找个前端大佬付费学习。
@wqq096737ink 非常杂乱，很难受，特别是各种包，各种版本。我都想撸回 html 三件套了。
@Philippa 太混乱了，而且各个框架也是一堆 bug ，很多模板也是堆了一堆东西进去，我不需要的一大堆，实际用的没几个。

@mumbler 就普通的 gpt ，现在的 4o 越来越傻了。
@lneoi 对啊，就是这个效果，但是后端 ai 还是很清晰给出方案的。
@0xD800 不复杂，唯一难点就是图表展示实时数据，用 echart ，但是结构我不会，折腾了很久。设计感这玩意 css 真的难

@kapaseker css 巨难搞，特别是领导想看到好看的页面效果。
@jdi 最近还要出差去装设备，难顶
@follower 我在开始学了，没办法，没人。项目又着急。
@pckillers 现在就是想找前端大佬写个模板，让我模仿着写。

一样，很难受，我花了很多次时间去看，最后都是不了了知，哭了

@wxf666 我的意思是单表存一个传感器设备的数据，这样相对来说方便后续读取，数据字段可能还会添加。查询这个还好，现在加上了索引，即使我查询前几个月的数据也能够很快就响应了。写入这个问题暂时不管了，mongo 数据库就是吃内存，空间换时间了，还是谢谢大佬的指点，很强，这个测试能力。

@wxf666 哇塞，首先谢谢大佬指点，大佬很强，不好意思，我假期没看论坛。目前我是建了索引，基本上解决问题。看了您的测试，太强了，我深感自己缺少这个精神，汗颜。不过我觉得单表不适合多传感器数据的存储，一开始我就 pass 了，数据太过分散，不方便后续读取维护。sqllite 我看到了乙方存的是记录，他们用文件存数据，然后有记录索引，用起始位置来标记数据，这个方案比较难，对我个人来说；所以就考虑用 mongoDB ，现在确实好用，有了索引查询效率瞬间上来了，之前占用内存大可能因为写入较频繁，每秒实时写入。我现在改成了异步延时写入，一开始存到了 redis 的 list ，然后再去 list 取数据写入到数据库，算是减少了内存消耗。不过大佬的实践很强，有时间我试试该数据库以及您说的方案，再次感谢大佬的指点！！！

@rickiey 这个数据对 MongoDB 还算正常，只是比较吃内存。
@celaraze 是的大佬，目前我给单表的时间戳字段都建立了索引，写入过程需要一直维护这个索引，确实开销大，目前我的写入逻辑是批量写，异步定时每间隔 5 秒写入一批数据，数据接收村存到了 redis 的队列中，后面再从 list 中读取数据入库操作，这里采用了多线程，redis 的分布式锁，保证数据不重复不交叉，暂时应该还好，后续我想着继续把写入逻辑延迟，积累到一定数据量再写入，比如说几百条甚至上万条。小弟目前公司就我一个人，这个项目也是我全程一个人推进的，有点心累，接下来我花时间看看 TDengine 这个数据库，似乎这个还不错，非常谢谢各位大佬提供解决方案，小弟是真的感谢！
@wxiao333 是的，单集合存单传感器分表这个逻辑比较合理，索引就是维护需要系统开销。目前也在关注时序数据库，大佬说的查询那个功能确实比较优秀，接下来会重点花时间去了解时序数据库，目前物联网比较适合这类数据库，不过就是学习成本有点高，公司不等我哈哈哈。

@cavemannb 数据比较多，基本的关系型还是差点意思，同行业的很多公司是直接存文件，这个难度更大一点。查数据方面。
@zglzy 感谢，我查查，数据结构比较稳定。

谢谢各位大佬啦，小弟现在把对应的集合建立了时间戳字段建立了索引，速度立马起来了，优化到几十 ms 级别的查询时间；至于性能这个问题，写入肯定是没有问题，MongoDB 确实很优秀，简单好用；目前唯一的问题就是确实吃内存，这个修改了配置文件的参数目前还是没有办法避免，这个空间换时间确实无法避免；小弟去年刚毕业，来的一家小公司，只有我是搞开发的，领导把整个项目都丢给我了，小弟经验不足，所以有很多不同的地方，还请各位大佬多多指教。

@abcfyk 一个集合 8 万多，有几百个集合。数据库暂时不换了，目前建了索引，发现速度快了。
@wupher 也关心数据，目前加了索引，速度起来了。
@fengpan567 没有用过。

@wenxueywx 还在调研中。
@iyaozhen 目前我知道插入不是问题，目前是查询较慢，现在建立了索引，快起来了。