В нашей настройке в настоящее время у нас есть 3 сегментированных кластера с набором сегментов, каждый из которых представляет собой набор реплик из 3. Количество операций записи в ближайшее время значительно возрастет для реализации новой функции, и мы знаем, что потребуются дополнительные данные. По своей природе наши записи - это в основном все upserts (которые, вероятно, будут обновлениями) и обновления, в которых мы увеличиваем конкретное поле на 1.
Наши обновления всегда увеличиваются на 1, и то, как наши данные распределяются, не все документы обрабатываются одинаково, поля некоторых увеличиваются намного больше. Альтернативное решение, которое, как я думал, могло быть эффективным, - это иметь какой-то посредник, например, несколько баз данных Redis (или несколько меньших монгодов), где мы сначала обновляем их, а примерно через 5 минут (или используем какую-то систему очередей), у нас есть группа рабочих, потребляющих данные и обновляющих актуальный живой кластер документами. Это сэкономит нашему основному кластеру массу операций записи, поскольку позволит некоторым документам с тяжелыми обновлениями накапливать свои обновления и может сэкономить нам массу операций записи (точные цифры я опубликую в ближайшее время в редакции).
Итак, в конце концов, когда добавление еще одного шарда не является правильным решением?
Redis, безусловно, можно использовать в качестве метода кеширования / обратной записи для MongoDB.
Однако добавление осколков является основным способом увеличения емкости записи вашего приложения, если вы уже исчерпали возможности добавления памяти, использования более быстрых дисков и т. Д.
Также помните о тенденциях MongoDB к блокировке записи. Mongo позволяет ядру управлять тем, что хранится в ОЗУ, поэтому при выполнении обновления рекомендуется сначала прочитать объект (чтобы он хранился в ОЗУ), а затем записать в него. В противном случае блокировка записи будет действовать намного дольше в случае объектов, не входящих в рабочий набор, потому что она устанавливает блокировку записи, затем считывает документ с диска, записывает в документ (теперь в оперативной памяти), а затем освобождает замок. Все это менее навязчиво, если чтение (перенос объекта в ОЗУ) было выполнено до того, как произошла блокировка записи.