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

Question

Вы написали собственные балансировочные устройства для разделения на балансные блоки, не использующие балансировщик в MongoDB, и не могли бы вы объяснить, почему вы должны это делать?

Answer 1

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

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

https://jira.mongodb.org/browse/SERVER-2545 https://jira.mongodb.org/browse/SERVER-4621

Answer 2

Два ответа по цене одного:

1. Цель: более медленная балансировка - Можно написать пользовательский балансировщик, который будет работать медленнее, добавляя временные задержки между каждым циклом баланса.Это может быть использовано для снижения пропускной способности IOPS / диска в тех случаях, когда вы разделяете пропускную способность с другими (предположительно более важными) приложениями.Я мог бы предложить использовать unix 'nice' на ваших демонах или настроить балансировку для использования расписания (см. Документы Mongo).

Примечание: В MongoDB версии 2.4 значение по умолчанию изменилось на primaryThrottle , чтобы проверить, что данные записываются во вторичные серверы, прежде чем перейти к переходу к чанкам.Это может значительно замедлить миграцию чанка, если вы просто отключите своих вторичных серверов.Чтобы это исправить, наберите:

use config
db.settings.update({"_id":"balancer"},{$set:{"_secondaryThrottle":false}})

1. Цель: более быстрое балансирование - Мы все знаем, что балансировщику может потребоваться вечность, чтобы уравновесить дико несопоставимые количества чанков, порядка дней.Я НЕ написал такого рода балансировщик, но я легко вижу, каким он может быть.Существует предположение, что за один раз может двигаться только один кусок.Если мы предположим, что у нас есть большое количество сегментов (скажем, 48 из них), и у каждого из них есть свой собственный диск / устройство, эту концепцию миграции МОЖНО БЫТЬ УСКОРЕННО объединить в пару сегментов / фрагментов, которые нужно перенести, и заставить все это войти впараллельно.

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

Или один из нас мог бы спросить 10Gen, если бы вы / я / мы написали такое животное, было бы оно полезным или просто привело бы к боли и смерти, или, что еще хуже, было вынуждено жить вМиссисипи.