OpenEuler上Docker Compose部署PostgreSQL数据库

一、开场：从MySQL到PostgreSQL

上次用Docker Compose部署了MySQL，感觉挺方便的。配置清晰，一条命令就能启动，数据持久化也不用担心。

这两天听同事提到PostgreSQL，说它在复杂查询、数据完整性方面比MySQL强，而且支持JSON、数组这些高级数据类型。正好手上有个项目可能要用到这些特性，就想着试试在OpenEuler上部署PostgreSQL。

还是用OpenEuler 22.03 LTS，2核4GB的服务器。上次MySQL跑得挺稳，这次试试PostgreSQL能不能达到类似的表现。

---

二、PostgreSQL：世界上最先进的开源数据库

2.1 为什么选PostgreSQL

PostgreSQL的官方口号是"世界上最先进的开源关系数据库"，这不是吹牛，是有底气的：

1. 历史悠久，成熟稳定

• 30多年的发展历史（1986年起源于伯克利大学）
• 经过无数生产环境的验证
• 企业级特性：完整的ACID支持、多版本并发控制（MVCC）

2. 功能强大

• 支持复杂查询：子查询、窗口函数、CTE（公用表表达式）
• 丰富的数据类型：JSON/JSONB、数组、hstore、UUID、几何类型等
• 强大的索引：B-tree、Hash、GiST、SP-GiST、GIN、BRIN
• 全文搜索：内置全文检索能力

3. 扩展性极强

• 支持自定义函数、类型、操作符
• 丰富的扩展生态：PostGIS（地理信息）、TimescaleDB（时序数据）等
• 支持多种编程语言编写存储过程：PL/pgSQL、PL/Python、PL/Perl等

4. 严格符合SQL标准

• 比MySQL更严格地遵循SQL标准
• 数据完整性更好

2.2 PostgreSQL vs MySQL：该选谁？

暂时无法在飞书文档外展示此内容

我的理解：

• 简单业务、高并发读写：MySQL更合适（配置简单、性能稳定）
• 复杂业务、数据分析：PostgreSQL更合适（功能强大、扩展性好）
• 两者都很优秀，关键看业务需求

2.3 OpenEuler与PostgreSQL

OpenEuler对PostgreSQL的支持很好：

• 官方软件仓库包含PostgreSQL
• Docker镜像运行稳定
• 内核优化对数据库性能有提升
  官方资源：
• 官网：https://www.openeuler.org/
• 文档：https://docs.openeuler.org/
• 社区：https://forum.openeuler.org/

---

三、Docker Compose部署PostgreSQL

3.1 创建docker-compose.yml

version: '3.8'

services:
  postgres:
    image: postgres:16
    container_name: postgres-server
    restart: always
    environment:
      POSTGRES_PASSWORD: your_strong_password
      POSTGRES_DB: testdb
      POSTGRES_USER: testuser
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data
      - ./postgresql.conf:/etc/postgresql/postgresql.conf
    command: postgres -c config_file=/etc/postgresql/postgresql.conf

volumes:
  postgres_data:

与MySQL的配置差异：

暂时无法在飞书文档外展示此内容

配置说明：

• image: postgres:16：使用PostgreSQL 16最新版本
• POSTGRES_USER/POSTGRES_PASSWORD：创建默认用户和密码
• POSTGRES_DB：创建默认数据库
• ports: 5432：PostgreSQL的默认端口
• command：指定自定义配置文件路径

3.2 PostgreSQL配置优化

# 连接配置
max_connections = 200
shared_buffers = 256MB
effective_cache_size = 1GB
maintenance_work_mem = 64MB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 1.1
effective_io_concurrency = 200
work_mem = 2MB
min_wal_size = 1GB
max_wal_size = 4GB

# 日志配置
logging_collector = on
log_directory = 'log'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_statement = 'all'
log_duration = on

# 字符集
client_encoding = UTF8

关键参数解析：

5. 内存相关

• shared_buffers = 256MB：共享内存缓冲区，建议设为物理内存的25%
• effective_cache_size = 1GB：告诉优化器可用的总缓存，设为物理内存的50%-75%
• work_mem = 2MB：每个查询操作的内存，不宜过大（会被多个连接共享）
• maintenance_work_mem = 64MB：维护操作（VACUUM、CREATE INDEX）的内存

6. 检查点（Checkpoint）

• checkpoint_completion_target = 0.9：检查点完成时间的目标比例，接近1更平滑
• min_wal_size = 1GB：WAL日志最小大小
• max_wal_size = 4GB：WAL日志最大大小

7. 查询优化

• random_page_cost = 1.1：随机页面访问成本（SSD可设为1.1，HDD建议4.0）
• effective_io_concurrency = 200：I/O并发能力（SSD可设为200）
  与MySQL配置对比：
  PostgreSQL的配置比MySQL复杂一些，但也更精细。MySQL的innodb_buffer_pool_size类似PostgreSQL的shared_buffers，但PostgreSQL还要考虑effective_cache_size等参数。

