为什么新的数据库会议还在不断早开？

为什么新的数据库会议还在不断早开？

当一切都要归结于语言编译器的问题，就是要了解数据库，从根本上说，每个计算机系统都与存储、移动和转换数据有关。操作系统、数据库和编程语言之间的界限有些随意——这是特定问题、可用硬件和历史事故的产物。

但是今天问题和硬件发生了巨大变化，因此我们开始看到人们尝试重新绘制线条。

以下是一些变化：

• 更便宜的内存、更快的存储硬件和更好的 IO api。过去，将数据库视为处理慢速块可寻址持久内存上的数据的事物，而将编程语言视为处理快速字节可寻址易失性存储器上的数据的事物是有意义的。这两种不同的硬件需要非常不同的技术。但在过去十年中，这种区别已经缩小，内存数据库已经跨越到另一边，随着字节可寻址非易失性存储器终于开始商业化，权衡将发生根本性的变化。
• 在存储速度提高的同时，内存延迟和 CPU 速度停滞不前。充分利用当今的硬件需要了解数据局部性、预取、流水线、分支预测等，更不用说利用增加的内核数量了。这需要以一种对大多数程序员来说非常陌生的风格编写代码，并且大多数编程语言都没有提供太多帮助。这就是为什么例如现代分析数据库中的 SQL 查询通常会胜过手写 C++ 程序的原因。
• 分布式系统已经变得更加普遍，这在很大程度上是由于一切都转移到了网络上。在服务器端，我们已经必须处理水平扩展，并且可能在未来处理服务器的分解。在客户端，大多数人现在拥有多个设备，每个设备都在朝着更加异构的硬件发展（例如arm 的 big.little）。我们现在比过去花费更多的时间来描述系统之间的数据移动，并且我们发现期望程序员能够手动推理一致性是一场失败的战斗（参见例如jepsen 打破一切，谷歌在全局一致性的Spanner）。
• 面向用户的应用程序和面向开发的 api 的赌注都增加了——实时更新、协作编辑、跨设备和云服务器同步、不同服务之间的互操作等。特别是分布式 web 应用程序和复杂应用程序的复杂性GUI 使变更管理具有吸引力（例如，反应hooks、领域的活动对象）。
• 服务器端日益增加的运营负担意味着人们对根本性的变化持开放态度，例如“无服务器”计算。
• 大数据分析的价值不断增长及其生态系统的碎片化导致需要能够在许多不同语言之间和跨多台机器（例如通过arrow）轻松共享数据。

以下是人们为应对这些变化而探索的一些方向：

• 将运行时状态和逻辑推送到数据库中，例如 facebook messenger将他们的大部分协调和缓存逻辑移动到 sqlite 中，我们的机器将他们的整个运行时状态存储在自定义内存数据库中，fossil将大部分逻辑写入 SQL 中，unity 鼓励存储实体组件系统中的所有运行时状态。
• 放弃全局控制流，转而支持理解数据流和依赖关系的调度系统，例如流系统如flink或kafka 流，增量系统如react , salsa或nix，并行执行系统如统一作业系统，事件触发系统如aws lambda 函数或空中自动化。
• 将数据密集型代码移动到专用系统中，例如像numpy或gandiva这样的矢量化库，像unity's burst、weld或futhark这样的专用编译器。
• 利用统一数据模型为难题提供通用解决方案，例如automerge提供离线协作，ultorg将数据库转换为 crud 应用程序，我们的机器数据库提供撤消、在线协作和自动生成的编辑器 UI，matrix搭载所有其他功能他们的通用消息同步协议。
• 将整体式数据库服务器拆分为单独的工具，例如将数据库翻过来，将数据库变成一个工具包。

我不知道未来会是什么样子，但一个有益的实验途径是采用数据库世界中开发的工具和技术，并以新的方式和新的问题重新组合它们——重新划定操作系统之间的界限，数据库和编程语言。

但是这些行仍然编码在我们字段的结构中。数据库人员参加数据库会议。编程语言的人去参加编程语言会议。游戏引擎开发人员不会参加其中任何一个会议。

如果我们试图让所有这些人在同一个房间里呢？