MongoDB Sharding на одной Linux-машине

Положительные стороны:

• у вас будет возможность одновременной записи при условии, что данные хешируются в разные шарды. MongoDB блокирует всю базу данных в этом экземпляре при выполнении записи, поэтому даже не сегментированный набор реплик может записывать только одну вещь за раз.
• это хороший способ изучения шардинга / наборов реплик / администратора, но если вы просто хотите это сделать, вы можете добиться этого с меньшим количеством экземпляров
• репликация будет очень быстрой :)

Минусы:

• вам понадобится мощная машина (несколько процессоров, но также как можно больше памяти и быстрые диски), чтобы действительно получить выгоду от производительности - Монго жаждет оперативной памяти! Для оптимальной производительности ваш общий размер индекса должен умещаться в ОЗУ, а это означает, что если у вас есть 2 гигабайта индекса на шард, вам понадобится 5 * 3 * 2 = 30 гигабайт оперативной памяти, а также память для ОС и т. Д.
• вы не можете получить много пользы от опции запроса slaveOK
• у вас не будет защиты от аппаратного сбоя - если коробка уйдет, все ваши шарды и ваши наборы реплик будут

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

Как правило, это не очень хорошая идея. Если вы запускаете пять отдельных процессов mongod (каждый из которых определен на сервере конфигурации mongo) и каждый записывает на отдельный диск (шпиндели, а не разделы), это может быть приемлемо и фактически дает вам некоторые преимущества в области Disk I / О. Однако вы не будете использовать память Мастера с максимальной пользой, и вы без необходимости усложнили настройку (особенно в теме резервного копирования / восстановления.

Обычно осколки выполняются только тогда, когда возникают задержки из-за операций ввода-вывода при записи на диск. (Задержки ввода-вывода при чтении можно уменьшить, включив Slave Read в драйвере языка.) Это указывает на необходимость масштабирования вашей архитектуры. Об этом важно помнить, потому что это означает, что вам следует покупать больше серверов. Содержание одного хозяина также значительно упрощает жизнь; шардинг увеличивает вашу сложность.

Начните с набора реплик, и если операции записи являются проблемой, затем ты осколок. Добавить шардинг намного проще, чем удалить его.

(Все это игнорирует возможность получить более быстрые диски и больше памяти. SSD часто делают ненужным сегментирование.)

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

|Host1     | Host2     | Host3     | Host4     | 
|Shard1Pri | Shard2Pri | Shard3Pri | Shard4Pri |
|Shard2Sec | Shard3Sec | Shard4Sec | Shard1Sec | 
|Shard3Sec | Shard4Sec | Shard1Sec | Shard2Sec | 
|Shard4Sec | Shard1Sec | Shard2Sec | Shard3Sec |