ES能为你解决什么问题,又会带来什么问题?

推荐阅读:

  • 这套Github上40K+star学习笔记,可以帮你搞定95%以上的Java面试

  • 毫不夸张的说,这份SpringBoot学习指南能解决你遇到的98%的问题

  • 最全面试题新鲜出炉:70+算法题、近30种大厂面试笔试常考知识点

业务需求痛点

  • 业务增长,查询条件越来越多,索引越来越多

    业务发展初期,数据量不多。查询,写入都很快。随着业务的发展,数据量增大,出现慢查询,开始往表里不断的加索引,保证数据查询效率。但是当数据量继续增大,业务查询越来越复杂。程序员天天想着这个表怎么加索引。索引的增加,写入数据的时间成本越来越高。

  • 表数据增加,数据拆分越来越复杂

    数据量增大,开始进行分表处理。慢慢的发现,尼玛,分的表越来越多。再这么下去,这台数据库服务器上都容不下他了,这是要做数据分片的操作啊。分表已经够费劲了,还要分片?

  • 全文检索功能

    嗨,哥们,给我加个全文搜索的功能。简单的一句话,你心里十万个草泥马。这么多的数据量你让我搞全文搜索。

    上面业务通点总结起来就是要查的快,要分布式,要全文搜。

ES 能解决什么问题

S主要运用于全文搜索、数据分析, 底层使用开源库Lucene,拥有丰富的REST API。内部分布式的数据存储、倒排索引等设计,使其可以快速存储、搜索、分析海量数据。典型的使用方和应用场景,如github,StackOverflow,elasticsearch+logstash+kibana 一体化的日志分析。

ES 搜索为什么快的原因
ES能为你解决什么问题,又会带来什么问题?_第1张图片

对于mysql中如上的数据表,ES会对每个字段的值建立索引,通过索引的值去找数据,而且这些索引都是在内存里面的。

name段索引:

ES能为你解决什么问题,又会带来什么问题?_第2张图片

age字段索引

ES能为你解决什么问题,又会带来什么问题?_第3张图片

address 字段索引

ES能为你解决什么问题,又会带来什么问题?_第4张图片

这样,当我们要找上海市,年龄为21岁的数据就能够通过address,age索引快递定位到数据id=2的是我们需要查找的。

然后在从磁盘中把数据id=2的数据读取出来。

上面的其实就是ES中倒排索引的一个简化版本。

实际上的ES的倒排序使用的是前缀作为索引,同时会使用FST对索引数据进行压缩,以保证在内存的数据量不会因为索引多而带来比较大的内存消耗。

对于上面的数据表,如果采用HashMap的方式对name字段索引的话,索引所占用内存20个字节。

但是如果转换成FST结构的话,可以用四个字节表示name,总共占用内存为4+4*3=16。(假设数据范围只有M,i,e,c) 四个字符。

ES能为你解决什么问题,又会带来什么问题?_第5张图片
ES 分布式数据结构设计
  • 数据分片均衡

    分片是 Elasticsearch 在集群中分发数据的关键。文档存储在分片中,然后分片分配到集群中的节点上。当集群扩容或缩小,Elasticsearch 将会自动在节点间迁移分片,以使集群保持平衡。

  • 数据可靠

    分片有主分片,复制分片。复制分片只是主分片的一个副本,它可以防止硬件故障导致的数据丢失,同时可以提供读请求,比如搜索或者从别的 shard 取回文档

    每个主分片都有一个或多个副本分片,当主分片异常时,副本可以提供数据的查询等操作。主分片和对应的副本分片是不会在同一个节点上的 。

  • 分布式搜索

    分片本身就是一个完整的搜索引擎,它可以使用单一节点的所有资源。主分片或者复制分片都可以处理读请求——搜索或文档检索,所以数据的冗余越多,能处理的搜索吞吐量就越大

    ES 集群中每个节点通过路由都知道集群中的文档的存放位置,所以每个节点都有处理读写请求的能力。

    在一个写请求被发送到某个节点后,该节点即为协调节点,协调节点会根据路由公式计算出需要写到哪个分片上,再将请求转发到该分片的主分片节点上。如果是查询操作,则协调节点会将请求分发到其他分片上,其他分片查询结果之后再由协调节点将数据组装返回。

所以,引入ES,能够实现帮你解决数据量多,分布式查询问题。同时ES会自动的替你对所有字段建立索引,以实现高性能的复杂聚合查询,因此只要是存入ES的数据,无论再复杂的聚合查询也可以得到不错的性能,而且你再也不用为如何建立各种复杂索引而头痛了。另外,ES支持多种分词器,对全文搜索支持更加高效。

ES引入会有什么样的问题

  • 字段类型无法修改、写入性能较低和高硬件资源消耗
    ES需要在创建字段前要预先建立Mapping,Mapping中包含每个字段的类型信息,ES需要根据Mapping为字段建立合适的索引。由于这个Mapping的存在,ES中的字段一但建立就不能再修改类型了。ES在数据结构灵活度上高于MySQL但远不如MongoDB

  • 不支持事务,JOIN

  • 吃硬件

    ES的排序和聚合(Aggregation)操作会把几乎所有相关不相关的文档都加载到内存中,一个Query就可以很神奇地吃光所有内存,现在新的Lucene版本优化了基于硬盘的排序,但也仅当你使用SSD的情况下,才不会牺牲过多的搜索性能。其他的问题还包括,大量的增量写操作会导致大量的后台Merge,CPU和硬盘读写都会很容易达到瓶颈。ES确实在横向Scale方面做的很出色,但前提是有足够的预算买硬件。

  • 数据实时性
    每当有新增的数据时,就将其先写入到内存中,在内存和磁盘之间是文件系统缓存,当达到默认的时间(1秒钟)或者内存的数据达到一定量时,会触发一次刷新(Refresh),将内存中的数据生成到一个新的段上并缓存到文件缓存系统 上,稍后再被刷新到磁盘中并生成提交点。因此,从Index请求到对外可见能够被搜到,最少要1秒钟的数据延时。

  • 不支持数据的权限管理

总结

ES香不香看你怎么用。有人用的很爽,有人用的很痛苦。用好了就少加班调索引,调sql。用不好就常加班调ES。

优点:
1.高并发
2.容错能力比mg强。比如1主多从,主片挂了从片会自动顶上
3.满足大数据下实时读写需求,无需分库(不存在库的概念)。
4.易扩展。分片数据自动均衡
5.支持较复杂的条件查询,group by、排序都不是问题

缺点:
1.不支持事务
2.读写有一定延时
3.无权限管理
4.吃硬件

你可能感兴趣的:(ES能为你解决什么问题,又会带来什么问题?)