ElasticSearch相信有不少朋友都瞭解，即使沒有了解過它那相信對ELK也有所認識E即是ElasticSearch。ElasticSearch最開始更多用於檢索，作為一搜索的叢集產品簡單易用絕對是一個非常不錯的選擇，其實本人早在ElasticSearch v0.2的時候就使用，一轉眼數年過去現在都7.X了。

        其實ElasticSearch除了提供強大的叢集化搜尋服務外，它提供一個aggregation功能會再一次讓你受到它的強大，aggregation是一個數據統計彙總功能，表面上這功能在關係資料庫上也可以做，但結合分詞建維度就更能體現出它的靈活之處。

關係資料庫問題

        拿產品訂單為例，它有產品分類，不同的規格，銷售人，客戶和地區等；然而這些資訊在設計上都是歸納到不同的表中，如果要針對這些不同的資訊來統計訂單銷售情況那相信是一件非常繁瑣和效率極其低下的工作（先不說資料數千萬了上億或更大規模，就算幾十上百萬資料這個關係資料的SQL查詢也夠受了）。即便可以把資料抽取並歸納起來做統計，但隨著新的資料維度增加新的維度欄位重新呼叫。

無維度欄位？

        在資料統計每個維度都對一個資訊列來儲存，這樣加入維度必須就需要新增資訊列。如果用一個欄位儲存所有維度資訊呢？顯然這種想法在傳統關係資料庫中也不可能的，因為無法做表的關聯和維度區分，其實不要說傳統資料庫很多資料庫都無法在一個字元中拆分出不同的維度出來，除非加入程式來切分，但這種法在資料規模大的情況必然是不可取的!

        如果用一個欄位就能儲存所有維度，那就意味著以後加入新的維度資料也無須調整結構和程式就實現新維護度資料的統計處理。這看上去多麼美好，似乎也很難實現，但ElasticSearch能解決這一問題。

試驗

        首先ElasticSearch是一個搜尋引擎，它最擅長的工作是對內容進行分詞並構建索引；在這機制下可以對一個欄位的資訊進行拆分並存儲到索引上。通過這一特性同樣可以把一個欄位的資訊切分成N個維度的資訊，然後儲存到索引；只要有了單一的維度索引那接下來針對不同維護的彙總統計就簡單了。

在單節點的ElasticSearch上建立了5千萬條產品銷售資料；然後Tag欄位儲存對應的維度資訊，每個維度通過/來區分，分別有:customer,employee,country和category.有了這些資訊，接下來的工作是嘗試使用Aggr功能來完成相應的彙總

var query = db.Index.CreateQuery();
query.Prefix("Tag", "客戶");
var aggs = db.Index.CreateAggs("customer_group", 
     Elasticsearch.Search.AggsType.terms, "Tag");
aggs.SubAggs("sum_quantity", Elasticsearch.Search.AggsType.sum, "Quantity");
aggs.SubAggs("sum_total", Elasticsearch.Search.AggsType.sum, "Total");
aggs.Size(5);
aggs.Query = query;
var items = await aggs.Execute<OrderRecord>();

程式碼並不複雜，查詢Tag標籤存在customer的資料，並對它們進行一個分組，最後再彙總出對應的Quantity和Total資訊；最後獲取排在最前面的5條資料。

效率

        ElasticSearch做這方面的效率怎樣呢？部署在一個節點上，分別彙總了客戶，國家和員工。

5千萬條(單機單節點)

5千萬條(單機雙節點)

 這個時間是在不停更新索引下同時做統計的結果，當在索引不更新的情況其二次處理效率會高上幾倍。

靜態歷史資料

        上面紹了ElasticSearch對大資料一個聚合效率做了一個測試，那測試是基於動態資料測試，即在聚合測試的過程中同時大量更新索引資料；接下來做的測試則是針對固定的歷史資料，在聚合測試過程中不進行資料更新。

測試資料環境

        5千萬條件產品銷售資料，分佈在2000-2020間，所有資料部署在單機雙節點的服務中。

測試過程

        分別彙總每一年的員工，國家和分類資料，並顯示最前面的3條記錄。

int top = 3;
for (int i = 2000; i < 2020; i++)
{
    DateTime start = new DateTime(i, 1, 1);
    DateTime end = new DateTime(i + 1, 1, 1);
    var result = await db.AggsTag("國家", top, start, end, null);
    Console.WriteLine($"|  {result.Title} use {result.UseTime:###,###.00}ms");
    Console.WriteLine($"|-{"".PadLeft(89, '-')}|");
    foreach (SummaryItem item in result.Items)
    {
        Print(item);
    }

    result = await db.AggsTag("分類", top, start, end, null);
    Console.WriteLine($"|  {result.Title} use {result.UseTime:###,###.00}ms");
    Console.WriteLine($"|-{"".PadLeft(89, '-')}|");
    foreach (SummaryItem item in result.Items)
    {
        Print(item);
    }

    result = await db.AggsTag("員工", top, start, end, null);
    Console.WriteLine($"|  {result.Title} use {result.UseTime:###,###.00}ms");
    Console.WriteLine($"|-{"".PadLeft(89, '-')}|");
    foreach (SummaryItem item in result.Items)
    {
        Print(item);
    }
}

測試結果

 從測試結果來看效率非常出色，每個年分類聚合統計所損耗的時候大概在0.1