3.3 启动PostgreSQL

mkdir -p ~/postgres-docker
cd ~/postgres-docker
# 创建配置文件（见上）
docker-compose up -d

启动日志显示：

PostgreSQL init process complete; ready for start up.
database system is ready to accept connections

成功！PostgreSQL容器已启动。

---

四、PostgreSQL基础操作

4.1 连接PostgreSQL

docker exec -it postgres-server psql -U testuser -d testdb

PostgreSQL版本信息：

PostgreSQL 16.10 (Debian 16.10-1.pgdg13+1) on x86_64-pc-linux-gnu

与MySQL命令对比：

暂时无法在飞书文档外展示此内容

数据库列表：

postgres (系统数据库)

template0 (模板数据库，不可修改)

template1 (模板数据库，可定制)

testdb (我们创建的数据库)

4.2 创建测试表和数据

-- 创建用户表
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    username VARCHAR(50) NOT NULL,
    email VARCHAR(100) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- 创建索引
CREATE INDEX idx_username ON users(username);
CREATE INDEX idx_email ON users(email);

-- 插入测试数据
INSERT INTO users (username, email) VALUES
('user1', 'user1@example.com'),
('user2', 'user2@example.com'),
('user3', 'user3@example.com'),
('user4', 'user4@example.com'),
('user5', 'user5@example.com'),
('user6', 'user6@example.com'),
('user7', 'user7@example.com'),
('user8', 'user8@example.com'),
('user9', 'user9@example.com'),
('user10', 'user10@example.com');

INSERT 0 10：成功插入10条记录。

PostgreSQL特色语法：

8. SERIAL自增主键

PostgreSQL使用SERIAL定义自增主键，等价于：

id INTEGER NOT NULL DEFAULT nextval('users_id_seq')

MySQL使用AUTO_INCREMENT：

id INT AUTO_INCREMENT PRIMARY KEY

9. TIMESTAMP类型
   PostgreSQL的TIMESTAMP支持时区（TIMESTAMP WITH TIME ZONE），MySQL的TIMESTAMP也支持时区但处理方式不同。

---

五、PostgreSQL性能测试：OpenEuler的表现

5.1 pgbench工具介绍

pgbench是PostgreSQL官方的性能测试工具，类似MySQL的sysbench。

测试场景：TPC-B

• TPC-B是一个标准的数据库基准测试
• 模拟银行业务：账户余额更新、分支余额更新、历史记录插入等
• 包含事务、并发、读写混合等测试
  与sysbench对比：
  暂时无法在飞书文档外展示此内容

5.2 准备测试数据

docker exec -it postgres-server pgbench -i -s 10 -U testuser testdb

pgbench初始化过程：

• scale factor = 10：缩放因子为10
• 生成数据：1,000,000行（100万行）
• 总耗时：1.73秒
  • drop tables: 0.00s
  • create tables: 0.01s
  • client-side generate: 1.38s
  • vacuum: 0.09s
  • primary keys: 0.26s
    生成的表：
• pgbench_accounts：账户表（100万行）
• pgbench_branches：分支表
• pgbench_tellers：柜员表
• pgbench_history：历史记录表
  数据生成速度很快！ 1.73秒生成100万行，说明PostgreSQL在OpenEuler上的写入性能不错。

5.3 运行性能测试

docker exec -it postgres-server pgbench -c 4 -j 2 -t 10000 -r -U testuser testdb

测试参数：

• -c 4：4个并发客户端
• -j 2：2个工作线程
• -t 10000：每个客户端执行10,000个事务
• -r：报告每个语句的平均延迟
  性能测试结果：
  暂时无法在飞书文档外展示此内容
  各语句延迟详情：
  暂时无法在飞书文档外展示此内容

5.4 性能数据分析

10. TPS（事务处理能力）

• PostgreSQL: 2,046 TPS
• MySQL: 459 TPS（上次测试数据）
  PostgreSQL的TPS是MySQL的4.5倍！
  这个差异主要因为：
• 测试工具不同：pgbench vs sysbench
• 测试场景不同：TPC-B vs OLTP读写混合
• 数据库架构不同：PostgreSQL的MVCC对并发事务更友好
  但这不代表PostgreSQL一定比MySQL快，只能说在这个测试场景下PostgreSQL表现更好。

11. 延迟表现

• 平均延迟1.954ms：非常优秀
• 没有失败事务：稳定性好
• 各语句延迟均衡：没有明显的性能瓶颈

12. 适用场景
    对于2核4GB的服务器：

• 2,046 TPS意味着每秒可以处理约2000个事务
• 对于中小型应用（日活几万）完全够用
• 如果是复杂查询（多表JOIN、子查询），PostgreSQL的优势更明显

5.5 OpenEuler上PostgreSQL的性能优势

为什么PostgreSQL在OpenEuler上能跑出这么好的性能？

13. 内核优化

OpenEuler基于Linux 5.10 LTS内核，针对数据库场景做了优化：

