ну может я чет не понимаю конечно

для чистоты эксперимента можно будет сравнить, когда в directory per db перееду, но... это позже.

может индексы не учитываются, но половина размера - индексы - тож странно

а local точно размер оплога показывает ?

оплог хранится в local

я просто не совсем слесарь )

ок

да вот и я тоже :) пытаюсь углубиться

я думаю скорее это цифра реальная которая храниться

во всяком случае у меня показывает 32 Гб

тоже по идее должен быть 50Гб

WT использует сжатие, может быть оно как-то влияет. и show dbs кажет реальное место на диске, в то время как данных внутри - 50 гиг. ничего умнее пока придумать не могу. Может быть @dd_bb поделится своими мыслями?

на диске занято таки 55Гб

5Гб размер базы

тоже по идее должен быть 50Гб

база в репликасете?

да

rs.printReplicationInfo() сделай плиз и покажи размер оплога

в личку

Чо

Чо

сорри за пинг

в личку

Нажми на rs.oplog.stats()

вопрос в том, почему show dbs показывает базу local в 25 гиг, в то время как размер оплога - 50 гиг?

Какую проблему вы пытаетесь решить вообще? WT по дефолту snappy использует. Хз насчёт оплога, но наверное тоже, почему нет. В stats всё напишут.

не совсем проблему решаю пытаюсь просветиться с помощью коллективного разума :)

В show dbs; по-моему storage size показывается, а это сколько реально места в дисковом хранилище выделено (именно что выделено, а не используется, там же CoW, страницы могут быть использованы повторно)

про CoW - шикарная идея, спасибо я все-таки про сжатие думал.

надо почитать, на что capped на коллекцию работает реальные данные или дисковые данные. ушел читать. спасибо всем откликнувшимся!

Открой ты stats и там всё напишут.

Там есть и storage size и data size и три мешка метрик WT, включая free pages

Capped ограничивает data size, afair

Так что если настроено 50 гб, а реально занято 25 это значит что оно в два раза сжалось. Не факт что оно будет так всегда, этож оплог. Нальют слабо сжимаемых данных — отрастёт.

Спасибо! а про "открой stats" - это, простите за лоу вопрос, вкуда смотреть?

db.getCollection(name).stats()

Спасибо! направления ясно, ушёл ковырять

Или просто db.<name>.stats()

Но в оплоге точка, не выйдет так.

Мне нужна онлайн копия бд.(на случай отказа ssd) Можно это сделать через репликацию?

Пишу в primary оно пишется еще и в secondary правильно?

Через replica set

Делаю все по инструкции. Главный (первый) сервер стал primary Присоединил второй пустой. Теперь первый стал secondary а второй startup. Что делать?

Приоритеты ?

Делаю все по инструкции. Главный (первый) сервер стал primary Присоединил второй пустой. Теперь первый стал secondary а второй startup. Что делать?

Добавить арбитра. У тебя нет большинства

Т.е. ноды не могут решить кто главный.

там гдето был пунктик про нечетное число нод в репликасете

разобрался заработало но как только включаю authorization: enabled то реплики не могут авторизоваться

нужно делать Internal Authentication ? через keyFile: ?

Внимательно прочитай весь раздел по аутентификации в документации. Там очень подробно написано.

Ребята, есть массив root, это массив объектов, мне нужно найти позицию объекта в массиве у которого _id="12345"

Ок

@dd_bb подскажи по такой ситуации: создаю шард коллекцию, создаю индексы, заливаю в коллекцию доки около 500 тыщ, по collname.stats() размер индексов условно 50Мб. Т.к. коллекция тестовая делаю ребилд индексов и получаю условно 20Мб. Собственно вопрос, а можнга сама умеет как-то сжимать индексы если все становится плохо? Ну например я залью не 500к а 500 мультов. Хочется понять какой размер индексов меня ожидает и сколько оперативы нужно

Собственно считай сам ответил про делает она сама чтонить или нет: Normally, MongoDB compacts indexes during routine updates. Вопрос только про эффект от автоматического сжатия будет сопоставим с ребилдом в плане используемого еста?

