LogSeq 为什么要推出数据库版本?「本地优先」的文本笔记该怎么办？

关于 LogSeq

火箭君一直在使用 Logseq 作为自身的日志管理工具。主要用来管理 Daily Log，和项目日志。

长久以来，LogSeq 和 Obsidian一样都是「本地优先」类笔记 App 的代表。 两者都是从最早的 类似 RoamResearch 的「本地存储版本」开始发力， 只不过， Obsidian 走向了一个「全功能」的双链笔记， LogSeq 则继续在树状结构的「节点笔记」上深耕。

LogSeq 的节点形式之上，另一家公司又带来了一个「非本地存储」的云端 App，Tana。 Tana 和 LogSeq 来自于两个截然不同的公司，两种不同的哲学。Tana 更深入地体现了 「节点笔记」的精髓，以节点为记录单位，而且彻底摒弃了「文件」的概念，自然也没有「本地存储」，一切都是云端数据库。Tana 的便利性和性能也因为这些改动而大幅提升，但是数据安全/数据所有权以及隐私保护，也受到了极大的挑战。

言归正传，LogSeq 其实挺适合个人或小团队使用，但不能大规模实时协作，尽管如此「节点笔记」 在「日志记录」领域有天然的优势，LogSeq，正如其名， 让 Log 像 Sequoia 一样尽情生长。这是火箭君最为钦佩的地方。

时至 2024 今日，LogSeq 团队在几周前发布了 关于转向 Database 的公告。 这无疑是一个「重磅炸弹」，LogSeq 社区内 顿时引来许多讨论，例如：是否还支持「本地文件」？是否影响现有笔记，为什么非要用DB不可 …… 关于所有这些问题， 火箭君将官方的回答和公告翻译后分享在下面。 对于喜欢 LogSeq 或「本地优先」笔记的小伙伴们来说，也算是一个重要的参考。

LogSeq 官方论坛原文地址：

https://discuss.logseq.com/t/why-the-database-version-and-how-its-going/26744

以下是官方公告译文的正文，由火箭君翻译并略作编辑和注释。

正文

大家好，我们知道很多人对即将推出的「数据库版本」有疑问，比如我们为什么要开发它，为什么要花这么长时间。

我们很抱歉几乎把所有时间都花在了开发上，却没有与社区进行良好的沟通。这里将尝试回答其中的一些问题。

一些背景

• 大家都喜欢「纯文本」文件，甚至通过 Git 和 Obsidian 等工具，我们可以将它们与 Logseq 结合使用。不过，这也带来一些限制：
  • 例如，在 Markdown 文件之上建立实时协作就极具挑战性：
    • 创建新块需要重写整个 Markdown 文件。
    • 重命名页面会更新所有引用该页面的文件。
  • 与数据库相比，结构数据支持有限，缺乏持久 ID、时间戳等功能。 （火箭君注：对，这个很痛，Obsidian 也出现了唯一ID命名功能，以及相应的插件。应该遇到了同样的问题）
• 虽然「模板」和「属性」可以方便大家网库里面添加 新书或论文等资料，但它们很难维护和协作。
• 我们的愿景是创造一个更好的学习和协作环境。目前的应用程序没有达到我们的目标，其局限性包括：
  • 没有网络支持（除了 https://demo.logseq.com 上的有限支持）。
  • 在多个客户端使用 Logseq 同步时丢失数据。
  • 大型Graph的性能不佳。（火箭君注：Graph，实际上是 LogSeq 对「资料库」的一种叫法，类似于 Obsidian 的 Vault）
  • 不可靠的撤消功能。
  • 没有内置的页面发布支持。
• 我们从各位用户当中得到了如此多的关爱和支持，以至于 Logseq 仍然丢失数据，这让我们无法接受。我们希望做得更好，因此我们开始为未来打下坚实的基础，也就是采用「数据库版本」，我们目标是：
  • 稳定，提高数据稳定性，可靠的撤消/重做
  • 性能良好、打开速度快、键入速度快
  • 任何人都可以使用新的「类」和「属性」创建任何工作流（火箭君注：推测可以 参考 Obsidian 的 属性，以及 Capcities 的 属性 功能）
• 我们还决定同时开发具有 实时协作（RTC）功能的新数据库版本，因为实施具有离线支持功能的 RTC 非常复杂。通过在设计过程中尽早考虑 RTC，我们可以最大限度地降低日后不得不改变实施方案的风险。

面临的挑战

• 存储方面
  • 新版数据库应可在多个平台上访问，包括网络、电子和移动平台。
  • 它应该能够处理大规模数据，毫不费力地支持多达 50,000 页的数据。（火箭君注：页，Page 就是 LogSeq 对一篇笔记的叫法）
  • 您的数据应该是安全的，永远不会被浏览器删除
  • 为方便高级查询，新版数据库应支持 Datalog 查询。
  • 此外，它还应提供灵活性，允许用户、插件甚至其他应用程序创建自定义类和属性。
• 类和属性的直观用户体验
  • 写作应该是一种愉悦的体验
• RTC（实时协作） 应该可以脱机工作
  • 我们依旧致力于「本地优先」，用户可以完全控制自己的数据
• RTC （实时协作）应该支持「端到端」加密
  • 是的，隐私第一

常见问题

• LogSeq 打算放弃对 Markdown 文件的支持吗？
  • 不会放弃，我们将继续支持基于文件和基于数据库的 Graph，长期目标是实现数据库和标记符文件之间的无缝双向同步。这将使您既能利用数据库版本的优势，又能使用其他工具。
• 为什么要花这么长时间？
  • 刚开始时，没有任何现有解决方案能满足我们对持久性数据库的要求，因此我们不得不从头开始构建。
  • 我们最初探索了 CRDT，以实现实时协作和离线支持，但最终发现当前的解决方案无法满足我们的需求。 （火箭君注：CRDT，是近几年以来为了解决本地优先和同步冲突的一种协调技术，还在发展中，会产生额外的开销，但有些笔记产品的确在使用，用于处理离线信息和云端同步问题。）
  • 我们花了大量时间完善类和属性的用户体验。
  • 我们的目标是确保新数据库版本不会影响现有版本的功能。
• 数据库版本是开源的吗？
  • 是的，可以在 GitHub 上找到：[WIP] 数据库版本 by tiensonqin – Pull Request #9858
• 数据库版本是免费的吗？
  • 是的，所有本地功能都将免费使用。我们只对依赖我们服务器的功能收费，如实时协作。

未来计划

• 我们计划在 2 到 3 个月内开始数据库版本的早期内部测试，首先邀请一小部分用户帮助我们改进数据库。随着它变得更加稳定，我们将扩大测试小组，让更多用户参与进来。
• 我们还将邀请部分用户和公司测试我们的实时协作功能。

写在最后

火箭君个人非常喜欢 LogSeq， 对于 官方始终秉持「本地优先」「开源」以及「免费」的思路表示高度赞赏，这是目前同类 App 中的「清流」。但是，不可否认，LogSeq 转型数据库而且还要兼容以往的文件笔记体系，而且还要支持协同，并解决同步冲突问题，这绝非易事，如此之艰难，几乎比推倒重做还要难。

最后，希望 LogSeq 最终可以成功转型，一方面，这是「本地优先」类型App的一次自我革新尝试，另一方面，毕竟我还有很多日志在上面。