Я пытаюсь понять поведение чтения в наборе реплик mongodb. В частности, у меня есть среда с высокой скоростью чтения, низкой скоростью записи и относительно небольшим набором данных (скажем, менее 8 ГБ). У меня есть набор реплик с тремя узлами.Распространять чтение через реплики в mongodb
Я прочитал этот документ:
http://docs.mongodb.org/manual/core/read-preference/
В частности:
режим основной по умолчанию. Все операции считываются из текущего набора реплик.
primaryPreferred В большинстве ситуаций операции считываются из первичной, но если они недоступны, операции считываются из вторичных элементов.
вторичный Все операции, считанные из вторичных элементов набора реплик.
secondPreferred В большинстве ситуаций операции, считанные из вторичных элементов, но если не доступны никакие вторичные элементы, операции считываются из первичной.
Ближайшие операции, считанные с ближайшего члена набора реплик, независимо от типа члена.
Так я понимаю, что читает по умолчанию перейти к первичному. Есть предпочтения чтения, которые позволяют читать со вторичных (secondary
и secondaryPreferred
). В этих случаях могут быть поданы устаревшие данные.
Мне кажется, что было бы предпочтительнее распространять показания как на первичных, так и на вторичных машинах, чтобы я мог наилучшим образом использовать все 3 машины. Но я не вижу этого в качестве опции. Следующее утверждение, в частности, озадачивает меня:
Если операции чтений составляют большой процент трафика вашего приложения, раздаточный читает вторичные элементы могут улучшить пропускную способность чтения. Однако в большинстве случаев шортинг обеспечивает лучшую поддержку для более масштабных операций, поскольку кластеры могут распространять операции чтения и записи по всей группе машин.
Однако в случае относительно небольшого набора данных, Sharding просто не имеет смысла. Может ли кто-то пролить свет на правильную конфигурацию?
Почему вы хотите распространять сообщения для вторичных пользователей? это похоже на то, что первична, возможно, сможет удовлетворить ваши потребности. –
что вы думаете об этом? Может ли он обрабатывать 1K запросов в секунду (с низкой задержкой, очевидно)? Как насчет 10K запросов в секунду? Независимо от моей нагрузки на трафик, в какой-то момент одна машина не может справиться с этим, и тогда я собираюсь распределить трафик между машинами. – Kevin
Конечно, я тестировал системы, которые могут обрабатывать 30 тыс. Считываний в секунду. То, как вы масштабируетесь или распространяете, не через второстепенные, это происходит через осколки. –