說說最近在生產使用CK的一些看法和感受吧。
我們部門生產系統比較多,雖然都是一個行業內的相關係統,屬於政府資料比較多的系統。政府的系統基本上沒有什麼統一規劃,想到哪做到哪這是比較常見的,但是各個部門又是很關心資料。經常這種資料統計一下,那種資料分析一下的那種。想搞資料倉庫,又太麻煩,什麼資料模型元資料啥的也沒啥意義。因此引入CK替代一下數倉的角色,同時也為能夠加快查詢速度啥的
說說好的地方吧
1 部署方便,照著網上教程就能部署一個多節點分散式的正式環境
2速度真是快,5個節點分散式,基本我們這邊最大的查詢資料量10億級別,秒級返回。當然分割槽啊啥的基本該做的都做了
3資料遷移和資料同步都有很成熟的技術方案,業務系統依舊使用原有的資料庫(原來用什麼庫就用什麼庫,CK就做資料查詢的主資料庫)基於資料庫日誌級別毫秒級同步生產業務庫沒有壓力
4各種查詢分析方法都很多,效率也很高
5SQL語句在idea中有提示,非常友好
下面說一下不足吧
1 跟標準SQL差距較大,原有的查詢方法基本需要重寫
2 欄位認大小寫,不過還好有idea的提示,也不算特別難解決
3 官方文件不是很完善,比較粗,社群也比較冷清
總的來說,如果你的系統數量級達到了一定程度,而你又沒有需求去做元資料數倉資料模型等東西,可以用CK替代一下,相對靈活
說說最近在生產使用CK的一些看法和感受吧。
我們部門生產系統比較多,雖然都是一個行業內的相關係統,屬於政府資料比較多的系統。政府的系統基本上沒有什麼統一規劃,想到哪做到哪這是比較常見的,但是各個部門又是很關心資料。經常這種資料統計一下,那種資料分析一下的那種。想搞資料倉庫,又太麻煩,什麼資料模型元資料啥的也沒啥意義。因此引入CK替代一下數倉的角色,同時也為能夠加快查詢速度啥的
說說好的地方吧
1 部署方便,照著網上教程就能部署一個多節點分散式的正式環境
2速度真是快,5個節點分散式,基本我們這邊最大的查詢資料量10億級別,秒級返回。當然分割槽啊啥的基本該做的都做了
3資料遷移和資料同步都有很成熟的技術方案,業務系統依舊使用原有的資料庫(原來用什麼庫就用什麼庫,CK就做資料查詢的主資料庫)基於資料庫日誌級別毫秒級同步生產業務庫沒有壓力
4各種查詢分析方法都很多,效率也很高
5SQL語句在idea中有提示,非常友好
下面說一下不足吧
1 跟標準SQL差距較大,原有的查詢方法基本需要重寫
2 欄位認大小寫,不過還好有idea的提示,也不算特別難解決
3 官方文件不是很完善,比較粗,社群也比較冷清
總的來說,如果你的系統數量級達到了一定程度,而你又沒有需求去做元資料數倉資料模型等東西,可以用CK替代一下,相對靈活