00:00
好,当我们介绍完这个GM调之后呢,再往下啊,你可以看到我们讲的这个h base啊,底层的原理很复杂对吧,能够修改的参数呢,也非常多啊,那你说我刚开始使用的时候,难道一定要把这所有的内容全部掌握了之后再去使用吗?啊,好像有一点点晚了,对不对?那这里呢,就给出大家一个最直观的一个经验法则,你按照这个官方给我们提供的权威的使用法则呢,你用起来这个h base斯的性能啊,就能够得到保证了啊,这就是我们常说的对不对,你要是追求极限的话,那你就给它进行一系列的优化,你要说只是一个常规使用的话,你按照这个体系来已经能够发挥它至少80%的性能了,这能理解吧,就跟我们玩电脑是一样的,对不对,你买那些正规的产品,它它总是能发挥到一个标准线及格线以上的,你想要发挥它的极致,那你自然需要去执行大量的一个操作,对吧?好,我们一起来看一下官方给我们的权威的使用法则啊,第一点,Region的大小要控制在十到50个G,默认事实。
01:01
十个G,你可以调大,那个大神呢,推荐我们调到20个G,但你不要调到超过50个G,其中这个意思啊,也不能太大对吧?啊,太大也不行,受不了啊,第二个cell啊,细胞的这个大小,就是每次你往里面传的最小的一个数据大小不能超过十兆啊,不能超过十兆,其实啊,他想说的是你最好不要超过100个K。啊,一条cell的数据应该是比较少的啊,应该比较少一条数据嘛,不要超过太多性能,对于小于100K呢,还有对应的一个优化,100K大概是0.1兆,这个数据足够你使用了,不要太大,如果你一定要使用太大的一个这个,呃,单独的一条数据的话呢,推荐大家使用mob啊,就是直接存储对象的一个形式,这个也比较合理,你存储数据你总是存不了这么大的。十兆的数据你可能没法想象对吧?这玩意儿要写成文本的话,都快够一本小说了,一般存不了这么大,我们存多大呢?可能是一些比较特殊的东西,那这里呢,就会有专门的一个用法,存对象,直接在里面存一个比较复杂的对象也可以啊,使用这种特殊用法能够让你达到十到50兆的一个性能啊,不要超过50兆,50兆有点太大了,咱看红楼梦了,在里面。
02:17
也不要超过这么大啊好,这个用法呢,如果你感兴趣到官网上搜都是有的,咱们呢,因为实在是用不到啊,就不做介绍了,再往下一张表的列足呢,最好是一到三个,不要涉及太多啊,最好最好就一个啊,就一个列组啊,如果太多的话呢,你。如果你使用过多个的,你也要尽量保证不会同时读取多个列组啊,你单个列组呢,应该是分开来读取的啊,因为你读多个列组的话,它一定是有一个region。来进行操作的。能理解吧,如果你一个表里面有十个列组。啊,十个12345对吧,十个列组一共好,如果它有十个列组的话,你同时读十个列组,它肯定是在一个region里面的,一个region里面就意味着是由一个节点。
03:07
对吧,是由一个节点来处理的,没有办法并发啊,一个表有太多列足一起去读,没有办法并发,一定是一个节点去处理的,效率会很低啊,所以我们设计的时候啊,列足最好是设置少一点,最好就一个,官方都告诉我们了,最好就一个,那你还没有想明白吗?对吧?一个能解决很多问题,前面刷写的时候也没有小文件问题啊,最好就一个在下面啊呃,一到两个列足的表格呢,设计五五十到100个region是比较合理的啊,就是你设置的这个列足啊,最好是一到两个,最多不要超过两个了啊,但人家说了极限范围一到三个啊,推荐最好就一个啊,实在想用用两个哈,这么一个范围好设计的时候呢,最好是50~100个region,咱们前面刚才讲的时候,为了比较好对应,所以我说了120个region,是这样吗?啊在实际开发的时候呢,不要设置这么多个region region多了。
04:01
对应的那个memory store写缓存也会增多,一个region一定会有一个写缓存的,即使你是一个列组对不对,那你写缓存也会增多,写缓存太多的话,一样不影响它那个刷写啊,Region不要设置太多,50~100个比较合理啊,你可以自己去对应一下,你比方说你一定要是12的倍数的话呢,你可以设置呃,乘一个五六十个。对吧,啊,一个分区呢,对应五个,一个月份对应五个region就可以了啊,可以自己去算一下啊,再往下列足的名称要尽量短啊,不要去模仿RDBMS就是关系型数据库,具有准确的一个名称和描述。在非关型的数据库里面,就比如说我们HP里面列足的名称,还有那个列的名称都是一定要尽量短的啊,一定要尽量短的,如果你能用数字1234表示,那最好不过了,但一般情况下这样不太好读,对不对啊,那你写的时候呢,一定要尽量短,为什么不要跟关系型数据库一样呢?给你简单说一下你就知道了。
05:03
在MYSQL里面列名呢,我们会写的尽量详细,尽量复杂一点,让他一看就知道什么意思,这是因为MYSQL里面的表格这个列名啊,永远只使用一次。它是一次性的,在表格里面,它列面就是它那遗留下来圈是它就使用一次,但是在我们非关系型数据库里面,是用KV的结构来进行存储的,它就意味着每一个cell底层存储的每一行的一个KV都会写一遍这个列组都会写一遍那个列名啊,如果你这个列特别长的话,它占用的内存会翻倍啊,占用的内存和磁盘空间会翻倍,所以列足的名字在非关系型数据库里面一定要小,这是一个通用的逻辑。所有的非关型数据库都会有这么一个限制啊,列足名称,列的名称一定要尽量短啊,再下一个,如果RO设计时间在最前面,会导致大量的旧数据存储在不活跃的region当中,使用的时候仅仅会操作少数的region,此时呢,建议增加更多的一个region个数啊,就是说如果你设置那个时间啊是在最前面,那个date是在最前面的。
06:10
它会导致呢,大量的一个以前的数据的时间,比方1990年的这个数据啊,它会始终保持在固定的那几个region进里面啊,固定在里面,它这个region里面的数据呢,会始始终保持不变,对不对,那这时候呢,会持有少数的这个region去活动啊,大量这个region呢会保持不变啊,那这时候呢,建议你增加更多的一个region进个数啊,不知道大家能不能听懂,就是说如果你不去预分区,它这个地方其实说的是不预分区,如果不预分区直接按照时间来的话,那你前面这个region进的范围就是1990年的数据到2000年的数据,下一个呢是2000年到2010年,再下一个是2020年到2010~2020,对吧,再下一个才是2020之后的,那你说这四个region我们会用哪个呢?是不是大量就使用这一个region啊。
07:01
有很多region都不使用,对吧,有不使用,那这时候你有几个选择,像我们一样增加预分区是更好的一个选择,像他这里呢说诶如果你实在容设计搞不明白啊,没有办法增加预分区的话,你就多加一些region镜的个数,也能缓解这么一个现象,如果少数的re镜活动的话,会导致什么现象呢?并发没法很好的实现,对不对?我们负载均衡就是为了多个region。分配给多个server啊,使用的时候呢,多个人server一起去操作,效果是最好的啊,你这种呢,只操作一个人,可着一个羊毛薅,那羊肯定受不了对吧?哎,你呢,多加几个羊可以缓解这个状况啊,像我们一样给它拆分来多个羊一起薅,那肯定是更好的啊。这是我们第六点,第七点,如果只有一个列足用于写入数据分配内存资源的时候呢,可以做出调整,即写缓存不会占用太多的一个内存啊,如果我们前面设计的都比较好的话,就按照他的要求来的话呢,也缓存就不会占用那么多的内存了,因为什么?因为memory store的个数有限。
08:09
啊,个数有限,它的个数一个memory最多不就128兆的数据吗?它是有上限的,对不对,如果我有十个memory的话,它最多最多占用内存就是1280兆。它是有一个上限的,如果我的GVM有16G的话,它有40%都是给这个memory对不对,你一乘啊,大概算下来呢,是呃,6G多对吧,6G多都给他,但他只能用一个G,诶你感受一下是不是它不会占用这么多内存啊,你给他6G也白瞎啊,就是这个意思啊,就这个意思啊啊一般来讲呢,我们也不会只有十个region对吧,只是给大家呢简单做一个介绍,你可以提前去算一下,分配资源的时候呢,可以给这个写法子呢,适当调小一点啊,但这个就比较精细了,对吧?哎,也是给你提个醒啊,那这个呢,是我们官方的一个使用经验的一个法则啊,按照这个来就已经能够发挥它80%的性能,你想要发挥极限,那就按照上面的ROK设计参数调跟GM调优来就可以了啊。
我来说两句