数据库

同一个「存数据」的需求，为什么长出了三种完全不同的数据库？ PostgreSQL、Redis、DuckDB——三者都管自己叫「数据库」，但架构几乎没有一处相同。本文从一个问题出发：为什么「存数据」这一件事，需要三种截然不同的答案？ 先说个真实感受：新人问我「该用什么数据库」时，我最怕听到的是「就……存点数据」。因为「存数据」这个需求背后，至少藏着三个互相矛盾的目标：要快（延迟）、要对（一致性）、要能算（分析吞吐）。这三个目标在物理层面就是打架的，所以业界长出了三种完全不同形态的数据库，各自押注一个目标。 这篇拿 PostgreSQL（75K+ Star 里的常青树）、Redis（75K Star）、DuckDB（40K Star）当样本——它们恰好是三条路线的教科书级代表。 三种数据库，三种「世界观」 PostgreSQL Redis DuckDB 一句话定位 数据的基础设施 远程数据结构接口 SQLite for Analytics 押注的目标 正确性 > 性能 延迟 > 一切 分析吞吐 + 零部署 数据在哪 磁盘（缓冲进内存） 内存 就在文件里（CSV/Parquet/S3） 并发模型 多进程、MVCC 多版本 单线程事件循环 单写者、Morsel 并行读 典型场景 金融、ERP、订单 缓存、会话、排行榜、限流 数据科学家本地跑 SQL 分析 注意：这三行的每一列差异都不是「实现细节」，全是世界观分歧。往下看。 PostgreSQL：把「正确」放在所有选项的前面 PostgreSQL 从 1986 年 Berkeley 的学术项目走到今天，38 年没死，靠的不是快——它从来不追求最快。它的护城河是正确性和可信度的复利。 几个能看出价值观的设计： 1. Process-per-connection：每个连接一个独立进程。 MySQL（InnoDB）用线程池，PG 用进程。进程更重、启动更慢，但一个连接崩了不会带走别人——内存隔离是操作系统保证的，不是代码纪律保证的。这是「可靠性高于便利」的字面体现。 2. MVCC 的代价是 VACUUM。 读写互不阻塞的代价是旧版本数据堆在表里，得靠 VACUUM 回收。很多人骂 VACUUM 烦，但这笔交易是明码标价的：读永远不阻塞写、写永远不阻塞读，换来的运维成本。对比 MySQL undo log 的回收方式，各有取舍，但 PG 把旧版本直接放主表的设计，让「时间旅行」「闪回查询」这类能力成为可能。 ...

一次真实的升级记录。 从 Ubuntu 默认 Cluster 管理模式，迁移到 PostgreSQL 官方推荐目录结构。 全程使用 pg_upgrade，保留所有数据库，最终实现： PostgreSQL 18 官方数据目录 systemd 管理 MacBook 远程访问 完整踩坑记录 一、为什么升级？ 原环境： 项目 版本 Ubuntu 24.04 PostgreSQL 16.14 数据目录 /srv/data/db/postgres/16/main 希望升级到： PostgreSQL 18.4 PostgreSQL 18 vs 16 关键改进 特性 PostgreSQL 16 PostgreSQL 18 增量备份 ❌ 仅全量 ✅ pg_basebackup 支持增量，备份时间减少 50%+ 逻辑复制 基础支持 ✅ 支持序列和大对象复制 并行查询 有限并行 ✅ 更多场景支持并行（VACUUM、CREATE INDEX） JSON 处理 JSONB 基础 ✅ JSON_TABLE 增强，复杂查询更高效 SSD 优化 无特殊处理 ✅ 强制 I/O 调度优化（见下文） 连接池 需外部工具 ✅ 内置连接池改进 SSD 专项优化（重要） PostgreSQL 18 对 NVMe/SSD 做了底层优化，这是升级的核心理由： ...

问题现象 普通 SQL 正常，stg 环境没发现异常。但生产环境用户反馈：超长 SQL（超过 1MB）会触发 400 报错。 恰好生产环境的用户有很多那种业务逻辑复杂、拼接出来的超长 SQL。 排查过程 第一步是对比。把报错的 SQL 和不报错的 SQL 摆在一起看，唯一的共同点就是——长。 短 SQL 跑得好好的，长到一定长度就 400。这不是 SQL 语法问题，是传输层的问题。 根因 查到最后，原因是这样的： 安全合规要求，把普通的 Statement 升级为 PreparedStatement。因为普通 Statement 有 SQL 注入风险，安全团队要求整改。 Presto 驱动版本太低，低版本的 Presto JDBC 驱动对 PreparedStatement 的支持不完善，特别是对超长 SQL 的处理有 bug。 服务端 Presto 没有同步升级。原因很简单——影响太大，涉及的下游服务和业务太多，不敢动。 所以就出现了一个尴尬的局面：客户端驱动升级了（为了安全），服务端没升级（为了稳定），两边版本不一致，超长 SQL 直接 400。 解决方案 还原升级。 把客户端驱动退回到兼容当前服务端的版本。安全问题用其他方式规避（比如在应用层做参数化查询、输入校验等）。 这不是最优解，但在"安全"和"可用"之间，先保可用。 避坑建议 1. 灰度环境重点覆盖验证 stg 环境为什么没发现？因为测试用的 SQL 都是短的。灰度环境应该重点覆盖边界场景： 超长 SQL（1MB+） 特殊字符 高并发场景 2. 客户端和服务端版本要对齐 升级驱动前，先确认服务端版本兼容性。不要客户端升了、服务端没升，两边版本不一致是定时炸弹。 3. 安全整改要评估影响面 ...

数据库选择 sqlite 小巧 无需安装 支持标准sql 语法 数据库客户端 DBeaver DBeaver (Community Edition) 支持 MySQL, PostgreSQL, SQLite等数据库 免费,开源 跨平台 DBeaver 下载安装 下载地址: https://dbeaver.io/download/ 创建示例数据库 下载jdbc驱动 打开sql脚本编辑器 DBeaver示例数据库-表介绍 DBeaver 默认自带的示例数据库 使用的是业界非常著名的 Chinook 数据库。 它模拟了一个 “数字音乐商店”（类似早期的 iTunes Store）的业务场景。 这个数据库结构非常经典，特别适合用来练习 SQL 的 JOIN（连接查询）、GROUP BY（分组统计） 以及理解主外键关系。 数据表 Album 音乐专辑表 Artist 艺术家/歌手 Customer 客户 Employee 员工 Genre 流派 Invoice 发票/订单头 InvoiceLine 发票明细/订单行 MediaType 媒体格式 Playlist 歌单 PlaylistTrack 歌单 sqlite_schema sqlite元数据 Track 歌曲/单曲 查看表关系 select 练习 1.select单表查询 select * from Track; 笔记: ...