Ръководство за разработчици за MongoDB Sharding

Масовият ръст на данните идва с разходи за намалена пропускателна способност, особено когато се обслужват от един сървър. Въпреки това, можете да подобрите тази производителност, като увеличите броя на сървърите и също така разпределите данните си на няколко броя от тези сървъри. В тази статия, набори от реплики в MongoDB, обсъдихме подробно как операциите с пропускателна способност могат да бъдат подобрени, освен да се гарантира висока наличност на данни. Този процес не може да бъде постигнат напълно, без да се спомене Sharding в MongoDB.

Какво е Sharding в MongoDB

MongoDB е проектиран по гъвкав начин, така че да е мащабируем, за да работите в клъстер в разпределена платформа. В тази платформа данните се разпределят в редица сървъри за съхранение. Този процес се нарича разделяне. Ако един сървър е подложен на голямо количество данни за съхранение, може да свършите пространството за съхранение. В допълнение, много критични операции с пропускателна способност, като четене и запис, могат да бъдат засегнати до голяма степен. Функцията за хоризонтално мащабиране в MongoDB ни позволява да разпределяме данни между множество машини с краен резултат от подобряване на балансирането на натоварването.

Части MongoDB

Един фрагмент може да се счита за набор от реплика, който хоства някои подмножества от данни, използвани в разчленен клъстер. За даден mongod екземпляр с някакъв набор от данни, данните се разделят и се разпределят в редица бази данни в този случай фрагменти. По принцип редица различни фрагменти служат като независими бази данни, но заедно съставляват логическа база данни. Частите намаляват натоварването, което трябва да се изпълнява от цялата база данни, като намаляват броя на операциите, които шардът трябва да обработва, освен по-малкото количество данни, което този шард ще хоства. Този показател дава място за хоризонтално разширяване на клъстер. По-долу е показана проста архитектура на разделяне.

Данните, изпратени от клиентско приложение, се прихващат от драйвери на сървъра и след това се подават на рутера. След това рутерът ще се консултира с конфигурациите на сървъра, за да определи къде да приложи операцията за четене или запис на сървърите на сегменти. Накратко, за операция като запис, той има някакъв индекс, който ще диктува кой сегмент е записът да бъде хост. Да приемем, че база данни има капацитет от 1TB данни, разпределен в 4 шарда, всеки шард ще съдържа 256GB от тези данни. С намалено количество данни, които шардът може да обработва, операциите могат да се извършват доста бързо. Трябва да помислите за използването на раздробения клъстер във вашата база данни, когато:

Очаквате количеството данни да надхвърли капацитета ви за съхранение на единичен екземпляр в бъдеще.
Ако операциите по запис не могат да бъдат извършени от единичния екземпляр на MongodB
Изчерпвате RAM паметта с произволен достъп за сметка на увеличения размер на активния работен комплект.

Разделянето идва с повишена сложност в архитектурата, освен допълнителни ресурси. Въпреки това е препоръчително да правите разделяне на ранни етапи, преди данните ви да надраснат, тъй като е доста досадно да го правите, когато данните ви са извън капацитета.

Shard Key MongoDB

Както всички знаем, документ в MongoDB има полета за съхранение на стойности. Когато разгръщате шардинг, ще трябва да изберете поле от колекция, което ще използвате за разделяне на данните. Това поле, което сте избрали, е ключът на шарда, който определя как ще разделите документите в колекцията на няколко фрагмента. В прост пример вашите данни може да имат имена на полета ученици, класни ръководители и оценки. Можете да решите, че един набор от фрагменти да съдържа документите с индексиращия ученик, друг – учители и оценки. Въпреки това, може да изискате вашите данни да се разпределят на случаен принцип, следователно да използвате хеширан ключ на сегмента. Освен хеширания ключ за сегменти има редица ключове, използвани за разделяне на данни, но двете основни категории са индексирано поле и индексирано съставно поле.

Избор на ключ за сегменти

За по-добра функционалност, възможности и производителност на стратегията за разделяне, ще трябва да изберете подходящия разделен ключ. Критериите за избор зависят от 2 фактора:

Структура на схемата на вашите данни. Можем например да разгледаме поле, чиято стойност може да се увеличава или намалява (променя се монотонно). Това най-вероятно ще повлияе на разпределението на вмъкванията към един фрагмент в рамките на клъстер.
Как се представят вашите конфигурации за заявки за извършване на операции по запис.

Какво е хеширан ключ на фрагмент

Това използва хеширан индекс на едно поле като ключ за фрагмент. Хешираният индекс е индекс, който поддържа записи с хешове на стойностите на индексирано поле, т.е.

{
    "_id" :"5b85117af532da651cc912cd"
}

За да създадете хеширан индекс, можете да използвате тази команда в mongo shell.

db.collection.createIndex( { _id: hashedValue } )

Където променливата hashedValue представлява низ от посочената от вас хеш стойност. Хешираното разделяне насърчава равномерното разпределение на данни в разделен клъстер, като по този начин намалява целевите операции. Въпреки това, документи с почти еднакви ключове на фрагменти е малко вероятно да са на един и същи фрагмент, поради което изискват монго инстанция да извърши разпръскваща операция, за да удовлетвори даден критерий за заявка.

Ключ за сегменти, базиран на диапазон

