00:01
好了,呃,然后下面的话,我们,嗯,让大家这个更加这个清晰的认识这个ES啊,然后我们跟这个目前我们已经熟悉的一些这个数据存储。主件,然后呢,进行一个比较啊,就是我们对比一下。嗯,比较的去说一说,然后你就对这个ES的定位呢,呃,更加的这个明确一点啊来,那我们就对比一下啊,我们要总共对比的是,呃,Red my ES这个face还有。或者这个have来首先看一下啊,这里面除了这个ES之外,大家都学过了吧。呃,这里面重点是h base啊,咱们班这个h base讲过了吗?VS,讲过了吗?跟我说一下啊,讲过的话打一啊。讲过了是吧,OK,那就完美了啊,因为好久之前讲的了是吧,嗯,那你好久之前讲的,那也是讲过了对不对。
01:07
来这个h base讲过的话那就好说了,因为这个ES中有很多机制跟h base是很像的。啊,跟HVS很像啊,OK,来吧,那我们对比一下啊,首先我们从这个容量的角度来去对比。那从这个容量角度来讲的话呢,一定是这个是最低的。因为它毕竟都是什么,把数据是什么构建到你的这个内存中的,是不是,那你的内存跟这个磁盘比,那肯定就比不了对吧,所以说从这个容量角度来讲啊,它这个red呢,肯定是最低的,然后呢,依次的话就是越来越多啊,比如说MYSO,嗯,就中等吧。对吧,买搜Q中等啊,就是对一些这个中小型的这个公司来讲,呃,你的这个买搜狗去维护数据应该是问题不大,但是对于这个大型公司来讲,买搜狗能不能维护数据呢?也能够维护啊,但是他一定是要去搞一个非常庞大的一个买SQ集群去做的。
02:00
理解吧,啊,它对这个数据的一个容量啊,大小来讲的话呢,是中等的。然后呢,这个ES啊,它是较大,呃,这个较大你怎么去说呢?嗯,其实理论情况下啊,理论情况下。它可以存无限大的数据啊,无限大的数据就跟你的这个什么h base或者什么这个哈,其实他们两个就是一个,因为他们两个底层都是基于这个HDFS的,对不对,还有哈豆op,然后那什么哈h base呃。底下都是什么所谓的HDR,那就理论情况下,这哥们呢,它存的数据也是无限大的。对吧,我只需要怎么去做扩容就可以了呀,比如说我存不下了,那我加机器存不下了,我加机器存不下了,加机器。对吧,我横向扩展就可以了。那其实这个ES也是一个道理啊。呃,它也是可以零的情况下也可以无限大。如果我这个存不下了,那我就什么横向扩容加机器存不下了,横向扩容加机器。
03:00
对吧,但是为什么我们把它们放到一起比较的话呢,我把它们定位成是一个海量,把它定位成是一个比较大呢。是因为这样子的这个ES,它的这个存储代价比较高,存储代价比较高,这个啥叫存储代价比较高呢?啊,就是比如说对于同一份数据来讲啊,比如说这个我有一个T的数据,对吧,你如果说存到这个HDFS中,那可能我就什么占上这个,比如说两个T或者三个T的空间,因为我可能会有副本嘛,对不对啊,比如说我就三个T吧,我有三个副本好吧,那就什么占三个T的空间就可以了。顶多呢,再加上一点点什么呀,就是那个原数据啊,那原数据没多少。对吧,几百K就差不多了。啊,这就忽略不计了吧,对吧,那么你要把这个数据放到ES中存的话呢,首先啊,你的一个T的数据,我他也他也有副本的机制啊,比如说我有三个副本,那我最起码要占三个T的空间,这是最起码要去占的,但其实呢,它占的空间远远比这个要大很多。
04:00
远远比这个大很多,为什么呢?因为他这里面在纯数据的时候,因为他要去支持你做这个全文搜索引擎,所以说呢,它会对你的数据呢,去构建各种各样的索引啊,去构建各种各样的索引,这个其实也会占用很大的空间。明白了吧,而且这个索引。有很多是要构建到内存中的,构建到内存中的,所以说呢,ES对这个内存的要求也是比较高的,就说白了,它对这个内存的一个使用率呢,也是比较高的。所以说啊,你同样大小的数据,如果说你交给这个HDFS去维护,那么它的代价是比较低的,但是交给这个ES维护呢,代价是比较高的,明白吧,所以说啊,我们一般情况下呢,也不会说使命的往这个ES中去怼数据。明白了吧,啊,不会往它里面去存太多数据了,就是你现在必须要要的,或者说呢,我们什么存一个周期的数据,比如说我就存最近一年的数据,对吧,或者什么最近两年的。能明白了吧,比如说超过这个一定周期的数据以后呢,就从他那边拿走了。
05:03
因为比如说这个去年的或者前年的数据,那大概率情况下,你这个访问的频次应该是很低了,或者说基本基本上我都不再去访问它了,那我可以把这个数据呢,从你的ES中拿走,比如说我就扔到这个HDFS中。它的代价很低呀,对吧,扔进去冷藏起来就完了。理解吧,啊,这是从这个容量角度啊呃,然后这个扩容角度的话呢,嗯。这几个应该都都OK啊,扩容。对吧,啊,其实其实。这几个都OK吧,这几个都OK啊,都还行。这个虽然说这个red也行啊,就他们都能扩容啊,都能扩容,都是可以做这个横向扩容的,比如说我可以搭击群。对吧,答题群做横向扩容,买色货的也可以啊,答题群横向扩容,他们都可以去做扩容。明白吧,所这个扩展性角度来讲的话呢,嗯,都差不多,只要我加机器,然后呢,就可以做横向扩容了。明白了吧,啊,所以这个主要是从容纳角度啊,容纳角度的话,这个呢,相对是比较低的啊好。
06:02
然后下面是从这个查询时效性这个角度来讲啊。那绝对是最优的。绝对是最优的啊。就是一个事物啊,它。就是在某一方面是特别特别突出的,你可能看到他这个,诶,其他方面的都都很平庸对不对,但是他一定在某一个方面是特别特别突出的。就比如说你从这个容量角度来讲,它是比较低的。对吧,但是你要从这个查询时效性角度来讲,那我觉得基本上没有人能跟他进行一个抗衡的。它是非常非常高的,因为这个数据是构建到内存中,而且我是基于什么,基于这个key做点查操作。对吧,这个效果是非常非常好的啊,所以说一般我们要求这个查询时效性比较高的这个场景里面啊,通常都会考虑到使用。都会有,它都会有它的这个一席之地啊好,然后MYSO,嗯,My soq,我们定位是较高啊,首先它肯定是没有这个ES,呃,没有这个什么red高的。明白吧,毕竟你的ES,呃,这个red走的是内存,你这个MYSQ呢,走的是磁盘啊,通常你要走磁盘的,就是要从磁盘中去调数据,那一个从内存调数据,一个从磁盘调数据,这个差别肯定就出来了。
07:13
对吧,而且啊,大家注意它这个较高呢,也有一个前提,什么前提呢。需要索引的一个加持。啊。My circle,它如果说在这个比较大的这个数据里面啊,数据量里面,想做到这个能够响应的什么时效性比较高一点,对吧,就是能够什么在这个很短的这个延迟内就把数据给你返回,是需要建索引的,如果说你不给他建索引。它是很慢的。啊,当然大家可能感受不到,说我们现在用的这个表对吧,我也没有见过什么收银,我觉得查起来也挺快呀,你那才几条数据啊。对吧,你这才几条数据啊,如果说你把这个买色号中啊,你存上这个,比如单表,你干到这个几百万吧,干到这个500万对吧。
08:00
你单表干到这个500万,500万条数据的时候,你再试着去查一下。他就已经什么很很慢很慢了,当然如果说你见了索以后呢,诶,这个差距还是比较大的啊,就几十倍的差距,就如果说你不见索引,可能就是大几秒钟,五秒钟或者什么,甚至于什么十秒钟都有可能,但你这样的缩影以后呢,基本上可以优化到一秒内啊,基本上可以达到一秒内。你能明白吧,这个差距还是比较比较比较大的啊,同学们。好说是一个买搜狗啊,一般我们在聊的时候呢,我们都是会有这个索引的啊,你加上索引以后呢,这个性能确实是不一样的。好吧,行,然后这个ES的话呢,呃较高啊,就是它跟买三果七差不多。啊,它跟MYSQ差不多,而且呢,呃,它在这个比MYSQL支持的数据量更高的情况下,它能够做到跟MYSQL差不多的一个查询性能。这还是挺厉害的吧?对吧,那为什么他能够这么快速的把数据查出来呢?其实也是基于它的这个索引优化啊,它里面也是有各种各样的索引的啊,这个等我们再具体给大家去聊的时候你就知道了,它里面有各种索引。
09:07
明白吧,啊,有各种索引啊行,然后h base呢,呃,它也差不多啊,就这几个的查阅性能都差不多。但是对于h base来讲,我们也有一个前提,就是你必须得基于你的R去查。理解吧,必须是一个点茶啊,你看啊,只要你见了索引啊,基本上我们都是类似的方式,都是点茶的方式,对吧,基本都是点茶啊,都是点茶。好,当然了,你也可以有这个什么范围查询是吧,嗯,行呃,你见到所有的情况下,那么你的性能呢,基本上都差不多。啊,都差不多。明白吧,但是这个h base中啊,如果说你要使用这个SC的这个方式,那就性能比较低了,因为它是一个范围查询,那你范围查询的话呢,就会比较慢,肯定没有这个基于查快。对吧,我给你一个ROK,我点查这个什么查到了,但你要什么这个去去死干了,去这个扫描了,那就会比较慢。
10:03
对吧,好,然后这个对于这个have吧,这个主要说的是have啊,这个have来讲的话,那就很低了。跟他们肯定是没有可比性的啊,没有可比性的他是很低的。明白吧,这个大家用过也都知道啊,这我就不多强调啊,它很低的啊行。然后下面从这个查询的灵活性角度来说啊,那这个呢最差。啥叫这个查询灵活性,就是我对你数据的一个查询的方式,你支持的多不多,那一定是最差的,他就只支持通过K来去查,不支持别的了。明白吧,买soq做的是最好的啊,应该跟这个呃,Hell一样啊,做的是最好的,为什么呢?因为他们支持的。烧烤语法。So,口的表达能力还是比较强悍的啊,就是我可以怎么在你的一条搜口中表达什么,我要我要去做做过滤对吧,我要做聚合啊,我要做排序。对不对,等等等等一些你都可以在你的一条口中把它表达出来,所以说我们是可以什么基于你的这个so呢去呃,非常方便的对你的数据呢,做一些这个分析,然后呢,做一些什么查询,做一些什么统计的。
11:11
对吧,那你看一下我们的买烧烤以及这个号,它都是什么支持这个标准化烧烤的,所以说他们的这个查询灵活性的是相对比较OK的。明白吧啊呃,那对于我们这个ES来讲的话呢,它是比较好啊,那肯定是没有这个so好啊,但是呢,它也还OK,为什么呢?因为它有自己的一个语法,叫这个DSL语法啊,这个等我们讲到你就知道了啊,就它有自己的一种什么特定的一种语法,然后呢,帮助我们去做数据的过滤,匹配,排序,聚合等等操作,但是呢,他。关联查询是很弱的哈。就所谓的什么招易操作啊,这个事情我们就不可能在这个ES中去做啊,因此的话,我们在这个前面讲项目的时候,就提前把那个什么该招易的数据是不是提前给他招引好了呀。尽可能避免让这个ES呢,帮你去做这个事儿啊,他是这个很很很害怕做这种事情的啊,但是你做别的。
12:06
对吧,什么过滤啊,什么匹配啊,什么排序啊,什么聚合呀,就做这个分析统计,他是非常擅长的。明白吧,啊,非常擅长的啊。行,那这个HV的话也是很差的啊,很差劲的。因为什么呀,我们正常使用的方式就是一个什么呀,基于周K的一个什么get的方式,就是我要去盖的数据。对不对啊,但是现在的话呢,我们一般在使用h base的场景里面都会有一个他的好基友存在,就是这个Phoenix。啊,或者说呢,现在我们使用h base啊,其实有很大一部分原因啊,就是因为这个Phoenix啊,这个Phoenix呢,给h base加了不少分啊。因为你单独使用它,其实局限性是很大的,就比如说你要去查数据,你只能是基于什么,基于可去做点查对吧,基于SC去做什么范围的查询。而且呢,你这些东西呢,都得什么,基于你的周来去做,那如果说我们想去做一些,比如说基于别的字段去做,就是做这个查询,那对不起,它的性能非常非常慢,因为它都要什么做全盘扫描。
13:07
但有了这个Phoenix以后呢,诶,他支持我们写so了,首先第一个。我的查询灵活性有了。再一个呢,它里面还有二级索引。对吧,那你通过别的字段去查数据性能也OK了,因为它什么可以支持你对别的字段建索引。对吧,说这个Phoenix其实是给你的这个H呢,加了不少分的。好吧,一般我们在使用h base场景里面,呃,都会这个配合这个菲尼斯,因为我写搜狗就可以了呀。明白吧?啊,所以你要说从HV本身来讲啊,它的这个查询灵活性是比较差的啊,但如果说有了这个Phoenix加持以后呢啊,那还是能够排得上号的啊,还是比较OK的啊。行,这是这个查询的一个灵活性啊,大家知道一下好呃,再往后是这个写物的速度啊。这个写入数组就什么,我要把数据呢,写到你的这个主站里面,那这个极快。
14:03
为什么极快呢?因为写到内存就可以了。对吧,数据直接扔到内存中搞定了。明白吧,搞定了啊。呃,买so是中的。呃,他没有这个ES和这个H写的快哈。为什么呢?因为他们的写入方式不一样,MYSQL是同步写入,ES和这个h base呢是异步写入。对吧,那我们先来说这个if写入吧,因为大家讲过h base你就应该知道啊,呃,H base在写数据的时候是怎么写的呢?它会先把数据呢写到一个内存中,这个内存叫store。对吧?啊,我不知道你们还有没有印象啊,他会先写到这个m store里面,然后呢,接下来啊,他就可以给这个客户端的返回了,说这个数据写成功了。那这个数据呢,它不需要等等,不需要什么等着你说真正的写到磁盘中啊,而是呢,它会有一个什么呀,有一个异步的处理。就是当我们的这个memory store啊,就是达到一定条件啊,比如说你达到多少了,对吧,大家应该讲过有很多条件,比如说单个memory达到128。
15:04
对吧,整体的达到多少,达到多少时间。等等一些啊,有很多条件,那么只要你满足了其中的某护条件,那我的这个数据呢,就会从你的内存中刷写到这个过程叫flash对吧,刷写到我的磁盘中就放到那个什么里面了。对吧,放到这个里面。所以说啊,从我们这个客户端啊,从用户的角度来讲,我写一个数据,我直接扔到内存中就完事了。我是不用你等到真正的写到磁盘中的。这个叫做异步写入,就是你写到内存中就完事了,那么王此盘写的呢,是另外一次操作了,就不是说在你本次操作中去完成的。说这个叫做异步写入。好,那我们ES呢,跟他这个机制其实是特别特别像的啊,它也是先写内存,然后呢,再去往这个磁盘呢去刷明白吧啊,所以他们两个这个速度呢是比较快的啊,但是呢,MYSQ呢就会相对比较慢了。为什么呢?因为这个味儿。
16:02
特别老实。啊,老老实人啊,为什么呢?他每次写数据,他就一定要保证你的数据真正的写到磁盘中了。他才会给你响应说写成功了。明白吧,他做的是最最靠谱的啊,他做了什么最安全的,就是他一定会保证你的数据真正的落盘成功了,他才会告诉客户端说写成功了。它是一个同步性。明白吧,所以这样的话就会比较慢,因为你写磁盘中就会比较慢呀。对吧,写完以后才能给你的客户端的响应书写成功了,或者说呢,他才能为什么去做别的事,比如说呢,我再次进行什么下一次写。是吧,所以这个会比较慢一点的好吧,呃,然后这个hell或者这个HDFS的话,那就什么更慢了呗,对吧,那就更慢了啊,他就这个跟他们比肯定是比不了的。明白吧,啊,跟他们比肯定比不了啊行,就是从这个写物输的角度,我们去聊一聊啊好,然后呢,呃,从这个一致性这个角度,我们再来说一下啊,从一致性角度来讲的话呢,什么呀,什么ES呀,什么h base呀,什么呃,Have或者lo啊都是比较弱的。
17:13
啊,其实这个我们不应该把它这个称之为弱的啊,这个可以称之为强的啊,因为hell其实也是有事物的啊。大家可能没有讲对不对,它其实也是有事物支持的啊,但其实现在我们一般都用have的时候,我们一般都不涉及这个方面啊,因为我们只是把它作为一个数据分析的一个容器来,呃,组件来去使用的,对吧?啊,所以一般还是把它规划成这个比较弱啊。那这里面唯独买烧烤。它是有强事物支持的。明白了吧,它是有强势物支持的啊,像那个什么呃。虽然说也有这个ready的事物,对吧,但它那个事物呢,跟我们跟我们所熟悉的那个事物呢,不是一回事啊,同学们,它也叫事物,但是人家那个事物呢,跟我们所熟悉的那个事物根本不是一回事。
18:00
OK吧,啊,根本不是一回事啊,他这个对一致性啊,或者什么这个事物的这个呃层面啊,它是比较弱的。对吧,然后像这个ES啊什么呃h base啊,这更不用说了。对吧,你聊都没聊过这些东西没有。啊,唯独这个买搜狗啊,它有这个强势物支持。所以说啊,一般这个买so呢,还是用到我们这个业务处理中叭较多,因为你的业务处理呢,就会涉及到这个事物,对吧,比如说你转个账啊。对吧,或者什么这个下个单啊,支个付啊。能明白吧,这些都需要有这个事物的支持。好吧,啊,所以这个它的这个使用场景呢,是不一样的啊OK。行吧,那你看一下啊,我们从一些这个呃,各个层面啊,然后呢,我们综合性的去对比了一下,那么大家呢,就会对这个ES呢,有一个相对比较直观的一个认识啊,他其实从每一个方面来讲。都还不错哈。就可能说没有特别的突出啊,但是呢,综合性好,它都做的还不错,你看啊,数据的角度还可以,查询时效性还OK,这个查询灵活性呢也比较OK。
19:08
对吧,而且啊,大家注意这个东西,呃,将来可能就会变成什么,变得非常好啊,为啥呢?因为目前来讲它还是使用这个DSL比较多,但是呢,他其实已经开始支持烧了。啊,只不过现在还做的不是特别的好啊。就没有全面支持搜Q,它的部分功能是已经支持这个搜Q了,那在未来的这个某些版本中可能就什么呀,全面支持搜Q,那就从灵活性角度来讲,就可以跟你的什么跟你的买烧烤啊,跟你的什么have啊是可以抗衡的,反正我们都用了so烤,谁怕谁呀。退吧,啊,所以这个现在来讲的话呢,还稍微会弱那么一点点。OK吧,那将来就不一定了啊,行,你看这个写入速度呀,也比较快。唯独就是这个一致性啊,事物角度。那你说你是做分析的,你你你的定位是一个分析型的一个什么组件,你考虑啥事物啊。
20:01
对吧,说这个层面根本是根本不影响他的啊,这不叫他的弱点,因为我就不考虑这个东西,你要想考虑事物,你就别考虑我ES对吧,你就别考虑我的,你就用买S就得了啊,用买S老老实实用买S就得了。听到了吧,所以这个不是减分项啊,同学们不是减分项啊好,所以说从这个各个层面来讲啊,它综合的这个性能呢,都是比较OK的。明白了吧,啊,大家把这个自己去理解一下啊,对他这个定位呢,呃,更加的这个清晰一些啊行了。
我来说两句