入门ClickHouse和Elasticsearch

最新推荐文章于 2024-08-22 15:21:58 发布

柳小葱

最新推荐文章于 2024-08-22 15:21:58 发布

阅读量4.3k

点赞数 9

分类专栏：阿里云大数据实践文章标签： elasticsearch big data hadoop ClickHouse

本文链接：https://blog.csdn.net/weixin_48077303/article/details/123086422

版权

阿里云大数据实践专栏收录该内容

10 篇文章 24 订阅

订阅专栏

❄️大多数同学都知道数据有mysql、mongodb、oracle、nosql等等，这些是我们在学校能接触到最多的数据库,今天我们就来认识2个企业中比较常用的数据库clickhouse和elasticsearch。对大数据感兴趣的同学可以参考下面的文章👇:

hadoop专题: hadoop系列文章.
spark专题: spark系列文章.
flink专题: Flink系列文章.

⛄️处理大数据这一方面不只有hadoop这一脉、类似的像支持分布式的数据产品clickhouse和elasticsearch也都有自己的特点，在企业中运用也较多，本篇博客就是给它俩扫盲！

1. clickhouse

1.1 clickhouse介绍

ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。它是俄罗斯yandex公司于2016年开源的一个列式数据库管理系统，这里需要注意的是列式数据库，我们常用的数据库如：MySQL、Postgres和MS SQL Server都是行式数据库：

行式存储数据库：处于同一行中的数据总是被物理的存储在一起。
列式存储数据库：来自不同列的值被单独存储，来自同一列的数据被存储在一起。

这两种存储的方式适用不同的业务场景，没有绝对的谁比谁好，只是使用的场景有所不同，例如：进行了何种查询、多久查询一次以及各类查询的比例；每种类型的查询(行、列和字节)读取多少数据；读取数据和更新之间的关系；使用的数据集大小以及如何使用本地的数据集；是否使用事务,以及它们是如何进行隔离的；数据的复制机制与数据的完整性要求；每种类型的查询要求的延迟与吞吐量等等，根据用户使用的场景来选择。

前面说到，clickhouse适合OLAP的场景，下面列举一些OLAP场景的特征：

数据库的数据不能修改
绝大多数是读请求
没有更新或者大量更新
宽表
允许简单查询
事务不必须
数据一致性要求低

为什么列式存储更适合OLAP呢？我们简单来举例：

行式存储数据库获取某些列的数据绘制报表

在这里插入图片描述
在行式存储的数据库中，如果我们需要取出指定列的数据，你首先需要读取整行数据，然后从整行数据，然后再从读取的行数据中读取你需要的列数据。

列式存储数据库获取某些列的数据绘制报表

在这里插入图片描述
而在列式村存储中，你只需要读取存储列的一小部分数据即可，这这大大降低了I/O操作的消耗和体积。数据量越大，越能凸显出这种优势。

但clickhouse也有自己的缺点：

不支持事务（ACID）。
缺少高频率，低延迟的修改或删除已存在数据的能力。仅能用于批量删除或修改数据。
不擅长根据主键按行粒度查询。

1.2 clickhouse的特点

这个章节主要讲述clickhouse数据库的一些特点：

支持数据压缩，数据压缩可以达到更优异的性能。在一些列式数据库管理系统中(例如：InfiniDB CE 和 MonetDB) 并没有使用数据压缩。
数据存储硬盘：许多的列式数据库(如 SAP HANA, Google PowerDrill)只能在内存中工作，对设备要求高，而clickhouse是在磁盘上工作，成本低。
多核心并行处理：会使用服务器上一切可用的资源，从而以最自然的方式并行处理大型查询。
多服务器分布式处理：列式存储数据库中唯一份支持分布式查询的数据库。
支持SQL：入手快，许多情况下与ANSI SQL标准相同。
支持数据复制和数据完整性：使用异步的多主复制技术。当数据被写入任何一个可用副本后，系统会在后台将数据分发给其他副本，以保证系统在不同副本上保持相同的数据。
角色的访问控制

