在当今数据驱动的世界中，技术变化非常迅速，数据库也不例外。 当前的数据库市场提供了数百种数据库，它们在数据模型、用途、性能、并发性、可扩展性、安全性和提供的供应商支持数量方面各不相同。

选择数据库是另一类挑战。 为您的企业选择合适的数据库并非易事。 能够对数据库技术做出严格、明智的选择需要详细了解以下内容：

• 了解业务需求
• 技术评估
• 技能集映射

了解您的业务需求

无论您考虑使用哪种类型的数据库，第一个关键步骤是定义您的业务需求。 对于小额采购，此步骤可能涉及与其他员工的快速对话，但对于大型、关键任务软件，可能需要数月的工作时间。

数据库选择过程的关键驱动因素包括对以下问题的回答：

• 业务应用是什么？
• 您希望存储的数据的性质是什么？
• 您期望什么样的数据增长？
• 如果数据库出现故障，会有什么影响？
• 数据访问的频率是多少？
• 您的业务需要哪些 ACID 属性？

让我们考虑一个例子：如果您的应用程序需要灵活地保存动态数据内容，那么您可能不会选择关系数据库，而可能更喜欢文档存储或键值数据库。

对非结构化数据的业务需求有不同种类的数据库，如 S3 对象存储、基于文件的系统等。

技术评估

任何数据库都支持写入数据并再次读回。 一些数据库允许查询任意字段。 有些为快速查找提供索引。 一些支持临时查询，而查询必须为其他人计划。 有这么多不同的数据库系统的原因很简单，任何系统不可能同时获得所有需要的特性。

对于任何数据库选择过程都很重要的常见通用数据库组件包括：

• 存储引擎
• 查询处理器
• 查询语言
• 元数据目录
• 优化引擎
• 分片或分区
• 数据可用性
• 缩放

选择数据库时，技术评估是一个关键部分，任何数据库的性能都取决于它内部构建的内容。

存储引擎：存储引擎是数据库管理系统（DBMS）的核心组件，它在操作系统级别与文件系统交互以存储数据。 所有与底层数据交互的 SQL 查询都通过存储引擎。

查询处理器：这是用户查询和数据库之间的中介。 查询处理器解释用户的查询，并使它们成为可操作的命令，数据库可以理解这些命令以执行适当的功能。

查询语言：与数据库交互需要数据库访问语言，从创建数据库到简单地插入或检索数据。 在许多查询语言中，查询语言的功能可以根据具体任务进一步分类：

• 数据定义语言 (DDL)：它由可用于定义数据库模式或修改数据库对象结构的命令组成。
• 数据操作语言 (DML)：直接处理数据库中数据的命令。 所有 CRUD 操作都在 DML 之下。
• 数据控制语言（DCL）：它处理数据库的权限和其他访问控制。
• 事务控制语言 (TCL)：处理内部数据库事务的命令。

元数据目录：这是数据库中所有对象的集中目录。 创建对象时，数据库使用元数据目录保存该对象的记录以及有关它的一些元数据。

分片：分片是一种跨多个数据库分布单个数据集的方法，然后可以将其存储在多台机器上。 这允许将较大的数据集拆分成较小的块并存储在多个数据节点中，从而增加系统的总存储容量。 分片可以是：

• 基于键的分片/哈希分片
• 基于范围的分片
• 基于字典的分片

分区：分区使用分区键/键将数据划分为某种逻辑形式。 数据库分区通常是出于可管理性、性能或可用性原因而完成的。

数据可用性：数据库高可用性是应用程序高可用性的一个重要组成部分，但这并不是全部。 某些情况（例如，区域性灾难或系统性损坏）需要适当的备份和恢复机制。 同样，并非所有数据库都提供相同级别的功能。

缩放：可扩展性描述了系统的弹性。 它指的是系统的增长能力。 您可以相应地缩小、放大和缩小。 良好的可扩展性可以保护您免受未来停机的影响，并确保您的服务质量。 水平扩展是指通过向资源池添加更多机器进行扩展（也称为“向外扩展”），而垂直扩展是指通过向现有机器添加更多功能（例如 CPU、RAM）进行扩展（也称为“扩展” 向上”）。

在垂直扩展中，数据存在于单个节点上，扩展是通过多核完成的，例如，在机器的 CPU 和 RAM 资源之间分配负载。

技能集映射

在没有适当指导的情况下处理未知技术通常会增加更多的不确定性。 如果您在没有适当的技术支持的情况下处理复杂的数据库，那将是一场噩梦。 一般来说，人们更喜欢稳定、流行的数据库，主要原因是在市场上有适当的支持和资源。

数据库评估最重要的部分是评估可用的技能集，并在选择正确的数据库之前找出组织中缺失的技能。 以下是非技术评估的一些重要标准：

• 技术普及
• 它支持的功能
• 产品成本
• 知识库或技术支持
• 可用资源和帮助
• 工程师的可用性及其成本

数据库即服务

DBaaS（数据库即服务）是一种云计算托管服务提供模型，使用户能够通过某种形式的数据库访问来设置、操作、管理和扩展，而无需在物理硬件上进行设置、安装软件、 或配置它以提高性能。

云服务提供商提供三类数据库服务：

• 关系数据库管理系统
• 无SQL
• DW

流行的 DBMS 产品包括：

数据库即服务的好处

 

• 敏捷性：云 DBaaS 应用程序本质上是敏捷的，因此它们可以根据业务或技术进步无缝适应任何升级。 DBaaS 允许快速配置数据库资源，以在尽可能短的时间内提供新的计算资源和存储设施。
• 保护您的数据：安全性是 DBaaS 领域中最关键的挑战之一。 随着越来越多的企业将数据托管在云端，DBaaS 提供商必须防止对数据资源的未授权访问，禁止滥用存储在第三方平台上的数据，并确保数据的机密性、完整性和可用性。
• 根据业务需求扩展：DBaaS 模型提供自动化和动态扩展。 DBaaS 提供商适应工作负载变化，并可以通过在高峰时段增加资源而不中断任何服务来管理负载变化，或者通过在非高峰使用期间分配更少的资源来帮助降低成本。 用户可以快速增加存储和计算能力以满足高处理需求，同时还可以为系统在需求波动期间的行为方式定义使用阈值策略。
• 高可用性：在当今快节奏的数字世界中，保持 24/7 的正常运行时间是任何现代企业的必备条件。 中断与收入损失成正比。 随着数字化转型变得越来越重要，您的应用程序服务应保持 24/7 不停机而变得越来越重要。
• 提高运营效率：由于 DBaaS 是一项服务，您可以一次从一个节点开始，然后在不中断业务的情况下扩大规模。 组织可以随着发展而扩展，这更具成本效益； 通过一次添加一个或多个节点，然后关闭不再需要的资源，IT 团队可以防止代价高昂的超支。

概括

在为业务需求选择合适的数据库时，有多个评估过程——从业务需求到运营管理，从技能集映射到技术审查。 拥有正确的工具和技术可以提高运营效率并减少干扰。 从数以千计的可用选项中选择最佳选项之一并不容易，需要技术娴熟的人员和学科专家。

目录

• 什么是ClickHouse？
• ClickHouse与PostgreSQL
• ClickHouse与TimescaleDB
• 结论

在过去的一年里，我们不断听到的一个数据库是ClickHouse，这是一个由Yandex最初构建并开源的面向列的OLAP数据库。

在这篇经过三个月研究和分析的详细文章中，我们回答了我们听到的最常见的问题，包括：

• 什么是ClickHouse（包括对其架构的深入了解）
• ClickHouse与PostgreSQL相比如何
• ClickHouse与TimescaleDB相比如何
• 与TimescaleDB相比，ClickHouse在时间序列数据方面的表现如何

向Timescale的工程师Alexander Kuzmenkov（最近是ClickHouse的核心开发人员）和Aleksander Alekseev（同时也是PostgreSQL的贡献者）大喊，他们帮助检查了我们的工作并让我们对这篇文章保持诚实。

标杆管理，而不是“标杆营销”（Benchmarking, not “Benchmarketing”）

在Timescale，我们非常认真地对待我们的基准。我们发现，在我们的行业中，有太多供应商偏向的“基准市场营销”，而没有足够诚实的“基准”。我们认为开发人员应该得到更好的服务。因此，我们竭尽全力真正了解我们正在比较的技术，并指出其他技术的闪光点（以及TimescaleDB可能的不足之处）。

您可以在我们的其他详细基准测试与AWS Timestream（29分钟读取）、MongoDB（19分钟读取）和InfluxDB（26分钟读取）中看到这一点。

我们也是真正喜欢学习和挖掘其他系统的数据库呆子。（这就是为什么这些帖子——包括这个帖子——这么长的几个原因！）

因此，为了更好地了解ClickHouse的优缺点，我们在过去的三个月和数百个小时里进行了基准测试、测试、阅读文档以及与贡献者合作。

ClickHouse在我们的测试中表现如何

ClickHouse是一项令人印象深刻的技术。在一些测试中，ClickHouse被证明是一个极快的数据库，能够比我们迄今为止测试过的任何其他数据库（包括TimescaleDB）更快地接收数据。在一些复杂的查询中，特别是那些进行复杂分组聚合的查询，ClickHouse是很难击败的。

但数据库中没有任何内容是免费的。ClickHouse之所以能够实现这些结果，是因为它的开发人员已经做出了具体的架构决策。这些架构决策也带来了局限性，尤其是与PostgreSQL和TimescaleDB相比。

ClickHouse的局限性/弱点包括：

• 在Time-Series Benchmark Suite中的几乎所有查询中，查询性能都低于TimescaleDB，但复杂聚合除外。
• 在小批量大小（例如100-300行/批）下，插入不良和磁盘使用率高出很多（例如，磁盘使用率比TimescaleDB高2.7倍）。
• 类似SQL的非标准查询语言，有几个限制（例如，不鼓励连接，语法有时不标准）
• 健壮的SQL数据库（如PostgreSQL或TimescaleDB）缺少其他功能：没有事务、没有相关子查询、没有存储过程、没有用户定义的函数、除了主索引和辅助索引之外没有索引管理、没有触发器。
• 无法以高速率和低延迟修改或删除数据，而必须批量删除和更新
• 批量删除和更新异步进行
• 因为数据修改是异步的，所以很难确保一致的备份：确保一致备份的唯一方法是停止对数据库的所有写入操作
• 缺少事务和数据一致性也会影响其他特性，如物化视图，因为服务器不能一次自动更新多个表。如果在向包含物化视图的表的多部分插入过程中出现中断，最终结果是数据的状态不一致。

我们列出这些缺点并不是因为我们认为ClickHouse是一个糟糕的数据库。实际上，我们认为它是一个很棒的数据库，更准确地说，是一个适合某些工作负载的很棒的数据库。作为开发人员，您需要为工作负载选择合适的工具。

为什么ClickHouse在某些情况下表现良好，但在其他情况下表现较差？

答案是底层架构。

数据库通常有两种基本架构，每种架构都有优缺点：在线事务处理（OLTP）和在线分析处理（OLAP）。

OLTP	OLAP
Large and small datasets	Large datasets focused on reporting/analysis
Transactional data (the raw, individual records matter)	Pre-aggregated or transformed data to foster better reporting
Many users performing varied queries and updates on data across the system	Fewer users performing deep data analysis with few updates
SQL is the primary language for interaction	Often, but not always, utilizes a particular query language other than SQL

 

ClickHouse、PostgreSQL和TimescaleDB体系结构

从较高的层次上讲，ClickHouse是一个为分析系统设计的优秀OLAP数据库。

相比之下，PostgreSQL是一个通用数据库，旨在成为一个多功能、可靠的OLTP数据库，用于具有高用户参与度的记录系统。

TimescaleDB是用于时间序列的关系数据库：专门构建在PostgreSQL上用于时间序列工作负载。它结合了PostgreSQL的优点和新功能，可以提高性能、降低成本，并为时间序列提供更好的总体开发体验。

因此，如果您发现自己需要对几乎不可变的大型数据集（即OLAP）执行快速分析查询，那么ClickHouse可能是更好的选择。

相反，如果您发现自己需要更通用的软件，那么它可以很好地为具有许多用户的应用程序提供支持，并且可能会频繁更新/删除，即OLTP、PostgreSQL可能是更好的选择。

如果您的应用程序具有时间序列数据，特别是如果您还希望PostgreSQL的多功能性，那么TimescaleDB可能是最佳选择。

时间序列基准套件结果汇总（TimescaleDB与ClickHouse）

我们可以看到这些架构决策对TimescaleDB和ClickHouse处理时间序列工作负载的影响。

