StarRocks 与 MySQL 深度对比：架构、性能与选型

2. 分布式架构

三、数据模型对比

StarRocks 特有数据模型

-- 1. 明细模型（记录所有明细）
CREATE TABLE detail_table (
    order_id BIGINT,
    user_id INT,
    amount DECIMAL(10,2),
    order_time DATETIME
)
DUPLICATE KEY(order_id, user_id)
DISTRIBUTED BY HASH(order_id) BUCKETS 10;

-- 2. 聚合模型（自动聚合）
CREATE TABLE agg_table (
    product_id INT,
    sale_date DATE,
    total_amount DECIMAL(20, 2) SUM,
    max_price DECIMAL(10, 2) MAX
)
ENGINE = OLAP
AGGREGATE KEY(product_id, sale_date)
DISTRIBUTED BY HASH(product_id) BUCKETS 8
PROPERTIES ( "replication_num" = "1" );

-- 3. 主键模型（唯一更新）
CREATE TABLE unique_table (
    user_id INT,
    email VARCHAR(100),
    last_login DATETIME
)
ENGINE = OLAP
UNIQUE KEY(user_id)
DISTRIBUTED BY HASH(user_id) BUCKETS 8
PROPERTIES ( "replication_num" = "1" );

MySQL 数据模型对比

-- MySQL 只有一种模型：关系表
CREATE TABLE user_table (
    id INT PRIMARY KEY,
    name VARCHAR(50),
    INDEX idx_name(name)
)
ENGINE=InnoDB;

数据模型对比表

四、SQL 语法差异

1. 建表语句对比

-- StarRocks（必须指定分布式参数）
CREATE TABLE user_orders (
    order_id BIGINT,
    user_id INT,
    amount DECIMAL(10, 2)
)
ENGINE = OLAP
DUPLICATE KEY(order_id)
DISTRIBUTED BY HASH(order_id) BUCKETS 10
PROPERTIES ("replication_num" = "1");

-- MySQL（简单直观）
CREATE TABLE user_orders (
    order_id BIGINT PRIMARY KEY,
    user_id INT,
    amount DECIMAL(10, 2),
    INDEX idx_user_id (user_id)
)
ENGINE = InnoDB;

2. 关键语法差异表

五、性能特征对比

1. 查询性能差异

2. 性能数据示例

-- 同样的查询，性能差异巨大
SELECT user_id, COUNT(*) AS order_count, SUM(amount) AS total_amount, AVG(amount) AS avg_amount
FROM user_orders
WHERE order_date >= '2024-01-01'
GROUP BY user_id
HAVING total_amount > 1000
ORDER BY total_amount DESC
LIMIT 100;

-- StarRocks：1 秒（10 亿数据）
-- MySQL：可能超时或几分钟（1000 万数据）

3. 并发能力对比

六、运维管理对比

1. 集群管理

2. 数据导入导出

-- StarRocks：多种导入方式
-- 1. Stream Load（HTTP 推送）
curl --location-trusted -u user:passwd \
-H "label:label1" \
-H "column_separator:," \
-T data.csv \
http://fe_host:8030/api/db/table/_stream_load

-- 2. Broker Load（HDFS/S3）
LOAD LABEL db.label1 (
    DATA INFILE("hdfs://path/*.csv") INTO TABLE table1
) WITH BROKER "broker1";

-- 3. Routine Load（持续导入）
CREATE ROUTINE LOAD db.job1 ON table1 PROPERTIES ("desired_concurrent_number"="3") FROM KAFKA (...);

-- MySQL：简单导入
LOAD DATA INFILE '/path/data.csv' INTO TABLE table1;

3. 监控和诊断

七、适用场景总结

✅ 使用 StarRocks 的场景

1. 大数据分析：TB/PB 级数据分析
2. 实时数仓：分钟级数据延迟要求
3. OLAP 报表：复杂聚合查询
4. 用户行为分析：用户画像、路径分析
5. 日志分析：Nginx/业务日志分析
6. BI 工具后端：Superset、Metabase 等

✅ 使用 MySQL 的场景

1. 业务系统：ERP、CRM、OA
2. 交易系统：订单、支付、库存
3. 网站后端：用户、内容、评论
4. 实时业务：需要 ACID 事务
5. 中小型应用：数据量<1TB
6. 需要外键/存储过程的应用

🔄 混合架构方案

┌─────────────────┐ ┌─────────────────┐
│ 业务系统        │ │ 分析系统        │
│ (OLTP)          │ │ (OLAP)          │
│                 │ │                 │
│ MySQL           │ │ StarRocks       │
│ ┌─────────┐     │ │ ┌─────────┐     │
│ │订单表   │     │ │ │聚合视图 │     │
│ │用户表   │────▶│ │ │分析报表 │     │
│ │商品表   │     │ │ │用户画像 │     │
│ └─────────┘     │ │ └─────────┘     │
└─────────────────┘ └─────────────────┘
         ▼                   ▼
   实时业务处理         分析查询
   (高并发写入)         (复杂分析)

八、迁移注意事项

从 MySQL 迁移到 StarRocks

1. 数据模型重构：

   • 确定使用哪种数据模型（明细/聚合/主键）
   • 设计合理的分桶键和分桶数

2. SQL 重写：

-- MySQL 写法
SELECT DATE(create_time), COUNT(DISTINCT user_id) FROM orders GROUP BY DATE(create_time);

-- StarRocks 优化写法（利用物化视图）
-- 可提前创建物化视图加速

3. 导入策略：

   • 使用批量导入而非逐行插入
   • 合理安排导入时间窗口

4. 应用改造：

   • 修改连接配置（端口 9030）
   • 调整查询逻辑（利用 StarRocks 特性）

九、总结对比表

十、选择建议

选择 StarRocks 当：

• 数据量 > 1TB
• 查询复杂（多表 JOIN、聚合）
• 需要实时分析
• 预算有限（更高性价比）

选择 MySQL 当：

• 数据量 < 1TB
• 需要完整事务支持
• 应用简单（CRUD 为主）
• 需要存储过程/触发器
• 团队熟悉 MySQL 生态

黄金法则：用 MySQL 处理事务，用 StarRocks 分析数据，各司其职，发挥各自优势。