RxDB Tradeoffs 深度解析：为什么客户端离线优先数据库在查询、事务与建模上做出这些取舍

RxDB Tradeoffs 深度解析为什么客户端离线优先数据库在查询、事务与建模上做出这些取舍【免费下载链接】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/rxdbRxDB 是一个运行在 JavaScript 应用内的客户端数据库主打 offline-first离线优先能力。虽然它也能跑在服务端但绝大多数场景是嵌入在 UI 应用中运行因此它针对客户端场景做出了与服务器数据库完全不同的技术取舍。本文以官方 rxdb-tradeoffs.md 为主线深入剖析 RxDB 为什么不用 SQL、为什么选择文档型 NoSQL 模型、为什么没有 ACID 事务与关系型外键、为什么强制要求 schema并结合仓库源码src/、src/types/、测试文件逐项验证这些取舍背后的工程原理。读完本文你将理解客户端数据库设计的核心权衡并能正确运用 Mango 查询、revision 冲突处理、schema 迁移等 RxDB 实战能力。图为 TypeScript 编辑器中对 RxDB 查询的实时报错selector 中使用了 schema 未定义的字段foobar编译器直接拒绝该对象字面量。为什么 RxDB 不用 SQL 语法当被问到希望浏览器端使用什么数据库时最常见的回答是类似 SQLite 的 SQL 数据库。这很合理——SQL 是大多数开发者在学校学过的查询语言且能跨多种数据库方案复用。但对于 RxDB 这类客户端数据库直接使用 SQL 并不是好选择。RxDB 基于文档写入document writes运作并使用基于 JSON 的Mango Query语法进行查询// 一个 Mango Query const query { selector: { age: { $gt: 10 }, lastName: foo }, sort: [{ age: asc }] };从类型定义看src/types/rx-query.d.tsMango 查询由三部分构成MangoQuerySelectorDocType查询选择器支持$and、$or、$nor、$eq、$gt、$regex、$elemMatch、$exists、$in等操作符且字段名通过PathsDocType约束为 schema 中存在的路径MangoQuerySortPart排序方向取值为asc | descMangoQueryRxDocType完整查询对象包含selector、sort、skip、limit等字段。在 src/rx-query-mingo.ts 中RxDB 通过 mingo 库实现 Mango 查询的执行引擎并刻意只注册了文档实际需要的一小部分操作符$sort、$project流水线以及$elemMatch、$eq、$nor、$exists、$regex、$and、$gt、$gte、$in、$lt、$lte、$ne、$nin、$mod、$not、$or、$size、$type并在注释中明确要求新增操作符必须在 test/unit/rx-storage-query-correctness.test.ts 中补充正确性测试——这体现了小而精的取舍避免引入 MongoDB 查询库的全部体积。SQL 是为数据库服务器设计的SQL 的典型用法是向数据库服务器发送一段字符串如SELECT SUM(column_name)...由服务器执行全部计算并只回传结果。这节省了应用端的性能开销也保证应用不会被阻塞。但 RxDB 是运行在应用内部的客户端数据库SUM()在数据库内执行与应用层用Array.reduce()计算结果性能上没有本质差别。查询执行的全部数据都在本地内存/存储中不存在网络往返。因此 SQL 那种把计算推到服务器的收益在客户端场景下并不存在反而引入了解析字符串、构建执行计划等额外成本。TypeScript 支持SQL 是string类型需要额外的 IDE 工具链才能确保书写的数据库代码有效。改用 Mango Query 语法后TypeScript 可以直接校验查询、自动补全代码并明确知晓文档中有哪些字段、没有哪些字段从而把查询的正确性保证从运行时提前到编译期。仓库中的类型定义印证了这一点src/types/rx-query.d.ts 中MangoQuerySelectorDocType的键被约束为PathsDocType——即 schema 中实际存在的字段路径同时$options?: MangoQueryRegexOptions等操作符选项也被强类型化。上图中的报错正是该机制的直接体现查询条件foobar不在 schema 定义的passportId | firstName | lastName | age之列TypeScript 编译即失败而不是等到运行时才暴露问题。可组合的查询Composeable Queries基于 JSON 的 Mango 查询可以很方便地在纯 JavaScript 中组合。例如对任意给定查询追加条件用户必须是 foobar只需直接向 selector 添加条件而无需解析和修改一段复杂的 SQL 字符串query.selector.user foobar;甚至合并多个查询的 selector 也不是问题queryA.selector { $and: [ queryA.selector, queryB.selector ] };这是因为查询是普通对象天然支持结构共享与函数式组合。与之对比SQL 是字符串任何动态拼接都需要解析 AST、改写再序列化既脆弱又难维护。这种可组合性也是 RxDB 查询缓存与 EventReduce 中normalizeMangoQuery的使用。为什么选择文档型NoSQL与大多数 NoSQL 数据库一致RxDB 在文档级别document level操作数据没有表tables、行rows、列columns的概念取而代之的是集合collections、文档documents与字段fields。文档型模型对客户端数据库有四个直接收益JavaScript 天然适合操作对象应用代码中的数据本来就是对象——状态管理、组件 props、API 响应都是嵌套对象。文档模型让数据库中的数据与应用中的数据零转换直接读写即可。缓存友好文档以整份对象为粒度存储写入时只需序列化/反序列化单个文档配合内存缓存RxDB 维护的 doc-cache可极大减少存储引擎的随机读写。整文档存取也比行级拆分的范式映射ORM更贴合本地持久化场景。EventReduce只算增量不重跑全量查询文档型模型 变更事件change event驱动了 RxDB 的核心性能机制EventReduce。在 src/event-reduce.ts 的calculateNewResults()中当存储层产生变更事件后RxDB 不会重新执行整个查询而是复用上一次的结果集previousResults与docsDataMap对每条变更事件调用calculateActionName()计算动作如doNothing、runFullQueryAgain能优化的变更直接在内存中增删改结果集const actionName: ActionName calculateActionName(stateResolveFunctionInput); if (actionName runFullQueryAgain) { return true; // 无法增量优化的变更才退回全量重查 } else if (actionName ! doNothing) { changed true; runAction(actionName, queryParams, eventReduceEvent, previousResults, previousResultsMap); }只有遇到runFullQueryAgain例如涉及$or、$nor等无法增量推导的复杂操作符时才回退到全量重查。这也解释了为什么 RxDB 刻意只启用了一小撮 Mango 操作符src/rx-query-mingo.ts——操作符集合越小EventReduce 可增量化的比例越高。你可以在创建数据库时通过eventReduce: true默认开启见 src/rx-database.ts启用该机制。更易与 TypeScript 协作由于是文档模型TypeScript 能精确知道查询返回的类型RxDocumentHeroDocType就是 schema 推导出的对象类型。而一条 SQL 查询可能返回数字、行集或复杂聚合结构类型无法静态收敛。配合上文的PathsDocType约束文档模型让schema → 类型 → 查询校验形成完整闭环。为什么没有事务TransactionsRxDB 没有关系型数据库那种 ACID 事务而是用revisions修订号机制来保证行为可预测。取舍原因有三离线优先不兼容ACID 事务要求所有参与方在线并达成一致而 offline-first 意味着客户端可以任意离线多标签页不兼容同一浏览器的多个 tab 是相互独立的应用实例无法在它们之间建立事务隔离文档级冲突处理更简单以单个文档为粒度做冲突检测与合并比跨表事务回滚简单得多。官方文档 transactions-conflicts-revisions.md 明确指出对单个文档的单次写操作是 RxDatabase 中唯一原子性的操作。没有事务带来的收益包括客户端读写互不阻塞、可离线写入后上线再复制、后端复制实现简单可与任意既有基础设施对接、以及可以使用 Sharding 等优化。用 revisions 代替事务每个文档都会携带一个类似1-9dcca3b8e1a的 revision 字符串由两部分组成revision height从1开始的数字每次对该文档的写入都会递增database instance token数据库实例令牌。一次写操作不只包含新文档数据还携带前一个文档数据及其 revision。若前一个 revision 与库中当前存储的 revision 匹配写入成功若不匹配则抛出409 CONFLICT错误——类似 Lamport Clock 的偏序逻辑保证了多端并发下依然可预测。冲突的两类来源与处理本地冲突local conflict多个应用部分同一 tab、多 tab、或写入与远程复制并发同时写同一文档导致。RxDB 抛出409 CONFLICT由调用方按业务逻辑处理。更省事的做法是用incrementalModify()、incrementalPatch()、incrementalUpsert()这类增量写操作它们内置了对冲突后的文档状态重新应用变更函数的重试机制参见 rx-document.md 与 rx-collection.md。复制冲突replication conflict多个客户端同时写同一文档再复制到后端时出现。使用 GraphQL 复制 或 复制原语 时RxDB 假定冲突由客户端侧检测并解决后端检测到冲突比较 revision 等后返回真实文档状态客户端对比本地状态后生成合并结果再次推送。默认冲突处理器src/replication-protocol/default-conflict-handler.ts实现了isEqual()深度相等判断用于冲突检测与resolve()默认丢弃 fork 状态、采用 master 状态两个函数你可以在addCollections()时通过conflictHandler覆盖它例如只比较updatedAt时间戳以提升性能或在resolve()中做字段级合并。为什么没有关系RelationsRxDB 刻意不提供关系型外键与 JOIN。原因很直接关系模型与简单的复制replication难以共存。外键约束要求跨文档的引用完整性在每次写入时都被验证而离线客户端各自写入、之后才复制到服务器——这种最终一致的模型无法保证引用完整性约束被即时满足。替代方案是population填充文档间用字段引用彼此查询后在应用层按需填充关联数据详见 population.md。这让引用关系保持尽力而为复制与冲突处理都只聚焦于单个文档复杂度大幅下降。这也是文档型数据库在客户端本地优先local-first场景下的主流建模方式。为什么必须提供 schemaRxSchemaRxDB 强制每个集合都有 JSON Schema遵循 JSON Schema 标准而不是像某些客户端 KV 存储那样完全无结构。原因同样是客户端场景的硬约束客户端数据迁移困难应用会持续迭代旧版本写入的数据必须以确定性的方式迁移到新 schema。没有 schema 就无从知道旧数据的结构迁移也就无从谈起为何选择 JSON SchemaJSON Schema 本身就是 JSON与文档模型同构可被序列化、比较且生态成熟。一个典型 schema 示例完整版见 rx-schema.md{ title: hero schema, version: 0, description: describes a simple hero, primaryKey: name, type: object, properties: { name: { type: string, maxLength: 100 }, color: { type: string }, healthpoints: { type: number, minimum: 0, maximum: 100 }, secret: { type: string }, birthyear: { type: number, final: true, minimum: 1900, maximum: 2050 }, skills: { type: array, maxItems: 5, uniqueItems: true, items: { type: object, properties: { name: { type: string }, damage: { type: number } } } } }, required: [name, color], encrypted: [secret], attachments: { encrypted: true } }其中version是 schema 版本号从0开始primaryKey必须是唯一的、final 的、必需的字符串字段也可以配置为基于多个字段的组合主键keyfieldsseparator。schema 还承担了类型推导的职责RxDocumentDocType、查询校验、索引定义、加密字段声明encrypted都从这份 JSON 派生。版本号与迁移策略migrationStrategies当 schema 的version大于0时创建集合必须提供migrationStrategies——一个按目标版本号映射到迁移函数的对象。迁移函数接收旧文档数据并返回新文档数据返回null则删除该文档详见 migration-schema.mdmyDatabase.addCollections({ messages: { schema: messageSchemaV1, migrationStrategies: { // 1 表示把数据从 version 0 转换到 version 1 1: function(oldDoc){ oldDoc.time new Date(oldDoc.time).getTime(); // string 转 unix 时间戳 return oldDoc; }, // 2 表示把数据从 version 1 转换到 version 2支持异步 2: function(oldDoc){ const coordinates oldDoc.coordinates; return fetch(http://myserver.com/api/countryByCoordinates/coordinates/) .then(response response.json()) .then(country { oldDoc.senderCountry country; // 新增必需字段 return oldDoc; }); } } } });默认情况下迁移在集合创建时自动执行addCollections()返回时迁移已完成对大数据量或耗时迁移可以手动调用migrationNeeded()判断、startMigration(10)分批启动并通过getMigrationState().$观察RUNNING | DONE | ERROR状态以渲染进度条状态对象包含count.total、count.handled、count.percent或用migratePromise(10)直接等待。注意迁移期间禁止对该集合写入写入会抛COL25错误须等待migratePromise()完成。客户端场景下的取舍总览取舍维度服务端数据库的常规做法RxDB 的客户端优先做法核心原因查询语言SQL 字符串JSON Mango Query可组合、可被 TypeScript 编译期校验、无需服务器端计算收益数据模型关系型表/行/列 JOIN文档型集合/文档/字段 population与应用对象零转换、利于缓存与 EventReduce 增量更新写入原子性ACID 事务单文档原子写 revision 版本控制多客户端可离线、多 tab 独立、冲突处理简单数据完整性外键与约束schema 校验 迁移策略客户端数据必须可确定性迁移一致性保证强一致最终一致conflict handler 解决offline-first 复制模型总结RxDB 的一切设计都以在浏览器/客户端内运行、支持离线优先复制为前提JSON Mango 查询换来类型安全与可组合性文档模型换来缓存与 EventReduce 的高效增量更新放弃事务改用 revision 换来可预测的并发与简单复制强制 schema 换来确定性的数据迁移。这些取舍并非能力缺陷而是客户端数据库在分布式、离线场景下被验证过的工程选择。当你使用 RxDB 时遵循其模型文档级设计、增量写、冲突处理器、版本迁移就能在复杂多端场景下获得稳定可预期的行为。相关主题可继续阅读 query-optimizer.md构建期索引优化、rx-query.md查询接口与 rx-schema.mdschema 全参数。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考