目前我们公司存在基础商品大约 300w 个商品.
存在 1k 个客户,每个客户在这 300w 的基础商品里面选大约 200w 的商品.
同一个品,每个客户有不同的价格,上下架状态,库存.
需要支持客户按价格和上下架状态,商品基础信息进行查询.(商品名称要涉及分词)
商品基础信息,上下架状态,价格,库存 日常 会有变动.但是量不会特别大,每天大约 10w 左右变动
大促活动的时候,可能会有大量的变动信息.
需要支持高效写入和高并发查询.目前是用 es 进行支持的.但是当大促的时候,es 写入性能较慢.
请问下各位大佬,还有什么好的技术方案吗?
存在 1k 个客户,每个客户在这 300w 的基础商品里面选大约 200w 的商品.
同一个品,每个客户有不同的价格,上下架状态,库存.
需要支持客户按价格和上下架状态,商品基础信息进行查询.(商品名称要涉及分词)
商品基础信息,上下架状态,价格,库存 日常 会有变动.但是量不会特别大,每天大约 10w 左右变动
大促活动的时候,可能会有大量的变动信息.
需要支持高效写入和高并发查询.目前是用 es 进行支持的.但是当大促的时候,es 写入性能较慢.
请问下各位大佬,还有什么好的技术方案吗?
 |
1
wzwb 8 天前 via Android
ParadeDB
|
 |
2
wangbin11 8 天前
我没登录账号逛 v 站，都的登录上来喷两句，你们的缓存呢中间件呢，全靠 es 撑着啊，es 的集群都多大了
|
 |
3
MADBOB 8 天前
我比较好奇...是做啥的...300w 个商品？ 1k 个客户看着也不像零售呀
|
 |
5
lazyfighter 8 天前
mark es 写入慢跟大促有啥关系，qps 高了，导致写入性能低， 低多少呢
|
 |
7
zgscwjm OP @lazyfighter 大促的时候,商品的基础价格,返点有变化,通过 spark 计算后,全量同步到 es 上,现在写入的过程中,会把 es 集群的 cpu.io 打满.导致其他服务查询 es 的时候超时
|
 |
8
31415926535x 8 天前
一个索引的话拆分索引试试，大促要扩机器
数据变更接受多少的延迟呢，写入可以走 mq 慢慢写么，或者改成批量写入操作 查询的数据需要精确度很高么，金额之类的如果可以忽略个位数，应该可以减少部分写入操作 |
 |
9
yn1024 8 天前
1 、引入 kafka ，把写入变得平滑一些，防止 ES 挂掉（但可能牺牲写入速度）
2 、加一层 redis ，应付高并发查询 3 、把数据（商品信息）做分片，多加几个 ES 实例，不同实例处理不同分片，上面加聚合层 |
 |
10
tidaizhe 8 天前
看起来像是做商超的
|
|
11
zgscwjm OP @31415926535x 多个分片,就是硬件资源有限,拆分索引会冗余存储商品信息.商品的基础变更会被放大.现在是直接用 spark 往 es bluk 写入,会把机器拖死,已经调整了 es 的 refresh_interval,等参数.商品价格,折扣对精度有要求.引入 kafka/mq 中间件这些的之前有考虑过,可以缓解 IO,但是更多的是想在结构上进行调整.
|
 |
12
me1onsoda 7 天前
300w 这个数据量很大吗，需要考虑那么多吗
|
 |
13
SorcererXW 7 天前
10w/天的数据量，qps 才 1 ，活动期间多个数量级算是 10qps ，不太能理解 es 为什么会消费不过来
|
|
15
zgscwjm OP @SorcererXW 大促 100w 的商品变动,要乘以 1000 的客户数.
|
|
19
lazyfighter 7 天前
返点折扣是以商家维度，还是商品维度，感觉是两个场景：
1 根据商家设置返点以及折扣 2 不同商家不同商品设置不同返点以及折扣 按照你的描述共计 300w 商品， 场景猜测： 大概率是商家维度设置整体的商品返点以及折扣，同时可以给商家配置特殊商品折扣。 如果是这种场景的话， 商家维度设置整体的商品返点以及折扣这个写入场景非常少，建立特殊的表存储，其它在查询的时候按照折扣以及返点实时计算筛选条件进行查询 |
 |
20
vivisidea 7 天前
300w 个商品算很少了吧，es 慢是多慢呢？目前 es 的集群是什么配置？多少个节点？ SSD 上了么？
能用硬件解决的，就不折腾了。。说不定比人工还便宜 |
|
21
zgscwjm OP |
 |
22
zzmark06 3 天前
300w 个商品，1000 个客户，sku 总计 30 亿以上，你比 amazon 规模还大。
淘宝十几年，估计也就这数量级吧 都这规模了，要不去硅谷挖几个人吧 哈哈哈哈 |
Select Language