Clickhouse&Elasticsearch介绍
Clickhouse是俄罗斯搜索巨头Yandex开发的完全列式存储计算的分析型数据库。ClickHouse在这两年的OLAP领域中一直非常热门,国内互联网大厂都有大规模使用。Elasticsearch是一个近实时的分布式搜索分析引擎,它的底层存储完全构建在Lucene之上。简单来说是通过扩展Lucene的单机搜索能力,使其具有分布式的搜索和分析能力。
今天很多用户在实际的业务场景中,常常面对ClickHouse和Elasticsearch技术选型的难题。本文将通过功能对比和性能测试的手段对比两者的优劣之处并进行选型,同时会附上一份覆盖多场景的测试报作为参考。
Clickhouse vs Elasticsearch
类别 |
Elasticsearch |
Clickhouse |
|
导入方式 |
MQ导入 |
内置支持kafka, 插件插件plusar |
内置支持 kafka, 插件支持plusar |
JDBC导入 |
内置支持 |
内置支持 |
|
用户导入 |
Rest API |
HTTP接口/JDBC |
|
存储架构 |
数据分区 |
时间分区,字段分区 |
支持多个分区字段 |
数据分桶 |
支持主键Hash分桶 |
支持分片 |
|
多副本 |
支持多副本设置 |
支持副本表 |
|
字段类型 |
结构化 |
结构化 |
|
压缩 |
LZ4,Deflate |
LZ4,ZSTD |
|
存储引擎 |
行/列/倒排索引 |
行存/稀疏索引 |
|
存储压缩比 | 一般 | 高 | |
计算能力 |
向量化计算 |
不支持 |
支持 |
并发能力 |
< ~100 |
< ~100 |
|
写入性能 |
3000/s |
3.5w/s |
|
谓词下推 |
弱 |
一般 |
|
JOIN |
不支持 |
支持BroadCast Join |
|
物化视图(预计算) | 不支持 | 支持 | |
自定义函数 |
不支持 |
支持 |
|
全文搜索 |
支持 |
不支持 |
|
扩展性 |
协议 |
JDBC/ODBC/RESTAPI协议 |
JDBC/ODBC/HTTP协议 |
SQL协议 |
DSL为主,SQL兼容性差 |
兼容标准SQL协议 |
|
动态列 | 支持 | 不支持 | |
存储分离 |
不支持 |
不支持 |
|
数据备份 |
支持快照,定时备份 |
第三方工具开 |
|
扩缩容 |
需要Reblance数据文章来源地址https://www.toymoban.com/news/detail-852121.html文章来源:https://www.toymoban.com/news/detail-852121.html |
需要Reblance数据 |
ClickHouse与ES的对比优缺点
优点:
- ClickHouse写入吞吐量大,单服务器日志写入量在50MB到200MB/s,每秒写入超过60w记录数,是ES的5倍以上。
- clickhouse的计算框架,支持向量化引擎,以及自低向上的极致算法层面优化,在OLAP场景下可以最大限度的压榨CPU IO等性能,对比ES存在明显优势。
- clickhouse支持雾化视图和语句算功能,对于固定的统计分析场景可以将耗时从十几秒下降到几十毫秒级别级别
- ClickHouse比ES服务器成本更低。一方面ClickHouse的数据压缩比比ES高(行列存储索引的存在),相同数据占用的磁盘空间只有ES的1/3~1/30,节省了磁盘空间的同时,也能有效的减少磁盘IO;另一方面ClickHouse比ES占用更少的内存,更高效的利用CPU资源。
- 相比ES,ClickHouse稳定性更高,运维成本更低。ES中不同的Group负载不均衡,有的Group负载高,会导致写Rejected等问题,需要人工迁移索引;在ClickHouse中通过集群和Shard策略,采用轮询写的方法,可以让数据比较均衡的分布到所有节点。
- ES中一个大查询可能导致OOM的问题;ClickHouse通过预设的查询限制,会查询失败,不影响整体的稳定性。
- ClickHouse采用SQL语法,比ES的DSL更加简单,新用户学习成本更低。
缺点:
- 由于是列式数据库,且只支持稀疏索引(bloom fliter),不具备倒排索引功能,无法像ES一样提供同样的全文检索能力。
- 无法动态添加字段,需要提前定义好表schema。
到了这里,关于Clickhouse & Elasticsearch 选型对比的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!