在这个基准测试研究期间，我们花了数百个小时与ClickHouse和TimescaleDB合作。我们测试了从1亿行（10亿指标）到10亿行（100亿指标）的插入负载，从1亿到1000万的基数，以及其间的许多组合。我们真的想了解每个数据库是如何跨各种数据集工作的。

总的来说，对于插件，我们发现ClickHouse的表现优于批量较大的插件，但低于批量较小的插件。对于查询，我们发现ClickHouse在基准测试套件中的大多数查询中表现不佳，但复杂聚合除外。

插入性能

当每次插入的行数在5000到15000行之间时，两个数据库的速度都很快，ClickHouse的性能明显更好：

ClickHouse、PostgreSQL和TimescaleDB体系结构

从较高的层次上讲，ClickHouse是一个为分析系统设计的优秀OLAP数据库。

相比之下，PostgreSQL是一个通用数据库，旨在成为一个多功能、可靠的OLTP数据库，用于具有高用户参与度的记录系统。

TimescaleDB是用于时间序列的关系数据库：专门构建在PostgreSQL上用于时间序列工作负载。它结合了PostgreSQL的优点和新功能，可以提高性能、降低成本，并为时间序列提供更好的总体开发体验。

因此，如果您发现自己需要对几乎不可变的大型数据集（即OLAP）执行快速分析查询，那么ClickHouse可能是更好的选择。

相反，如果您发现自己需要更通用的软件，那么它可以很好地为具有许多用户的应用程序提供支持，并且可能会频繁更新/删除，即OLTP、PostgreSQL可能是更好的选择。

如果您的应用程序具有时间序列数据，特别是如果您还希望PostgreSQL的多功能性，那么TimescaleDB可能是最佳选择。

时间序列基准套件结果汇总（TimescaleDB与ClickHouse）

我们可以看到这些架构决策对TimescaleDB和ClickHouse处理时间序列工作负载的影响。

在这个基准测试研究期间，我们花了数百个小时与ClickHouse和TimescaleDB合作。我们测试了从1亿行（10亿指标）到10亿行（100亿指标）的插入负载，从1亿到1000万的基数，以及其间的许多组合。我们真的想了解每个数据库是如何跨各种数据集工作的。

总的来说，对于插件，我们发现ClickHouse的表现优于批量较大的插件，但低于批量较小的插件。对于查询，我们发现ClickHouse在基准测试套件中的大多数查询中表现不佳，但复杂聚合除外。

插入性能

当每次插入的行数在5000到15000行之间时，两个数据库的速度都很快，ClickHouse的性能明显更好：

Performance comparison: ClickHouse outperforms TimescaleDB at all cardinalities when batch sizes are 5,000 rows or greater

然而，当批处理大小较小时，结果会以两种方式反转：插入速度和磁盘消耗。ClickHouse的批量较大，每批5000行，在测试期间消耗了约16GB的磁盘，而TimescaleDB消耗了约19GB的磁盘（均在压缩之前）。

使用较小的批处理大小，TimescaleDB不仅在100-300行/批之间保持了比ClickHouse更快的稳定插入速度，而且ClickHouse的磁盘使用量也高2.7倍。由于每个数据库的体系结构设计选择，应该可以预料到这种差异，但它仍然很有趣。

Performance comparison: Timescale outperforms ClickHouse with smaller batch sizes and uses 2.7x less disk space

查询性能

为了测试查询性能，我们使用了一个“标准”数据集，该数据集在三天内查询4000台主机的数据，总共有1亿行。在我们过去运行基准测试的经验中，我们发现这种基数和行计数可以作为基准测试的代表性数据集，因为它允许我们在几个小时内跨每个数据库运行许多摄取和查询周期。

基于ClickHouse作为快速OLAP数据库的声誉，我们预计ClickHouse在基准测试中的几乎所有查询中都会优于TimescaleDB。

当我们在没有压缩的情况下运行TimescaleDB时，ClickHouse确实表现得更好。

然而，当我们启用TimescaleDB压缩（这是推荐的方法）时，我们发现了相反的情况，TimescaleDB几乎在所有方面都表现出色：

Results of query benchmarking between TimescaleDB and ClickHouse. TimescaleDB outperforms in almost every query category

（对于那些想复制我们的研究结果或更好地理解ClickHouse和TimescaleDB在不同情况下的表现方式的人，请阅读整篇文章以了解详细信息。）

汽车与推土机

今天，我们生活在数据库的黄金时代：有太多的数据库，所有这些行（OLTP/OLAP/时间序列等）都变得模糊了。然而，每个数据库的架构都不同，因此有不同的优缺点。作为开发人员，您应该为工作选择合适的工具。

在花了大量时间与ClickHouse打交道，阅读他们的文档，并通过几周的基准测试，我们发现自己在重复这个简单的类比：

ClickHouse就像一台推土机，对于特定用例来说非常高效和高效。PostgreSQL（和TimescaleDB）就像一辆汽车：通用、可靠，在你生活中面临的大多数情况下都很有用。

大多数时候，“汽车”会满足你的需求。但如果你发现自己在做大量的“建筑”工作，无论如何，找一台“推土机”

我们不是唯一有这种感觉的人。以下是stingraycharles在HackerNews上分享的类似观点（我们不知道他是谁，但如果你正在阅读本文，那么stingraycharles——我们喜欢你的用户名）：

“TimescaleDB有一个很好的时间序列故事，一个普通的数据仓库故事；Clickhouse有一个很棒的数据仓库案例，一个一般的时间序列案例，还有一个小小的集群故事（YMMV）。”

在本文的其余部分中，我们深入探讨了ClickHouse体系结构，然后重点介绍了ClickHouse、PostgreSQL和TimescaleDB的一些优缺点，这些都是由其每个开发人员（包括我们）所做的体系结构决策所导致的。最后，我们进行了更详细的时间序列基准分析。我们还详细描述了我们的测试环境，以便自己复制这些测试并验证我们的结果。

是的，我们是TimescaleDB的制造商，所以您可能不信任我们的分析。如果是这样，我们请您在接下来的几分钟内保持怀疑态度，并阅读本文的其余部分。正如你（希望如此）将看到的，我们花了很多时间来理解ClickHouse的对比：首先，确保我们以正确的方式进行基准测试，以便我们对ClickHouse公平；而且，因为我们本质上是数据库书呆子，并且非常想了解ClickHouse是如何构建的。

后续步骤

你对TimescaleDB感兴趣吗？最简单的入门方法是创建一个免费的TimescaleCloud帐户，这样您就可以访问一个完全托管的Timescale DB实例（30天内100%免费）。

如果您想自己托管TimescaleDB，您可以完全免费—访问我们的GitHub了解更多选项、获取安装说明等(⭐️ 非常感谢！🙏)

最后一件事：你可以加入我们的社区休闲活动，提问、获取建议，并与其他开发人员联系（我们正在7000人以上！）。我们，这篇文章的作者，在所有的渠道上都非常活跃——我们所有的工程师、团队时间尺度成员和许多热情的用户也是如此。

什么是ClickHouse？

ClickHouse是“Clickstream Data Warehouse”的缩写，是一个专栏式OLAP数据库，最初是为Yandex Metrica的web分析而构建的。通常，ClickHouse以其高插入率、快速分析查询和类似SQL的方言而闻名。

Timeline of ClickHouse development (Full history here.)

我们是ClickHouse的粉丝。它是一个围绕某些体系结构决策构建的非常好的数据库，这使得它成为OLAP风格分析查询的一个很好的选择。特别是，在我们使用时间序列基准测试套件（TSBS）进行基准测试时，ClickHouse在数据接收方面的表现比我们迄今为止测试过的任何时间序列数据库（包括TimescaleDB）都要好，在一个实例上，当行被适当批处理时，平均每秒超过600k行。

但是数据库中没有任何内容是免费的，正如我们将在下面展示的那样，这种体系结构也对ClickHouse造成了很大的限制，使得许多类型的时间序列查询和一些插入工作负载的速度变慢。如果您的应用程序不符合ClickHouse（或TimescaleDB）的体系结构边界，那么您可能最终会遇到一个令人沮丧的开发体验，需要重新进行大量工作。

ClickHouse架构

ClickHouse是为具有特定特征的OLAP工作负载而设计的。从ClickHouse文档中可以看出，这类工作负载的一些要求：

• 绝大多数请求都是读访问。
• 数据以相当大的批量（>1000行）插入，而不是以单行插入；或者根本没有更新。
• 数据已添加到数据库，但未修改。
• 对于读取，数据库中处理了相当多的行，但只处理了列的一小部分。
• 表是“宽”的，这意味着它们包含大量列。
• 查询相对较少（通常每台服务器上有数百个查询，或者每秒更少）。
• 对于简单查询，允许大约50毫秒的延迟。
• 列值相当小：数字和短字符串（例如，每个URL 60字节）。
• 处理单个查询时需要高吞吐量（每台服务器每秒最多数十亿行）。
• 交易是不必要的。
• 数据一致性要求低。
• 每个查询有一个大表。所有的桌子都很小，只有一张除外。
• 查询结果明显小于源数据。换句话说，数据被过滤或聚合，因此结果适合于单个服务器的RAM。

ClickHouse是如何为这些工作负载设计的？以下是其体系结构的一些关键方面：

• 压缩的、面向列的存储
• 表引擎
• 索引
• 矢量计算引擎

压缩的、面向列的存储

首先，ClickHouse（与几乎所有OLAP数据库一样）是面向列的（或列的），这意味着同一表列的数据存储在一起。（相比之下，在几乎所有OLTP数据库都使用的面向行的存储中，相同表行的数据存储在一起。）

面向列的存储有几个优点：

• 如果查询只需要读取几列，那么读取数据的速度会快得多（不需要读取整行，只需要读取列）
• 将相同数据类型的列存储在一起会导致更大的可压缩性（尽管如我们所示，可以将列压缩构建为面向行的存储）。

Table engines

为了改进ClickHouse中数据的存储和处理，使用表“引擎”集合实现了列数据存储。表引擎确定表的类型和可用于处理存储在其中的数据的功能。

ClickHouse主要使用MergeTree表引擎作为数据写入和组合的基础。几乎所有其他的表引擎都是从MergeTree派生而来的，并允许在（稍后）处理数据以进行长期存储时自动执行其他功能。

（快速澄清：从这一点开始，每当我们提到MergeTree时，我们都指的是整个MergeTre体系结构设计和从中派生的所有表类型，除非我们指定了特定的MergeTree-type）

在较高的级别上，MergeTree允许将数据快速写入和存储到多个不可变文件（ClickHouse称为“部分”）。这些文件稍后会在将来的某个时候在后台进行处理，并合并为一个较大的部分，目的是减少磁盘上的部分总数（文件越少，以后读取数据的效率越高）。这是ClickHouse在大批量上惊人的高插入性能的关键原因之一。

表中的所有列存储在单独的部分（文件）中，每个列中的所有值都按主键的顺序存储。这种列分离和排序实现使未来的数据检索更加高效，特别是在计算大范围连续数据的聚合时。

索引

一旦数据被存储并合并到每个列的最有效部分集中，查询就需要知道如何高效地查找数据。为此，Clickhouse依赖于两种类型的索引：主索引和辅助索引（数据跳过）。

与知道如何定位表中任何行的传统OLTP BTree索引不同，ClickHouse主索引本质上是稀疏的，这意味着它没有指向主索引每个值位置的指针。相反，因为所有数据都是按主键顺序存储的，所以主索引每N行存储主键的值（默认情况下称为index_granuclear，8192）。这是为了实现特定的设计目标，即将主索引拟合到内存中，以实现极快的处理速度。

当您的查询模式适合这种索引样式时，稀疏特性可以帮助显著提高查询速度。一个限制是，您不能在特定列上创建其他索引来帮助改进不同的查询模式。我们稍后将对此进行更多讨论。

矢量计算引擎

ClickHouse的设计初衷是希望以其他OLAP数据库无法实现的方式进行“在线”查询处理。即使使用压缩和列式数据存储，大多数其他OLAP数据库仍然依赖增量处理来预计算聚合数据。通常是预先聚合的数据提供了速度和报告功能。

为了克服这些限制，ClickHouse实现了一系列矢量算法，用于逐列处理大型数据数组。通过矢量化计算，ClickHouse可以专门处理成千上万块或行（每列）中的数据进行多次计算。矢量化计算还提供了一个机会，可以编写更高效的代码，利用现代SIMD处理器，并使代码和数据更紧密地结合在一起，以获得更好的内存访问模式。

总的来说，这对于处理大型数据集和在有限的列集上编写复杂查询来说是一个很好的功能，随着我们探索更多利用列数据的机会，TimescaleDB可以从中受益。

