Фоновые индексы Mongodb - они все еще созданы после создания?

При создании индекса в mongodb вы можете указать флаг background: true, который заставляет создание индекса быть неблокирующим. Это здорово в производстве, так как вы не хотите, чтобы вся база данных была заблокирована, создавая индекс, который вам явно не нужен критически (так как у вас его не было).

Считывая docs, кажется, что этот флаг определяет только, как создается индекс, и как только он будет создан, индекс действует точно так же, как обычный индекс, Это то, что я хочу - я бы не хотел, чтобы индекс не синхронизировался с документами, потому что он обновлялся в фоновом режиме, хотя я могу представить базу данных, которая делает это.

Я спрашиваю здесь, потому что команда getIndexes показывает, что индекс по-прежнему отмечен как background даже после его создания. Это просто напоминание о том, как оно было создано? Или индексы background ведут себя по-разному после создания? Может быть, какая-то тонкость с репликацией?

Ответы

Ответ 1

После создания они действуют так же, как и обычные индексы. Они сохраняются в getIndexes как напоминание, похожее на unique, sparse и т.д.

Но это также имеет и другое значение. Просто потому, что индексы переднего плана блокируют всех авторов, в этом случае вы не сможете выполнить db.testCollection.getIndexes(), пока не будут созданы все индексы. Между тем, когда вы создаете фоновый индекс, вы можете вызвать db.testCollection.getIndexes(), и вы увидите, что этот индекс, похоже, уже создан.

Но в этом случае мы не можем быть уверены, действительно ли были созданы индексы или нет. В этом случае вам нужно вызвать db.currentOp(), и если вы увидите что-то вроде

{
  "inprog": [
    {
      "opid": 2001060,
      "active": true,
      "secs_running": 1,
      "op": "insert",
      "ns": "test.system.indexes",
      "insert": {
        "v": 1,
        "key": {
          "a": 1
        },
        "ns": "test.testCollection",
        "name": "a_1",
        "background": 1
      },
          ....
      "msg": "bg index build Background Index Build Progress: 368640/1000000 36%",
      "progress": {
        "done": 368640,
        "total": 1000000
      }
      ...
    }
  ]
}

то это означает, что создание фоновых индексов все еще продолжается, а также вы можете увидеть некоторую информацию о процессе.

Например, вы можете выполнить грубые вычисления: 368640 из 1000000 занимает 1 секунду (+1 секунда как возможное смещение), поэтому все должно занять 3-6 секунд (в итоге это заняло 4,8 с).

Очевидно, что если вы не видите такую операцию в процессе, то индексы уже созданы.

Примечание. Если у вас много параллельных операций, вы можете указать аргумент поиска для db.currentOp(), f.e.

db.currentOp({"insert.background":1})

Ответ 2

Существует несколько параметров индексирования - передний план (по умолчанию) и фон. Передний план относительно быстрый, и он блокирует всех писателей и читателей. Другие базы данных, к которым мы все еще можем добраться. Это должно быть сделано не в производственной среде.

Создание фонового индекса немного медленнее, и они не блокируют читателей и писателей. С помощью MongoDB 2.4 и более поздних версий вы можете создавать несколько фоновых индексов параллельно даже в одной базе данных.

Начиная с MongoDB 2.6, создание индекса в фоновом режиме на первичной основе приведет к тому, что индексы будут созданы в фоновом режиме на вторичных. Вторичные начнут создание индекса, когда первичный объект завершит построение своего индекса.

Существует еще один способ создания индекса очень эффективно в производственной системе. То есть для создания индекса на другом сервере, который используется для обслуживания большинства запросов. Скажем, в наборе реплик из нескольких серверов баз данных, работающих в тандеме, можно извлечь и запросы можно перенаправить на доступные. Создание индекса переднего плана может быть выполнено на отдельном сервере. После того, как создание будет выполнено успешно, его можно вернуть в кластер.

Ответ 3

У вас есть три варианта построения индексов 1) Foreground 2) Предыстория 3) Роллинг (сервер по серверу)

Все методы имеют плюсы и минусы. Мой предпочтительный метод для производственного кластера - 3). Подробнее в сообщении в блоге, которое я создал - https://scalegrid.io/blog/the-perils-of-building-indexes-on-mongodb/