由于传统的 mysql 数据库并不擅长海量数据的检索，当数据量到达一定规模时（估算单表两千万左右），查询和插入的耗时会明显增加。同样，当需要对这些数据进行模糊查询或是数据分析时，MySQL作为事务型关系数据库很难提供良好的性能支持。使用适合的数据库来实现模糊查询是解决这个问题的关键。

但是，切换数据库会迎来两个问题，一是已有的服务对现在的 MySQL 重度依赖，二是 MySQL 的事务能力和软件生态仍然不可替代，直接迁移数据库的成本过大。我们综合考虑了下，决定同时使用多个数据库的方案，不同的数据库应用于不同的使用场景。而在支持模糊查询功能的数据库中，elasticsearch 自然是首选的查询数据库。这样后续对业务需求的切换也会非常灵活。

那具体该如何实现呢？在又拍云以往的项目中，也有遇到相似的问题。之前采用的方法是在业务中编写代码，然后同步到 elasticsearch 中。具体是这样实施的：每个系统编写特定的代码，修改 MySQL 数据库后，再将更新的数据直接推送到需要同步的数据库中，或推送到队列由消费程序来写入到数据库中。

但这个方案有一些明显的缺点：

• 系统高耦合，侵入式代码，使得业务逻辑复杂度增加
• 方案不通用，每一套同步都需要额外定制，不仅增加业务处理时间，还会提升软件复复杂度
• 工作量和复杂度增加

在业务中编写同步方案，虽然在项目早期比较方便，但随着数据量和系统的发展壮大，往往最后会成为业务的大痛点。

伴随整个政采云搜索业务的发展，商品总量也从千万级别快速膨胀到亿级别，伴随商品量的增长，带来的是索引体积的快速膨胀，进而导致ES 集群面临越来越严重的 io 读取瓶颈。

作为一家搜索引擎公司，我们会很倚赖 ES 帮忙处理包括文章召回，数据源划分，实体、标签管理等任务，而且都收到了不错的结果。

最近我们需要对行业知识库进行建模，其中可能会涉及到实体匹配、模糊搜索、向量搜索等多种召回和算分方式，最终我们选择了通过 ES 7.X （最终选择 7.10）里的新功能，Dense vector 帮忙一起完成这部分的需求。

本文结合ES在贝壳找房的房源搜索、小区搜索、看点信息流等应用的实践经验，介绍ES的相关性计算原理，以及如何对相关性调优。

Elasticsearch 是一个开源的分布式 RElasticsearchTful 搜索引擎，作为一个分布式、可扩展、实时的搜索与数据分析引擎，它可以快速存储、搜索和分析大量数据。

本文翻译自QBox官方博客“Elasticsearch性能调优权威指南”系列文章的第一篇。

随着腾讯云 Elasticsearch 云产品功能越来越丰富，ES 用户越来越多，云上的集群规模也越来越大。我们在日常运维工作中也经常会遇到一些由于前期集群规划不到位，导致后期业务增长集群规模大了之后带来的各种各样的集群可用性及稳定性问题。

QBox在其博客上发布的系列文章之一，本文是该系列的第三篇。

本文梳理了Elasticsearch对于数值索引实现方案的升级和优化思考。

es怎么配置可以把请求日志都打印出来。就是不管是调用借口，还是kibana查询数据，es能打印dsl的请求日志。

Elasticsearch 自动补全的检索方式一网打尽。

搜索商品A的SPUCodeText编码：OWBB050，slop设置为49-54无法查询出该商品；slop设置为55及其以上的值，才可以查询出商品A。

从某种角度上说，ES是十分易用的，利用ES完成一些基本的写入和查询操作，只需要简单看下文档就能学会。但是ES又有很多配置可以自定义，当你有实际的业务需要时，如何能有效利用现有的资源达到比较好的时延和吞吐量确又非常困难。本文就聊一下分片（shard）和副本（replica），来看看究竟应该如何选择一个合适的分片和副本数。

问题1：bool 组合嵌套过深。

问题2：大量使用 wildcard 查询。

问题3："track_total_hits": 2147483647 没有必要搞这么大？

问题4：track_scores 确认是否必要使用！

问题5："_source": {"includes": [ 确认是否必须

问题6：match，match_phrase, wildcard 都混合使用，考虑分词问题解决。

问题7：建议线上使用复杂DSL，可以使用性能测试验证一下。

美团基于Run-Length Encoding（RLE）设计了一款高效的倒排索引结构，使检索耗时（TP99）降低了84%。

In this blog, we discuss how we power real-time search for Tweets, Users, Direct Messages and more using Elasticsearch.