В тази категория наборът от данни е разделен въз основа на диапазони от стойности на избран ключ на полето, следователно голям диапазон от дялове. т.е. ако имате цифров ключ, чиито стойности се движат от отрицателна безкрайност до положителна безкрайност, всеки ключ от фрагмент ще падне в определена точка в тази линия. Този ред е разделен на парчета, като всяка част има определен диапазон от стойности. Точно тези документи с почти подобен ключ на фрагменти се хостват в една и съща част. Предимството на тази техника е, че поддържа редица заявки, тъй като рутерът ще избере фрагмента с конкретната част.

Характеристики на оптимален ключ за сегменти

Идеалният ключ за шард трябва да може да насочва към един сегмент, за да подобри програмата mongos да връща операции на заявка от един екземпляр на mongod. Основното, че основното поле, характеризира това. т.е. не във вграден документ.
Имат висока степен на произволност. Това означава, че полето трябва да е налично в повечето документи. Това ще гарантира, че операциите по запис са разпределени в рамките на шарда.
Бъдете лесно делими. С лесно разделяем ключ за сегменти има увеличено разпределение на данни, следователно повече фрагменти.

Severalnines Станете DBA на MongoDB – Пренасяне на MongoDB в Производството Научете какво трябва да знаете, за да внедрите, наблюдавате, управлявате и мащабирате MongoDB Изтеглете безплатно

Компоненти на внедряване на производствен клъстер

По отношение на архитектурата, показана по-горе, производственият клъстер на фрагменти трябва да има:

Mongos/ рутери за заявки. Това са монго екземпляри, които действат като сървър между драйверите на приложението и самата база данни. При внедряването балансиращото натоварване е конфигурирано така, че да позволява връзка от един клиент за достигане до същите mongo.
Шардове. Това са дяловете, в които се хостват документи, споделящи една и съща дефиниция на ключа. Трябва да имате поне 2, за да увеличите достъпността на данните.
Конфигурационни сървъри:можете да имате 3 отделни сървъра за конфигуриране на различни машини или група от тях, ако ще имате множество разчленени клъстери.

Разгръщане на разчленен клъстер

Следните стъпки ще ви дадат ясна насока за разгръщане на вашия разчленен клъстер.

Създаване на хост за конфигурационните сървъри. По подразбиране сървърните файлове са налични в директорията /data/configdb, но винаги можете да зададете това на предпочитаната от вас директория. Командата за създаване на директорията с данни е:
```
$ mkdir /data/configdb
```
Стартирайте конфигурационните сървъри, като дефинирате порта и пътя на файла за всеки с помощта на командата
```
$ mongod --configsvr --dbpath /data/config --port 27018
```
Тази команда ще стартира конфигурационния файл в директорията с данни с името config на порт 27018. По подразбиране всички сървъри на MongoDB работят на порт 27017.
Стартирайте mongos екземпляр, като използвате синтаксиса:
```
$ mongo --host hostAddress --port 27018.
```
Променливата hostAddress ще има стойността за името на хоста или ip адреса на вашия хост.
Стартирайте mongod на сървъра на шардовете и го инициирайте с помощта на командата:
```
mongod --shardsvr --replSet
rs.initiate()
```
Стартирайте вашите mongo на рутера с командата:
```
mongos --configdb rs/mongoconfig:27018
```
Добавяне на парчета към вашия клъстер. Да кажем, че имаме порт по подразбиране да е 27017 като наш клъстер, можем да добавим шард към порт 27018 по следния начин:
```
mongo --host mongomaster --port 27017
sh.addShard( "rs/mongoshard:27018")
{ "shardAdded" : "rs", "ok" : 1 }
```

Активирайте разделянето за базата данни, като използвате името на шарда с командата:

sh.enableSharding(shardname)
{ "ok" : 1 }

Можете да проверите състоянието на шарда с командата:

sh.status()

Ще ви бъде представена тази информация

sharding version: {
"_id" : 1,
"minCompatibleVersion" : 5,
"currentVersion" : 6,
"clusterId" : ObjectId("59f425f12fdbabb0daflfa82")
}
shards:
{ "_id" : "rs", "host" : "rs/mongoshard:27018", "state" : 1 }
active mongoses:
"3.4.10" : 1
autosplit:
Currently enabled: yes
balancer:
Currently enabled: yes
Currently running: no
NaN
Failed balancer rounds in last 5 attempts: 0
Migration Results for the last 24 hours:
No recent migrations
databases:
{ "_id" : shardname, "primary" : "rs", "partitioned" : true }

Балансиране на фрагменти

След добавяне на фрагмент към клъстер, може да забележите, че някои фрагменти все още могат да хостват повече данни от други и за да бъде по-секантно, новият шард няма да има данни. Следователно трябва да изпълните някои проверки на фона, за да осигурите баланс на натоварването. Балансирането е основата, за която данните се преразпределят в клъстер. Балансьорът ще открие неравномерно разпределение и следователно ще мигрира парчета от един фрагмент към друг, докато се достигне кворум за баланс.

Процесът на балансиране консумира много честотна лента, освен режийните разходи за натоварване и това ще повлияе на работата на вашата база данни. По-добрият процес на балансиране включва:

Преместване на една част наведнъж.
Извършете балансирането, когато бъде достигнат прагът за мигриране, т.е. когато разликата между най-ниския брой парчета за дадена колекция и най-големия брой парчета в разчленената колекция.