Чтение из наборов реплик MongoDB с помощью PyMongo

Настройки чтения — это новая функция в MongoDB 2.2, которая позволяет вам точно контролировать, как запросы направляются членам набора реплик. С тонким контролем приходит сложность, но не бойтесь: я объясню, как использовать настройки чтения для маршрутизации ваших запросов с помощью PyMongo.

(Я помог написать спецификацию 10gen для настроек чтения и сделал реализацию для PyMongo 2.3.)

Эта проблема

Какой элемент набора реплик должен использовать PyMongo для findкоманды типа «только для чтения», например count? Должен ли он запросить первичный или вторичный? Если он запрашивает вторичный, какой из них он должен использовать? Как вы можете контролировать этот выбор?

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

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

Читать настройки

Предпочтение чтения состоит из трех частей:

Режим . Это определяет, следует ли читать с первичного или вторичного. Есть пять режимов:

• PRIMARY: Режим по умолчанию. Всегда читайте с основного. Если первичное повышение не вызвано, исключение: «AutoReconnect: первичная реплика не установлена ​​для запроса».

• SECONDARY: Чтение из вторичной , если есть один, в противном случае вызвать исключение: AutoReconnect: No replica set secondary available for query. PyMongo предпочитает вторичные с коротким временем пинга.

• PRIMARY_PREFERRED: читать с первичного, если есть, в противном случае вторичный.

• SECONDARY_PREFERRED: чтение из вторичного, если есть, в противном случае первичное. Опять же, второстепенные с низкой задержкой предпочтительнее

• NEAREST: читать с любого члена с низкой задержкой.

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

{
    _id : "someSet",
    members : [
        {_id : 0, host : "A", tags : {"dc": "ny"}},
        {_id : 1, host : "B", tags : {"dc": "ny"}},
        {_id : 2, host : "C", tags : {"dc": "sf"}},
        {_id : 3, host : "D", tags : {"dc": "sf"}},
        {_id : 4, host : "E", tags : {"dc": "uk"}}
    ]
}

Вы можете настроить PyMongo для использования этого массива наборов тегов:

[{'dc': 'ny'}, {'dc':'sf'}, {}]

Драйвер просматривает массив, от первого набора тегов до последнего, в поисках набора тегов, который соответствует одному или нескольким элементам. Таким образом, если в сети есть какие-либо совпадающие участники {'dc': 'ny'}, водитель выбирает их, предпочитая тех, у кого меньше времени пинга. Если ни один из членов не совпадает {'dc': 'ny'}, PyMongo ищет подходящих участников {'dc':'sf'}и так далее в списке.

Последний пустой набор тегов {}означает «читать из любого члена независимо от тегов». Это отказоустойчиво. Если вы предпочитаете вызывать исключение, а не читать элемент, который не соответствует набору тегов, пропустите пустой набор в конце массива:

[{'dc': 'ny'}, {'dc':'sf'}]

В этом случае, если все участники в Нью-Йорке и Сан-Франциско не работают, PyMongo выдаст исключение вместо того, чтобы судить участника в Великобритании.

Вы можете иметь несколько тегов в наборе. Участник должен соответствовать всем тегам. Например, если ваш массив наборов тегов выглядит так:

[{'dc': 'ny', 'disk': 'ssd'}]

… тогда только член помечено как с 'dc': 'ny'и 'disk': 'ssd'совпадение. Дополнительные теги члена, вроде бы 'rack': 2, не имеют никакого эффекта.

Каждый режим взаимодействует немного по-разному с наборами тегов:

• PRIMARY: Вы не можете комбинировать наборы тегов с PRIMARY. В конце концов, есть только один первичный, поэтому бессмысленно просить первичный с определенными тегами.
• PRIMARY_PREFERRED: Если основной файл активен, считывайте его независимо от того, как он помечен. Если основной не работает, прочитайте из вторичного соответствия соответствующие теги. Если такого вторичного элемента нет, выведите ошибку.
• SECONDARY: Чтение из вторичного объекта, который соответствует первому набору тегов, для которого есть совпадения.
• SECONDARY_PREFERREDНравится SECONDARY, или если нет соответствующих вторичных серверов, как PRIMARY.
• NEARESTНравится SECONDARY, но относиться к первичным так же, как к вторичным.

secondary_acceptable_latency_ms . PyMongo отслеживает время пинга каждого участника (см. Мониторинг ниже) и запрашивает только «ближайшего» участника или любого случайного члена, не более чем на 15 мсек «дальше» от него.

Скажем, у вас есть участники, которые находятся на расстоянии 10, 20 и 30 миллисекунд:

