我在業餘時間開發維護了一款免費開源的升訊威線上客服系統,也收穫了許多使用者。對我來說,只要能獲得使用者的認可,就是我最大的動力。
最近客服系統成功經受住了客戶現場組織的壓力測試,獲得了客戶的認可。
客戶組織多名客服上線後,所有員工同一時間開啟訪客頁面瘋狂不停的給線上客服發訊息,系統穩定無異常無掉線,客服回覆訊息正常。訊息實時到達無任何延遲。
我會通過一系列的文章詳細分析升訊威線上客服系統的並行高效能技術是如何實現的,使用了哪些方案以及具體的做法。
本篇介紹資料儲存方面的具體化檢視技術。
通過為常用聚合的具體化檢視投資資源(資料儲存、後臺 CPU 週期),可以獲得以下優勢:
效能提升: 對於相同的聚合函數,查詢具體化檢視通常比查詢源表效能更好。
時效性: 具體化檢視查詢始終返回最新結果,而不受上次進行具體化的時間的影響。 查詢組合了檢視的具體化部分和源表中尚未具體化的記錄(delta 部分),始終提供最新結果。
降低成本:與對源表執行聚合操作相比,查詢具體化檢視消耗群集中的資源較少。 如果只需要聚合,則可以減少源表的保留策略。 此設定可減少源表的熱快取開銷。
下面是可以使用具體化檢視解決的常見方案:
通過使用 arg_max()(聚合函數)返回每個實體的最後一條記錄來更新資料。
通過對原始資料計算定期統計資訊來減少資料的解析。 按時間段使用各種聚合函數。
例如,使用 T | summarize dcount(User) by bin(Timestamp, 1d) 維護每天不同使用者的最新快照。
使用 take_any()(聚合函數)消除表中的重複記錄。
.create materialized-view MV on table T
{
table('T')
| summarize take_any(*) by EventId
}
具體化檢視和更新策略的工作方式不同,適用於不同的用例。 根據以下準則來確定應使用哪一個:
具體化檢視適用於聚合,而更新策略則不適合。 更新策略針對每個引入批單獨執行,因此只能在同一引入批中執行聚合。 如果需要聚合查詢,請始終使用具體化檢視。
更新策略適用於資料轉換、維度表的擴充(通常使用查詢運運算元),以及可在單個引入的範圍內執行的其他資料操作。
更新策略在引入期間執行。 資料在源表和目標表中均不適用於查詢,直到所有更新策略都在其上執行。 另一方面,具體化檢視不是引入管道的一部分。 具體化過程在引入後在後臺定期執行。 源表中的記錄在具體化之前可用於查詢。
更新策略和具體化檢視都不適合聯接。 兩者都可以包括聯接,但僅限於特定用例。 也就是說,只有在更新策略/具體化過程執行時,聯接兩側的匹配資料才可用。 如果匹配的實體預期在同一時間引入到左聯接表和右聯接表,則有可能在更新策略/具體化執行時錯過資料。 有關 dimension tables 的詳細資訊,請參閱具體化檢視查詢引數和事實表和維度表。
可以通過兩種方法查詢具體化檢視:
查詢整個檢視:按名稱查詢具體化檢視(與查詢表類似)時,具體化檢視查詢會將檢視的具體化部分與源表中尚未具體化 (delta) 的記錄組合在一起。
** 查詢具體化檢視時,會始終根據引入到源表的所有記錄返回最新結果。 有關具體化檢視中的具體化和非具體化部分的詳細資訊,請參閱具體化檢視的工作原理 。
** 此選項可能不會以最佳方式執行,因為它需要在查詢時具體化 delta 部分。 在這種情況下,效能取決於檢視的生存期和在查詢中應用的篩選器。 具體化檢視查詢優化器部分包括在查詢整個檢視時提高查詢效能的可能方法。
僅查詢具體化部分:查詢該檢視的另一種方法是使用 materialized_view() 函數。 此選項支援僅查詢該檢視的具體化部分,同時指定使用者願意容忍的最大延遲。
cluster('cluster1').database('db').ViewName
cluster('cluster1').database('*').ViewName
database('*').ViewName
database('DB*').ViewName
database('*').materialized_view('ViewName')
database('DB*').materialized_view('ViewName')
升訊威線上客服與行銷系統是一款客服軟體,但更重要的是一款行銷利器。