write down,forget
adidas eqt support ultra primeknit vintage white coming soon adidas eqt support ultra boost primeknit adidas eqt support ultra pk vintage white available now adidas eqt support ultra primeknit vintage white sz adidas eqt support ultra boost primeknit adidas eqt adv support primeknit adidas eqt support ultra boost turbo red white adidas eqt support ultra boost turbo red white adidas eqt support ultra boost turbo red adidas eqt support ultra whiteturbo adidas eqt support ultra boost off white more images adidas eqt support ultra boost white tactile green adidas eqt support ultra boost beige adidas eqt support ultra boost beige adidas eqt support refined camo drop adidas eqt support refined camo drop adidas eqt support refined running whitecamo adidas eqt support 93 primeknit og colorway ba7506 adidas eqt running support 93 adidas eqt support 93
标签 Tag : search

Diving Into ElasticSearch (5) 分布式架构

<Category: Diving Into ElasticSearch> 3 条评论

今天介绍下ElasticSearch的分布式架构,如果你熟悉cassandra、hadoop、mongodb,你会发现ElasticSearch里面有很多他们的影子,没错,ElasticSearch吸收了目前主流的分布式系统的很多特性,下面简单介绍一把。

之前翻译过一篇[译]搜索引擎与时间机器,里面介绍了下作者在设计ElasticSearch的一些想法,现在看起来还是记忆犹新,因为他的这种思路实在是非常新颖,比如ES里面的将数据分为工作数据和持久化数据两种:

工作数据就是正常的提供查询和索引的数据,这部分数据假定是瞬时的,并且是不可靠的,随时可能丢失的数据,而持久化数据则是可靠的,一致的数据,工作数据可以都放在内存中,这样可以保证非常好的性能,而持久化数据则专心保证数据的一致性就ok了,我们自动的分布式系统有CAP原则,通过对数据分离方式,我们很好的解决了C和A的问题,你可能会问,你内存中的数据如果不对了怎么办?不就会影响数据的一致性吗?一方面数据可以从持久化数据进行加载,另外ES节点间的数据会定时刷新和同步,最终确保数据的一致,就算万一机器都歇了,没关系,从持久化目录里面重新加载数据即可。

单前面说的那个还不算什么,如果不能很好的解决动态扩容的问题,那就不算是ElasticSearch了,在ElasticSearch里面,索引目录有如下两个概念:shard(碎片)、replica(副本)

碎片(shard)的意思很好理解,db可以有sharding,索引也可以做嘛,单个索引目录太大,GB级别的索引文件,你再继续往里塞数据,文件合并,优化,有过这种经验的人应该会明白这种痛苦,怎么办?拆呗(china?拆那?),一般的做法是按数据拆,自己按租户,按时间拆等等,很是麻烦,并且拆完了之后的事情也不少,跨目录查询怎么办?更新怎么办?接口要怎么变?这些在ElasticSearch里面都帮你想到了,对你而言,全是透明的,你操作的就是一个索引,你在创建索引的时候,根据索引的规模指定碎片的大小,其他的你就不用管了,至于它里面怎么实现数据的平均分配,其实很简单,就用了一个取模的算法,随机分配到各个碎片中,至于一致性哈希之类的,目前来说完全没有必要。

碎片可以解决单个索引太大的问题,但是凡任何事有利必有弊,索引碎片在实现上其实就分成了很多个索引目录,索引目录越多,对建索引的速度会有提示,尤其是多线程环境,因为我们建索引的时候单个索引目录肯定加锁,一旦涉及锁,势必要减慢速度,不过我多几个目录,不就可以并发执行了吗?是的,ES就是这么做的,但是前面说了,有利就有弊,索引搞得到处都是,ES查询起来就很费劲了,一般情况下,我们在没有使用Routing的情况下(后面再介绍routing),ES会同时多个线程去读取各个碎片的索引数据,然后再合并查询结果,另外在ES的分布式环境下,碎片如果分布在多台服务器上就要加上网络的开销,势必会影响查询速度了,在海量数据的前提下,这些其实都还好,并且ES支持多种查询方式(reflink:search type):

Query And Fetch:

Query Then Fetch:

Dfs, Query And Fetch:

Dfs, Query Then Fetch:

Count:

Scan:

根据不同的查询需求,选择合适的查询类型,会收到意想不到的效果。

先整体看看单ES节点的模块结构吧:

 

再看看一次索引操作

再看看一次查询请求

本文来自: Diving Into ElasticSearch (5) 分布式架构

How to make searching faster

<Category: Lucene> Comments Off on How to make searching faster

http://wiki.apache.org/lucene-java/ImproveSearchingSpeed

Here are some things to try to speed up the seaching speed of your Lucene application. Please see ImproveIndexingSpeed for how to speed up indexing.

阅读这篇文章的其余部分 »

本文来自: How to make searching faster

Lucandra,when Lucene meet Cassandra

<Category: Lucene, 云里雾里> Comments Off on Lucandra,when Lucene meet Cassandra

转自:http://blog.sematext.com/2010/02/09/lucandra-a-cassandra-based-lucene-backend/

GitHub地址:http://github.com/tjake/Lucandra/blob/master/README

 关于Lucandra的介绍:

 
Lucanadra线上应用:http://sparse.ly
阅读这篇文章的其余部分 »

本文来自: Lucandra,when Lucene meet Cassandra