Lindorm:Lindorm SearchIndex の機能の詳解

例

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 'Xiao%'
    ソート付き多次元クエリ: SELECT * FROM myTable WHERE city='Hangzhou' AND age>=18 ORDER BY age ASC
    ページング付き多次元クエリ: SELECT * FROM myTable WHERE name='Xiao Liu' AND sex=false OFFSET 100 LIMIT 10 ORDER BY age DESC

  • 高度なクエリ文

    ソート付き多次元クエリ: SELECT * FROM myTable WHERE search_query='+city:Hangzhou +age:[18 TO *] ORDER BY age ASC'
    テキスト取得: SELECT * FROM myTable WHERE search_query='address:Xihu District'

利用シーン

SearchIndex は、Alibaba 内の複数のビジネスシナリオで成功裏に使用されています。この機能は現在パブリッククラウドで利用可能であり、以下の主要な機能をサポートしています。

• 多次元クエリ：Term クエリ、範囲クエリ、および条件の任意の組み合わせを使用するその他のクエリ。

• ワイルドカードクエリ：* を使用して任意の数の文字を表し、? を使用して任意の単一の文字を表します。

• 統計集約：最小値、最大値、合計、平均値を計算し、行数をカウントします。

• ソートとページング：任意のインデックスキー列で出力をソートします。

• テキストトークン化：中国語/英語のトークン化、デリミタトークン化、ピンイントークン化などをサポートします。

• 地理位置情報：距離クエリおよび矩形/多角形範囲クエリ。

これらの機能により、Lindorm をさまざまなビジネスシナリオに適用できます。一般的なユースケースは次のとおりです。

• 注文詳細：物流注文、取引請求書など。注文の多次元クエリとソートをサポートします。

• ユーザーペルソナとタギング：例えば、企業は購入者を選択してタグ付けし、ターゲットを絞った情報を配信できます。

• テキスト検索：例えば、ログ分析や異常情報の取得など。

仕組み

複数のモデルをサポートするマルチモーダルデータベースとして、Lindorm は検索エンジンとワイドテーブルモデルを深く統合し、直感的で使いやすい SearchIndex 機能を提供します。全体的な階層アーキテクチャは次のとおりです。

• クエリアクセス

  複数の QueryProcessor ノードで構成されるこのレイヤーは、クエリアクセス、SQL 解析、およびルールベース最適化 (RBO) に基づく適切なインデックスの自動選択を担当します。

• インデックス前処理

  このレイヤーは、新しく挿入または更新された生データを、インデックスキー列のメタデータに基づいてインデックスデータに変換します。さまざまなシナリオに応じて、適切な Mutability プロパティを選択できます。例えば、データが書き込まれた後に更新されない日次モニタリングでは、Immutable モードを使用して生インデックスデータを直接生成できます。部分的な更新が頻繁に必要なステートフルなデータの場合、既存データを読み取って完全な生インデックスデータを構築します。このレイヤーは、カスタムタイムスタンプを持つデータの書き込みもサポートし、データが正しい順序で処理されることを保証します。

• インデックス同期

  結果整合性モデル (デフォルト) の場合、Lindorm エコシステムのデータ同期サービスである Lindorm Tunnel Service (LTS) は、効率的なリアルタイム同期と完全移行機能を提供します。先行書き込みログ (WAL) の変更をリアルタイムで監視し、生インデックスデータを変換して検索エンジンに書き込むことができます。また、1回の読み取りで複数回の書き込みもサポートしており、1つの WAL を複数のインデックステーブルに同期できるため、同期効率が大幅に向上します。強力な整合性モデルの場合、生インデックスデータは構築後に検索エンジンに同期的に書き込まれます。その後、検索エンジンはリアルタイムでフルテキストインデックスを生成し、データが書き込まれた直後に検索可能になる強力な整合性を提供します。

• インデックスエンジン

  複数のノードで構成される分散 Lucene クラスター。データはハッシュまたは範囲によって複数のシャードにパーティション分割され、フルテキスト検索機能を提供します。

• インデックスストレージ

  インデックスデータは、分散ファイルシステム Lindorm DFS に保存されます。ストレージとコンピュートを分離するアーキテクチャは、優れたスケーラビリティを提供します。同時に、ストレージレイヤーでの透明な圧縮とインテリジェントなコールド・ホットデータ分離により、インデックスストレージコストを大幅に削減できます。

