ClickHouse(一)-基础介绍以及表引擎

文章目录

    • 1 相关概念
      • 1.1 定义
      • 1.2 特点:
      • 1.3 优势(自夸)
      • 1.4 高效的硬件使用
      • 1.5 功能丰富的SQL语法支持:
      • 1.6 线性的扩展:
      • 1.7 缺点:
      • 1.8 CK的使用场景:
    • 2 单点搭建
      • 2.1 快速安装:
      • 2.2 官网教程;
    • 3 库引擎
      • 3.1 ordinary引擎
      • 3.2 dictionary引擎
      • 3.3 memory引擎
      • 3.4 MySQL引擎
      • 3.5 Lazy延时引擎
    • 4 表引擎
      • 4.1 作用
      • 4.2 类型
        • 4.2.1 mergetree
        • 4.2.2 log
        • 4.2.3 Integration
        • 4.2.4 special

1 相关概念

1.1 定义

是一款开源的面向列的允许使用sql实时的生成分析报告的ROLAP数据库

1.2 特点:

  • 分布式:大数据分布式服务该有的优点都有,c++编程
  • 火一样的速度: ck会利用硬件所有可用的资源去处理每个查询请求(故并发不行,最高100),针对列存储数据读取每秒最高可达2T
  • 容错:支持多master异步副本,每个节点都是相等的,可避免单点故障
  • 容易使用:开箱即用,使用sql进行分析
  • 高可用:可配置分布式的,单点故障不影响使用

1.3 优势(自夸)

它比传统OLAP数据库快100-1000倍,其计算性能远超现有的任何一款面向列式存储的数据库,单台机器每秒处理十几亿到几十亿的字节数据,具体指标可观看:官网性能对比,确实是当前市面上最最最高效的单表分析OLAP引擎(真话)

1.4 高效的硬件使用

磁盘、cpu .相较于传统的列式存储使用同样的磁盘和cpu,其典型sql分析速度快2到3个量级,即使是使用普通的机械硬盘也不会对查询性能有多大的影响,降低使用固态盘成本.

  • 高效的CPU使用: 矢量化的sql查询动态生成代码在处理列式数据中大大提高CPU的命令中率
  • 高效的磁盘驱访问:通过记录连续存储的数据引用位置,ck最大限度减少范围查询的搜索次数,提高了机械硬盘的驱动器的效率
  • 最小化的数据传输:因为是列式存储故,每次计算查询所涉及的到的数据仅仅是计算相关的字段,无需使用大宽带进行数据传输计算(个人觉得还是大宽带香,万一全列扫描呢)

1.5 功能丰富的SQL语法支持:

  • 除列支持基本的RDBMS常见操作,还内置列很多高效的适合OLAP场景的功能函数
  • 由于是列式存储,故支持表列数达到上千列而不影响查询和计算的性能,可通过数组、元组、嵌套结构类型将非规范化的数据进行打包
  • 丰富的的table join功能,它不仅能ck集群的数据,也可join外部数据源的数据.
  • 可近似的查询数据,用户可在结果的准确性以及计算耗时之间进行选择权衡

1.6 线性的扩展:

ck在水平扩展(增加实例扩充机器)以及垂直扩展(增加单机配置)都表现的很好,可在单个服务器上执行,单点数据量可超过万亿行数百T,yandex的ck集群远远超过1000个节点

1.7 缺点:

  • 没有完成的事物支持(支持部分事物)

  • 3.2 稀疏索引导致ck不擅长细粒度或kv类型数据的查询需求-稀疏索引导致查询某条数据时直接查询那一批数据

  • 缺少高频率、低延时的修改或删除数据的能力.仅能用于批量删除或修改数据-即实时高效写入能力比较弱

  • 不擅长join操作

  • 低并发,并发很难超过100,通常是个位数

1.8 CK的使用场景:

  • 用于分析干净.结构化的、不可变得的事件流或者日志流,建议将这种流放在一个带有预连接的维度的大宽表中.(个人理解是数据做过清洗,且无删除或更新操作的业务数据或者日志数据)
  • 适用场景: 网络和应用分析,广告网络和RTB,电信,电子商务和金融,信息安全,监测和遥测,时间序列,商业智能,在线游戏,物联网
  • 不适用场景:OLTP、Blob或文件存储、高并发的kv查询

2 单点搭建

2.1 快速安装:

快速启动,(外事问google)踩坑centos7系统启动任务需要使用 systemctl start clickhouse-server方式

2.2 官网教程;

官网教程支持中文

3 库引擎

ck有库引擎和表引擎两种,库引擎是创建库时指定的引擎

3.1 ordinary引擎

默认的引擎,支持所有的表引擎 – 生产通常使用这种引擎

3.2 dictionary引擎

字典引擎,此数据库会自动为所有数据字典创建表

3.3 memory引擎

所有数据只会保存在内存中,服务重启数据丢失,该库只能使用memory表引擎

3.4 MySQL引擎

该引擎会自动拉取远端mysql中数据,并在该库下创建mysql表引擎的数据表

3.5 Lazy延时引擎

将最近一次访问间隔时间段内的数据放在内存中,仅使用log引擎表 --适用于连续频繁访问同一批的数据

4 表引擎

表引擎在ck中十分中要,不同的表引擎具有不同的特性

4.1 作用

不同的表引擎决定了数据的存储方式以及位置 --有的表引擎的数据在内存,有的在磁盘

  • 支持哪些查询以及如何查询 – 只有mergetree表引擎支持所有的标准的sql语法
  • 是否支持并发访问
  • 是否支持索引
  • 是否可以支持多线程请求
  • 是否支持数据的复制

4.2 类型

4大类,28种小类(扩展:mysql引擎常见9种,几乎用inodb,其它如memory、MyISAMD、Active等)

4.2.1 mergetree

MergeTree(海量数据分析用到的最多的引擎,几乎支持所有的ck核心功能)、Data Replication、custom partitionning key、 replacingMergeTree…GrapHitemergeTree 等都是基于MergeTree衍生而来的

  • 衍生公式: replicated ->Replacing、Summing、Aggregating、Collapsing、VersionedCollapsing、Graghite -> MergeTree

4.2.2 log

stripelog、Log、special 用来做小表(少于一百万行)的数据分析,数据是存储磁盘,写入时是文件追加、不支持索引、不支持突变操作(DDL)

4.2.3 Integration

kafka、MySQL、JDBC、ODBC、HDFS, 数据依旧存储在上述的外部存储介质中(类似于hive中创建HBase的映射表),只是使用ck的计算引擎进行分析

4.2.4 special

Null(所有往这样表插入的数据都是空,用于测试语句完整性)、merge(可以将多张表逻辑合并成一张,要求表结构完全一致)、View、MaterializedView、File、Set、URL、dictionary、external data、distributed、join

你可能感兴趣的:(ClickHouse,数据库,大数据,ROLAP,ClickHouse,c++)