标签

数据库

Airbnb 如何用 Sitar-agent 给 Kubernetes Pod 动态下发配置

来源: infoq.com 53
Airbnb 披露了 Sitar-agent 的架构：它是运行在 Kubernetes 服务旁边的 sidecar，用来把动态配置稳定地下发到数以万计的 Pod。这个系统每分钟要处理多次配置更新，核心挑战不是“能不能推送配置”，而是当规模、启动风暴、网络抖动和存储故障同时出现时，应用还能不能拿到可用配置。 这次重构的几个关键词很明确：Java 重写、用...
# AI # InfoQ # Java
阅读全文

etcd 3.7：RangeStream、v3store 启动与升级时真正要检查的事

来源: kubernetes.io 49
etcd v3.7.0 是一个不小的 minor release。它解决了大范围查询一次性缓冲带来的延迟和内存问题，引入 RangeStream；继续压低 Kubernetes 控制平面的 CPU 开销；同时把启动链路从遗留 v2store 中抽离出来，并完成 protobuf 依赖的大规模更新。对只运行官方镜像的团队来说，这更像一次需要认真读升级说明...
# AI # Go # Kubernetes
阅读全文

SonnetDB 3.0：把八类数据能力收进一套 SQL

来源: oschina.net 43
SonnetDB 3.0.0 的核心信息很直接：IoTSharp 团队把时序、关系表、键值、JSON 文档、全文检索、向量检索、对象存储和消息队列放进同一个数据库引擎，并通过同一套 SQL 与 API 暴露出来。对开发团队来说，这不是“少装几个软件”这么简单，而是数据建模、查询路径、运维边界都会被重新摆放。 很多系统一开始只有关系表，后来接入设备数据，...
# AI # 全栈 # 后端
阅读全文

PostgreSQL 的 enable_partitionwise_join：让分区表按分区对齐再 Join

来源: postgr.es 50
是 PostgreSQL 里一个经常被忽略的优化开关。它的作用很直接：当两张表都按 Join Key 分区，并且分区边界兼容时，优化器可以把一次大 Join 拆成多组“对应分区之间的小 Join”。这通常能减少扫描范围、降低中间结果规模，也更容易触发每个分区上的局部优化。 但它不是打开就一定变快的魔法开关。它默认通常是关闭的，原因也很工程化：分区越多，...
# AI # PostgreSQL # 数据库
阅读全文

PostgreSQL 30 年：从研究项目到数据库默认底座

来源: postgr.es 31
1996 年 7 月 8 日，PostgreSQL 社区接过 Postgres95 留下的火种。三十年后，它已经不只是一个“开源数据库选项”，而是很多团队设计后端系统时的默认起点：应用数据库、分析型扩展、队列、全文检索、地理数据、向量检索，越来越多能力都围绕它展开。 PostgreSQL 的故事有一个很工程化的转折点：它从 Berkeley 的研究项目...
# PostgreSQL # 数据库
阅读全文

死锁不是小概率异常：它如何拖垮数据库，以及应用该怎么收手

来源: planetscale.com 54
死锁听起来像数据库内部的小插曲：两个事务互相等锁，其中一个被数据库杀掉，应用重试一下就完了。现实里，它经常是停机事故的前奏。查询写得不稳、事务持锁太久、应用无限并发冲击同一批行，都会把一次死锁扩大成连接池耗尽、请求排队、数据库 CPU 飙升，最后变成用户可见的不可用。 典型死锁并不复杂：事务 A 锁住了 ，等待 ；事务 B 锁住了 ，等待 。数据库会检...
# MySQL # 数据库
阅读全文

从 PostgreSQL 换到 ClickHouse：高吞吐缓存查询的现实取舍

来源: infoq.com 41
Momentic 为 AI 驱动的软件测试平台重构了缓存系统：规模达到每天超过 200 万次查询、总计约 200 亿条记录，同时把平均响应延迟维持在约 250 ms。关键变化不是给 PostgreSQL 再加一层补丁，而是把缓存查询负载迁移到列式数据库 ClickHouse。 这类迁移值得后端团队关注，因为它不是“数据库谁更强”的抽象争论，而是一个典型...
# AI # InfoQ # LLM
阅读全文

用 ClickHouse 扛住 200 万次/天缓存查询：从 PostgreSQL 迁移的工程取舍

来源: infoq.com 49
Momentic 在重构其 AI 软件测试平台的缓存系统时，把存储层从 PostgreSQL 迁到列式数据库 ClickHouse，用来支撑每天超过 200 万次查询、总量约 200 亿条缓存记录，并把平均响应延迟维持在约 250 ms。这个案例值得关注，不是因为“PostgreSQL 不行”，而是因为缓存查询的形态一旦变成大规模读、宽表扫描、按条件过...
# AI # InfoQ # LLM
阅读全文

Amazon QuickSight 多数据集关系建模：从表结构到 SQL 落地

来源: aws.amazon.com 52
Amazon QuickSight 的多数据集关系建模，不只是把几张表拖到一起。真正麻烦的地方在于：不同业务表的粒度不同、维度表可能复用、事实表之间不一定能直接 join，错误的模型会让看板出现重复计数、指标膨胀或过滤器失效。来源文章的重点从概念转向模式：针对不同 schema，梳理表结构、适用场景、实现步骤、示例 SQL，并讨论高级场景下需要额外建模...
# AI # AWS # 云平台
阅读全文

用 pgBackRest TLS 模式做 PostgreSQL 灾备恢复：少一点 SSH，少一点横向移动风险

来源: postgr.es 53
PostgreSQL 灾备恢复里，pgBackRest 通过 SSH 拉取备份是一条成熟路线：简单、可靠、很多团队已经这么跑。但当 DR 服务器越来越多、隔离区越来越严格、密钥轮换越来越频繁时，SSH key 的分发和审计会变成运维负担。pgBackRest 的原生 TLS transport 提供了另一种模型：DR 服务器不需要拿到能登录备份节点的 ...
# AI # Go # PostgreSQL
阅读全文