是由 Yandex 创建的用于在线分析查询处理（OLAP）的开源列式数据库管理系统。 Yandex、CloudFlare、VK.com、Badoo 和世界各地的其他服务使用它来存储大量数据（每秒插入数千行或存储在磁盘上的 PB 数据）。
在普通的“字符串”DBMS 中，例如 MySQL、Postgres、MS SQL Server，数据按以下顺序存储：
在这种情况下，与一行相关的值在物理上并排存储。 在列式DBMS中，来自不同列的值是分开存储的，而一列的数据是存储在一起的：
列式 DBMS 的示例包括 Vertica、Paraccel（Actian Matrix、Amazon Redshift）、Sybase IQ、Exasol、Infobright、InfiniDB、MonetDB（VectorWise、Actian Vector）、LucidDB、SAP HANA、Google Dremel、Google PowerDrill、Druid、kdb+。
该公司是一家邮件转运公司 我于 2018 年开始使用 Clickhouse 进行报告，它的简单性、可扩展性、SQL 支持和速度给我留下了深刻的印象。 这个 DBMS 的速度近乎神奇。
缓解
Clickhouse 使用单个命令即可在 Ubuntu 上安装。 如果您了解 SQL，您可以立即开始使用 Clickhouse 来满足您的需求。 但是，这并不意味着您可以在 MySQL 中“显示创建表”并在 Clickhouse 中复制粘贴 SQL。
与 MySQL 相比，该 DBMS 中的表模式定义存在重要的数据类型差异，因此您仍然需要一些时间来更改表模式定义并学习表引擎以适应。
Clickhouse 无需任何其他软件即可正常工作，但如果您想使用复制，则需要安装 ZooKeeper。 查询性能分析显示出出色的结果——系统表包含所有信息，并且所有数据都可以使用陈旧而无聊的 SQL 获得。
Производительность
- Clickhouse 与 Vertica 和 MySQL 在配置服务器上的比较：两个插槽 Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz； 128 GiB 内存； md RAID-5，位于 8 个 6TB SATA HDD，ext4。
- Clickhouse 与 Amazon RedShift 云存储的比较。
- 博客摘录 :
ClickHouse数据库的设计非常简单——集群中的所有节点都具有相同的功能，并且仅使用ZooKeeper进行协调。 我们构建了一个由多个节点组成的小型集群并进行了测试，在此过程中我们发现该系统具有相当令人印象深刻的性能，这与分析型 DBMS 基准测试中所声称的优势相对应。 我们决定仔细研究 ClickHouse 背后的概念。 研究的第一个障碍是缺乏工具和 ClickHouse 的小社区，因此我们深入研究了这个 DBMS 的设计以了解它是如何工作的。
ClickHouse不支持直接从Kafka接收数据，因为它只是一个数据库，所以我们用Go编写了自己的适配器服务。 它从 Kafka 读取 Cap'n Proto 编码的消息，将其转换为 TSV，并通过 HTTP 接口批量插入 ClickHouse。 后来我们重写了这个服务，将 Go 库与我们自己的 ClickHouse 接口结合使用，以提高性能。 在评估接收数据包的性能时，我们发现了一件重要的事情——事实证明，对于 ClickHouse 来说，这种性能很大程度上取决于数据包的大小，即同时插入的行数。 为了理解为什么会发生这种情况，我们研究了 ClickHouse 是如何存储数据的。
主要引擎，或者更确切地说，ClickHouse 用于存储数据的一系列表引擎是 MergeTree。 该引擎在概念上类似于 Google BigTable 或 Apache Cassandra 中使用的 LSM 算法，但避免构建中间内存表并将数据直接写入磁盘。 这使其具有出色的写入吞吐量，因为每个插入的数据包仅按“主键”主键排序、压缩并写入磁盘以形成段。
缺乏内存表或任何数据“新鲜度”概念也意味着它们只能添加，系统不支持更改或删除。 截至目前，删除数据的唯一方法是按日历月删除数据，因为分段永远不会跨越月份边界。 ClickHouse 团队正在积极致力于使此功能可定制。 另一方面，它使写入和合并段无争用，因此接收吞吐量随着并行插入的数量线性扩展，直到 I/O 或内核饱和。
但是，这种情况也意味着系统不适合小数据包，因此使用Kafka服务和插入器进行缓冲。 进一步，ClickHouse在后台不断地不断合并片段，这样很多小片段的信息就会被组合起来记录更多次，从而增加记录的强度。 然而，只要合并继续，太多不相关的部分就会导致插入的严重限制。 我们发现，实时数据摄取和摄取性能之间的最佳折衷方案是每秒接受有限数量的表插入。
表读取性能的关键是数据在磁盘上的索引和位置。 无论处理速度有多快，当引擎需要从磁盘扫描 TB 级数据并且仅使用其中的一小部分时，都需要时间。 ClickHouse 是一个列存储，因此每个段都包含每列（column）的文件，以及每行的排序值。 因此，可以首先跳过查询中不存在的整个列，然后可以通过向量化执行并行处理多个单元。 为了避免完全扫描，每个段都有一个小索引文件。
鉴于所有列均按“主键”排序，索引文件仅包含每 N 行的标签（捕获的行），以便即使对于非常大的表也能够将它们保留在内存中。 例如，您可以将默认设置设置为“标记每 8192 行”，然后对 1 万亿的表进行“微薄”索引。 容易装入内存的行只需要 122 个字符。
系统开发
Clickhouse的发展和完善可以追溯到 并确保“成长”的过程以令人印象深刻的速度发生。
声望
Clickhouse 的受欢迎程度似乎呈指数级增长，尤其是在俄语社区。 去年的 High load 2018 会议（莫斯科，8 年 9 月 2018 日至 40 日）显示，像 vk.com 和 Badoo 这样的怪物使用 Clickhouse，它同时从数万台服务器插入数据（例如日志）。 在XNUMX分钟的视频中 。 很快我们将把成绩单发布在 Habr 上，以便于使用这些材料。
应用
经过一些时间的研究，我认为 ClickHouse 在某些领域可以很有用，或者能够完全取代其他更传统和流行的解决方案，例如 MySQL、PostgreSQL、ELK、Google Big Query、Amazon RedShift、TimescaleDB、Hadoop、MapReduce、Pinot 和德鲁伊。 以下是使用ClickHouse升级或完全替换上述DBMS的详细信息。
扩展 MySQL 和 PostgreSQL
最近，我们用 ClickHouse 部分取代了时事通讯平台的 MySQL 。 问题在于，由于设计不周，MySQL 使用 Base64 哈希记录了发送的每封电子邮件以及该电子邮件中的每个链接，从而创建了一个巨大的 MySQL 表 (email_stats)。 仅向该服务的订阅者发送了 10 万封电子邮件后，该表就占用了 150 GB 的文件空间，MySQL 在简单查询上开始变得“愚蠢”。 为了解决文件空间问题，我们成功地使用了 InnoDB 表压缩，将其减少了 4 倍。 然而，仅仅为了阅读历史记录而在 MySQL 中存储超过 20-30 万封电子邮件仍然没有意义，因为任何简单查询由于某种原因必须执行完整扫描，从而导致交换和大量 I/O开销，我们经常收到 Zabbix 的警告。
Clickhouse 使用两种压缩算法，可将数据量减少约 ，但在这种特殊情况下，数据特别“可压缩”。
ELK 替代品
根据我自己的经验，ELK 堆栈（ElasticSearch、Logstash 和 Kibana，在本例中为 ElasticSearch）需要的运行资源比存储日志所需的资源多得多。 如果您想要良好的全文日志搜索（我认为您并不真正需要），ElasticSearch 是一个很棒的引擎，但我想知道为什么它已成为事实上的标准日志引擎。 它的摄取性能与 Logstash 相结合，即使在相当轻的工作负载下也给我们带来了问题，并且需要添加越来越多的 RAM 和磁盘空间。 作为数据库，Clickhouse 比 ElasticSearch 更好，原因如下：
- SQL 方言支持；
- 存储数据的最佳压缩程度；
- 支持正则表达式搜索而不是全文搜索；
- 改进的查询调度和更好的整体性能。
目前，ClickHouse 与 ELK 进行比较时出现的最大问题是缺乏上传日志的解决方案，以及缺乏有关该主题的文档和教程。 同时，每个用户都可以使用Digital Ocean手册来设置ELK，这对于此类技术的快速实施非常重要。 这里有一个数据库引擎，但是 ClickHouse 还没有 Filebeat。 就在这里 以及一个处理日志的系统 ，有一个工具 将日志文件数据输入ClickHouse，但这一切都需要更多时间。 然而，ClickHouse 由于其简单性仍然处于领先地位，因此即使是初学者也可以轻松安装它并在短短 10 分钟内开始完整的功能使用。
我更喜欢简约的解决方案，尝试将 FluentBit（一种内存非常低的日志上传工具）与 ClickHouse 结合使用，同时尽量避免使用 Kafka。 但是，需要解决一些轻微的不兼容性，例如 在没有将数据从 FluentBit 转换为 ClickHouse 的代理层之前就可以完成。
作为 Kibana 的替代方案，您可以使用 ClickHouse 作为后端 。 据我了解，这可能会在渲染大量数据点时导致性能问题，尤其是使用旧版本的 Grafana 时。 在 Qwintry 中，我们还没有尝试过这一点，但 Telegram 的 ClickHouse 支持频道上不时出现对此的抱怨。
替换 Google Big Query 和 Amazon RedShift（针对大公司的解决方案）
BigQuery 的理想用例是加载 1TB 的 JSON 数据并对其运行分析查询。 Big Query 是一款出色的产品，其可扩展性不容小觑。 这是比运行在内部集群上的 ClickHouse 复杂得多的软件，但从客户端的角度来看，它与 ClickHouse 有很多共同点。 一旦您开始为每个 SELECT 付费，BigQuery 就会快速“定价”，因此它是一个真正的 SaaS 解决方案，具有所有优点和缺点。
当您运行大量计算成本较高的查询时，ClickHouse 是最佳选择。 您每天运行的 SELECT 查询越多，用 ClickHouse 替换 Big Query 就越有意义，因为当涉及到处理的数 TB 数据时，这种替换将为您节省数千美元。 这不适用于存储的数据，在 Big Query 中处理存储的数据非常便宜。
在 Altinity 联合创始人 Alexander Zaitsev 的一篇文章中 描述了此类 DBMS 迁移的好处。
TimescaleDB 替换
TimescaleDB 是一个 PostgreSQL 扩展，它优化了常规数据库中时间序列的处理（, ).
尽管ClickHouse在时间序列领域并不是一个严重的竞争对手，但在列式结构和向量查询执行方面，它在处理分析查询的大多数情况下都比TimescaleDB快得多。 同时，接收ClickHouse包数据的性能提高了约3倍，此外，它使用的磁盘空间减少了20倍，这对于处理大量历史数据来说非常重要： .
与 ClickHouse 不同，TimescaleDB 中节省一些磁盘空间的唯一方法是使用 ZFS 或类似的文件系统。
ClickHouse 即将进行的更新可能会引入增量压缩，这将使其更适合处理和存储时间序列数据。 在以下情况下，TimescaleDB 可能是比裸 ClickHouse 更好的选择：
- RAM 很少（<3 GB）的小型安装；
- 您不希望缓冲成大片段的大量小 INSERT；
- 更好的一致性、均匀性和 ACID 要求；
- PostGIS 支持；
- 与现有 PostgreSQL 表合并，因为 Timescale DB 本质上是 PostgreSQL。
与 Hadoop 和 MapReduce 系统的竞争
Hadoop 和其他 MapReduce 产品可以执行大量复杂的计算，但它们往往会以巨大的延迟运行。ClickHouse 通过处理 TB 级数据并几乎立即生成结果来解决这个问题。 因此，ClickHouse 在执行快速、交互式分析研究方面更加高效，这应该是数据科学家感兴趣的。
与皮诺和德鲁伊的竞争
ClickHouse 最接近的竞争对手是柱状、线性可扩展的开源产品 Pinot 和 Druid。 文章中发表了对这些系统进行比较的出色工作 1二月2018
这篇文章需要更新 - 它说 ClickHouse 不支持 UPDATE 和 DELETE 操作，这对于最新版本来说并不完全正确。
我们对这些 DBMS 没有太多经验，但我不喜欢运行 Druid 和 Pinot 所需的底层基础设施的复杂性 - 它是一大堆被 Java 从各个方面包围的“移动部件”。
Druid 和 Pinot 是 Apache 孵化器项目，Apache 在其 GitHub 项目页面上详细介绍了这些项目。 Pinot 于 2018 年 8 月出现在孵化器中，而 Druid 则早 XNUMX 个月出生——XNUMX 月。
由于缺乏有关 AFS 工作原理的信息，我提出了一些也许是愚蠢的问题。 不知道Pinot的作者是否注意到Apache基金会对Druid更加偏向，这种对待竞争对手的态度是否引起了嫉妒？ 如果支持前者的赞助商突然对后者感兴趣，Druid 的发展是否会放缓，Pinot 的发展会加速？
ClickHouse的缺点
不成熟：显然，这仍然是一项无聊的技术，但无论如何，在其他列式 DBMS 中还没有看到这样的情况。
小插入在高速下性能不佳：插入必须分成大块，因为小插入的性能随每行中的列数成比例降低。 这就是 ClickHouse 在磁盘上存储数据的方式 - 每列意味着 1 个或更多文件，因此要插入包含 1 列的 100 行，您需要打开并写入至少 100 个文件。 这就是为什么插入缓冲需要中介（除非客户端本身提供缓冲）——通常是 Kafka 或某种排队系统。 您还可以使用 Buffer 表引擎稍后将大块数据复制到 MergeTree 表中。
表连接受到服务器 RAM 的限制，但至少它们存在！ 例如，Druid 和 Pinot 根本没有这样的连接，因为它们很难直接在不支持在节点之间移动大块数据的分布式系统中实现。
发现
在未来几年中，我们计划在 Qwintry 中广泛使用 ClickHouse，因为该 DBMS 提供了性能、低开销、可扩展性和简单性之间的出色平衡。 我非常确定，一旦 ClickHouse 社区提出更多在中小型安装中使用它的方法，它就会迅速传播。
一些广告🙂
感谢您与我们在一起。 你喜欢我们的文章吗？ 想看更多有趣的内容？ 通过下订单或推荐给朋友来支持我们， , 我们为您发明的入门级服务器的独特模拟： （适用于 RAID1 和 RAID10，最多 24 个内核和最多 40GB DDR4）。
Dell R730xd 在阿姆斯特丹的 Equinix Tier IV 数据中心便宜 2 倍？ 只有这里 在荷兰！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起！ 阅读
来源： habr.com