也就是说，正如您将从基准测试结果中看到的，在TimescaleDB中启用压缩（将数据转换为压缩的列存储），可以以比ClickHouse更好的方式提高许多聚合查询的查询性能。

ClickHouse的缺点在于其架构（又名：没有免费的东西）

数据库架构中没有免费的内容。显然，ClickHouse的设计考虑了非常具体的工作量。同样，它也不是为其他类型的工作负载而设计的。

我们可以从ClickHouse文档中看到一组最初的缺点：

• 没有正式的交易。
• 无法以高速率和低延迟修改或删除已插入的数据。可以使用批删除和更新来清理或修改数据，例如，为了符合GDPR，但不适用于常规工作负载。
• 稀疏索引使得ClickHouse对于通过键检索单行的点查询来说没有那么有效。

有几个缺点值得详细说明：

• 不能在表中直接修改数据
• 有些“同步”操作实际上并不同步
• 类似SQL，但不完全是SQL
• 备份中没有数据一致性

MergeTree限制：不能在表中直接修改数据

ClickHouse中的所有表都是不可变的。无法直接更新或删除已存储的值。相反，UPDATE或DELETE数据的任何操作只能通过“ALTER TABLE”语句来完成，该语句应用过滤器，并在后台重新写入整个表（逐部分）以更新或删除相关数据。本质上，它只是应用了一些过滤器的另一个合并操作。

因此，存在多个MergeTree表引擎来解决此缺陷，以解决通常需要频繁修改数据的情况。然而，这可能导致意外行为和非标准查询。

例如，如果只需要存储最近读取的值，则创建CollapsingMergeTree表类型是最佳选择。使用此表类型，将向表中添加一个附加列（称为“Sign”），该列指示当所有其他字段值都匹配时，哪一行是项目的当前状态。然后，ClickHouse将异步删除带有“Sign”的行，这些行相互抵消（值为1对-1），并在数据库中保留最新状态。

例如，考虑一种常见的数据库设计模式，其中传感器的最新值与长期时间序列表一起存储，以便快速查找。我们将此表称为SensorLastReading。在ClickHouse中，每当数据库中存储新信息时，该表都需要以下模式来存储最新的值。

传感器上次读取

SensorID	Temp	Cpu	Sign
1	55	78	1

当接收到新数据时，您需要向表中再添加两行，一行用于对旧值求反，另一行用于替换旧值。

SensorID	Temp	Cpu	Sign
1	55	78	1
1	55	78	-1
1	40	35	1

在插入之后的某个时候，ClickHouse将合并更改，删除在Sign上相互取消的两行，只留下这一行：

SensorID	Temp	Cpu	Sign
1	40	35	1

但请记住，MergeTree操作是异步的，因此在执行类似折叠操作之前，可以对数据进行查询。因此，从CollapsingMergeTree表中获取数据的查询需要额外的工作，如将行乘以其“Sign”，以确保在表处于仍然包含重复数据的状态时获得正确的值。

这里是ClickHouse文档提供的一个解决方案，针对我们的示例数据进行了修改。注意，对于数字，可以通过将所有值乘以Sign列并添加HAVING子句来获得“正确”答案。

SELECT SensorID, sum(Temp * Sign) AS Temp, sum(Cpu * Sign) AS Cpu FROM SensorLastReading GROUP BY SensorId HAVING sum(Sign) > 0

同样，这里的价值在于，MergeTree表以事务和简单概念（如UPDATE和DELETE）为代价提供了真正快速的数据摄取，就像传统应用程序尝试使用这样的表一样。有了ClickHouse，管理这种数据工作流只需要更多的工作。

因为ClickHouse不是一个ACID数据库，所以这些后台修改（或者任何数据操作）都无法保证能够完成。因为没有事务隔离，任何在更新或删除修改（或我们前面提到的折叠修改）过程中接触数据的SELECT查询都将获得每个部分中当前的任何数据。例如，如果删除过程只修改了列的50%的部分，查询将从尚未处理的其余部分返回过期数据。

更重要的是，这适用于存储在ClickHouse中的所有数据，不仅是存储类似时间序列数据的大型分析型表，还包括相关元数据。例如，虽然可以理解时间序列数据通常只插入（很少更新），但随着时间的推移，以业务为中心的元数据表几乎总是有修改和更新。无论如何，您可以存储在ClickHouse中以进行复杂连接和深入分析的相关业务数据仍在MergeTree表（或MergeTree's的变体）中，因此，无论何时进行修改，更新或删除都需要进行完全重写（通过使用“ALTER table`）。

分布式MergeTree表

分布式表是异步修改可能导致您更改查询数据方式的另一个示例。如果应用程序将数据直接写入分布式表（而不是高级用户可能写入的不同群集节点），则首先将数据写入“启动器”节点，后者又会尽快将数据复制到后台的碎片。因为没有事务来验证数据是否作为两阶段提交（在PostgreSQL中可用）的一部分被移动，所以您的数据可能并不是您认为的那样。

如何处理分布式数据至少还有一个问题。由于ClickHouse不支持事务，并且数据处于不断移动的状态，因此无法保证集群节点状态的一致性。将100000行数据保存到分布式表并不能保证所有节点的备份都是一致的（我们稍后将讨论可靠性）。其中一些数据可能已被移动，而一些数据可能仍在传输中。

同样，这是精心设计的，所以ClickHouse中发生的事情没有什么特别的错误！当将ClickHouse与PostgreSQL和TimescaleDB之类的东西进行比较时，需要注意这一点。

有些“同步”操作实际上并不同步

ClickHouse中的大多数操作都不是同步的。但我们发现，即使一些标记为“synchronous”的也不是真正同步的。

在基准测试期间，一个特别的例子让我们感到惊讶，那就是“TRUNCATE”的工作原理。我们针对ClickHouse和TimescaleDB运行了许多测试周期，以确定行批量大小、工作线程甚至基数的变化如何影响每个数据库的性能。在每个周期结束时，我们将“TRUNCATE”每个服务器中的数据库，希望磁盘空间能够快速释放，以便开始下一个测试。在PostgreSQL（和其他OLTP数据库）中，这是一个原子操作。一旦截断完成，磁盘上的空间就会释放出来。

TRUNCATE是TimescaleDB/PostgreSQL中的一个原子操作，几乎可以立即释放磁盘

我们对ClickHouse也有同样的期望，因为文档中提到这是一个同步操作（而且ClickHouse中的大多数操作都不是同步的）。然而，事实证明，这些文件只会被标记为删除，而磁盘空间会在稍后的、未指定的时间在后台释放出来。这种情况何时发生没有具体的保证。

TRUNCATE is an asynchronous action in ClickHouse, freeing disk at some future time

对于我们的测试来说，这是一个小小的不便。我们必须在测试周期中加入10分钟的睡眠时间，以确保ClickHouse完全释放了磁盘空间。在实际情况中，像使用临时表的ETL处理一样，“TRUNCATE”实际上不会立即释放临时表数据，这可能会导致您修改当前进程。

我们指出其中的一些场景，只是为了强调一点，即ClickHouse并不是现代应用程序中记录系统（OLTP数据库）常用的许多功能的直接替代品。异步数据修改可能需要花费更多的精力才能有效地处理数据。

类似SQL，但不完全是SQL

在许多方面，ClickHouse选择SQL作为首选语言，走在了时代的前列。

ClickHouse在开发初期选择了使用SQL作为管理和查询数据的主要语言。考虑到对数据分析的关注，这是一个明智而明显的选择，因为SQL已经被广泛采用并被理解用于查询数据。

在ClickHouse中，SQL并不是为了满足部分用户社区的需要而添加的。也就是说，ClickHouse提供的是一种类似SQL的语言，不符合任何实际标准。

类SQL查询语言的挑战很多。例如，重新培训将访问数据库的用户（或编写访问数据库的应用程序）。另一个挑战是缺乏生态系统：使用SQL的连接器和工具不仅可以开箱即用，也就是说，它们需要一些修改（以及用户的知识）才能工作。

总的来说，ClickHouse能够很好地处理基本的SQL查询。

然而，由于数据的存储和处理方式与大多数SQL数据库不同，因此您可能希望从SQL数据库（例如，PostgreSQL、TimescaleDB）中使用许多命令和函数，但ClickHouse不支持这些命令和函数或对它们的支持有限：

• 未针对JOIN进行优化
• 除了主索引和辅助索引之外，没有索引管理
• 无递归CTE
• 无相关子查询或LATERAL联接
• 没有存储过程
• 没有用户定义的函数
• 没有触发器

ClickHouse最突出的一个例子是，join本质上是不受欢迎的，因为查询引擎缺乏优化两个或多个表的连接的能力。相反，我们鼓励用户使用单独的子选择语句查询表数据，然后使用类似“ANY INNER JOIN”的语句，严格查找连接两侧的唯一对（避免标准JOIN类型可能出现的笛卡尔积）。JOIN产品也没有缓存支持，因此如果一个表被多次联接，那么对该表的查询将被多次执行，从而进一步减慢查询速度。

例如，TSBS中的所有“double groupby”查询都按多个列分组，然后连接到标记表以获取最终输出的“hostname”。下面是如何为每个数据库编写查询。

Timescale数据库：

WITH cpu_avg AS ( SELECT time_bucket('1 hour', time) as hour, hostname, AVG(cpu_user) AS mean_cpu_user FROM cpu WHERE time >= '2021-01-01T12:30:00Z' AND time < '2021-01-02T12:30:00Z' GROUP BY 1, 2 ) SELECT hour, hostname, mean_cpu_user FROM cpu_avg JOIN tags ON cpu_avg.tags_id = tags.id ORDER BY hour, hostname;

ClickHouse:

SELECT hour, id, mean_cpu_user FROM ( SELECT toStartOfHour(created_at) AS hour, tags_id AS id, AVG(cpu_user) as mean_cpu_user FROM cpu WHERE (created_at >= '2021-01-01T12:30:00Z') AND (created_at < '2021-01-02T12:30:00Z') GROUP BY hour, id ) AS cpu_avg ANY INNER JOIN tags USING (id) ORDER BY hour ASC, id;

可靠性：备份中没有数据一致性

作为ClickHouse体系结构的一部分，需要考虑的最后一个方面是备份中没有数据一致性，而且它缺乏对事务的支持。如前所述，所有数据修改（甚至跨集群的切分）都是异步的，因此，确保一致备份的唯一方法是停止对数据库的所有写入，然后进行备份。数据恢复也面临同样的限制。

事务和数据一致性的缺乏也会影响其他特性，如物化视图，因为服务器不能一次原子地更新多个表。如果在向包含物化视图的表的多部分插入过程中出现中断，最终结果是数据的状态不一致。

ClickHouse意识到了这些缺点，并且肯定正在为将来的版本进行更新或计划更新。某种形式的事务支持已经讨论了一段时间，备份正在进行中，并被合并到代码的主要分支中，尽管还不建议在生产中使用。但即便如此，它也只为交易提供有限的支持。

ClickHouse与PostgreSQL

（正确的ClickHouse与PostgreSQL比较可能需要另外8000个单词。为了避免让这篇文章更长，我们选择了对两个数据库进行简短的比较，但如果有人想提供更详细的比较，我们很乐意阅读。）

如上所述，ClickHouse是一个架构良好的OLAP工作负载数据库。相反，PostgreSQL是一个架构良好的OLTP工作负载数据库。

此外，PostgreSQL不仅仅是一个OLTP数据库：它是增长最快、最受欢迎的OLTP数据库（DB Engines，StackOverflow，2021开发者调查）。

因此，我们不会比较ClickHouse和PostgreSQL的性能，因为继续之前的类比，这就像比较推土机和汽车的性能。这是为两个不同的目的而设计的两种不同的东西。

我们已经确定了为什么ClickHouse非常适合分析工作负载。现在让我们了解为什么PostgreSQL在事务性工作负载方面如此受欢迎：多功能性、可扩展性和可靠性。

PostgreSQL的通用性和扩展性

多功能性是PostgreSQL的突出优势之一。这是PostgreSQL最近在更广泛的技术社区复苏的主要原因之一。

PostgreSQL支持多种数据类型，包括数组、JSON等。它支持多种索引类型，不仅支持通用B树，还支持GIST、GIN等。全文搜索？检查基于角色的访问控制？检查当然，还有完整的SQL。

此外，通过使用扩展，PostgreSQL可以保留它擅长的东西，同时添加特定功能以提高开发工作的ROI。

您的应用程序需要地理空间数据吗？添加PostGIS扩展名。有利于时间序列数据工作负载的功能是什么？添加TimescaleDB。您的应用程序能从使用三角图搜索的功能中受益吗？添加pg_trgm。

