huangleijay的专栏

前言对于任何一个模块或服务或框架来说都需要具备可升级性。升级背后的诉求可能是多种： 版本的升级，寻求更安全的代码或者享用更强大的功能。 当前服务已经不能承担目前的用户量，急需要横向扩容升级。 其他外界因素引发的升级需求，如机房迁移等。 正文本文要讲的Kafka架构的升级，原因是上述讲的第二种。在kafka横向扩容中，首先调研了kafka本身架构具备的横向扩容能力。即将新broker加入到新的集群即可，新broke...

前言：如何在业务上敲定kafka的机器数目！需要遵循的前提是，单数原则，就是zookeeper和broker的节点数目最好是单数！分区分配给消费者有三个策略，默认是第一个。RangeAssignor策略：假设n=分区数/消费者数量，m=分区数%消费者数量，那么前m个消费者每个分配n+1个分区，后面的（消费者数量-m）个消费者每个分配n个分区。@hxx 针对于单个topic分区的分配，如果一个consumer同时订阅了多个topic，那么对于多个topic而言，某个consumer可能分配

背景：云搜同一query多次查询，结果数目不一致，或者排序不稳定？经过排查，结果数目不一致，是因为副本间数据不一致导致（build请求edoc偶发超时），而云搜的svc模式并不能保证同一个query落到一个副本上，所以出现了同query多次请求结果变化而，排序不稳定，部分是因为，当多个doc打分相同的情况下，排序规则是根据索引中的docid来排的（注意，非主键id，而是从1开始算的），此docid从1开始根据如索引时间来递增，而在多副本的的build中，不同doc进入索引的时机并不能保证！.

前言搜索提示要实现哪些功能？a： 支持前缀匹配，如输入”海底“，提示”海底捞“b：同时支持汉字，拼音输入 @hxx 有java组件可实现c：支持多音字，如 ”chongqing“ 和 ”zhongqing“ 都应该提示”重庆“ @hxx 注意，多音字涉及到组合全排列d：支持拼音缩写， 如“cq”，提示“重庆” @hxx 在b的时候抽取e： 基于用户的历史搜索行为，按照关键字热度进行排序 为了提供suggest关键字的准确度，进行排序。正文1：mt的实现： trie..

背景1： 核心数据类型(strings, numbers, booleans及dates)以不同的方式进行索引，而这点也是现实：在Elasticsearch中他们是被区别对待的2： 确切值(exact values)(比如string类型)及全文文本(full text)之间的区别，这是搜索引擎和数据库之间搜索的根本差异正文1： analysisfulltext或者分词字段，查询和索引都会经过同一套analysis模块，这个功能和esearch一样，包含过滤（大小写，空格，特..

前言自己理解的倒排求交：1： 首先倒排链是排序的，根据docid大小排序2： 比如现在有两个倒排链（对应于两个term的查询结果），现在需要求交3： 两个指针在倒排链上移动，先移动拥有较小头的链的首指针，找到大于等于另一个链首的时候，停下4： 如果等于，则放到记录此docid， 大于则移动另一条5： 记录下来的docid就是求交后的结果集如果三条的倒排链求交？答案是可以同时用三个指针，不要想着两个结束后操作第三个正文下面给出Lucene的倒排链求交的过程..

前言1：查询的过程是怎样的（结合架构分析）2：索引过程是怎样的（结合架构分析）3：ES索引的存储结构是怎样的本文只介绍索引正文1： 索引过程文档只有在segment中才能被查询，建索引的时候是放在内存中，此内存不是一个segment。refresh操作是生成新segment，fsync是将translog刷新到磁盘，flush相当于一次segment落盘。a： 更新的doc，先会被放在mem-buffer中，即在建完的正倒排信息放在内存中，并且将此次id...

前言1： 删除文档后，版本信息默认会保留60s。2： 关于cas重试，是需要重新get 一下version的，那肯定会成功吧?这个场景主要在，对于多用户的局部更新，文档被修改了并不要紧。例如，两个进程都要增加页面浏览量，增加的顺序我们并不关心——如果冲突发生，我们唯一要做的仅仅是重新尝试更新既可。正文1： ES使用乐观锁，即版本号策略来保证数据一致性PUT /test_index/test_type/6{"test_field": "test test"}...

前言需要确认的地方！1： 内存段中的数据删除后是否立即删除，查不到信息？即内存段，是否没有删除表？是有的，读段都有delete map2： 内核说，能查到标记删除的文档的版本号信息，得到的是 add -- > delete ---> now 这里面的delete版本号信息吗？ 我感觉可能是add的信息，如果是的话，那么delete 需要记录版本号的信息， ES中delete也会存储一个版本号。3： 解决的痛点是，段合并的时候查不到版本号信息，也就是从3...

