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

ParadeDB

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

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

toB

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

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

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

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

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

看起来像是做商超的

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

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

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

300w 乘以 1000 客户数

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

用户也不会同时查看 300w 个商品信息吧？

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

参考 9 楼说的很清楚了

返点折扣是以商家维度，还是商品维度，感觉是两个场景：
1 根据商家设置返点以及折扣
2 不同商家不同商品设置不同返点以及折扣
按照你的描述共计 300w 商品， 场景猜测：
大概率是商家维度设置整体的商品返点以及折扣，同时可以给商家配置特殊商品折扣。
如果是这种场景的话， 商家维度设置整体的商品返点以及折扣这个写入场景非常少，建立特殊的表存储，其它在查询的时候按照折扣以及返点实时计算筛选条件进行查询

300w 个商品算很少了吧，es 慢是多慢呢？目前 es 的集群是什么配置？多少个节点？ SSD 上了么？

能用硬件解决的，就不折腾了。。说不定比人工还便宜