PyMongo распределяет запросы равномерно между 10- и 20-миллисекундным членом. Он оправдывает 30-миллисекундный член, потому что он более чем на 15 мс дальше, чем ближайший член. Вы можете переопределить значение по умолчанию 15 мс, установив опцию snappily-named secondary_acceptable_latency_ms.

Алгоритм

PyMongo выбирает элемент, используя три части предпочтения чтения в качестве трехэтапного фильтра, удаляя неподходящих членов на каждом этапе. Поскольку PRIMARYдрайвер просто выбирает первичное, или, если нет первичного, вызывает исключение. Для SECONDARYи NEAREST:

1. Примените режим. Для SECONDARY, отфильтруйте основной и продолжить. Ибо NEAREST, сохраните всех участников и продолжайте.

2. Примените наборы тегов. Если настроенные наборы тегов не настроены, тогда передайте все элементы на следующий этап. В противном случае выполните поиск в массиве наборов тегов в поисках набора тегов, который соответствует некоторым элементам, и передайте эти элементы на следующий этап.

3. Применить пинг раз. Сначала найдите ближайшего участника, который до сих пор пережил фильтрацию. Затем отфильтруйте участников более чем на 15 мс дальше.

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

PRIMARY_PREFERREDиспользует основной, если он есть, в противном случае он запускает SECONDARYалгоритм.

SECONDARY_PREFERREDсначала запускает SECONDARYалгоритм, и если в конце нет члена, он использует основной.

Я слышу ваши возражения: «Это сложно», — говорите вы. Это является довольно сложным, но мы выбрали этот алгоритм , потому что мы считаем , что он может быть настроен для работы в любом потребительном случае , если вы бросаете на нее. (См. Варианты использования ниже.) «Это дорого», — возражаете вы. Алгоритм дешевле, чем кажется, потому что он вообще не вводит / выводит. Он просто использует то, что он уже знает о вашем наборе реплик из периодического мониторинга .

Наконец, некоторый код

Давайте на самом деле использовать настройки чтения с PyMongo. Самый простой способ — настроить MongoReplicaSetClient. По умолчанию режим таков, PRIMARYнаборы тегов пусты и secondary_acceptable_latency_msсоставляют 15 мс:

from pymongo.mongo_replica_set_client import MongoReplicaSetClient

rsc = MongoReplicaSetClient('host1,host2,host3', replicaSet='foo')

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

from pymongo.mongo_replica_set_client import MongoReplicaSetClient
from pymongo.read_preferences import ReadPreference

rsc = MongoReplicaSetClient('host1,host2,host3', replicaSet='foo',
    read_preference=ReadPreference.SECONDARY_PREFERRED,
    tag_sets=[{'dc': 'ny'}, {}],
    secondary_acceptable_latency_ms=50)

(Обратите внимание, что то, что я называю «режимом», настраивается с помощью read_preferenceопции.)

Если вы инициализируете MongoReplicaSetClient, как это, то все чтения используют настроенный вами режим, наборы тегов и задержку. Вы также можете переопределить любой из этих трех вариантов post-hoc:

rsc = MongoReplicaSetClient('host1,host2,host3', replicaSet='foo')
rsc.read_preference = ReadPreference.NEAREST
rsc.tag_sets = [{'disk': 'ssd'}]
rsc.secondary_acceptable_latency_ms = 1000

Вы можете сделать то же самое при доступе к базе данных из MongoReplicaSetClient:

db = rsc.my_database
db.read_preference = ReadPreference.SECONDARY

Или коллекция:

collection = db.my_collection
collection.tag_sets = [{'dc': 'cloud'}]

Вы даже можете установить свои предпочтения для отдельных вызовов методов:

results = list(
    collection.find({}, secondary_acceptable_latency_ms=0))

document = collection.find_one(
    {'field': 'value'}, read_preference=ReadPreference.NEAREST)

Каждый из этих четырех уровней — соединение, база данных, коллекция, метод — наследует параметры предыдущего уровня и позволяет их переопределять.

(Дальнейшее чтение: настройки чтения PyMongo , MongoReplicaSetClient PyMongo .)

stats = rsc.my_database.command(
    'dbStats', read_preference=ReadPreference.SECONDARY)

collection.find(
    {'field': 'value'},
    read_preference=ReadPreference.SECONDARY_PREFERRED,
    tag_sets=[{'dc': 'ny'}, {}])

{
    $query: {field: 'value'},
    $readPreference: {
        mode: 'secondaryPreferred',
        tags: [{'dc': 'ny'}, {}],
    }
}

rsc.read_preference = ReadPreference.NEAREST
rsc.tag_sets = [{'dc': 'ny'}, {}]

rsc = MongoReplicaSetClient('host1,host2,host3', replicaSet='foo')