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

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

ParadeDB

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

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

@MADBOB toB

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

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

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

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

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