Отладка. Утверждайте по сравнению с исключениями

Question

Отладка. Утверждайте по сравнению с исключениями

Краткий ответ: Актуальность в Elasticsearch не простая тема :) Подробности ниже.

Я пытался воспроизвести ваше дело ...

Сначала я поместил два документа:

POST /megacorp/employee/1
{
  "first_name": "John",
  "last_name": "Smith",
  "age": 25,
  "about": "I love to go rock climbing",
  "interests": [
    "sports",
    "music"
  ]
}

POST /megacorp/employee/2
{
  "first_name": "Jane",
  "last_name": "Smith",
  "age": 32,
  "about": "I like to collect rock albums",
  "interests": [
    "music"
  ]
}

, а позже я использовал ваш запрос:

GET /megacorp/employee/_search
{
  "query": {
    "match": {
      "about": "rock climbing"
    }
  }
}

Мои результаты были совершенно другими:

{
  "took": 89,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 2,
    "max_score": 0.5753642,
    "hits": [
      {
        "_index": "megacorp",
        "_type": "employee",
        "_id": "1",
        "_score": 0.5753642,
        "_source": {
          "first_name": "John",
          "last_name": "Smith",
          "age": 25,
          "about": "I love to go rock climbing",
          "interests": [
            "sports",
            "music"
          ]
        }
      },
      {
        "_index": "megacorp",
        "_type": "employee",
        "_id": "2",
        "_score": 0.2876821,
        "_source": {
          "first_name": "Jane",
          "last_name": "Smith",
          "age": 32,
          "about": "I like to collect rock albums",
          "interests": [
            "music"
          ]
        }
      }
    ]
  }
}

[ 1115] Как видите, результаты в «ожидаемом» порядке. Обратите внимание, что значения _score полностью отличаются от вас.

1116 Вопрос: почему? Что произошло?

Подробный ответ для этой ситуации был описан в Практическом BM25 - Часть 1: Как Осколки влияют на оценку релевантности в статье Elasticsearch .

Коротко: как вы, вероятно, могли заметить, Elasticsearch хранит документы, разделенные между осколками. Чтобы быть быстрее, по умолчанию используется стратегия query_then_fetch . Это означает, что Elasticsearch сначала запрашивает результаты для каждого сегмента, а затем извлекает результаты и представляет их пользователю. Конечно, то же самое происходит с подсчетом очков.

Как вы можете видеть, в наших результатах 5 осколков, где были запрошены. Elasticsearch использует 5 шардов по умолчанию, если они не указаны при создании индекса (можно указать с помощью параметра number_of_shards). Вот почему наши оценки разные. Более того, если вы попытаетесь сделать это самостоятельно, есть большая вероятность, что вы снова получите другие результаты. Все зависит от того, как документ распределяется между осколками. Если вы установите number_of_shards в 1 для этого индекса, вы будете получать одинаковые оценки каждый раз.

Еще одна вещь, также упоминаемая в статье :

Люди начинают загружать в свой индекс всего несколько документов и спрашивают: «Почему у документа A выше / более низкий балл, чем у документа B », и иногда ответ заключается в том, что пользователь имеет относительно высокое отношение сегментов к документам, поэтому оценки пересекаются между различными фрагментами.
blockquote>
Elasticsearch был разработан для поддержки большого объема данных, и чем больше данных вы помещаете в индекс, тем более точные результаты вы получаете.

Надеюсь, мой ответ объяснит ваши сомнения.

17

assertions exception .net

задан Community 23 May 2017 в 11:44

8 ответов

Во-первых, причем MyClass допустим, должен быть, конечно, выражен MyClass инвариант .

119-секундный, Вы говорите, что "Мы ожидаем, что MyMode будет обновлен внешними пользователями этого класса" - конечно, метод set этого режима должен иметь типичную форму дизайна контракта (как любая государственная функция):

  void Setter(mode m)
  {
    // INVARIANT ASSERT (1)
    // PRECONDITION ASSERTS (uses "m") (2)

    // BODY (3)

    // POSTCONDITION ASSERTS (if any) (4)
    // INVARIANT ASSERT (5)
  }

В (5) Вы перестали бы работать с кричащим нарушением утверждения, которое не содержит инвариант. , Но в (2) Вы перестали бы работать, ранее, потому что режим m передал, недопустимо. Это отправило бы сообщение открытым текстом пользователю и таким образом решает Вашу проблему.

И не говорите мне, что поле режима общедоступно, и пользователи изменяют его без любого управления вообще.

Редактирование: Об утверждениях и режиме выпуска, см. также:

5