lucene

ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。 Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是第二流行的企业搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。 建立一个网站或应用程序，并要添加搜索功能，令我们受打击的是：搜索工作是很难的。希望我们的搜索解决方案要快，希望有一个零配置和一个完全免费的搜索模式，我们希望能够简单地使用JSON通过HTTP的索引数据，我们希望我们的搜索服务器始终可用，我们希望能够一台开始并扩展到数百，我们要实时搜索，我们要简单的多租户，我们希望建立一个云的解决方案。Elasticsearch旨在解决所有这些问题和更多的问题。 ElasticSearch的Schema与其它DB比较： ElasticSearch三方访问方式: 环境是 CentOS 6.4，安装方法有好几种，在这儿我们直接从官网下载包, 1.71版解压后，进入目录执行: bin/elasticsearch 检查服务是否正常工作 curl -X GET http://localhost:9200/ elasticsearch默认是9200端口，返回一个JSON数据，有版本说明运行正常。 elasticsearch的伸缩性很高

作者： 骚年编程去 ，发表于2015年4月 转载自：http://blog.csdn.net/a837199685 一面 IO模型有哪些？（linux下的io模型，当时没答上，后来下去查了一下，阻塞，非阻塞，io复用，驱动，同步，异步等） 进程线程的区别 不同操作系统实现进程怎么样（ps:我还真不知道，以后要好好看看OS了） gc算法，回收器有哪些（这个答得不错，标记-整理，标记-清理，复制，分代，cms收集器的并行这些说了一下） ACID。事务隔离机制（一致性，原子性，隔离性，持久性，读未提交，读提交，可重复读，序列化） syn在方法上和代码块有什么不同（作用域，和锁对象） memcached和其他nosql的区别（拿memcached和redis做了一下比较） 解释mvc threadlocal解释（结合源码的threadmap讲了一下） volatile的作用（内存可见性，内存屏障，重排序，happens-before） 堆和栈的区别和联系（自由发挥啊） tcp和udp的不同之处（面向链接，是否可靠等） tcp如何保证可靠的（超时重传，ack确认，滑动窗口，连接管理，差错控制等） 数组和链表的区别（先说说数据结构上的区别，然后结合java的两个类的源码做了一些分析） 排序算法应用场景（。。。。。这个比较简单） lucene全文检索原理（分词过滤，filter等，） 二面

每天早上 七点三十 ，准时推送干货 Hello 大家好，我是鸭血粉丝，大家都叫我阿粉，搜索引擎想必大家一定不会默认，我们项目中经常使用的 ElasticSearch 就是一种搜索引擎，在我们的日志系统中必不可少，ELK 作为一个整体，基本上是运维标配了，另外目前的搜索引擎底层都是基于 Lucene 来实现的。 阿粉最近遇到一个需求，因为数据量没有达到需要使用 ElasticSearch 的级别，也不想单独部署一套集群，所以准备自己基于 Lucene 实现一个简易的搜索服务。下面我们一起来看一下吧。 背景 **Lucene **是一套用于全文检索和搜索的开放源码程序库，由 Apache 软件基金会支持和提供。Lucene 提供了一个简单却强大的应用程序接口，能够做全文索引和搜索。Lucene 是现在最受欢迎的免费 Java 信息检索程序库。 上面的解释是来自维基百科，我们只需要知道 Lucene 可以进行全文索引和搜索就行了，这里的索引是动词，意思是我们可以将文档或者文章或者文件等数据进行索引记录下来，索引过后，我们查询起来就会很快。 索引这个词有的时候是动词，表示我们要索引数据，有的时候是名词，我们需要根据上下文场景来判断。新华字典前面的字母表或者书籍前面的目录本质上都是索引。 接入 引入依赖 首先我们创建一个 SpringBoot 项目，然后在 pom 文件中加入如下内容

在一个大数据团队中，大数据架构师主要关注的 核心问题就是技术架构选型问题 。架构选型问题一般会受到哪些因素的影响呢？在我们的实践中，一般大数据领域架构选型最受以下几个因素影响： 数据量级 这一点在大数据领域尤其是一个重要的因素。不过从根本上讲，数据量级本身也是一种业务场景的衡量。数据量级的不同往往也就昭示着业务场景的不同。 业务需求 经验丰富的大数据架构师能够从纷繁的业务需求中提炼出核心技术点，根据抽象的技术点选择合适的技术架构。主要的业务需求可能包括：应用实时性要求、查询的维度和灵活程度、多租户、安全审计需求等等。 维护成本 这一点上大数据架构师一方面要能够清楚的了解各种大数据技术栈的优劣势，在满足业务需求的要求下，能够充分的优化架构，合理的架构能够降低维护的成本，提升开发的效率。 另一方面， 大数据架构师要能清楚的了解自己团队成员，能了解其他同学的技术专长和品位，能够保证自己做的技术架构可以得到认可和理解，也能得到最好的维护和发展。 接下来我们会围绕这几个方面去看看，做一个最适合自己团队业务的架构选型会如何受到这些因素的影响？ 技术架构选型 业务需求是五花八门的，往往影响我们做技术选型的不是种种需求的细节，而是经过提炼后的一些具体的场景。就好比，业务需求提出我们要做一个日志分析系统，或者要做一个用户行为分析系统，这些具体需求背后我们要关注哪些具体的点？这是一个很有趣的问题

导语： 本文作者为解决一个JDK性能问题，从堆栈分析，到GC分析，再到Safepoint原因分析，最终定位到问题根因与所用的JDK版本有关。并整理成文，与所有Java相关开发的同学分享此次经验。 01 问题来了 笔者近期在工作中遇到这样一个问题：某客户新上线了一个Elasticsearch应用，但运行一段时间后就变的特别慢，甚至查询超时。重启后服务恢复，但每隔3～4小时后问题重现。 针对这个问题，我身边的同事也帮忙做了简单分析，发现存在大量Merge的线程，应该怎么办呢？根据我之前定位问题的经验，一般通过Thread Dump日志分析，就能找到问题原因的正确方向，然后再分析该问题不断重复的原因。按着这个思路，问题分析起来应该不算复杂。But，后来剧情还是出现了波折。 02 困惑的堆栈日志 因网络隔离原因，只能由客户配合获取Thread Dump日志。并 跟客户强调了获取Thread Dump日志的技巧，每个节点每隔几秒获取一次，输出到一个独立的文件中。集群涉及到三个节点，我们暂且将这三个节点称之为39，158， 211。问题复现后，拿到了第一批Thread Dump文件： 从文件的大小，可轻易看出39节点大概率是一个问题节点，它的Thread Dump日志明显大出许多：查询变慢或者卡死，通常表现为大量的Worker Thread忙碌，也就是说，活跃线程数量显著增多。而在ES