06 | 如何用Elasticsearch构建商品搜索系统？

Hi，我是李玥。 还是在这里回顾一下上节课的思考题： 2PC也有一些改进版本，比如3PC、TCC这些，它们大体的思想和2PC是差不多的，解决了2PC的一些问题，但是也会带来新的问题，实现起来也更复杂，限于篇幅我们没法每个都详细地去讲解。在理解了2PC的基础上，课后请你自行去学习一下3PC和TCC，然后对比一下，2PC、3PC和TCC分别适用于什么样的业务场景？ 谈一下我的理解： 3PC相比于2PC做了两个改进，一是事务执行器也增加了超时机制，避免我们课程中提到的因为协调者宕机，导致执行器长时间卡死的问题，另外，3PC在2PC之前增加一个询问阶段，这个阶段事务执行器可以去尝试锁定资源（但不等待），这样避免像2PC那样直接去锁定资源，而资源不可用的情况下，一直等待资源而卡住事务的情况。 TCC可以理解为业务层面的2PC（也有观点主张TCC和2PC是完全不同的，我个人建议没必要在这些概念上较真，理解并正确使用才是关键），TCC同样分为Try和Confirm/Cancel 两个阶段，在Try阶段锁定资源，但不执行任何更新操作，Confirm阶段来执行所有更新操作并提交，如果失败进入Cancel阶段。Cancel阶段就是收拾烂摊子，把Confirm阶段做的数据更新都改回去，把Try阶段锁定的资源都释放。相比于2PC，TCC可以不依赖于本地事务，但是Cancel阶段的业务逻辑比较难实现。

因为用户每输入一个字都可能会发请求查询搜索框中的搜索推荐。所以搜索推荐的请求量远高于搜索框中的搜索。es针对这种情况提供了suggestion api，并提供的专门的数据结构应对搜索推荐，性能高于match，但它应用起来也有局限性，就是只能做前缀匹配。再结合pinyin分词器可以做到输入拼音字母就提示中文。如果想做非前缀匹配，可以考虑Ngram。不过Ngram有些复杂，需要开发者自定义分析器。比如有个网址www.geekbang.com，用户可能记不清具体网址了，只记得网址中有2个e，此时用户输入ee两个字母也是可以在搜索框提示出这个网址的。以上是我在工作中针对前缀搜索推荐和非前缀搜索推荐的实现方案。

老师，我刚刚问的那个问题，我这边找到了一个方案，但不知道是否是业界用的方案，还请老师指点一下 全文检索要把 title 的 type 设置为 text 前缀推荐要把 title 的 type 设置为 completion 想同时支持全文检索和前缀匹配推荐如何做？ 用 fields mapping 文件如下 PUT sku { "mappings": { "properties": { "sku_id":{ "type": "long" }, "title":{ "type": "text", "analyzer": "ik_max_word", "search_analyzer": "ik_max_word", "fields": { "title_suggest":{ "type":"completion" } } } } } } 支持全文检索 GET sku/_search?pretty { "query": { "match": { "title": "苹果手机" } } } 支持前缀匹配 POST sku/_search?pretty { "size":0, "suggest": { "suggester": { "prefix": "烟台", "completion": { "field": "title.title_suggest" } } } }

老师，es除了做搜索，还有哪些业务场景可以使用呢？能简单列举下吗？

李sir我还想再问下，根据我们不同的业务，选分词插件有啥讲究没？虽有点跑题，但是能不能简单说下，感谢~

李老师好，请问下ES在做深度分页查询时的场景下有什么好的方案么

老师您好，是否可以做一些电商这种海量数据下，后台管理系统存储方面的最佳实践。还有对于不同系统之间的数据同步，也希望得到一些比较好的实践方案或者工具。 以下是比较具体的点： 我在上家公司也是做电商系统的，不过我负责的是后台商品数据的维护系统。前台可以用各种缓存来提速，但是对于后台系统，该如何让系统变得比较快？尤其是后台管理系统往往会涉及大批量商品的价格，库存之类的更新，并且更新后业务团队希望能实时看到他们更新成功了，而且有不少更新的操作对丢数据的容忍度比较低，这种情况下缓存也很难做，所以想得到一些对于这种大批量数据后台管理系统的实践经验。 对于数据同步，主要是有的原始数据存储在传统数据库，而为了速度，会存储到一些no sql产品做缓存，但是我们在实践中，经常会有一些丢数据，或者未能及时同步的情况发生，希望能得到这方面的一些经验分享。

老师 您说的二次查找是指在第一次的查找结果中继续查找吗

老师，针对订单中心的表数据，业务库用mysql，同步到es做查询时，比如一个订单主表，关联5个子表，在es存的时候是以嵌套的形式存一个index，还是mysql一张表，对应es的一个index，然后维护父子关系？或者有更好的方案

用ES有两个问题，1.它不适合多索引关联，就像关系数据库的多表关联，那关系数据库多表关联查询的情况是不是建一张中间表，把中间表的数据导入到es 2.要做到准实时的要求，有没有好的方式