大佬们咨询下你们公司的商品信息存储方案.

[zgscwjm]

目前我们公司存在基础商品大约 300w 个商品.
存在 1k 个客户,每个客户在这 300w 的基础商品里面选大约 200w 的商品.
同一个品,每个客户有不同的价格,上下架状态,库存.
需要支持客户按价格和上下架状态,商品基础信息进行查询.(商品名称要涉及分词)
商品基础信息,上下架状态,价格,库存 日常 会有变动.但是量不会特别大,每天大约 10w 左右变动
大促活动的时候,可能会有大量的变动信息.
需要支持高效写入和高并发查询.目前是用 es 进行支持的.但是当大促的时候,es 写入性能较慢.
请问下各位大佬,还有什么好的技术方案吗?

[wzwb]

ParadeDB

[wangbin11]

我没登录账号逛 v 站，都的登录上来喷两句，你们的缓存呢中间件呢，全靠 es 撑着啊，es 的集群都多大了

[MADBOB]

我比较好奇...是做啥的...300w 个商品？ 1k 个客户看着也不像零售呀

[zgscwjm]

@MADBOB toB

[lazyfighter]

mark es 写入慢跟大促有啥关系，qps 高了，导致写入性能低， 低多少呢

[zgscwjm]

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

[zgscwjm]

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

[31415926535x]

一个索引的话拆分索引试试，大促要扩机器
数据变更接受多少的延迟呢，写入可以走 mq 慢慢写么，或者改成批量写入操作
查询的数据需要精确度很高么，金额之类的如果可以忽略个位数，应该可以减少部分写入操作

[yn1024]

1 、引入 kafka ，把写入变得平滑一些，防止 ES 挂掉（但可能牺牲写入速度）
2 、加一层 redis ，应付高并发查询
3 、把数据（商品信息）做分片，多加几个 ES 实例，不同实例处理不同分片，上面加聚合层

[tidaizhe]

看起来像是做商超的

[zgscwjm]

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

[me1onsoda]

300w 这个数据量很大吗，需要考虑那么多吗

[SorcererXW]

10w/天的数据量，qps 才 1 ，活动期间多个数量级算是 10qps ，不太能理解 es 为什么会消费不过来

[zgscwjm]

@me1onsoda 300w 乘以 1000 客户数

[zgscwjm]

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