凭借所有这些功能，PostgreSQL非常灵活，这意味着它基本上是经得起未来考验的。随着应用程序的变化或工作负载的变化，您将知道您仍然可以根据需要调整PostgreSQL。

（关于PostgreSQL强大可扩展性的一个具体示例，请阅读我们的工程团队如何使用客户操作员将函数编程构建到PostgreQL中。）

PostgreSQL可靠性

作为开发人员，我们决心面对这样一个事实：程序崩溃、服务器遇到硬件或电源故障、磁盘故障或出现损坏。您可以减轻这种风险（例如，稳健的软件工程实践、不间断电源、磁盘RAID等），但不能完全消除它；这是系统生命中的一个事实。

作为回应，数据库是通过一系列机制构建的，以进一步降低此类风险，包括流式复制到副本、完整快照备份和恢复、流式备份、强健的数据导出工具等。

PostgreSQL在20多年的开发和使用中受益匪浅，这不仅造就了一个可靠的数据库，还造就了一系列经过严格测试的工具：流式复制用于高可用性和只读副本，pg_dump和pg_recovery用于完整数据库快照，pg_basebackup和日志传送/流式传输用于增量备份和任意时间点恢复，pgBackrest或WAL-E用于连续归档到云存储，以及强大的COPY FROM和COPY to工具，用于快速导入/导出各种格式的数据。这使得PostgreSQL能够提供更大的“心灵平和”，因为衣柜中的所有骨架都已经找到（并解决）。

ClickHouse与TimescaleDB

TimescaleDB是建立在PostgreSQL之上的领先的时间序列关系数据库。它提供PostgreSQL所能提供的一切，外加一个完整的时间序列数据库。

因此，PostgreSQL的所有优点也适用于TimescaleDB，包括通用性和可靠性。

但TimescaleDB添加了一些关键功能，使其在时间序列数据方面表现更佳：

• Hypertables是TimescaleDB许多功能（如下所示）的基础，Hypertables提供跨时间和空间的自动分区数据，以实现更高性能的插入和查询
• 连续聚合-智能更新时间序列数据的物化视图。TimescleDB不是每次都重新创建物化视图，而是仅根据原始数据的底层更改更新数据。
• 列压缩—对大多数时间序列数据进行90%以上的高效数据压缩，大大提高了历史查询、长查询和窄查询的查询性能。
• Hyperfunctions-添加到PostgreSQL的以分析为中心的函数，通过近似百分位数、高效下采样和两步聚合等功能增强时间序列查询。
• 功能管道（本周发布！）-通过应用函数编程原理和Python的Pandas和PromQL等流行工具，从根本上改进开发人员在PostgreSQL和SQL中分析数据的人体工程学。
• 水平扩展（多节点）—跨多个节点的存储和分布式查询的时间序列数据的水平扩展。

时间序列数据的ClickHouse与TimescaleDB性能

时间序列数据之所以流行起来，是因为跟踪和分析事物随时间变化的价值在各个行业都变得显而易见：DevOps和IT监控、工业制造、金融交易和风险管理、传感器数据、广告技术、应用事件、智能家居系统、自动驾驶汽车、职业体育等等。

它与更传统的业务类型（OLTP）数据至少在两个主要方面有所不同：它主要是插入量大，数据的规模不断增长。这会影响数据收集和存储，以及我们如何分析价值本身。传统OLTP数据库通常无法每秒处理数百万事务，也无法提供有效的数据存储和维护方法。

时间序列数据也比一般分析（OLAP）数据更独特，因为查询通常具有时间成分，并且查询很少触及数据库中的每一行。

然而，在过去几年中，OLTP和OLAP数据库的功能之间的界限开始模糊。在过去十年中，许多NoSQL架构缓解了存储挑战，但仍然无法有效处理时间序列数据所需的查询和分析。

因此，许多应用程序试图在OLTP数据库的事务功能和OLAP数据库提供的大规模分析之间找到适当的平衡。因此，许多应用程序尝试使用ClickHouse是有道理的，它为时间序列数据提供了快速摄取和分析查询功能。

因此，让我们看看ClickHouse和TimescaleDB如何使用我们的标准TSBS基准比较时间序列工作负载。

性能基准

让我首先说，这不是一个我们在几个小时内完成的测试，然后再继续。事实上，就在昨天，在完成这篇博客帖子时，我们安装了最新版本的ClickHouse（3天前发布），并再次运行了所有测试，以确保获得尽可能好的数据！（基准，而非基准营销）

为了准备最后一组测试，我们分别在TimescaleDB和ClickHouse上运行了几十次基准测试——至少是几十次。我们尝试了不同的基数、生成数据的不同时间长度，以及对TimescaleDB的“chunk_time_interval”等易于控制的内容的不同设置。我们想真正了解每个数据库在典型的云硬件和我们在野外经常看到的规格下的性能。

我们还承认，大多数实际应用程序的工作方式与基准测试不同：首先接收数据，然后查询数据。但是，分离每个操作使我们能够了解在不同阶段哪些设置影响了每个数据库，这也使我们能够调整每个数据库的基准设置，以获得最佳性能。

最后，我们始终将这些基准测试视为一种学术和自我反思的体验。也就是说，花几百个小时处理这两个数据库通常会使我们考虑改进TimescaleDB（特别是）的方法，并仔细考虑何时我们可以而且应该说另一个数据库解决方案是特定工作负载的好选择。

​​机器配置

对于这个基准测试，我们有意识地决定使用基于云的硬件配置，这些配置对于初创企业和成长型企业的中等工作量来说是合理的。在以前的基准测试中，我们使用了具有专用RAID存储的较大机器，这是生产数据库环境的典型设置。

但是，随着时间的推移，我们看到越来越多的开发人员使用Kubernetes和模块化基础架构设置，而没有进行大量专门的存储和内存优化，因此在与我们在野外看到的更接近的实例上对每个数据库进行基准测试更为真实。当然，我们总是可以投入更多的硬件和资源来帮助实现峰值，但这通常无助于传达大多数现实应用程序的期望。

为此，为了比较插入和读取延迟性能，我们在AWS中使用了以下设置：

• 版本：TimescaleDB版本2.4.0，社区版，带PostgreSQL 13；ClickHouse 21.6.5版（测试时这两个数据库的最新非测试版）。
• 1台运行TSBS的远程客户端计算机，1台数据库服务器，两者位于同一云数据中心
• 实例大小：客户端和数据库服务器都运行在Amazon EC2虚拟机（m5.4xlarge）上，每个虚拟机有16个vCPU和64GB内存。
• 操作系统：服务器和客户机都运行Ubuntu 20.04.3
• 磁盘大小：1TB EBS GP2存储
• 部署方法：使用官方源通过apt-get安装

数据库配置

ClickHouse：没有对ClickHouse进行配置修改。我们只是根据他们的文档进行了安装。目前，ClickHouse还没有像timescaledb这样的工具。

TimescaleDB:对于TimescaleDB，我们遵循了时间刻度文档中的建议。具体来说，我们运行了timescaledb-tune并接受了基于EC2实例规范的配置建议。我们还在postgresql.conf中设置synchronous_commit=off。这是一种常见的性能配置，用于写入繁重的工作负载，同时仍保持事务性和日志完整性。

插入性能

为了提高插入性能，我们使用了以下数据集和配置。这些数据集是使用仅含cpu用例的时间序列基准套件创建的。

• 数据集：100-100000000台模拟设备每10秒生成10个CPU指标，读取间隔约为1亿次。
• 每个配置使用的间隔如下：100台设备31天；4000台设备3天；100000台设备需要3小时；30分钟，1000000
• 批量大小：插入是使用5000的批量大小制作的，ClickHouse和TimescaleDB都使用了该批量大小。我们尝试了多种批量大小，发现在大多数情况下，每个数据库每批5000到15000行之间的总体插入效率几乎没有差异。
• TimescaleDB块大小：我们根据数据量设置块时间，目标是每个配置总共7-16个块（这里有更多关于块的信息）。

最后，这些是使用5000行的批处理大小将TSBS客户机预生成的时间序列数据接收到每个数据库的性能数字。

 

Insert performance comparison between ClickHouse and TimescaleDB with 5,000 row/batches

说实话，这并不让我们感到惊讶。我们最近看到了许多关于ClickHouse摄取性能的博客文章，由于ClickHouse使用了不同的存储体系结构和机制，不包括事务支持或ACID遵从性，所以我们通常预计它会更快。

然而，当你考虑到ClickHouse被设计成将接收到的行的每个“事务”都保存为单独的文件（稍后使用MergeTree架构进行合并）时，情况确实有所改变。事实证明，当您要接收的数据批次更少时，ClickHouse会比TimescaleDB慢得多，并且会消耗更多的磁盘空间。

（吸收1亿行，4000台主机，3天的数据-22GB的原始数据）

Insert performance comparison between ClickHouse and TimescaleDB using smaller batch sizes, which significantly impacts ClickHouse's performance and disk usage

你注意到上面的数字了吗？

无论批处理大小如何，TimescaleDB在压缩之前始终使用每个数据摄取基准消耗约19GB的磁盘空间。这是chunk_time_interval的结果，它决定了为给定的时间序列数据范围创建多少块。虽然较小的批处理可能会降低接收速度，但会为相同的数据创建相同的块，从而产生一致的磁盘使用模式。在压缩之前，很容易看到TimescaleDB无论批大小如何，都会持续消耗相同数量的磁盘空间。

相比之下，ClickHouse存储需求与需要写入的文件数量相关（这部分取决于要保存的行批的大小），实际上，在将数据合并到更大的文件之前，将数据保存到ClickHouse需要更多的存储空间。即使在500行的批处理中，对于22GB大小的源数据文件，ClickHouse消耗的磁盘空间也比TimescaleDB多1.75倍。

读取延迟

对于基准读取延迟，我们对每个数据库使用以下设置（机器配置与插入比较中使用的配置相同）：

• 数据集：4000/10000模拟设备每10秒生成10个CPU指标，持续3天（100M+读取间隔，1B+指标）
• 我们还启用了TimescaleDB上的本机压缩。除了最近的数据块外，我们压缩了所有数据，使其保持未压缩状态。通常建议使用这种配置，其中未压缩的原始数据保存在最近的时间段，而较旧的数据被压缩，从而提高查询效率（有关更多信息，请参阅我们的压缩文档）。我们用于启用压缩的参数如下：我们按tags_id列进行分段，并按时间降序和usage_user列进行排序。

在读取（即查询）延迟时，结果更复杂。与插入不同，插入主要取决于基数大小（可能还有批大小），可能的查询范围基本上是无限的，特别是对于像SQL这样强大的语言。通常，对读取延迟进行基准测试的最佳方法是使用计划执行的实际查询进行基准测试。对于这种情况，我们使用一组广泛的查询来模拟最常见的查询模式。

下面显示的结果是每个查询类型的1000个查询的中间值。此图表中的延迟均以毫秒为单位显示，另一列显示TimescaleDB与ClickHouse相比的相对性能（当TimescaleDB更快时以绿色突出显示，当ClickHouse更快时以蓝色突出显示）。

Results of benchmarking query performance of 4,000 hosts with 100 million rows of data

Results of benchmarking query performance of 10,000 hosts with 100 million rows of data

简单滚动

对于简单的汇总（即单个groupby），当在单个主机上聚合一个指标1或12小时，或在一个或多个主机上聚合多个指标（1小时或12小时）时，TimescaleDB通常在低基数和高基数方面都优于ClickHouse。特别是，TimescaleDB在4000和10000台设备的配置上表现出高达1058%的ClickHouse性能，每个读取间隔生成10个独特的指标。

AGGREGATES

在计算1个设备的简单聚合时，TimescaleDB在任何数量的设备上都始终优于ClickHouse。在我们的基准测试中，TimescaleDB在4000台设备上聚合8个指标时，其性能达到了ClickHouse的156%，在10000台设备上集合8个指标后，其性能提高了164%。TimescaleDB在高端场景中再次超越ClickHouse。

DOUBLE ROLLUPS

ClickHouse在查询延迟方面始终优于TimescaleDB的一组查询是按时间和另一个维度（例如，GROUPBY time、deviceId）聚合度量的双汇总查询。下面我们将详细讨论为什么会这样，但这也并非完全出乎意料。

THRESHOLDS

当根据阈值选择行时，TimescaleDB在计算单个设备的阈值时显示出249-357%的ClickHouse性能，但在计算随机时间窗口中所有设备的阈值后，仅显示出130-58%的ClickHouse性能。

COMPLEX QUERIES

对于超出汇总或阈值的复杂查询，比较有点微妙，特别是在查看TimescaleDB时。区别在于TimescaleDB让您可以控制压缩哪些块。在大多数时间序列应用程序中，尤其是像物联网这样的应用程序，经常需要通过某种聚合来查找某个项的最新值或前X个项的列表。这是lastpoint和groupby orderby limit查询的基准。

