MongoDB от теории к практике. Руководство по установке кластера mongoDB

[asktomsk]

Замечательная статья. Хоть и работал с MongoDB и имел в голове картинку из пунктов 1 и 2, но не до конца понимал принцип как оно работает.
Очень понравилась практическая часть, после которой стало все абсолютно понятно.
Спасибо, жду продолжения!

[asktomsk]

Прошу прощения, не успел отредактировать комментарий.

После осмысления появилось несколько небольших вопросов:
Балансировкой шардов занимается сам Config Server или mongos? Кто кем управляет?
Можно ли запустить mongos без configdb и будет ли в таком случае работать шардинг?

P.S. пункт #3 встречается 2 раза.

[firefoxy]

mongos при своем старте поднимает процесс balancer, который как раз и занимается балансировкой шардов. Config server поднимается независимо от монгоса, но при старте самого монгоса мы обязаны передать его одним из параметров:
> mongos --configdb {host:port} --port {port}
причем если пропустить параметр --configdb, мы получим примерно следующую ошибку:
error: no args for --configdb
Ошибка связана с тем, что если монгос не закэширует данные из конфиг сервера, то он просто не знает на каком шарде лежит тот или иной чанк и роутинг запросов становится невозможным

[WellWisher]

У mongoDB есть отличные курсы,
DBA и Developers (под Java, Python и Node.js)

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

education.mongodb.com/

[ToSHiC]

У вас довольно мутное объяснение про правильный выбор shard key, а ведь это в горизонтальном масштабировании самое важное.

Основное условие выбора shard key: ваши запросы на запись должны равномерно размазываться по всем чанкам. Желательно, конечно, чтобы и чтения размазывались. Если это условие не соблюсти, то вас ожидает боль и печаль от лочащейся базы. Дополнительно есть возможность хешировать значение какого либо поля и после этого строить по нему shard key. Основная засада заключается в том, что поменять shard key в процессе работы невозможно. docs.mongodb.org/manual/core/sharding-shard-key/

[northbear]

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

В общем, строительство шарды раньше времени, это зло того же рода, что и преждевременная оптимизация кода.

[n0ne]

Обязательно напишите про репликацию! Лично я очень жду (-:

[EvgenyBorisov]

Отличная статья, спасибо автору! Возник такой вопрос, а можно ли для улучшение перформенса настроить Mongo так, чтобы все чунга чанги хринились не на диске а в оперативной памяти, как это например сделано в XAP. Ведь при правильно настроенных репликациях данные пропасть не должны. Зато производительность должна вырости неумоверно.

[firefoxy]

Насколько я знаю, хранить чанки в оперативной памяти нельзя, но этого и не нужно. MongoDB работает с памятью по принципу mmf — memory mapped files. В оперативную память помещается working set — самые частоиспользуемые документы + индексы. При записи в БД, документ обновляется либо добавляется в оперативную память, а только потом, в фоне, мапится на реальный файл на жестком диске, причем маппингом занимается процесс операционной системы.

Проблемы возникают, когда working set не влазит в оперативную память, появляются page faults и перформанс ухудшается (конечно, если у вас SSD, то это не так страшно).

Тема на самом деле обширная и я думаю, вынесу ее в отдельный пост.

[borodka_lenina]

> db.tickets.insert({name: “Max”, amount: Math.random()*100}) //инсертим первую запись в коллекцию tickets (если не существует, то будет создана при первом инсерте)

У тебя тут кавычки “Max” неправильные, при копипасте ругается «E QUERY SyntaxError: Unexpected token ILLEGAL»

[mrevgenx]

Очень классная статья. Жаль, что с новыми версиями много чего поменялось.
Если писать вот так в одном терминале:

sudo mongod --configsvr --dbpath /data/config --port 27002

А потом вот так в другом:

sudo mongos --configdb 127.0.0.1:27002 --port 27100

То получается ошибка:

BadValue: configdb supports only replica set connection string
try 'mongos --help' for more information

Может оказаться полезно следующее дополнение. Чтобы все это исправить и дойти до конца в практической части мне пришлось добавить опцию shardsvr для инстансов шардов:

sudo mongod --dbpath /data/instance1 --port 27000 --shardsvr
sudo mongod --dbpath /data/instance2 --port 27001 --shardsvr

Добавить replSetName в настройки конфиг-сервера, чтобы получился replica-set из одного сервера, в данном случае я запускал через опцию --config mongo.conf с таким файлом:

net:
   port: 27002
sharding:
   clusterRole: "configsvr"
storage:
   dbPath: "/data/config"
replication:
   oplogSizeMB: 128
   replSetName: configrs

И запустить mongos с конфиг-сервером как replica-set:

sudo mongos --configdb configrs/127.0.0.1:27002 --port 27100

В логах может быть что-то вроде «Unable to reach primary for set configrs», но решилось это простым ожиданием, видимо кластер из целого одного сервера выбирал primary реплику несколько дольше, чем я думал.