Edge浏览器翻译的CedarDB博客文章：如何让研究项目做好生产准备 - l1t1/note GitHub Wiki

原文：https://cedardb.com/blog/research_vs_production/

一年前，我们启动了 CedarDB，作为大学研究项目 Umbra 的衍生产品。这篇文章讨论了如何为生产工作负载准备一个研究项目，以及为工业而构建与为学术界构建有何不同。

克里斯蒂安·温特

在 CedarDB，我们着手将非常成功的 Umbra 研究项目的成果带给更广泛的受众。虽然 Umbra 无疑一直有潜力成为高性能生产级数据库系统的基础，但让研究项目为生产工作负载做好准备并同时建立公司并非易事。

一年前我们成立时，我们还在弄清楚在大学里建立研究系统和建立一个广泛使用的系统之间的区别。从那时起，我们学到了很多东西。

在这篇文章中，我们将探讨我们如何将我们的研究转变为公开可用的社区版本，如何为公开发布做好准备，以及我们在此过程中学到了什么。如果您想直接进入并了解我们已经走了多远，您可以使用下面的链接开始使用我们的社区版，稍后继续阅读。

现在开始从研究思维转变从大学过渡到我们看到的第一个重大变化是我们的工作重点。研究重点通常不在传统的数据库组件之外，试图充分利用新的硬件趋势和部署环境 [1， 2， 3]、数据模型 [4,5]，甚至编程语言 [6] 和 CPU 架构 [7， 8]。

当然，还有大量关于更传统组件的研究，例如查询优化器 [9， 10]、事务处理 [11] 以及更高效的数据库运算符 [12， 13， 14] 和存储后端 [15， 4]，其中一些我们已经在之前的博客文章中探讨过，这些作品的重点往往放在表演上。相比之下，我们的研究只有一小部分是关于人们期望从数据库中获得的其他特性，例如可靠性、容错性和与流行工具的兼容性。

“快速行动，打破常规”的口头禅对许多初创公司来说可能很棒，但在信任用户数据时，这并不是最好的口头禅。因此，我们将重点转向稳定。幸运的是，在慕尼黑工业大学研究小组中，已经非常注重把事情做对，而不是偷工减料。对 Umbra 主分支的贡献需要通过严格的测试套件，确保正确处理所有极端情况和数据类型，并且代码结构良好且有文档记录。这无疑使我们的过渡变得更容易。但这仍然不容易。

这就是为什么我们的很多工作都集中在扩展测试套件上，确保我们发现的每个错误都能在未来立即被发现。

今天在 CedarDB 中单元测试中的代码行以及分拆时在 Umbra 中我们将基于 SQL 的测试增加了一倍多，甚至将内部单元测试增加了 10%，而没有添加太多新功能。除了新的单元测试之外，我们现在还测试了不同的东西。在大学里，如果实验的一部分 Umbra 实例运行了一天以上，它就已经被认为是一个长时间运行的测试。实际上，大多数基准测试设置都侧重于单个基准测试和查询，通常在运行之间重新启动数据库以测试不同的配置和算法。当然，在现实中，数据库系统可以不间断地运行多年。我们已经取得了长足的进步，以至于我们现在在内部使用 CedarDB 数月来跟踪和存储内部指标，而没有发生任何事故。

为解决现实世界问题而构建尽管我们的主要重点是变得稳定可靠，但我们的目标从来都不是成为另一个 SQL 数据库。因此，虽然我们的许多工作都集中在成为一个更成熟的系统上，但我们并没有停止构建新功能来解决当今的问题。对于这项任务，作为一家公司而不是一个研究小组有很大帮助。不幸的是，数据库研究往往与现实世界的问题脱钩。这不一定是研究人员的错。可悲的是，没有多少公司公开谈论他们的数据问题和当前数据堆栈的局限性。这使得研究人员别无选择，只能尝试自己寻找潜在问题，仔细阅读公司出版物和聆听有关当前市场趋势的演示，在先发制人地解决问题之前估计人们可能遇到的问题。

虽然作为研究人员，与公司取得联系以讨论其数据管道中的问题总是很困难，但当您为他们的问题开发可用的解决方案时，这变得非常容易。这使我们能够开发人们真正想要和需要的功能。而且，由于我们非常注意 CedarDB 的内部架构是模块化的且面向未来，因此构建这些功能相当快。因此，在过去的几个月里，我们添加了许多 CDC 工具所需的支持更新插入的经常请求的功能，以及用于更高效的时间序列作的 As-of Joins，而无需太多麻烦。对于As-of Join，我们甚至可以重用之前Umbra对带连接的研究[16]。

