能否用Typesense替代Firestore作为唯一主数据存储？其弊端有哪些？

Typesense本质是全文检索引擎，不是通用数据库，把它当主存储用，会踩一堆设计定位带来的坑，具体理由和弊端如下：

1. 数据操作能力跟不上通用业务需求 #

• 不支持复杂事务：如果你的应用需要原子性操作（比如下单同时扣减库存），Typesense做不到，很容易出现数据不一致。
• 更新效率低：Typesense更新文档基本要全量替换，不像Firestore可以只改单个字段，高频小更新场景下成本和性能都拉胯。
• 查询能力受限：除了搜索、过滤这类检索场景，聚合计算、多文档关联查询（比如关联用户和订单的复杂查询），Typesense的支持远不如Firestore灵活。

2. 成本会失控 #

• 计费模式不匹配：Typesense按检索请求、存储、节点收费，要是把它当主存储，频繁的CRUD会让检索请求量暴增——比如一次更新可能要先删旧文档再插新的，算两次操作，还要触发索引更新，成本比Firestore按读写操作计费高很多。
• 存储冗余：Typesense要维护索引结构，存同样的原始数据，实际占用的存储空间比Firestore多，存储成本没优势。

3. 扩展性和可靠性有硬伤 #

• 写性能瓶颈：Typesense的索引构建是CPU密集型操作，高频写入会导致索引更新延迟，检索结果跟不上数据变化。而Firestore的写扩展是针对通用场景优化的，能扛住更大的写负载。
• 备份恢复麻烦：Firestore有自动多区域备份、时间点恢复，Typesense的备份基本靠手动导出，恢复成本高，数据丢了很难找回。
• 生态太窄：Firestore能和实时监听、云函数、身份验证无缝集成，Typesense的生态只围绕检索，做业务逻辑时要自己搭很多额外工具，开发维护成本飙升。

4. 数据一致性没保障 #

Typesense没有内置的冲突解决机制，多个客户端同时改同一份文档，很容易直接覆盖，丢数据。Firestore有乐观锁、离线同步这些机制，能处理这类并发场景。

总结下来 #

搜索引擎的核心价值是高效检索，硬把它当主存储用，就是拿它的短板去碰通用数据库的长处。除非你的应用纯做搜索、几乎没写操作，否则还是保留Firestore做主存储，Typesense当检索层的架构更靠谱。

内容的提问来源于stack exchange，提问作者Paul