数据库NoSQL嵌入式数据库实时数据库【免费下载链接】rxdbThe local-first database that runs on every JS runtime and replicates with your existing backend - no vendor, no lock-in - https://rxdb.info/项目地址https://gitcode.com/gh_mirrors/rx/rxdb点击查看免费下载Minimongo 是 Meteor.js 于 2012 年引入的客户端 MongoDB 兼容数据层曾让大量开发者第一次接触浏览器端 MongoDB 查询接口这一概念。本文以 RxDB当前仓库gh_mirrors/rx/rxdb为主体对比 Minimongo 的能力边界与 RxDB 的替代方案从持久化存储、可观察查询、冲突处理、任意后端复制到多标签协调逐项给出可运行的代码示例与源码级佐证帮助你判断何时该从 Minimongo 迁移到 RxDB以及迁移后如何落地。什么是 MinimongoMinimongo 是用 JavaScript 编写的、MongoDB 查询接口的客户端内存实现。它作为 Meteor.js 框架的一部分被创建用以支撑一种名为latency compensation延迟补偿的编程模型用户执行操作时客户端立即把变更应用到本地 Minimongo 集合UI 瞬间更新同时把一次写入在后台发送给服务器如果服务器拒绝了这次写入本地状态再回滚。Minimongo 最大的优点是熟悉的 MongoDB 风格 API。熟悉 MongoDB 的开发者可以在客户端使用与服务端相同的 selector 语法来调用find、insert、update和remove。独立的mWater/minimongo包2014 年 1 月从 Meteor fork 出来增加了 IndexedDB、WebSQL、LocalStorage 等持久化存储后端让 Minimongo 得以脱离 Meteor 生态独立存活。但该独立包已多年未获得积极维护不应在新项目中使用。简要时间线2012—— Minimongo 作为 Meteor.js 的核心模块被引入支撑 DDPDistributed Data Protocol数据同步层。2014——mWater/minimongo项目 fork 了 Meteor 代码使其可作为 Meteor 之外的 npm 包使用并增加了地理空间查询支持与存储适配器。2016-2020—— Minimongo 作为更大框架的一部分随 Meteor 持续更新独立 fork 的维护活动逐渐减少。2024-2025—— 在 Meteor 3.x 中Minimongo 仍作为客户端缓存层随框架发布但在 Meteor 之外独立 fork 实际上已停止维护。需要客户端 MongoDB 风格数据库的新项目通常会选择能力更强的工具。Minimongo 如今的使用场景Minimongo 仍在被使用但基本只作为Meteor 框架栈的一部分。作为独立于 Meteor 的库它已很少被推荐独立 fork 的仓库长期没有新 release未处理的 issue 持续堆积却无人回复。对不使用 Meteor 的开发者而言Minimongo 提供了熟悉的查询语法却缺少生产级离线优先应用所需的基础设施默认没有持久化存储、没有可观察查询、没有基于修订revision的冲突处理、没有内置复制协议。Minimongo 的工作方式在 Meteor 技术栈中Minimongo 充当服务器发布数据的本地镜像。服务器定义publications发布——即 MongoDB 集合的过滤子集客户端subscribe订阅这些发布Meteor 的 DDP 协议通过 WebSocket 连接把文档流式推送到客户端的 Minimongo 集合。// Server-side: a Meteor publication Meteor.publish(recentPosts, function () { return Posts.find({}, { sort: { createdAt: -1 }, limit: 50 }); }); // Client-side: subscribing and querying Minimongo Meteor.subscribe(recentPosts); const posts Posts.find({ category: news }).fetch();在客户端Posts变量指向一个 Minimongo 集合。find()之类的操作完全在内存中对本地缓存执行。写入先进入 Minimongo 以获得乐观结果再传播到服务器。而一旦你在 Meteor 之外使用 Minimongo就失去了 DDP 层剩下的只是一个必须手动填充和同步的内存存储没有任何标准协议或内置机制来让它与某个后端保持同步。Minimongo 的关键局限默认没有持久化存储核心 Minimongo 实现把所有文档放在内存中。用户关闭或刷新浏览器标签页后所有数据都会丢失。应用必须重新连接服务器并重新拉取全部数据才能恢复可用。独立mWaterfork 中虽然存在一些存储适配器IndexedDB、LocalStorage但实现维护不佳。对生产应用而言依赖它们意味着引入风险。这是任何需要离线优先行为的场景中最致命的局限。一个离线优先应用必须能在用户完全没有网络连接时启动、读取数据并接受写入——包括浏览器刷新之后。Minimongo 无法在不大幅额外开发的情况下保证这一点。没有可观察查询Minimongo 不提供原生的 observable / 响应式查询接口。在 Meteor 内部响应式能力由TrackerMeteor 自己的依赖追踪系统提供当响应式数据源变化时Tracker 的响应式计算会重新执行。这套响应式机制完全绑定 Meteor 生态与 RxJS、Vue 的响应式、React 或其他标准 JavaScript 响应式原语都不兼容。如果独立使用 Minimongo集合数据变化时你得不到任何自动通知只能自己轮询或实现自定义事件系统。没有文档修订或冲突处理Minimongo 按_id索引每个文档的当前状态。它没有文档修订revision的概念没有版本向量也没有检测写入冲突的机制。如果两个客户端在其中一个离线期间修改了同一文档Minimongo 的数据模型既无法表示两个版本也无法帮助应用在两者之间做出选择。在 Meteor 的 DDP 模型中服务器永远获胜。客户端恢复在线后服务器应用冲突状态时本地文档会被静默覆盖。这对简单协作场景可行但对用户长时间离线、需要保留自己修改的应用来说行不通。MongoDB 查询支持不完整Minimongo 只实现了 MongoDB 查询语言的子集。以下 MongoDB 特性在 Minimongo 中缺失或仅部分支持没有聚合管道$lookup、$group、$facet、$unwind没有多文档事务二级索引支持有限部分查询运算符的行为与服务端等价实现不一致这意味着针对 Minimongo 编写的查询代码不能总是直接用于服务器端的 MongoDB反之亦然。没有多标签页支持每个运行 Minimongo 应用的浏览器标签页各自维护一份内存存储标签页之间没有协调。标签页 A 中的写入在标签页 B 中不可见直到两个标签页都从服务器重新拉取。对于用户可能同时打开多个标签页的应用这会导致数据视图不一致。活跃度数据印证数字也反映了这一现状。截至 2026 年 7 月 30 日原文档记载的数据mWater/minimongo仓库约有 1,212 个 GitHub star而 RxDB 约有 23,296 个minimongo包近 30 天 npm 下载量约 13,810 次rxdb则约为 270,494 次。开发节奏同样放缓mWater/minimongo仓库master分支的最新提交停留在 2025 年 10 月。RxDB 如何解决这些问题RxDB 是一个local-first本地优先的 JavaScript 数据库把本地存储当作主要数据源所有读写都先在本地完成与后端服务器的复制在后台运行。数据库持久化到所选的存储引擎因此数据在页面刷新、浏览器重启后依然存在且完全不需要网络连接。跨环境的持久化存储RxDB 采用可插拔存储系统。你可以按部署环境选择匹配的存储引擎环境存储方案浏览器IndexedDB浏览器高吞吐OPFSOrigin Private File SystemReact Native / ExpoSQLiteNode.js / ElectronFilesystem / SQLite测试Memory多标签页浏览器SharedWorker切换存储引擎只需修改创建数据库时的storage参数其上层所有应用代码保持不变import { createRxDatabase } from rxdb/plugins/core; import { getRxStorageIndexedDB } from rxdb/plugins/storage-indexeddb; const db await createRxDatabase({ name: myapp, storage: getRxStorageIndexedDB() }); await db.addCollections({ posts: { schema: { title: post schema, version: 0, primaryKey: id, type: object, properties: { id: { type: string, maxLength: 100 }, title: { type: string }, category: { type: string }, createdAt: { type: number } }, required: [id, title, category, createdAt], indexes: [createdAt, category] } } });完成上述设置后写入db.posts的所有数据都会持久化到 IndexedDB。用户离线、刷新浏览器或重启设备后下一次加载即可立即读到数据无需任何服务器往返。从仓库源码看存储引擎被抽象为统一的RxStorage接口见 src/types/rx-storage.d.ts各引擎插件IndexedDB、OPFS、SQLite、Memory、LocalStorage、MongoDB、FoundationDB 等见 src/plugins 目录都实现同一套读写、查询、变更流协议这正是只换storage参数即可迁移环境的底层原因。基于 RxJS 的可观察查询RxDB 的响应式层建立在 RxJS 之上——JavaScript 生态中最广泛采用的反应式编程库之一。RxDB 中每个查询都通过$属性暴露一个 Observable订阅时立即发出当前结果集底层数据变化时重新发出。// Subscribe to all posts in the news category, ordered by date const newsPosts$ db.posts .find({ selector: { category: news }, sort: [{ createdAt: desc }] }) .$; newsPosts$.subscribe(posts { console.log(News posts updated:, posts.length); renderPostList(posts); });每当有帖子被插入、更新或删除这个订阅都会自动触发。不需要轮询、不需要手动缓存失效、不需要任何框架特定的接线。同一个订阅在 React、Vue、Angular、Svelte、SolidJS 或纯 JavaScript 中都能工作。RxDB 还在文档级和字段级暴露 observable// Watch a single documents title field const doc await db.posts.findOne(post-001).exec(); doc.get$(title).subscribe(newTitle { console.log(Title changed to:, newTitle); }); // Watch the entire collection for any change db.posts.$.subscribe(changeEvent { console.log(Change event:, changeEvent.operation, changeEvent.documentId); });这种细粒度的响应式能力让你无需编写任何手动刷新逻辑就能构建反映当前数据状态的 UI。除此之外RxDB 还使用event-reduce算法优化查询重执行当一个文档被插入、更新或删除时RxDB 会检查能否仅凭变更事件更新既有查询的结果集而不必对存储引擎重新执行完整查询。这在写密集型场景中能显著减少存储读取次数。该机制在仓库中由 src/event-reduce.ts 实现——它把 RxDB 的变更事件转换为event-reduce-js的变更事件再利用预计算的查询参数QueryParams增量推导newResults只有当事件无法增量推导时才回退为重新执行完整查询EventReduceResultNeg见 src/event-reduce.ts。文档修订与冲突处理RxDB 追踪每个文档的修订历史。每次写入都会为文档附加一个修订标识符复制层利用这些修订来检测并解决本地数据库与服务器之间的冲突。当同一文档存在两个版本一个本地、一个来自服务器时RxDB 会调用可配置的conflict handler冲突处理器来决定结果await db.addCollections({ posts: { schema: postSchema, conflictHandler: async (input) { const { newDocumentState, realMasterState } input; // Strategy: keep the version with the most recent updatedAt timestamp if (newDocumentState.updatedAt realMasterState.updatedAt) { return { documentData: newDocumentState }; } return { documentData: realMasterState }; } } });你可以实现应用所需的任意冲突解决策略最后写入获胜last-write-wins、字段级合并、用户提示解决或通过 CRDT 自动调和。RxDB 原生支持 CRDTConflict-free Replicated Data Types无冲突复制数据类型无需自定义处理器即可自动、确定性地解决冲突import { getCRDTSchemaPart, RxDBcrdtPlugin } from rxdb/plugins/crdt; import { addRxPlugin } from rxdb/plugins/core; addRxPlugin(RxDBcrdtPlugin); const counterSchema { version: 0, primaryKey: id, type: object, properties: { id: { type: string, maxLength: 100 }, // The CRDT field stores the operation log for automatic merging crdts: getCRDTSchemaPart() }, crdt: { field: crdts } };有了 CRDT 支持RxDB 可以自动合并来自多个客户端的并发编辑非常适合 Minimongo 需要大量自定义代码才能处理的协作编辑场景。从源码实现看冲突处理的契约定义在 src/types/conflict-handling.d.ts冲突处理器的输入RxConflictHandlerInput包含assumedMasterState、realMasterState与newDocumentState三个文档状态注意它们是不含_meta等本地元数据的WithDeletedRxDocType因为这些元数据不参与复制、不能用于解决冲突输出要么是{ isEqual: true }表示两个版本完全相同、无需解决要么是{ isEqual: false, documentData }给出解决后的文档。RxDB 内置的默认冲突处理器在 src/replication-protocol/default-conflict-handler.ts 中isEqual用deepEqual做全量深比较resolve则总是丢弃 fork 状态、采用 master 状态即服务器获胜——这与 Meteor DDP 模型一致但它只是可替换的默认值。冲突的实际解决发生在复制管道的上游侧resolveConflictError调用conflictHandler.resolve(input, replication-resolve-conflict)并为解决后的文档重建修订号_rev与最后写入时间lwt见 src/replication-protocol/conflicts.ts。CRDT 插件src/plugins/crdt/index.ts则在文档中维护操作日志字段operations数组与hash每次写入追加操作并通过哈希链接保证操作顺序的确定性。与任意后端复制Minimongo 的复制绑定 Meteor 的 DDP 协议要求 Meteor 服务器搭配 MongoDB 后端独立版 Minimongo 则完全没有内置复制。RxDB 的复制是后端无关的。复制系统提供一个简单的 pull/push 接口你可以针对任意服务器实现import { replicateRxCollection } from rxdb/plugins/replication; const replicationState await replicateRxCollection({ collection: db.posts, replicationIdentifier: posts-replication-v1, pull: { handler: async (checkpoint, batchSize) { const response await fetch( /api/posts/pull?since${checkpoint?.updatedAt ?? 0} limit${batchSize} ); return response.json(); // { documents: [...], checkpoint: {...} } } }, push: { handler: async (rows) { const response await fetch(/api/posts/push, { method: POST, body: JSON.stringify(rows), headers: { Content-Type: application/json } }); return response.json(); // return conflicting documents if any } }, live: true, retryTime: 5000 }); replicationState.error$.subscribe(err { console.error(Replication error:, err); });如果网络中断复制状态会按配置的间隔自动重试。本地写入总是立即成功并排队等待下一次成功同步。离线期间不会丢失任何数据。该复制插件以 src/plugins/replication/index.ts 为基础原语实现——文件头注释明确说明这个插件包含创建 RxDB 客户端-服务器复制所需的原语既可被其他复制插件复用也可配合自定义复制 handler 独立使用。retryTime则被awaitRetry包装进collection.promiseWait(retryTime)的重试逻辑见 src/plugins/replication/replication-helper.ts。除自定义 HTTP 复制外RxDB 还提供了常见后端的现成插件CouchDB 复制GraphQL 复制Firestore 复制WebSocket 复制WebRTC 点对点复制多标签页协调RxDB 通过 SharedWorker 存储 处理多标签页浏览器应用。当同一个应用的多个标签页打开时它们都连接到一个运行在 SharedWorker 中的共享数据库实例。所有写入和订阅都经过这个共享实例因此一个标签页的变更会立即在其他所有标签页中可见import { getRxStorageSharedWorker } from rxdb/plugins/storage-shared-worker; const db await createRxDatabase({ name: myapp, storage: getRxStorageSharedWorker({ workerInput: new SharedWorker( new URL(rxdb/plugins/storage-shared-worker/worker.js, import.meta.url), { type: module } ) }) });完成设置后任何标签页中的订阅都观察同一条统一数据流无需额外代码即可保持标签页同步。在不支持 SharedWorker 的环境中RxDB 回退到使用 BroadcastChannel API 跨标签页传播变更事件——即使使用标准 IndexedDB 存储所有打开的标签页也能看到更新。查询能力与索引RxDB 的find操作使用MongoDB 兼容查询语法熟悉 Minimongo 查询接口的开发者可以使用类似的 selector 和 sort 表达式。与 Minimongo 不同RxDB 在schema 层面强制定义索引因此存储引擎可以使用高效的 B-tree 查找而不是全集合扫描// Schema with compound and single-field indexes const postSchema { version: 0, primaryKey: id, type: object, properties: { id: { type: string, maxLength: 100 }, category: { type: string, maxLength: 50 }, authorId: { type: string, maxLength: 100 }, createdAt: { type: number } }, required: [id, category, authorId, createdAt], indexes: [ createdAt, category, [category, createdAt] // compound index for category time queries ] }; // This query uses the compound index const results await db.posts.find({ selector: { category: news }, sort: [{ createdAt: desc }], limit: 20 }).exec();Minimongo 因为没有索引基础设施每次查询都对内存中的全部文档做线性扫描。对于几百个文档的集合这尚可接受但到几千个文档时性能会明显下降。RxDB 的查询规划与索引选择逻辑在 src/query-planner.ts 与 src/custom-index.ts 中实现schema 索引定义则写入集合 schema 的indexes字段见 src/rx-schema-helper.ts 的索引处理。Schema 校验与类型安全RxDB 会在文档写入存储之前用 JSON Schema 校验每个文档。这意味着数据完整性在数据库层面得到保证而不仅仅依赖应用代码// Invalid documents are rejected at insert time try { await db.posts.insert({ id: post-002, // title is missing, which is required category: news, createdAt: Date.now() }); } catch (err) { console.error(Validation error:, err.message); }Minimongo 没有内置 schema 校验insert或update传什么它就存什么。这让错误数据更容易被写入集合进而引发难以排查的隐性 bug。RxDB 还会根据 schema 定义自动生成 TypeScript 类型让所有集合操作都获得完整的 IDE 自动补全和编译期类型检查。定位谁应该迁移如果你正在构建一个不需要长期离线能力的标准 Meteor 应用Minimongo 是合理的选择。在这个狭窄的上下文里它恰好完成了设计目标提供一个快速、乐观的客户端缓存镜像 MongoDB 的发布数据。但如果你在 Meteor 生态之外构建任何东西或者你的 Meteor 应用需要以下能力在无服务器连接的情况下跨页面刷新持久化数据能与 React、Vue、Angular 或纯 JavaScript 配合的响应式查询并发离线编辑的冲突解决与 MongoDB 之外的后端复制多标签页状态协调带校验的类型安全 schema……那么 Minimongo 就不是合适的工具而 RxDB 开箱即用地覆盖了上述全部需求。快速上手 RxDB安装 RxDB 和 RxJSnpm install rxdb rxjs创建数据库、添加集合并订阅响应式查询import { createRxDatabase, addRxPlugin } from rxdb/plugins/core; import { RxDBDevModePlugin } from rxdb/plugins/dev-mode; import { getRxStorageIndexedDB } from rxdb/plugins/storage-indexeddb; // Add the dev mode plugin for schema validation errors during development addRxPlugin(RxDBDevModePlugin); const db await createRxDatabase({ name: blogapp, storage: getRxStorageIndexedDB() }); await db.addCollections({ posts: { schema: { title: post schema, version: 0, primaryKey: id, type: object, properties: { id: { type: string, maxLength: 100 }, title: { type: string }, category: { type: string }, authorId: { type: string }, createdAt: { type: number }, updatedAt: { type: number } }, required: [ id, title, category, authorId, createdAt, updatedAt ], indexes: [createdAt, category] } } }); // Insert a document await db.posts.insert({ id: post-001, title: Getting Started with Local-First Apps, category: tutorial, authorId: user-42, createdAt: Date.now(), updatedAt: Date.now() }); // Subscribe reactively to all tutorial posts db.posts.find({ selector: { category: tutorial }, sort: [{ createdAt: desc }] }).$.subscribe(posts { console.log(Tutorial posts:, posts.map(p p.title)); });完成初始设置后你可以添加 复制 与既有后端同步也可以使用 SQLite 存储插件 配合同一套集合 schema 部署到 React NativeExpo 场景见 React Native 数据库指南。对比总结维度MinimongoRxDB类型内存中的客户端缓存持久化的本地优先数据库持久化默认在内存中页面刷新即丢失原生支持 IndexedDB、OPFS、SQLite、Filesystem响应式查询仅通过 Meteor TrackerMeteor 专属RxJS Observables生态标准可观察变更流独立版本不可用集合、文档、字段级别均可观察冲突处理无服务器覆盖客户端可配置冲突处理器支持 CRDT文档修订无每个文档内置修订追踪复制协议DDP仅 Meteor或独立版无复制HTTP、CouchDB、GraphQL、WebSocket、WebRTC、自定义后端要求MongoDB经 Meteor DDP任意后端或无需后端多标签页支持无每个标签页各自持有内存存储SharedWorker 提供统一跨标签页状态Schema 校验无内置每次写入均做 JSON Schema 校验TypeScript 支持部分完整从 schema 自动生成类型查询索引始终全集合扫描显式定义索引高效 B-tree 查找聚合管道不支持非内置可通过自定义计算字段实现移动端React Native不支持iOS/Android 的 SQLite 存储插件积极维护独立版否mWater fork 未维护是持续开发premium 插件模式框架无关绑定 Meteor 生态支持 React、Vue、Angular、Svelte、纯 JS许可证MITApache 2.0FAQ我可以在 MongoDB 后端上使用 RxDB 吗可以。RxDB 的复制协议能与任意 HTTP 服务器通信包括由 MongoDB 支撑的 Node.js API。你只需实现 pull 和 push 处理器查询 MongoDB API 端点并返回 RxDB 期望的文档格式。在前端使用 RxDB 无需替换后端。RxDB 支持与 Minimongo 相同的查询语法吗RxDB 使用 MongoDB 兼容的查询语法 编写 selector因此你为 Minimongo 写的许多查询只需少量修改甚至无需修改即可在 RxDB 上运行。RxDB 查询中的selector字段使用与 Minimongo 相同的运算符$eq、$gt、$in、$or、$and等。RxDB 不支持完整的 MongoDB 聚合管道但覆盖了客户端过滤、排序和分页所需的查询模式。RxDB 可以在没有后端服务器的情况下工作吗可以。RxDB 完全可以作为纯本地数据库使用不需要任何服务器。你可以创建数据库、写入文档、运行查询、订阅响应式变更全程无需网络连接。复制是可选的你可以先用纯本地模式起步等应用需求增长后再添加复制层。用户长时间离线时RxDB 如何处理数据设备恢复在线后RxDB 会运行一个复制周期拉取自上次成功 checkpoint 以来服务器上变化的所有文档推送离线期间累积的全部本地写入。如果同一文档在两侧都被修改RxDB 会调用你的冲突处理器决定最终状态。无论离线五分钟还是数周这一过程都能正确工作。RxDB 适合 React Native 吗适合。RxDB 通过 SQLite 存储插件 运行在 React Native 上。为 Web 应用编写的同一套 schema 定义、查询代码和复制配置可以复用到 React Native 应用。RxDB 还通过专用存储插件支持 Expo。赞分享数据库NoSQL嵌入式数据库实时数据库【免费下载链接】rxdbThe local-first database that runs on every JS runtime and replicates with your existing backend - no vendor, no lock-in - https://rxdb.info/项目地址https://gitcode.com/gh_mirrors/rx/rxdb点击查看免费下载相关推荐RxDB 作为 RethinkDB 替代方案离线优先的客户端响应式数据库实战指南RxDB 作为 RethinkDB 替代方案离线优先的客户端响应式数据库实战指南 RethinkDB 曾以 changefeed变更推送机制引领了实时数据数据库NoSQL嵌入式数据库实时数据库RxDB 作为 Horizon 的替代方案离线优先、客户端响应式数据库实战指南RxDB 作为 Horizon 的替代方案离线优先、客户端响应式数据库实战指南 Horizon 曾是 RethinkDB 官方的客户端实时数据库方案但因公司数据库NoSQL嵌入式数据库实时数据库RxDB 作为 CouchDB 替代方案客户端本地优先、离线优先与响应式查询实战指南RxDB 作为 CouchDB 替代方案客户端本地优先、离线优先与响应式查询实战指南 CouchDB 是广为人知的服务端文档数据库以多主复制协议和 HTTP数据库NoSQL嵌入式数据库实时数据库创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考