1 はじめに
ClickHouse は、2016 年にロシアの Yandex によってオープンソース化されたオンライン分析処理(OLAP: オンライン分析処理) MPPアーキテクチャ用の列型ストレージ データベース(DBMS: データベース管理システム)です。SQL クエリを使用して分析データ レポートをリアルタイムで生成できます。ClickHouse の正式名称は、Click Stream、Data WareHouse です。
2. クリックハウスの特徴
線形拡張をサポートするオープンソースのカラム ストレージ データベース管理システムで、シンプルで便利、信頼性が高く、
高速フォールト トレラントの実行スコア: Vertica の 5 倍、Hive の 279 倍、MySQL の 800 倍の速さです。処理できるレベルは10億レベルに達しました
多機能：さまざまなシナリオのデータ統計分析のサポート、SQLのようなクエリのサポート、リモートレプリケーションの展開
3. ClickHouse はなぜ速いのですか?
1. データ圧縮. Clickhouse は列型ストレージ データベースです。データの各列は lz4 によって圧縮されています。列データ間の繰り返しが非常に高いため、非常に優れた圧縮率を持っています。データの列をクエリするとき、スキャン速度が向上します。非常に高速であるため、クリックハウスは非常に高いデータ圧縮率 (20%) を実現できます。
2. CPU 命令レベルでの最適化では、多数のベクトル化された演算命令が使用され、CPU の L1、L2、および L3 キャッシュを使用してメモリまたはディスクの読み取り動作を最小限に抑えることが非常に得意です。
3. 異なるシナリオでは異なるアルゴリズムやデータ構造が使用されます。たとえば、データ量が少ない場合は配列配列に格納され、データのサイズが中程度である場合はハッシュセット構造に格納されます。データが大きい場合、ハイパーログログ構造に保存されます。
4.マージ ツリー テーブル エンジン、集約マージ ツリー テーブル エンジン、メモリ テーブル エンジンなどのさまざまなテーブル エンジン。さまざまなアプリケーション シナリオでさまざまなテーブル エンジンを使用して、パフォーマンスを向上させることができます。
文字列検索のアルゴリズム選択など、内部の高性能アルゴリズムを使用する場合、クリックハウスは最速のアルゴリズムを選択します。
4. クリックハウスのメリット・デメリットのご紹介
アドバンテージ：
CPU を効率的に使用するために、データは列に格納されるだけでなく、ベクトルでも処理されます。
データ圧縮には大きなスペースがあり、IO が削減されます。単一クエリを高スループットで処理するため、各サーバーは 1 秒あたり最大数十億行に達します。
インデックスは B ツリー構造ではないため、フィルター条件がインデックス列に含まれていれば、左端の原則を満たす必要はありません。使用中のデータがインデックスに含まれていない場合でも、さまざまな並列処理により、 ClickHouse のフル テーブル スキャン速度は非常に高速です。
書き込み速度は非常に速く、行あたり 100Byte に基づいて見積もると 50 ～ 200M/s で、これは 50W ～ 200W/s の書き込み速度とほぼ同等です。大量のデータ更新に非常に適しています。
欠点:
トランザクションをサポートしません。
高い同時実行性はサポートされていません。公式の推奨値は 100 qps です。サーバーが十分に優れている場合は、構成ファイルを変更することで接続数を増やすことができます。
SQL は日常的に使用される文法の 80% 以上を満たしており、結合の記述方法は非常に特殊であり、最新バージョンではすでに SQL と同様の結合をサポートしていますが、パフォーマンスは良好ではありません。
ClickHouse の最下層で非同期データのマージが継続され、クエリのパフォーマンスに影響を与えるため、1,000 を超えるレコードをバッチで書き込むようにし、行ごとまたは小さなバッチの挿入、更新、削除操作を避けてください。可能な限り回避するために、リアルタイムのデータ書き込みが行われます。
ClickHouse は並列処理メカニズムを採用しているため高速です。クエリでも実行にサーバーの CPU の半分が使用されるため、ClickHouse は同時実行性の高い使用シナリオをサポートできません。デフォルトでは、1 つのクエリで使用される CPU コアの数はサーバー コアの数の半分。サーバー コアの数は自動的に識別され、このパラメータは構成ファイルを通じて変更できます。
5. 拡張: カラムナ型ストレージ データベースとは何ですか
従来の行ベースのデータベース システムでは、データは次の順序で保存されます。
行 |
ウォッチID |
Java有効化 |
タイトル |
グッドイベント |
イベント時間 |
#0 |
89354350662 |
1 |
投資家向け広報 |
1 |
2016-05-18 05:19:20 |
#1 |
90329509958 |
0 |
Contact us |
1 |
2016-05-18 08:10:20 |
#2 |
89953706054 |
1 |
Mission |
1 |
2016-05-18 07:38:00 |
#N |
… |
… |
… |
… |
… |
处于同一行中的数据总是被物理的存储在一起。
常见的行式数据库系统有：MySQL、Postgres和MS SQL Server。
在列式数据库系统中，数据按如下的顺序存储：
Row: |
#0 |
#1 |
#2 |
#N |
WatchID: |
89354350662 |
90329509958 |
89953706054 |
… |
JavaEnable: |
1 |
0 |
1 |
… |
Title: |
Investor Relations |
Contact us |
Mission |
… |
GoodEvent: |
1 |
1 |
1 |
… |
EventTime: |
2016-05-18 05:19:20 |
2016-05-18 08:10:20 |
2016-05-18 07:38:00 |
… |
这些示例只显示了数据的排列顺序。来自不同列的值被单独存储，来自同一列的数据被存储在一起。
常见的列式数据库有： Vertica、 Paraccel (Actian Matrix，Amazon Redshift)、 Sybase IQ、 Exasol、 Infobright、 InfiniDB、 MonetDB (VectorWise， Actian Vector)、 LucidDB、 SAP HANA、 Google Dremel、 Google PowerDrill、 Druid、 kdb+。
不同的数据存储方式适用不同的业务场景，数据访问的场景包括：进行了何种查询、多久查询一次以及各类查询的比例；每种类型的查询(行、列和字节)读取多少数据；读取数据和更新之间的关系；使用的数据集大小以及如何使用本地的数据集；是否使用事务,以及它们是如何进行隔离的；数据的复制机制与数据的完整性要求；每种类型的查询要求的延迟与吞吐量等等。
系统负载越高，依据使用场景进行定制化就越重要，并且定制将会变的越精细。没有一个系统能够同时适用所有不同的业务场景。如果系统适用于广泛的场景，在负载高的情况下，要兼顾所有的场景，那么将不得不做出选择。是要平衡还是要效率？
6.OLAP场景的关键特征
绝大多数是读请求
数据以相当大的批次(> 1000行)更新，而不是单行更新;或者根本没有更新。
已添加到数据库的数据不能修改。
对于读取，从数据库中提取相当多的行，但只提取列的一小部分。
宽表，即每个表包含着大量的列
查询相对较少(通常每台服务器每秒查询数百次或更少)
对于简单查询，允许延迟大约50毫秒
列中的数据相对较小：数字和短字符串(例如，每个URL 60个字节)
处理单个查询时需要高吞吐量(每台服务器每秒可达数十亿行)
事务不是必须的
对数据一致性要求低
每个查询有一个大表。除了他以外，其他的都很小。
查询结果明显小于源数据。换句话说，数据经过过滤或聚合，因此结果适合于单个服务器的RAM中
很容易可以看出，OLAP场景与其他通常业务场景(例如,OLTP或K/V)有很大的不同， 因此想要使用OLTP或Key-Value数据库去高效的处理分析查询场景，并不是非常完美的适用方案。例如，使用OLAP数据库去处理分析请求通常要优于使用MongoDB或Redis去处理分析请求。
7.列式数据库更适合OLAP场景的原因
列式数据库更适合于OLAP场景(对于大多数查询而言，处理速度至少提高了100倍)，下面详细解释了原因(通过图片更有利于直观理解)：
行式
列式
看到差别了么？下面将详细介绍为什么会发生这种情况。
输入/输出
针对分析类查询，通常只需要读取表的一小部分列。在列式数据库中你可以只读取你需要的数据。例如，如果只需要读取100列中的5列，这将帮助你最少减少20倍的I/O消耗。
由于数据总是打包成批量读取的，所以压缩是非常容易的。同时数据按列分别存储这也更容易压缩。这进一步降低了I/O的体积。
由于I/O的降低，这将帮助更多的数据被系统缓存。
例如，查询«统计每个广告平台的记录数量»需要读取«广告平台ID»这一列，它在未压缩的情况下需要1个字节进行存储。如果大部分流量不是来自广告平台，那么这一列至少可以以十倍的压缩率被压缩。当采用快速压缩算法，它的解压速度最少在十亿字节(未压缩数据)每秒。换句话说，这个查询可以在单个服务器上以每秒大约几十亿行的速度进行处理。这实际上是当前实现的速度。
8.性能对比图
9.clickhouse安装
https://blog.csdn.net/2301_76154806/article/details/128781183
安装完成后使用dbeaver连接测试.