• 文件系统优化（ext4、XFS）
• I/O调度器优化（对数据库的随机读写友好）
• 内存管理优化（大页内存支持）
• 进程调度优化（多进程架构的PostgreSQL受益）

14. 容器化性能
    OpenEuler对Docker的支持很好：

• 容器网络性能高
• 存储卷（volume）性能损耗小
• cgroup资源限制精准
  这次测试PostgreSQL是跑在Docker容器里的，性能依然很优秀。

15. 系统稳定性
    测试过程中：

• 40,000个事务，0失败
• 系统负载稳定
• 没有出现任何异常
  对于数据库这种关键应用，稳定性比性能更重要。

---

六、容器资源占用与进程结构

6.1 资源占用情况

docker stats --no-stream postgres-server

资源占用数据：

暂时无法在飞书文档外展示此内容

与MySQL对比：

暂时无法在飞书文档外展示此内容

PostgreSQL更节省资源！

• 内存占用：PostgreSQL约300MB，MySQL约535MB
• 进程数：PostgreSQL 7个进程，MySQL 63个进程
  这个差异主要因为：
• PostgreSQL是多进程架构，进程数少但每个进程功能明确
• MySQL是多线程架构，线程数多（显示为进程数）
• 配置不同：MySQL设置了1GB的innodb_buffer_pool，PostgreSQL的shared_buffers是256MB

6.2 PostgreSQL进程结构

docker exec postgres-server ps aux | grep postgres

PostgreSQL的7个进程：

暂时无法在飞书文档外展示此内容

PostgreSQL的多进程架构：

• 优点：进程隔离性好，一个进程崩溃不会影响其他进程
• 缺点：进程切换开销比线程大（但在现代操作系统上影响很小）
  MySQL的多线程架构：
• 优点：线程切换开销小，内存共享方便
• 缺点：线程间隔离性差，一个线程崩溃可能影响整个进程
  两种架构各有优劣，PostgreSQL的多进程在OpenEuler的内核优化下表现很好。

---

七、PostgreSQL vs MySQL：实战对比

7.1 部署体验对比

配置复杂度：

• PostgreSQL：配置文件参数多，需要理解各个参数的含义
• MySQL：配置相对简单，默认值就能用
  启动速度：
• 两者差不多，都在几秒内启动完成
  日志查看：
• PostgreSQL：日志更详细，结构清晰
• MySQL：日志简洁，但有时不够详细

7.2 性能对比

暂时无法在飞书文档外展示此内容

注意：这个对比不完全公平，因为测试工具和场景不同。但可以看出：

• PostgreSQL在事务处理上有优势
• PostgreSQL内存占用更低
• MySQL在简单查询、高并发读写上可能更有优势

7.3 使用体验对比

SQL语法差异：

暂时无法在飞书文档外展示此内容

命令行差异：

暂时无法在飞书文档外展示此内容

学习曲线：

• MySQL：更容易上手，SQL语法宽松
• PostgreSQL：学习曲线稍陡，但功能更强大

---

八、总结：OpenEuler上的数据库选择

8.1 整体感受

部署完PostgreSQL，做了性能测试，对比了MySQL，有几点感受：

16. PostgreSQL功能确实强大

• 复杂查询、高级数据类型、扩展性都很好
• 适合复杂业务场景

17. MySQL更易用

• 配置简单，上手快
• 适合快速开发

18. OpenEuler对两者都支持很好

• MySQL和PostgreSQL都能稳定运行
• 性能表现优秀
• 容器化部署方便

8.2 OpenEuler的优势

通过MySQL和PostgreSQL两次实践，我对OpenEuler有了更深的认识：

19. 兼容性好

OpenEuler能很好地支持主流数据库：

• MySQL、PostgreSQL都能无缝运行
• Docker镜像兼容性好
• 软件生态完善

20. 性能优秀

• PostgreSQL TPS 2,046，延迟1.95ms
• MySQL TPS 459，延迟8.70ms
• 两者在OpenEuler上都能发挥出应有的性能

21. 稳定可靠

• 两次测试都很稳定，没有出现异常
• 容器化部署可靠
• 适合作为生产环境

22. 资源利用率高

• PostgreSQL内存占用只有300MB
• MySQL内存占用535MB
• 2核4GB的服务器能同时跑多个数据库容器

8.3 OpenEuler：国产操作系统的优秀代表

通过这两次数据库部署和测试，我对OpenEuler有了信心：

23. 可以替代CentOS

• 软件生态完善
• 性能不输主流发行版
• 稳定性好

24. 适合作为数据库服务器

• 内核优化到位
• 容器化支持好
• 资源利用率高

25. 国产化支持

• 自主可控
• 社区活跃
• 文档完善
  如果你也在：
• 寻找CentOS的替代品
• 搭建数据库服务器
• 探索云原生架构
• 考虑国产化方案
  那么OpenEuler绝对值得一试。 性能好、稳定、生态完善，而且国产化支持也很重要。