Elastic Search初識のツッコミ
3488 ワード
#サマリー#
Elastic Searchに対する初期印象は全文検索であり,SOLRと競合している.他のストレージ型データベースとどのような違いがあるのか、なぜ他のデータベースがテキスト検索機能を提供しているのか、ESが必要なのかなど、一連の問題は心の中で困惑しています.この文章は主にこれらの問題とElastic Searchの概括的な紹介をまとめている.
ESリソース
ESダウンロード:https://www.elastic.co/downloads/elasticsearchES文書:https://www.elastic.co/guide/en/elasticsearch/reference/current/index.htmlESソース:https://github.com/elastic/elasticsearchES中国フォーラム:https://elasticsearch.cn/
ES紹介
ElasticはApacheV 2ベースのオープンソースシステムであり、分散、リアルタイムのドキュメントインデックス、オンライン分析を提供することができます.Schema free.
専有名詞
マッピング(Mappings)
リレーショナル・データベースのschemasであり,ESが事前に明確にデータのタイプを指定しなくてもよい点が異なる.
インデックス(indexes)
こちらのインデックスは通常の意味でのインデックスとは少し異なり、こちらのインデックスはESの専門名詞であり、関係型データベースにおけるdatabaseを表す論理ネーミングである.
タイプ(Type)
関係型データの表の意味です
クラスタアーキテクチャ
プライマリノード
クラスタには1つしかなく,クラスタ全体の協調ノードである.ダウンが落ちると、自動的に選挙から1つ出ます.インデックスの削除など、クラスタレベルの操作を担当します.どのノードを追跡するときにクラスタの一部は,どのshardがどのノードに割り当てられるかを決定する.
データノード
Luceneのインデックススライスを保存し、ESの分散インデックスを構成する
接待ノード(ingest node)
これは前処理を実行できるpipelineの仕事です.
ノードのみの調整
ルーティングのみを担当し、search reduceフェーズを処理します.
デフォルトでは、1つのノードのロールがあります.クラスタが拡大した場合、ロールを分割したい場合は、あるロールにdisableして、あるノードに1つのことしかできません.
マスターでもdataノードでも構いません
ツッコミ:ESがうまくいかないと思って、明確なクラスタ拡張トポロジー図はありません.例えば、データ規模が小さい場合、すべてのノードが各キャラクタであり、データ量が大きい場合に特定のキャラクタを区別するという実際の操作は現実的ではなく、いつデータ量が大きいかを特定することができ、いつ特定のキャラクタがすべての角色よりも効率的である.また,スイッチング中にどのようにスイッチングする必要があるか,ESはresharding,およびスライス分裂をサポートしない.インデックスも移行できず、どのようにロール変換を行うことができますか.また、coordinate nodeが分割されると、クライアント接続ノードが更新されます.
ES初認識
スライス
ノードレベルに基づくスライスはなく,mongoとは異なりcassandraのpartitionと類似している.id hashでスライスします.shard numberはindexの作成の最初に指定する必要があります.後期に変更するにはreindexが必要です.
分散クエリー
分散クエリーは、各shardをクエリーし、結果を組み合わせて、各shard上のクエリーを並列に行うことができますが、shard numberがノード数より多い場合は、同じノードでシリアルに実行する必要があり、効率が低下します.一般に単一ノード上のshardは2個を超えない,すなわちindexのshard numberは10に設定され,ノードレベルが20個に拡張されるとそれほど差がない.
政府はshard分裂を支持しない理由について shard分裂はreindex dataであり、このプロセスはshardを1つのノードcopyから別のノードに比較すると より重い.分裂は指数的で、1分2、2分4、4分8であり、50% のみの拡張は許されない. shard分裂は、2番目のインデックスを保存するのに十分な能力を必要とします.通常、拡張が必要であることに気づいた場合、スライスをサポートするのに十分な空間がない可能性があります.
ESのreindexプロセスも比較的重いプロセスであり、同じように十分なスペースが必要ですが、少なくとも新しいインデックスのインデックス数を制御することができます.
ツッコミ:このスライスメカニズムは、ESのデザインがあまりにも腐っていて、使用者にとって、MySQLのような自分で実現するのではなく、自動スライスの意味は初期のスライスだけでなく、もちろん拡張に対する要求も含まれています.利用者はどのように自分のデータ規模の増加の上限を知っていて、どのように最初の時にどれだけのスライスを使うかを知っていて、reindexingはデータ量の大きい情況の下で、完全に災難で、もちろんこの部分の仕事を日常的に解決するべきです.
索引
ESのインデックスは逆インデックスであり、これは一般的なB-Treeインデックスとは異なり、ESが全文検索エンジンである理由でもある.B-Treeインデックスの場合はフィールドのソートであり、曖昧なクエリー、例えばlikeに対してはインデックスを調べることができないが、逆インデックスの場合は逆インデックスであり、まず分詞を行い、その後、単語がどのフィールドに現れるかを記録する.これは、一般的なデータベースが全文検索エンジンを提供できない理由です.
NoSQLデータベース
ESはNoSQLデータベースとしても使用されています.デフォルトでは元のデータが保存されており、transaction logがあり、データを失わないことを保証しています.他のqueryは豊富で、一部のgroupbyはaggregationで実現できます.一部のユーザーはBI分析をしています
まとめ
ESは使いやすく、使いやすいです.RESTFUL APIインタフェース、JSONドキュメントストレージを提供し、呼び出しが便利です.全文検索としては選択肢であり,solrとの区別はしばらく不明である.NoSQLデータベースストレージとして、クエリーが豊富でデータ量が多くなく、クラスタ規模が大きくない場合に選択できますが、クラスタ拡張能力が不足し、スライスポリシーに欠陥があります.大規模なデータストレージでは使いにくい.
リファレンス
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html
https://www.elastic.co/guide/en/elasticsearch/guide/current/overallocation.html
https://blog.insightdatascience.com/anatomy-of-an-elasticsearch-cluster-part-i-7ac9a13b05db
Elastic Searchに対する初期印象は全文検索であり,SOLRと競合している.他のストレージ型データベースとどのような違いがあるのか、なぜ他のデータベースがテキスト検索機能を提供しているのか、ESが必要なのかなど、一連の問題は心の中で困惑しています.この文章は主にこれらの問題とElastic Searchの概括的な紹介をまとめている.
ESリソース
ESダウンロード:https://www.elastic.co/downloads/elasticsearchES文書:https://www.elastic.co/guide/en/elasticsearch/reference/current/index.htmlESソース:https://github.com/elastic/elasticsearchES中国フォーラム:https://elasticsearch.cn/
ES紹介
ElasticはApacheV 2ベースのオープンソースシステムであり、分散、リアルタイムのドキュメントインデックス、オンライン分析を提供することができます.Schema free.
専有名詞
マッピング(Mappings)
リレーショナル・データベースのschemasであり,ESが事前に明確にデータのタイプを指定しなくてもよい点が異なる.
インデックス(indexes)
こちらのインデックスは通常の意味でのインデックスとは少し異なり、こちらのインデックスはESの専門名詞であり、関係型データベースにおけるdatabaseを表す論理ネーミングである.
タイプ(Type)
関係型データの表の意味です
クラスタアーキテクチャ
プライマリノード
クラスタには1つしかなく,クラスタ全体の協調ノードである.ダウンが落ちると、自動的に選挙から1つ出ます.インデックスの削除など、クラスタレベルの操作を担当します.どのノードを追跡するときにクラスタの一部は,どのshardがどのノードに割り当てられるかを決定する.
データノード
Luceneのインデックススライスを保存し、ESの分散インデックスを構成する
接待ノード(ingest node)
これは前処理を実行できるpipelineの仕事です.
ノードのみの調整
ルーティングのみを担当し、search reduceフェーズを処理します.
デフォルトでは、1つのノードのロールがあります.クラスタが拡大した場合、ロールを分割したい場合は、あるロールにdisableして、あるノードに1つのことしかできません.
マスターでもdataノードでも構いません
ツッコミ:ESがうまくいかないと思って、明確なクラスタ拡張トポロジー図はありません.例えば、データ規模が小さい場合、すべてのノードが各キャラクタであり、データ量が大きい場合に特定のキャラクタを区別するという実際の操作は現実的ではなく、いつデータ量が大きいかを特定することができ、いつ特定のキャラクタがすべての角色よりも効率的である.また,スイッチング中にどのようにスイッチングする必要があるか,ESはresharding,およびスライス分裂をサポートしない.インデックスも移行できず、どのようにロール変換を行うことができますか.また、coordinate nodeが分割されると、クライアント接続ノードが更新されます.
ES初認識
スライス
ノードレベルに基づくスライスはなく,mongoとは異なりcassandraのpartitionと類似している.id hashでスライスします.shard numberはindexの作成の最初に指定する必要があります.後期に変更するにはreindexが必要です.
{
"settings": {
"number_of_shards": 5,
"number_of_replicas": 2
}
}
分散クエリー
分散クエリーは、各shardをクエリーし、結果を組み合わせて、各shard上のクエリーを並列に行うことができますが、shard numberがノード数より多い場合は、同じノードでシリアルに実行する必要があり、効率が低下します.一般に単一ノード上のshardは2個を超えない,すなわちindexのshard numberは10に設定され,ノードレベルが20個に拡張されるとそれほど差がない.
政府はshard分裂を支持しない理由について
ESのreindexプロセスも比較的重いプロセスであり、同じように十分なスペースが必要ですが、少なくとも新しいインデックスのインデックス数を制御することができます.
ツッコミ:このスライスメカニズムは、ESのデザインがあまりにも腐っていて、使用者にとって、MySQLのような自分で実現するのではなく、自動スライスの意味は初期のスライスだけでなく、もちろん拡張に対する要求も含まれています.利用者はどのように自分のデータ規模の増加の上限を知っていて、どのように最初の時にどれだけのスライスを使うかを知っていて、reindexingはデータ量の大きい情況の下で、完全に災難で、もちろんこの部分の仕事を日常的に解決するべきです.
索引
ESのインデックスは逆インデックスであり、これは一般的なB-Treeインデックスとは異なり、ESが全文検索エンジンである理由でもある.B-Treeインデックスの場合はフィールドのソートであり、曖昧なクエリー、例えばlikeに対してはインデックスを調べることができないが、逆インデックスの場合は逆インデックスであり、まず分詞を行い、その後、単語がどのフィールドに現れるかを記録する.これは、一般的なデータベースが全文検索エンジンを提供できない理由です.
NoSQLデータベース
ESはNoSQLデータベースとしても使用されています.デフォルトでは元のデータが保存されており、transaction logがあり、データを失わないことを保証しています.他のqueryは豊富で、一部のgroupbyはaggregationで実現できます.一部のユーザーはBI分析をしています
まとめ
ESは使いやすく、使いやすいです.RESTFUL APIインタフェース、JSONドキュメントストレージを提供し、呼び出しが便利です.全文検索としては選択肢であり,solrとの区別はしばらく不明である.NoSQLデータベースストレージとして、クエリーが豊富でデータ量が多くなく、クラスタ規模が大きくない場合に選択できますが、クラスタ拡張能力が不足し、スライスポリシーに欠陥があります.大規模なデータストレージでは使いにくい.
リファレンス
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html
https://www.elastic.co/guide/en/elasticsearch/guide/current/overallocation.html
https://blog.insightdatascience.com/anatomy-of-an-elasticsearch-cluster-part-i-7ac9a13b05db