コア機能

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

注文シナリオ

物流、サードパーティ決済、モバイル旅行などのビジネスにとって、注文データの保存はコア要件です。注文データには、しばしば独自の特徴があります。

• 高い成長率：「独身の日」(Double 11) ショッピングフェスティバルやその他の大規模なセールプロモーション中など、データはいつでも爆発的に増加する可能性があります。

• 低コスト：注文データは一般的に直接的な経済的利益を生み出すものではなく、ビジネスの顧客にとっての付加価値です。したがって、低コストで保存する必要があります。

• 多次元クエリ：エンドユーザーは、さまざまな視点から注文を分類、タグ付け、表示、フィルターすることがよくあります。

以前は、これらの要件に対する一般的なソリューションは、MySQL と検索エンジンを組み合わせたものでした。ビジネスは両方のシステムに書き込むか、binlog を使用してリアルタイム同期を行いました。クエリは、異なるシステムから結果を取得しました。データ量が増えるにつれて、このアーキテクチャはホットデータ用に MySQL、コールドデータ用に Lindorm、そして検索エンジンという形に進化する可能性がありました。このマルチシステムアプローチはビジネス上の問題を解決できますが、複数のシステムを維持するための時間と労力のコストが伴います。

Lindorm は、これらの問題に対するワンストップソリューションを提供し、データフローを管理する必要性をなくし、アクセス用の統一された API を提供します。

• コールド・ホットデータ分離、圧縮最適化などの方法により、ストレージコストを大幅に削減します。

• 水平スケーリングにより、大量のデータ書き込みに対応します。

• SearchIndex CQL は、豊富なクエリ構文を提供します。

ユーザーペルソナ

ユーザーペルソナデータは、一般的に基本データと分析から派生したタグデータの2種類があります。このデータは、マーケティング、レコメンデーションなどのシナリオに適用でき、ビジネスの急速な収益成長を支援します。ペルソナデータの主な課題は次のとおりです。

• 大規模なデータ量：ペルソナデータはユーザーベースと強く相関しており、しばしば数千万から数億レコードに達します。データには非常に多くのディメンションもあります。一部の顧客シナリオでは、5,000 を超えるタグをサポートします。

• 高並行性：ペルソナデータはしばしば完全更新が必要であり、これは後続のレコメンデーションや広告配信などを効果的にサポートするために、ベースライン時間内に完了する必要があります。

• 動的カラム：データのディメンションは絶えず変化するため、システムは列の動的な追加と削除をサポートする必要があります。

• 多次元クエリ：ペルソナデータのクエリニーズは、ビジネス要件によって異なります。運用担当者は、しばしば任意のディメンションからのデータに対して統計を実行する必要があります。

プロファイルシナリオは、一般的に強力なトランザクションを必要としません。これらは、大規模なデータ量と高並行性の読み取り/書き込みが特徴であり、この組み合わせはリレーショナルデータベースには適していません。NoSQL データベースである Lindorm は、これらのシナリオに最適です。

• 複数のカラムファミリー、動的カラム、TTL などの機能は、テーブルスキーマが固定されておらず、頻繁に変更されるビジネスシナリオに適しています。

• 高性能スループット。

• SearchIndex CQL は、任意のディメンションでのクエリと統計をサポートします。

ログ検索

ログは、システムログ、データベース監査ログ、行動ログなど、さまざまなソースから得られます。インターネット企業では、このデータはオープンソースの Elasticsearch (ES) に保存され、ELK スタックを使用してワンストップのロギングプラットフォームを構築することがよくあります。しかし、ES のストレージコストは非常に高く、ストレージとコンピュートはしばしば同じマシンに同居しています。大量のデータ量では、システムの運用保守は多くの課題に直面します。データ移行、ノードのスケーリングなどのタスクには手動介入が必要です。マルチモーダルデータベースである Lindorm の SearchIndex 機能は、ログ検索シナリオにとってより良い選択です。ワイドテーブルエンジンを使用して大量のデータを保存し、コストを削減し、検索エンジンを使用してインデックスを構築し、クエリを高速化します。統一された API は、ビジネス開発コストをさらに削減します。