背景

現在、クラウドコンピューティングとデータは急速に成長しています。今日のアプリケーションはペタバイト（PB）やZB（Zerobyte）単位の速度でデータを生成しており、さらに高速で高いパフォーマンスを求める声は高まり続けています。データが蓄積されるにつれて、これらのデータを迅速かつ効果的に検索することが、バックエンドサービスにとって大きな課題となっています。この記事では、業界で最も人気のある2つのオープンソース検索エンジン、SolrとElasticSearchを比較します。どちらもApache Luceneオープンソースプラットフォーム上に構築されており、主要な機能は非常に似ていますが、導入の容易さ、スケーラビリティ、その他の機能に関しては大きく異なります。

エラストシサーチ

導入

Elasticsearchは、分散型のRESTful検索・データ分析エンジンです。Javaで開発され、Apacheライセンスの下でオープンソースとして公開されており、エンタープライズグレードの検索エンジンとして人気を博しています。Elasticsearchはその使いやすさから急速に多くのユーザーを獲得し、ウェブサイト検索、ログ分析、その他多くのアプリケーションに利用されています。強力な水平スケーリング機能を備えているため、ElasticsearchをNoSQLデータベースとして直接利用するユーザーも少なくありません。

特性

• 検索エンジン: Elasticsearch を使用すると、さまざまな種類の検索 (構造化データ、非構造化データ、地理的位置、メトリック) を実行および組み合わせることができるため、検索エクスペリエンスをカスタマイズできます。
• 分析エンジン：そうです、数十億行ものログを処理します。Elasticsearchのアグリゲーション機能により、データの全体像を把握し、傾向やパターンを探索できます。
• 検索パフォーマンス: 有限状態トランスフォーマーを使用して全文検索用の転置インデックスを実装し、数値および地理データを格納するための BKD ツリーを実装し、分析用の列ストレージを実装しました。
• スケーラビリティ: 水平方向に拡張でき、1 秒あたり大量のイベントを処理し、クラスター全体でのインデックスとクエリの分散を自動的に管理して、非常にスムーズな操作を実現します。
• 検索機能：検索結果は、キーワードの出現頻度や最新性、人気度など、様々な要素に基づいて並べ替えられます。これらの要素は他の機能と組み合わせることで、ユーザーへの表示を最適化します。
• データ フォールト トレランス: クラスター間のレプリケーションにより、補助クラスターをいつでもホット バックアップとして使用できます。
• リアルタイムのインタラクション: ワッフル チャートやヒートマップから時系列データ分析まで、Kibana の魅力的な視覚化機能を使用してデータを探索します。

データ構造

• インデックス：インデックスはドキュメントのコンテナであり、特定の種類のドキュメントのコレクションです。従来のリレーショナルデータベースと同様に、インデックスはSQLにおけるデータベースに相当します。
• タイプ: バージョン6.0.0以降、1つのインデックスには1つのタイプしか設定できません。これはバージョン7.0.0以降では推奨されず、バージョン8.0.0以降では完全にサポートされません。
• ドキュメント: ドキュメントインデックス内の単一のレコードはドキュメントと呼ばれます。これは、リレーショナルデータベースのテーブル内の行に相当します。
• フィールド: 属性はリレーショナルデータベースのフィールドに似ています。各属性には、コア型、複合型（オブジェクト型とネスト型）、地理型、特殊型など、独自の型があります。

クラスタ

Elasticsearch は、ペタバイト規模のデータ処理に対応しながら、数百（あるいは数千）規模のサーバーノードに水平方向に拡張できます。Elasticsearch の基本原則は、可用性とオンデマンドのスケーリングです。スケーリングは、より高性能なサーバーを購入するか（垂直スケーリング）、サーバーを追加することで実現できます（水平スケーリング）。Elasticsearch はより強力なハードウェアの恩恵を受けることができますが、垂直スケーリングには限界があります。真のスケーリング機能は、水平スケーリング、つまりクラスターにノードを追加し、負荷と安定性をノード間に分散させることで実現されます。ほとんどのデータベースでは、水平スケーリングによって増加するリソースを活用するには、通常、アプリケーションの大幅な変更が必要になります。対照的に、Elasticsearch は本質的に分散型です。複数のノードを管理することで、スケーラビリティと可用性を向上させることができます。つまり、アプリケーション側でこの点を気にする必要はありません。

クラスターは次の機能をサポートします。

• クラスターの健全性
• フェイルオーバー
• 水平方向の拡大
• 障害への対応

ソル

導入

Solrは、Luceneを基盤として構築された、高性能なJavaベースの全文検索サーバーです。Luceneを拡張し、より豊富なクエリ言語、柔軟な設定、スケーラビリティ、パフォーマンス最適化、そして包括的な管理インターフェースを提供することで、優れた全文検索エンジンとなっています。Apache Solrは成熟したプロジェクトであり、2006年にオープンソースとして初めてリリースされ、長年にわたり検索分野を席巻してきました。その後、2010年頃にElasticsearchが新たな選択肢として市場に登場しました。

特徴

• RESTful API: Solrとの通信には、RESTfulサービスを使用できます。XML、JSON、CSVなどの形式のファイルを入力ドキュメントとして使用し、同じファイル形式で結果を取得できます。
• 全文検索: Solr は、トークン、フレーズ、スペルチェック、ワイルドカード、オートコンプリートなど、全文検索に必要なすべての機能を提供します。
• エンタープライズ対応: Solr は、企業または組織のニーズに応じて、スタンドアロン、分散、クラウドなど、あらゆるタイプのシステムに導入できます。
• 柔軟でスケーラブル: Solr コンポーネントは、Java クラスを拡張し、それに応じて構成することでカスタマイズできます。
• NoSQL データベース: Solr は大規模な NoSQL データベースとして使用でき、検索タスクをクラスター全体に分散できます。

