分类 数据后台 下的文章

关于solr build search分离的讨论以及re-indexing的实现

场景需求与分析

我们的做法,一般将索引构建大致分为两类操作,一为全量索引构建,二为增量索引构建。使用solr建索引,一般会在初始状态的时候,进行一次全量构建,根据当前数据源的整体数据生成一套完整索引,可提供服务,但为了保证索引数据的完整且最新,还需要增量索引,使得数据源的改变(包括记录的增加,修改,与删除)体现在这套索引之上。

- 更多 -

Solr源码掘金之 SolrCloud中的zookeeper使用分析

上一周,对公司搜索引擎工作流程的做改造工作。涉及到不同角色服务器之间的沟通工作。我们试图应用zookeeper到我们的场景,实现应用模块之间的解耦。本文深入到solr源码,从中掘金,看看solr是如何使用zookeeper的。
在做本次改造的时候,公司同事对于zookeeper的使用,提供了很好的建议,其中一个重要原则就是“谁创建,谁修改”,也就是各个服务应用自己创造自己的结点,自己去修改配置自己的最新状态。一般情况下,对结点的修改是结点的创建者,而不应该是其它对些结点数据的关注者,不然会增加操作复杂度与不确定性。


- 更多 -

如何对10亿数据量级的mongoDB作高效的全表扫描

一、正常情况下,不应该有这种需求

首先,大家应该有个概念,标题中的这个问题,在大多情况下是一个伪命题,不应该被提出来。要知道,对于一般较大数据量的数据库,全表查询,这种操作一般情况下是不应该出现的,在做正常查询的时候,如果是范围查询,你至少应该要加上limit。
说一下,我的应用场景:用于全量建立搜索引擎的索引。这就是一种需要用到全表扫描的非一般情况。对于全表扫描的结果,我们没有排序要求。


- 更多 -

IK分词器原理与源码分析

引言

做搜索技术的不可能不接触分词器。个人认为为什么搜索引擎无法被数据库所替代的原因主要有两点,一个是在数据量比较大的时候,搜索引擎的查询速度快,第二点在于,搜索引擎能做到比数据库更理解用户。第一点好理解,每当数据库的单个表大了,就是一件头疼的事,还有在较大数据量级的情况下,你让数据库去做模糊查询,那也是一件比较吃力的事(当然前缀匹配会好得多),设计上就应当避免。关于第二点,搜索引擎如何理解用户,肯定不是简单的靠匹配,这里面可以加入很多的处理,甚至加入各种自然语言处理的高级技术,而比较通用且基本的方法就是靠分词器来完成,而且这是一种比较简单而且高效的处理方法。

- 更多 -