Presto連接數(shù)據(jù)源的性能問題
老師你好，我想請問一些Presto連接數(shù)據(jù)源的問題。
我這里嘗試了presto連接PG數(shù)據(jù)庫，做了簡單的聚合嘗試，比在PG中直接查詢是慢的。
想請教一下，
是否需要數(shù)據(jù)源為Hive 或類似列存儲格式的等特殊類型的數(shù)據(jù)源格式，presto才具有高性能的特點
測試pg和presto兩臺機(jī)器各自獨立，采用公網(wǎng)IP訪問，是否需要部署同一臺測試，感覺如果jdbc協(xié)議走tcp的話，應(yīng)該相差不大
presto是否會緩存數(shù)據(jù)源的數(shù)據(jù)在內(nèi)存中，第二次查詢會更快？
測試數(shù)據(jù)為單表千萬級數(shù)據(jù)，presto的單機(jī)是否存在性能瓶頸，8cores 28g ram，感覺影響不大
目前在摸索一些數(shù)據(jù)分析類的大數(shù)據(jù)工具，使用過Clickhouse，不知道老師是否了解
2020-04-10
首先需要聲明一點，presto本身是查詢引擎，對于hive數(shù)據(jù)源的查詢流程為讀取metastore，然后讀取hdfs上文件。 對于其他jdbc的數(shù)據(jù)源的讀取流程為生成執(zhí)行計劃，下推執(zhí)行計劃，jdbc數(shù)據(jù)源執(zhí)行查詢，在presto端再進(jìn)行聚合。
所以依次回復(fù)你的問題：
1. presto所具備的高性能，快速是相對的，在數(shù)據(jù)量較大，進(jìn)行分布式查詢，進(jìn)行多個數(shù)據(jù)源的聚合查詢等等操作
2. 對于presto和pg的測試，我們可以簡單這樣理解，你通過presto對pg做簡單查詢=presto生成查詢計劃+pg查詢自身，完全沒有對比性
3. presto不會緩存數(shù)據(jù)
4. 單機(jī)presto發(fā)揮不出mpp架構(gòu)的優(yōu)勢，只適合測試使用
5. clickhouse我的了解也不多，和presto一樣是mpp架構(gòu)，ck對于數(shù)據(jù)存儲、索引、查詢等等方面都進(jìn)行了優(yōu)化。而presto對于數(shù)據(jù)存儲這塊主要是依賴列式存儲格式orc以及parquet。
希望能夠?qū)δ阌兴鶐椭?，有問題隨時溝通~