V2EX › iamtuzi3333 的所有回复 › 第 2 页 / 共 5 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5

❮

❯

91 天前

回复了 iamtuzi3333 创建的主题 › 数据库 › 大佬们，想请教一下数据库设计

@lancelock 有一个关键字段就是数组，里面有 200 个元素，就是拆除 200 个 key 对应 value 么
@LieEar 开源的 influxdb 想试试，刚看了一下，发现还行，就是要拆数据字段，不知道查询效果怎么样，比如说多传感器能不能多表存储，就一个传感器一张表

91 天前

回复了 iamtuzi3333 创建的主题 › 数据库 › 大佬们，想请教一下数据库设计

@sagaxu 数据不是追加的，每秒都会有新的数据入库，设备数据采集频率很高，所以数据很多，比如说 200Hz ，就说明每秒都有一条数据出来，其中的 data 数组就存储了 200 个浮点数，这种情况下如何编写索引，遍历随着数据量增长，到后面基本没办法找去年的数据出来了。

91 天前

回复了 iamtuzi3333 创建的主题 › 数据库 › 大佬们，想请教一下数据库设计

@sunxvvv 现在有一个字段是 int 整形，存储的是当前时间戳的值，每条写入的时候都有会，这样子适合建立吗，真实查询数据的场景不是很多，偶尔需要查询。
@halov 直接占了快 60G ，同时他的 mapper file 会持续上涨，备用内存全是这个内容，导致可用内存最后剩下不到 100M ，服务器 192GB 的内存都给干满了。
@Mithril 是的，不涉及修改，就是现在数据入库我为了查询方便，就加了一个字段，这个字段存的值就是当前时间戳的值。
@encro 唉，难受，这个确实没办法完美解决，而且其他数据库适合存的情况下接口又不方便。哭了

91 天前

回复了 iamtuzi3333 创建的主题 › 数据库 › 大佬们，想请教一下数据库设计

@celaraze 我先搜一下，只有我一个人，顶着公司走，难受。。。
@Desdemor 似乎接口有点复杂，我先看看。
@zhazi 好的，我先去试试优化，其实 MongoDB 存是非常的方便，就是吃内存很严重，即使修改了配置文件的内容。

91 天前

回复了 iamtuzi3333 创建的主题 › 数据库 › 大佬们，想请教一下数据库设计

@yoyolichen 数据字段是一个值吗，就一个时间字段映射一个值？现在麻烦的就是字段特别多，不同的类型也多，有数组这些。

91 天前

回复了 iamtuzi3333 创建的主题 › 数据库 › 大佬们，想请教一下数据库设计

@celaraze 数据是 loT 。但是时序数据库一个麻烦的点就是我没有找到有很好的字段支持，很多时序数据库都是一个时间点对应一个值，我的数据字段比较多，还有数组类型在里面，不好处理。
@seedhk 时间戳的值会一直变，这样索引更新不是更加消耗资源吗，单表数据量目前是 600 多万条文档了，每天 8 多万增加。

91 天前

回复了 iamtuzi3333 创建的主题 › 数据库 › 大佬们，想请教一下数据库设计

@corcre 一个点位的一个数的话时序数据库很方便，但是数据就很麻烦，我之前找过 influxdb ，感觉不太行。

91 天前

回复了 iamtuzi3333 创建的主题 › 数据库 › 大佬们，想请教一下数据库设计

@celaraze 文档的字段都是一致的，估计是，因为文档数量非常的多，每秒一条，一天有 8 万多条了。

91 天前

回复了 iamtuzi3333 创建的主题 › 数据库 › 大佬们，想请教一下数据库设计

@celaraze 索引没建立，我是按照一个时间戳字段去查询，这个值一直在变，没法用索引吧。
@flmn 我查一下这个。

94 天前

回复了 iamtuzi3333 创建的主题 › MongoDB › 大佬们，大问题请教，内存占满

@juvenn 我目前就是使用的 WiredTiger 引擎，然后数据模型都是 JSON ，插入的时候我特地转为 JSON 插入，查询的实时性要求性不高，现在招人初步判断就是因为写入数据速度太慢，跟不上接收数据的速度，导致全部堆积在内存中。

97 天前

回复了 iamtuzi3333 创建的主题 › MongoDB › 大佬们，大问题请教，内存占满

@Haku 参数都按不死，疯狂吃，吃的只剩下十几 M 可用，内存一看全是映射文件占着茅坑。

97 天前

回复了 iamtuzi3333 创建的主题 › MongoDB › 大佬们，大问题请教，内存占满

@AlanBrian 现在这个 MongoDB 用的社区版本，然后是 Window server 服务器，就是直接启动。
@Moyyyyyyyyyyye 小公司就一台服务器，没办法。
@xsi640 时序我看了一番，没发现有很合适的，主要是字段不方便存，很多时序数据库都是支持字段单值存储，我的数据字段重点是一个数组。

97 天前

回复了 iamtuzi3333 创建的主题 › MongoDB › 大佬们，大问题请教，内存占满

