MongoDB: отдельные коллекции для чтения и записи для высокой производительности

Question

Я использую mongodb и хочу создать базу данных для удовлетворения высоких требований к масштабируемости. В настоящее время, скажем, коллекция A в значительной степени используется для чтения и записи. Запись будет означать блокировку (теперь блокировка базы данных, надеюсь, сбор блокировки в будущих выпусках), блокировка операций чтения.

Моя идея состоит в том, чтобы дублировать A в A и A-tmp, где обе имеют одну и ту же схему. A хранит все данные, а A-tmp изначально пуст. Новые записи вставляются в A-tmp. Использование записей cronjob из A-tmp периодически перемещается в A. Когда приложение пытается найти данные после записи, будет выглядеть в A, и если данные не будут найдены впоследствии, посмотрите в A-tmp. Таким образом, A-tmp в основном используется для записи и иногда читается, когда записи не найдены в A. A в основном используется для чтения и периодически записывается в A-tmp.

Это разумное решение? Или это дает мало пользы? Или все это обрабатывается для меня, когда я перехожу к репликации и оштрафован дополнительным оборудованием?

Answer 1

Запись будет означать блокировку (теперь блокировка базы данных, надеюсь, сбор блокировки в будущих выпусках), блокировка операций чтения.

Это не просто автоматически блокировать чтение, блокировка писатель жадный, но есть правила спадать для чтения и т.д.

Я только де-факто вставить эту ссылку: http://docs.mongodb.org/manual/faq/concurrency/

Использование записей cronjob из A-tmp периодически перемещается в A.

Звучит просто.

Или это дает мало пользы?

Теперь хорошо отметить, что в вашем названии упоминается «db», но ваш вопрос упоминается как A и A-tmp как коллекции.

Я положу основы коллекций.

Нет, нет никакой выгоды для их разделения, если не существует серьезной логической причины относительно того, почему, то есть дизайн приложения/схемы.

Или все это обрабатывается для меня, когда я перехожу к репликации и оштрафованию с помощью дополнительного оборудования?

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

Это совершенно разные вещи.

Answer 2

В вашем случае это не похоже на то, что отличается от high-availability replication, поскольку набор реплик даст вам желаемое поведение для A-tmp, которое является таким же поведением для вторичных узлов в наборе реплик. Вам потребуются дополнительные аппаратные средства, но оперативное использование набора реплик будет намного проще, чем управление заданием cron.

В сценарии высокой готовности с MongoDB вы должны подумать о том, какой уровень отказоустойчивости вы хотите поддержать или сколько членов может стать недоступным, прежде чем набор не сможет выбрать новый первичный. Это и ряд других проблем HA: documented here.