查询服务系统：一种新兴的数据系统

如今，人们正在构建的数据库和数据系统的种类比以往任何时候都多。我们有像CockroachDB和经典Postgres这样的 OLTP 系统，像Druid和Clickhouse这样的OLAP 系统，像ElasticSearch和Solr这样的搜索系统，像MongoDB和Cassandra这样的 NoSQL 数据库，像Pinecone和Vespa这样的向量数据库，像Neo4j和Dgraph这样的图数据库，像Delta Lake和Hudi等的数据湖，还有Snowflake和Redshift这样的数据仓库，甚至许多其他正在冒出的新概念（比如：数据湖库！）。我在这篇博文中想要做的是在混乱中施加一点秩序，并提出许多这些表面上看起来不同的系统，但实际上属于具有多个共享属性的数据系统类别：我们称之为查询服务系统。

在抽象层面，查询服务系统服务于高并发、低延迟的查询。为了使这一点更具体，让我们通过以下三个属性来定义它们：

1. 查询服务系统服务于大型数据并行 查询：查询自然是可并行化的，因为它们将相同的操作应用于多个数据项，并且每个查询访问 GB 到 TB 的数据。
2. 查询服务系统专门用于低延迟。它们针对特定的问题域，并且可以在高度优化的自定义数据表示的帮助下，在几毫秒到几秒内在该域中运行大型数据并行查询。
3. 查询服务系统管理批量数据更新。更新是定期的，但可以批量更新，因此高度并发的冲突写入很少成为问题。

一旦你知道要寻找什么，很明显许多不同的系统都具有所有这三个属性！例如，像ElasticSearch或Apache Solr这样的全文搜索系统执行的查询将相同的操作（搜索）应用于每个文档；使用倒排索引等专门的数据结构来存储文档并优化搜索性能；并且主要是以Append（追加）的方式进行数据写入（Append-most）。像Apache Druid这样的实时 OLAP 数据库执行聚合查询，对每条记录应用相同的操作，如求和（sum）或分组(group by)；使用优化的压缩列存格式来运行这些查询 ，速度比非专业系统快几个数量级；并且使用仅追加的方式摄取数据（append-only）。许多其他系统以相似的共享这些设计属性，包括像InfluxDB和OpenTSDB这样的时间序列数据库，像Pinecone和Vespa这样的矢量数据库，甚至一些（但不是全部）图数据库。

我们对查询服务系统的一个有趣观察是，它们都包含大量定制的基础设施，都需要支持大规模运行，在多台机器上分布数据和查询。然而，若我们将这些系统一一比较，我们会发现这种分布式基础设施的实现基本相似。我们考察的每个系统都有一个基本的分布式架构，这个架构是由查询服务工作负载的数据并行性自然产生的：它们都将数据划分为许多分片（每个分片都将数据存储在前面讨论的自定义专门数据结构中），为存储在分片中的数据提供一致和持久的容错更新，为高可用性复制分片，并以数据并行的方式提供在多分片上运行容错分布式查询的能力。为了更清楚地说明这一点，我们把在分片数据上执行的数据并行查询画在下面；查询服务系统负责把每个查询分布在许多分片上，并负责管理存储在分片上的数据，包括：数据的更新以及保持数据的可用性。

查询服务系统的数据分片架构

这种架构的普遍性很有意思，因为它意味着我们可以将不同查询服务系统的分布式部分封装在一个共同的、模块化的抽象中，使可扩展的查询服务系统更容易构建，因为开发人员可以使用这种抽象，而不是为每个新系统编写自定义的分布式代码。我一直在研究通用抽象是否可行的问题，最近我发表了一篇关于一种可能的抽象的论文（在NSDI '22会议上），称为data-parallel actors (DPA)。高级思想是我们可以将分布式查询服务系统表示为有状态参与者的集合其中每个参与者都是一个不透明的对象，它封装了以某种自定义格式（如 Solr 倒排索引）存储的数据的分区或分片。通过为存储在参与者中的数据提供分布式保证（例如，更新的一致性和持久性）并定义一组通用并行运算符，开发人员可以从中构建任何数据并行查询，DPA旨在使从单节点组件构建一个分布式查询服务系统成为可能。为了展示 DPA 的工作原理，我们将几个现有的查询服务系统（包括 Solr 和 Druid）移植到它，并使用它构建了一个基于单节点列存储的简化数据仓库——MonetDB。如果这听起来很有趣并且您想阅读更多内容，那么这篇论文中有更多详细信息！

放大来看，我认为DPA和类似的系统很有前途，但即使我们最终没有用一个共同的抽象来构建所有的查询服务系统，我也希望认识到它们的相似性，鼓励研究人员和工程师从新的角度来看待查询服务系统，并建立针对它们的模块化基础设施。例如，我目前正在与斯坦福大学的其他一些人合作，为查询服务系统开发一种通用的数据放置算法，通过最大限度地提高查询的并行性（将经常被一起查询的分片分散开来），从而改善延迟。我猜想，它也有可能为查询服务系统的自动扩展和增量视图维护提出有趣的新的通用方法。更广泛地说，我希望这对查询服务系统的开发者是有用的，因为他们知道有一大类问题是共享的，他们可以从其他系统（希望将来能从DPA这样的通用框架）获得灵感。

原文：https://petereliaskraft.net/blog/query-serving-systems