索引表和ES的使用心得是什么

這篇文章將為大家詳細講解有關索引表和ES的使用心得是什么，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

在電商項目中，物理庫存系統是個極其重要的系統，訂單支付后，就會開始來占用物理庫存。一般情況下，庫存系統都是要分庫的，因為主要的操作是寫操作，例如占用/釋放/取消等寫操作。使用分庫可以降低數據庫寫的壓力。盡管寫操作為主，但是讀操作也是有的。比如說，庫存占用的時候，得先查詢是否有庫存，而這個查詢操作并不都會帶上分庫因子(用于路由到具體的某個數據庫)，而是一些比較寬松的查詢條件，這些查詢條件對應的數據可能分布在不同的數據庫上。這個時候為了查詢的方便，會構建一個索引表。這個索引表是存在另外的單獨的一個數據庫中，不會再分庫了的。

比如說一個查詢商品的操作，只是按照價格去搜索的時候，如下圖： 

這個時候就得從幾個DB里面去獲取數據，需要遍歷DB，相當的麻煩。當然也可以為價格建立索引，加快查詢速度，但是要知道，查詢的時候，可能還根據其他條件來查詢，像上下架狀態，商品類別等，不可能都為這些查詢條件建立索引，代價太大了，也不合理。引入索引表之后，則不同了。

根據查詢條件從索引表中找出主鍵ID，再根據主鍵ID從多個數據庫中查找數據。這樣無論查詢條件有哪些，通通只需要根據主鍵ID查找數據即可。當然索引表的設計不只是像上圖那樣設計，大概分三種。

1、查詢字段+數據庫主鍵

把查詢字段放到索引表，還需要把對應的數據庫主鍵ID也放置進去。當查詢請求到來時，根據查詢條件找出對應的數據主鍵，再根據數據主鍵路由到對應的存有完整業務數據的數據分庫上。這種方案呢。索引表占用空間小，可以支撐很久。但是要找出業務數據，還是需要路由到分庫上。另外，如果要把索引表的數據存儲到ES搜索引擎上的話，這種方式就不行了。因為索引表中沒有外部系統要的業務數據。所以當時的庫存系統沒有使用這種索引表設計方案。

2、查詢字段+數據庫主鍵+需要展示的業務字段

這種方案呢。當請求到來的時候，直接查詢索引表即可。無需根據主鍵路由到分庫了。同時如果要結合ES的話。可以直接把索引表的數據弄到ES上即可。后續直接讓ES暴露查詢接口即可。目前我在唯品會參與的物理庫存項目中，是使用這種方式的。但是這個方案也有個缺點。就是索引表的體積比較大，后續數據量一大的話，也是個問題。能不能優化一下呢？

3、索引表拆分

上面說到的第二種方案，索引表的膨脹可能很快，可以考慮將索引表拆分。比如說：索引表只是保存查詢條件和主鍵，而需要展示給外部系統的數據，另外存儲在單獨的表上。比如叫index_detail表。這個表擁有索引表的主鍵。這樣的話，當查詢請求到來的時候，先從索引表查詢到主鍵，再根據主鍵從index_detail表中查詢出數據。當然這樣做的話。ES的數據來源就變成多張表了，不過這是可以接受的。

如何把業務數據寫入到索引表

使用MQ

一般來說，構建索引數據是使用單獨一個應用來做的。比如叫data-index域。這個域會從消息隊列中讀取消息，用于構建索引數據。當業務數據發生變化后，生產者發送MQ消息到隊列上。 
這里的消息設計也分兩種情況。一種是消息只是帶有數據主鍵和操作類型(ADD/Update/DELETE),消費者拿到主鍵后再去DB獲取完整的數據并插入到索引表中。另一種方案呢，是消息包含了大部分需要的字段，消費者拿到消息后直接把數據插入到索引表中。這兩種消息設計，我在實際項目中都有用過。

直接操作DB

這種方案呢就比較粗暴，直接配置一個索引表庫的數據源，當業務數據發生變化時，使用Mybatis或者JDBC把數據更新到索引表中。一般不建議這么做，一來構建索引數據的邏輯跟數據的CRUD操作融合在一起了。二來，操作其他數據庫的數據，要么通過接口的方式，要么由單獨的域來做。建議還是使用MQ的方式來構建索引數據。

如何把索引表數據弄到ES上

監聽數據庫表的數據變化

像在唯品會這邊，自研了一個叫VDP的組件，使用storm job去監聽索引表數據的變化，一旦有變化，就把數據同步到隊列中，ES直接從隊列中獲取數據，并存儲到ES上。 
這種方案的好處是，我們無需寫任何代碼，數據自動可以同步到ES上。

使用MQ

如果公司內部沒有開發VDP這樣的組件，可以通過發送MQ消息的方式來將索引表的數據同步數據到ES上。

讓ES暴露CUD接口

另外一種方案是，讓ES暴露CUD接口，用于同步索引表數據。但是這樣就跟ES耦合在一塊了。不太推薦這么做。

當索引表結合ES后，交互流程就變成如下的形式了。 

關于分頁

在數據庫分庫的情況下，如果要分頁展示數據的話，并且數據庫數據的數量又特別龐大，可以借助ES，從ES獲取分頁數據。如果沒有ES，只有索引表的話，那就直接在索引表中獲取分頁數據對應的ID，再從數據庫中獲取。

進一步的思考

1、ES不支持Group By后再分頁這樣的操作，所以在構建索引表的時候，可以事先計算好Group By的一些統計數據，并存儲到索引表中； 
2、一些后臺應用中，如果數據庫表的數量已經很大，好幾個億了，并且查詢的SQL還非常變態，用數據庫已經無法支持了，那么可以使用ES，查詢速度快，也支持一些統計操作； 
3、使用ES輸出數據時，也有個坑。經常會拿到臟數據的。例如當數據發送變化后，構建索引數據并把索引數據同步到ES上是需要時間的，但是我們后臺通常有將數據下架的操作，下架的操作操作完后，再次點擊查詢按鈕，可能還是看到臟數據，因為數據同步到ES上沒那么快。現在我還沒想到很好的辦法來解決這個問題。

關于索引表和ES的使用心得是什么就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。