使用舉例

使用SearchIndex創建索引表時只需要枚舉出索引列名即可，查詢時不需要感知索引表的存在。以下示例介紹如何使用Lindorm CQL操作SearchIndex。

• 原始表

  CREATE TABLE myTable (
      id bigint,
      name text,
      age int,
      sex text,
      city text，
      address text,
      PRIMARY KEY (id)
  ) WITH compression = {'class': 'ZstdCompressor'};

• 索引

  對姓名 (name)、年齡 (age)、性別 (sex)、城市 (city)、地址 (address) 建立全文索引。

  CREATE SEARCH INDEX myIndex ON myTable WITH COLUMNS (name, age, sex, city, address);

  說明

  索引列的先后順序不影響，即索引列 (c3, c2, c1)與索引列 (c1, c2, c3)最終的效果是一致的。

• 查詢

  • 標準查詢語句

    模糊查詢：SELECT * FROM myTable WHERE name LIKE '小%'
    多維查詢排序：SELECT * FROM myTable WHERE city='杭州' AND age>=18 ORDER BY age ASC
    多維查詢翻頁：SELECT * FROM myTable WHERE name='小劉' AND sex=false OFFSET 100 LIMIT 10 ORDER BY age DESC

  • 高級查詢語句

    多維查詢排序：SELECT * FROM myTable WHERE search_query='+city:杭州 +age:[18 TO *] ORDER BY age ASC'
    文本檢索：SELECT * FROM myTable WHERE search_query='address:西湖區'

適用場景

SearchIndex在阿里內部已經成功應用多個業務場景，當前該特性在公有云上已經發布，支持的重要功能列表如下：

• 多維查詢：多個條件任意組合的精確查詢、范圍查詢等。

• 通配符查詢：* 代表任意個字符；? 代表任意單個字符。

• 統計聚合：求最小值、求最大值、求和、求平均值、統計行數。

• 排序分頁：任意索引列的排序輸出。

• 文本分詞：支持中文/英文分詞，分隔符分詞，拼音分詞等。

• 地理位置：距離查詢、長方形/多邊形范圍查詢。

有了這些功能，可以很容易的將Lindorm應用到多樣化的業務場景中，經典的使用場景主要有以下幾個：

• 訂單詳情，例如物流訂單、交易賬單，支持訂單的多維查詢、排序等。

• 標簽畫像，例如基于商家對買家進行標簽圈選，定向投遞信息。

• 文本搜索：例如日志分析，異常信息檢索等。

實現原理

Lindorm作為一款多模數據庫，同時支持多種模型，將搜索引擎與寬表模型深度融合，對外提供簡單易用的SearchIndex，整體的分層架構如下：

• 查詢接入

  由多個QueryProcessor節點組成，主要負責查詢接入，進行SQL解析，基于RBO自動選擇合適的索引。

• 索引預處理

  基于索引列的元信息將新插入或者更新的原始數據轉換為索引數據，并且針對不同的場景可以選擇與之匹配的Mutability屬性，比較典型的例如日常監控，數據寫入后不更新，可以選擇Immutable模式，直接生成索引原始數據；而那些有狀態的數據，大多需要局部更新，此時通過回讀歷史數據組裝成索引原始數據，并且能夠支持業務自定義時間戳的寫入，確保數據不亂序。

• 索引同步

  對于最終一致模式（默認），LTS (Lindorm Tunnel Service)作為Lindorm生態的數據同步服務，具備高效的實時同步和全量遷移能力。可以實時監聽WAL的變化，將索引原始數據轉換后寫入到搜索引擎，同時支持一讀多寫，即一份WAL可以同步到多個索引表中，極大提升同步效率；對于強一致模式，索引原始數據構建完畢后同步寫入到搜索引擎，由搜索引擎實時生成全文索引，為業務提供寫入即可查的強一致體驗。

• 索引引擎

  由多個節點組成的分布式Lucene集群，數據按照Hash或者Range來劃分為多個Shard，對外提供全文檢索能力。

• 索引存儲

  索引數據存儲在分布式文件系統Lindorm DFS上，存算分離的架構具有極好的擴展性，同時存儲層的透明壓縮和智能冷熱分離可以顯著降低索引的存儲成本。

核心特性

SELECT name,id FROM myTable WHERE search_query = '+city:hangzhou +age:[1 TO 18]';

訂單場景

對于物流、第三方支付和移動出行等業務場景，訂單數據的存儲是核心需求。而且訂單數據往往有其特殊的天然屬性。

• 高增長：數據可能隨時會爆發式的增長，例如雙11或大促節日。

• 低成本：訂單數據一般不會直接產生經濟效益，是業務對外呈現的附加價值，需要低成本存儲。

• 多維查詢：對于C端用戶而言，往往會從不同角度對訂單進行分類、標記以及查看和過濾自己的訂單。

在之前，面對上面的訴求，一般的解決方案是MySQL+搜索引擎。業務雙寫到兩個系統中，或者借助binlog進行實時同步，查詢時分別從不同的系統中獲取結果。隨著數據量的增長，可能會演變為MySQL熱數據+Lindorm冷數據+搜索引擎的架構，基于多套系統可以有效解決業務問題，但需要面臨多套系統維護的時間成本和人力成本。

現在，Lindorm可一一站式解決上述問題，不用關心數據的流轉，統一的API訪問。

• 通過冷熱分離、壓縮優化等手段顯著降低存儲成本。

• 橫向彈性擴展適應海量數據的寫入。

• SearchIndex CQL提供豐富的查詢語法。

用戶畫像

用戶畫像的數據一般有兩種：一個是基礎數據，另一個是經過分析得到的標簽數據。這些數據可以被應用到營銷、推薦等場景中，可以助力企業營收快速增長。畫像數據的主要痛點如下：

• 數據量大：畫像數據與用戶基數強相關，往往在千萬甚至億級別，而且數據維度非常高，在我們服務的客戶中，有的場景支持的標簽數在5000個以上。

• 高并發。畫像數據通常需要全量刷新，需要在基線的時間內完成才能有效輔助后續的推薦、廣告投放等。

• 動態列。數據維度在不斷的變化中，因此需要支持動態增/刪列。

• 多維查詢。面向不同的業務需求，畫像數據查詢需求也會有差異，運營人員通常會統計任意一個維度的數據。

畫像場景一般沒有強事務需求，而是大數據量、高并發讀寫的場景，關系數據庫不太適合。Lindorm作為一款NoSQL數據庫，非常適合這樣的場景。

• 多列族、動態列、TTL等特性，適合表結構不固定，經常需要進行變更的業務場景。

• 高性能吞吐。

• SearchIndex CQL支持任意維度的查詢和統計。

日志檢索

日志的來源非常廣泛，例如系統日志、數據庫審計日志、用戶行為日志等，這些數據在互聯網公司中通常存儲于開源Elasticsearch（ES）中，借助ELK體系構建一站式的日志平臺。但ES的存儲成本是非常高的，而且存儲和計算往往需要同機部署，在海量數據下系統運維面臨非常多的挑戰，數據遷移、節點擴縮容等都需要人工介入。多模數據庫Lindorm的SearchIndex是日志檢索場景的更優選擇，通過寬表引擎存儲海量數據降低成本，搜索引擎構建合適的索引加速查詢，統一的API操作進一步降低業務開發成本。