前言1：为什么要讲fst和skiplist检索的倒排结构通常包含两种结构，一个是词典(一般要加载到内存)，一个是倒排表。如下图一次查询需要经历两个阶段，找到词典的位置（或者叫判断这个词存不存在），比如输入Lucene，先要找到这个词存在的位置。词典的存储结构就有两种实现方式，fst或跳表。Lucene3.0之前使用的是跳跃表结构，后换成了FST，但跳跃表在Lucene其他地方还有应用如倒排表合并和文档号索引。@hxx 跳跃表加速合并，因为布尔查询时，and 和or 操作都需要合并倒排表，..

前言1： 在ES中有一个原始文档行式存储，引发了行式存储这个概念的深究.正文1： 行式存储 vs 列式存储行式存储，如mysql数据库，表的结构都是以行为结构的，而且在存储上一行的数据都是存储在连续的空间。 那么想想针对于搜索场景，一般是term级别的操作，都需要将一行的数据完整的加载出来，性能非常不友好！所以列式存储在海量数据中有优势！行式存储适合的场景1、适合随机的增删改查操作;2、需要在行中选取所有属性的查询操作;3、需要频繁插入或更...

前言根据文档id定位到某个字段的正排信息，常常用于需要根据某个字段排序，分类计算，这个必须使用Doc values正文1： 在ES中原始数据是以行式存储的，也就是文档的所有字段都会连续的存储在物理空间上。这样势必会占用非常多的空间，所以一般都是压缩存储的！正排信息不是来自于原始文档中。存储原始文档的文件 如下查看原始文档的过程！第一步二分查找block，定位属于哪个block。　　第二步就是根据从block里根据每个chunk的起始文档号，找到属于哪个chu...

前言1：理解query到正排链的查询过程2：理解docid到取出正排值的过程正文:1： 举例说明从query到倒排链的过程query= title=爱将爱进行Unicode编码，成 ep 01xx使用词典文件（.tip，在内存），FST 路径搜索，匹配前缀，找到后缀地址，加载后缀块后缀块中，有倒排索引指针，找到 “爱” 倒排链 ， docids如果多个链的话，需要进行倒排链求交，使用skiplist2： 获取正排信息拿到最终的docid 集合后， 需要进行排.

1ES架构简介国际惯例，站在上帝的视角看看闻名的ElasticSearch长什么样，由于今天仅仅讲查询模块，所以对图中的大多数模块不会涉及。查询相关的模块主要有：Api接口，Transport模块，Searcher模块、索引相关。2ES查询分类ElasticSearch支持的查询有三种 query_and_fetch ...

目前流行的云搜索服务的主要特点有：1：接入快捷、运维能力强，提供了可视化运维数据、多维立体化监控和自助工具界面，实现全托管自运维。2：服务可靠、高可用。索引系统采用多副本数据和服务冗余、不同级别的隔离、集群联邦和资源预留等容灾机制，确保高可用性。宕机时副本自动迁移、恢复服务、同步索引数据，无需手工介入，做到用户无感知。3：文档属性丰富，搜索方式多样化。在索引服务流程中文档被嵌入了丰富信...

原文地址：Windows下开源搜索引擎Nutch1.2的安装作者：杨庆跃 Nutch是Apache组织的一个开源项目，利用它用户可以建立自己内部网的搜索引擎，也可以建立针对整个网络的搜索引擎。   两年前Nutch0.9版本的时候我写了个针对Linux的安装介绍，最近nutch1.2出来了，很想试试有什么新功能，可惜没有专门的Linux服务器，就在Windows上安装吧。(我使用的操作系统是

可以参见另一个：Lucene.Net系列一本文介绍了什么是Lucene,Lucene能做什么实验环境:   vmware 6.0<XMLNAMESPACE PREFIX ="O" />  redhat 5.1软件环境  apache-tomcat-6.0.29.tar.gz  nutch-1.0.tar.gz  jdk-6u21-linux-i586.bin

摘要：两篇文档是否相关往往不只决定于字面上的词语重复，还取决于文字背后的语义关联。对语义关联的挖掘，可以让我们的搜索更加智能化。本文着重介绍了一个语义挖掘的利器：主题模型。主题模型是对文字隐含主题进行建模的方法。它克服了传统信息检索中文档相似度计算方法的缺点，并且能够在海量互联网数据中自动寻找出文字间的语义主题。近些年来各大互联网公司都开始了这方面的探索和尝试。就让我们看一下究竟吧。关键词：