Kibana UI から Index の作成と削除 (elasticsearch)
Index の作成
Index 名: products
shardsの数: 2
replicasの数: 2
実行するクエリ
レスポンス
Index の削除
実行するクエリ
レスポンス
テスト用に Index を作成・削除するだけなら非常に簡単に出来る。
本番環境用に作成する場合、shardsやreplicasの数は設定ファイルで定義されている方が望ましい。
Master node (elasticsearch)
Android(kotlin) 既に起動中の Activity に onCreate を通らずに戻りたい
例えば、FieldActivity という Activity が既に起動していて、今は別の Activity が Active になっているとします。
以下のように、intent のインスタンスに Intent.FLAG_ACTIVITY_REORDER_TO_FRONT をセットし、それを startActivityIfNeeded() で呼び出してあげると、onCreate を通らずに、FieldActivity の状態を保持したままで戻ることができます。
val intent = Intent(applicationContext, FieldActivity::class.java) intent.flags = Intent.FLAG_ACTIVITY_REORDER_TO_FRONT startActivityIfNeeded(intent, 0)
FLAG_ACTIVITY_REORDER_TO_FRONT
スタック内の同一Activityを最前面に移動させます。
startActivityIfNeeded(Intent intent, int requestCode)
新たなActivityが必要な場合のみActivityを生成します。
※ requestCodeに0以上の値をセットした場合、起動したActivityのfinish()後に onActivityResult(int intRequestCode,int intResultCode, Intent intent) が呼ばれる。onActivityResult では intRequestCode と intResultCode の内容に応じた処理を実装する。
同一の Activityを最前面に移動させた上で、同一の Activityを改めて起動する必要はないため、startActivityIfNeeded は新たな Activity を生成しない。
Elasticsearch における Replication
Replication レプリケーションとは
フォールトトレラントとしてレプリケーションをサポートしている
※システムの一部に問題が生じても全体が機能停止するということなく動作し続けるようなシステム
Elasticsearch においてレプリレーション機能はデフォルト（フリー）で提供されている。
どのように動くか
- レプリケーションはインデックスレベルで作成される
- レプリケーションはシャードをコピーすることで行われる
- コピー元のシャード(データの読み書き双方可能)は、プライマリシャードと呼ばれる
- プライマリシャードから作成されたレプリカはレプリカシャード(データの読み込み可能)と呼ばれる
- プライマリシャードとそのレプリカ群はまとめてレプリケーショングループと呼ばれる
- レプリカシャードはプライマリシャードと同様にリクエスト(データの読み込み可能)を処理可能
- レプリカの数はインデックスの生成時に構成される(index の設定に依存)
- レプリカシャードはプライマリシャードと同じノード上に生成されることはない
⇒仮に1台消失しても、他のノード上に残っている状態を確保するため
あるインデックスにおける Replication group A の例
Replication group A
- Primary Shard A
- Replica A1
- Replica A2
Replication group B
- Primary Shard B
- Replica B1
- Replica B2
Primary Shard と Replica Shard の例
2台Node構成で2つの indices が存在している場合。
それぞれの index 用に Primary Shard と Replica Shard が作られ、それぞれ違うノードに保持される。
Node1
- Primary Shard A
- Primary Shard B
Node2
- Replica Shard A
- Replica Shard B
このケースでも2台同時にノードが壊れてしまった場合は復旧ができない。
いくつの replica shards を保持するべきかはケースによる。
一時的にでもデータのロストが許容される場合、1つの replica shard
一時的にでもデータのロストが許容されない場合、少なくとも2つの は replica shard を確保したい（合計3台のノード上でデータが保持される）
Snapshots
Elasticsearch は snapshots をデータバックアップ用としてサポートしている。
⇒ある時点（snapshots取得時)でのデータ復旧が可能
snapshots は index レベルあるいは、cluster 全体の何れかのレベルで取得可能。
Snapshots があれば replication は必要なのか ?
⇒ snapshots はバックアップのため、replication は高可用性のために必要
⇒ replication はデータロストを防ぐために必要だが、データをクエリを投げる前に戻すことはできない
⇒ 何か大きなクエリを投げる前に snapshots を取得しておき、もし失敗したら復旧に使う
例）
デイリーで snapshot をバックアップ用で取得する。
作業前に手動で snapshot をデータ復旧用に取得する。
Snapshots に対する Replication
replication はノードが壊れた時にでも、データを継続して使用し続けることが出来ることを保証する。
また、 データロストを防ぐのと同時に、スループットの向上にも期待ができる。
例）
ユーザーはあるインデックスに対して、何らかのクエリを大量に投げるとする
⇒ このインデックスはたくさんのクエリ（リクエスト）を受け取る
⇒ ただ、このインデックスは1つの Shardで構成されている、何故ならドキュメントの数が少ないから
どのようにしてスループットを向上させるか?
⇒ 例えば、一つノードを追加する
⇒ Node1 が Primary shard、Node2 が replica shardをもつ状態になる
⇒ この時点で、読み込みリクエストが半分に分散される
スループット向上のためにノードを有効に活用するには、replica shards の数を増やす必要がある
⇒ Replica shards の数を増やすことでスループットの向上が期待できる
Elasticsearch は自動的にクエリを実行するための shard を選択する
⇒ もし同じインデックスにリクエストが同時に３つあったとしても、もし3つの shard (primary + 2 replica) が存在していれば、異なる shard 上で同時に処理することが可能
２つしかノードがないのに、なぜ３つ処理できるのか？
⇒ CPUがマルチコア構成だから、1ノード上で複数のリクエストを同時に処理可能
よって、replication はデータの可用性と、データのスループットの向上に役立つ。
ただし、replica の数を増やすためには、shard を丸ごとコピーできる程のディスクサイズが必要。
kibana 上でインデックスを作成してみる
news という名前の インデックスを作成します。
成功すれば以下のようなレスポンスが返ってきます。
インデックスの状態をチェックすると、ステータスが yellow になっています。
シャードの状態を以下のクエリで確認してみると、
"primary shard(p)" は STARTED になっていますが、”replica shard(r)” は UNASSIGNED になっています。
これはこのクラスターが1台のノードでしか構成されていないため、”replica shard(r)” はどこにも作られていないことを意味します。
従って、インデックスのステータスが yellow になっています。
Python for ループ用のインデックス変数はループ処理後も有効
Java における for ループ用のインデックス変数（以下の例では i ) については、for ループ内でしか有効ではない。
for (int i = 0; i < 10; i++) { print(i); }
Python における for ループ用のインデックス変数 (以下の例では idx) については、forループ後も有効。
>>> array = ["A","B","C"] >>> array_num = len(array) >>> for idx in range(array_num): ... print(array[idx]) ... A B C
idx を参照してみると、ループ処理後の値が入っている。
>>> print(idx) 2
$ for i in {1..9}; do echo ${i};done
1
2
3
4
5
6
7
8
9
$ echo $i
9
Elasticsearch における Sharding
Sharding とは
1. Sharding とは、インデックスを小さなピースに分割するための手段
2. それぞれのピースは Shard として扱われる
3, Sharding はインデックスレベルで行われる（クラスタやノードレベルではない）
4. Sharding によってデータが均等にノードに分けられる
⇒1つのノードに収まらない大きなサイズのインデックスを複数のノードに分けて格納することが可能になる
Shard とは
1. インデックス単位で独立している（厳密には違うらしいが、そのように捉えても差し支えない）
2. Shard は Apache Lucene index である
3. 即ち、Elasticsearch のインデックスは複数の Lucene indices で構成されている
4. Shard はサイズは固定されておらず、ドキュメントの増加に伴い増加する
5. Shard は20億ものドキュメントを保持するケースもある
Sharding する目的
1. Sharding することで、数十億ものドキュメントを１インデックスに保持することがある
2. Sharding することで、データをノードに合わせたサイズにすることができる
3. Sharding することで、検索時のクエリが並行処理することが可能となり、パフォーマンスの向上
⇒複数のシャード上で並行処理が行われる
pri とは primary shard のことで、もし複数の Shard が存在している場合、ここに複数の番号が付与される。
Elasticsearch バージョン7未満まではデフォルトで5つの Shard が生成されていた。
しかしながら、小さなインデックスに対して Shard を作成することは問題(over-sharding)が起こることがあった。
そのため、バージョン7からはデフォルトで1つのShard が生成される。
Shard を増やすためには、Split API を使用する。
Shard を減らすためには、Shrink API を使用する。
⇒どれくらいのドキュメントを格納するかによって、Shardの数を見積する必要がある。
最適な shard の数は?
求めるための公式はない。
⇒多くの要素に依存する
⇒ノードの数やキャパシティ、インデックスの数やサイズ、クエリの数など
もし1インデックスに対して、数百万のドキュメントが予想されるのであれば、5つのShardで様子を見てみるとよいかもしれない。
