MongoDB: Sharding на одной машине.Имеет ли это смысл? - PullRequest
Новая
       4

MongoDB: Sharding на одной машине.Имеет ли это смысл?

8 голосов
/ 25 июня 2011

создал коллекцию в MongoDB, состоящую из 11446615 документов.

Каждый документ имеет следующую форму: 

{ 
 "_id" : ObjectId("4e03dec7c3c365f574820835"), 
 "httpReferer" : "http://www.somewebsite.pl/art.php?id=13321&b=1", 
 "words" : ["SEX", "DRUGS", "ROCKNROLL", "WHATEVER"],     
 "howMany" : 3 
}

httpReferer : просто URL

words : слова, проанализированные с URL-адреса выше. Размер списка составляет от 15 до 90.

Я планирую использовать эту базу данных для получения списка веб-страниц с похожим содержанием.

Я сделаю запрос к этой коллекции, используя поле слов, поэтому я создал (или, скорее, начал создавать) индекс для этого поля: 

db.my_coll.ensureIndex({words: 1})

Создание этой коллекции занимает очень много времени. Я попробовал два подхода (тесты, приведенные ниже, были проведены на моем ноутбуке):

  1. Вставка и индексирование Вставка заняла 5,5 часов в основном из-за интенсивной предварительной обработки данных процессором. Индексирование заняло 30 часов.
  2. Индексирование перед вставкой Для вставки всех данных в сбор потребуется несколько дней.

Моя основная задача - уменьшить время создания коллекции. Мне не нужна репликация (по крайней мере, сейчас). Запросы также не должны быть быстрыми.

Теперь время для вопроса:

У меня есть только одна машина с одним диском, где я могу запустить свое приложение. Имеет ли смысл запускать более одного экземпляра базы данных и разделять мои данные между ними?

Ответы [ 5 ]

16 голосов
/ 22 февраля 2012

Да , имеет смысл использовать шард на одном сервере.

  1. В настоящее время MongoDB все еще использует глобальную блокировку для каждого сервера mongodb. Создание нескольких серверов освободит сервер от блокировок друг друга.

  2. Если вы используете многоядерный компьютер с отдельными NUMA, это может также увеличить производительность.

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

Машины различаются. Я предлагаю написать свою собственную программу тестирования массовых вставок и раскрутить различное количество серверных сегментов MongoDB. У меня есть 16-ядерный RAID-компьютер, и я обнаружил, что 3-4 осколка, кажется, идеально подходят для моей тяжелой базы данных записи. Я обнаружил, что мои два NUMA являются моим узким местом.

6 голосов
/ 05 августа 2015

В наше время (2015) с mongodb v3.0.x есть блокировка на уровне коллекции с помощью mmap, которая немного увеличивает пропускную способность записи (при условии, что вы пишете в несколько коллекций), но если вы используетеВ wiredtiger есть блокировка на уровне документа, которая имеет гораздо более высокую пропускную способность записи.Это устраняет необходимость в разделении на одну машинуХотя технически вы все равно можете повысить производительность mapReduce путем разделения на одну машину, но в этом случае вам лучше использовать инфраструктуру агрегации, которая может использовать несколько ядер.Если вы в большой степени полагаетесь на алгоритмы сокращения карт, возможно, имеет смысл использовать что-то наподобие Hadoop.

Единственная причина для шардинга mongodb - это горизонтальное масштабирование.Таким образом, в случае, если на одной машине не может быть достаточно дискового пространства, памяти или мощности ЦП (редко), тогда разбиение становится выгодным.Я думаю, что действительно очень редко кто-то имеет достаточно данных, которые им нужно осквернить, даже крупному бизнесу, особенно с учетом того, что в wiredtiger добавлена ​​поддержка сжатия, которая может снизить использование диска более чем на 80%.Также нечасто, когда кто-то использует mongodb для выполнения действительно больших нагрузок на процессор в больших масштабах, потому что для этого есть гораздо лучшие технологии.В большинстве случаев IO является наиболее важным фактором производительности, не так много запросов нагружают процессор, если вы не выполняете много сложных агрегаций, даже геопространственное индексируется при вставке.

Скорее всего, вы 'Если вам нужно много индексов, которые занимают большой объем ОЗУ, вам нужно использовать shard, wiredtiger уменьшает это, но это все еще самая распространенная причина для shard.В то время как разделение на одной машине, скорее всего, приведет к нежелательным накладным расходам, при этом очень мало или вообще не будет никаких преимуществ.

2 голосов
/ 07 января 2013

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

  1. сеть (т. Е. Вы находитесь на гигабитной линии, вы используете большую ее часть в пиковые моменты времени, но ваша база данных на самом деле не загружена)
  2. ЦП (ваш ЦП почти на 100%, но диск и сеть едва работают)
  3. диск

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

1 голос
/ 25 июня 2011

Нет, не имеет смысла расшаривать на одном сервере.

Есть несколько исключительных случаев, но они в основном сводятся к проблемам параллелизма, связанным с такими вещами, как запуск map / redu или javascript.

0 голосов
/ 25 июня 2011

Ответ дан в первом абзаце руководства по набору реплик

http://www.mongodb.org/display/DOCS/Replica+Set+Tutorial

...