向量数据库数据库人工智能后端【免费下载链接】lancedbDeveloper-friendly OSS embedded retrieval library for multimodal AI. Search More; Manage Less.项目地址https://gitcode.com/gh_mirrors/la/lancedb点击查看免费下载LanceDB 的 Node.jsTypeScriptSDK 中RemovalStats接口用于描述一次清理cleanup / prune操作的结果统计被移除的旧版本数量与释放的磁盘空间。本文以该接口为切入点结合仓库中 TypeScript 声明、Rust N-API 绑定与 Rust 内核实现完整讲解RemovalStats的两个字段、它如何通过table.optimize()产生、相关参数的行为边界以及如何在实际代码中读取并利用这些统计信息。RemovalStats 接口全貌RemovalStats定义在 docs/src/js/interfaces/RemovalStats.md是 LanceDB JS SDK 自动生成 API 文档的一部分。接口的语义注释为Statistics about a cleanup operation关于一次清理操作的统计信息它只包含两个数值字段interface RemovalStats { /** The number of bytes removed */ bytesRemoved: number; /** The number of old versions removed */ oldVersionsRemoved: number; }字段类型含义bytesRemovednumber本次清理操作从磁盘上移除的数据字节数oldVersionsRemovednumber本次清理操作移除的旧数据集版本数量这两个字段都是整数语义的数字类型。它们描述的是清理操作cleanup operation的结果而不是查询或写入的结果——即当你主动让 LanceDB 删除旧版本数据时返回给你用于评估清理是否生效、释放了多少空间的指标。谁会产生 RemovalStatsoptimize 中的版本清理PruneRemovalStats不会凭空出现它作为OptimizeStats.prune属性返回。在 nodejs/lancedb/table.ts 与 docs/src/js/interfaces/OptimizeStats.md 中可以看到table.optimize()的返回类型为interface OptimizeStats { compaction: CompactionStats; prune: RemovalStats; }也就是说一次optimize()调用内部会依次执行三类动作——文件压缩compact、版本清理prune与索引优化index其中版本清理的结果单独以RemovalStats汇报而bytesRemoved/oldVersionsRemoved正是 prune 阶段的实际产出。import * as lancedb from lancedb/lancedb; const db await lancedb.connect(./data); const table await db.openTable(my_table); // 执行 optimize默认清理 7 天前的旧版本 const stats await table.optimize(); console.log(清理旧版本: ${stats.prune.oldVersionsRemoved}); console.log(释放磁盘空间: ${stats.prune.bytesRemoved} bytes);控制清理行为的两个关键参数清理行为由OptimizeOptions控制同样定义在 nodejs/lancedb/table.tsinterface OptimizeOptions { cleanupOlderThan: Date; deleteUnverified: boolean; }cleanupOlderThan清理截止时间类型为Date绝对时间戳。所有早于该时间点提交的版本都会被移除当前版本永远不会被删除。不传时默认值为7 天即清理 7 天前提交的所有旧版本。传入new Date()时表示删除本次调用之前提交的所有版本由于 optimize 调用自身产生的新版本晚于截止时间因此会被保留见 nodejs/lancedb/table.ts 的示例注释。// 删除 1 天前的所有旧版本 const olderThan new Date(); olderThan.setDate(olderThan.getDate() - 1); await table.optimize({ cleanupOlderThan: olderThan }); // 删除本次调用之前提交的所有版本 await table.optimize({ cleanupOlderThan: new Date() });deleteUnverified是否删除未验证文件由于新提交的文件可能属于进行中的事务默认情况下7 天内的文件不会被删除。当你确定当前没有任何进行中的事务时可以设置为true从而删除所有早于cleanupOlderThan的文件包括较新的未验证文件。文档与源码均给出了明确警告只有在能保证没有其他进程正在操作该数据集时才应开启否则可能将数据集置入损坏状态见 nodejs/lancedb/table.ts 与 rust/lancedb/src/table/optimize.rs。底层实现从 TypeScript 到 Rust 内核RemovalStats在 TypeScript 侧的字段名是驼峰命名而 Rust 内核使用蛇形命名映射关系清晰可见。N-API 绑定层在 nodejs/src/table.rs 中optimize()是#[napi]异步方法它将cleanupOlderThan毫秒时间戳转换为 Rust 侧的绝对时间DateTimeUtc分别执行压缩、清理与索引优化最后把结果组装为OptimizeStatsprune: RemovalStats { bytes_removed: prune_stats.bytes_removed as i64, old_versions_removed: prune_stats.old_versions as i64, },而RemovalStats结构体本身也定义在同文件nodejs/src/table.rs/// Statistics about a cleanup operation pub struct RemovalStats { pub bytes_removed: i64, pub old_versions_removed: i64, }这里bytes_removed与old_versions_removed直接来自 Rust 内核清理动作的返回值字段语义与 TypeScript 接口一一对应。值得注意的是当未指定cleanupOlderThan时绑定层会走OptimizeAction::Prune { older_than: None, ... }分支即使用内核默认的 7 天保留策略。Rust 内核清理动作的真实发生地真正的清理逻辑位于 rust/lancedb/src/table/optimize.rsOptimizeAction::Prune枚举变体携带三个参数older_than保留时长、delete_unverified是否删除未验证文件、error_if_tagged_old_versions存在被标记的旧版本时是否报错cleanup_old_versions()调用lance::dataset::Dataset::cleanup_old_versions传入保留时长与两个布尔选项返回RemovalStatscleanup_old_versions_before()则使用CleanupPolicyBuilder::default().before_timestamp(...)构建清理策略对应 JS 侧传入绝对时间戳的场景OptimizeStats结构中prune字段为OptionRemovalStats——当执行仅清理prune-only操作时compaction为None此时prune是唯一的统计来源。此外内核清理完成后还会顺带删除不再被任何存活版本引用的计算列签名 sidecar 文件见 rust/lancedb/src/table/optimize.rs 中cleanup_old_versions对prune_sidecars的调用这也是释放空间的一部分。测试如何验证这两个字段仓库测试对RemovalStats的语义给出了精确的行为约束是理解这两个字段含义的最佳佐证。单元测试prune-only 场景在 rust/lancedb/src/table/optimize.rs 的内核测试中先连续add5 次数据制造多个版本再以 0 天为 cutoff 执行清理let prune_stats stats.prune.unwrap(); assert!(prune_stats.bytes_removed 0); assert_eq!(prune_stats.old_versions, 5);这验证了两点bytes_removed在确有旧版本被删除时严格大于 0old_versions精确等于被删除的旧版本数量这里为 5。Node.js 集成测试时间戳精度问题nodejs/test/table.test.ts 中的 cleanups old versions 用例非常值得注意// Lance 以纳秒精度存储版本时间戳而 JS Date 只有毫秒精度。 // 若截止时间与最后一次提交落在同一毫秒内截断后可能早于该提交 // 导致其被保留因此先等待时钟跳到下一秒。 const cutoff await nextMillisecond(); const stats await table.optimize({ cleanupOlderThan: cutoff }); expect(stats.prune.bytesRemoved).toBeGreaterThan(0); expect(stats.prune.oldVersionsRemoved).toBe(2);该测试揭示了cleanupOlderThan精度的一个关键工程细节Lance 的版本时间戳是纳秒精度而 JavaScriptDate只有毫秒精度同一毫秒内的边界可能造成想删却没删掉的偏差测试因此显式等待时钟跳转后再取 cutoff。在真实项目中建议截止时间与业务提交时间拉开一定余量。deleteUnverified 的行为差异同文件 delete unverified 用例展示了deleteUnverified对统计结果的直接影响先手动删除一个 manifest 文件模拟未验证状态随后optimize({ deleteUnverified: false })时oldVersionsRemoved为 0未验证文件默认不删改用cleanupOlderThan: new Date(), deleteUnverified: true后oldVersionsRemoved大于 1。由此可以确认oldVersionsRemoved的值会随deleteUnverified与cleanupOlderThan的取值显著变化这正是解读统计结果时需要注意的前提。一个完整可运行的实战示例结合上述内容给出一个包含注释的完整示例演示如何用RemovalStats衡量清理效果import * as lancedb from lancedb/lancedb; async function main() { const db await lancedb.connect(./example_db); const table await db.openTable(logs); // 1) 常规优化默认清理 7 天前的旧版本统计清理结果 const stats1 await table.optimize(); console.log([默认] 移除版本: ${stats1.prune.oldVersionsRemoved}, 释放: ${stats1.prune.bytesRemoved} bytes); // 2) 激进清理删除本次调用前提交的所有版本 // 注意仅当确认没有其他进程在写该表时才可配合 deleteUnverified 使用 const stats2 await table.optimize({ cleanupOlderThan: new Date(), deleteUnverified: true, }); console.log([激进] 移除版本: ${stats2.prune.oldVersionsRemoved}, 释放: ${stats2.prune.bytesRemoved} bytes); // 3) 判断是否有空间可回收bytesRemoved 为 0 说明没有更旧的版本可清理 if (stats2.prune.bytesRemoved 0) { console.log(没有可回收的旧版本当前表已处于最紧凑状态); } } main();使用注意事项当前版本永不删除无论cleanupOlderThan如何设置当前版本都不会被移除因此oldVersionsRemoved不会把当前版本计入。默认保留 7 天不传参时只清理 7 天前的版本想清理更多需显式传入更早的截止时间。deleteUnverified双刃剑它能加速释放空间但会绕过进行中事务保护多进程并发写入场景下务必保持默认的false。时间戳精度边界JSDate毫秒精度与 Lance 纳秒精度之间存在截断问题截止时间与提交时间过于接近时可能导致边界版本保留对应测试见 nodejs/test/table.test.ts。跨语言一致性Python SDK 中RemovalStats同样暴露bytes_removed与old_versions_removed两个字段见 python/python/lancedb/_lancedb.pyi说明这是 LanceDB 各语言绑定的统一统计语义。综上RemovalStats虽只有两个字段却是评估 LanceDB 数据生命周期管理与磁盘占用优化的核心指标。理解其产生时机optimize 的 prune 阶段、控制参数cleanupOlderThan/deleteUnverified与底层实现能够帮助你在生产环境中安全、精确地回收存储空间。赞分享向量数据库数据库人工智能后端【免费下载链接】lancedbDeveloper-friendly OSS embedded retrieval library for multimodal AI. Search More; Manage Less.项目地址https://gitcode.com/gh_mirrors/la/lancedb点击查看免费下载相关推荐LanceDB Node.js 更新操作指南深入理解 UpdateResult 接口与 table.update()LanceDB Node.js 更新操作指南深入理解 UpdateResult 接口与 table.update 导读 UpdateResult 是 Lanc向量数据库数据库人工智能后端LanceDB Node.js SDK 索引统计IndexStatistics 接口字段详解与实战LanceDB Node.js SDK 索引统计IndexStatistics 接口字段详解与实战 导读 IndexStatistics 是 LanceDB向量数据库数据库人工智能后端LanceDB Node.js 的 MemtableStats 接口深入理解 LSM 写路径中的内存 Memtable 统计LanceDB Node.js 的 MemtableStats 接口深入理解 LSM 写路径中的内存 Memtable 统计 导读 MemtableStats向量数据库数据库人工智能后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考