@dd_bb подскажи по такой ситуации: создаю шард коллекцию, создаю индексы, заливаю в коллекцию доки около 500 тыщ, по collname.stats() размер индексов условно 50Мб. Т.к. коллекция тестовая делаю ребилд индексов и получаю условно 20Мб. Собственно вопрос, а можнга сама умеет как-то сжимать индексы если все становится плохо? Ну например я залью не 500к а 500 мультов. Хочется понять какой размер индексов меня ожидает и сколько оперативы нужно

посчитать расход на одну запись и экстраполировать на количество записей

т.е. если у тебя 500к документов и 20Мб это 20*1024*1024/500000 = 42 байта

собственно так и думал делать, но вот это изменение в размере после реиндексации немного сбило с толку

лучше считать по верхней границе

просто считать по плохому сценарию где было 50М или уже после компакта

по плохому, да

better be safe than sorry

ну да здравый смысл он такой)

еще я там где вычитал что монга могет редкоиспользуемые части индекса убирать из памяти и работать с тем что осталось. это в реальности работает?

я рекомендую не воспринимать рекомендации монги слишком буквально

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

короч, не стоит заниматься предварительной оптимизацией

Ребята, есть массив root, это массив объектов, мне нужно найти позицию объекта в массиве у которого _id="12345"

только в Aggregation Framework: https://docs.mongodb.com/manual/reference/operator/aggregation/indexOfArray/

т.е просто через find не получится

Если это нужно для обновления, то есть $: https://docs.mongodb.com/manual/reference/operator/update/positional/

Здравствуйте! Есть такой вопрос Имеется MongoDB 3.0.7, в ней имеется бд размером 10 ГБ, одна коллекция весит 6.5 ГБ (bson) Соответственно, запросы идут медленно к данной базе Можете подсказать, в какую сторону можно оптимизировать Я так понимаю, нужно смотреть в сторону GridFS, но не пойму, как преобразовать обычный bson 6.5 ГБ в gridFS

Привет. Нет, не нужно смотреть в gridfs. Это решение для хранение файлов в монге. В любом случае оно в самой монге будет храниться как bson. Нужно изучить запросы (см explain) и создать поддерживающие индексы.

понял, спасибо а можете подсказать по поводу оперативки, диска, сколько его нужно для нормальной работы с коллекциями такого размера сейчас на сервер 5 ГБ оперативы при размере бд 10 ГБ и еще вопрос по поводу engine - стоит ли смотреть в сторону WiredTiger или MMAP тоже норм?

Даже нужно смотреть в сторону wiredtiger. Смотреть надо на размер индексов

Памяти должно хватать на индексы + часто используемые данные

ну и по поводу миграции на новые версии, есть ли у кого опыт насколько я понимаю нужно мигрироваться 3.0 -> 3.2 -> 3.4 есть ли какие-то подводные камни?

Можно сделать дамп и обновиться сразу до 3.4

Залив его в 3.4 в смысле

ок, понял а есть несовместимости в bson-формате между вервиями?

или впринципе не должны быть

Скажем что нет. Bson отдельный стандарт, последнее что там появилось — decimal128

Это кажется в районе 3.4 и случилось. Или 3.2

ок, понял, спасибо

А что за колекции по 6гб, что там?

Зависит от того что это за данные, по ним нужно искать? или можно сохранить как большой бинарный кусок

5 млн записей, нужна пагинация с фильтрами

Плюс вывод нрафиков по этим данным

Тогда gridfs тебе не поможет

Посчитай сразу по ним то что нужно и это сохрани

Я так понимаю, нужно смотреть в сторону индексов

И еще такой вопрос - в этой коллекции имеется вложенная коллекция, которая дополняется (массив). Остальные поля обновляются. Как лучше и проще вынести эту коллекцию в отдельную

В голову приходит вариант в скрипте по курсору пройтись и переместить

Вопрос только в том как создать связи между коллекциями

Почему у тебя такие колекции большие получились

Что это за данные?

Почему у тебя такие колекции большие получились

Большие?