背景

有2種常見的多維度查詢場景，分別是：

• 帶多個篩選條件的列表查詢
• 不含分庫分表列的其他維度查詢

普通的數(shù)據(jù)庫查詢，很難實現(xiàn)上述需求場景民镜，更不用提模糊查詢弄唧、全文檢索了适肠。

下面結(jié)合樓主的經(jīng)驗和知識，介紹初級方案候引、進階方案（上ElasticSearch）侯养，大部分情況下推薦使用ElasticSearch來實現(xiàn)多維度查詢，趕時間的讀者可以直接跳到“進階方案：將ElasticSearch添加到現(xiàn)有系統(tǒng)中”澄干。

初級方案

1逛揩、根據(jù)常見查詢場景，增加相應(yīng)字段的組合索引

這個是為了實現(xiàn)帶多個篩選條件的列表查詢的麸俘。

優(yōu)點

• 非常簡單
• 讀寫不一致時間較短：取決于數(shù)據(jù)庫主從同步延時息尺，一般為毫秒級別

缺點

• 非常局限：除非篩選條件比較固定，否則難以應(yīng)付后續(xù)新增或修改篩選條件
• 如果每次來新的篩選查詢字段的需求疾掰，就新增索引搂誉，最終導(dǎo)致索引過于龐大，影響性能

于是就出現(xiàn)了經(jīng)典的一幕：產(chǎn)品提需求說要支持某個新字段的篩選查詢静檬，開發(fā)反饋說做不了炭懊、或者成本很高，于是不了了之 :）

2拂檩、異構(gòu)出多份數(shù)據(jù)

更加優(yōu)雅的方式侮腹，是異構(gòu)出多份數(shù)據(jù)。
例如稻励，C端按用戶維度查詢父阻，B端按店鋪維度查詢，如果還有供應(yīng)商望抽，按供應(yīng)商維度查詢加矛。一個數(shù)據(jù)庫只能按一種維度來分庫。

（1）程序?qū)懭攵鄠€數(shù)據(jù)源

優(yōu)點是：非常簡單煤篙。

缺點

• 跨庫寫存在一致性問題（除非不同維度的表使用公共的分庫斟览，事務(wù)寫入），性能低
• 不能靈活支持更多其他維度的查詢

（2）借助Canal實現(xiàn)數(shù)據(jù)的自動同步

通過Canal同步數(shù)據(jù)辑奈，異構(gòu)出多個維度的數(shù)據(jù)源苛茂。詳見之前寫的這篇文章：架構(gòu)師必備：巧用Canal實現(xiàn)異步绑嘹、解耦的架構(gòu)

image.png

優(yōu)點是：更加優(yōu)雅上鞠，無需改動程序主流程中鼠。

缺點

• 仍然無法解決不斷變化的需求色难，不可能為了支持新維度就異構(gòu)出一份新數(shù)據(jù)

進階方案：將ElasticSearch添加到現(xiàn)有系統(tǒng)中

應(yīng)用架構(gòu)

現(xiàn)有系統(tǒng)一般都會用到MySQL數(shù)據(jù)庫，需要引入ES躁绸，為系統(tǒng)增強多維度查詢的功能裕循。
MySQL繼續(xù)承擔(dān)業(yè)務(wù)的實時讀寫請求、事務(wù)操作涨颜，ES承擔(dān)近實時的多維度查詢請求费韭，ES可支撐十萬級別qps（取決于節(jié)點數(shù)茧球、分片數(shù)庭瑰、副本數(shù)）。
需要注意的是：同步數(shù)據(jù)至ES是秒級延遲（主要耗費在索引refresh）抢埋，而查詢已進入索引的文檔弹灭，是在數(shù)毫秒到數(shù)百毫秒級別。

image.png

導(dǎo)入數(shù)據(jù)

需要同步機制揪垄，來把MySQL中的數(shù)據(jù)導(dǎo)入到ES中穷吮，主要流程如下：

• 預(yù)先定義ES索引的mapping配置，而不依賴ES自動生成mapping
• 初始全量導(dǎo)入饥努，后續(xù)增量導(dǎo)入：Canal+MQ數(shù)據(jù)管道同步捡鱼，不需要或僅需少量代碼工作
• 數(shù)據(jù)過濾：不導(dǎo)入無需檢索的字段，減小索引大學(xué)酷愧，提高性能
• 數(shù)據(jù)扁平化處理：如果數(shù)據(jù)庫中有json字段列驾诈，需要從中提取業(yè)務(wù)字段，避免嵌套類型的字段溶浴，提高性能

image.png

查詢數(shù)據(jù)

• 從ES 8.x版本開始乍迄，建議使用Java api client，并且要Java 8及以上環(huán)境士败，因為可使用各種lambda函數(shù)闯两，來提高代碼可讀性

  • 優(yōu)點是新客戶端與server代碼完全耦合（相比于原Java transport client，在8.x版本已廢棄）谅将，并且API風(fēng)格與http rest api很接近（相比于原Java rest client漾狼，在8.x版本已廢棄），只要熟練掌握http json請求體寫法饥臂，即可快速上手邦投。
  • 底層使用的還是原來的low level rest client，實現(xiàn)了http長連接擅笔、訪問ES各節(jié)點的負(fù)載均衡志衣、故障轉(zhuǎn)移屯援，最底層依賴的是apache http async client。

