Dark Horse-Spring クラウド マイクロサービス テクノロジー スタック データ集約。
プロジェクトにはテクノロジーが関係します
- 知識ポイントは話数ごとに並べられているので、後々の検索に便利です。
- 固定のネットワーク方法ではなく、場合によっては WiFi、場合によってはホットスポットであることを考慮すると、静的 IP を構成すると、ネットワークが変更されるたびに再構成が発生するため、仮想マシンを実行する必要があるときに IP が変更されると、仮想マシンで使用される動的ルーティングを変更する必要があります。関連プログラム| | |の設定で
yml文件十分です。test测试类启动类 - コード パスの列挙は主にフォローアップ レビューのために行われます。
- RestClient は、ホテル インデックス ライブラリのコード パスを操作します
E:\微服务\实用篇\day05-Elasticsearch01\资料\hotel-demo。 - データベース+mqを操作してデータ同期を実現するコードパス
E:\微服务\实用篇\day07-Elasticsearch03\资料\hotel-admin。
実用記事
- 集計– 文書データの統計、分析、計算。(P120)
- 一般的な種類の集計
Bucket(バケット集計): ドキュメント データをグループ化する; TermAggregation: ドキュメント フィールドごとにグループ化する; 日付ヒストグラム: 1 週間や 1 か月などの日付ラダーごとにグループ化する。Metric(メトリック集計またはネストされた集計): 平均、最小、最大、ステータスなどのドキュメント データを計算します (合計、最小などを同時に検索します)。Pipeline(パイプライン集計): 他の集計結果に基づいて集計を実行します。- 集計に参加するフィールドのタイプは、キーワード、値、日付、ブール値である必要があります。
- DSL を使用したバケット集約の実装(P121)
- aggs は集計の略で、クエリと同じレベルにあり、クエリの役割は、集計されたドキュメントの範囲を制限することです。
- 集計には、集計名、集計タイプ、集計フィールドの 3 つの要素が必要です。
- 集計の設定可能な属性は次のとおりです: size: 集計結果の数を指定します; order: 集計結果のソート方法を指定します; field: 集計フィールドを指定します。
- DSL はメトリクスの集約を実現します(P122)
- ResrClient は集約を実装します(P123)
# 统计所有数据中的酒店品牌有几种，此时可以根据酒店品牌的名称做聚合
# size-设置size为0，结果中不包含文档，只包含聚合结果
# aggs-定义聚合 brandAgg-给聚合起个名字
# terms-聚合的类型，按照品牌值聚合，所以选择
# field-参与聚合的字段 size- 希望获取的聚合结果数量
GET /hotel/_search
{
"size": 0,
"aggs": {
"brandAgg": {
"terms": {
"field":"brand",
"size": 10
}
}
}
}
# Bucket聚合会统计Bucket内的文档数量，记为_count，并且按照_count降序排序
GET /hotel/_search
{
"size": 0,
"aggs": {
"brandAgg": {
"terms": {
"field":"brand",
"size": 10,
"order": {
"_count": "asc"
}
}
}
}
}
# Bucket聚合是对索引库的所有文档做聚合，我们可以限定要聚合的文档范围，只要添加query条件
GET /hotel/_search
{
"query": {
"range": {
"price": {
"lte": 200
}
}
},
"size": 0,
"aggs": {
"brandAgg": {
"terms": {
"field":"brand",
"size": 10
}
}
}
}
# 获取每个品牌的用户评分的min、max、avg等值.
# aggs-brands聚合的子聚合，也就是分组后对每组分别计算
# scoreAgg-聚合名称
# stats-聚合类型，这里stats可以计算min、max、avg等
# field-聚合字段，这里是score
GET /hotel/_search
{
"size": 0,
"aggs": {
"brandAgg": {
"terms": {
"field":"brand",
"size": 10,
"order": {
"scoreAgg.avg": "desc"
}
},
"aggs": {
"scoreAgg": {
"stats": {
"field": "score"
}
}
}
}
}
}
- オートコンプリート（P126）
- ピンイン ワード ブレーカーをインストールしてテストします。
- カスタム ワード ブレーカー– elasticsearch のワード ブレーカー (アナライザー) の構成は 3 つの部分で構成されます。
character filters: トークナイザーの前にテキストを処理します。たとえば、文字を削除したり、文字を置き換えたりします。tokenizer: テキストを特定のルールに従って用語に切り取ります。たとえば、keyword は分詞ではなく、ik_smart などもあります。tokenizer filter: トークナイザーによって出力されたエントリをさらに処理します。たとえば、大文字と小文字の変換、同義語の処理、ピンインの処理などです。
# 安装pinyin分词器
# 查看数据卷elasticsearch的plugins目录位置
docker volume inspect es-plugins
# 到这个目录下
cd /var/lib/docker/volumes/es-plugins/_data
# 使用FileZillar直接传输Windows下解压的pinyin分词器的文件夹，结果是成功的
# 重启es容器
docker restart es
# 查看es日志
docker logs -f es
# 测试拼音分词器
GET /_analyze
{
"text": ["如家酒店还不错"],
"analyzer": "pinyin"
}
# 删除索引库
DELETE /test
# 自定义拼音分词器,创建索引库时，通过settings来配置自定义的analyzer（分词器）;拼音分词器适合在创建倒排索引的时候使用，但不能在搜索的时候使用。--导致多音字都被搜出来
# 创建倒排索引时应该用my_analyzer分词器 -- analyzer；
# 字段在搜索时应该使用ik_smart分词器 -- search_analyzer;
PUT /test
{
"settings": {
"analysis": {
"analyzer": {
"my_analyzer": {
"tokenizer": "ik_max_word",
"filter": "py"
}
},
"filter": {
"py": {
"type": "pinyin",
"keep_full_pinyin": false,
"keep_joined_full_pinyin": true,
"keep_original": true,
"limit_first_letter_length": 16,
"remove_duplicated_term": true,
"none_chinese_pinyin_tokenize": false
}
}
}
},
"mappings":{
"properties":{
"name": {
"type": "text",
"analyzer": "my_analyzer",
"search_analyzer": "ik_smart"
}
}
}
}
# 测试自定义分词器
GET /test/_analyze
{
"text": ["如家酒店还不错"],
"analyzer": "pinyin"
}
- オートコンプリート–
completion suggesterクエリ – オートコンプリート機能を実装します。(P128) - フィールドのオートコンプリート要件: type は
completiontype、フィールド値は複数のエントリの配列です。 - 事例: ホテルデータの自動補完- ホテルインデックスライブラリの自動補完機能とピンイン検索機能を実現します。(P130)
# 自动补全的索引库
PUT test1
{
"mappings":{
"properties":{
"title": {
"type": "completion"
}
}
}
}
# 示例数据
POST test1/_doc
{
"title":["Sony", "WH-1000XM3"]
}
POST test1/_doc
{
"title":["SK-II", "PITERA"]
}
POST test1/_doc
{
"title":["Nintendo", "switch"]
}
# 自动补全查询
POST /test1/_search
{
"suggest": {
"title_suggest": {
"text": "s", # 关键字
"completion": {
"field": "title", # 补全字段
"skip_duplicates": true, # 跳过重复的
"size": 10 # 获取前10条结果
}
}
}
}
- データ同期–と
elasticsearchの間のデータ同期mysql(P132) - 質問: マイクロサービスでは、ホテル管理を担当するビジネス (mysql を実行) とホテル検索を担当するビジネス (elasticsearch を実行) が 2 つの異なるマイクロサービス上に存在する場合があります。データの同期を実現するにはどうすればよいですか? 解決策:
- 方法 1:同期呼び出し; 長所: シンプルで無礼な実装; 短所: ビジネス結合度が高い。
- 方法 2:非同期通知; 長所: 低結合、実装の一般的な困難; 短所:
依赖mq信頼性が高い。 - 方法 3: binlog を監視する; 利点: サービス間の完全な分離; 欠点:
开启binlogデータベースの負担が増加し、実装が複雑になります。–canalミドルウェアを使用します。 - ESクラスタ構造（P138）
- データストレージ用のスタンドアロンの elasticsearch は必然的に次のような問題に直面します
两个问题。 - 大規模なデータ ストレージの問題– インデックス ライブラリを N 個のシャードに論理的に分割し、複数のノードに保存します。
- 単一障害点の問題– 断片化したデータを別のノード (レプリカ) にバックアップします。
- 各インデックス ライブラリのシャードとコピーの数は、インデックス ライブラリの作成時に指定され、シャードの数は一度設定すると変更できません。
- elasticsearch のクラスター ノードにはさまざまな役割があります。
master eligi(マスター ノード) – 代替マスター ノード: マスター ノードは、クラスターのステータスを管理および記録し、シャードがどのノード上にあるかを決定し、インデックス ライブラリの作成および削除リクエストを処理できます。data(データ ノード) – データ ノード: データの保存、検索、集計、CRUD。ingest– データ保存前の前処理。coordinating(調整ノード) – リクエストを他のノードにルーティングして、他のノードによって処理された結果をマージしてユーザーに返します。- ES クラスターのスプリット ブレイン– マスター ノードと他のノードの間のネットワークに障害が発生すると、スプリット ブレイン問題が発生する可能性があります。
- 調整ノードの役割
- 分散された新しい追加のシャーディングを決定する方法 –計算
coordinating nodeによると、結果は数値の残りであり、残りは対応するシャードです。idhashshard - 分散クエリの 2 つのフェーズ。
- 分散フェーズ: 調整ノードはクエリリクエストを異なるシャードに分散します。
- 収集フェーズ: クエリ結果を調整ノードに要約し、整理してユーザーに返します。
- フェイルオーバー– マスターがダウンすると、EligibleMaster が新しいマスター ノードとして選択されます。マスター ノードは断片化とノードのステータスを監視し、障害が発生したノードの断片化を通常のノードに転送してデータ セキュリティを確保します。