00:00
呃,那接下来呢,我们讨论这个dim层,咱们的维表层应该用什么啊,那首先呢,它要符合一个永久存储。然后最好呢,根据主件信息能够查询。对吧,根据主键信息查询一行数据啊,它满足这两个点,大家想一想我们有哪些框架。可能是可以的,对吧,就是大家呢,把你们自己所想的答案写在这个弹幕上好吧。就是你觉得可不可以,诶那个牛总说了叫H对吧,好,那我们先写上啊,呃,这个到底行不行呢,不知道。啊好red诶不错,对吧,因为我们是实时,那red它符合永久存储,而且还快对吧,好快好,那还有呢。还有没有我们所学习的框架,我们还可以用什么?
01:00
我们等会再来讨论啊,好,那朱总所说克了一个house对吧?可以啊,不错啊,好ES。还有没有?还有没有啊。嗯,没了吧。还有一个东西啊,大家忘了。哎,对了,牛总还得是牛总对吧?啊对,买circle买circle买circle我们想一下是不是也可以啊对吧,可以有主见永久存储对吧?满足这些个条件就买S克本身对吧,就是买S克呢,就是换句话说,我们DM层压根就不导对吧,我直接用买S这边我讲一个叫本身对吧,就是它那就不需要导数据了。
02:04
啊,他就不需要导出,因为你本来就在买搜狗。数据。对吧,其他的框架呢,你要导一下,好,那我们就来讨论一下这些个框架。可不可以?对吧,可不可以好,那我们讲第一个。呃,永久存储。没毛病对吧,好,根据主键查询是不是没毛病啊,对吧?好,而且呢,它是什么,它是海量,我们写一下海量。数据。对吧,啊,海量数据永久存储。还有,根据主见。啊,快速查询。快速查询对吧?好,那就满足这两个,那我们同时还扩展了就是海量数据对吧,如果数据量大我也可以,那更关键在于呢,我只要根据主键,因为在H里边,这个主键对应H是什么东西。
03:09
对应h base是什么东西?Rookie吧,大家还记得吗?对了啊,Rie,那在is里边,如果说我们要根据rookie进行查询,它的效率是非常高的。啊,因为他说会排序。还会给rookie建索引啊,所以它的一个查询效率呢,是非常非常高的,OK吧,好,这是我们所说的这个。那他可以对吧,也就是说这种方案呢可行。啊,那目前来说没什么问题对吧?哎,那我们就打一个勾啊,目前可行那呢。大家想一下,Red用存储可以根据主件查询也可以对吧,因为red所有的数据都是KV类型的,它这个KV类型的数据库对吧,所以呢,它要根据主件查询必然是可以,那我们用red作为我们这个地方的DM层可不可以的?
04:16
我们思考一下对吧,有可能这里边框架都行啊,有可能都行对吧?啊主要说呢,我们选一个啊,但是我们在讨论到对吧,那red可不可以呢,大家想。可不可以?而且从访问效率来说,比。肯定可以啊。啊,可以,但怕内存不够,哎,它问题不就在这儿吗?对吧?好,那这里边有一个瑕疵点就在于什么呢?用户表数据量大啊,你ready呢是内存数据库优势在于什么呢。
05:17
内存的访问效率高,我是实时项目,所以我从时效性来说,我肯定选用red。但是。他成页内存,败页内存。你内存访问是快,但是呢,你毕竟。内存存储。对吧,啊,那我们不能存储太大的一个数据量。啊,倒不是说内存放不下,你要能能能放下也可以,那你就购买更多的。集群对吧,你是至于是自己搭建还是购买,你都得更多台来做这个事情才可以。对吧,啊,单台服务器可能不够了。
06:01
好,那内存比较贵嘛,成本很高很高。这不是高的问题,而是很高对吧,应该这样聊,还不是像你把这个机械换固态那内存。啊,你想想看,你你想吧,你买一个内存条。呃,32G的内存条多少钱?知道吗?1000左右吧,32G的内存条。1000左右吧,好,那你买一个1T的固态呢。你再买一个1T的机械呢?对吧。1T的固态大概在八九百吧,我就打1000吧,八九百左右对吧,哎,也就1T。固态跟32G内存价格差不多。你要普通磁盘,你四个T的硬盘对吧,你现在买个移动硬盘,四个T的才几百块钱吧,不到1000块钱,那这个价格也就是说基本上来说,我们可以说这个,呃,固态。
07:06
要比这个机械要贵个几倍,但是你要跟内存比,那可不是几倍的事,对吧,所以呢,用户数据量大,你是内存数据库对吧,内存数据库不好。啊,不好,对吧,能不能存呢?一定要存也可以,但是呢,很明显不好,投入太多了对吧?问题在这,好,那接下来克里克house可不可以呢?Click house永久存储啊满足对吧?根据主键查询也可以啊,对吧,我will根据一个主键去查询。也可以。对吧,是没毛病的。这个。好不好呢?查询的效率也很快,单表对吧,单表根据主键去查询效率也很高,那这个好不好呢。克能不能行呢?可以直接打勾。
08:01
对吧,海量数据永久存储,然后呢,根据主键快速查询,对吧,目前我们在想到是它好,它到底好不好呢。就这个能不能行呢,有没有问题呢。语法不行。语法为什么不行?啊,搜个过多不太好啊,事实数据一大,你查询的就很多对吧?啊并发不行啊,这是一个点啊,就是说并发不行。还有呢,还有没有。就这个我就不写了吧,我就直接写他缺点啊,因为感觉到他克里号草他不行对吧,我就写缺点好并发不行,还有没有还有一个东西啊。还有一个东西。这个大家报了吗?
09:03
明白吧?它是裂存。对吧,而我们这个维表。最好怎么存啊?所以你看我要根据主键查询一行数据吧,是不是行存是最好的。大家想,是不是航存是最好的?对吧,我要根据主件查询一行信息嘛,那必然行存更好嘛,那你这个课列号是什么,是列存,然后呢,呃,并发不太好对吧,太高的并发不太好,那所以呢,从这个角度来说,我们不用克雷house,那换句话说,你h base刚才我们没有考虑这个问题,对吧?现在我们想一想,那h base这个东西它是航存还是列存?
10:00
我们是不是也得考虑一下?它是航船还是列传?啊。评论同学告诉我。哎,方总说了可行可列,对了,它可以做成行存,也可以做成列存,这个主要在于什么呢?在于你的列组,或者叫列错,对吧,你应该如何去设计,我举个例子,比如说我现在呢,一个表对吧,还是位一个表有三个零啊。我呢有三个类。现在呢,我如果说我只有一个列族。它是行存还是列存,大家告诉我。
11:02
它是一行数据紧挨着,还是一个列的数据紧挨着?我。有三个列,但是只有一个列足,这个时候它是行存还是列存?对了,这个时候呢,它是行存。啊,他是航船。啊。为什么呢?我们讲啊,在我们数据呢,是存到HDFS的,那么它一个列组是一个文件夹。是一个目录对吧,它一个列组是一个目录,是一个文件夹。好,那么我们想你呢?有三个列,放在一个列组里边。对吧,那就是说这三个列呢,未来是存到一个目录底下的,那未来刷写下来就是这三个列呢,在一个文件里边,如果说都有的话,是不是这三个列在一个文件里边没毛病吧?好,那么我们知道无论是在内存还是在磁盘h base里边的数据啊,它都是根据什么,根据r key进行排序的。
12:11
那我一行数据有三个列,那三个列的rookie肯定一样的,比如说我存1001A,然后接下来存1001B,接下来存1001C,然后才会存1002。ABC吧。对吧,因为我要根据rookie进行排序,我要等第一个rookie存完了才会存第二个rookie,所以这样看起来我们是不是一行数据在一起。对吧,这个呢行存,那换句话说,如果说呢,咱们的数据是这样子的。是一个什么叫三个列,同时有三个列组,每个列有专门的一个列组,对吧,那未来呢,在HDFS它是不是对应的有三个目录啊。三个目录,每个目录里边呢,放一个列那。
13:02
这里边1001A 1001B对吧?A1002A1002B,这边呢,1001C。1001啊,1002C对吧,你看这个时候它是放在不同的目录的,那这样看起来是不是咱们的。列是放在一起的呀,对吧,所以刚才有同学说了对吧,说这个地方呢,H base它可行可列。啊好,那我问大家,未来我们要用的时候,我们应该设置几个列组,就是这边如果我们选用了h base作为我们的DM层存储,我们该设置几个列组?我们是根据有多少个列,设置多少个列组,还是说设置一个列组,大家告诉我。我们希望他航船对吧。我们设置列足的个数应该是多少个?
14:04
对了,就一个吧,就一个就够了。啊,因为我们希望它是航存,希望它是航存对吧,所以呢,通过格里house引出来一个问题,我们回过头来呢,H又解决了这个问题,对吧?好,接下来这个ES。ES能不能行呢?根据主见。查询永久存储好像也可以,因为在ES里边咱们有一个document的ID do cid,对吧,这个可以作为主线,同时它还具有幂等性,假如说你改了,我也可以用幂等性把这个数据呢,改掉,你也不会查出来多条,感觉也可以啊,对吧。那我们ES这个好不好呢?根据主键查询一行数据。
15:01
好不好呢?其实它不太好,为什么?因为ES里边它是不是会做一个切词啊,就是说它默认的,你要注意默认给所有字段分词处理,对吧?呃,你不想分词需要额外指定。就是说这个分词处理呢,就见索引,它会给你所有的字段去见索引,然后呢,还分词对吧,很有可能分词见索引啊,就是所有字段见索引创建索引了,而我们只需要根据主键查询,我不会根据里边任何其他的一个字段查询,我只会根据主键查询,那你默认键索引,那你不是相当于什么呢,杀鸡用牛刀吗?对吧,那你还要给每一个字段去指定一下,说我不见,所以。
16:04
对吧,因为你不建索引,需要额外指定ES的默认都建索引,那其实这个索引建出来没有意义,因为我不需要,我只需要根据ID查询,根据这个主线查询,对吧,其他的一概是不需要的,所以呢,这个地方我们就不用ES了,没必要,而且ES它API写起来。还麻烦对吧?啊,那h base虽然API也麻烦,但是h base有一个什么。X可以结合Phoenix写circle吧,对吧?那这样的话还会简单一点啊,Select from,一张表,Will ID等于多少多少就行了,对吧?好,这是我们所说的ES,它呢?不太好,不好的点我们也说了对吧,默认给所有的字段键索引好最后一个买so本身可不可以呢。买本身可不可以呢。
17:05
我们思考一下。哎,郭总说了可以。其他同学呢,什么意见?数据量有点大,查起来很慢。呃,那你要知道这个数据呢,它本身就是存在买的。买克顶不住事实啊,问题就说到这儿对吧,因为你看啊,呃,我们数据买S呢,它本身什么,你看啊,前台你去下订单支付,它是不是要用到这个MYS做增删改查本身业务这边要做对吧,现在呢,你Li做实时计算,还要查我的买S。
18:01
还要查我的买口,那这边的压力压力太大对吧,压力太大。因为它本身业务也要用。然后呢,你实时还要用对吧,虽然你实时是查,但是我本人的业务是要做增删改查,对吧,压力太大,如果你实在要用MYSQL可不可以呢?可以使用实在。要用就使用什么从库,不要用主库。不要用这个有写操作的这种能听懂吗?对吧,如果说你用的是从库,我只是去读嘛,对吧,My circle也能扛得住这个压力,实际上。啊,实际上也能够去扛得住这个压力,他不是说完全就。扛不住。对吧,啊,但是呢,它跟其他的大数据框架相比,数据量大了以后,对吧,跟这个大数据框架比肯定还会差一些,但如果说我们启用从库其实也能用。
19:07
OK吧,就是你不要用主库。就是你本来就往这个数据往里写,你还从这读,不要这样做,你用从库。OK吧,所以在这里边呢,像我们买本身以及这两个都可以啊,但是买S呢,你要建这个从库从表对吧,而S呢需要导一下,那这里边呢,咱们最终在这个项目里边选用S,因为毕竟你要考虑到数据量一大。实时这块这个压力请求对吧,过多,那这个呢是读请求,你又不能像写说我搞一个批量写出。对吧,这一块读,那就来一条,你就得查一条。实时的我读的数据量可能非常非常大,对吧,你买三个压力呢,还是太大了,就是说实时这样的查询可能还是顶不住,对吧,还顶不住,所以呢,他其实可行啊,如果说你的公司当中这个高峰期的数据量。
20:05
高峰值速度没那么大对吧,其实用MYSL也可以啊,但是呢,你如果峰值过大,那其实建议不要用这个my circleq啊,因为他查询的时候呢,呃,效率肯定会偏低一些啊,很有可能就扛不住,对吧?所以从这里边来说呢,最好的选择是不是还是贝散,就我们所学习过的框架啊,当然我们没学过框架还有很多,那其他的可不可以呢?也有很多。对吧,还有其他的很多都可以啊,但是呢,我们学过的框架里边,我们把它列出来了,那就当然其实学过的框架里面还有一个东西啊。还有个东西我写一下,但是这个写出来大家都知道,他肯定不行啊。或者说是这个这个肯定不行,但是我们写在这儿,他也能做存储对吧,效率太低,这个没问题吧,啊我就快速写一下,这个呢,大家肯定都比较清楚。
21:06
我好难受啊,你们难受吗?对不起啊。呃,那就这样吧,这个挺难挺难过的啊。那就这样好好对吧,最终呢,我们选择的是HB作为我们DM层啊,理由呢,都在下面给大家列出来了,对吧,这一套就是你未来工作的时候啊,其实你会发现会的人越多,你发现有时候取舍东西就会麻烦,对吧,你得都得考虑到啊。
我来说两句