从存算一体到存算分离在单机上用Docker体验StarRocks 3.2新架构含MinIO对象存储当数据仓库技术演进到云原生时代存算分离架构正成为新一代分析型数据库的核心设计范式。StarRocks作为国产MPP数据库的佼佼者在3.x版本中实现了存算分离架构的重大升级。本文将带您通过Docker Compose在单机环境下快速搭建包含MinIO对象存储的StarRocks 3.2迷你集群亲身体验存算分离架构的技术魅力。1. 环境准备与架构解析在开始部署之前我们需要理解存算分离架构的核心价值。传统存算一体架构中计算节点和存储节点紧密耦合导致扩缩容成本高、资源利用率低。而存算分离架构通过将数据持久化到对象存储如S3实现了计算资源的弹性伸缩和存储资源的独立扩展。本次实验环境需要以下组件Docker Engine 20.10Docker Compose v2.15至少8GB可用内存50GB磁盘空间关键配置检查清单# 验证Docker版本 docker --version docker-compose --version # 检查系统资源 free -h df -h提示如果是在Linux环境下建议关闭Swap分区以获得更稳定的性能表现sudo swapoff -a sudo sed -i /swap/s/^/#/ /etc/fstab2. 基础设施部署MinIO对象存储我们选择MinIO作为S3兼容的对象存储服务它完美模拟了云上S3存储的行为模式。以下是docker-compose.yml中MinIO服务的配置片段services: minio: image: minio/minio:latest environment: MINIO_ROOT_USER: minioadmin MINIO_ROOT_PASSWORD: minioadmin volumes: - ./minio/data:/data ports: - 9000:9000 # API端口 - 9001:9001 # 控制台端口 command: server /data --console-address :9001启动后可以通过http://localhost:9001访问MinIO控制台账号minioadmin/minioadmin需要手动创建名为starrocks的存储桶。对象存储关键参数对比参数项存算一体架构存算分离架构数据持久化位置本地SSD/HDD对象存储(S3协议)存储扩展方式增加BE节点无限扩展存储桶容量数据冗余策略多副本存储层EC编码典型延迟微秒级毫秒级3. StarRocks 3.2集群部署完整的docker-compose.yml应包含FE(前端)、CN(计算节点)和MinIO三个服务。以下是关键配置说明3.1 FE节点配置starrocks-fe: image: starrocks/fe-ubuntu:3.2-latest environment: RUN_MODE: shared_data AWS_S3_ENDPOINT: http://minio:9000 AWS_S3_ACCESS_KEY: minioadmin AWS_S3_SECRET_KEY: minioadmin AWS_S3_PATH: starrocks volumes: - ./fe/meta:/opt/starrocks/fe/meta - ./fe/log:/opt/starrocks/fe/log ports: - 8030:8030 # HTTP服务 - 9030:9030 # MySQL协议3.2 CN节点配置starrocks-cn: image: starrocks/cn-ubuntu:3.2-latest depends_on: - starrocks-fe environment: CN_AUTO_JOIN: true volumes: - ./cn/log:/opt/starrocks/cn/log启动集群docker-compose up -d验证服务状态# 检查容器运行状态 docker ps --format table {{.Names}}\t{{.Status}}\t{{.Ports}} # 连接FE执行SQL验证 mysql -h127.0.0.1 -P9030 -uroot -e SHOW FRONTENDS; SHOW COMPUTE NODES;4. 存算分离特性深度体验4.1 数据导入性能测试创建一个测试表并导入数据-- 创建测试数据库 CREATE DATABASE test_db; USE test_db; -- 建表语句使用存算分离特有的存储介质配置 CREATE TABLE lineorder_flat ( lo_orderdate DATE, lo_orderkey INT, lo_linenumber TINYINT ) ENGINEOLAP DUPLICATE KEY(lo_orderdate, lo_orderkey) PARTITION BY RANGE(lo_orderdate) ( START (1992-01-01) END (1999-01-01) EVERY (INTERVAL 1 YEAR) ) DISTRIBUTED BY HASH(lo_orderkey) PROPERTIES ( storage_medium S3, storage_cooldown_time 9999-12-31 23:59:59 ); -- 使用Stream Load导入示例数据 curl --location-trusted -u root: \ -H label:lineorder_1 \ -H column_separator:| \ -T lineorder.tbl \ http://127.0.0.1:8030/api/test_db/lineorder_flat/_stream_load4.2 弹性扩缩容演示存算分离架构的最大优势在于计算资源的弹性伸缩。我们可以动态添加CN节点-- 查看现有计算节点 SHOW COMPUTE NODES; -- 动态扩容实际生产中通过k8s或docker-compose scale实现 docker-compose up -d --scale starrocks-cn2 -- 在新CN启动后自动注册到集群 SHOW PROC /compute_nodes;4.3 存储成本优化存算分离架构下可以通过以下方式优化存储成本-- 冷热数据分层存储 ALTER TABLE lineorder_flat SET ( storage_cooldown_time 7 DAY ); -- 数据压缩算法选择 ALTER TABLE lineorder_flat SET ( storage_format zstd );5. 架构对比与选型建议存算一体 vs 存算分离关键指标对比维度存算一体(v2.5)存算分离(v3.2)部署复杂度中等需3BE3FE简单1FE1CN起步存储成本较高3副本较低EC编码计算弹性分钟级秒级典型查询延迟亚秒级毫秒级适用场景高性能OLAP云原生弹性需求对于技术选型建议考虑以下因素选择存算一体当需要极致查询性能、已有稳定物理服务器资源选择存算分离当云环境部署、需要频繁扩缩容、有显著成本优化需求在单机Docker环境中体验完整流程后可以明显感受到3.2版本在运维便捷性和架构灵活性上的提升。特别是在进行计算节点扩缩容操作时存算分离架构几乎可以实现即时生效而传统架构需要重新平衡数据分片。