OushuDB(MPP)硬件配置原则
OushuDB是一个数据库产品,在企业系统框架里数据库属于比较核心的地位,所以一般数据库产品我们会考虑几个方面
性能原则
有一个误区,由于OushuDB存储使用的是HDFS,很多说法是HDFS对硬件要求不高,选用HDFS就是要降低硬件成本,这也是这种项目与传统数据库的优势。
其实这种说法是不对的,也可以说是片面的,这种观念的产生,主要还是业务需求的问题,因为目前大部分在HDFS(HADOOP常见场景)都是属于历史数据存储,或者做简单加工,这种应用对性能本身要求就不是很高,响应级别也很低,那么硬件可能相对要求不是很高,所以硬件配置完全与应用相关,硬件是性能的基础,让我们想象一下在硬件无穷大的情况下,什么设计与优化都不必关心,当然这是不现实的事情。
我们要做的是在现有需求的前提下做最佳性价比的选择
均衡原则
配置均衡是硬件配置很重要的原则,不然会出现严重的浪费情况。
下面有几个例子:
配置1:cpu 24个核,内存256GB,网络万兆环境,两个机械盘容量16T
配置2:cpu 24个核,内存256GB,网络千兆环境,12个机械每块盘容量12T
配置3:cpu 24个核,内存256GB,网络万兆环境,12个机械每块盘容量96T
配置1的配置看起来很强劲,但是只有两块物理盘,最终会怎么样呢,出现了一个明显的"木桶",两块物理盘可能IO吞吐量才200多MB,那么在应用繁忙时cpu和网络都在等IO,这种配置还不如配个少点cpu,千兆网络,当然内存也不用那么高,因为配置高也用不到(当然不是绝对情况,cpu密集计算情况下cpu多点还是好的,但是一般作为离线的数据仓库产品,大量的批量操作使得IO使用都会很大)。
配置2也是同理,在其他配置都很高的情况下,网络是千兆的,那么千兆网络实际也就100MB带宽,12块盘一般都在1GB的带宽,由于我们是MPP架构,最终瓶颈全在网络上了。
配置3很有意思,我们看到似乎配置很平均,不过按这个配置每块盘8T,明显这是大容量盘,这里有两个问题。
第一个问题,一般我们扩容都是与存储相关的,如果一个节点的空间没用到50%以上有什么理由去扩容?申请扩容都很难,但是按这么大的容量,到后来计算能力很可能跟不上,就会出现"小马拉大车的情况"。
第二个问题,一般大容量盘转速都比较低,那么一进一出这个配置在项目后期会有很大问题。
所以总结一下,均衡不单要考虑项目前期,还要考虑后期随数据量上升,扩容的问题,才能保证系统与资源的健康良性扩展。
可靠性原则
可靠性是所有数据库产品必需考虑的问题,X86架构的PC服务器在稳定性上肯定不如小机,所以我们在软件实现了一定的高可用,不过由于硬件的不稳定导致的问题肯定会影响到软件,所以在选择硬件上一般要选择业界比较稳定的机型搭建集群。
OushuDB(MPP)硬件配置建议选择
我们的推荐:
处理器(CPU):双路(2*8核)/ 双路(2*12核) intel
执行以下语句,确定CPU是否有相关avx指令集
cat /proc/cpuinfo | grep avx (新执行器)
内存:128GB/256GB
网卡:one-port/dual-port 万兆网卡
mode=4绑定或者mode=6绑定
存储:12 * 2TB
SAS盘
RAID 5(Hot-Spare)或者RAID1+0 、条带化512KB、Read Policy为Read Ahead、Write Policy为Write Back
交换机:网兆交换机
建议开启LACP功能,做动态链路聚合,或者对应mode=6不做配置
处理器与内存
处理器推荐以当前情况来看,还是比较普遍的配置,性价比很好,需要注意的是目前我们只支持intel,并且CPU是否有avx扩展指令集(这个是我们新执行器需要支持的)。内存的推荐配置也比较普遍。
网卡
网卡方面,希望万兆并且条件允许的情况下最好4块网卡,因为一般设计会做内网与外网的的隔离,往往一个网段需要两块做绑定所以需要四块,绑定级别上一般选择mode 4或者mode 6,聚合以后可以保证高可用与负载均衡的兼顾。
存储
存储一般推荐SAS盘,SATA盘差了一点,SSD很少有全配的,1块两块SSD比10几块机械盘IO吞吐量还是不够的,所以SAS盘性价比比较好。
RAID配置
raid配置上推荐RAID 5(Hot-Spare)或者RAID1+0,虽然OushuDB有自己的数据副本,出现坏盘不至于影响应用,不过总归是一个故障,如果有一层raid保护可以更好的高可用,比如RAID 5(Hot-Spare)盘坏后热盘直接自动替换,一般磁盘在3年后会慢慢出现故障。另外RAID卡的缓存对性能也有很大帮助。
RAID卡选项
Read Policy为Read Ahead,条带化512KB
因为MPP数据库主要面向离线系统,操作大多是顺序读,所以块大点可以减少IO次数,Read Ahead也对顺序读有预读缓存的优化,所以建议这样选择,不过如果是随机读频繁的场景,就不太适合这种选择。
Write Policy为Write Back
Write Back在高速缓存性能上优于Write through,但是在安全性上Write through好。
Force WB with no battery
这个是在raid电池损坏的情况下依然缓存写,这样如果出现故障有丢数的可能性,这个要看取舍。