世界中心的专栏

ElasticSearch 包含nested字段类型，该类型的出现主要是由于对象数组类型的操作往往不能如我们预期，这主要是因为在Lucene内部没有对象的概念，所以ES将层级的JSON数据转化成扁平的键值对列表形式。例如文档：PUT my_index/my_type/5{ "owner" : "小李", "family" : [ { "call" : "dad

1. ES官方文档，可作为参考手册。https://www.elastic.co/guide/en/elasticsearch/reference/master/cat-master.html2..NET开发 使用APIhttps://github.com/Yegoroff/PlainElastic.Net3.Elasticsearch 权威指南http://learn

IK Analyzer 3.0特性 采用了特有的"正向迭代最细粒度切分算法"，具有80万字/秒的高速处理能力采用了多子处理器分析模式，支持：英文字母（IP地址、Email、URL）、数字（日期，常用中文数量词，罗马数字，科学计数法），中文词汇（姓名、地名处理）等分词处理。优化的词典存储，更小的内存占用。支持用户词典扩展定义针对Lucene全文检索优化的查询分析器IKQuer

MMSEG是中文分词中一个常见的、基于词典的分词算法（作者主页：http://chtsai.org/index_tw.html），简单、效果相对较好。由于它的简易直观性，实现起来不是很复杂，运行速度也比较快。关于算法的原文，可以参 见：http://technology.chtsai.org/mmseg/总的来说现在的中文分词算法，大概可以笼统的分为两大类：一种基于词典的，一种是非基于

ES可以使用三种类型的高亮：the lucene highlighter  fast-vector-highlighter postings-highlighte高亮显示的前提要求：1.高亮的字段是存储的，store set to true 2.如果前提1不满足，会从source中提取，但是必须保证 source set to enable3._al

Kibana+Logstash+Elasticsearch 日志查询系统目录(?)[+]https://www.loggly.com/日志的分析和监控在系统开发中占非常重要的地位，系统越复杂，日志的分析和监控就越重要，常见的需求有:根据关键字查询日志详情监控系统的运行状况统计分析，比如接口的调用次数、执行时间、成功率等异常数据自动触发消息通知

logstash日志分析的配置和使用      logstash是一个数据分析软件，主要目的是分析log日志。整一套软件可以当作一个MVC模型，logstash是controller层，Elasticsearch是一个model层，kibana是view层。      首先将数据传给logstash，它将数据进行过滤和格式化（转成JSON格式），然后传给Elastics

Java 内存溢出（java.lang.OutOfMemoryError）的常见情况和处理方式总结java.lang.OutOfMemoryError这个错误我相信大部分开发人员都有遇到过，产生该错误的原因大都出于以下原因：JVM内存过小、程序不严密，产生了过多的垃圾。导致OutOfMemoryError异常的常见原因有以下几种：内存中加载的数据量过于庞大，如一次从数据库取

原文链接：http://my.oschina.net/secisland/blog/636213?fromerr=1lO0Yxc3在Elasticsearch中非常多的插件，这些插件主要分成以下几类：API插件，报警插件，分析插件，发现插件，管理和站点插件，映射器插件，脚本插件，安全插件，快照/恢复插件，传输插件。有很多新版本都不支持，本文介绍的插件基本都可以在新版本上使用。 

安全——免费插件 Search GuardSearch Guard 简介Search Guard是一个Elasticsearch的AAA plugin，特性包括：权限控制粒度可以到indices, types，甚至可以到过滤field层次。也可以限制用户行为，read, write, admin;提供多种HTTP认证方式，包括Basic, Proxy header, SPNEGO/

GET _search{ "_source": { "include": ["title.Value","dataType","_score"] }, "query": { "bool": { "should": [ { "query_string": { "default_field": "t

setting中的通用属性Store该属性的取值可以为yes和no，用于指定字段的原始属性是否存入索引。默认值是no.意味着不能在结果中返回字段的原始值（即使没有存储原始值，也可以使用Soure字段返回原始值）。如果已经建立索引可以搜索该字段的内容。ElasticSearch默认是存储整个文件的，如果要改变这种情形的话可以设置：“_source”:{"enable":"false"}P

在SqlServer等结构化的数据库中通常使用geometry 或者是 geoGraphy 。在数据中的类型如下： .NET对其操作 通过使用EF中的DbGeometry类型进行映射，并且包含对其的多种属性和操作。基本可以满足我们通用的需求。在EF中，该类型的定义如下：这虽然满足，.net程序，对于空间数据的基本使用和操作。但是由于目前我们使用的数据存储服务器为Elas

5 ways to synchronize data from MongoDb to ElasticSearchElastic search(ES) is a pop-star for recording and analyzing data, and Mongodbis a famous NoSQL database for storing and querying data

跨域请求：ES服务器安装部署成功之后从另外一个域的浏览器访问ES服务器数据，会出现跨域的问题。抛出错误：No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access. The response ha

Dictionary ConfigurationIKAnalyzer.cfg.xml can be located at {conf}/analysis-ik/config/IKAnalyzer.cfg.xml or {plugins}/elasticsearch-analysis-ik-*/config/IKAnalyzer.cfg.xml IK Analyzer 扩展配置

小知识：ElasticSearch默认分词器的配置。已知ES默认的分词器是标准分词器Standard。如果需要修改默认分词器可以做如下设置： 在配置文件config/elasticsearch.yml中添加  index.anlysis.analyzer.default.type:ik。当然在ik5.0.0中还是有些许的变化IK5.0.0：移除名为ik的analyzer和tok

_all字段_all字段是一个特殊的获得全部的字段，它连接其他所有字段的值到一个大的字符串当中，并用分隔符分开。该字段被索引和分词，但是不被存储。这就意味着他可以被搜索但是不能被获取。_all字段不在_source字段中，同时默认不存储，所以不可以高亮，可以在mapping的时候设置store：true。_all字段默认是启用的，也可以在 mapping 的时候关闭，如下设

NESTelasticsearch的官方高级.NET客户端。 它旨在成为一个坚实，强类型的客户端，具有非常简洁的API。内部使用低级Elasticsearch.Net客户端的高级客户端使用流畅的接口和对象初始化器语法来映射对强类型对象的请求和响应带有一个非常强大的查询DSL，与Elasticsearch一一对应利用.NET特性（它们有意义）（即，协变的IEnumerable 结果类

准备测试用例，JSON文档{ "testdate" : ISODate("2016-12-13T16:11:03Z"), "testname" : "石头"}{ "testdate" : ISODate("2016-12-13T16:11:03Z"), "testname" : "肖晓琨"}{ "testdate" : ISODate("2016-12-13

X-Pack是一个Elastic Stack的扩展，将安全，警报，监视，报告和图形功能包含在一个易于安装的软件包中。在Elasticsearch 5.0.0之前，您必须安装单独的Shield，Watcher和Marvel插件才能获得在X-Pack中所有的功能x-pack 安装步骤如下：1. 在ES5.0安装 X-PACKbin/elasticsearch-plugin install

这次我们直接实践出发，讲一下几种Update API 的使用方式 以及 修改的结果首先建一个新的index 和 type ，并写入一些基本的测试数据POST index/type/_bulk{"index":{"_id":1}}{"example": "data", "timestamp": "2016-06-21T18:48:55.560+0000" }{"index":{"_id

2016年10月26号正式发布，感觉ES越来越强大了呢，今天是十一月的开始，ES 5.0 学习开始……windows 下载zip 文件下载地址：https://www.elastic.co/downloads/elasticsearch下载之后解压，点击 /elasticsearch-5.0.0目录下面的 elasticsearch.bat 启动ES服务然后访问http://l

DSL Changessearch_type=count 去除（removed）。替换为设置size=0search_type=scan 去除（removed）。替换为 {"sort":["_doc"]}shard count limit search exists 去除（removed）。替换为{"size":0,"terminate_after":1}Mapping

声明使用版本：MongoDB         version 3.0.4ElasticSearch   version 1.6.0Python             version 2.7.10 使用其自带的pip 安装 Mongo-connectorMongoDB同步数据到ElasticSearch首先确保database---> index  coll

ELK（ElasticSearch  logstash  kibana）系统默认并不含有用户认证功能，基本上任何人都可以随意读写ElasticSearch的API并获取数据，这时该如何对ELK系统做好防护工作呢？可以使用shield 保护ES平台并兼权限控制那么shield 是什么呢？Shield是Elastic公司为ElasticSearch开发的一个安全插件。在安装

最近在做ES部署，却发现相同的ES安装包，在不同的服务器上有的可以跑，有的不可以跑出现的错误，如下所示：来自于ES启动日志说是不支持安装的几个分词器插件，但是之前命名在这个服务器的环境中是可以跑通的，只不过最近对分词器插件加载词库进行自定义，通过配置文件读取数据库中的词条来作为分词的词库。难道是这个原因，一看能跑通的服务器上的JDK版本是：jdk-8u51-wind

1. ES2.X  plugin1、rivers所有的rivers都在2.x版本总不再支持，所以mongoDB的数据同步无法再通过rivers进行同步。https://www.elastic.co/blog/deprecating-rivers根据官方的文档显示，解决的办法一是通过已有的各客户端软件（如elasticsearc-net）进行迁移。【当然这里肯定速度肯定会比较慢，可以

根据索引文档的地理坐标来进行搜索，Elasticsearch 也能够处理这样的搜索。——空间搜索一、为空间搜索准备映射PUT my_space_test{ "mappings": { "poi": { "properties": { "name": { "type": "string" }, "l

function_score查询function_score查询是处理分值计算过程的终极工具。它让你能够对所有匹配了主查询的每份文档调用一个函数来调整甚至是完全替换原来的_score。实际上，你可以通过设置过滤器来将查询得到的结果分成若干个子集，然后对每个子集使用不同的函数。这样你就能够同时得益于：高效的分值计算以及可缓存的过滤器。它拥有几种预先定义好了的函数：

根据过滤子集来提升(Boosting Filtered Subsets)回到在忽略TF/IDF(Ignoring TF/IDF)中处理的那个问题，我们需要根据每个度假酒店拥有的卖点数量来对它们的相关度分值进行计算。我们希望利用缓存的过滤器来影响分值，而function_score则正好可以实现该目标。在目前的例子中，我们为所有的文档都使用了一个函数。现在我们希望使用过滤器将

部分匹配(Partial Matching)敏锐的读者可能已经发现到目前为止，介绍的查询都是在整个词条层面进行操作的。匹配的最小单元必须是一个词条。你只能找到存在于倒排索引(Inverted Index)中的词条。但是如果你想匹配词条的一部分，而不是整个词条呢？部分匹配(Partial Matching)允许用户指定词条的一部分然后找到含有该部分的任何单词。匹配词条一部分这

控制相关度(Controlling Relevance)对于仅处理结构化数据(比如日期，数值和字符枚举值)的数据库，它们只需要检查一份文档(在关系数据库中是一行)是否匹配查询即可。尽管布尔类型的YES|NO匹配也是全文搜索的一个必要组成，它们本身是不够的。我们还需要知道每份文档和查询之间的相关程度。全文搜索引擎不仅要找到匹配的文档，还需要根据相关度对它们进行排序。全

索引期间的优化(Index-time Optimizations)目前我们讨论的所有方案都是在查询期间的。它们不需要任何特殊的映射或者索引模式(Indexing Patterns)；它们只是简单地工作在已经存在于索引中的数据之上。查询期间的灵活性是有代价的：搜索性能。有时，将这些代价放到查询之外的地方是有价值的。在一个实时的Web应用中，一个额外的100毫秒的延迟会难以承受

通配符和正则表达式查询wildcard查询和prefix查询类似，也是一个基于词条的低级别查询。但是它能够让你指定一个模式(Pattern)，而不是一个前缀(Prefix)。它使用标准的shell通配符：?用来匹配任意字符，*用来匹配零个或者多个字符。以下查询能够匹配包含W1F 7HW和W2F 8HW的文档：GET /my_index/address/_search

通过查询结构调整相关度ES提供的查询DSL是相当灵活的。你可以通过将单独的查询子句在查询层次中上下移动来让它更重要/更不重要。比如，下面的查询：quick OR brown OR red OR fox我们可以使用一个bool查询，对所有词条一视同仁：GET /_search{ "query": { "bool": { "sh

Lucene中的Practical Scoring Function对于多词条查询(Multiterm Queries)，Lucene使用的是布尔模型(Boolean Model)，TF/IDF以及向量空间模型(Vector Space Model)来将它们结合在一起，用来收集匹配的文档和对它们进行分值计算。像下面这样的多词条查询：GET /my_index

忽略TF/IDF有时我们不需要TF/IDF。我们想知道的只是一个特定的单词是否出现在了字段中。比如我们正在搜索度假酒店，希望它拥有的卖点越多越好：WiFi花园(Garden)泳池(Pool)而关于度假酒店的文档类似下面这样：{ "description": "A delightful four-bedroomed house with ... " }

查询期间的即时搜索(Query-time Search-as-you-type)现在让我们来看看前缀匹配能够如何帮助全文搜索。用户已经习惯于在完成输入之前就看到搜索结果了 - 这被称为即时搜索(Instant Search, 或者Search-as-you-type)。这不仅让用户能够在更短的时间内看到搜索结果，也能够引导他们得到真实存在于我们的索引中的结果。比如，如果用户

空间搜索在聚合中的使用直接上代码： "aggs": { "aggs_geopoint": { "geo_distance": { "field": "location", "origin": { "lat": 51.5072222, "lon": -0.1275 },