兼容 PostgreSQL 意味着什么尽管干净的内部结构对于构建新功能非常有用，但它无法完全保护我们免受其他系统的技术债务的影响。如果你想成为一个 PostgreSQL 兼容的系统，你必须至少遵守它的一些设计选择，即使它们看起来没有任何意义。虽然在研究中，通过手工制作的工具与数据库进行交互是可以的，但对于生产就绪的数据库系统来说，情况就不那么重要了。因此，除了稳定性之外，我们还花费了大量时间来支持尽可能多的开箱即用的 PostgreSQL 工具和功能。我不会在这里详细介绍，但如果您想了解更多信息，请查看我们关于如何兼容 PostgreSQL 的单独帖子。

有时，与 PostgreSQL 兼容会让人感觉像是一场艰苦的战斗。实现一个PostgreSQL函数可能会显示需要另外三个函数。尽管如此，这是值得的。PostgreSQL 是迄今为止最受欢迎的数据库生态系统，尽管它的一些内部结构和功能看起来已经过时或完全错误，但它在很多事情上都是正确的。甚至功能的放大也是双向的，而构建一个新功能有时会发现另外三个功能需要构建，确保一个工具的兼容性也确保了与无数其他工具的兼容性。因此，通常情况下，我们尝试的新工具只会毫无错误地连接到 CedarDB。

思考用户体验研究项目和公司之间的另一个主要区别是，对于后者，绝大多数用户都不是系统的开发人员。对于 Umbra 研究项目，几乎所有主要用户都熟记代码库。虽然我个人总是更喜欢看到 gdb 会话中出现的问题而不是错误消息，但普通用户会以不同的方式看待它。为此，我们极大地改进了打印的日志和错误消息，以及其他检查功能的输出，例如我们新的平面 EXPLAIN 计划布局。距离我们所有的日志和错误消息都得到完全完善还有很长的路要走，因此，如果您遇到令您感到困惑的问题，请确保在我们的问题跟踪器中打开一个问题。

作为研究人员，我们也非常关心运行我们系统的硬件和作系统的确切规格，确保将其完全配置为我们想要的行为。当然，并不是每个人都像我们一样对 SSD作的确切延迟特征充满热情。因此，虽然 Umbra 有很多针对硬件特性的手动调整旋钮，但我们确保为您转动这些旋钮，自动适应主内存和 CPU 特性，并为您的存储选择正确的事务模式。所有这些都对用户透明地发生，无论您拥有哪种硬件规格和作系统版本，或者您是独立运行 CedarDB 还是在 Docker 容器中运行。fsync

自动适应底层硬件只是我们提供无忧部署努力的一部分。并非每个 Linux 内核都有相同的可用功能集，虽然我们始终使 Umbra 仅与最新的 LLVM 和 Ubuntu 版本保持一致，但我们现在遇到了使用比 Umbra 本身更旧的 Linux 内核的用户。而且，与研究领域相比，您无法在要运行它的每台机器上编译数据库系统。因此，我们甚至不能依赖在编译时检测可用功能，例如io_uring和 SSD 写入行为以实现高效的 IO，而是需要在运行时执行此作。当然，所有这些对用户都是透明的，无论您是通过我们的安装脚本使用我们的本地二进制文件，还是我们的 Docker 镜像。

到目前为止，将我们的重点转移到用户体验上并不局限于错误消息和无忧部署。您经常希望将研究系统推向系统和底层硬件的绝对极限，以调查在充分利用资源时可能发生的事情。因此，对于 Umbra，我们欣然接受了被 OOM 杀手杀死的风险，只是为了确保我们能够使用每个字节的可用内存。对于生产就绪的数据库系统，情况就不同了。因此，我们现在不再依赖 OOM 杀手进行内存管理，而是积极跟踪内存消耗，当单个查询超过可用内存时失败，而不是使整个系统崩溃。

保持前进势头虽然我们在过去一年中已经取得了很多成就，但我们并没有放慢脚步。去年的大部分开发都集中在 CedarDB 的幕后功能上，这些方面对我们的用户来说是不直接可见的，但我们也已经在努力开发令人兴奋的用户可见功能，以便在未来几个月及以后推出。

除了进一步扩展 CedarDB 的 PostgreSQL 兼容性和用户体验外，这还包括将存储扩展到 S3 等云对象存储、支持 Parquet 等新文件类型以及改进的监控支持。

我们还在努力支持最具挑战性的工作负载和环境，提供高可用性、从其他数据库系统到 CedarDB 的高效复制，以及针对小型机器上最复杂查询的高效假脱机处理。如果您想了解我们的最新进展，请务必关注我们的时事通讯。