00:02
好,我们接着来说啊,呃,这个刚才把事实数据已经分流完事了啊,然后下面就是我们的维度数据了啊。那这个维度数据的话呢,我们之前也这个说过了啊,我们要把它这个分流到这个中。明白吧,分流到中啊行。好,那接下来。你要往RA中去写数据了。对吧,那我们这个时候就要先想明白一个事情。什么事情呢,你用什么类型。对吧,比如说怎么串呢啊诶怎么串啊,List呀set呀贼site哈西好吧,想一想啊,然后呢,你的key怎么设计好,你的value怎么设计,OK,然后呢,这个写入API我用什么?将来这个我要去读了,对吧?那我的读取API我用什么。
01:09
好,最后呢,这个过期吗?行吧,又是这么几个问题。啊,只要你使用这个red,你要往里面存数据了,你都会涉及到这么几个。问题啊,你得把它先想明白了啊,我应该怎么去存。呃,先明确类型吧,明确了类型以后,下面的东西自然而然也就出来了啊,其实主要还是这个类型的一个选择啊。行,来这个大家投个票吧,现在我们想存数据了啊,比如说啊,就是我们多了不说,我们就拿这个用户用户的这个用户表来说啊。来。打卡表。User。诶,这就是user info是吧。好,来看一下啊呃,我就简单截截点图吧,好吧,简单截点图拿过来啊。
02:03
行看一下吧,就现在我是有这个用户数据的啊,就将来我要把这些东西呢,给它存到我这个red中啊,那么你来这个分析一下我用。哪种类型?大家投个票吧,啊,你觉得用哪种比较合适啊,你就把它打到这个聊天窗口里面啊,我看一下。好,抓紧时间啊,来,都想一想。哈希,嗯。这个,韦哲和李帅说。还有董七啊,都说哈希是吧,嗯,行,来哈希的有人投票了啊。别的呢,有没有?啊,有没有偷别的的呀,同学们都是都是哈希吗?
03:05
Site。List。List啊,List也有哈。还有别的吗?没啦。行,来,那我们一起来这个分析一下吧啊呃,投了这个list和site,还有这个哈希啊,然后呢,这个字符串,这个赛没用投票啊行,那我们来分析一下到底用哪个啊呃,先说这个list和set吧,好吧,啊,这两个其实都是大家,呃,如果说你想用这两个的话,应该考虑的点都是一样子的,就是一对多。对吧,就一对多啊,大家很明显发现我们现在是有很多条数据的啊,那么大家就想到了说诶,那我应该要用一个类似于什么集合啊这样的一种类型,然后去存,对吧,比如说我的每条数据就是呃,当成一个元素,然后存到你这个集合中啊,应该这么去想的啊,行,那我们就来分析一下啊,拿这个list和这个set纯呢合不合适啊,首先啊,它们是一个集合类型的,那就说白了,我将来有一个KK里面的话呢,我对应的是一个集合。
04:19
对吧,如果说你要用list或者用set的话,那么你应该是这么去存,就是在你的。每一个这个类里面,或者set里面,你要把你的每条数据呢,诶单独存成一个值对吧,然后呢,每条数据呢,单独存成一个值,对不对,你要这么去存吧。好,那么这么穿行不行呢?这么穿可以。呃,但是大家一定要想明白一个事儿啊,你纯数据,纯数据,其实不仅仅是为了纯呐。你存下来,我们更重要的是不是将来我要去把数据再给它读出来呀,我得用啊。好,那现在我来问你啊,假如说我现在想让你去帮我读一个ID,为这个这个一的。
05:02
用户好,假如说你这么存的啊,这是IDV1的,这是IDV2,这是IDV3,这是IDV4。对吧,好,那我现在想让你去把这个ID唯一的用户给我读出来,你要怎么去读啊。如果你用的是list的话,或者你用的是这个set的话。你要怎么去读啊。你想想啊,你读的时候这个事情是不是很麻烦的呀。对吧,你得怎么去做了,因为它是一个整体,所以说你每次读的时候,你得先把这个整体呢,全部给我读出来。读出来了以后呢,我再从它里面去迭代,然后呢,去找我想要用的那个数据。对不对。就你不管是读一个也好,或者读两个也好,反正这个整体你都得给我拿出来,你拿出来以后呢,然后我再什么呀,我再去从里面去找我想要用的那个。那你想想你这个过程,你找起来方便吗?
06:02
你找用户方便吗?不方便对吧,你想想啊,如果说我是在你这个MYSQL的存的,我知道你的ID为一,那我从你这个表里面去查数据的时候,我是不是只要给个条件VID等于一,我是不是拿你的ID可以什么直接去定位的吧,但是呢,你存到这个red中以后呢,你发现诶我不能够什么直接去定位了,我只能是什么先把所有的数据呢都查出来,查出来以后呢,我再从中去找,诶我想要用的那一个。你变得更加的复杂了。对吧。所以说你这么一分析啊,其实list和set是不太合适的。啊,那这个贼也肯定不合适。对不对啊,说这几个就直接把它排除掉了啊,这个想都不用想啊,肯定是不太合适的啊,那这个剩下的应该就是我们这个哈希和这个字符串了啊呃,这两个啊,大家没有人去投这个字符串啊,其实字符串应该是比较合适的啊,这个哈希行不行呢?哈希也可以。但如果你要使用这个哈希的话,你得想明白这个哈希怎么去纯。你能听懂吧,啊哈希怎么去存,大家的想法应该都是这种想法,就是我整个表我存一个KV。
07:07
对吧,整个表存一个KV,你看啊,你不是哈希吗?那我就可以这么可可以这么去存啊,我的K呢,那我就什么比如说K,我就叫你的表的名字吧,对吧,就叫什么U3音能理解好,那因为你是哈希,那么后面存的是你的fair的value,然后呢,Fair的value。对吧,大家可能这么想的啊,那你的field呢,我就拿你的什么呀,拿你的这个ID,比如说你是个一,然后这个value是什么呢?VALUE6就是我的整条数据。对吧,然后呢,Fail的是二,然后value呢,就是我的整套数据。这样的话,将来我再去查,比如说我想查ID为一的,ID为一的这个用户,那我们是不是可以什么直接从你的这个哈希里面来一个什么h get对吧,我指定一下你的key,然后呢,我再指定一个fair的,比如说我指定一个一,或者指定二,我是不是可以直接把你的数据给它调出来的。对吧,这个查起来也是比较方便的,存起来也行,查起来也可以。
08:00
就是我可以做到点查啊,我可以做到点查,啥叫点查呢?我给你一个ID,然后呢,你立马把我什么定位到这个数据,你不用去做什么筛查,你不用去做过滤,对吧,你直接什么定位到这个数据。啊,你起码要做到这种效果。对吧。啊,那这个行不行呢,这个是可以的,没没有什么问题的。就从我们存储以及使用角度来讲的话呢,它还是比较方便的。啊,还是比较方便的。好,但是啊,呃,这里面我们得去考虑另外一个问题,这个问题大家可能可能这个没有想到啊,不过现在的话,我们应该涉及不了这个问题啊,就是数据量的一个问题,数据量。啊,你要听好了啊,如果说你敢把一个表存成一个KV,在我的这个red中去做存储。好,那假如说我这个表中的数据量特别特别的大,那就表达你的这个整个KV所维护的数据量也会特别特别的大。好,那你先要去考虑一下你的red能不能够。
09:00
维护得起这个数据。对吧,就是把它维护成一个KV,因为你一个KV你就必须得放到你的red的一台节点里面去做维护,就哪怕你是个集群,那你的这个数据也得什么由一个节点去做维护。对吧,当然哈,我们不可能说一个表的数据量就大到说这个一个节点维护不下啊,这种情况一般不存在,但是你还得想另外一个问题,就是因为你把它呢交给了一个KV进行维护了。那么将来如果说你对这个数据的访问是特别特别频繁的,而且是高频次的访问的情况下。那你就想吧,因为你是把它交给red的一个KV进行维护的,你所有对这个数据的访问,你都会打到red的同一个节点上面。那你要去考虑一下,你的这个red这个节点能不能扛得住这个压力。能听懂吧,能不能顶得住这个压力?OK吧,因为你的数据它是维护到一起的,他没有分散开来,那我所有的请求都得打给他。
10:00
对吧,这个时候你就得去考虑一下这些问题了啊,首先第一个我维护的这个大小,我能不能维护起来,再一个我能不能顶得住将来这个高频次的一个访问。听明白了吧,同学们啊,说是你使用哈希,你要说什么,把这个整个表,然后呢,存成一个哈希的话呢,你要去考虑这个问题啊,来我们这个解释一下吧,好吧,呃,哈希啊,就是我们就整个表啊,整个表然后呢,存成一个哈希啊,要考虑什么要考虑。数据大小,数据量大小及这个高频访问问题啊,高频访问问题。对吧,而且啊,大家注意大家可能在想,诶,这个数据量如果说目前不是很大,那我可以去存,然后呢,高频访问问题的话呢,一般来讲啊,对于red来讲,这个高频访问问题不在话下,它解决的就是这种高频访问的一个什么这个这个问题。
11:00
对吧,因为它是能够什么这个支持特别特别高频次的这个访问的啊,你这个并发再多大,这个一般也能扛得住。好吧,啊,但是呢,这里面还会隐含另外一个问题,就是你目前你的数据量不是很大,那不代表着你将来的数据量不大,所以你要想明白将来我的数据量会不会增长。啊,会不会什么这个爆发性的这个增长,如果会的话,那就很有可能会导致将来,诶你的数据量大到我的一个节点维护起来有点吃力的,对吧,有点压力的情况。这个时候。你哭都来不及了,为什么呢?因为你想的说,那我这个维护不下数据以后,那大家想着说那我要扩容对不对,你要去做扩容,你怎么扩容啊,你扩容如果说你是一个纵向扩容对不对,啥叫纵向扩容,就是我在我的当节当节点里面,就在我在我的当前那个节点里面,比如说我加硬盘对吧,加什么加内存。这个你只能扩容到一定程度,你就不能再扩容了,因为你的服务器不可能无限制的去加硬盘加内存的。
12:02
好,那假设说你已经扩容到上限了,但是呢,我的数据量呢,还是有点够呛,对不对,还是维护一下有压力,那你只能在做横向扩容,就是我再去加red节点,能明白吧,我把它搞成一个集群。但其实你搞集群是解决不了这个问题的。因为我们知道red集群它是分成了16384个slot,对不对啊slot,然后呢,你的每一个key它都要经过计算,然后呢,确定出来你在哪一个slo里面,那就说白了,只要你的数这个数据是基于一个KV维护的,那最后你算出来以后呢,它一定还在某一个lo里面,那你的某一个lo就一定还在。某一个节点。就相当于你虽然说做了这个横向扩容了,你有了很多台这个什么机器了,但是你的数据呢,还是只能够在一个节点里面维护。你没有办法把这个数据给它打散了。听懂了吧,所以说这个要注意的啊,要考虑数据量大小,要考虑目前对不对啊,目前数据量大小以及及啊数据量大小及什么呀,呃和啊将来数据增长问题啊,数据量增长。
13:20
问题。好急什么呀,急这个高频访问问题。理解吧,啊,这是你要去考虑的啊,行,呃,那这是我们这个哈希啊,整个表纯成一个哈希,那么当然呢,还有同学可能是这么想的啊,我还是使用哈希啊,我还是使用哈希。好,但是呢,我是不把整张表存一个哈希,我是什么一条数据存一个哈希,一条数据存成啊存成一个哈C,那这又是什么方案呢?啊,比如说我的我就把这条数据拿过来啊,那我存的时候呢,我的key怎么设计呢?K就是你的表对吧,再加上你的什么组件ID就就可以了,就你能够标识你是哪个表的哪条数据。
14:08
那我的fair的value怎么存呢?就是你的字段的名字,Value就是你的字段的值对吧?Fail就是你的字段的名字,Value就是你的字段的值。能理解我这个意思吧,那我这么去存也可以。好,那么这么存的话呢,呃,行不行呢?我觉得可以没有任没有什么问题对吧,但是你要考虑是我有没有必要把这个数据给它拆开,因为这样的话就相当于什么,相当于把这个数据一个一个是不是都把它解析出来了呀。对吧,解析出来以后,单个字段,单个字段的什么去给他做做一个什么存储啊,那你这么存的话呢,你要考虑一下我以后会不会用到这个东西。你这么蠢。我比较方便的是我可以。任意去调用你的某条数据的某个字段,对吧,任意去查找某条数据的某个字段,这个是非常方便的,能理解吧,但如果说诶,你将来这个后续的这个处理过程中啊,你很少说会有这个,我要单独的去找某条数据的某个字段。
15:09
对吧,如果说没有这种需求的话,那我觉得你没必要这么去存,你说你辛辛苦苦的把数据解析出来,然后呢,存成每一个什么fair value了,但是我将来的话呢,我还不去查。那你这么存不就相当于白存了吗?对吧,或者说将来我确定要去什么,去查你这个数据,但是呢,我不是查某个字段,我可能查一下子要查很多个字段。对不对,那你一下要查很多个字段的话。你就那什么一个一个往出往往出去掉。对吧,那还不如我直接把你的整条数据我都拿出来,拿出来以后呢,比如说你拿出来以后什么再从你里面什么把每个字段都提取出来,这样是不是也可以啊。对吧。所以你这么分析完以后的话,其实你会发现我纯成一个哈希可以,但是呢,我其实也可以什么呀。我直接什么把它串成一个字符串。
16:03
对吧,一条数据全成一个什么战神符串,对不对,我就直接把你整条数据就转换成一个什么战神字符串。能理解吧,粘成字符串,我就什么当成一个字符串去存了,好那如果说将来我没有说这个非要什么单独去调用你的某个字段的这个场景。那我这种方案肯定是可以的。对吧。如果说我们将来的场景是我想什么直接把你的整条数据拿出来,然后呢,从你里面去获取很多个字段,那这个时候你存成字符串也是比较合理的,因为我可以把整张数据调出来,调出来以后呢,我把它什么转换成什么加成对象,那我转换成这个摘胜对象以后呢,我是不是可以非常方便的去从里面拿你的每个字段了呀?对吧,这样是不是也是OK的呀,同学们。嗯,所以说你这个相对来讲的话,这个性价比比较高的啊,应该还是这个字符串会比较好一点。听明白了吧,啊,当然这个这种方案也可以啊,也可以就是看你有没有必要在这个纯的时候,就把这个每个字段呢,给它解析出来,然后呢,纯生什么单独的fair的value fair value。
17:11
理解我的意思吧,啊,你有没有必要去做这个工作啊,你自己去琢磨一下。好行,那么这两种方案的话,其实这个都差不多啊,它都是把你的一个表呢,其实是什么存成了很多个KV了。OK吧,那么他们的一个不好的点就在于我的一个表的数据呢,没有存到一起啊,这其实也是一个不好的点,就是它把数据呢,分成了,分散成了很多个KV,那么就导致了你的RA中呢,诶会有很多个KV的什么存在。对吧,这可能是我们感觉不在好的一个点,但其实对于red来讲,这个根本就不在话下,你能明白吧,因为你的每个KV呢,它都会什么会帮你做一个计算,你的K在什么地方存的,我将来找的时候呢,我都是么按照你的key去找的,我都是一个点查,至于你的key有多少,对于来讲这个压力不是很大。所以说我们不用去担心说,哎哟,那你存的这个东西也太乱了,对吧,或者什么太散了。
18:02
不用担心,就是说就是做这个事的,他就是来支持你这个KB存储的。明白吧,啊,说这个并不叫问题啊,而且呢,它反而能够带来一个好处,就是将来当我们这个数据爆发性增长的时候,好在我们的每条数据呢,都存成了一个KV,那你想想我们做了横向扩容以后,对吧,我的做了横向扩容以后,因为你是存成了不同的KV了,那我的key经过计算以后,我大概率情况下会算到不同的slot里面,那你不同的slot就会大概率放到诶不同的机器里面。这样的话呢,其实我的一个表的数据呢,其实可以什么分散到多个red节点里面去存的。明白吧,也就能为什么做到这个横向的扩容,做到这个什么负载的均衡。OK吧,同学们啊,这个事情你要能够想得到啊,行吧,那我们这个综合这个分析了半天啊,这两种方案都可以啊,那我目前的话我就选择最后一种了啊,这种方案因为它稍微会方便一些,就省得我去解析你的每个字段了,对吧,我就什么直接一条什么字符段数据给你干进去就完了。
19:03
好吧,行,呃,那这个分析明白以后,那我们就什么最终采用这种方案,那keep的话呢,将来怎么设计啊,Keep就是你的表明加你的字段的什么表面,加你这个数据的一个什么组件呗,我得明确你是哪个表的数据,你还得能够什么通过组件方便的找到你。对吧,所以我们的key的话,我们就是表明啊,就是你的表明啊,这个表明好再加上表的名字啊,好再加上你的这个ID,就组建ID。好,那当然哈,我们一般呢会呃,让你的这个K呢,有一定的含义,所以说我们告诉他这是我们的维度啊,那我就加上个DM吧。那行吧,诶加上个DM啊行,然后这个VALUE6的话,就是我们一条数据的摘啊,一条整条数据啊,整条数据的这个摘格式对吧?摘字符串OK吧,好行,那这个写入API,那你都用字符串了,那写入的话肯定就是site了呗,那读取肯定就是get了呗。
20:06
对吧,这个很简单啊好,那这个数据过期吗?同学们。这个应该不用分析吧,这个数据肯定不过期啊,因为你是一个维度数据,你不能说我今天用完了,我就把数据给你删了,那我明天我就不用了吗。对吧,啊,你明天还得用啊,说这个数据不过期啊,你就存到这个里面,就一直存着吧,除非说将来我的这个什么实时任务我不跑了,我不用了,那我才可以把它什么删除掉。对吧,只要你的实施任务还在,那你的这个数据就不能过期。OK吧,行来这是我们这个,诶纯维度数据啊,我们对这个RA的类型的一个这个分析。啊,其实每次我们时间呢,就花到这个分析上面了。因为我得给大家去说明白哪些类型,我们可以用哪些类型比较合适啊,这样的话慢慢的就会给你们,呃,这个这个潜移默化的啊,就会给你们什么呀,灌输一点东西就是啊,将来我在用的时候呢,我也能够学会分析啊,就当前我要存的数据的格式是什么样子的,对吧,那我在里面存的时候呢,我都可以有哪些种类型去存储,哪些比较好,哪些不好,你也就怎么知道去分析这个优缺点了。
21:11
明白吧,说这个分析过程其实是很重要的啊,有些同学呢,他可能说,哎呀,这个分不分析的无所谓,我只要知道这个最终的结果就行了,我跟你讲那个结果它不是标准答案,它只适用你当前的这个场景,你再换一个场景,就不一定要使用这种格式了,你可能要换别的格式了,但是换什么格式,这就得你去分析了呀。明白吧,说这个分析的过程是很重要的啊,你一定要把这个事情给它当成一个重点去看。那至于最后的结果,那结果谁不会写啊?我都把答案告诉你了,谁不会写啊?对吧。这个一定要跟着去去分析的啊,行好,那我们就先分析到这儿啊,然后接下来我们就可以通过代码的去实现啊。
我来说两句