30億日志，檢索+分頁+背景展示，你是否遇到過更奇葩的需求？

沈老師，你好，想請教一個資料庫查詢日志，前台頁面顯示的問題。 需求：（1）按照某些特定檢索條件查詢日志；（2）通過前台Web頁面查詢并顯示相關日志資訊；（3）檢索需求包含使用者，時間段區間，類型等特定字段；

希望做到

（1）查詢速度盡可能快；（2）支援分頁查詢； 

目前方案：日志資訊存儲在Oracle中，根據日期對Oracle做了分區處理，每天生成一個分區表，每個分區表中的資料總量大概在1000W左右。在相關查詢字段例如使用者，類型上建立索引，來滿足不同次元的查詢需求。 潛在問題：跨分區的查詢，求記錄總數（計算分頁時的查詢），耗時要3-4分鐘，請問有什麼優化方法麼? ==問題描述完== 這個需求還是非常變态的，通常日志會進行過濾/結構化/彙總，放入資料倉庫，建立業務寬表，寬表上的查詢，一般不會具體查一行一行的記錄。 如果要支援檢索，并一行一行在Web背景進行展示，至少要解決幾個方面的問題：（1）存儲問題；（2）檢索問題；（3）擴充性問題（資料量擴充，檢索字段擴充）； 一、存儲問題

是否可以用關系型資料庫存儲日志？如果日志格式固定，檢索條件固定，是可以的。 例如：

2019-08-11 23:19:20 uid=123 action=pay type=wechat money=12

可以轉化為表：

t_log(date, time, uid, action, type, money)

然後在相關字段上建立索引，以滿足背景查詢與展示的需求。 資料量太大，怎麼解決？按照題目描述，日資料量大概在1000W級别，1年的資料量大概在36Y級别。

如果用Oracle存儲，1000W為一個分區表：一年需要365個分區，跨分區的查詢性能較低，不太合适。 改為1個月一個分區：單分區3Y記錄，大部分分區無寫操作（插入，修改，删除），隻有索引上的讀操作，讀寫性能基本能抗住。一年12個分區，性能比365個分區好很多。 雖然本例的日志可以結構化（将日志轉化表），由于資料量太大，其實關系型資料庫不太适用，可以用适合更大資料量的ES或者Hive來存儲。 二、檢索問題日志格式固定，檢索條件固定，如果用關系型資料庫或者Hive存儲，可以在相關字段上建立索引，來滿足查詢需求。 如果用ES來存儲，其内部用倒排表實作，天然支援檢索。 三、擴充性問題 資料量擴充不管用Oracle，ES還是Hive來存儲，它們的差別隻是單執行個體/單叢集存儲容量不一樣，如果資料量無限擴充，本質上的解決方案還是“水準切分”。

 需要注意的是，盡量不要使用自帶的“分區表”來擴充，而在業務層自己拆分。

檢索字段擴充如果日志不是标準化的，檢索字段也不是固定的，那就麻煩了，那就變成了也“搜尋引擎”的問題。 此時使用ES是更為合适的，不過結合無限的資料量，最終可能需要自己實作存儲于檢索引擎（類似于百度，存儲容量無限，檢索字段不固定）。

總結

結合本例，日志量大，模式固定，建議：

（1）最建議，使用Hive存儲，使用索引的方式實作日志背景檢索需求；（2）如果擴充性要求稍高，可以使用ES實作存儲與檢索，使用水準擴充來存儲更大的資料量； 希望上述思路對星官有幫助，經驗有限，也歡迎大家貢獻更多更好的方案，思路比結論重要。

本文轉自“架構師之路”公衆号，58沈劍提供。