在搜索场景的应用中，存在希望根据某个或某些字段来调整排序评分，从而实现排序沉底或置顶效果的使用需求。以商机管理中的扫街场景为例，当我们在扫街场景中需要寻找一个商户时，希望这个商户离的近、GMV 潜力大、被他人跟进过的次数越少越好。在策略上离的近在排序中的权重要比 GMV 潜力大更大，因为我们希望就近拜访，在距离差不多的情况下优先拜访能带来更多 GMV 的商家。如果这个商家是一个“激励商家”且高转化

在 5 月 24-25 日举办的第十一届 GIAC 全球互联网架构大会中， 火山引擎云原生计算技术负责人-李亚坤 受邀作为 Cloud Native （云原生）专场出品人，带大家深入云原生技术创新及应用，了解随着企业数字化转型步伐的加快，云原生技术如何成为推动敏捷开发、确保高可用性和实现无缝扩展的关键技术手段。Cloud Native（云原生）专场在这场专为技术先锋和创新者设计的专场中，我们将深

本文将以图像搜索应用为例，介绍如何借助火山引擎云搜索服务的解决方案快速开发一个混合搜索应用。

ES 作为一个分布式搜索引擎，从扩展能力和搜索特性上而言无出其右，然而它有自身的弱势存在，其作为近实时存储系统，由于其分片和复制的设计原理，也使其在数据延迟和一致性方面都是无法和 OLTP（Online Transaction Processing）系统相媲美的。也正因如此，通常它的数据都来源于其他存储系统同步而来，做二次过滤和分析的。这就引入了一个关键节点，即 ES 数据的同步写入方式，本文介绍

RocketMQ 是一个典型的发布订阅系统，通过 Broker 节点中转和持久化数据、解耦上下游。Broker 是真实存储数据的节点，由多个水平部署但不一定完全对等的副本组构成，单个副本组的不同节点的数据会达到最终一致。RocketMQ 优异的性能表现，绕不开其优秀的存储模型 。下文将从 RocketMQ 存储机制设计展开介绍。存储机制设计在存储方式上，RocketMQ/Kafka/RabbitM

在大模型席卷全球的行业背景下，基于检索结果增强的文本生成(RAG)备受关注。而作为 RAG 关键技术的向量数据库(VectorDB)正处在发展的一十字路口。为了探讨 VectorDB 的发展趋势、应用场景、上下游技术生态，OpenSearch 社区发起本次「大模型时代下的 VectorDB」Meetup。在本次活动中，您将见到来自于头部企业的向量检索技术研发专家、OpenSearch 社区的活跃贡

在持续建设基于 ES 的跨域数据聚合服务中发现 ES 的很多特性跟 MySQL 等常用数据库差别较大，本文会分享 ES 的实现原理、在直播平台中的业务选型建议及实践中遇到的问题和思考。Elasticsearch 是一种分布式的、近实时的海量数据存储、检索与分析引擎。我们常说的“ELK”就是指 Elasticsearch、Logstash / Beats、Kibana 组成的具备收集、存储、检索和可

在面对众多的消息队列时，我们往往会陷入选择的困境：“消息队列那么多，该怎么选啊？Kafka 和 RabbitMQ 比较好用，用哪个更好呢？”想必大家也曾有过类似的疑问。对此本文将在接下来的内容中以 Kafka 和 RabbitMQ 为例分享消息队列选型的一些经验。消息队列即 Message+Queue，消息可以说是一个数据传输单位，它包含了创建时间、通道/主题信息、输入参数等全部数据；队列（Que

继上文在完成了从千万级到亿级商品量级搜索系统的搭建后，本文将继续介绍一些扩容无法解决的 ES 性能问题，即对相关 ES 搜索引擎的稳定性治理实践。希望通过本文大家可以对 ES 的使用场景有更多数据和使用上的参考。回顾： 从 0 到 1 搭建亿级商品 ES 搜索引擎完成了第一阶段 ES 搜索引擎的搭建后， 随着业务的发展问题也逐渐开始暴露，起源是在某次大促活动下线的时候，ES 集群某个机房 CPU

建设并维护一个亿级的搜索引擎并非易事，也不存在一劳永逸的最优治理方法。本文是在 实践中不断学习和总结的成果， 介绍了 如何搭建一个可支持从千万级到亿级商品量级的搜索系统 ，并实现 查询总 QPS 从百级增长到千级，写入总 QPS 从百级增加到万级 的过程 。其中，ES 资源扩容是必不可少的，但除此之外，本文还将重点介绍一些扩容无法解决的 ES 性能问题。希望通过本文大家可以对 ES 的使用场景有更