V2EX › zgscwjm 的所有回复 › 第 1 页 / 共 1 页

V2EX = way to explore

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

现在注册

已注册用户请登录

2025 年 1 月 23 日

回复了 zgscwjm 创建的主题 › 数据库 › 大佬们咨询下你们公司的商品信息存储方案.

@vivisidea 300w 要乘以 1000 个客户哦,就是 30 亿数据,全量同步的时候,cpu.io 全部打满.大约 40 分钟的时间内通过 id 查询耗时在 5 秒之上.3 个节点.ssd 上了哦,就是没有资源了.

2025 年 1 月 23 日

回复了 zgscwjm 创建的主题 › 数据库 › 大佬们咨询下你们公司的商品信息存储方案.

@headwindx 会从中根据各种属性进行筛选

2025 年 1 月 22 日

回复了 zgscwjm 创建的主题 › 数据库 › 大佬们咨询下你们公司的商品信息存储方案.

@SorcererXW 大促 100w 的商品变动,要乘以 1000 的客户数.

2025 年 1 月 22 日

回复了 zgscwjm 创建的主题 › 数据库 › 大佬们咨询下你们公司的商品信息存储方案.

@me1onsoda 300w 乘以 1000 客户数

2025 年 1 月 22 日

回复了 zgscwjm 创建的主题 › 数据库 › 大佬们咨询下你们公司的商品信息存储方案.

@31415926535x 多个分片,就是硬件资源有限,拆分索引会冗余存储商品信息.商品的基础变更会被放大.现在是直接用 spark 往 es bluk 写入,会把机器拖死,已经调整了 es 的 refresh_interval,等参数.商品价格,折扣对精度有要求.引入 kafka/mq 中间件这些的之前有考虑过,可以缓解 IO,但是更多的是想在结构上进行调整.

2025 年 1 月 22 日

回复了 zgscwjm 创建的主题 › 数据库 › 大佬们咨询下你们公司的商品信息存储方案.

@lazyfighter 大促的时候,商品的基础价格,返点有变化,通过 spark 计算后,全量同步到 es 上,现在写入的过程中,会把 es 集群的 cpu.io 打满.导致其他服务查询 es 的时候超时

2025 年 1 月 22 日

回复了 zgscwjm 创建的主题 › 数据库 › 大佬们咨询下你们公司的商品信息存储方案.

@wangbin11 缓存这些我理解在这里的场景使用有限吧.

2025 年 1 月 22 日

回复了 zgscwjm 创建的主题 › 数据库 › 大佬们咨询下你们公司的商品信息存储方案.

@MADBOB toB

2024 年 8 月 26 日

回复了 zzzzyg 创建的主题 › NAS › 由于阿里云限速，自己搭了一套 nas，电信千兆网络， 24 小时开机，求一个 PT💊

@Masonn 大佬,同 NAS 新手,24 小时开机,求一个 ,邮箱 :emdzY3dqbUBnbWFpbC5jb20= 感谢