storage 分类归档

共 314 篇文章 · 返回首页

【Ceph RADOS】Recovery、Backfill 与 Scrub:修复路径、reservation 机制与 mClock QoS 边界

区分三种修复机制的触发条件与保证边界:recovery 依赖 PG log 修复分歧对象,backfill 做全量对象枚举拷贝,scrub/deep-scrub 主动扫描校验;重点解释 reservation 如何限流、async recovery 如何减少前台阻塞,以及 mClock 调度器对修复流量的控制边界与局…

【存储工程】NVMe 协议与存储接口演进

存储接口(Storage Interface)是连接主机与存储介质的桥梁,其协议设计直接决定了数据访问的延迟、吞吐量和并发能力。从早期的并行接口到现代的非易失性内存快捷通道(Non-Volatile Memory Express,NVMe),存储协议经历了数十年的演进。本文将系统梳理存储接口的发展历程,深入剖析 NV…

数据库内核实验索引

汇总本站数据库内核文章:PostgreSQL / MySQL InnoDB / 列存、湖仓、流处理、查询引擎、RocksDB、向量、Redis、全文检索、TiKV/HTAP、FoundationDB、SQLite、WiredTiger 与图数据库内核,以及 LSM-Tree 实验与其它单篇。

【向量检索引擎】混合检索与标量过滤:表达式、bitset 与选择度打穿归并

按 Milvus 2.6.x Bitset、Filter Templating 文档拆解表达式如何变成 bitset 再喂给 Knowhere;用最小故事、bitset 取反细节与选择度打穿 Top-k 归并的示意图,说明为何过滤会改变延迟而不只是改变结果数量;对读 db-frontier/09 的 ACORN、Fi…

【向量检索引擎】Delete · Upsert · TTL:软删生命周期与覆盖写的两条路径

按 2.6.x Delete/Upsert/TTL 文档拆解软删 bitset 从逻辑不可见到 compaction 物理回收的完整生命周期,用官方 override/merge 内部步骤的时序图区分两种 upsert,并与 FreshDiskANN 的图索引删除模型对照,说明 Milvus 用「整段重建」而非「增量…

【向量检索引擎】副本、负载与故障恢复:读缓存式副本与 WAL 单所有者

按官方 In-Memory Replica 与 Streaming Service 文档拆解副本组、shard leader、Proxy 缓存 failover 与 WAL Wait for Ready;用多副本拓扑图与迁移时序图说明 Milvus 的读副本更接近只读缓存池而非共识复制,并与 Chain Replic…

【向量检索引擎】生产排障:召回、延迟、堆积、OOM

用症状到机制的决策树覆盖召回/延迟/堆积/OOM 四类故障,按可见性、段状态、过滤选择度、离线队列、对象存储与副本拓扑逐层定位;用一个跨软删广播与副本改派的最小故事说明为什么同一查询会得到不稳定结果,不含未跑的集群数字。

【存储工程】LMDB 与内存映射存储

数据库存储引擎通常自己管理一块内存,维护 Buffer Pool,用 read()/pread() 把磁盘页加载进来,再用 LRU 或 Clock 算法做淘汰。这套方案灵活、可控,但代码量大、调优参数多,且引入了用户态到内核态的数据拷贝。有没有一种方式,让操作系统直接把磁盘文件映射到进程地址空间,数据库只管读指针,不…

【SQLite 内核】查询计划器与统计:没有 ANALYZE 时的启发式与代价估计边界

钉住 EXPLAIN QUERY PLAN 的 SEARCH/SCAN 判定、ANALYZE 写入 sqlite_stat1/stat4 的具体语义,以及没有统计时 SQLite 用什么默认猜测(表大小猜一百万行、重复度猜 10);对照官方 N3 join 排序算法与 PG 式穷举代价优化器的复杂度边界,本机 3.5…

【SQLite 内核】索引与 covering scan:什么时候真的省掉了第二次查找

钉住 covering index 消除的具体开销:第 4 篇 index b-tree 只存 key+rowid,命中后仍要回表这一次二次查找;用本机 3.53.2 实测 SELECT 列是否全部落在索引内如何改变 EQP 输出,并区分语句级自动索引与 sqlite_autoindex_* 约束索引这两个常被混淆的…

