clickhouse
what‘s it
面向列的數(shù)據(jù)庫管理系統(tǒng)，可用于olap
ClickHouse允許在運(yùn)行時(shí)創(chuàng)建表和數(shù)據(jù)庫，加載數(shù)據(jù)和運(yùn)行查詢，而無需重新配置和重新啟動(dòng)服務(wù)器。
數(shù)據(jù)壓縮
LZ4和ZSTD
好處：節(jié)省空間，降低網(wǎng)絡(luò)IO，磁盤IO
壞處：內(nèi)存中解壓縮，增大cpu負(fù)載，查詢同樣不壓縮的數(shù)據(jù)性能相比較會(huì)有所下降
參考文章
多核心并行處理
簡(jiǎn)言之就是支持任務(wù)并行處理，并行度取決整個(gè)集群的core的數(shù)量。利用可利用的一切資源去執(zhí)行任務(wù)
較為支持sql
支持的查詢包括 GROUP BY，ORDER BY，IN，JOIN以及非相關(guān)子查詢。不支持窗口函數(shù)和相關(guān)子查詢。
向量搜索引擎
這個(gè)比較復(fù)雜，采用knn，kdtree等算法。
好處就是在精度不做特別要求時(shí)，速度要快
壞處就是消耗更多的資源
適用于topn場(chǎng)景
參考
支持索引
按照主鍵對(duì)數(shù)據(jù)進(jìn)行物理排序
在線計(jì)算
即現(xiàn)查現(xiàn)算
近似計(jì)算
用于近似計(jì)算的各類聚合函數(shù)，如：distinct values, medians, quantiles
基于數(shù)據(jù)的部分樣本進(jìn)行近似查詢。這時(shí)，僅會(huì)從磁盤檢索少部分比例的數(shù)據(jù)。
不使用全部的聚合條件，通過隨機(jī)選擇有限個(gè)數(shù)據(jù)聚合條件進(jìn)行聚合。這在數(shù)據(jù)聚合條件滿足某些分布條件下，在提供相當(dāng)準(zhǔn)確的聚合結(jié)果的同時(shí)降低了計(jì)算資源的使用。
限制
1.沒有完整的事務(wù)支持。2.缺少高頻率，低延遲的修改或刪除已存在數(shù)據(jù)的能力。僅能用于批量刪除或修改數(shù)據(jù)，但這符合 GDPR。3.稀疏索引使得ClickHouse不適合通過其鍵檢索單行的點(diǎn)查詢。
ps :ck是數(shù)據(jù)庫管理系統(tǒng)不是數(shù)據(jù)庫
how to use
安裝
sudo yum install yum-utilssudo rpm --import https://repo.clickhouse.tech/CLICKHOUSE-KEY.GPGsudo yum-config-manager --add-repo https://repo.clickhouse.tech/rpm/clickhouse.reposudo yum install clickhouse-server clickhouse-clientsudo /etc/init.d/clickhouse-server startclickhouse-client
常用運(yùn)維命令
clickhouse start｜stop｜restart
clickhouse-client
日志路徑
/var/log/clickhouse-server/
常見問題
啟動(dòng)失敗
· 端口沖突，需要修改，修改文件conf.xml
需要設(shè)置密碼和登錄端口
常用配置文件 user.xml conf.xml
· 開啟遠(yuǎn)程訪問需要修改conf.xml
· 設(shè)置密碼需要修改user.xml
web訪問
http://ui.tabix.io/#!/sql
接口層
jdbc/odbc
clickhouse-client
mysql
· 即通過mysql客戶端工具鏈接ck
· 參考
http客戶端
· 即restapi操作
· 參考
第三方
tabix
https://clickhouse.tech/docs/en/interfaces/third-party/integrations/
HouseOps
DBeaver
DataGrip
數(shù)據(jù)格式
最為常見的就是csv格式，其他的見官網(wǎng)
引擎
概述
· 一般在創(chuàng)建數(shù)據(jù)庫的時(shí)候不指定引擎,默認(rèn)使用的就是clickhouse自己的引擎,也可以指定使用mysql的引擎,就是可以在clickhouse中調(diào)用mysql 中的數(shù)據(jù),進(jìn)行查詢,也可以使用 lazy引擎.
數(shù)據(jù)庫引擎
· 延時(shí)引擎Lazy
? CREATE DATABASE testlazy ENGINE = Lazy(expiration_time_in_seconds);
? 日志引擎，在該數(shù)據(jù)庫下只能創(chuàng)建 log 系列引擎的表
· MySQL
? MySQL引擎用于將遠(yuǎn)程的MySQL服務(wù)器中的表映射到ClickHouse中，并允許對(duì)表進(jìn)行INSERT和SELECT查詢MySQL數(shù)據(jù)庫引擎會(huì)將對(duì)其的查詢轉(zhuǎn)換為MySQL語法并發(fā)送到MySQL服務(wù)器中，可以執(zhí)行諸如SHOW TABLES或SHOW CREATE TABLE之類的操作。無法對(duì)其執(zhí)行以下操作：RENAMECREATE TABLEALTER
? CREATE DATABASE [IF NOT EXISTS] db_name [ON CLUSTER cluster]ENGINE = MySQL('host:port', ['database' | database], 'user', 'password')
? host:port — 鏈接的MySQL地址。database — 鏈接的MySQL數(shù)據(jù)庫。user — 鏈接的MySQL用戶。password — 鏈接的MySQL用戶密碼
· Ordinary
? 默認(rèn)引擎
? 在這種數(shù)據(jù)庫下面的表可以是任意類型引擎。
· Dictionary
? 字典引擎，此類數(shù)據(jù)庫會(huì)自動(dòng)為所有數(shù)據(jù)字典創(chuàng)建它們的數(shù)據(jù)表（加載配置文件中配置的字段表信息和數(shù)據(jù)）
· Memory
? 內(nèi)存引擎，用戶存放臨時(shí)數(shù)據(jù)，數(shù)據(jù)只會(huì)在內(nèi)存中，不會(huì)涉及任何磁盤操作，當(dāng)服務(wù)重啟后數(shù)據(jù)會(huì)清空。并且對(duì)表引擎也有限制，只能使用memory類型表引擎。
? 所有數(shù)據(jù)只會(huì)保存在內(nèi)存中,服務(wù)重啟數(shù)據(jù)消失.
表引擎
· log系列
? log系列表引擎功能相對(duì)簡(jiǎn)單，主要用于快速寫入小表（1百萬行左右的表），然后全部讀出的場(chǎng)景
? 表引擎的共性是：數(shù)據(jù)被順序append寫到磁盤上；不支持delete、update；不支持index；不支持原子性寫；insert會(huì)阻塞select操作。
? TinyLog
? 不支持并發(fā)讀取數(shù)據(jù)文件，查詢性能較差；格式簡(jiǎn)單，適合用來暫存中間數(shù)據(jù)；
? create table test(a UInt16 ,b string) ENGINE =TinyLog
? StripLog
? 支持并發(fā)讀取數(shù)據(jù)文件，查詢性能比TinyLog好；將所有列存儲(chǔ)在同一個(gè)大文件中，減少了文件個(gè)數(shù)；
? create table test(a UInt16 ,b string) ENGINE =StripLog
? Log
? 支持并發(fā)讀取數(shù)據(jù)文件，查詢性能比TinyLog好；每個(gè)列會(huì)單獨(dú)存儲(chǔ)在一個(gè)獨(dú)立文件中
? create table test(a UInt16 ,b string) ENGINE =Log
· Integration系列
? Kafka
? 將Kafka Topic中的數(shù)據(jù)直接導(dǎo)入到ClickHouse；
? create table test(a UInt16 ,b string)ENGINE=Kafka SETTINGS kafka_broker_list='localhost:9092',kafak_topic_list='topic',kafka_group_name='groupname',kafka_formta='JSONEachRow',kafka_num_consumers=4
? MySQL
? 將Mysql作為存儲(chǔ)引擎，直接在ClickHouse中對(duì)MySQL表進(jìn)行select等操作；
? create table test(a UInt16 ,b string) ENGINE=MySQL('localhost:3306',''databases',username','password',)
? JDBC/ODBC
? 通過指定jdbc、odbc連接串讀取數(shù)據(jù)源；
? create table test(a UInt16 ,b string)ENGINE =ODBC('DSN=mysqlconn','test','test')
? create table test(a UInt16 ,b string)ENGINE =JDBC('jdbc:mysql://localhost:3306/?'user=username&password=password ,'test','test')
? HDFS
? 直接讀取HDFS上的特定格式的數(shù)據(jù)文件；
? create table test(a UInt16 ,b string) ENGINE=HDFS('hdfs://clustername:9000/data','TSV')
· MergeTree系列
? MergeTree
? ReplacingMergeTree
? CollapsingMergeTree
? VersionedCollapsingMergeTree
? SummingMergeTree
? AggregatingMergeTree
? 詳情點(diǎn)擊
· Special系列
? Memory
? 將數(shù)據(jù)存儲(chǔ)在內(nèi)存中，重啟后會(huì)導(dǎo)致數(shù)據(jù)丟失。查詢性能極好，適合于對(duì)于數(shù)據(jù)持久性沒有要求的1億一下的小表。在ClickHouse中，通常用來做臨時(shí)表。
? Buffer
? 為目標(biāo)表設(shè)置一個(gè)內(nèi)存buffer，當(dāng)buffer達(dá)到了一定條件之后會(huì)flush到磁盤。
? File
? 直接將本地文件作為數(shù)據(jù)存儲(chǔ)；
? Null
? 寫入數(shù)據(jù)被丟棄、讀取數(shù)據(jù)為空；
SQL
https://clickhouse.tech/docs/zh/sql-reference/syntax/
how to work
架構(gòu)
向量化執(zhí)行引擎
[圖片上傳失敗...(image-5f11cd-1609924266376)]
· 向量化執(zhí)行，可以簡(jiǎn)單地看作一項(xiàng)消除程序中循環(huán)的優(yōu)化。這里用一個(gè)形象的例子比喻。小胡經(jīng)營(yíng)了一家果汁店，雖然店里的鮮榨蘋果汁深受大家喜愛，但客戶總是抱怨制作果汁的速度太慢。小胡的店里只有一臺(tái)榨汁機(jī)，每次他都會(huì)從籃子里拿出一個(gè)蘋果，放到榨汁機(jī)內(nèi)等待出汁。如果有8個(gè)客戶，每個(gè)客戶都點(diǎn)了一杯蘋果汁，那么小胡需要重復(fù)循環(huán)8次上述的榨汁流程，才能榨出8杯蘋果汁。如果制作一杯果汁需要5分鐘，那么全部制作完畢則需要40分鐘。為了提升果汁的制作速度，小胡想出了一個(gè)辦法。他將榨汁機(jī)的數(shù)量從1臺(tái)增加到了8臺(tái)，這么一來，他就可以從籃子里一次性拿出8個(gè)蘋果，分別放入8臺(tái)榨汁機(jī)同時(shí)榨汁。此時(shí)，小胡只需要5分鐘就能夠制作出8杯蘋果汁。為了制作n杯果汁，非向量化執(zhí)行的方式是用1臺(tái)榨汁機(jī)重復(fù)循環(huán)制作n次，而向量化執(zhí)行的方式是用n臺(tái)榨汁機(jī)只執(zhí)行1次。
· 為了實(shí)現(xiàn)向量化執(zhí)行，需要利用CPU的SIMD指令。SIMD的全稱是Single Instruction Multiple Data，即用單條指令操作多條數(shù)據(jù)?，F(xiàn)代計(jì)算機(jī)系統(tǒng)概念中，它是通過數(shù)據(jù)并行以提高性能的一種實(shí)現(xiàn)方式 ( 其他的還有指令級(jí)并行和線程級(jí)并行 )，它的原理是在CPU寄存器層面實(shí)現(xiàn)數(shù)據(jù)的并行操作。在計(jì)算機(jī)系統(tǒng)的體系結(jié)構(gòu)中，存儲(chǔ)系統(tǒng)是一種層次結(jié)構(gòu)。典型服務(wù)器計(jì)算機(jī)的存儲(chǔ)層次結(jié)構(gòu)如圖1所示。一個(gè)實(shí)用的經(jīng)驗(yàn)告訴我們，存儲(chǔ)媒介距離CPU越近，則訪問數(shù)據(jù)的速度越快
· 從上圖中可以看到，從左向右，距離CPU越遠(yuǎn)，則數(shù)據(jù)的訪問速度越慢。從寄存器中訪問數(shù)據(jù)的速度，是從內(nèi)存訪問數(shù)據(jù)速度的300倍，是從磁盤中訪問數(shù)據(jù)速度的3000萬倍。所以利用CPU向量化執(zhí)行的特性，對(duì)于程序的性能提升意義非凡。
多線程與分布式
多主架構(gòu)
數(shù)據(jù)分片與分布式查詢
· 數(shù)據(jù)分片是將數(shù)據(jù)進(jìn)行橫向切分，這是一種在面對(duì)海量數(shù)據(jù)的場(chǎng)景下，解決存儲(chǔ)和查詢瓶頸的有效手段，是一種分治思想的體現(xiàn)。ClickHouse支持分片，而分片則依賴集群。每個(gè)集群由1到多個(gè)分片組成，而每個(gè)分片則對(duì)應(yīng)了ClickHouse的1個(gè)服務(wù)節(jié)點(diǎn)。分片的數(shù)量上限取決于節(jié)點(diǎn)數(shù)量 ( 1個(gè)分片只能對(duì)應(yīng)1個(gè)服務(wù)節(jié)點(diǎn) )。
· ClickHouse并不像其他分布式系統(tǒng)那樣，擁有高度自動(dòng)化的分片功能。ClickHouse提供了本地表 ( Local Table ) 與分布式表 ( Distributed Table ) 的概念。一張本地表等同于一份數(shù)據(jù)的分片。而分布式表本身不存儲(chǔ)任何數(shù)據(jù)，它是本地表的訪問代理，其作用類似分庫中間件。借助分布式表，能夠代理訪問多個(gè)數(shù)據(jù)分片，從而實(shí)現(xiàn)分布式查詢。
· 這種設(shè)計(jì)類似數(shù)據(jù)庫的分庫和分表，十分靈活。例如在業(yè)務(wù)系統(tǒng)上線的初期，數(shù)據(jù)體量并不高，此時(shí)數(shù)據(jù)表并不需要多個(gè)分片。所以使用單個(gè)節(jié)點(diǎn)的本地表 ( 單個(gè)數(shù)據(jù)分片 ) 即可滿足業(yè)務(wù)需求，待到業(yè)務(wù)增長(zhǎng)、數(shù)據(jù)量增大的時(shí)候，再通過新增數(shù)據(jù)分片的方式分流數(shù)據(jù)，并通過分布式表實(shí)現(xiàn)分布式查詢。
[圖片上傳失敗...(image-69efb0-1609924266376)]
· Column與Field
? Column和Field是ClickHouse數(shù)據(jù)最基礎(chǔ)的映射單元。作為一款百分之百的列式存儲(chǔ)數(shù)據(jù)庫，ClickHouse按列存儲(chǔ)數(shù)據(jù)，內(nèi)存中的一列數(shù)據(jù)由一個(gè)Column對(duì)象表示。Column對(duì)象分為接口和實(shí)現(xiàn)兩個(gè)部分，在IColumn接口對(duì)象中，定義了對(duì)數(shù)據(jù)進(jìn)行各種關(guān)系運(yùn)算的方法，例如插入數(shù)據(jù)的insertRangeFrom和insertFrom方法、用于分頁的cut，以及用于過濾的filter方法等。而這些方法的具體實(shí)現(xiàn)對(duì)象則根據(jù)數(shù)據(jù)類型的不同，由相應(yīng)的對(duì)象實(shí)現(xiàn)，例如ColumnString、ColumnArray和ColumnTuple等。在大多數(shù)場(chǎng)合，ClickHouse都會(huì)以整列的方式操作數(shù)據(jù)，但凡事也有例外。如果需要操作單個(gè)具體的數(shù)值 ( 也就是單列中的一行數(shù)據(jù) )，則需要使用Field對(duì)象，F(xiàn)ield對(duì)象代表一個(gè)單值。與Column對(duì)象的泛化設(shè)計(jì)思路不同，F(xiàn)ield對(duì)象使用了聚合的設(shè)計(jì)模式。在Field對(duì)象內(nèi)部聚合了Null、UInt64、String和Array等13種數(shù)據(jù)類型及相應(yīng)的處理邏輯。
? 這句話歸納如下：column與field是兩中不同的數(shù)據(jù)結(jié)構(gòu)，column定義了數(shù)據(jù)的處理邏輯，filed定義了特殊的數(shù)據(jù)類型以及相應(yīng)的處理邏輯。column是列式操作，filed是單元格操作。
· DataType
? 數(shù)據(jù)的序列化和反序列化工作由DataType負(fù)責(zé)。IDataType接口定義了許多正反序列化的方法，它們成對(duì)出現(xiàn)，例如serializeBinary和deserializeBinary、serializeTextJSON和deserializeTextJSON等，涵蓋了常用的二進(jìn)制、文本、JSON、XML、CSV和Protobuf等多種格式類型。IDataType也使用了泛化的設(shè)計(jì)模式，具體方法的實(shí)現(xiàn)邏輯由對(duì)應(yīng)數(shù)據(jù)類型的實(shí)例承載，例如DataTypeString、DataTypeArray及DataTypeTuple等。
? DataType雖然負(fù)責(zé)序列化相關(guān)工作，但它并不直接負(fù)責(zé)數(shù)據(jù)的讀取，而是轉(zhuǎn)由從Column或Field對(duì)象獲取。在DataType的實(shí)現(xiàn)類中，聚合了相應(yīng)數(shù)據(jù)類型的Column對(duì)象和Field對(duì)象。例如，DataTypeString會(huì)引用字符串類型的ColumnString，而DataTypeArray則會(huì)引用數(shù)組類型的ColumnArray，以此類推。
· Table
? 在數(shù)據(jù)表的底層設(shè)計(jì)中并沒有所謂的Table對(duì)象，它直接使用IStorage接口指代數(shù)據(jù)表。表引擎是ClickHouse的一個(gè)顯著特性，不同的表引擎由不同的子類實(shí)現(xiàn)，例如IStorageSystemOneBlock ( 系統(tǒng)表 )、StorageMergeTree ( 合并樹表引擎 ) 和StorageTinyLog ( 日志表引擎 ) 等。IStorage接口定義了DDL ( 如ALTER、RENAME、OPTIMIZE和DROP等 ) 、read和write方法，它們分別負(fù)責(zé)數(shù)據(jù)的定義、查詢與寫入。在數(shù)據(jù)查詢時(shí)，IStorage負(fù)責(zé)根據(jù)AST查詢語句的指示要求，返回指定列的原始數(shù)據(jù)。后續(xù)對(duì)數(shù)據(jù)的進(jìn)一步加工、計(jì)算和過濾，則會(huì)統(tǒng)一交由Interpreter解釋器對(duì)象處理。對(duì)Table發(fā)起的一次操作通常都會(huì)經(jīng)歷這樣的過程，接收AST查詢語句，根據(jù)AST返回指定列的數(shù)據(jù)，之后再將數(shù)據(jù)交由Interpreter做進(jìn)一步處理。
· Block與Block流
? Block對(duì)象可以看作數(shù)據(jù)表的子集。Block對(duì)象的本質(zhì)是由數(shù)據(jù)對(duì)象、數(shù)據(jù)類型和列名稱組成的三元組
· Parser與Interpreter
? Parser和Interpreter是非常重要的兩組接口：Parser分析器負(fù)責(zé)創(chuàng)建AST對(duì)象；而Interpreter解釋器則負(fù)責(zé)解釋AST，并進(jìn)一步創(chuàng)建查詢的執(zhí)行管道。它們與IStorage一起，串聯(lián)起了整個(gè)數(shù)據(jù)查詢的過程。Parser分析器可以將一條SQL語句以遞歸下降的方法解析成AST語法樹的形式。不同的SQL語句，會(huì)經(jīng)由不同的Parser實(shí)現(xiàn)類解析。例如，有負(fù)責(zé)解析DDL查詢語句的ParserRenameQuery、ParserDropQuery和ParserAlterQuery解析器，也有負(fù)責(zé)解析INSERT語句的ParserInsertQuery解析器，還有負(fù)責(zé)SELECT語句的ParserSelectQuery等。
? Interpreter解釋器的作用就像Service服務(wù)層一樣，起到串聯(lián)整個(gè)查詢過程的作用，它會(huì)根據(jù)解釋器的類型，聚合它所需要的資源。首先它會(huì)解析AST對(duì)象；然后執(zhí)行"業(yè)務(wù)邏輯" ( 例如分支判斷、設(shè)置參數(shù)、調(diào)用接口等 )；最終返回IBlock對(duì)象，以線程的形式建立起一個(gè)查詢執(zhí)行管道
· Functions 與Aggregate Functions
? ClickHouse主要提供兩類函數(shù)—普通函數(shù)和聚合函數(shù)。普通函數(shù)由IFunction接口定義，擁有數(shù)十種函數(shù)實(shí)現(xiàn)，例如FunctionFormatDateTime、FunctionSubstring等。除了一些常見的函數(shù) ( 諸如四則運(yùn)算、日期轉(zhuǎn)換等 ) 之外，也不乏一些非常實(shí)用的函數(shù)，例如網(wǎng)址提取函數(shù)、IP地址脫敏函數(shù)等。普通函數(shù)是沒有狀態(tài)的，函數(shù)效果作用于每行數(shù)據(jù)之上。當(dāng)然，在函數(shù)具體執(zhí)行的過程中，并不會(huì)一行一行地運(yùn)算，而是采用向量化的方式直接作用于一整列數(shù)據(jù)。
? 聚合函數(shù)由IAggregateFunction接口定義，相比無狀態(tài)的普通函數(shù)，聚合函數(shù)是有狀態(tài)的。以COUNT聚合函數(shù)為例，其AggregateFunctionCount的狀態(tài)使用整型UInt64記錄。聚合函數(shù)的狀態(tài)支持序列化與反序列化，所以能夠在分布式節(jié)點(diǎn)之間進(jìn)行傳輸，以實(shí)現(xiàn)增量計(jì)算。
· Cluster與Replication
? ClickHouse的集群由分片 ( Shard ) 組成，而每個(gè)分片又通過副本 ( Replica ) 組成。這種分層的概念，在一些流行的分布式系統(tǒng)中十分普遍。例如，在Elasticsearch的概念中，一個(gè)索引由分片和副本組成，副本可以看作一種特殊的分片。如果一個(gè)索引由5個(gè)分片組成，副本的基數(shù)是1，那么這個(gè)索引一共會(huì)擁有10個(gè)分片 ( 每1個(gè)分片對(duì)應(yīng)1個(gè)副本 )。如果你用同樣的思路來理解ClickHouse的分片，那么很可能會(huì)在這里栽個(gè)跟頭。ClickHouse的某些設(shè)計(jì)總是顯得獨(dú)樹一幟，而集群與分片就是其中之一。這里有幾個(gè)與眾不同的特性。ClickHouse的1個(gè)節(jié)點(diǎn)只能擁有1個(gè)分片，也就是說如果要實(shí)現(xiàn)1分片、1副本，則至少需要部署2個(gè)服務(wù)節(jié)點(diǎn)。分片只是一個(gè)邏輯概念，其物理承載還是由副本承擔(dān)的。
? 分片即表示安裝clickhouse的節(jié)點(diǎn)數(shù)
參考
原理
列式存儲(chǔ)
[圖片上傳失敗...(image-8d94a5-1609924266376)]
· 分析場(chǎng)景中往往需要讀大量行但是少數(shù)幾個(gè)列。在行存模式下，數(shù)據(jù)按行連續(xù)存儲(chǔ)，所有列的數(shù)據(jù)都存儲(chǔ)在一個(gè)block中，不參與計(jì)算的列在IO時(shí)也要全部讀出，讀取操作被嚴(yán)重放大。而列存模式下，只需要讀取參與計(jì)算的列即可，極大的減低了IO cost，加速了查詢。
· 同一列中的數(shù)據(jù)屬于同一類型，壓縮效果顯著。列存往往有著高達(dá)十倍甚至更高的壓縮比，節(jié)省了大量的存儲(chǔ)空間，降低了存儲(chǔ)成本。
· 更高的壓縮比意味著更小的data size，從磁盤中讀取相應(yīng)數(shù)據(jù)耗時(shí)更短。
· 高壓縮比，意味著同等大小的內(nèi)存能夠存放更多數(shù)據(jù)，系統(tǒng)cache效果更好
數(shù)據(jù)有序存儲(chǔ)
· ClickHouse支持在建表時(shí)，指定將數(shù)據(jù)按照某些列進(jìn)行sort by。sort by是局部排序，在hive中表示在一個(gè)reduce內(nèi)部排序排序后，保證了相同sort key的數(shù)據(jù)在磁盤上連續(xù)存儲(chǔ)，且有序擺放。在進(jìn)行等值、范圍查詢時(shí)，where條件命中的數(shù)據(jù)都緊密存儲(chǔ)在一個(gè)或若干個(gè)連續(xù)的Block中，而不是分散的存儲(chǔ)在任意多個(gè)Block， 大幅減少需要IO的block數(shù)量。另外，連續(xù)IO也能夠充分利用操作系統(tǒng)page cache的預(yù)取能力，減少page fault。
? 簡(jiǎn)言之，就是where后面的謂詞在建表時(shí)候要提前指定。由于集中存儲(chǔ)在一個(gè)數(shù)據(jù)塊內(nèi)，就會(huì)減少掃描時(shí)間。io
**better to use **
環(huán)境要求
如果可能的話，使用10G或更高級(jí)別的網(wǎng)絡(luò)。
至少4GB的RAM來執(zhí)行重要的查詢
RAM所需的體積取決于:查詢的復(fù)雜性。查詢中處理的數(shù)據(jù)量
監(jiān)控體系
[圖片上傳失敗...(image-d202b4-1609924266376)]
