mysql落地方案,SIEM落地方案：初识ClickHouse

简述

首先，ELK是支持SIEM，一开始我也是用ELK进行数据收集、数据展示和数据分析，但是逐渐到后面，有一些功能需求使用查询语句是非常复杂，虽然ELK提供云SIEM，但是作为动手能力非常强的人(穷)，就有放弃ELK这个想法。

后来某大佬说clickhouse非常香，于是就开始去了解这个东西。

clickhouse(以下简称CH)是列式数据库，作为数据库小白，当然要查询一下与传统行式数据库的区别，看起来好像列式数据库很厉害。

下图是官方对于行式和列式数据库查询的对比，可以看到行式是扫描全表，而列式数据库是直接找到相关列的数据，查询速度不言而喻。

说明一下，应用场景不同采用的架构方案不同。为什么CH会适合做SIEM呢？咱们看看官方对于CH功能特点描述

OLAP场景的关键特征大多数是读请求(siem展示就是查询语句去查询，所以大多数是读请求)

数据总是以相当大的批(> 1000 rows)进行写入(成千上万服务器的日志量存储怕不止1千行吧)

不修改已添加的数据(siem就是要日志存储，要修改他数据干嘛)

每次查询都从数据库中读取大量的行，但是同时又仅需要少量的列(查询特定列的大量行内容)

宽表，即每个表包含着大量的列(对的，有大量的字段，这边字段有上百个)

较少的查询(确实不多，siem展示的SQL也不超过几百条查询语句)

对于简单查询，允许延迟大约50毫秒(这个是允许的，相对于ES查询，这个真香)

列中的数据相对较小：

数字和短字符串(例如，每个URL 60个字节)

处理单个查询时需要高吞吐量(每个服务器每秒高达数十亿行)

事务不是必须的(不用做事务操作)

对数据一致性要求低(这块还没有研究，目前没这个需求，以后出现再补回来)

每一个查询除了一个大表外都很小

查询结果明显小于源数据，(数据被过滤或聚合后能够被盛放在单台服务器的内存中)

那么按照这些关键特征，很满足咱们对于siem存储和查询的功能，接下来就实战看看是不是如此。

安装

官方有yum源，可以直接通过yum进行安装。

导入仓库地址信息sudo yum install yum-utilssudo rpm --import https://repo.clickhouse.tech/CLICKHOUSE-KEY.GPGsudo yum-config-manager --add-repo https://repo.clickhouse.tech/rpm/stable/x86_64

安装CH服务端和客户端。sudo yuminstall clickhouse-server clickhouse-client

安装之后，启动服务/etc/init.d/clickhouse-serverstart

使用客户端进行进去，默认是走9000端口通信，并且没有密码认证

实战

CH核心是数据引擎，也就是table处理方法，我这边使用TinyLog和MergeTree，前者存储数据量最好不能过百万，用来做一些表的对比和记录；后者是可以做基于时间的时序数据库，用来后面grafana展示使用的。具体的细节可以参考这边文章：ClickHouse 快速入门开发

我这边补充一下细节，测试发现CH不支持存储过程，假如要写递归功能，抱歉不支持。不过CH定义了递归功能，针对于找爸爸的功能(子ID找父ID)，说实话这个功能还是有缺陷的，测试发现，量大会出现找爸爸错误。

CH查询语句跟MYSQL差不多，大体上是一致的，不同的地方可以翻文档查

按照官方文档，我下载了他们脱敏的数据库，导入进去，有两个表。

查看其中一个表结构，都有133个列

我这边测试机器是双核8G虚拟机，查询速度3亿行数据，需要1分钟，因为列式数据库是吃内存的，所以内存越大查询速度越快。

查询两个列，可以看到速度简直无敌

聚合查询也是如此

声明：本文来自FreeBuf，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。