2. elasticsearch

2.1 elasticsearch介绍

Elasticsearch是一个实时分布式和开源的全文搜索和分析引擎。它可以从RESTful Web服务接口访问，并使用模式少JSON(JavaScript对象符号)文档来存储数据。它是基于Java编程语言，这使Elasticsearch能够在不同的平台上运行。使用户能够以非常快的速度来搜索非常大的数据量。

Elasticsearch最初是用于做全文检索的场景，可多数时候是用来做精确查询加速，查询条件很多，可以任意组合，查询速度很快，替代其它很多数据库复杂条件查询的场景需求，现在es已经成为事实上的文档型数据库，使用Json格式来存储数据。
在这里插入图片描述
根据2022年2月份的数据es数据库排名第8。下面我们介绍一下es数据适用的场景：

ES作为网站的主要后端系统：比如博客的数据直接在es上进行检索。
作为大数据分析的承载工具：数据进行hadoop生态处理后，可以输入es中数据库提供查询。
数据分析
机器学习

es和传统的数据库的概念有着对应关系：

关系型数据库	ES
Table	Index(Type)
Row	Document
Column	Field
Schema	Mapping
SQL	DSL

解释一下：es中的表称为索引、行称为文档、列称为域等。

2.2 elasticsearch特点

这里介绍一下es的特点，es作为NoSQL数据库代表之一，非常适合于非结构化文档类数据存储、更创新支持智能分词匹配模糊查询。特点如下：

分布式的文件存储，每个字段都被索引且可用于搜索。
分布式的实时分析搜索引擎，海量数据下近实时秒级响应。
简单的restful api，天生的兼容多语言开发。
易扩展，处理PB级结构化或非结构化数据。

3. clickhouse和elasticsearch对比

3.1 两者的分布式架构

Elasticsearch采用的是主备同步机制，由主节点负责同步到备节点，这种方式会更加简单高效。
ClickHouse引入了外置的ZooKeeper集群，来进行分布式DDL任务、主备同步任务等操作的下发。多副本之间的数据同步（data shipping）任务下发也是依赖于ZooKeeper集群，但最终多副本之间的数据传输还是通过Http协议来进行点对点的数据拷贝，同时多副本都可写，数据同步是完全多向的，对用户的易用性略差，用户门槛相对较高。

3.2 存储架构

Elasticsearch会将数据先写入内存，然后隔一段时间将内存数据写入磁盘，是一个接近实时的系统。
ClickHouse是直接使用磁盘进行读写。

在数据‘写的快‘这方面Elasticsearch更快，但是在写入吞吐能力上ClickHouse更强。

3.3 查询架构

Elasticsearch是一个搜索引擎，而搜索引擎能处理的查询复杂度是确定的、有上限的，所有的搜索查询经过确定的若干个阶段就可以得出结果。它完全不具备数据库计算引擎的流式处理能力，它是完全回合制的request-response数据处理。当用户需要返回的数据量很大时，就很容易出现查询失败，或者触发GC。一般来说Elasticsearch的搜索引擎能力上限就是两阶段的查询，像多表关联这种查询是完全超出其能力上限的。
ClickHouse的计算引擎特点则是极致的向量化，完全用c++模板手写的向量化函数和aggregator算子使得它在聚合查询上的处理性能达到了极致。配合上存储极致的并行扫描能力，轻松就可以把机器资源跑满。

尤其是ClickHouse支持SQL而Elasticsearch用的是DSL(难懂、难上手)

3.4 总结

Elasticsearch只有在完全搜索场景下面（where过滤后的记录数较少），并且内存足够的运行环境下，才能展现出并发上的优势。而在分析场景下（where过滤后的记录数较多），ClickHouse凭借极致的列存和向量化计算会有更加出色的并发表现。两者的侧重不同而已，同时ClickHouse并发处理能力立足于磁盘吞吐，而Elasticsearch的并发处理能力立足于内存Cache。ClickHouse更加适合低成本、大数据量的分析场景，它能够充分利用磁盘的带宽能力。