正如我们之前在其他数据库（InfluxDB和MongoDB）中所展示的，以及ClickHouse本身所记录的那样，获取项目的单个有序值并不是类似MergeTree的/OLAP数据库的用例，通常因为没有可以为时间、键和值定义的有序索引。这意味着询问项目的最新值仍然会导致对OLAP数据库中的数据进行更密集的扫描。

我们在结果中看到了这一点。在搜索数据库中每个项目的最新值（lastpoint）时，TimescaleDB比ClickHouse快3486%左右。这是因为在接收数据时，最新的未压缩块通常会保存这些值的大部分，这是一个很好的例子，说明为什么压缩的灵活性会对应用程序的性能产生重大影响。

然而，我们完全承认，压缩并不总是对每个查询表单都返回良好的结果。在最后一个复杂的查询中，ClickHouse以相当大的速度超过TimescaleDB，几乎快了15倍。我们的结果没有显示，从未压缩块（最近的块）读取的查询比ClickHouse快17倍，平均每个查询64毫秒。TimescaleDB中的查询如下所示：

SELECT time_bucket('60 seconds', time) AS minute, max(usage_user) FROM cpu WHERE time < '2021-01-03 15:17:45.311177 +0000' GROUP BY minute ORDER BY minute DESC LIMIT 5

正如您可能猜测的那样，当块被解压缩时，可以使用PostgreSQL索引按时间快速排序数据。压缩区块时，必须首先解压缩与谓词匹配的数据（上例中为“WHERE time<”2021-01-03 15:17:45.31177+0000”），然后再对其进行排序和搜索。

当“lastpoint”查询的数据落在未压缩的块中时（对于具有诸如“WHERE time<now（）-INTERVAL‘6 hours’”谓词的短期查询，通常是这种情况），结果令人吃惊。

（未压缩区块查询，4k主机）

Query latency performance when lastpoint and groupby-orderby-limit queries use an uncompressed chunk in TimescaleDB

最后一组查询的关键结论之一是，数据库提供的功能可能会对应用程序的性能产生重大影响。有时它只是工作，而其他时候能够微调数据存储方式可能会改变游戏规则。

读取延迟性能摘要

• 对于简单查询，无论是否使用本机压缩，TimescaleDB都优于ClickHouse。
• 对于典型的聚合，即使在许多值和项中，TimescaleDB也优于ClickHouse。
• ClickHouse执行更复杂的双汇总，每次都优于TimescaleDB。在某种程度上，我们对这种差距感到惊讶，并将继续了解如何更好地适应对原始时间序列数据的此类查询。在实际应用程序中，解决这种差异的一个方法是使用连续聚合来预聚合数据。
• 当根据阈值选择行时，TimescaleDB的性能优于ClickHouse，速度快了250%。
• 对于一些复杂的查询，特别是像“lastpoint”这样的标准查询，TimescaleDB的性能大大优于ClickHouse
• 最后，根据查询的时间范围，TimescaleDB在分组和有序查询方面比ClickHouse快得多（高达1760%）。当这些类型的查询进一步回到压缩块时，ClickHouse的性能优于TimescaleDB，因为必须解压缩更多的数据才能找到合适的max（）值来排序。

结论

你成功了！感谢您抽出时间阅读我们的详细报告。

了解ClickHouse，然后将其与PostgreSQL和TimescaleDB进行比较，使我们意识到在当今的数据库市场上有很多选择，但通常仍然只有一个合适的工具来完成这项工作。

在决定使用哪一个应用程序之前，我们建议后退一步，分析您的堆栈、团队的技能以及您现在和将来的需求。现在选择最适合您的情况的技术，可以在未来带来所有不同。相反，您希望选择一种随您发展和成长的体系结构，而不是一种在数据开始从生产应用程序流动时迫使您从头开始的体系结构。

我们总是对反馈感兴趣，我们将继续与更大的社区分享我们的见解。

 

对于开发人员来说，这是一个没有争议的特性。数据库的未来是开源的。2022年对约70000名代码争论者进行的堆栈溢出调查显示，几乎所有的专业人士都使用两种领先的开源RDBMSE之一，PostgreSQL（46.5%）或MySQL（45.7%），尽管他们也使用其他系统。

以RDBMS为起点建立全球软件帝国的甲骨文（Oracle）仅被约12%的开发人员使用，而银行和全球零售商使用的IBM数据主力Db2仅为2%。

毫无疑问，领先优势是开源——构建新系统的人正是他们自己的选择。问题是为什么他们在开发人员中占据主导地位。

数据库咨询公司Percona的首席执行官彼得·扎伊采夫（Peter Zaitsev）是MySQL AB的早期员工，由原始开源数据库作者迈克尔·蒙蒂·维德尼乌斯（Michael“Monty”Widenius）领导。对扎伊采夫来说，这是20世纪初创业场景中的一个经济学问题。

“如果你看看Oracle和Db2，它们可能是非常非常昂贵的系统。在21世纪初，就在互联网时代之后，缺乏资金的新一代创业公司需要但无法负担Oracle、Db2或SQL Server，”他说。

但在使用开源数据库的过程中，新一代创业公司——Facebook、Uber和谷歌等——开始发现他们可以根据自己的需求调整系统，为开源代码做出贡献，同时从社区其他地方的开发中获益。

Zaitsev说：“这是一种无许可的创新，你与社区一起定制和改进软件的能力非常重要。”。

快进十年，这一批初创企业——吸引了数十亿用户，吸引了金融市场和迷人的数字转型大师——开始主导网络原生开发者的思维。

Zaitsev说：“创业开发者文化开始渗透到整个生态系统，因为人们正在关注谷歌、Airbnb或优步可能采取的方式。”。

“这得到了数据库领域的关注。它转向了开源数据库。你可能很难找到一些真正酷的基于Oracle的系统作为后端数据库。在企业和政府机构的肚子里，这可能非常重要，但非常无聊。这一切都很好，但不是开发人员所期望的。”

PostgreSQL和MySQL已经有超过50年的发展历史，但新一代开源数据库已经出现在市场上，并引发了围绕其开源模式的激烈辩论。

MySQL的分支MariaDB和分布式RDBMS CockroachDB采用了他们所称的业务源许可证（BSL）。根据MariaDB的定义，这是“封闭源代码或开放核心许可模型的新替代方案”。源代码始终是公开可用的，代码的非生产性使用始终是免费的，许可方还可以提供额外的使用许可，允许有限的生产性使用。源代码保证在某个时间点成为开放源代码。

同时，流行的基于文档的NoSQL数据库MongoDB提供了服务器端公共许可证（SSPL）v1.0，该版本要求向社区发布MongoDB的增强功能。这些限制意味着公司不能将MongoDB作为托管服务提供给其他用户。

SSPL或BSL都不满足开放源代码倡议（OSI）设定的所有开放源代码软件标准。

扎伊采夫说，这些公司的做法在一定程度上是由于投资者倾向于开源的想法。

认为需要抵御企业狼

“金钱可以创造现实。这对开源来说可能是一种危险。开源运动的一些地区有点浪漫，希望改变世界。现在，商业开源是为了赚钱。是的，人们认为开源是好的：这是我们20多年来学到的东西。所以现在，许多新的兴趣正试图重新定义什么是开源软件，而ch允许他们保护自己，但仍然是开源的。但这与开源截然相反，开源应该像科学一样——放弃它，让每个人都能够构建和使用它。”

Zaitsev认为，通过这种方式，开源软件的用户可以自由终止与供应商的关系，并与其他公司签订合同，开发或支持他们的系统，同时保留原始代码的所有权，避免所谓的供应商锁定。

但是，倡导这些许可证的公司这样做是为了保护自己不受占主导地位的云超级规模商的影响，这些超级规模商在开发人员中拥有惊人的市场影响力和影响力。数据库公司担心，如果他们采用自由和开源软件（FOSS）方法，AWS、Google Cloud和Microsoft Azure等公司会简单地复制他们的代码，并将其商业化为托管服务，例如AWS的完全管理关系数据库服务，在这种模式下提供MySQL和PostgreSQL系统。他们认为，这将使开源软件背后的主要公司缺乏收入。

数据管理分析师Gartner veep Merv Adrian在最近一篇关于开源数据库商业可行性的博客中指出，云服务提供商从其开源数据库即服务（DBaaS）产品中获得的收入可能远远超过独立供应商的收入总和。

MongoDB、Cockroach Labs和MariaDB认为，他们采用的模型允许开源的重要特性在这种商业环境中生存。在本文中，我们为这些公司提供了扩展这些观点的机会，同时也为那些采用更宽松的开源方法的公司提供了一个平台，包括Yugabyte、DataStax和PostgreSQL公司EDB，以捍卫他们的立场。Oracle拒绝了谈论MySQL的机会。

作为一个对比，我们邀请了分析领域的一个相对新手Exasol，就其选择专有模型的原因发表评论。

我们还想讨论为什么开源在现代开发中很重要，为什么它可能不重要。首先，我们求助于EDB，这是一家支持和贡献PostgreSQL的商业公司，同时提供一些专有工具和DBAA。

EDB：社区控制和自由

可以说，Postgres是最古老的主要开源数据库，由加州大学伯克利分校的Michael Stonebraker和Lawrence Rowe于1986年首次提出，作为Ingres的继承者。其创建目标之一是数据类型、运算符和访问方法的可扩展性。根据OSI批准的PostgreSQL许可证，对象关系数据库已被证明是可扩展的，支持图形和JSON等新数据类型。

在2022年堆栈溢出调查中，它是开发者中最受欢迎的数据库，在数据库引擎排名中排名第四，十年来一直稳步攀升。

PosgreSQL咨询公司和贡献者EDB的首席技术官马克·林斯特（Marc Linster）表示，该系统的优势不仅在于许可，还在于吸引开发人员的贡献的多样性。

他区分了“俘虏式开源”项目和“真正的社区开源”项目，前者的绝大多数贡献来自单个公司，后者的贡献来自软件供应商、用户和其他相关方。

“如果你看Linux，或者看PostgreSQL，你会发现它背后有一个充满活力的社区。PostgreSQL是由EDB合作开发的——是的——还有VMware、富士通、NTT、微软、亚马逊等等。有很多公司在这方面投资，”他说。

“从技术上讲，你有其他开源软件拥有开源许可证，但它们实际上被一家公司所控制——比如说MongoDB。如果你是一个社区驱动的过程，会有更多的创新，因为在过程中的这些动态中，有很多推动和拉动来快速实现创新。同时，也有很多质量控制，这两个都来自于desi。”从gn的角度和执行的角度来看，因为审查、集成到代码中，所有这些都是公开的，并且完全公开。

“社区驱动的过程也保护了开源，使其不会突然获得BSL等人工许可或其他许可，因为其背后的社区不会接受。”

虽然核心PostgreSQL项目独立于EDB，但该公司销售自己的专有软件，以帮助保护和管理数据库。

Linster解释说，这些元素没有进入开源项目，因为虽然有些用户可能需要它们，但整个社区没有。

“我们做了一些社区不会做的事情。它不会说它需要数据库中的密码配置文件，比如Oracle。Postgres社区不太可能这样做，但客户通常有非常具体的需求，”他说。

Linster说，客户可以“拥有Postgres中所有的东西”，但也可以获得PostgreSQL社区无法接受的功能，如Oracle兼容性，EDB认为这是“独立的竞争优势”。

DataStax：没有人喜欢陷入陷阱

Apache Cassandra最初是由Facebook工程师Avinash Lakshman和Prashant Malik开发的分布式结构化存储系统，用于支持社交媒体公司的收件箱搜索功能。2008年7月，Facebook将Cassandra作为Google代码的开源项目发布，到2010年，它已成为顶级Apache项目。

DataStax的开发者关系副总裁帕特里克·麦克法丁（Patrick McFadin）表示，该项目由商业公司DataStax支持，该公司提供有偿DBaaS，但开源项目的想法对该公司仍然至关重要，因为开发者希望在云中获得自由和灵活性。

“因为云，它变得非常有趣。我们进入了这个世界，有很多项目和公司开始做这种假开源，你可以说它在你的笔记本电脑上工作，但在其他任何地方你都必须付费。

“没有人喜欢陷入陷阱。[开源]对于开发人员来说仍然是非常重要的，因为他们希望有选择的自由和扩展的自由。如果你看看所有主要的开源数据库，包括Cassandra、MySQL和PostgreSQL，它们都做得很好。有一个企业版，你可以付费，还有一个托管服务，你可以付钱。但是，还有一个免费版本。”

