2014-01-16 3 views
4

Я пытаюсь понять поведение чтения в наборе реплик mongodb. В частности, у меня есть среда с высокой скоростью чтения, низкой скоростью записи и относительно небольшим набором данных (скажем, менее 8 ГБ). У меня есть набор реплик с тремя узлами.Распространять чтение через реплики в mongodb

Я прочитал этот документ:

http://docs.mongodb.org/manual/core/read-preference/

В частности:

режим основной по умолчанию. Все операции считываются из текущего набора реплик.

primaryPreferred В большинстве ситуаций операции считываются из первичной, но если они недоступны, операции считываются из вторичных элементов.

вторичный Все операции, считанные из вторичных элементов набора реплик.

secondPreferred В большинстве ситуаций операции, считанные из вторичных элементов, но если не доступны никакие вторичные элементы, операции считываются из первичной.

Ближайшие операции, считанные с ближайшего члена набора реплик, независимо от типа члена.

Так я понимаю, что читает по умолчанию перейти к первичному. Есть предпочтения чтения, которые позволяют читать со вторичных (secondary и secondaryPreferred). В этих случаях могут быть поданы устаревшие данные.

Мне кажется, что было бы предпочтительнее распространять показания как на первичных, так и на вторичных машинах, чтобы я мог наилучшим образом использовать все 3 машины. Но я не вижу этого в качестве опции. Следующее утверждение, в частности, озадачивает меня:

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

Однако в случае относительно небольшого набора данных, Sharding просто не имеет смысла. Может ли кто-то пролить свет на правильную конфигурацию?

+0

Почему вы хотите распространять сообщения для вторичных пользователей? это похоже на то, что первична, возможно, сможет удовлетворить ваши потребности. –

+0

что вы думаете об этом? Может ли он обрабатывать 1K запросов в секунду (с низкой задержкой, очевидно)? Как насчет 10K запросов в секунду? Независимо от моей нагрузки на трафик, в какой-то момент одна машина не может справиться с этим, и тогда я собираюсь распределить трафик между машинами. – Kevin

+1

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

ответ

0

мне удалось частично решить проблему, используя тег ссылки https://docs.mongodb.com/manual/tutorial/configure-replica-set-tag-sets/

conf = rs.conf() 
conf.members[1].tags = { "tagType": "dummyValue"} 
rs.reconfig(conf) 

Пользовательского тег был установлен на каждом из вторичных машин, а также различные шаблоны Mongo (я использую Spring Монго) были определены с использованием наборы тегов (https://docs.mongodb.com/manual/core/read-preference/#tag-sets)

<bean id="tag" class="com.mongodb.Tag"> 
    <constructor-arg value="tagType" /> 
    <constructor-arg value="dummyValue" /> 

<bean id="tagSet" class="com.mongodb.TagSet"> 
    <constructor-arg ref="tag" /> 
</bean> 

<bean id="readPref" class="com.mongodb.ReadPreference" 
     factory-method="secondaryPreferred" > 
     <constructor-arg ref="tagSet" /> 
</bean> 

<bean id="mongoTemplate" class="org.springframework.data.mongodb.core.MongoTemplate"> 
     <constructor-arg name="mongoDbFactory" ref="mongoFactory" /> 
     <property name="readPreference" ref="readPref" /> 
     <property name="writeConcern" value="JOURNALED" /> 
    </bean> 

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

Смежные вопросы