• ES 7.x版本及以下念脯，或使用Java 7及以下狞洋，建議升級，否則就只能繼續(xù)用high level rest client绿店。

代碼示例如下（含詳細注釋）：

public class EsClientDemo {

    // demo演示：創(chuàng)建client吉懊，然后搜索
    public void createClientAndSearch() throws Exception {
        // 創(chuàng)建底層的low level rest client，連接ES節(jié)點的9200端口
        RestClient restClient = RestClient.builder(
            new HttpHost("localhost", 9200)).build();

        // 創(chuàng)建transport類假勿，傳入底層的low level rest client借嗽，和json解析器
        ElasticsearchTransport transport = new RestClientTransport(
            restClient, new JacksonJsonpMapper());

        // 創(chuàng)建核心client類，后續(xù)操作都圍繞此對象
        ElasticsearchClient esClient = new ElasticsearchClient(transport);


        // 多條件搜索
        // fluent API風(fēng)格转培，并且使用lambda函數(shù)提高代碼可讀性恶导，可以看出Java api client的語法，同http json請求體非常相似
        String searchText = "bike";
        String brand = "brandNew";
        double maxPrice = 1000;

        // 根據(jù)商品名稱浸须，做match全文檢索查詢
        Query byName = MatchQuery.of(m -> m
            .field("name")
            .query(searchText)
        )._toQuery();

        // 根據(jù)品牌惨寿，做term精確查詢
        Query byBrand = new Query.Builder()
            .term(t -> t                          
                .field("brand")                    
                .value(v -> v.stringValue(brand))
            ).build();

        // 根據(jù)價格，做range范圍查詢
        Query byMaxPrice = RangeQuery.of(r -> r
            .field("price")
            .lte(JsonData.of(maxPrice))
        )._toQuery();

        // 調(diào)用核心client删窒，做查詢
        SearchResponse<Product> response = esClient.search(s -> s
            .index("products")  // 指定ES索引
            .query(q -> q       // 指定查詢DSL
                .bool(b -> b    // 多條件must組合裂垦，必須同時滿足
                    .must(byName)
                    .must(byBrand)
                    .must(byMaxPrice)
                )
            ),
            Product.class
        );

        // 遍歷命中結(jié)果
        List<Hit<Product>> hits = response.hits().hits();
        for (Hit<Product> hit: hits) {
            Product product = hit.source();  // 通過source獲取結(jié)果
            logger.info("Found product " + product.getName() + ", score " + hit.score());
        }
    }

}

可參閱：https://www.elastic.co/guide/en/elasticsearch/client/index.html

數(shù)據(jù)模型轉(zhuǎn)換

因為既有MySQL，又有ES肌索，所以有2種異構(gòu)的數(shù)據(jù)模型蕉拢。需要在代碼中定義2種數(shù)據(jù)模型，并且實現(xiàn)類型互相轉(zhuǎn)換的工具類诚亚。

• MySQL數(shù)據(jù)VO
• ES數(shù)據(jù)VO
• MySQL數(shù)據(jù)VO晕换、ES數(shù)據(jù)VO互相轉(zhuǎn)換工具
• 業(yè)務(wù)層BO
• 接口DTO

原理概要

ES之所以比MySQL，能勝任多維度查詢亡电、全文檢索届巩，是因為底層數(shù)據(jù)結(jié)構(gòu)不同：

• ES倒排索引
  • 如果是全文檢索字段：會先分詞，然后生成 term -> document 的倒排索引份乒，查詢時也會把query分詞恕汇，然后檢索出相關(guān)的文檔。相關(guān)度算法如TF-IDF（term frequency–inverse document frequency）或辖，取決于：詞在該文檔中出現(xiàn)的頻率（TF瘾英，term frequency），越高代表越相關(guān)颂暇；以及詞在所有文檔中出現(xiàn)的頻率（IDF缺谴，inverse document frequency），越高代表越不相關(guān)耳鸯，相當(dāng)于是一個通用的詞湿蛔，對相關(guān)性影響較小膀曾。
  • 如果是精確值字段：則無需分詞，直接把query作為一個整體的term阳啥，查詢對應(yīng)文檔添谊。
  • 因為文檔中的所有字段，都生成了倒排索引察迟，所以能處理多維度組合查詢
• MySQL B+樹
  • B+樹的非葉子節(jié)點記錄了孩子節(jié)點值的范圍斩狱，而葉子節(jié)點記錄了真正的一組值，并且在同一層扎瓶，形成了一個有序鏈表
  • 組合索引需要顯式創(chuàng)建：選擇需索引的字段所踊、并且順序是重要的，所以如果待查詢的字段不在索引中概荷，就無法高效查詢秕岛，可能演變?yōu)槿頀呙?/strong>（對聚簇索引的葉子節(jié)點做一次遍歷）