Многоуровневый вложенный объект против "нескольких вложенных объектов" в упругом поиске

Question

Мое требование - захватить несколько торговых площадок для продукта в упругом поиске.

индекс: рейтинги Тип: productchild

Каждый продукт будет иметь несколько рынков, и каждый рынок будет иметь несколько регионов, и каждый регион будет иметь несколько стран, и я обозначил это как

{
  "ratingsindextest": {
    "mappings": {
      "productchild": {
        "_routing": {
          "required": true

             "productId": {
            "type": "string",
            "index": "not_analyzed"
          },
          "productMarkets": {
            "type": "nested",
            "properties": {
              "lobID": {
                "type": "string",
                "index": "not_analyzed"
              },
              "lobValue": {
                "type": "string",
                "index": "not_analyzed"
              },
              "regions": {
                "type": "nested",
                "properties": {
                  "countries": {
                    "type": "nested",
                    "properties": {
                      "country": {
                        "type": "string",
                        "index": "not_analyzed"
                      },
                      "status": {
                        "type": "string",
                        "index": "not_analyzed"
                      }
                    }
                  },
                  "regionId": {
                    "type": "string",
                    "index": "not_analyzed"
                  },
                  "regionName": {
                    "type": "string",
                    "index": "not_analyzed"
                  }
                }
              }
            }
          },
          "productName": {
            "type": "string",
            "analyzer": "english"
          },
          "shortDescription": {
            "type": "string",
            "analyzer": "english"
          },
          "supplierId": {
            "type": "string",
            "index": "not_analyzed"
          }
        }
      }
    }
  }
}

и у меня вопрос, будут ли какие-либо потери производительности из-за многоуровневых вложенных полей, созданных, как указано выше, или целесообразно изменить отображение так, чтобы оно соответствовало простому списку, как показано ниже

{
  "ratingsindextest": {
    "mappings": {
      "productchild": {
        "_routing": {
          "required": true
        },
        "properties": {
          "productId": {
            "type": "string",
            "index": "not_analyzed"
          },
          "productMarkets": {
            "type": "nested",
            "properties": {
              "lobID": {
                "type": "string",
                "index": "not_analyzed"
              },
              "lobValue": {
                "type": "string",
                "index": "not_analyzed"
              },
              "region": {
                "type": "string",
                "index": "not_analyzed"
              },
              "countryId": {
                "type": "string",
                "index": "not_analyzed"
              },
              "countryName": {
                "type": "string",
                "index": "not_analyzed"
              }
            }
          },
          "productName": {
            "type": "string",
            "analyzer": "english"
          }
        }
      }
    }
  }
}

вышеупомянутый способ будет иметь несколько вложенных документов с одним и тем же Lob, но несколькими регионами и каждый регион имеет несколько стран.

Любые советы, по которым следует придерживаться подхода

Answer 1

Всегда лучше, если вы можете отменить нормализацию своих данных, но, конечно, это не всегда возможно. Кроме того, меньше вложенности лучше - это будет стоить вам дешевле при выполнении поиска по вложенным.

Вложенные

• Вложенные документы хранятся в одном блоке Lucene друг с другом, что повышает производительность чтения / запроса. Чтение вложенного документа происходит быстрее, чем эквивалентный родительский / дочерний документ.
• Обновление отдельного поля во вложенном документе (родительском или вложенном дочернем) вынуждает ES переиндексировать весь вложенный документ. Это может быть очень дорого для больших вложенных документов
• «Перекрестная ссылка» на вложенные документы невозможна.
• Лучше всего подходит для данных, которые не часто меняются

Parent / Child

• Дети хранятся отдельно от родителя, но направляются в тот же осколок. Таким образом, родители / дети немного меньше производительности на чтение / запрос, чем вложенный
• Родительские / дочерние отображения имеют немного дополнительной памяти, так как ES поддерживает список «соединения» в памяти
• Обновление дочернего документа не влияет на родительский или другие дочерние документы, что потенциально может значительно сэкономить при индексации больших документов
• Сортировка / оценка могут быть затруднены с родителем / ребенком, так как операции «Имеет ребенка / Имеет родителя» могут быть непрозрачными время от времени

Денормализация

• Вы сами управляете всеми отношениями!
• Самые гибкие, самые административные накладные расходы
• Может быть более или менее быстродействующим в зависимости от ваших настроек

Цитируется из: Управление отношениями внутри Elasticsearch