Відповіді:
Якщо ви використовуєте шардинг, то "балансир завантаження" - це процес монгоса - насправді він більше схожий на маршрутизатор - він зберігає в пам'яті копію бази даних конфігурацій і може приймати рішення на основі ключа шару.
Якщо ви маєте на увазі балансування навантаження через ідентичні набори реплік або поміж членами набору, то є запит на функцію, щоб і монгоси обробляли цей сценарій ( https://jira.mongodb.org/browse/SERVER-1594 ), однак дано як драйвери працюють, це насправді не потрібно (однак це зробить драйвери менш складними).
В одному наборі реплік ви не можете поширювати записи, всі вони повинні перейти до основного. Ви вже можете розповсюджувати читання у вторинниках за допомогою пункту «Налаштування читання», як вважаєте за потрібне. Водій відслідковує, що є первинним, а що є вторинним, і маршрутизує запити належним чином.
"Врівноваження навантаження" досягається за допомогою шарнірування. Шардінгом ви фактично поширюєте записи / оновлення на окремі фрагменти. Не існує жодного конкретного алгоритму, який би зробив це, оскільки mongo дозволить вам розділити дані на основі будь-якої комбінації ключів. Найкращі алгоритми розділів - це ті, у яких є складова послідовних записів плюс випадкова.
Наприклад, ідентифікатор користувача можна розділити наступним чином
xx-sha1(user email)
xx = time sequence
Майте на увазі, що для здійснення шардингу вам потрібно мати три конфігураційні сервери та вузли даних. Вузли даних можуть бути згруповані в набори реплік для надмірності і можуть бути використані (лише якщо можна) для зчитування даних із вторинних видань. Я кажу лише, якщо ви можете прочитати дані, оскільки реплікація виконана асинхронно, тому не є гарантією того, що нові дані будуть доступні в час запитів у вторинних журналах.
Майте на увазі, що алгоритм розподілу повністю залежить від ваших потреб. Також слід врахувати, чи ви просто хочете записати дані, і лише у вас є випадкові читання або вам потрібно прочитати їх відразу після їх написання.