麦克法丁补充道：“如果你看看DataStax的客户，他们雇佣了这三家公司。我们有非常大的客户会购买我们的企业版，他们会使用我们的托管服务，然后他们会在同一个环境中拥有很多开源的Cassandra。他们有一种心理安全感，知道他们可以根据当前的业务四处移动。没有开源数据库，你无法做到这一点。”

例如，亚马逊有自己的键值数据库DynamoDB，它将其作为服务提供。

“你不能在亚马逊之外运行DynamoDB，因为它有一个非常明确的API。因此，开源不仅仅是软件，还有标准、API或查询语言等，”McFadin说。

他表示，DataStax将向开源社区发布其云服务的任何扩展，因为其付费卡桑德拉迭代和Apache卡桑德拉的API之间存在分歧。他认为，这意味着客户可以自由地离开任何付费系统，而无需对其应用程序进行重大重写。

麦克法丁说：“客户有时也会离开。我想的第一件事是，‘哦，那太糟糕了’。但这不是正确的说法。更像是‘我很高兴你还在使用卡桑德拉，我会在社区里看到你’，这是正确的答案。”。

Yugabyte：都是关于DBaaS的

YugabyteDB是过去几年中备受关注的分布式RDBMS供应商之一。其他获得NewSQL这个可疑名字的人包括CochroachDB，在某种程度上还有MariaDB。

Yugabyte是一个双层数据库。它的灵感来自下面的Google Panner，并与上面的PostgreSQL兼容，目的是创建一个高度可用、可扩展的分布式数据库。

去年10月，该公司在C轮融资中筹集了1.88亿美元，其业务价值约为13亿美元。

YugabyteDB在Apache 2.0许可下可用，并跨私有、公共和混合云环境在Kubernetes、VM和裸机上运行。

该公司由前Facebook工程师Kannan Muthukkaruppan、Karthik Ranganathan和Mikhail Bautin创建，于2017年脱离了秘密状态，但直到2019年才采用Apache 2.0。这一原因暴露了一些关于开源数据库的公开争论。

现在担任首席技术官的Ranganathan在接受注册时表示，所有创始人从一开始就希望完全开源，但投资者说服了他们。

“投资者群体非常清楚，开源是一种正在消亡的商业模式。因此，我们决定从根本上说，我们将成为一家开源公司，但因为他们的投资者说完全开源是一场失败的游戏，我们选择了开放核心，这意味着我们的数据库将有80%的价值是开放的，20%是关闭的，”他说。

然而，在该软件获得早期客户的支持后，它决定改变主意。

Ranganathan说：“我们意识到，除了在数据库中找出我们需要什么之外，如果没有DBaaS方面的支持，这就像刚到就死了一样。”。

这个启示意味着在DBAA上的竞争力与在数据库上的竞争力一样重要，客户希望数据库是开源的。Ranganathan指出：“我们告诉客户，我们喜欢PostgreSQL，但它是分布式的，他们说‘但PostgreSQL是非常开放的’。”。

Ranganathan说，尽管供应商担心——如果他们完全开放源代码——AWS或其他云提供商会通过提供自己的DBAA来吃午餐，但这没有抓住要点。

“如果——作为拥有该项目的主要供应商——您的DBaaS产品足够好，那么就应该很容易为人们提供使用该托管服务的理由。AWS只能为AWS提供这种服务；我们可以在任何云上（包括云外）提供这种服务，因为我们没有特别的偏好；我们实际上希望它在任何地方都可用。AWS只有在拥有整个基础设施时才能成功。”cture数据，即使客户想要拥有它，我们也是成功的。”

MariaDB：开源，但用于商业主干

MariaDB是从MySQL中分割出来的，MySQL是一个开源关系数据库，始于1995年。自2008年以来，MySQL一直是Sun Microsystems的一部分，但2010年甲骨文收购Sun时，MySQL联合创始人Widenius将代码分给了一个新的开源数据库MariaDB。

MariaDB采用了业务源代码许可证（BSL），批评者认为它不是真正的开源，因为它不允许用户或开发人员使用代码做他们想做的事情。在BSL下，源代码始终是公开的，非生产使用的代码始终是免费的，并且源代码最终保证开放。

该公司表示，许可模式只要求生产使用该软件的人获得商业许可，这通常表明环境为企业带来了巨大价值。

虽然BSL不符合OSI定义，但MariaDB确实坚持开源精神，同时确保其成为可持续发展的公司。

MariaDB首席执行官迈克尔·霍华德，告诉Reg：“开源最初是一种意识形态和一种生活方式。它是关于自由软件和非商业商业商业模式。在当今世界，世界上最大、最强大的公司在商业化努力中为自己的目的重用开源，人们意识到开源不能独立。独立、独立和依赖独立取决于强大的商业支柱。”

虽然BSL是“对开源的认可”，但它也为给定产品提供了强大的商业化平台。霍华德说：“这与Apache BSD或GPL（Linux使用的）非常不同，后者有悬而未决的需求和障碍，要求人们贡献一部分，并自动将其返回存储库，让任何人使用。”。

通过这种方式，它阻止了世界上最大的云公司围绕MariaDB数据库提供商业软件作为服务。“hyperscalers业务中的商业模式无疑推动了新的许可证模式，包括BSL。然而，当它最初设计时，更多的是关于企业家建立一个良好的企业，”他说。

Howard说，虽然MariaDB的许可证比其他开源项目更严格，但它可能比任何开源数据库都吸引更多的贡献，包括MySQL和PostgreSQL，这两个数据库都更老。

但与专有软件不同的是，无论是来自用户还是支持公司的开发人员，都可以自由查看源代码，一旦他们的数据库被转移到更为宽松的许可证，就可以为用户提供支持选项。

“大型机构将开源视为给他们提供了一种选择，他们可以与供应商合作，就像MariaDB一样，或者如果必须，他们可以修复自己的错误。他们可以雇佣人来修复错误，而不必依赖商业项目。这是一个深刻的区别，”他说。

CockroachDB：开源历史，商业前景

蟑螂实验室在这一领域相对来说是个新手。它由前谷歌程序员斯宾塞·金博尔（Spencer Kimball）、彼得·马蒂斯（Peter Mattis）和本·达内尔（Ben Darnell）于2015年创建。

该公司的数据库CockroachDB是一个分布式RDBMS，与PostgreSQL兼容，并由一个键值存储支持，该键值存储是RocksDB或一个专门构建的名为Pebble的衍生工具。

2021 12月，该公司通过2.78亿美元的F轮融资达到了50亿美元的名义估值。它的客户包括康卡斯特、eBay和Nubank。

像MariaDB一样，CockroachDB严重依赖于BSL。源代码是可用的，但未经Cockroach Labs同意，用户不得将CockroachDB用作服务。其他核心功能受CCL（Cockroach Community许可证）约束，根据该许可证，某些功能是付费或免费的，但代码是可用的。发布几年后，代码转移到Apache 2.0许可证。

Cockroach说，BSL没有被认证为开源许可证，但大多数OSI标准都得到了满足。

尽管开源和商业模式混合在一起，首席产品经理Jim Walker表示，公司一直沉浸在开源运动中。早期的版本是在Apache许可下发布的，而共同创始人Kimball和Mattis是流行的开源GIMP照片处理工具的幕后推手，该工具是由一个大学项目产生的。

但对沃克来说，开源不仅仅是许可证。“我并不是说它不重要，绝对不重要。如果你打算纯粹基于这一因素来做一个二进制的‘什么是开源？’？好吧，很好，我理解开源与否。然而，对我来说，开源远远不止于此。有一个社区的人参与其中。他们喜欢贡献和讨论（计算问题）。第一，这是关于人的。

“第二，它是关于代码的。它是关于开放源代码库的。如果你正在攻读分布式系统博士学位，你可以查看蟑螂实验室的代码库。现在，它完全开放。任何人都可以查看。”

批评者指出，对于采用混合模式的公司来说，他们的项目最终往往依赖于一个供应商，该供应商可以控制项目的方向，而不管更广泛社区的观点如何。贡献的多样性是一个健康的迹象。

但就贡献而言，沃克承认，大部分都是蟑螂实验室。那么，为什么不全力以赴，通过使软件成为专有软件来保护其知识产权呢？

沃克说：“对我来说，这是一条死胡同。考虑到过去三到五年来，由于开源，世界的发展速度。我说的不仅仅是我们的软件：世界发生了变化，因为我们可以从我们的系统中获得效率和规模。我们绝对是一个公民，也是其中的一部分。”。

他还认为，CockroachDB为用户提供了未来选择软件的自由：他们可以将数据和模式迁移到数据库的免费版本，并让其他人托管，或者自己运行。

但沃克表示，开发商面临的压力可能会阻止他们放弃付费托管服务。

“人们只是不这样做。没有人愿意这样做。CockroachDB的一部分价值基本上是，我不需要雇佣很多人，我也不需要那么多的资源来运行数据库。市场上出现了一种新的愿望，即低运营成本，并消除了我必须做的大量工作。”

MongoDB：超尺度（hyperscalers ）将我们排除在外的风险

随着13年前第一次发布，MongoDB在某种程度上是NoSQL运动的鼻祖。至少根据DB引擎，它也是避免关系模型的数据库中排名最高的。

该公司于2017年首次公开募股，目前估值约220亿美元。

MongoDB为2018年10月16日之后发布的所有版本提供服务器端公共许可，而自由软件基金会的GNU AGPL v3.0适用于该日期之前发布的MongoDB软件。

SSPL由MongoDB引入，要求向社区发布MongoDB的增强功能。如果出于法律原因无法接受，则可以使用MongoDB Enterprise Advanced获得商业许可。

产品管理高级副总裁安德鲁·戴维森（Andrew Davidson）表示：“开源是MongoDB成功的关键部分。在当今时代，如果没有开源第一的理念，就不可能成为广泛采用的开发解决方案。”

但多年来，该公司开始意识到，超尺度者将MongoDB投资的产品作为服务交付的风险，将MongoDB排除在外，他说。

“SSPL是非常明确的，旨在澄清一个模糊性，即您不能将MongoDB作为托管云服务交付，目标是超规模者。通过SSPL许可的社区版让我们的用户可以自由地在任何他们想要的地方运行它，并将其用于他们想要的任何应用程序。唯一的限制是，他们不能将其作为管理服务销售。”d云服务，”戴维森说。

但他们可以在MongoDB之上构建自己的软件，并将其作为服务提供，他说。

在MongoDB早期开发之后的几年中，该公司开始意识到未来是托管服务，因此投入了创建Atlas的工作，即其DBAA，例如，该公司通过解决分析问题的附加功能对其进行了修饰。

批评者提出的关于混合模式开源的一个问题是未来自由的问题：一旦客户构建了应用程序，他们是否有能力离开供应商？他们可以复制数据库并在其他地方托管应用程序吗？

对于MongoDB Atlas，答案是“可能”和“取决于”

“我们已将Atlas扩展到OLTP数据库之外，以提供触发器、数据湖产品、数据联盟、API服务器和应用服务等……基本上，您可以完全移动这些服务。如果您正在使用这些辅助服务中的任何一项，那么如果您离开Atlas，您必须构建自己的体验这些类型用例的方式。”

虽然开源倡导者认为项目受益于多种贡献者，如PostgreSQL，但戴维森认为，亚马逊、微软和EDB等贡献者的企业对项目的成功感兴趣。

MongoDB可能更像是一个单一的供应商项目，但这允许它“沉迷于开发人员体验，并以一种与脱节的联合体模式稍有不同的方式创造优雅的集成体验，”戴维森说。

无论对开源的解释如何，它都有一个共同的核心价值，那就是对代码的信任。“你需要能够知道，你可以进去，用显微镜[和]检查这个东西是如何建造的。

“当然，你可能不会真的这么做，但知道无数其他人——博士、学生、学者和行业专业人士——正在这么做是非常关键的。我们谈论的是人们应用程序的核心，这是他们业务的关键。这一切都是关于知道你正在构建的是社区验证的东西。”

魔鬼的拥护者也可能会指出，世界各地的银行都在运行专有的Oracle和Db2，而且它们似乎很好。但这些系统都是由大型公司多年来设计的。开放源代码模型允许在没有这种支持的情况下可靠地引入新数据库。

Exasol：社区无法实现的专有技术

最后，观察者认为所有现代数据库都以某种方式基于开源软件，这是可以原谅的，但事实并非如此。德国的Exasol开发了一种内存分析系统，戴尔和体育巨头阿迪达斯使用该系统。长期以来，它一直声称在TPC价格/性能基准方面处于领先地位。

首席技术官Mathias Golombek告诉《注册》杂志，并行硬件有一些细节，这意味着开源路线对他们的核心产品不起作用。

