集群规模及容量估算
SeaboxMPP数据库规模及容量估算¶
虽然SeaboxMPP数据库支持在线扩容/缩容,以及通过表空间管理增加单节点磁盘容量。但仍建议用户在集群首次部署时要对集群规模及服务器配置做科学严谨的评估,主要原因包括:
-
扩容时,很难保证新增节点与原集群配置相同,尤其是服务器代差,同一集群中节点配置不一致容易造成新/老节点能力无法充分利用的资源浪费;
-
在线扩容虽然能保证业务连续性,但扩容过程中重分布任务使用较多计算及IO读写能力,对业务运行性能有一定影响。
强烈建议用户安装部署前从SeaboxMPP数据库技术支持处获取更多专业指导。
服务器配置及市场情况经常变化,且面向OLAP的业务场景差异非常大,具体的集群规模及相关硬件配置需考虑用户实际业务情况讨论。本节主要说明的是,SeaboxMPP数据库规模及容量评估过程中的一些原则及注意事项。
影响SeaboxMPP数据库规模及容量的主要因素主要包括:
-
当前以及未来可预见的需要存储管理的用户数据规模
-
当前以及未来可预见的使用场景性能需求
-
当前性价比较高的主流服务器硬件配置
其中,对未来可预见的容量及性能情况,需要考虑以下方面:
-
当前建设系统或应用的历史数据,周期性增量,数据保留周期及清理策略
-
未来可能建设或投产的新系统或新模块
-
性能方面要考虑业务对时效性的要求,尤其是关键业务的时效性,如某些实时类分析或联机查询分析场景
容量估算¶
通常情况,建议用户采购SeaboxMPP节点服务器考虑最主流的服务器,即销售量大、运行稳定、口碑较好的产品型号。后续扩容或服务器故障后的零备件替换较容易获取,同时维修或维护技能也较为通用。
按照经验,针对不同的应用场景,磁盘可选择不同的配置:
-
针对批量加工类场景,尤其保留较长时间历史数据的情况下,配置大容量SATA盘,确保容量充足
-
针对高并发联机查询场景,尤其是要求秒级响应时间的情况下,可配置SSD硬盘作为存储
-
如既需要保证近期数据的并发查询性能,也需要保留长时间历史数据,可采用SSD磁盘+SATA盘混合配置方式,近期的热数据存储在SSD磁盘
例如:某能源用户大数据平台既需要保障当日数据加工的时效性,有需要存储大量历史数据,其配置采用以下混合方式:
-
2*480GB
SAS盘 RAID1 作为系统盘 -
6*960GB
SAS SSD RAID5作为近期数据存储盘 -
8*4TB
7200RPM SATA盘 RAID5作为长期数据存储盘
该用户SeaboxMPP单节点总容量(数据盘)为(6-1)*960/1024+(8-1)*4*1000/1024
约等于32TB
计算可用磁盘容量¶
要计算SeaboxMPP数据库集群可以容纳多少数据,须计算每个executor节点的可用磁盘容量,然后将其乘以executor节点数。
从可用于数据存储的executor节点上物理磁盘的原始容量(raw_capacity)开始,即:
disk_size * number_of_disks=raw_capacity
首先考虑去除文件系统格式化开销(通常为10%)以及RAID级别。例如,如使用RAID10,计算结果为:
(raw_capacity * 0.9) / 2 = formatted_disk_space
为了达到最佳性能,通常不建议将磁盘容量全部使用,而是保持70%以下运行。考虑到这一点,计算可用磁盘空间如下:
formatted_disk_space * 0.7 = usable_disk_space
RAID磁盘阵列格式确定并获得最大推荐容量(即usable_disk_space)后,就可以计算用户数据实际可用的存储量(设为U);考虑SeaboxMPP数据库使用镜像机制进行数据冗余,那么这将使用户数据的大小将增加一倍(2*U);此外,SeaboxMPP数据库还需要保留一些空间作为查询的临时工作空间,该工作空间建议是用户数据大小的大约三分之一(work space = U/3)。即:
(2 * U) + U/3 = usable_disk_space
典型的分析型工作负载情况下,临时文件空间和用户数据空间的配置应遵循以下原则。高并发或查询使用非常大的临时空间的工作负载,建议保留加大的工作空间(work_space)。通常,可使用SeaboxMPP的资源管理功能来降低整个系统的吞吐量,同时降低工作空间的使用。同时,可指定临时空间和用户空间位于不同的表空间,将彼此隔离。
计算用户数据大小¶
与其他数据库一样,原始数据加载到数据库后,原始数据较数据库内要略大一些。SeaboxMPP数据库中,通常数据加载到数据库后,原始数据平均是数据库磁盘文件的1倍以上,不同的数据类型、表存储类型、数据库压缩等因素,均会影响该比例,可能会更大。
- 数据值存储
- 如使用表默认的存储类型,即heap类型,库内不使用压缩策略,数据按page存储,每行数据在实际大小的基础上再增加24字节作为page头;如使用列存储,即使用using scolumn关键字的表存储类型,则数据按列切分,每列单独一个或多个文件进行压缩存储,通常32K行作为一个block,每个block中值的最大值、最小值等统计信息会额外存储(称为稀疏索引),SeaboxMPP数据库列存储支持lz4、zstd、gorilla等压缩算法,通常情况下列存储的压缩比可达1:5到1:10:。
一般来说,建议使用尽可能小的数据类型来存储数据(如知道该字段可能具有的值)。
建议尽量使用列存储作为表的存储类型。
- 索引
- 在SeaboxMPP数据库中, 索引和表的数据一样,也是分布在多个executor节点上。默认索引类型是B-Tree。因为索引大小取决于索引中的唯一值的数目和要插入的数据,所以预先精确计算索引的确切大小是不现实的。通常,可使用以下公式粗略估算索引的大小。
-
B-tree:
unique_values * (data_type_size + 24 bytes)
-
Bitmap:
(unique_values * number_of_rows * 1 bit * compression_ratio / 8) + (unique_values * 32)
计算元数据和日志的空间需求¶
在每个executor节点上,还需要考虑数据库日志文件和元数据的空间:
- 系统元数据
- SeaboxMpp数据库节点上的每个seaboxsql实例(包括executor实例和coordinator实例),通常系统目录和元数据大约为200MB。
- 预写式日志
- 预写式日志(Write Ahead Log),每个SeaboxMpp数据库节点上的每个seaboxsql实例(包括executor实例和coordinator实例,都需要为预写式日志(WAL)分配空间。WAL按64MB大小切分为多个文件,通常WAL文件的数量为:
2 * checkpoint_segments + 1
可使用上述公式来估算WAL的空间需求。SeaboxMPP数据库实例的默认参数checkpoint_segments设置为8,即节点上的每个seaboxsql实例需分配1088MB的WAL空间。
- 数据库日志文件
- 每个seaboxsql实例都会生成数据库日志文件,日志文件将随运行时间而增长。需考虑为日志文件分配足够的空间,且应该使用某种类型的日志周期处理工具来确保日志文件不会变得太大。
集群规模估算原则¶
在SeaboxMPP数据库集群各个节点服务器配置确定的情况下,集群规模主要考虑存储容量及性能要求两个方面的因素。
其中,存储容量方面,集群规模可依据未来预见的数据总量与当前单节点可存储用户数据量的比值计算得来。
性能方面,通常不能通过直接公式计算得来,建议在生产环境部署方案确定前,选取对性能考量明确的关键业务进行小规模业务测试,根据测试结果再去测算实际规模。
按照经验,通常有以下性能建议:
-
批量加工场景,单条SQL单节点处理数据集(指通过稀疏索引过滤后的数据集)规模在100万行至2000万行时,效率最佳
-
高并发单表联机查询场景,单条SQL单节点处理数据集规模在10万至500万间,效率最佳
-
高并发单表联机查询场景,每增加约200并发,需增加一个coordinator节点用于汇总最终结果集并返回客户端