Каково время ожидания блокировки запроса обновления MongDB (WiredTiger) по умолчанию?

Question

Я вложил массив вложенных документов в документ MongoDB, и несколько пользователей могут попытаться добавить вложенные документы в массив.Я использую запрос на обновление ($ push), чтобы добавить документ в массив, но если несколько пользователей пытаются добавить запись из пользовательского интерфейса, как я могу убедиться, что второй $ push не потерпит неудачу из-за блокировки первой?У меня была бы возможность только нескольких пользователей добавить запись в один и тот же документ, поэтому не стоит беспокоиться о случае, когда существуют сотни пользователей.Каково время ожидания обновления по умолчанию в WiredTiger, поэтому 2-е нажатие не прерывается немедленно и может занять до 1 секунды, но $ push должно завершиться успешно?

Я попытался найти время ожидания по умолчанию в документах MongoDB и WiredTiger., Я мог бы найти время ожидания транзакции по умолчанию, но обновить запрос.

Answer 1

Внутренне WiredTiger использует оптимистический метод блокировки. Это означает, что когда два потока пытаются обновить один и тот же документ, один из них будет успешным, а другой отключится. Это проявится как «конфликт записи» (см. metrics.operation.writeConflicts ).

Этот конфликт будет повторен прозрачно, поэтому, с точки зрения клиента, запись займет больше времени, чем обычно.

Алгоритм возврата будет ожидать дольше, чем больше конфликтов, с которыми он сталкивается, от 1 мс и ограниченный 100 мс за ожидание. Таким образом, чем больше конфликтов, с которыми он сталкивается, тем больше он будет ждать 100 мс за попытку.

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

1. MongoDB имеет ограничение в 16 МБ для размера документа, поэтому массив нельзя обновлять бесконечно.
2. Проблемы с блокировкой, как вы легко определили.

Для # 2 в патологическом случае запись может столкнуться с конфликтом после конфликта, ожидая 100 мс между ожиданиями. Ограничение на количество ожиданий не ограничено, поэтому он может ждать несколько минут. Это признак того, что рабочая нагрузка является узким местом в одном документе, и приложение по существу работает в однопоточной модели.

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