“开源系统非常流行，尤其是事务数据库，”他说。“在更动态的数据分析领域，Exasol以各种方式拥抱开源软件；然而，我们的核心数据库引擎仍然是专有的，因为到目前为止，还没有能够访问MPP硬件设置并专门从事内存计算的合适的开发人员社区。

“为了充分利用这两个世界，并支持开源作为软件行业的一个基本概念，Exasol通过利用敏捷社区帮助创建各种集成项目，增加了数十个开源项目，如通过我们的语言容器的数据科学，或通过虚拟模式的数据虚拟化。

“随着时间的推移，我们了解到，与封闭源代码相比，开放源代码的重要性越来越小，而是软件体系结构是否与数据问题相关。开放源代码商业模式已经让尚未实现这一目标的企业软件供应商失败了。”

本文：https://jiagoushi.pro/open-source-databases-what-are-they-and-why-do-th…

确定哪种类型的数据库或数据库服务最适合您的企业的最佳方法是什么？这完全取决于您需要什么类型的用例。在本文中了解更多信息。

基本上，我们每天使用的所有数字信息都在世界某处的数据库管理系统或存储阵列中。这些存储设备可以小到智能手机，也可以大到基本上不受限制的云存储系统。

如何最好地找出哪些DBMS适合您的企业？你应该订阅AWS、Azure、Google或其他云服务提供商提供的服务，还是购买数据中心存储和服务器并自己运行？这完全取决于您需要哪种类型的用例；例如，如果您是金融服务、医疗保健或国防部门的受监管行业，则可能需要同时安装这两种类型的用例。如果你是一个小企业，也许你需要的只是云服务。这里的大多数公司都提供这两种选择。

自20世纪80年代《个人电脑周》（PC Week）出版以来，eWEEK一直在研究和报告数据库及其管理系统，当时IBM的DB2、微软的SQL Server和Sybase是该行业的大腕。在这篇文章中，我们找到并评估了2019年前十大现代数据库管理系统，包括专有和开源系统，并将它们编译到本文中。

 

Oracle RDMS

加州红木海岸。

潜在买家的价值主张：大型、功能强大且相对昂贵的条款通常附属于Oracle的企业数据库，但你可以得到你所付出的代价。

甲骨文在这一领域统治了30多年，该公司在这一领域已有42年的历史。甲骨文设计了其数据库硬件和软件，以便在云端和数据中心协同工作。该公司声称，这消除了复杂性，简化了一般性。这通常是正确的，但是如果用例和环境发生变化，用户通常会被锁定在一个单一的供应商系统中，以后很难更改。

甲骨文对它的所有层都采用开放标准的方法，但它需要本地企业it人员的专业知识才能在预先配置的甲骨文系统之外更换各种组件，而且许多中小型企业都没有这种专业知识。定价sla也会发生变化。复杂度较低，维护较少的点解决方案和一般一流的性能的权衡往往过于压倒许多企业忽视。

作为一家早年对云系统嗤之以鼻的公司，它现在是一家积极销售基于云的DBMS系统的公司，以配合其Exadata数据中心服务器。时代确实变了，甲骨文也跟着时代变了。

对于需要模块化解决方案的客户，Oracle的开放式体系结构和多个操作系统选项提供了来自堆栈每一层中同类最佳产品的无与伦比的好处。这允许客户为其企业构建尽可能优化的基础架构。

关键价值/差异：

• Oracle SQL的基于UNIX的数据库管理系统提供了在任何操作系统中选择运行企业数据库的灵活性。专用语言仅与同一制造商的操作系统兼容。例如，只能在基于Windows的计算机上运行Microsoft SQL Server。相比之下，您可以在Unix服务器上安装Oracle SQL，在保持SQL标准化的同时，还可以从Unix的可靠性中获益。
• Unix不易受到许多常见的计算机病毒的攻击，从而保证信息的安全。
• Oracle SQL也是向后兼容的，因此用户可以选择在将来升级而不丢失任何数据。
• 对于需要模块化解决方案的客户，Oracle的开放式体系结构和多种操作系统选项提供了来自堆栈每一层中同类最佳产品的好处。这允许客户为其企业构建尽可能优化的基础架构。

路线图：

• Oracle数据库管理系统每年更新一次或两次，并定期迭代发送。

谁使用它：中大型企业

工作原理：云部署、物理on-prem服务

埃韦克分数：4.9/5.0

 

Oracle提供的MySQL

加州红木海岸。

潜在买家的价值主张：Oracle拥有的MySQL是一个流行且广泛使用的开源关系数据库管理系统。

这是一个节省成本和有效的数据库管理系统，但它需要专门知识的数据库系统安装和维护。它的名字是“My”和“SQL”的组合，前者是联合创始人MichaelWidenius的女儿，后者是结构化查询语言的缩写。MySQL是GNU通用公共许可条款下的免费开源软件，也可以在各种专有许可下使用。MySQL是由瑞典MySQL公司创建和赞助的，该公司被Sun Microsystems收购。2010年，当甲骨文收购Sun时，Widenius将开源MySQL项目分给了MariaDB。

关键价值/差异：

• 它有一个令人印象深刻的用户列表。MySQL被许多数据库驱动的web应用程序使用，包括Drupal、Joomla、phpBB和WordPress。MySQL也被许多流行网站使用，包括Facebook、Twitter、Flickr和YouTube。
• MySQL长期以来一直受到好评，评论人士称它在一般情况下表现非常好，开发人员界面也在那里，文档（更不用说通过网站等在现实世界中的反馈）非常非常好。
• 它还被测试为一个快速、稳定、真正的多用户、多线程的SQL数据库服务器。
• 它的开源核心和属性支持用例所需的任意数量的配置。
• 甲骨文拥有一支庞大而专业的支持人员队伍，可以与MySQL客户合作。
• MySQL在大多数企业服务器上工作，它们不必是Oracle服务器。

路线图：

• MySQL每年都会从Oracle的团队那里获得几次更新，并且会定期迭代发送。

谁使用它：中小企业到大企业

工作原理：订阅云服务、物理on-prem服务

埃韦克分数：4.9/5.0

 

Microsoft SQL服务器

雷蒙德，华盛顿。

潜在买家的价值主张：这是一个行业标准的数据库管理系统。

Microsoft SQL Server的历史始于第一个microsoftsqlserver产品（SQL Server 1.0，1989年用于IBM OS/2操作系统的16位服务器），一直延续到今天。微软重新开发了Microsoft SQL Server，使其能够与自己的Windows操作系统最佳地协同工作。与其他数据库管理系统类似，它的主要功能是根据其他软件应用程序的请求存储和检索数据，这些应用程序可以运行在同一个数据中心上，也可以运行在网络（包括internet）上的另一台计算机上。事实上，近一半的微软SQL Server实例部署在微软的Azure云中。

关键价值/差异：

以下是自2019年4月起SQL Server的新功能列表。

• 微软已经开发了至少十几个版本的Microsoft SQL Server，针对不同的受众和工作负载，从小型的单机应用程序到大型的面向Internet的应用程序，这些应用程序有许多并发用户。因此，它是迄今为止最通用的MySQL部署。
• SQL Server企业版：这包括核心数据库引擎和附加服务，以及一系列用于创建和管理sqlserver集群的工具。它可以管理高达524petabytes的数据库，处理12tb的内存，并支持640个逻辑处理器（CPU核）。
• 标准版：SQL Server标准版包括核心数据库引擎和独立服务。它不同于企业版，因为它支持较少的活动实例（集群中的节点数），并且不包括一些高可用性功能，如热添加内存（允许在服务器仍在运行时添加内存）和并行索引。Web SQL Server Web版是一个低TCO的Web宿主选项。
• 商业智能：在SQL Server 2012中引入，专注于自助服务和企业商业智能。它包括标准版功能和商业智能工具：PowerPivot、Power View、BI语义模型、主数据服务、数据质量服务和xVelocity内存分析。

路线图：

• SQL Server每年会获得一到两次主要更新，今年晚些时候将发布一个新版本，其中包括智能查询处理、大数据集群和更多功能。

谁使用它：中小企业、中端服务器、边缘服务器、大型企业

工作原理：订阅云服务和物理on-prem服务

埃韦克分数：4.7/5.0

PostGres SQL

费城,宾夕法尼亚州。

对潜在购买者的价值定位:PostgreSQL是一个对象关系数据库管理系统，强调可扩展性和标准遵从性。它可以处理许多并发用户的工作负载，从单机应用程序到Web服务或数据仓库。PostgreSQL是由PostgreSQL全球开发小组开发的，该小组由许多公司和个人贡献者组成。它是自由和开放源代码的软件，在一个宽松的软件许可下发布。

键值/差异:

• PostgreSQL是跨平台的，可以在许多操作系统上运行，包括Linux、FreeBSD、Solaris和Microsoft Windows。它可以处理从小型单机应用程序到具有许多并发用户的大型面向internet的应用程序等各种工作负载。最近的版本还提供了数据库本身的复制，以保证安全性和可伸缩性。
• PostgreSQL支持ANSI SQL和SQL/MED等标准，但具有高度可扩展性，支持12种以上的过程语言、GIN和GIST索引、空间数据支持，以及基于文档或键值的应用程序的多个类似于SQL的特性。
• PostgreSQL是acid兼容和事务性的。它提供了对RDBMS特性的支持，如可更新和物化视图、触发器、外键;函数和存储过程。

路线图:

• PostgreSQL每年都会有几次主要的更新。

谁在使用它:中小型企业、中型企业、边缘服务器、大型企业

它是如何工作的:订阅云服务，物理预发布服务

eWEEK评分:4.8/5.0

 

MongoDB

纽约,纽约

对潜在购买者的价值定位:MongoDB是一个开源的、跨平台的面向文档的数据库管理系统。

作为一个NoSQL数据库管理系统，MongoDB使用类似json的文档和模式。MongoDB由MongoDB公司开发，并在服务器端公共许可证(SSPL)下授权。作为一种开源产品，定价对于小公司来说要合理得多，这与大型、成熟的数据库供应商提供的全服务是不同的。

键值/差异:

• MongoDB可以运行在多个服务器上，平衡负载或复制数据以保持系统正常运行，以防硬件故障。
• MongoDB提供高可用性的副本集，其中包含两个或多个副本的数据。每个副本集成员可以在任何时候充当主副本或次副本的角色。默认情况下，所有的写和读都是在主副本上完成的。
• 辅助副本使用内置的复制来维护主副本的数据副本。当主副本失败时，副本集将自动执行一个选择过程，以确定哪个辅助副本应该成为主副本。二级服务器可以选择性地提供读操作，但是默认情况下这些数据最终是一致的。
• MongoDB使用分片进行水平扩展(分片是一个拥有一个或多个副本的主机)。

路线图:

• MongoDB每年都会有几次重大更新。

谁在使用它:中型到大型企业

它是如何工作的:订阅云服务，物理预发布服务

eWEEK评分:4.8/5.0

IBM DB2

纽约州阿蒙克市

潜在购买者的价值主张:IBM DB2是一种行业标准数据库管理系统。

DB2代表了一组完整的数据管理系统，包括可在云环境中使用的服务器，这些服务器最初是由IBM在20世纪80年代早期开发的。它们支持关系数据库模型，但近年来，一些产品已经扩展为支持对象关系特性和非关系结构，如JSON和XML。从1983年创建到2017年，该品牌被命名为DB2。

IBM在2019年为Db2制定的目标是成为帮助增强认知应用程序的人工智能数据库。IBM混合数据管理(HDM)是在Db2公共SQL引擎上构建的，它提供了一个平台来跨所有源和目标管理所有数据类型。

由于该软件的高可靠性、弹性和安全性等特点，成千上万的组织使用IBM混合数据管理和db2(在线事务处理(OLTP)、在线分析处理(OLAP)和大数据段中的市场支柱)来运行关键任务应用程序。IBM打算使用Db2(混合数据管理平台的核心组件)让用户能够加速他们的AI应用程序开发，同时自动化一些数据管理。

IBM Db2现在为流行的数据科学语言和框架提供了驱动程序，包括Go、Ruby、Python、PHP、Java和Node。使开发人员和数据科学家能够第一次使用Db2数据构建AI应用程序。这些驱动程序现在可以在GitHub上使用。

键值/差异:

• IBM的商标，在几十年的产品开发和服务中建立起来的声誉，在所有数据中心系统软件和设备中意义重大。
• DB2系统的一个重要特性是错误处理。SQL communications area (SQLCA)结构曾经专门用于DB2程序中，在执行每条SQL语句之后将错误信息返回给应用程序。主要的(但不是特别有用的)错误诊断位于SQLCA块中的SQLCODE字段中。

