大家好，我是考100分的小小码 ，祝大家学习进步，加薪顺利呀。今天说一说电商商品搜索 es_正规电商平台有哪些,希望您对编程的造诣更进一步.
- 关系型数据库 ，大多数互联网公司会选用mysql作为关数据库的主选，用于存储商品，用户信息等数据。 关系型数据库对于事务性非常高的OLTP操作(比如订单，结算等)支持良好。
- hadoop生态 ，hadoop是数据仓库主要的载体，除了备份关系型数据库的所有版本，还存储用户行为，点击，曝光，互动等海量日志数据，hadoop对于数据分析，数据挖掘等OLAP支持比关系型数据库更加具有扩展性和稳定性。
- 搜索引擎 ，以elasticsearch和solr为代表。搜索引擎是获取信息最高效的途径，几乎成为各类网站，应用的基础标配设施(地位仅次于数据库)。
目前搜索引擎技术已经有非常成熟的开源解决方案，最出名的ElasticSearch和Solr都是基于lucence的。很多中小型互联网公司搜索引擎都是基于这两个开源系统搭建的，但是即便如此，一个搜索引擎团队想把搜索引擎质量做到商用标准，从系统熟悉，服务搭建，功能定制，通常需要花费较长时间。
通用搜索引擎应用在互联网商用搜索 通常会遇到如下几个问题 ：
- 搜索引擎与公司现有数据系统的集成。mysql 和 hadoop是电商的两个主要数据载体，搜索引擎在全量和增量建索引过程中必须和mysql或hadoop无缝集成，才能发挥搜索引擎自身的实时性，水平扩展性(性能与容量和机器数量成正比)等优势。
- 商用搜索高度定制化与通用搜索引擎的矛盾。商用搜索的问题有时候超越了搜索引擎本身解决的范围，比如商品的去重，店铺的去重需要很专业的搜索引擎使用技巧; 商品的权重，用户意图的识别需要算法和模型的支持。
- 在不了解搜索引擎专业知识的前提下，很难创建对性能友好的索引。结果造成了通用搜索性能很差的假象。
笔者是有赞大数据架构师，从自身的搜索实践出发，分享搜索引擎实际的架构和解决的问题。
搜索引擎架构
有赞搜索引擎实践，上半部分主要介绍搜索引擎的架构和性能优化方面的经验；下半部分是算法篇，介绍有赞实际需要的搜索算法的问题和解决方案。文章仅仅介绍一个中型电商公司实际的使用现状和笔者个人的经验，不代表搜索引擎最佳实践方法，也不代表可以适用所有的场景。
1.技术架构
有赞搜索引擎基于分布式实时引擎elasticsearch(ES)。ES构建在开源社区最稳定成熟的索引库lucence上，支持多用户租用，高可用，可水平扩展；并有自动容错和自动伸缩的机制。我们同事还实现了es与mysql和hadoop的无缝集成；我们自主开发了高级搜索模块提供灵活的相关性计算框架等功能。
2.索引构建
互联网索引的特点是实时性高，数据量大。时效性要求用户和客户的各种行为能够第一时间进入索引；数据量大要求一个有效分布式方案可以在常数时间内创建不断增长的TB数量级索引。
实时索引我们采用 面向队列的架构 ，数据首先写入DB(或文件)，然后通过数据库同步机制将数据流写入kafka队列。这种同步机制和数据库主从同步的原理相同，主要的开源产品有mypipe和阿里推出的canal。es通过订阅相应的topic实现实时建立索引。
如果数据源是文件，则使用flume实时写入Kafka。
另外一个索引问题是全量索引。有如下几个场景让 全量索引是一个必要过程 ：
- 实时更新有可能会丢数据，每次很少的丢失时间长了降低搜索引擎的质量。 周期性的全量更新是解决这个问题的最直接的方法；
- 即使能够保证实时更新，业务的发展有可能有重新建索引的需求(比如增加字段，修改属性，修改分词算法等)。
- 很多搜索引擎是在业务开始后很久才搭建的，冷启动必须全量创建索引。
我们采用 Hadoop-es 利用hadoop分布式的特性来创建索引。hadoop-es让分布式索引对用户透明，就像单机更新索引一样。一个是分布式的数据平台，一个是分布式搜索引擎，如果能把这两个结合就能够实现分布式的全量索引过程。Hadoop-es正式我们想要的工具。
我们给出一个通过Hive sql创建索引的栗子 ：
drop table search.goods_index;CREATE EXTERNAL TABLE search.goods_index (is_virtual int,created_time string,update_time string,title string,tag_ids array) STORED BY ‘org.elasticsearch.hadoop.hive.EsStorageHandler’ TBLPROPERTIES (‘es.batch.size.bytes’=’1mb’,‘es.batch.size.entries’=’0’,‘es.batch.write.refresh’=’false’,‘es.batch.write.retry.count’=’3’,‘es.mapping.id’=’id’,‘es.write.operation’=’index’,‘es.nodes’=’192.168.1.10:9200’,‘es.resource’=’goods/goods’);
系统把es映射成hive的一个外部表，更新索引就像是写入一个hive表一样。实际上所有分布式问题都被系统透明了。
不建议从数据库或文件系统来全量索引。一方面这会对业务系统造成很大的压力，另一方面因为数据库和文件系统都不是真正分布式系统，自己写程序保证全量索引的水平扩展性很容易出问题，也没有必要这么做。
全量索引和增量索引的架构如下图所示。另外一点是hadoop也是订阅kafka备份数据库和日志的。我个人建议一个公司所有DB和文件都存储在hadoop上，这样做起码有二个 好处 ：
- hadoop上使用hive或者spark创建的数据仓库为大数据提供统一的操作接口。
- hadoop数据相对于线上更加稳定，可以作为数据恢复的最后一个防线。
数据仓库的话题不在本篇文章的讨论范围，这里只是简单提一下。
为什么我们选择Kafka？Kafka 是一个以高吞吐著名的消息系统。Kafka开启了日志合并(log compaction)功能后，可以永久保存每条消息。每一条消息都有一个key，正好对应数据库的主键，Kafka始终保存一个key最新的一条消息，历史版本会被垃圾回收掉。有了这个特性，Kafka不仅可以保存数据库最新的快照，而且可以实现实时更新的消息系统。
第一次同步的时候，数据表中每行记录都转化成以主键为key的消息进入Kafka，并且可以被任意数量的broker消费。之后数据库的每次更新(insert，updated，delete)都会被转化成Kafka的消息。如果一行记录频繁被更改，Kafka会识别这些重复的消息，把旧的消息回收掉。
Kafka既保存数据库最新的全量数据，又提供实时数据流的这个特性为架构的可维护性提供极大便捷。如果你想从零扫描整个数据库，你只需要从开始消费这个Kafka的topic即可完成，当读到topic末端，自动获得实时更新的特性。
Kakfa的另一个特性是 支持从任意断点读取数据 ，比如我们全量索引是从HDFS中读取，我们可以根据HDFS保存的数据的最后一条的时间戳，直接切换到Kafka读取之后的数据。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
转载请注明出处: https://daima100.com/10044.html
