ElasticSearch

github:https://github.com/exceptionless/Exceptionless docs:https://exceptionless.com/docs/clients/dotnet/sending-events/ docker: docker run -d -p 5050:80 -v D:\docker\esdata:/usr/share/elasticsearch/data exceptionless/exceptionless 使用： app.UseExceptionless(Configuration); 来源： oschina 链接： https://my.oschina.net/u/4334316/blog/4844508

一、背景知识 在Es中，字段的类型很关键： 在索引的时候，如果字段第一次出现，会自动识别某个类型，这种规则之前已经讲过了。 那么如果一个字段已经存在了，并且设置为某个类型。再来一条数据，字段的数据不与当前的类型相符，就会出现字段冲突的问题。如果发生了冲突，在2.x版本会自动拒绝。 如果自动映射无法满足需求，就需要使用者自己来设置映射类型，因此，就需要使用者了解ES中的类型。 下面就步入正题吧！ 二、字段中的索引和存储 其中需要说明的是： 1.index定义字段的分析类型以及检索方式 如果是no，则无法通过检索查询到该字段； 如果设置为not_analyzed则会将整个字段存储为关键词，常用于汉字短语、邮箱等复杂的字符串； 如果设置为analyzed则将会通过默认的standard分析器进行分析， 详细的分析规则参考这里 2.store定义了字段是否存储 在《ES IN ACTION》中有这样一段描述： This might be useful when you ask Elasticsearch for a particular field because retrieving a single stored field will be faster than retrieving the entire _source and extracting that field from

一、简介 1.先看ES的架构图 二、ES支持的客户端连接方式 1.REST API 　　http请求，例如，浏览器请求get方法；利用Postman等工具发起REST请求；java 发起httpClient请求等。 2.Transport 连接 　　socket连接，用官方提供的TransPort客户端，底层是netty。 注意：ES的发展规划中在7.0版本开始将废弃 TransportClient，8.0版本中将完全移除 TransportClient，取而代之的是High Level REST Client。 3. ES提供了多种编程语言客户端 　　 官网可以了解详情： https://www.elastic.co/guide/en/elasticsearch/client/index.html 三、Java REST Client介绍 1. ES提供了两个JAVA REST client 版本 Java Low Level REST Client: 低级别的REST客户端，通过http与集群交互，用户需自己编组请求JSON串，及解析响应JSON串。 兼容所有ES版本 。 Java High Level REST Client: 高级别的REST客户端，基于低级别的REST客户端，增加了编组请求JSON串、解析响应JSON串等相关api。

这些用法是基于elasticsearch6.42 版本测试的不同版本语法有差别 1.创建用户有则覆盖 http://47.105.74.94:9200/department/employee/1 { "first_name" : "姜", "last_name" : "绵岳", "age" : 150, "about" : "I love to go rock climbing", "interests": [ "sports", "music" ] } 返回结果 { "_index": "department", "_type": "employee", "_id": "1", "_version": 2, "result": "updated", "_shards": { "total": 2, "successful": 1, "failed": 0 }, "_seq_no": 1, "_primary_term": 1 } 2.查看用户 http://47.105.74.94:9200/department/employee/1 3.查询 http://47.105.74.94:9200/department/employee/_search 4.分词查找 http://47.105.74.94:9200/department/employee/_search?q=last

前几天工作比较忙没有过来写，今天趁着有点空我来跟大家一起研究一下搜索提示框联想。 先来看看百度的搜索框。非常朴素简单。作为一个搜索引擎，推荐的搜索词只是方便你用来进行 进一步的搜索。 逻辑上给我个人的感觉是10条，那么排序上应该是根据搜索率倒序的前10条记录。 这里能匹配到的数据应该很多，但是如果全部加载进来会显得很长很长，速度还会慢。 Typeahead 的使用 为了提高效率，我选择了个成熟好用的搜索提示框架，由 Twitter 出品的 Typeahead.js。 源码地址： https://github.com/twitter/typeahead.js Typeahead 需要依赖 jQuery 1.9+，我们先创建一个简单的静态页面，名为 index.html。 下载好 jQuery 和 Typeahead 的 JS。 先建个demo页面index.html，内容如下。 基本上给input绑定应该都看的很清晰，找到id=demo下的class=typeahead绑定上方法下面 的hint就是提示，主要的是source：数据源。 var suggestions = ['test1', 'test2', 'test3', 'ceshi1', 'ceshi2', 'ceshi3']; 我这里是写死的，用post可以去后台请求数据源。 那么我来看看效果。 我因为做测试没有加样式

引言 阿里云数据库ClickHouse二级索引功能近日已正式发布上线，主要弥补了ClickHouse在海量数据分析场景下，多维度点查能力不足的短板。在以往服务用户的过程中，作者发现绝大部分用户对ClickHouse单表查询性能优化问题感到无从下手，借此机会，本文会先为大家展开介绍ClickHouse在单表分析查询性能优化上的几个方法，基本涵盖了OLAP领域存储层扫描加速的所有常用手段。在解决过各种各样业务场景下的性能优化问题后，作者发现目前ClickHouse在解决多维搜索问题上确实能力不足，一条点查常常浪费巨大的IO、CPU资源，于是云数据库ClickHouse自研了二级索引功能来彻底解决问题，本文会详细介绍二级索引的DDL语法、几个典型适用场景和特色功能。希望可以通过本文让大家对ClickHouse在OLAP场景下的能力有更深的理解，同时阐述清楚二级索引适用的搜索场景。 存储扫描性能优化 在介绍各类OLAP存储扫描性能优化技术之前，作者先在这里申明一个简单的代价模型和一些OLAP的背景知识。本文使用最简单的代价模型来计算OLAP存储扫描阶段的开销：磁盘扫描读取的数据量。在类似ClickHouse这样纯列式的存储和计算引擎中，数据的压缩、计算、流转都是以列块为单位按列进行的。在ClickHouse中，只能对数据列以块为单位进行定位读取