(solr搜索引擎)如何在solr配置文件里添加新的搜索字段？

solr的三个配置文件：1、solrconfig.xml 只配置一次就够了2、data-config.xml 配置数据库与solr搜索的映射关系，需要按实际情况处理3、schema.xml 配置solr搜索字段

对比性能其实很不好回答，因为没有我还不知道有 benchmark做了很深入的，而且没有偏见的性能对比。就实时搜索而言(Near Real Time Search), feature 实现主要是lucene layer. Elasticsearch 比 SOLR 提前实现这个feature。但是现在Solr 也进步了不少，性能差别并没有很大，毕竟底层都是用lucene 和JVM的嘛。 但是因为实现不一样，feature 和 feature 之前性能差别肯定也还是有的。但是不同的use case，性能对比结果也是不一样。而且两个产品都有很多参数可以调试， 结果也就更不一样了。就我个人的理解，毕竟elasticsearch 是2010 年后 才出现的项目，设计和实现上也更加考究，也更容易上手。 Solr的主要问题是直到 solr cloud, 一直并没有 很好的scale 和 做分布式的办法。SolrCloud release之后 bug 又很多。 加之就Elastic 这个产品 Stack 而言，search engine 是一块基石。本身产品内部设计架构强调模块化，使得用户很容易在上面搭建自己的扩展插件 (aws plugin 啥的)。然后 Kibana前台UI 和 Logstash 又给产品找来了很多眼球。我想这是Elasticsearch 现在更流行的原因吧。

solr 的搜索用的是lucene ，如果要全词优先，那么首先在建索引的时候全词得作为一个整词建入索引，也就是分词器需要识别出全词是一个词；其次搜索结果是与tf和idf相关公式计算权值并按照多个字段权值相加结果进行排序的，所以若要排名靠前，要么设计让全词单独作为一个字段存放并给予较高的字段权值，要么自己改写计算公式来达到目的。

首先：技术架构

一般初期的电商网站，基本就几个业务子系统：网站前台、商家前台、系统管理后台、App、M站等。业务量也不是很大。所以，MVC+缓存+数据库基本就搞定了。

其次：基础架构

前端网站和M站，考虑到访问量和系统的可用性，基本会采用分布式部署。通过代理服务器进行请求分发。

其它的业务子系统，像商家前台和管理系统，基本上都是单机或是主从部署。

各个DB，Redis服务和文件和图片服务，搜索引擎Solr服务等，采用主从部署。

第三：详细架构

整个系统架构里面，还有一个比较重要的组成部分，那就是监控系统。例如：流量监控、硬件监控、系统性能监控等， 还有就是对某个页面进行监控，设置页面的其中一块进行监控等。它是提高整个平台可用性的一个重要手段。多平台、多个维度的监控，能够确保系统的可用性。一旦出现异常，特别在硬件或者性能方面出现异常，监控系统也能立刻发出警告，这样也好防范于未然。

索引可以放到solr,但不作存储正向文档正向文档可以放到hbase搜索在solr处理，取数据到hbase取

电商网站架构是一个很需要经验的活，基本需要面对的技术难题有瞬时高并发，稳定性，安全性，支付业务等。

电商网站最高并发的挑战是抢购，如何能抗住抢购的流量高点，不同网站做法有很多，大都方法是过滤请求加使用缓存等方式。

安全性更多是凭借经验来做处理。

拼音搜索，使用一个汉字-拼音的字典来完成。 在关键词库中，每次生成关键词的时候，就在字典中找出汉字对应的拼音，记录在关键词对应的位置。 在收到拼音查询请求后，可以通过找到这些拼音，然后取出对应的汉字关键词，再找到搜索结果。

谢邀，看完这篇文章后可能对你有所帮助。

我们知道，影响一个词在一篇文档中的重要性主要有两个因素：

1 term frequency (tf):该词在当前文档出现了多少次，tf越大，说明越重要。

2 document frequency (df):有多少文档包含该term,该词越大说明太普通了，越不重要。

比如solr一词在文档中出现次数很多，说明这篇这篇文档主要是跟solr有关的；那比如the this it which 诸如此类的词，也很多，但重要吗，很明显不重要，为什么？因为每一篇文档可能都有很多这样的词，所以这时候就是由df来决定了。

计算权重的公式如下：

Wt,d = tft,d * log(n / dft)

Wt,d：词在文档中的权重

tft,d：词在该文档中出现的频率次数

n: 文档总数

dft：包含这个词的文档的数量

当然，不同的系统可能有自己不同的实现。

VSM: 向量空间模型算法

1 我们把文档看做一系列的词

2 每一个词在文档中都有自己的权重

3 不同的词根据自己在文档中的权重来影响文档打分

4 我们把文档中词的权重看做一个向量：

Document Vector = {weight1, weight2, …… ,weight N}

5 我们把Query也用向量表示

Query Vector = {weight1, weight2, …… , weight N}

6 我们把搜索出来的文档向量和query向量放在一个N维空间，每一个term是一个维度。

7 我们认为两个向量之间的夹角越小，相关性越大。所以我们计算夹角的余弦值作为相关性的打分，夹角越小，余弦值越大，打分高，相关性越大

查询语句一般是很短的，包含的词(Term)是很少的，因而查询向量的维数很小，而文档很长，包含词(Term)很多，文档向量维数很大。你的图中两者维数怎么都是N呢？在这里，既然要放到相同的向量空间，自然维数是相同的，不同时，取二者的并集，如果不含某个词(Term)时，则权重(Term Weight)为0

举例子：

查询语句共有3个term, 文档共有5个term

计算2篇文档跟查询语句的相关性打分分别为：

得到的结果第二个比第一个大，所以返回的结果第二个排在第一个前面。

关注我不迷路，我是程序员小樊