路线图:

• DB2每年进行一次或两次重大更新，并根据需要进行增量修复。

谁在使用它:中小型企业到大型企业

它是如何工作的:云服务，物理预启动服务

eWEEK评分:4.8/5.0

 

Microsoft Access

华盛顿州雷德蒙德

潜在买家的价值主张:Microsoft Access是第二代数据库管理系统(DBMS)，它将关系型Microsoft Jet数据库引擎与图形用户界面和它自己的一套软件开发工具结合在一起。

它是Microsoft Office应用程序套件的成员，包含在专业版和高级版中，或单独出售。Microsoft Access基于Access Jet数据库引擎以自己的格式存储数据。它还可以导入或直接链接到存储在其他应用程序和数据库中的数据。与其他Microsoft Office应用程序一样，Visual Basic for applications (VBA)支持访问，这是一种基于对象的编程语言，可以引用各种对象，包括DAO(数据访问对象)、ActiveX数据对象和许多其他ActiveX组件。窗体和报表中使用的可视化对象在VBA编程环境中公开它们的方法和属性，VBA代码模块可以声明和调用Windows操作系统操作。

键值/差异:

• 除了用作自己的数据库存储文件之外，Microsoft Access还可以用作程序的前端，而其他产品用作后端表，如Microsoft SQL Server和非Microsoft产品，如Oracle和Sybase。Microsoft Access Jet数据库(ACCDB和MDB格式)可以使用多个后端源。
• 类似地，一些应用程序如Visual Basic, ASP。NET或Visual Studio .NET将对其表和查询使用Microsoft Access数据库格式。Microsoft Access也可能是更复杂的解决方案的一部分，它可能与其他技术集成，如Microsoft Excel、Microsoft Outlook、Microsoft Word、Microsoft PowerPoint和ActiveX控件。
• 访问表支持各种标准字段类型、索引和引用完整性，包括级联更新和删除。访问还包括查询接口、用于显示和输入数据的表单以及用于打印的报告。包含这些对象的底层Jet数据库是多用户的，它处理记录锁定。
• 重复的任务可以通过带有指向和单击选项的宏实现自动化。在网络上放置数据库，让多个用户共享和更新数据，而不覆盖彼此的工作，这也很容易。数据被锁定在记录级别，这与Excel锁定整个电子表格有很大的不同。

路线图:

• Microsoft give Access每年获得一到两次重大更新，并根据需要进行增量修复。预计今年不会有重大更新。

谁在使用它:中型到大型企业

它是如何工作的:云服务，物理预启动服务

eWEEK评分:4.6/5.0

Redis 实验室

加州山景城。

潜在买家的价值主张:Redis内存数据库管理系统是为速度和效率而设计的第二代核心开源系统。Redis Labs是商业Redis提供商市场的老大，它的企业级Redis DBMS速度快于平均水平，为前沿应用程序提供了强大的支持。它的Redis Labs企业集群和Redis云解决方案因高性能、高可伸缩性、真正的高可用性、一流的专业知识和支持用例而受到数千名开发人员和企业客户的信任。这些包括实时分析、快速的大容量事务、社交应用程序功能、应用程序作业管理和缓存。

键值/差异:

• Redis Labs是Redis的主要贡献者，该数据库已成为2019年可用的最快数据库。
• Redis在开发者中排名第一，在所有开发者工具和服务中排名第12。
• Redis被认为是以下用例的一流数据库:分析、大数据、云数据服务、企业软件、信息技术、开源、软件即服务。

路线图:

• Redis定期获得主要更新，有时每周更新一次。

谁在使用它:中型到大型企业

工作原理:只提供云服务

eWEEK评分:4.9/5.0

 

Apache Cassandra

门洛帕克,加利福尼亚州。

对潜在买家的价值定位:Apache Cassandra最初是在Facebook开发的，用于支持其收件箱搜索功能，现在是世界上领先的内存开源数据库管理系统之一。它是一个免费的、开源的、分布式的、宽列存储的NoSQL数据库管理系统，设计用于跨许多普通服务器处理大量数据，提供高可用性，没有单点故障。Cassandra为跨多个数据中心的集群提供了健壮的支持，异步无主复制允许所有客户端进行低延迟操作。

键值/差异:

• 集群中的每个节点都具有相同的角色。没有单一的失败点。数据分布在集群中(因此每个节点包含不同的数据)，但是没有主节点，因为每个节点都可以为任何请求提供服务。
• 支持复制和多数据中心复制:复制策略是可配置的。Cassandra被设计为一个分布式系统，用于跨多个数据中心部署大量节点。Cassandra的分布式架构的关键特性是专门为多数据中心部署、冗余、故障转移和灾难恢复而定制的。
• 可伸缩性:设计为读写吞吐量均随着新机器的添加而线性增加，目标是不停机或不中断应用程序。
• 容错:自动将数据复制到多个节点以实现容错。支持跨多个数据中心的复制。失败的节点可以替换为没有停机时间。
• 可调一致性:Cassandra通常归类为一个美联社系统,这意味着可用性和分区容忍通常被认为是更重要的比一致性在卡桑德拉,写入和读取的提供一个可调水平的一致性,从“写永远不会失败”“阻止所有副本可读,”中间的群体水平。

路线图:

• Cassandra每年都会有几次重大更新。

谁在使用它:中型到大型企业

工作原理:只提供云服务

eWEEK评分:4.8/5.0

 

荣誉奖:Sybase by SAP (SAP Adaptive Server)， SAP HANA, Quest, CA, BMC

 

原文：https://www.eweek.com/database/top-database-management-systems-vendors

本文：http://jiagoushi.pro/top-database-management-systems-vendors

讨论：请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】

在当今实时数据处理和分析的世界中，流媒体数据库已成为希望保持领先地位的企业的重要工具。这些数据库专门设计用于处理连续大量生成的数据，非常适合物联网（IoT）、金融交易和社交媒体分析等用例。然而，市场上有这么多选择，选择合适的流媒体数据库可能是一项艰巨的任务。

👉 这篇文章帮助您了解什么是SQL流、流数据库、何时使用以及为什么使用它，并讨论了在为您的业务选择合适的流数据库时应该考虑的一些关键因素。

学习目标📖

您将在本文中学习以下内容：

• 什么是流数据（事件流处理）？
• 什么是流式SQL方法？
• 流式处理数据库、功能和用例。
• 排名前五的流媒体数据库（包括开源和SaaS）。
• 选择流式数据库的条件。

让我们在接下来的几节中快速回顾一些概念，比如什么是流式数据、流式SQL和数据库。

什么是流式数据？⤵️

流是随着时间的推移而可用的事件/数据元素的序列。数据流是一种实时处理和分析数据的方法，数据由各种来源生成，如传感器、电子商务购买、网络和移动应用程序、社交网络等。它涉及以事件或消息的形式持续不断地收集、处理和传递数据。

您可以使用更改数据捕获（CDC）从不同的数据源获取数据，如消息代理Kafka、Redpanda、Kinesis、Pulsar或数据库MySQL或PostgreSQL，这是识别和捕获数据更改的过程。

什么是流式SQL？⤵️

收集数据后，您可以将这些数据存储在流式数据库中（在下一节中，将对此进行解释），在那里可以使用SQL查询和SQL流式处理和分析这些数据。这是一种使用SQL查询处理实时数据流的技术。它允许企业使用与批处理相同的SQL语言来实时查询和处理数据流。

数据可以从流中实时转换、过滤和聚合为更有用的输出，如物化视图（CREATE materialized view），以提供见解并实现自动化决策。

☝️ 物化视图通常用于需要频繁执行复杂查询或查询结果需要长时间计算的情况。通过预计算结果并将其存储在物化视图（虚拟表）中，可以更快地执行查询，并减少开销。PostgreSQL、Microsoft SQL Server、RisingWave或Materialize支持自动更新的物化视图。

SQL流的一个主要好处是，它允许企业利用现有的SQL技能和基础设施来处理实时数据。这可能比学习Java、Scala等新的编程语言或处理数据流的工具更有效👍.

什么是流式数据库？⤵️

流式数据库，也称为实时数据库，是一种设计用于实时处理连续数据流的数据库管理系统。它经过优化，可处理和存储以连续快速流形式到达的大量数据。

流式数据库使用与传统数据库相同的声明性SQL和相同的抽象（表、列、行、视图、索引）。与传统数据库不同，数据存储在与写入（插入、更新）结构匹配的表中，所有计算工作都发生在读取查询（选择）上，流式数据库在连续的基础上运行，在数据到达时处理数据，并以物化视图的形式将其保存到持久存储中。这允许对实时事件进行即时分析和响应，使企业能够根据最新信息做出决策和采取行动。

流式数据库通常使用专门的数据结构和算法，这些结构和算法经过优化以实现快速高效的数据处理。它们还支持复杂事件处理（CEP）和其他实时分析工具，以帮助企业实时获得见解并从数据中提取价值。

流式数据库独有的功能之一是能够更新增量物化视图💪.

您可以对Stream数据库做些什么？⤵️

以下是您可以使用流式数据库执行的一些操作：

• 从不同的流/数据源（如Apache Kafka）收集和转换数据。
• 为需要增量聚合的数据创建物化视图。
• 使用简单的SQL语法查询复杂的流数据。
• 在聚合和分析实时数据流之后，您可以使用实时分析来触发下游应用程序。

5个顶级流媒体数据库⤵️

由于有各种类型的流式数据库可用，并且每个流式数据库都提供了许多功能。

下面，我分享了5个顶级流媒体数据库（包括开源和SaaS），并注意到它们并没有按流行或使用的特定顺序排列。

1. RisingWave.
2. Materialize.
3. Amazon Kinesis.
4. Confluent.
5. Apache Flink.

如何选择流媒体数据库⤵️

选择合适的流媒体数据平台可能是一项具有挑战性的任务，因为需要考虑几个因素。在选择流媒体数据平台时，需要记住以下一些关键注意事项：

• 数据源：考虑平台可以接收和处理的数据源类型。确保平台能够处理您需要的数据源。Kafka、Redpanda、Apache Pulsar、AWS Kinesis、Google Pub/Sub主要用作流源服务/消息代理。或者PostgreSQL或MySQL等数据库。
• 可扩展性：考虑平台随着数据需求的增长而扩展的能力。一些平台的扩展能力可能有限，而另一些平台可以处理大量数据和多个并发用户。确保缩放过程几乎可以在不中断数据处理的情况下立即完成。例如，开源项目RisingWave使用一致的哈希算法将数据动态划分到每个计算节点。这些计算节点通过计算数据的唯一部分进行协作，然后相互交换输出。就云提供商中的流媒体数据平台而言，它们支持开箱即用的自动扩展功能，因此这不是问题。
• 集成：考虑平台与其他系统和工具（如BI和数据分析平台）集成的能力，您目前正在使用或计划在未来使用这些平台。确保平台支持与其他系统连接所需的协议和API。RisingWave集成了许多BI服务，包括Grafana、Metabase、Apache Superset等。
• 性能：考虑平台的速度和效率。一些平台在查询速度、数据处理和分析方面可能比其他平台表现更好。因此，您需要选择一个流式数据库，该数据库可以在几秒钟内提取、转换和加载数百万条记录。流数据平台的关键性能指标（KPI）是事件速率、吞吐量（事件速率乘以事件大小）、延迟、可靠性和主题数量（对于发布子架构）。有时与基于JVM的系统相比，使用诸如Rust之类的低级编程语言设计的平台可能速度极快。
• 安全性：考虑平台的安全功能，如访问控制、数据加密和合规认证，以确保您的数据得到保护。
• 易用性：考虑平台的易用性，包括其用户界面、文档和支持资源。确保该平台易于使用，并为您的团队提供足够的支持。
• 成本：考虑平台的成本，包括许可费、维护成本以及任何额外的硬件或软件要求。确保该平台符合您的预算，并提供良好的投资回报。

总结⤵️

总之，流式数据库提供了几个独特的功能，包括实时数据处理、事件驱动架构、连续处理、低延迟、可扩展性、对各种数据格式的支持以及灵活性。这些功能能够在实时应用程序中实现更快的洞察力、更好的决策和更高效的数据使用。

适合您的用例的最佳流式数据库将取决于您的特定需求，例如支持的数据源、容量和速度、数据结构、可扩展性、性能、集成和成本。重要的是要根据这些因素仔细评估每个选项，以确定最适合您的组织。

相关资源

• What Are Materialized Views in Databases?
• What is Streaming SQL?
• How to choose a streaming data platform?

推荐内容

• Is RisingWave the Right Streaming Database?
• RisingWave vs Apache Flink
• Rethinking Stream Processing and Streaming Databases