重要的业务场景就是存储不同传感器设备数据，保障完整性，可用性，然后一个需求就是能够方便查询数据，这也是我为什么想单个传感器单表存储，传感器数量多，数据比较高频，字段比较多，有没有大佬指点一下这方面改用啥时候好用一点，后台用 nodejs 或者 Java 写查询功能多一点。目前公司就我一个人顶着，有点难顶，还请各位大佬指教，服务器用的 Window server ，华为云服务器，配置不会太差，此前有个项目有 600 多个传感器，也用的 MongoDB ，一启动内存就慢慢被占用满，导致可用内存越来越少，影响其他项目运行。数据除了存库还有个写入文件保存，目前初步排查是因为写入速度跟不上接入速度，导致数据跟文件全部堆积在内存中。

97 天前

回复了 iamtuzi3333 创建的主题 › MongoDB › 大佬们，大问题请教，内存占满

@bcllemon 时序数据库我还在找，但是数据是 JSON 对象，关键的字段 data 是一个数组，时序数据库大部分是存单个值，不太符合。
@KingPL 目前是还在找。
@975779964 目前传感器会有几百个，然后数据格式都是 JSON ，其中设备不同，字段也不同，然后传感器每秒上传数据，其中数据有多个字段，其中一个字段是数组，存的元素比较多，几百个，目前看了 influxdb ，他好像只支持单值存储，还有其他好推荐的吗。每个传感器单表就是不想多传感器数据混合在一起，最多的业务场景就是突然要查询某一段的历史数据。
@ktonline 这个全称是啥，大佬指点一下。

97 天前

回复了 iamtuzi3333 创建的主题 › MongoDB › 大佬们，大问题请教，内存占满

@yinft 我限制了，但是还是用的很严重。
@AlanBrian 但是现在备用内存疯狂涨，把可用压榨到十几 M 了，我看了内存占用里面，备用内存中全是他的 mapper 映射文件，用量太厉害了。
@jason56 我用的新版本，就是这个引擎，内存设定的是 50 多 G ，
@pangdundun996 已经改了，但是效果不明显。
@GodIsJasonBourne 这个新版已经是这个设置，参数设置的 50 多 G 。

97 天前

回复了 iamtuzi3333 创建的主题 › MongoDB › 大佬们，大问题请教，内存占满

@yinft 羡慕，咱们没人去搞 docker ，项目也是能 run 就行

97 天前

回复了 iamtuzi3333 创建的主题 › MongoDB › 大佬们，大问题请教，内存占满

@wheat0r 原来这样子，那看来还是机器的问题了。
@ShuA1 那看来就是配置的问题了。现在这个问题比较难处理，难顶，现在准备更换存储方式了。

98 天前

回复了 iamtuzi3333 创建的主题 › MongoDB › 大佬们，大问题请教，内存占满

@wheat0r 这个倒不会，同台服务器上面有个 sqlserver ，MySQL ，上面也是存了大量数据，但是未发现有这么吃内存，而且现在发现 mongo 太迟了，他的底层是内存映射（ Memory-Mapped Files ）来处理数据库文件，目的是尽可能将数据库数据加载到内存中以提高读写性能。MongoDB 默认会尽量使用可用的内存来缓存数据文件和索引，因此当数据集较大时，mongod.exe 可能会占用大量内存。
现在这是个无底洞，而且不会自动清除映射文件，全是占用在备用内存中，导致可用内存越来越少。现在我在想找新的数据库来替换了。

98 天前

回复了 iamtuzi3333 创建的主题 › MongoDB › 大佬们，大问题请教，内存占满

目前项目我停掉了，占用太多了，估计 mongo 就是吃内存，这个似乎是他原本就这么设计的。

98 天前

回复了 iamtuzi3333 创建的主题 › MongoDB › 大佬们，大问题请教，内存占满

@pxllong 复制了一条，大概就是这样
insert query update delete getmore command dirty used flushes vsize res qrw arw net_in net_out conn time
*0 *0 *0 *0 0 0|0 0.0% 0.0% 0 6.49G 255M 0|0 0|0 111b 59.8k 6 Sep 19 19:25:06.463
*0 *0 *0 *0 0 1|0 0.0% 0.0% 0 6.49G 255M 0|0 0|0 112b 59.9k 6 Sep 19 19:25:07.463
*0 *0 *0 *0 0 0|0 0.0% 0.0% 0 6.49G 255M 0|0 0|0 111b 59.8k 6 Sep 19 19:25:08.463
*0 *0 *0 *0 0 0|0 0.0% 0.0% 0 6.49G 255M 0|0 0|0 111b 59.8k 6 Sep 19 19:25:09.464
*0 *0 *0 *0 0 1|0 0.0% 0.0% 0 6.49G 255M 0|0 0|0 112b 59.9k 6 Sep 19 19:25:10.463
*0 *0 *0 *0 0 4|0 0.0% 0.0% 0 6.49G 255M 0|0 0|0 514b 60.8k 6 Sep 19 19:25:11.463
*0 *0 *0 *0 0 0|0 0.0% 0.0% 0 6.49G 255M 0|0 0|0 111b 59.8k 6 Sep 19 19:25:12.464
*0 *0 *0 *0 0 0|0 0.0% 0.0% 0 6.49G 255M 0|0 0|0 111b 59.8k 6 Sep 19 19:25:13.464
*0 *0 *0 *0 0 1|0 0.0% 0.0% 0 6.49G 255M 0|0 0|0 112b 59.9k 6 Sep 19 19:25:14.464
*0 *0 *0 *0 0 2|0 0.0% 0.0% 0 6.49G 255M 0|0 0|0 321b 60.5k 6 Sep 19 19:25:15.464

1 2 3 4 5

❮

❯