【SQLite 内核】ATTACH / 多库边界:跨库事务的原子性在 WAL 下会退化

钉住 ATTACH DATABASE 的命名空间规则、super-journal 如何让跨文件事务在 rollback journal 模式下保持原子,以及官方文档明确写明的一条反常识边界:main 库或任一 attached 库切到 WAL 后,跨库事务只在单文件粒度原子,崩溃中间态可能只改了一部分文件;本机 3.…

【TiKV / HTAP 内核】悲观事务与 ResolveLock:TTL、死锁检测边界,纠正「TiKV 无锁」

拆解 TiKV 悲观锁的写入路径、in-memory 优化、TTL 与心跳续期,死锁检测器的中心化选举与 wait-for-graph 检测边界,以及 GC/客户端两条 ResolveLock 路径;用锁的实际存在形态纠正「TiKV 是无锁架构」这一常见误解。

【存储工程】LSM-Tree 工程调优:三种放大的权衡

LSM-Tree 的核心设计是把随机写转换为顺序写,但这个转换不是免费的。写入经过 MemTable 刷盘、再经过多次 Compaction 合并,每一字节的用户数据在磁盘上可能被反复读写数十次。读取一个 key 时,最坏情况下需要逐层搜索,直到命中或遍历全部层级。与此同时,旧版本数据和墓碑标记占用的额外空间,在 C…

【数据湖与开放表格式】Lakehouse 全景:从 Hive 表到开放表格式

Hive 目录式分区表把『表』等同于『一组目录加 metastore 里的分区行』,于是没有原子提交、planning 要 LIST 目录、schema 与分区演进常要重写。本文用这三个硬伤切入,讲清 lakehouse 把表拆成『不可变数据文件 + 可变元数据指针 + catalog』三层后各自解决了什么,并给出全…

【数据湖与开放表格式】表格式为什么存在

目录式分区表(Hive 表)在对象存储上有三处硬伤:并发写部分提交、list planning 太贵、缺快照隔离与原子提交。本文拆开放表格式补上的四件事——原子提交、快照隔离、文件级统计裁剪、schema 与分区演进,并抽象出三家共有的『元数据指针 + 不可变数据文件』骨架。

【数据湖与开放表格式】行级删除与 Merge-on-Read

Iceberg 在不可变文件上做行级删除的两条路线:copy-on-write(重写整文件)与 merge-on-read(写 delete 文件,读时合并)。讲清 position delete 与 equality delete 的语义、字段与作用域规则,写放大/读放大的取舍,V2 delete file 到 V…

【数据湖与开放表格式】提交协议与并发控制

