Keyv项目中SQLite存储适配器的命名空间迭代器问题分析

问题背景

在Keyv项目中，当开发者使用SQLite作为存储后端时，如果多个Keyv实例共享同一个存储适配器(store)但使用不同的命名空间(namespace)，会出现一个严重的问题：所有实例的迭代器(iterator)都会返回最新创建实例的命名空间数据，而不是各自命名空间的数据。

问题复现

通过以下代码可以清晰复现该问题：

import KeyvSqlite from "@keyv/sqlite";
import Keyv from "keyv";

const store = new KeyvSqlite("sqlite://.data/test.db");

const keyvA = new Keyv({ store, namespace: "a" });
const keyvB = new Keyv({ store, namespace: "b" });

// 向两个命名空间写入不同数据
await keyvA.set("a", "x"); 
await keyvB.set("a", "one");

// 迭代器会返回错误的数据
for await (const [key, value] of keyvA.iterator()) {
  console.log(key, value); // 预期输出"x"，实际输出"one"
}

问题原因分析

经过深入分析，这个问题源于Keyv的SQLite存储适配器在实现迭代器功能时的设计缺陷：

1. 共享存储适配器状态：当多个Keyv实例共享同一个存储适配器时，命名空间信息被存储在适配器级别而非实例级别。

2. 迭代器命名空间覆盖：最新创建的Keyv实例会覆盖存储适配器的命名空间设置，导致所有实例的迭代器都使用最后一个命名空间。

3. 查询隔离失效：本质上这是SQL查询条件中的命名空间过滤失效，所有查询都使用了相同的命名空间条件。

临时解决方案

目前官方建议的临时解决方案是为每个命名空间创建独立的存储适配器实例：

const keyvA = new Keyv({ 
  store: new KeyvSqlite("sqlite://.data/test.db"), 
  namespace: "a" 
});

const keyvB = new Keyv({
  store: new KeyvSqlite("sqlite://.data/test.db"),
  namespace: "b"
});

但这种方法存在明显缺点：

• 每个命名空间都会创建独立的数据库连接
• 对于需要大量动态命名空间的场景(如上千个命名空间)会造成资源浪费

技术影响评估

这个问题对以下场景影响较大：

1. 多租户应用：每个租户使用独立命名空间存储数据
2. 模块化系统：不同功能模块使用独立命名空间隔离数据
3. 动态命名空间场景：运行时动态创建大量命名空间

未来改进方向

根据项目维护者的反馈，未来计划改进命名空间的工作机制：

1. 实现真正的命名空间隔离
2. 优化共享存储适配器下的命名空间管理
3. 可能引入连接池机制来优化多命名空间场景

开发者建议

对于当前需要处理大量动态命名空间的开发者，可以考虑：

1. 暂时使用原生SQLite实现替代
2. 监控Keyv项目的更新，等待命名空间机制改进
3. 在非关键业务中使用临时解决方案

这个问题反映了存储抽象层设计中命名空间隔离的重要性，对于构建可靠的多租户系统尤为关键。