建築

Apache Solrの主な構成要素（コンポーネント）

• リクエストハンドラ – Apache Solr に送信されたリクエストは、これらのリクエストハンドラによって処理されます。リクエストには、クエリリクエストまたはインデックス更新リクエストがあります。リクエストハンドラは、これらのリクエストの要件に基づいて選択されます。リクエストを Solr に渡すために、通常、ハンドラは特定の URI エンドポイントにマッピングされ、指定されたリクエストを処理します。
• 検索コンポーネント - 検索コンポーネントは、Apache Solr で提供される検索タイプ（機能）です。スペルチェック、クエリ、ファセット、ヒットのハイライト表示などが含まれます。これらの検索コンポーネントは検索ハンドラーとして登録されます。1つの検索ハンドラーに複数のコンポーネントを登録できます。
• クエリパーサー（Apache Solrクエリパーサー）は、Solrに渡されたクエリを解析し、クエリ構文にエラーがないか検証します。解析後、クエリをLuceneが理解できる形式に変換します。
• レスポンスライター - Apache Solrのレスポンスライターは、ユーザークエリに対してフォーマットされた出力を生成するコンポーネントです。SolrはXML、JSON、CSVなどのレスポンス形式をサポートしています。レスポンスの種類ごとに異なるレスポンスライターが使用されます。
• アナライザー/トークナイザー - Luceneはトークンの形式でデータを識別します。Apache Solrはコンテンツを分析し、トークンに分解してLuceneに渡します。Apache Solrのアナライザーはフィールドのテキストを検査し、トークンのストリームを生成します。トークナイザーはアナライザーによって生成されたトークンストリームをトークンに分解します。
• 更新リクエストハンドラー - Apache Solrに更新リクエストが送信されると、そのリクエストは更新リクエストハンドラーと呼ばれるプラグインセット（署名、ログ記録、インデックス作成）によって処理されます。このハンドラーは、フィールドの削除や追加などの変更処理を担当します。

要約

Solrはテキスト検索に重点を置いているのに対し、Elasticsearchは統計分析のためのクエリ、フィルタリング、グループ化によく使用されます。では、SolrとElasticsearchのどちらを選ぶべきでしょうか？明確な答えを見つけるのは難しい場合があります。どちらを選ぶにせよ、まずは適切なユースケースと将来の要件を理解し、それぞれの特性をまとめる必要があります。

• 分散インデックスが必要な場合は、Elasticsearch が最適な選択肢です。優れたスケーラビリティとパフォーマンスが求められるクラウド環境や分散環境の場合は、Elasticsearch はさらに優れた選択肢となります。
• Solrでは、インデックスを結合するには、ドキュメント間の関係性（SQL結合など）を検索するために、単一のシャードを他のノードのレプリカセットに関連付ける必要があります。しかし、Elasticsearchでは、このような関連ドキュメントを取得するための、より効率的なhas_childrenクエリとtop_childrenクエリを提供しています。
• どちらも優れた運用ツールを備えていますが、Elasticsearch は使いやすい API を備えているため、DevOps 担当者が多く、Elasticsearch を中心により活気のあるツールのエコシステムを構築できます。
• オープンソースのログ管理のユースケースではElasticsearchが主流であり、多くの組織がElasticsearchでログをインデックス化して検索可能にしています。現在ではSolrもこの目的に使用できますが、Solrは必ずしもその目的を達成できるわけではありません。
• Solrはよりテキスト指向です。一方、Elasticsearchは、必ずしもテキスト検索というよりも、フィルタリングやグループ化、クエリワークロードの分析によく使用されます。
• Elasticsearchの開発者は、LuceneとElasticsearchの両方のレベルで、このようなクエリをより効率的に（メモリ使用量とCPU使用量を削減）するために多大な努力を注いできました。そのため、テキスト検索だけでなく、複雑な検索時の集計を必要とするアプリケーションには、Elasticsearchの方が適しています。
• Elasticsearchは習得が簡単で、一度ダウンロードしてコマンド一つで全てを稼働させることができます。Solrは従来、より多くの作業と知識を必要としていましたが、近年ではその負担を軽減する大きな進歩を遂げており、今やその評判を変えるために努力するだけです。
• Elasticsearchは1つのプロセスのみで構成されているため、運用面では比較的シンプルです。Elasticsearchに似た完全分散型デプロイメントモデルであるSolrCloudでは、Apache ZooKeeperが採用されています。ZooKeeperは非常に成熟しており、広く利用されていますが、依然としてアクティブなコンポーネントとして残っています。ElasticsearchにはZooKeeperに似たコンポーネントであるXenが組み込まれていますが、ZooKeeperはElasticsearchクラスターで時折発生する恐ろしいスプリットブレイン問題に対するより優れた保護機能を提供します。
• Solrは、XMLファイル、カンマ区切り（CSV）ファイル、データベース内のテーブルから抽出されたデータ、Microsoft WordやPDFなどの一般的なファイル形式など、様々なソースからのデータを受け入れます。Elasticsearchは、Git、JDBC、JMS、Kafka、LDAP、MongoDBなど、他のソースからのデータもサポートしています。また、様々なプラグインも利用可能です。