**1\. 寫在前面**
(1)如果你的業務預算或機器資源有限,強烈不推薦使用clickhouse,因為這套架構成本比較高。
(2)最小集群部署所需機器:ck節點需要2臺256G內存/40c cpu物理機,磁盤使用SSD,加上3臺zookeeper和2臺chproxy應用主機或者云主機。
(3)Clickhouse自帶了豐富的功能來應對復雜的業務場景和大數據量,所以在使用期間需要運維和開發側都投入人力對這些功能(表引擎類型)學習和掌握。
**2\. 業務在數據層的表現**
(1)業務大多數是讀請求,存儲寬表,無大字段,較少的并發(單臺100-200qps左右)。
(2)數據批寫入(1000條以上,線上業務建議5w-10w),不修改或少修改已添加的數據。
(3)無事務要求,對數據一致性要求低。
(4)對于簡單查詢,允許延遲大約50毫秒,每一個查詢除了一個大表外都很小。
(5)處理單個查詢時需要高吞吐量(每個服務器每秒高達數十億行)。
**3.具體業務場景**
(1)用戶行為分析,精細化運營分析:日活,留存率分析,路徑分析,有序漏斗轉化率分析,Session分析等;
(2)實時日志分析,監控分析;
(3)實時數倉。
- 導讀
- 概述
- 第一章 安裝部署
- 1.1. docker安裝clickhouse
- 第二章 使用實踐與規范
- 2.1. ClickHouse應用場景
- 2.2. 表引擎選擇
- 2.2.1. MergeTree表引擎
- 2.2.2. ReplicatedMergeTree表引擎
- 2.2.3. ReplacingMergeTree表引擎
- 2.2.4. SummingMergeTree表引擎
- 2.2.5. Aggregatingmergetree表引擎
- 2.3. 開發規范
- 2.4. 集群架構
- 2.4.1. 常用架構
- 2.4.2. zookeeper的關鍵作用
- 2.4.3. chproxy
- 2.5. 客戶端工具選擇
- 2.6. 可用性說明
- 2.7. 集群配置參數調優
- 第三章 數據類型&語法以及常用函數
- 3.1. 基礎數據類型
- 3.2. SQL函數
- 3.3. DDL與DML基本語法
- 3.4. UPDATE 和 DELETE操作
- 3.4.1. 數據UPDATE和DELETE操作示例
- 3.4.2. 數據的實時更新操作(Real-time UPDATE)
- 第四章 clickhouse實戰篇
- 4.1. JDBC操作clickhouse
- 4.2. clickhouse集成mybatis