2GISの腸には、InfoRussiaプロジェクトがあります。これにより、オペレーターは組織のカードを呼び出して検証します。 データベースには、ロシアの組織に関するデータを含む400万枚のカードが含まれており、その合計サイズは150 GBを超えています。 データはリレーショナルデータベースに格納され、一部はテーブルに、一部はxmlフィールドに配置されます。
解決する必要がある問題とタスクのリスト：
1.多数の基準で検索します。
2.完全なインデックス再作成を行わずに、インデックスに情報を追加します。
3.テーブルをロックせずにデータをアップロードします。
4.ベースの負荷を減らし、大きな結合テーブルを削除します。
5.開発に大きな投資をすることなく、多言語検索をサポートします。
利用可能なソリューションを分析した後、ほとんどの要件を満たしているため、Elasticを選択しました。
分析に基づいて、要件は次のとおりでした。
機能要件：
- 基準による検索（単一の値または値のリストの完全一致）。
- 範囲（数字、日付）で検索します。
- 全文検索（形態、テンプレート（ワイルドカード））。
- ブール検索（AND / ORによる検索条件の組み合わせ）。
非機能要件：
- 信頼性（分散インデックスのサポート）。
- スケーラビリティ（複数のサーバーに配布し、必要なすべてのインフラストラクチャをすぐにサポートする機能）。
- 「リアルタイム」モードでのインデックス作成（新しいデータは、「合理的な」時間内にインデックスを完全に再構築する必要がないため、インデックスを作成する必要があります）。
- 構成可能性（特に、追加の属性にインデックスを付けるには、完全な再構築を必要とせずにインデックスに新しいフィールドを追加する必要があります）。
- 使いやすさ（目的のプラットフォーム/言語の「クライアント」の存在、HTTPなどのパブリックプロトコルの使用）。
- パフォーマンス（300人のオンラインオペレーターの負荷、データ量-ロシア全体で提供される応答時間）。
- 所有コスト/サポート。
検索エンジンの役割の主な候補者は、ElasticSearch、Solr、およびSphinxです。
Solrは適合しませんでした。なぜなら、オンラインインデックス作成では、検索速度が大幅に低下するからです（詳細については、 記事を参照してください ）。 次の図は、この事実を示しています。 SolrとElasticSearchを詳細に解析する記事を読むこともできます。
次にレビューした候補はSphinxです。 ElasticSearchは、シャーディング、レプリケーション、複雑なクエリを作成し、検索から元のデータを抽出する機能のサポートにより勝ちました。
検索する
ESに基づいて検索するために作成された非常に最初のプロトタイプは非常に優れていることが判明したため、すぐに戦闘アプリケーションに移動し、そこに住んでいます。
プロジェクトが始まったばかりのとき、ESにはまだRiverメカニズムがなかったため、データベースのインデックスを再作成するジョブを作成しました。
サービスは、変更されたエンティティに関するデータを取得し、キュー全体を処理するまでESインデックスに追加します。 高速ロードのために、次の最適化を適用できます。
1.一括操作を使用します。
2. refresh_intervalパラメーターを-1に設定します。
このパラメーターは、ESの内部再インデックスの時間を担当します。 すべてのデータが検索に読み込まれた後、デフォルト値を返す必要があります。 この方法を使用すると、ダウンロードしたものはすべて分析されないため、内部のインデックス再作成が行われるまで検索できません。
私たちのプロジェクトの検索はオンラインで索引付けされ、一度に100枚のカードが索引付けされます。
データがインデックスに登録されたら、検索できます。
Elastic Searchを使用して、さまざまなパラメーターによる迅速な検索を必要とする問題を解決します。
たとえば、データベースに400万枚のカードがある場合、すべてのカード電話を調べて同じ電話を見つける必要があります（データスキームでは、電話はxmlフィールド内に格納されます）。 このようなMS SQLデータベースへのクエリには、最大10〜15分かかります。 Elastic Searchはこのタスクを数ミリ秒で処理します。
そのため、Elastic Searchの使用を決定した主なケース：
同じアドレスを持つカードを検索します（カード編集ウィンドウで）
建物内に新しいカードが確立されると、オペレーターはこの建物内の他の組織を確認し、近くにある組織の情報を確認できます。
同じ電話番号のカードを検索します
また、1つの電話番号で複数の組織を確認できるため、同じ連絡先を持つ他のカードを示します。
検索フォームの検索カード
とりわけ、アプリケーションには膨大な数の基準で検索できる検索フォームがあります。 このフォームは、組織の調整の計画、品質管理などに使用されます。
各タブには、検索エンジンへのクエリ用の4〜5個のパラメーターがあります。
このような多数のフィールドでリレーショナルデータベースにインデックスを構築するのはかなり無駄です。そのため、Elasticはこの問題の解決に役立ちました。
データのアップロード
アプリケーションのビジネスケースの1つは、Excelへのデータのアップロードのサポートです。 アンロードは、収集されたデータの品質を分析し、情報収集の専門家の作業を計画するために、さまざまな専門家によって使用されます。
Excelの検索からデータをエクスポートするには、ESも使用します。 Elasticはデータを取得するための特別なモードであるスクロールをサポートしているため、これは非常に便利です。
スクロールモードでは、検索クエリの結果を「修正」し、これらの結果を少しずつ取得できます。
このモードには多くの制限があります。 たとえば、データを並べ替えることはできません（実際、できますが、パフォーマンスとメモリ消費が低下します）。
テストの結果、1日で2GISデータベース全体をExcelファイルにアップロードできることがわかりました。
このような大量のアンロードを整理する場合、リポジトリ内のすべての必要なデータの可用性は非常に重要です。 したがって、ElasticをNoSQLストレージとして使用します。NoSQLストレージでは、アップロードにのみ必要なデータがインデックス化できないフィールドに格納されます。
スクリーンショットは、インデックスに非正規化データが含まれていることを示しており、都市IDとその名前をカードとともに保存します。
さらに、組織が置かれている勤務時間や見出しなど、ネストされたエンティティを作成できます。
ヨーロッパ言語のサポート
このアイテムを個別にマークする必要があります。 少し前、2GISはいくつかの国際プロジェクトを立ち上げました。 プラハ 、 リマソール 、 パドヴァをサポートするために、検索クエリを絞り込む必要はありませんでした。 カードをインデックスにロードしたところ、検索自体が機能しました。
最近、発音区別記号に基づく検索をサポートするために、少し洗練されたクエリがありますが、実際には、これは組み込みのElastic関数です。
信頼性と弾力性
Elasticは、シャーディングとクラスター内の複数ノードのインストールの両方をサポートしています。 これで、オンラインで300人にサービスを提供する2つのノードのクラスターを組み立てました。
2年間の運用で、検索エンジンの問題は、仮想マシンの崩壊またはインフラストラクチャのその他の問題が原因でのみ発生しました。 他の検索エンジンと同様に、Elasticは優れたドライブとRAMが大好きなので、ストレステスト中はこれらのパラメーターに特に注意することをお勧めします。
おわりに
Elastic Searchは、検索エンジンの要件を完全に満たし、重要なビジネス機能をできるだけ早く実装できるようにしました。 信頼性、スピード、使いやすさ-これらは用語であり、それらを組み合わせることで彼の方向に選択をすることができました。 もちろん、市場にはこの記事の範囲を超えた他のソリューションがあります。 この記事の目的は、無料のElastic Searchを使用してビジネスアプリケーションのどのタスクを閉じることができるかを示すことでした。
Elasticの前向きな経験を考慮して、他の内部チームはプロジェクトでこの検索エンジンの使用を開始しました。