一句話區別
- OLTP：基於行存儲的關系數據庫，寫入速度極快，用於數據記錄修改場景，MySQL、Oracle
- OLAP：基於列存儲，查詢速度極快，用於海量數據分析，Clickhouse、Vertica、 Amazon Redshift、 Sybase IQ、 Exasol、 Infobright、 InfiniDB、 LucidDB、 SAP HANA、 Google Dremel
- 列族：使用k-v + 時間戳存儲，用於大表大數據存儲，分布式存儲，帶版本時序操作等場景，HBase、Cassandra、BigTable（google）
區別
1.在數據寫入上的對比
1）行存儲的寫入是一次完成。如果這種寫入建立在操作系統的文件系統上，可以保證寫入過程的成功或者失敗，數據的完整性因此可以確定。
2）列存儲由於需要把一行記錄拆分成單列保存，寫入次數明顯比行存儲多（意味着磁頭調度次數多，而磁頭調度是需要時間的，一般在1ms~10ms)，再加上磁頭需要在盤片上移動和定位花費的時間，實際時間消耗會更大。所以，行存儲在寫入上占有很大的優勢。
3）還有數據修改,這實際也是一次寫入過程。不同的是，數據修改是對磁盤上的記錄做刪除標記。行存儲是在指定位置寫入一次，列存儲是將磁盤定位到多個列上分別寫入，這個過程仍是行存儲的列數倍。所以，數據修改也是以行存儲占優。
2.在數據讀取上的對比
1）數據讀取時，行存儲通常將一行數據完全讀出，如果只需要其中幾列數據的情況，就會存在冗余列，出於縮短處理時間的考量，消除冗余列的過程通常是在內存中進行的。
2）列存儲每次讀取的數據是集合的一段或者全部，不存在冗余性問題。
3） 兩種存儲的數據分布。由於列存儲的每一列數據類型是同質的，不存在二義性問題。比如說某列數據類型為整型(int)，那么它的數據集合一定是整型數據。這種情況使數據解析變得十分容易。相比之下，行存儲則要復雜得多，因為在一行記錄中保存了多種類型的數據，數據解析需要在多種數據類型之間頻繁轉換，這個操作很消耗CPU，增加了解析的時間。所以，列存儲的解析過程更有利於分析大數據。
OLAP-OLTP 的查詢性能對比
以OLAP ClickHouse為例，可以看出在1億條數據情況下，MySQL和Hive比ClickHouse慢289倍和831倍
ClickHouse有個在線的domo，可以試試查詢它1億行的表（hits_100m_obfuscated）復雜查詢的速度，挺驚人。
https://play.clickhouse.tech/?file=welcome
存儲方式
行式數據庫OLTP
在傳統的行式數據庫系統中，數據按如下順序存儲：
| row | watchID | JavaEnable | title | GoodEvent | EventTime |
|---|---|---|---|---|---|
| #0 | 89354350662 | 1 | 投資者關系 | 1 | 2016-05-18 05:19:20 |
| #1 | 90329509958 | 0 | 聯系我們 | 1 | 2016-05-18 08:10:20 |
| #2 | 89953706054 | 1 | 任務 | 1 | 2016-05-18 07:38:00 |
| #N | … | … | … | … | … |
處於同一行中的數據總是被物理的存儲在一起。mysql innodb數據還和索引放在一起。
列式數據庫OLAP
在列式數據庫系統中，數據按如下的順序存儲：
| row: | #0 | #1 | #2 | #N |
|---|---|---|---|---|
| watchID: | 89354350662 | 90329509958 | 89953706054 | … |
| JavaEnable: | 1 | 0 | 1 | … |
| title: | 投資者關系 | 聯系我們 | 任務 | … |
| GoodEvent: | 1 | 1 | 1 | … |
| EventTime: | 2016-05-18 05:19:20 | 2016-05-18 08:10:20 | 2016-05-18 07:38:00 | … |
該示例中只展示了數據在列式數據庫中數據的排列方式。
實際上列式數據庫還應該有一個內部索引，左邊是行數據庫，右邊是列數據庫
將Customes Name列及Material列做邏輯化索引標識，查詢時分別匹配Materia=Refrigerator及Customes Name=Miller的數據，然后做交叉匹配。
列族數據庫的存儲模型
核心是k-v 加 時間戳存儲。
場景
行式存儲的適用場景：
1、適合隨機的增刪改查操作;
2、需要在行中選取所有屬性的查詢操作;
3、需要頻繁插入或更新的操作，其操作與索引和行的大小更為相關。
列式存儲的適用場景：
一般來說，一個OLAP類型的查詢可能需要訪問幾百萬甚至幾十億個數據行，且該查詢往往只關心少數幾個數據列。例如，查詢今年銷量最高的前20個商品，這個查詢只關心三個數據列：時間（date）、商品（item）以及銷售量（sales amount）
列族存儲的適用場景：
列族是一種K-V方式的行列混合存儲模式，這種模式能夠同時滿足OLTP和OLAP的查詢需求。
但寫效率不如行式，讀效率不如列式
OLAP-ClickHouse應用場景分析
新近極熱門的ClickHouse大有干掉ES、Hodoop生態鏈如Hive、HBase的趨勢的可能。
使用ClickHouse作為OLAP服務的常見的應用場景包括：監控系統、ABtest、用戶行為分析、BI報表，特征分析等。
hadoop VS OLAP ClickHouse
- Hadoop 體系是一種離線系統，一般很難支持即席查詢。ClickHouse 可以支持即席查詢。
- Hadoop 體系一般不支持實時更新，都采用批量更新和寫入。ClickHouse 支持實時數據更新。
- Hadoop 體系一般采用行記錄存儲，數據查詢需要掃描所有列，當表很寬時會掃描很多用不到的列。ClickHouse 是列式存儲，查詢只需要加載相關的列。
目前大量使用 ClickHouse 的互聯網公司：
1. 今日頭條內部用 ClickHouse 來做用戶行為分析，內部一共幾千個 ClickHouse 節點，單集群最大 1200 節點，總數據量幾十 PB，日增原始數據 300TB 左右。
2. 騰訊內部用 ClickHouse 做游戲數據分析，並且為之建立了一整套監控運維體系。
3. 攜程內部從 18 年 7 月份開始接入試用，目前 80% 的業務都跑在 ClickHouse 上。每天數據增量十多億，近百萬次查詢請求。
4. 快手內部也在使用 ClickHouse，存儲總量大約 10PB， 每天新增 200TB， 90% 查詢小於 3S。
5. 在國外，Yandex 內部有數百節點用於做用戶點擊行為分析，CloudFlare、Spotify 等頭部公司也在使用。
ClickHouse 高性能的背后
建議讀這篇：
https://blog.csdn.net/u013256816/article/details/108413872
https://zhuanlan.zhihu.com/p/103781296