简述

首先，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。