数据库文档数据库后端【免费下载链接】couchdbSeamless multi-primary syncing database with an intuitive HTTP/JSON API, designed for reliability项目地址https://gitcode.com/gh_mirrors/co/couchdb点击查看免费下载导读本文深度解读 Apache CouchDB 仓库中 RFC 005FoundationDB 下 _all_docs 索引实现。当 CouchDB 把存储引擎迁移到 FoundationDB 后传统基于 B-tree 视图的_all_docs端点需要一套全新的数据模型来支撑同时GET /dbname返回的 dbinfo 元数据doc_count、update_seq、sizes、cluster 等也需要重新设计。读完本文你将掌握专用?BY_ID子空间的关键结构、原子操作维护计数器的原理、update_seq零写入读取技巧、三种数据尺寸的取舍以及 RFC 对_all_docs/ dbinfo HTTP 响应字段的移除与弃用决策。背景为什么需要专门的 all-docs 索引在传统 CouchDB 中_all_docs由一个基于 map-reduce 的视图couch_mrview支撑返回结果形如{total_rows: N, offset: M, rows: [...]}。而在 FoundationDB 数据模型下文档正文见 RFC 004 的?DOCUMENTS子空间和文档修订历史见 RFC 001 的?REVISIONS子空间被拆分为独立的键值存储区因此必须设计一个独立的索引子空间来回答“这个数据库里有哪些文档”这个问题。RFC 005 的核心目标有两个维护一份足以支撑_all_docs端点的全库文档索引明确GET /dbname响应中各个 dbinfo 元数据字段在 FoundationDB 上的存储与维护方式。_all_docs 索引数据模型?BY_ID 子空间RFC 005 提出正常的_all_docs请求由一个专用子空间dedicated subspace支撑数据库内每个“至少存在一个deletedfalse修订条目”的文档在该子空间中拥有唯一一个键。键结构如下(?BY_ID, DocID) (ValueFormat, RevPosition, RevHash)各元素定义元素定义ValueFormat值编码方式的枚举用于支持后续 schema 演进DocID文档 IDRevPosition正整数使用标准 tuple layer 编码有符号、变长、保序RevHash16 字节唯一标识该文档的获胜修订winning revision该结构与 RFC 001 中?REVISIONS子空间的修订元数据键保持一致的编码惯例RevPosition与RevHash的编码方式、ValueFormat/RevFormat的“枚举用于 schema 演进”思路均一脉相承。RFC 001 还定义了NotDeleted标志\x26表示修订叶已删除\x27表示未删除正是“deletedfalse条目”这一筛选条件的底层语义来源。索引维护规则盲写与删除清理盲写blind write该子空间的条目可以在每次更新事务中直接写入无需先读取旧值。并发写同一文档的协调完全依赖?REVISIONS子空间——RFC 001 的更新路径保证每个写者都会读取/修改“获胜分支”的修订元数据 KVFoundationDB 据此把并发修改同一文档的事务正确判为冲突。删除清理如果一个事务删除了某个文档的最后一个活跃编辑分支live edit branch它必须同时清除该文档在此子空间中的对应条目。这对应 RFC 001 中NotDeleted编码的语义——当所有分支的NotDeleted均为\x26已删除时文档就不该再出现在_all_docs中。include_docstrue 的两种实现路径RFC 明确include_docstrue时有两种实现选择且明确表示“该实现选择不影响实际数据模型”因此 RFC 不强制规定先范围请求后补查对?BY_ID子空间做一次范围请求拿到文档 ID 与修订信息再额外发起 N 个显式指定完整修订信息的范围请求去?DOCS子空间取回正文直接全量扫描对?DOCS子空间直接做完整范围扫描丢弃冲突正文conflict bodies以及与已删除修订关联的用户数据。第二种方式之所以可行是因为 RFC 004 将每个修订的文档体单独存储键形如{DbName, ?DOCUMENTS, DocID, NotDeleted, RevPos, RevHash, ...}并且“普通删除tombstone 中无用户数据根本不会出现在?DOCUMENTS子空间中”这让扫描时能低成本地跳过垃圾数据。dbinfo 元数据各字段在 FoundationDB 上的维护策略GET /dbname返回的 dbinfo JSON 对象包含大量数据库元数据。当前 CouchDB 的实现路径是 chttpd_db.erl 中通过fabric:get_db_info(DbName)从集群层聚合各分片信息后返回。RFC 005 对每个字段逐一给出了 FoundationDB 时代的方案db_name应可“平凡访问”trivially accessible——直接由数据库名编码得到无需额外维护。doc_count 与 doc_del_count原子操作计数器doc_count作为单个键维护使用 FoundationDB 的原子操作atomic operations变更。当某事务创建新文档、或重新创建“此前所有编辑分支都已被删除”的文档时计数器加 1。doc_del_count同样是原子操作维护的键。事务对某文档最后一个deletedfalse编辑分支打墓碑tombstone时加 1事务给“所有旧分支均已删除”的文档新增一个deletedfalse分支时减 1。RFC 强调修订模型revisions model保证每个事务都拥有足够信息判断是否需要修改上述一个或两个计数器。这正是 RFC 001 中获胜分支元数据包含BranchCount、NotDeleted与Sequence的价值——写者总是先读?REVISIONS中获胜分支的 KV从而天然知道本次编辑会让文档从“无活分支”变为“有活分支”或反之。值得对照的是当前 CouchDB 的存储引擎抽象层 couch_db_engine.erl 已经以行为回调的形式定义了这些元数据的读写接口如get_doc_count/1、get_del_doc_count/1、get_update_seq/1、set_update_seq/2并在#db记录中携带doc_count/doc_del_count字段——RFC 005 即是为 FoundationDB 引擎实现这些回调而设计的存储方案。update_seq零额外写入的读取技巧RFC 建议不要为update_seq做任何额外写入最有效的方式是在?CHANGES子空间末尾执行一次get_key操作配合last_less_thanKeySelector 取回最后一个键即可。?CHANGES子空间由 RFC 003 定义其键形如(changes, Sequence) (SeqFormat, DocID, RevPosition, RevHash, BranchCount, NotDeleted)其中Sequence是 13 字节值由数据库Incarnation1 字节与事务Versionstamp12 字节由提交版本 串行化序号 用户自定义字节组成拼接而成全集群全局单调递增。由于_changes子空间天然按Sequence排序直接取最后一个键即可得到当前update_seq且该值在 CouchDB 2.x/3.x 的 Base64 分片序列号基础上提供了更强的全序保证。purge_seq依赖 purge 设计RFC 表示purge_seq待定TBD取决于 purge 的详细设计如果 purge 最终完全是事务性的purge_seq可以固定为update_seq或者干脆删除。当前 CouchDB 中 purge 响应仍携带purge_seq字段见 chttpd_db.erl 中{purge_seq, null}的占位实现说明该字段在迁移期间需要额外处理。数据尺寸Data Sizes三种尺寸的取舍RFC 指出目前每个数据库跟踪三种尺寸尺寸含义sizes.external“在数据库外部表示内容所需的字节数”sizes.active将数据库存储在磁盘上的理论最小字节数sizes.file当前磁盘上的实际字节数关键讨论点active 与 file 的关系传统后端用sizes.active与sizes.file的对比指导压缩compaction决策。但 FoundationDB 不需要压缩而且存储引擎压缩可能造成的两者差异不会上抛给客户端因此 RFC 认为同时保留两者可能没有意义。external 的测量口径问题RFC 明确指出当前实现sizes.external测的不是 JSON 表示的长度而是 JSON 的未压缩 Erlang term 表示的大小——这是一个别扭的选择因为 Erlang term 的内部表示会随时间变化例如新版 Erlang 引入 Maps或未来直接由 JSON 解码器产出 RFC 004 定义的格式。实现所需的两块设施假设尺寸集合与计算方式达成一致实现需要两部分每个尺寸一个键用原子操作变更在?REVISIONS子空间中记录每个修订的大小使事务能计算每个文档的增量delta。cluster 对象r/w/q/n 的重新解释与弃用建议cluster对象中的r、w、q、n是 CouchDB 2.x 引入的用于描述数据库拓扑与操作的默认仲裁quorum设置。RFC 005 给出了它们在 FoundationDB 下的映射字段FoundationDB 下的解释r永远固定为 1w解释为记录提交的事务日志数取决于底层 FoundationDB 数据库的redundancy moden解释为托管某个键的存储服务器数量同样取决于redundancy modeq最接近的类比是用get_boundary_keysAPI报告边界键隐含的不同区间ranges数量RFC 提醒这种解释可能带来意外例如 “r1, w4, n3” 是流行配置但对期待 Dynamo 风格数字的人来说毫无意义。因此 RFC 倾向忽略向后兼容引导用户查看真正的 FoundationDB 配置信息并整体弃用cluster对象“Open for discussion”即该议题留待讨论。值得注意的是当前 CouchDB 的集群配置中分片参数n默认 3与q默认 2仍通过config:get_integer(cluster, n, 3)/config:get_integer(cluster, q, 2)读取见 chttpd_db.erl这是 2.x 语义的现状与 RFC 的迁移方向形成对照。Key Changes事务时限与 HTTP API 变更5 秒事务限制RFC 明确FoundationDB 的底层事务必须在5 秒内完成这隐式限制了单次_all_docs调用可返回的结果数量。这意味着大范围遍历必须分页pagination否则无法在事务时限内完成——这与 RFC 014分页 的讨论方向一致。HTTP API 移除项_all_docs响应中移除total_rows与offset新响应形式更简洁{rows: [ {id:foo, key:foo, value:{rev:1-deadbeef...}}, ... ]}dbinfo 响应中移除以下字段compact_runningFoundationDB 不需要压缩因此无需“压缩是否进行中”标志disk_format_versionRFC 解释这是一个棘手字段——我们为 FoundationDB 中存储的每一种键都定义了“格式版本”且版本可能键与键之间各不相同因此为整个数据库列一个单一数字是 ill-posed不适定的。已弃用、可随下一个大版本移除的字段以下字段已被标记弃用可独立于 FoundationDB 迁移在下一个大版本移除instance_start_timeotherdata_sizedisk_size影响面Applications and Modules affectedTBD取决于后续代码布局HTTP API 新增无安全考量未识别到任何安全问题。与相关 RFC 的协同关系RFC 005 并非孤立设计它与仓库src/docs/rfcs/目录下的其他 FoundationDB 系列 RFC 环环相扣RFC 001修订元数据模型——定义?REVISIONS子空间、获胜分支、NotDeleted编码、BranchCount与Sequence是?BY_ID索引“盲写 删除清理”规则的底层依据RFC 003sequence 索引——定义?CHANGES子空间与全局全序Sequence支撑update_seq的last_less_than读取方案其styleall_docs优化还利用BranchCount1避免多余请求RFC 004文档存储——定义?DOCUMENTS子空间的文档体键结构含NotDeleted、RevPos、RevHash与 1 MB 最大文档尺寸限制是include_docstrue两种实现路径的基础。总结RFC 005 为 CouchDB 的 FoundationDB 后端规划了两条清晰的实现主线一是用?BY_ID专用子空间 盲写策略维护全库文档索引借助修订模型天然的并发协调与“删除最后一个活跃分支即清除条目”的规则保持索引正确二是用原子操作键、last_less_thanKeySelector 与子空间结构分别承载 dbinfo 的计数器、序列号与尺寸信息并在数据尺寸、cluster 对象等语义层面果断做减法弃用、移除或重新解释以适配 FoundationDB 无需压缩、全序可控的新特性。对开发者而言理解这份 RFC 是把握 CouchDB 未来存储引擎演进方向、以及_all_docs/ dbinfo 行为变迁的关键入口。赞分享数据库文档数据库后端【免费下载链接】couchdbSeamless multi-primary syncing database with an intuitive HTTP/JSON API, designed for reliability项目地址https://gitcode.com/gh_mirrors/co/couchdb点击查看免费下载相关推荐Apache CouchDB 的 FoundationDB 序列索引设计_changes 数据模型、索引维护与访问模式深度解析Apache CouchDB 的 FoundationDB 序列索引设计_changes 数据模型、索引维护与访问模式深度解析 本文基于 Apache Cou数据库文档数据库后端深度解析Ai2Psd如何实现Illustrator到Photoshop的矢量图层无损转换深度解析Ai2Psd如何实现Illustrator到Photoshop的矢量图层无损转换 在数字设计工作流中Illustrator和Photoshop是设计数据库文档数据库后端LMCache 深度解析面向可扩展 LLM 推理的 KV Cache 管理层LMCache 深度解析面向可扩展 LLM 推理的 KV Cache 管理层 LMCache 是一个面向 LLM 推理的 KV Cache 管理层KV ca数据库文档数据库后端上一篇如何用 Apktool 解包与重建 Android APK3 步跑通全流程的完整指南下一篇uuid v7时间戳UUID实战为什么它是数据库主键的终极选择创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考