没有数据库进程,Iceberg 怎么在对象存储上做原子提交与并发控制?拆解提交=catalog 对元数据指针做 compare-and-swap,乐观并发如何基于当前 snapshot 生成新 snapshot、冲突按操作类型与隔离级别重试,不同 catalog 的原子性来源(DB 行锁/CAS、REST 后端、对象…

【数据湖与开放表格式】Iceberg、Delta、Hudi 对照与互通

把前面 08–13 章拆过的 Iceberg、Delta、Hudi 放在一个坐标系里对照:元数据模型、行级更新、并发控制、引擎生态四维,每维标清口径。再讲两条互通路线——Delta UniForm(写时同步生成 Iceberg/Hudi 元数据)与 Apache XTable(事后转换元数据),以及它们的边界。最后给…

【数据湖与开放表格式】湖上 AI 与向量

湖仓如何承接 AI 负载:embedding/特征/训练样本存湖、按 snapshot 固定数据版本做可复现训练,以及 Parquet 在随机访问和向量检索上的短板。用本机实测对比 Lance 与 Parquet 的顺序扫描与按行随机 take,讲清 Lance 为何为随机访问与向量而生,并划清湖侧存储与专用向量引擎…

【数据湖与开放表格式】Parquet · Iceberg · Delta · Hudi 内核拆解

拆解 lakehouse 的两层基础:列式文件格式(Parquet/ORC/Arrow)与开放表格式(Iceberg/Delta/Hudi)。讲清没有数据库进程时,如何在对象存储上做 ACID、行级更新、快照与并发,以及 catalog、查询引擎、流式入湖如何拼成可运维的湖仓。面向数据平台工程师与从 OLAP/数仓转…

【存储工程】列式存储原理:为什么分析查询快 10 倍

一条典型的分析查询只访问表中数百列里的三四列,行式存储却把整行数据从磁盘搬进内存,绝大多数字节在读入后立刻被丢弃。列式存储(Columnar Storage)把同一列的值连续存放,查询只需要读取涉及到的列,I/O 量可以降低一到两个数量级。但 I/O 减少只是故事的一半——列式布局还为压缩、向量化执行(Vectori…

【存储工程】Parquet 文件格式深度解析

上一篇我们讨论了列式存储(Columnar Storage)的核心思想:把同一列的数据连续存放,让分析查询只读取需要的列,而不是扫描整行。这个思想落地到具体文件格式时,需要回答一系列工程问题:文件内部怎么组织数据才能同时支持并行读取和列裁剪?同一列的数据用什么编码方式才能最大化压缩率?如何在不读取全部数据的前提下跳过…

【存储工程】Apache Arrow:零拷贝内存列式格式

在大数据和分析系统的演进过程中,一个反复出现的性能瓶颈不是计算本身,而是数据在不同系统之间搬运时的序列化(Serialization)与反序列化(Deserialization)开销。Pandas 把数据交给 Spark,Spark 把结果传给 R,R 再把子集喂给 TensorFlow——每一次跨系统传递,数据都要…

【存储工程】时序存储引擎

监控系统每秒钟从数万台机器上采集 CPU 使用率、内存占用、磁盘 IOPS、网络流量;物联网(IoT)网关把传感器温度、湿度、振动频率汇聚到云端;金融交易系统以毫秒级粒度记录每一笔报价和成交。这些数据有一个共同特征——每条记录都带有一个时间戳(Timestamp),按时间顺序源源不断地涌入,几乎只追加(Append-…

【存储工程】数据湖存储格式:Delta Lake、Iceberg 与 Hudi

数据湖(Data Lake)的核心思想是把海量异构数据以开放格式存储在廉价的对象存储(Object Storage)上,用计算引擎按需查询。Apache Parquet 解决了列式编码(Columnar Encoding)问题,让分析查询的 I/O 效率提升了一个数量级。但 Parquet 只是一个文件格式,它不管事…

【存储工程】Bitcask 与日志结构哈希表

在存储引擎(Storage Engine)的设计谱系中,Bitcask 占据着一个独特而优雅的位置: 它用最简单的数据结构——哈希表(Hash Table)与追加日志(Append-Only Log)—— 组合出了一个在特定工作负载下性能极其出色的键值存储引擎。 本文将从核心思想出发,逐层拆解 Bitcask 的架构…

【存储工程】嵌入式存储引擎对比

当我们提到"数据库"时,多数人首先想到的是 MySQL、PostgreSQL 这类以独立进程运行的数据库服务器。客户端通过网络协议连接到服务器,服务器管理存储、索引、事务和并发控制。然而,还有一类存储系统以库(Library)的形式直接链接到应用进程中,不需要独立的服务器进程,不需要网络通信,不需要序列化和反序列化—…

【存储工程】存储引擎概览:堆文件到 LSM-Tree 的演化路径

数据库系统的架构可以划分为两大层:上层的查询处理层负责解析 SQL、生成执行计划、优化查询;下层的存储引擎(Storage Engine)负责把数据持久化到磁盘,并在需要时高效地把数据取回来。查询处理层决定"做什么",存储引擎决定"怎么存、怎么取"。同一个查询处理层可以对接不同的存储引擎——MySQL 的 InnoD…

【存储工程】索引结构:从 B+Tree 到倒排索引

数据库里存了一亿行数据,要找出 userid 42 的那一行。没有索引的做法是全表扫描(Full Table Scan)——从第一个数据页读到最后一个数据页,逐行比对。假设每个数据页 16 KB,一亿行占 20 GB,即使顺序读能跑到 500 MB/s,也需要 40 秒。加一个 B+Tree 索引,三次磁盘 I/O…

【存储工程】块存储加密:LUKS 与 dm-crypt

在存储系统的安全防线中,加密是最后一道也是最重要的一道屏障。当物理安全措施失效——磁盘被盗、服务器被非法访问、退役硬盘未彻底销毁——只有加密能确保数据不被未授权方读取。块级加密(Block-Level Encryption)在存储栈的最低层工作,对上层文件系统和应用程序完全透明,不需要修改任何一行应用代码就能保护磁盘…

【存储工程】存储快照与精简配置

存储系统有两个看似独立、实则紧密交织的能力:快照(Snapshot)和精简配置(Thin Provisioning)。快照解决的是"时间维度"的问题——在任意时刻冻结数据状态,用于备份、回滚或测试;精简配置解决的是"空间维度"的问题——让存储容量按需分配,避免预先占满物理磁盘。两者的交叉点在于写时复制(Copy-on…

【存储工程】文件系统基础:inode、目录与 VFS

磁盘是一个线性的块数组,但没有人愿意用"第 48372 号扇区"来定位自己的文档。文件系统(File System)就是那个把"名字"映射到"数据"的翻译层——它把一片平坦的块空间组织成人类可以理解的层级结构,同时维护着每个文件的权限、大小、时间戳等元数据(Metadata)。

【存储工程】ext4 架构与调优

ext4 是 Linux 世界中使用最广泛的本地文件系统(Local Filesystem)。从 2008 年合入内核主线至今, 它已经在无数生产服务器、嵌入式设备以及桌面系统上稳定运行了十余年。本文将从磁盘布局、 核心数据结构、日志机制、分配策略等维度,对 ext4 进行全面剖析,并结合实际调优场景给出 可落地的最…

【存储工程】Btrfs:写时复制文件系统

ext4 和 XFS 走的是"就地更新"路线:数据写到哪个块,就直接覆盖那个块。这条路线简单、高效,但有一个根本性的问题——如果写到一半断电,磁盘上的数据处于半新半旧的状态,文件系统就损坏了。日志(Journal)机制可以缓解这个问题,但它本质上是"先写一遍日志,再写一遍数据",写放大不可避免。

【存储工程】文件系统选型与基准测试

在生产环境中,文件系统(Filesystem)的选择直接影响存储栈的性能上限、数据安全边界和运维复杂度。本文将从设计目标、元数据性能、数据吞吐、典型业务场景、基准测试方法论等多个维度,对 ext4、XFS、Btrfs(B-tree Filesystem)、ZFS(Zettabyte File System)四种主流文…

【存储工程】块设备层:bio、request 与 I/O 调度器

文件系统把"写这个文件"翻译成"写这些逻辑块",但逻辑块怎么变成磁盘控制器能执行的命令?中间那一层就是块设备层(Block Layer)。它做的事不复杂——把上层的 I/O 请求收集、合并、排序,然后交给设备驱动——但做得好不好,直接决定了存储栈的吞吐和延迟。

【存储工程】Page Cache 深度解析

应用程序每一次 read() 或 write() 系统调用,感觉像是直接在操作磁盘上的文件,但实际上,内核在中间插入了一层透明的缓存——页缓存(Page Cache)。这层缓存用物理内存保存最近访问过的文件数据,使得绝大多数读操作不需要触发磁盘 I/O,而写操作可以先落到内存,再由后台线程异步刷回存储设备。

【存储工程】SSD 与 NAND Flash:FTL、写放大与磨损均衡

SSD 已经在大多数性能敏感场景中取代了 HDD,但 SSD 并不是"没有机械部件的硬盘"——它是一个完全不同的存储架构,带来了一组全新的工程约束。理解这些约束,需要从 NAND Flash(NAND 闪存)的物理特性开始,逐层向上推导出 FTL(Flash Translation Layer)、垃圾回收(Garba…

【存储工程】持久化内存与存储层次

现代计算系统的性能瓶颈,往往不在处理器本身,而在数据的存取速度。从寄存器(Register)到磁带(Tape),存储层次结构跨越了十余个数量级的延迟差异。持久化内存(Persistent Memory,简称 PMem)的出现,试图在易失性内存与持久化存储之间架起一座桥梁,从根本上改变应用程序访问数据的方式。