一、综述
搜索
http://baike.baidu.com/item/ %E6%90%9C%E7%B4%A2/ 2791632#viewPageContent
早期的搜索引擎是把因特网中的资源服务器的地址收集起来，由其提供的资源的类型不同而分成不同的目录，再一层层地进行分类。人们要找自己想要的信息可按他们的分类一层层进入，就能最后到达目的地，找到自己想要的信息（树状结构）。这其实是最原始的方式，只适用于因特网信息并不多的时候。
随着因特网信息按几何式增长，出现了真正意义上的搜索引擎，这些搜索引擎知道网站上每一页的开始，随后搜索因特网上的所有超级链接，把代表超级链接的所有词汇放入一个数据库。这就是现在搜索引擎的原型。
它包括信息搜集、信息整理和用户查询三部分。
发展
随着yahoo!的出现，搜索引擎的发展也进入了黄金时代，相比以前其性能更加优越。现在的搜索引擎已经不只是单纯的搜索网页的信息了，它们已经变得更加综合化，完美化了。以搜索引擎权威yahoo!为例，从1995年3月由美籍华裔杨致远等人创办yahoo!开始，到现在，他们从一个单一的搜索引擎发展到现在有电子商务、新闻信息服务、个人免费电子信箱服务等多种网络服务，充分说明了搜索引擎的发展从单一到综合的过程。
ETL-数据仓库技术
Extraction-Transformation -Loading的缩写，中文名称为数据提取、转换和加载。
http://baike.so.com/doc/ 2126217-2249603.html
ETL，是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取(extract)、转换(transform)、加载(load)至目的端的过程。ETL一词较常用在数据仓库，但其对象并不限于数据仓库。
ETL是构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗,最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。
原理
抓取网页（Extraction）
每个独立的搜索引擎都有自己的网页抓取程序（spider）。Spider顺着网页中的超链接，连续地抓取网页。由于互联网中超链接的应用很普遍，理论上，从一定范围的网页出发，就能搜集到绝大多数的网页。
处理网页（Transformation）
搜索引擎抓到网页后，还要做大量的预处理工作才能提供检索服务。其中，最重要的就是提取关键词，建立索引文件。其他还包括去除重复网页、分析超链接、计算网页的重要度等。
检索服务（Loading）
用户输入关键词进行检索，搜索引擎从索引数据库中找到匹配该关键词的网页；为了用户便于判断，除了网页标题和URL外，还会提供一段来自网页的摘要以及其他信息。
二、搜索引擎
搜索引擎（Search Engine）是指根据一定的策略、运用特定的计算机程序从互联网上搜集信息，在对信息进行组织和处理后，为用户提供检索服务，将用户检索相关的信息展示给用户的系统。搜索引擎包括全文索引、目录索引、元搜索引擎、垂直搜索引擎、集合式搜索引擎、门户搜索引擎与免费链接列表等。
一个搜索引擎由搜索器、索引器、检索器和用户接口四个部分组成。
1.搜索器的功能是在互联网中漫游，发现和搜集信息。
2.索引器的功能是理解搜索器所搜索的信息，从中抽取出索引项，用于表示文档以及生成文档库的索引表。
3.检索器的功能是根据用户的查询在索引库中快速检出文档，进行文档与查询的相关度评价，对将要输出的结果进行排序，并实现某种用户相关性反馈机制。
4.用户接口的作用是输入用户查询、显示查询结果、提供用户相关性反馈机制。
搜索引擎现主要为全文索引和目录索引。垂直搜索引擎由于其在特定领域的更高的用户体验，以及更小的硬件成本，也开始逐渐兴起。
1.分类：
1.1全文搜索引擎
搜索引擎分类部分提到过全文搜索引擎从网站提取信息建立网页数据库的概念。搜索引擎的自动信息搜集功能分两种。
一种是定期搜索，即每隔一段时间（比如Google一般是28天），搜索引擎主动派出“蜘蛛”程序，对一定IP地址范围内的互联网网站进行检索，一旦发现新的网站，它会自动提取网站的信息和网址加入自己的数据库。
另一种是提交网站搜索，即网站拥有者主动向搜索引擎提交网址，它在一定时间内（2天到数月不等）定向向你的网站派出“蜘蛛”程序，扫描你的网站并将有关信息存入数据库，以备用户查询。随着搜索引擎索引规则发生很大变化，主动提交网址并不保证你的网站能进入搜索引擎数据库，最好的办法是多获得一些外部链接，让搜索引擎有更多机会找到你并自动将你的网站收录。
当用户以关键词查找信息时，搜索引擎会在数据库中进行搜寻，如果找到与用户要求内容相符的网站，便采用特殊的算法——通常根据网页中关键词的匹配程度、出现的位置、频次、链接质量——计算出各网页的相关度及排名等级，然后根据关联度高低，按顺序将这些网页链接返回给用户。这种引擎的特点是搜全率比较高
1.2目录索引
目录索引也称为：分类检索，是因特网上最早提供WWW资源查询的服务，主要通过搜集和整理因特网的资源，根据搜索到网页的内容，将其网址分配到相关分类主题目录的不同层次的类目之下，形成像图书馆目录一样的分类树形结构索引。目录索引无需输入任何文字，只要根据网站提供的主题分类目录，层层点击进入，便可查到所需的网络信息资源。
严格意义上，目录索引不能称为搜索引擎。
1.2.1目录索引与搜索引擎的不同
1.搜索引擎为程序自动索引；而目录索引则依赖人为操作。
2.搜索引擎不考虑网站分类，根据关键词网站频率构建搜索索引；而目录索引需要甄别网站的分类目录位置。
3.搜索引擎检索到的信息是程序爬虫自动获取的，没有或少有过滤机制，而目录索引有大量的人为审查过滤机制，因而信息目录构建也相对缓慢。
1.2.2目录索引与搜索引擎的融合
现在的搜索引擎一般也提供分类查询的功能。如Google使用Open Directory目录提供分类查询。在默认搜索模式下，一些目录类搜索引擎首先返回的是自己目录中匹配的网站，如中国的搜狐、新浪、网易等；而另外一些则默认的是网页搜索，如Yahoo。这种引擎的特点是检索的准确率比较高。
1.3垂直搜索引擎
垂直搜索引擎为2006年后逐步兴起的一类搜索引擎。不同于通用的网页搜索引擎，垂直搜索专注于特定的搜索领域和搜索需求（例如：机票搜索、旅游搜索、生活搜索、小说搜索、视频搜索、购物搜索等等），在其特定的搜索领域有更好的用户体验。相比通用搜索动辄数千台检索服务器，垂直搜索具备需要的硬件成本低、用户需求特定、查询的方式多样等优点。比较适合中小型公司和创业型公司的搜索服务。
2.工作原理
按照搜索引擎的定义，一般将其工作原理分为四部分，即爬行，抓取存储，预处理，排名。
2.1爬行（信息获取）
网络搜索引擎通过特定算法的软件，跟踪网页中的超链接，逐层深入链接，逐渐扩张成一张遍布网络。因此，也形象的称之为蜘蛛（Spider）或爬虫。这种软件的爬行，需要遵循一定的规则，按照指定的爬行深度和爬行广度来进行网页爬取。
除了爬取Web之上的资源，可获取的数据库，文本文件，PDF等可解析出文字形成有效数据的信息资源都可以成为爬取的资源。当然，针对不同的文件格式和文档编码，都需要有相对应的文件解析和预处理器配合，才能实现信息的爬取。
2.2抓取存储（信息存储）
搜索引擎将爬虫爬取到的可识别存储信息存储到原始页面数据库中。其中的数据是还未经处理的信息，还不具备数据的有效性，因此还不能称之为数据。
在爬取页面的过程中，爬虫也会对数据进行初步的重复性检测，根据相应的权重以及重复比有选择的爬取页面信息，并忽略被大量转载、抄袭、复制的内容。
2.3预处理（信息-数据）
搜索引擎的预处理器会将爬虫爬取回来的数据进行各种的预处理操作，减小数据音噪比，提炼有效数据。并通过索引器根据指定的索引构建方式构建索引。
一般会进行的预处理包括但不限于：提取文字，特定语种分词（如中文分词），去除停止词，消除噪音（如版权声明文字、导航条、广告等……），链接关系计算，特殊文件处理等。
索引构建一般有正向索引（顺序索引），倒排索引等方式。
2.4排名
搜索引擎会根据多种指标来对根据检索词汇检索到的初步结果进行结果排名。如有名的Google创始人拉里·佩奇的PageRank算法就是Google搜索引擎排名运算法则的一部分。
Google的PageRank根据网站的外部链接和内部链接的数量和质量来衡量网站的价值。PageRank背后的概念是，每个到页面的链接都是对该页面的一次投票，被链接的越多，就意味着被其他网站投票越多。这个就是所谓的"链接流行度"--衡量多少人愿意将他们的网站和你的网站挂钩。PageRank这个概念引自学术中一篇论文的被引述的频度--即被别人引述的次数越多，一般判断这篇论文的权威性就越高。
但是这样的一种排名机制导致后来出现了SEO中的链接销售和交换策略，市场泛滥的同时，也让搜索的准确率不断下降。因此Google通过修改规则，对相关度不高的网页中链接，以及缺乏内容的链接工厂（Link Farm）进行了排除。同时降低了PR值得更新频率，一般一年更新四次，抑制了互联网链接的不正常发展。
当然，Google作为世界上最为著名的搜索引擎（=。=），它的排名算法不仅仅只是PageRank，PR只是它排名规则的一部分而已。
关于排名规则与指标，还有更多其它考虑因素，如网站与网站内容的符合程度等，其中还涉及到反黑帽SEO作弊技术的相关算法规则。
排名作为搜索引擎面向用户接口的重要一环以及一个可获得利益点，在百度的竞价排名规则中表现明显。而Google则遵循其“Don’t be evil”的组织文化原则，根据搜索结果提供更大可能对用户有用的广告产品来获取收益，从而保证了自身搜索引擎排名的公正性和有用性。
排名算法规则和方式自诞生以来就广受争议，站在成本角度考量，要维持一个普适性强的搜索引擎的正常良好运作，需要巨大的人力和机器成本，如果不能从中获取收益，对运行维护公司来说将是巨大的损失。但是在互联网时代虚假消息横行的时代，反虚假、反捏造信息的责任更多的放到了作为互联网网页入口的搜索引擎的身上，促使它们不断的更改自己的算法，添加新的规则，来让用户得到真实有效的信息。
三、Lucene
1.概念
Solr和Elasticsearch都是基于Lucene实现的。
Lucene是apache软件基金会4
jakarta项目组的一个子项目，是一个开放源代码的全文检索引擎工具包，但它不是一个完整的全文检索引擎，而是一个全文检索引擎的架构，提供了完整的查询引擎和索引引擎，部分文本分析引擎（英文与德文两种西方语言）。
Lucene的目的是为软件开发人员提供一个简单易用的工具包，以方便的在目标系统中实现全文检索的功能，或者是以此为基础建立起完整的全文检索引擎。Lucene提供了一个简单却强大的应用程式接口，能够做全文索引和搜寻。在Java开发环境里Lucene是一个成熟的免费开源工具。信息检索程序库，虽然与搜索引擎有关，但不应该将信息检索程序库与搜索引擎相混淆。
全文搜索引擎：国外具代表性的有Google、Fast/AllTheWeb、AltaVista、Inktomi、Teoma、WiseNut等，国内著名的有百度（Baidu）。
2.倒排索引
http://baike.baidu.com/item/ %E5%80%92%E6%8E%92% E7%B4%A2%E5%BC%95/ 11001569#reference- [2]-676861-wrap
2.1概念
倒排索引源于实际应用中需要根据属性的值来查找记录。这种索引表中的每一项都包括一个属性值和具有该属性值的各记录的地址。由于不是由记录来确定属性值，而是由属性值来确定记录的位置，因而称为倒排索引(inverted index)。
2.2应用背景
在关系数据库系统里，索引是检索数据最有效率的方式,。但对于搜索引擎，它并不能满足其特殊要求:
1)海量数据:搜索引擎面对的是海量数据，像Google，百度这样大型的商业搜索引擎索引都是亿级甚至百亿级的网页数量，面对如此海量数据,使得数据库系统很难有效的管理。
2)数据操作简单:搜索引擎使用的数据操作简单,一般而言,只需要增、删、改、查几个功能,而且数据都有特定的格式,可以针对这些应用设计出简单高效的应用程序。而一般的数据库系统则支持大而全的功能,同时损失了速度和空间。最后,搜索引擎面临大量的用户检索需求,这要求搜索引擎在检索程序的设计上要分秒必争,尽可能的将大运算量的工作在索引建立时完成,使检索运算尽量的少。一般的数据库系统很难承受如此大量的用户请求,而且在检索响应时间和检索并发度上都不及我们专门设计的索引系统。
2.3概念辨析
2.3.1倒排列表
利用倒排索引方式构建而成的单词与文档的映射，其中文档部分的结构就是倒排列表。
倒排列表用来记录有哪些文档包含了某个单词。一般在文档集合里会有很多文档包含某个单词，每个文档会记录文档编号（DocID），单词在这个文档中出现的次数（TF）及单词在文档中哪些位置出现过等信息，这样与一个文档相关的信息被称做倒排索引项（Posting），包含这个单词的一系列倒排索引项形成了列表结构，这就是某个单词对应的倒排列表。
在实际的搜索引擎系统中，并不存储倒排索引项中的实际文档编号，而是代之以文档编号差值（D-Gap）。文档编号差值是倒排列表中相邻的两个倒排索引项文档编号的差值，一般在索引构建过程中，可以保证倒排列表中后面出现的文档编号大于之前出现的文档编号，所以文档编号差值总是大于0的整数。之所以要对文档编号进行差值计算，主要原因是为了更好地对数据进行压缩，原始文档编号一般都是大数值，通过差值计算，就有效地将大数值转换为了小数值，而这有助于增加数据的压缩率。
2.3.2倒排索引
https://zh.wikipedia.org/wiki/ %E5%80%92%E6%8E%92%E7%B4%A2%E5%BC%95
倒排索引（Inverted index），也常被称为反向索引、置入档案或反向档案，是一种索引方法，被用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射。它是文档检索系统中最常用的数据结构。通过倒排索引，可以根据单词快速获取包含这个单词的文档列表。倒排索引主要由两个部分组成：“单词词典”和“倒排文件”。
倒排索引有两种不同的反向索引形式：
一条记录的水平反向索引（或者反向档案索引）包含每个引用单词的文档的列表。
一个单词的水平反向索引（或者完全反向索引）又包含每个单词在一个文档中的位置。
后者的形式提供了更多的兼容性（比如短语搜索），但是需要更多的时间和空间来创建。
现代搜索引擎的索引都是基于倒排索引。相比“签名文件”、“后缀树”等索引结构，“倒排索引”是实现单词到文档映射关系的最佳实现方式和最有效的索引结构。
2.3.2.1构建方法
构建方法有简单法和合并法两种。
简单法：
索引的构建相当于从正排表到倒排表的建立过程。当我们分析完网页时,得到的是以网页为主码的索引表。当索引建立完成后,应得到倒排表,流程描述如下：
1）将文档分析成单词term，
2）使用hash去重单词term
3）对单词生成倒排列表
倒排列表就是文档编号DocID，没有包含其他的信息（如词频，单词位置等），这就是简单的索引。
这个简单索引功能可以用于小数据，例如索引几千个文档。然而它有两点限制：
1）需要有足够的内存来存储倒排表，对于搜索引擎来说，都是G级别数据，特别是当规模不断扩大时,我们根本不可能提供这么多的内存。
2）算法是顺序执行，不便于并行处理。
合并法：
归并法，即每次将内存中数据写入磁盘时，包括词典在内的所有中间结果信息都被写入磁盘，这样内存所有内容都可以被清空，后续建立索引可以使用全部的定额内存。
合并流程：
1）页面分析，生成临时倒排数据索引A，B，当临时倒排数据索引A，B占满内存后，将内存索引A，B写入临时文件生成临时倒排文件，
2)对生成的多个临时倒排文件,执行多路归并,输出得到最终的倒排文件(
inverted file)。
索引创建过程中的页面分析,特别是分词为主要时间开销。算法的第二步相对很快。这样创建索引算法的优化就集中在分词效率上了。
2.3.2.2更新策略
更新策略有四种：完全重建、再合并策略、原地更新策略以及混合策略。
1）完全重建策略：当新增文档到达一定数量，将新增文档和原先的老文档整合，然后利用静态索引创建方法对所有文档重建索引，新索引建立完成后老索引会被遗弃。此法代价高，但是主流商业搜索引擎一般是采用此方式来维护索引的更新。
2）再合并策略：当新增文档进入系统，解析文档，之后更新内存中维护的临时索引，文档中出现的每个单词，在其倒排表列表末尾追加倒排表列表项；一旦临时索引将指定内存消耗光，即进行一次索引合并，这里需要倒排文件里的倒排列表存放顺序已经按照索引单词字典顺序由低到高排序，这样直接顺序扫描合并即可。其缺点是：因为要生成新的倒排索引文件，所以对老索引中的很多单词，尽管其在倒排列表并未发生任何变化，也需要将其从老索引中取出来并写入新索引中，这样对磁盘消耗是没必要的。
3）原地更新策略：试图改进再合并策略，在原地合并倒排表，这需要提前分配一定的空间给未来插入，如果提前分配的空间不够了需要迁移。实际显示，其索引更新的效率比再合并策略要低。
4）混合策略：出发点是能够结合不同索引更新策略的长处，将不同索引更新策略混合，以形成更高效的方法。
四、Solr
http://www.importnew.com /12707.html
搜索总体上划分为两个过程索引和搜索。
1.索引(Indexing)
Sorl/Lucene采用的是方向索引方式，即从关键词到文档的映射过程。
通过构建关键词和文档之间的关系，在查询关键词的过程中能够快速定位文档位置。
索引创建步骤：
1.1索引文档词条化（文档Document-词汇单元Token）
把原始待索引文档内容交给分词组件（Tokenizer），分词组件通过Tokenize过程将文档分解为词汇单元（Token）。
其中Tokenize过程包含这些操作：
1.将文档分成单词
2.去除文档中的标点符号
3.去除停词（Stop word）（停词，即语言之中的助词，谓语等没有实际含义的词。例：英语中的“a”，“the”，中文中的“啊”，“唉”，“之”，“乎”，“者”，“也”等）
1.2语言分析再处理（词汇单元Token-词Term）
此过程是语言处理组件（Linguistic Processor）对词汇单元Token的再处理工作，通常是根据不同的语种来进行相应的特性处理，如英语语种会进行的操作：变为小写（Lowercase），单词缩为词根形式（stemming），单词转变为词根形式（Lemmatization）等。
词汇单元Token经过此过程处理后的到词（Term）
1.3倒排索引构建索引库
此过程会由索引组件（Indexer）将上一步的词Term与文档Document之间建立索引关系，从而形成索引库。在这个过程中索引组件会对所有的词进行创建词典，排序，和合并相同词等操作，从而保证可检索词的唯一性。
索引库中包含了一下几列：词（Term），文档频率（Document Frequency），文档中则拥有文档ID（Document ID），频率（Frequency）。其中：
词（Term），即为构建索引库后要检索的关键词。而它对应的文档频率则表明这个词在多少篇文档中出现了。
文档中的文档ID用来和词链接，从而能根据词索引到文档，而频率则说明了，所搜索的词在该文档中出现的次数。
2.搜索（Search）
搜索是面向用户接口的主要操作，对检索的处理是搜索技术是否能够达到预期效果的重要一步。
技术原理核心-空间向量模型
https://zh.wikipedia.org/wiki/ %E5%90%91%E9%87%8F%E7%A9% BA%E9%96%93%E6%A8%A1%E5%9E%8B
我们在构建索引时，将文档切分为Term，那么当我们要根据关键词或者语句进行检索时，怎么通过语句来寻找Term，再通过Term来找到对应的文档呢？
反过来想，根据面向文档的思想，其实用户界面输入的关键词也是一篇文档。那么当我们使用构建索引的操作对关键词进行分词构建索引之后，通过这些索引去搜索匹配索引数据库中的索引，就可以找到相对应的结果了。
而匹配搜索之后我们需要根据关键词和各文档之间的相关性进行排序，这时候之前对关键词构建的索引又派上了用场。这里我们就可以使用空间向量模型算法来评价文档结果集中的文档的索引和关键词索引之间的相关性了。
这个过程，其实就是寻找在两篇文档中，哪些词对文档之间关系的更重要，哪些最重要，主要文档中的词在待匹配文档中出现频率的高低的过程，这个判断关键词的Term对文档的Term的重要性的过程称为计算词的权重（Term Weight）的过程。
计算词的权重有两个参数：一是词（Term），二是文档（Document）。词的权重表示此词在文档中的重要程度，越重要的词有越大的权重，因为i在计算文档之间的相关性中将发挥更大的作用。
向量空间模型算法就可以用来判断词之间的关系，从而量化得到文档之间的相关性。
1.计算权重（Term Weight）的过程
影响一个词(Term)在一篇文档中的重要性主要有两个因素：
1）Term Frequency (tf)：即此Term在此文档中出现了多少次。tf越大说明越重要。
2）Document Frequency
(df)：即有多少文档包含次Term。df越大说明越不重要。
当一个Term在某篇文档中出现的次数越多，即tf越大，说明文档的主要工作都是在介绍或者重点引用这个概念，那么他们之间的相关性也就越高，权重越大。而当很多的文档都包含这一个Term时，这个Term对文档的区分性就越差，即通过df指标非常大的Term更不能区分出文档之间的相关性，所以表现为权重越不重要。
上公式即为计算权重的一个简单典型，实际情况可能会有不同，但基本比相同。
2.判断Term之间的关系从而得到文档相关性的过程，也即向量空间模型（VSM）的算法
我们把文档看做一系列Term，通过和关键词文档的Term的计算，每一个词都获得了一个权重，通过空间向量模型算法，根据这些权重，来为不同词与文档的相关性计算打分。
我们把文档中的词的全助攻看做一个向量：
Document = {term1, term2, …… ,term N}
Document Vector = {weight1, weight2, ……,weight N}
也同样把关键词看做一个文档，用向量来表示它们：
Query = {term1, term 2, …… , term N}
Query Vector = {weight1, weight2, …… ,weight N}
把所有搜索出来的文档向量以及查询向量放到一个N维空间中，每个Term是一个维度。向量空间的维度数取二者的Term集合的并集。
当两个向量之间的夹角，即余弦值越小，我们就人为他们的相关性越大，所计算得到的相关性得分也就越高。相关性的分值计算公式如下：通过将关键词文档与检索结果集中的各文档的打分分值，进行降序排序，就得到了这个关键词检索后的具有相关性排序的结果列表。
2.1对查询内容进行词法分析、语法分析、语言处理
词法分析，即区分查询内容中的单词与关键字。关键字例如：“and”，“not”等。
语法分析，通过语法分析将查询单词与关键字区分开来之后，根据定义好的语法规则，形成语法树。
语言处理，类似于索引阶段的语言分析处理部分，将包含数量和时态等属性的单词转变为它的原型词。例：“bananas”的原型词为“banana”，“gone”或“went”的原型词为“go”。
2.2搜索索引，得到符合语法树的文档集合
将经过词法分析、语法分析、语言处理过后的语法树，在构建好的索引库中进行随机查询，初步得到所有符合语法树的文档集合。
2.3根据查询语句与文档的相关性，对结果进行排序
相关性处理详见“技术原理核心-控件向量模型”一节。
实际应用中，相关性的计算因素不只有文档分词权重，在商业化运营中，如百度就发展出了相当丰富的如竞价排名的更多的相关性计算因素。
相关性的技术原理是空间向量模型，其本身也具有一些局限性：
1.不适用于较长的文档，因为它的相似值不理想（过小的内积和过高的维数）。
2.检索词组必须与文档中出现的词组精确匹配；词语子字串可能会导致“假阳性”匹配。
3.语义敏感度不佳；具有相同的语境但使用不同的词组的文档不能被关联起来，导致“假阴性匹配”。
4.词组在文档中出现的顺序在向量形式中无法表示出来。
5.假定词组在统计上是独立的。
6.权重是直观上获得的而不够正式。
因此，在相关性排序时，可以利用其它的数学技术如奇异值分解或词汇数据库的方式对算法局限进行弥补。
五、ElasticSearch
1.相关概念
1.1集群-节点
单个节点可以作为一个运行中的Elasticsearch的实例。而一个集群是一组拥有相同cluster.name的节点，他们能一起工作并共享数据，还提供容错与可伸缩性。(当然，一个单独的节点也可以组成一个集群)
多节点组成的集群拥有冗余能力，它可以在一个或几个节点出现故障时保证服务的整体可用性。
1.2面向文档（DO）
在应用程序中对象很少只是一个简单的键和值的列表。通常，它们拥有更复杂的数据结构，可能包括日期、地理信息、其他对象或者数组等。
也许有一天你想把这些对象存储在数据库中。使用关系型数据库的行和列存储，这相当于是把一个表现力丰富的对象挤压到一个非常大的电子表格中：你必须将这个对象扁平化来适应表结构--通常一个字段对应一列而且又不得不在每次查询时重新构造对象。
Elasticsearch是面向文档的，意味着它存储整个对象或文档。Elasticsearch不仅存储文档，而且索引每个文档的内容使之可以被检索。在Elasticsearch中，你对文档进行索引、检索、排序和过滤，而不是对行列数据。这是一种完全不同的思考数据的方式，也是Elasticsearch能支持复杂全文检索的原因。
1.3索引的概念
名词关系：
集群-索引-类型-文档-属性：
一个Elasticsearch集群可以包含多个索引，相应的每个索引可以包含多个类型。这些不同的类型存储着多个文档，每个文档又有多个属性。
索引（名词）：如前所述，一个索引类似于传统关系数据库中的一个数据库，是一个存储关系型文档的地方。
索引（动词）：索引一个文档就是存储一个文档到一个索引（名词）中以便它可以被检索和查询到。这非常类似于SQL语句中的INSERT关键词，除了文档已存在时新文档会替换旧文档情况之外。
倒排索引：关系型数据库通过增加一个索引比如一个B树（B-tree）索引到指定的列上，以便提升数据检索速度。Elasticsearch和Lucene使用了一个叫做倒排索引的结构来达到相同的目的。
默认的，一个文档中的每一个属性都是被索引的（有一个倒排索引）和可搜索的。一个没有倒排索引的属性是不能被搜索到的。
1.4分片(Shard)和副本(Replica)
ES的“分片(shard)”机制可将一个索引内部的数据分布地存储于多个节点，它通过将一个索引切分为多个底层物理的Lucene索引完成索引数据的分割存储功能，这每一个物理的Lucene索引称为一个分片(shard)。
每个分片其内部都是一个全功能且独立的索引，因此可由集群中的任何主机存储。创建索引时，用户可指定其分片的数量，默认数量为5个。
Shard有两种类型：primary和replica，即主shard及副本shard。
Primary shard用于文档存储，每个新的索引会自动创建5个Primary
shard，当然此数量可在索引创建之前通过配置自行定义，不过，一旦创建完成，其Primary shard的数量将不可更改。
Replica shard是Primary Shard的副本，用于冗余数据及提高搜索性能。
特点：
1.每个Primary shard默认配置了一个Replica
shard，但也可以配置多个，且其数量可动态更改。ES会根据需要自动增加或减少这些Replica shard的数量。
2. ES集群可由多个节点组成，各Shard分布式地存储于这些节点上。
3. ES可自动在节点间按需要移动shard，例如增加节点或节点故障时。简而言之，分片实现了集群的分布式存储，而副本实现了其分布式处理及冗余功能。
2.原理示意图
著名的开源程序Lucene是索引组件，它提供了搜索程序的核心索引和搜索模块，例如图中的“Index”及下面的部分；而ElasticSearch则更像一款搜索组件，它利用Lucene进行文档索引，并向用户提供搜索组件，例如“Index”上面的部分。二者结合起来组成了一个完整的搜索引擎。
3.深入知识讨论
3.1ES的精确值（Exact Values）和全文（full-text）类型
ES的数据可被广义的分为两种类型：“types:exact”和“full-text”。
精确值(Exact values)就是指数据未曾加工过的原始值，而Full-text则用于引用文本中的数据。
在查询中，精确值是很容易进行搜索的，但full-text则需要判断文档在“多大程度上”匹配查询请求，换句话讲，即需要评估文档与给定查询的相关度(relevant)。
所谓的full-text查询通常是指在给定的文本域内部搜索指定的关键字，但搜索操作需要真正理解查询者的目的。为了完成此类full-text域的搜索，ES必须首先分析文本并将其构建成为倒排索引(inverted index)，倒排索引由各文档中出现的单词列表组成，列表中的各单词不能重复且需要指向其所在的各文档。
3.2倒排索引
倒排索引的原理在第三部分2小节已经介绍，这里主要介绍ES下的构建分词过程。
3.2.1分析
如上一小节所讲，倒排索引构建完成之后的索引要保证能够完成full-text的搜索工作，那么在构建索引过程中进行对应的分词（Tokenization）操作就是必要的过程。这个过程会将文档中域的值切分为独立的单词（Term或Token）。
知道了搜索所使用的空间向量模型原理后，我们知道，要在搜索结果完成后进行相应的匹配，那么在构建索引和搜索时构建索引的过程中，使用的分词语法规则必须是统一的，一致的。在ES中，这个过程叫做正规化（Normalization）。通过将数据统一为一个标准格式，从而方便搜索匹配以及结果相关性的衡量。
这里的分词（Tokenization）以及正规化（Normalization）也称为分析（Analysis）。
分析过程有两个步骤的操作组成，都由指定的分析器（Analyzers）完成：
1）首先，将文本切分为Term以适合构建倒排索引；
2）其次，将各Term正规化为标准格式以提升其“可搜索度”。
3.2.2分析器
一个分析器通常由三个组件构成：字符过滤器(Character filters)、分词器(Tokenizer)和分词过滤器(Token filters)组成。
字符过滤器(Character
filters)：在文本被切割之前进行清理操作，例如移除HTML标签，将&替换为字符等；
分词器(Tokenizer)：将文本切分为独立的词项；简单的分词器通常是根据空白及标点符号进行切分；
分词过滤器(Token
filters)：转换字符(如将大写转为小写)、移除词项(如移除a、an、of及the等)或者添加词项(例如，添加同义词)；
Elasticsearch内置了许多字符过滤器、分词器和分词过滤器，用户可按需将它们组合成“自定义”的分析器。
固然，创建倒排索引时需要用到分析器，但传递搜索字符串时也可能需要分析器，甚至还要用到与索引创建时相同的分析器才能保证单词匹配的精确度。
执行full-text域搜索时，需要用到分析器，但执行精确值搜索时，查询过程不会分析查询字符串而是直接进行精确值匹配。
3.3ES的数据查询
查询执行过程通常要分成两个阶段，分散阶段及合并阶段。分散阶段是向所查询的索引中的所有shard发起执行查询的过程；合并阶段是将各shard返回的结果合并、排序并响应给客户端的过程。
向ElasticSearch发起查询操作有两种方式：一是通过RESTful request API传递查询参数，也称“query-string”；另一个是通过发送REST request body，也称作JSON格式。而REST形式的请求保证了ES可以做到跨平台和跨语言。
ES的查询语句称为Query DSL，它分为两种：查询DSL(query DSL)和过滤DSL(filter
DSL)。
两种DSL的区别：
1）就使用场景来说，当执行full-text查询或查询结果依赖于相关度分值时应该使用查询DSL，当执行精确值(extac-value)查询或查询结果仅有“yes”或“no”两种结果时应该使用过滤DSL。
2）Filter
DSL计算及过滤速度较快，且适于缓存，因此可有效提升后续查询请求的执行速度。而query DSL不仅要查找匹配的文档，还需要计算每个文件的相关度分值，因此为更重量级的查询，其查询结果不会被缓存。不过，由于倒排索引方式的缘故，一个仅返回少量文档的简单query或许比一个跨数百万文档的filter执行起来并不显得更慢。
3）Queries用于查询上下文，而filters用于过滤上下文，不过，Elasticsearch的API也支持此二者合并运行。组合查询可用于合并查询子句，组合过滤用于合并过滤子句，然而，Elasticsearch的使用习惯中，也常会把filter用于query上进行过滤。不过，很少有机会需要把query用于filter上的。
4.主要特性：
1.实时文档存储，文档对象的每个field都建立了索引，都能被检索
2.构建适应于不同规模的应用的体系结构，在此之上实现分布式搜索。
3.为其他平台系统提供了具有rest风格的原生java api。也有hadoop的依赖包
4.简单可用性强，不需要对搜索原理有深入的理解。平台有免费模式。
具有可伸缩性，灵活的构建和易用性。提供一个易用性的平台，进行规模扩展时无需考虑核心功能与用户自定义选项间妥协。
5.应用
使用厂商：Dell、ebay、Fackbook、netflix等。
应用场景：热点图，交通情况地理信息图等需要实时数据搜索和显示的场景，数据更新频繁的场景等。
1）2013年初，GitHub抛弃了Solr，采取ElasticSearch来做PB级的搜索。“GitHub使用ElasticSearch搜索20TB的数据，包括13亿文件和1300亿行代码”。
2）维基百科：启动以elasticsearch为基础的核心搜索架构。
3）SoundCloud：“SoundCloud使用ElasticSearch为1.8亿用户提供即时而精准的音乐搜索服务”。
4）百度：百度目前广泛使用ElasticSearch作为文本数据分析，采集百度所有服务器上的各类指标数据及用户自定义数据，通过对各种数据进行多维分析展示，辅助定位分析实例异常或业务层面异常。目前覆盖百度内部20多个业务线（包括casio、云分析、网盟、预测、文库、直达号、钱包、风控等），单集群最大100台机器，200个ES节点，每天导入30TB+数据。
另外，新浪，阿里，有赞等著名公司也开始了ES方面的技术研发和实践。
六、Solr和ElasticSearch的不同
1.Solr利用Zookeeper进行分布式管理；而Elasticsearch自身带有分布式协调管理功能;
2.Solr支持更多格式的数据json，XML等；而Elasticsearch仅支持json文件格式；
3.Solr官方提供的功能更多；而Elasticsearch本身更注重于核心功能，高级功能多由第三方插件提供；
4.Solr在传统的搜索应用中表现好于Elasticsearch，但在处理实时搜索应用时效率明显低于Elasticsearch。
5.Solr是传统搜索应用的有力解决方案，但Elasticsearch更适用于新兴的实时搜索应用。 |
