Има теоретични граници, както ще покажа по-долу, но дори долната граница е доста Високо. Не е лесно да се изчислят границите правилно, но порядъкът на величината трябва да е достатъчен.
mmapv1
Действителното ограничение зависи от няколко неща, като дължина на имената на шардове и други подобни (това обобщава, ако имате няколкостотин хиляди от тях), но ето грубо изчисление с реални данни.
Всеки шард се нуждае от малко място в config db, което е ограничено като всяка друга база данни до 32TB на една машина или в набор от реплики. На сървърите, които администрирам, средният размер на запис в config.shards е 112 байта. Освен това всяка част се нуждае от около 250 байта информация за метаданни. Нека приемем, че оптималните размери на парчетата са близки до 64MB.
Можем да имаме максимум 500 000 парчета на сървър. 500 000 * 250 байта се равняват на 125 MB за информацията за парчета на фрагмент. Така че на шард имаме 125,000112 MB на шард, ако изчерпим максимално всичко. Разделянето на 32TB на тази стойност ни показва, че можем да имаме максимум малко под 256 000 фрагмента в клъстер.
Всеки шард от своя страна може да побере данни на стойност 32TB. 256 000 * 32TB е 8,19200 екзабайта или 8 192 000 терабайта. Това би било ограничението за нашия пример.
Да кажем, че има 8 екзабайта. Към момента това може лесно да се преведе на „Достатъчно за всички практически цели“. За да ви създаде впечатление:Всички данни, съхранявани от Библиотеката на Конгреса (може би една от най-големите библиотеки в света по отношение на размера на колекцията) съдържат приблизителен размер на данните от около 20 TB, включително аудио, видео и цифрови материали. Можете да го поставите в нашия теоретичен MongoDB клъстер около 400 000 пъти. Имайте предвид, че това е долната граница на максималния размер, използвайки консервативни стойности.
WiredTiger
Сега за добрата част:Механизмът за съхранение на WiredTiger няма това ограничение:Размерът на базата данни не е ограничен (тъй като няма ограничение за това колко файлове с данни могат да се използват), така че можем да имаме неограничен брой сегменти. Дори когато имаме тези сегменти, работещи на mmapv1 и само нашите конфигурационни сървъри на WT, размерът на a става почти неограничен – ограничението до 16,8M TB RAM на 64-битова система може да причини проблеми някъде и да причини индексите на config.shard колекцията да бъде разменена на диск, спирайки системата. Мога само да гадая, тъй като моят калкулатор отказва да работи с числа в тази област (и ме мързи да го правя на ръка), но оценявам ограничението тук в областта на двуцифрените йотабайти (и пространството, необходимо за хостване на това някъде с размера на Тексас).
Заключение
Не се притеснявайте за максималния размер на данните в шардинг среда. Независимо от всичко, това е достатъчно, дори и при най-консервативния подход. Използвайте шардинг и сте готови. Между другото:дори 32TB са адски много данни:Повечето клъстери, които познавам, съдържат по-малко данни и фрагменти, тъй като IOPS и използването на RAM надвишават капацитета на един възел.
