« Rev
@mongodb_ru   101
Fwd »


Max
может индексы не учитываются, но половина размера - индексы - тож странно
Alex
а local точно размер оплога показывает ?
Max
оплог хранится в local
Alex
я просто не совсем слесарь )
Alex
ок
Max
да вот и я тоже :) пытаюсь углубиться
Alex
я думаю скорее это цифра реальная которая храниться
Alex
во всяком случае у меня показывает 32 Гб
Alex
тоже по идее должен быть 50Гб
Max
WT использует сжатие, может быть оно как-то влияет. и show dbs кажет реальное место на диске, в то время как данных внутри - 50 гиг. ничего умнее пока придумать не могу. Может быть @dd_bb поделится своими мыслями?
Alex
на диске занято таки 55Гб
Alex
5Гб размер базы
Max
тоже по идее должен быть 50Гб
база в репликасете?
Alex
да
Max
rs.printReplicationInfo() сделай плиз и покажи размер оплога
Alex
в личку
yopp
Чо
Max
Чо
сорри за пинг
yopp
в личку
Нажми на rs.oplog.stats()
Max
вопрос в том, почему show dbs показывает базу local в 25 гиг, в то время как размер оплога - 50 гиг?
yopp
Какую проблему вы пытаетесь решить вообще? WT по дефолту snappy использует. Хз насчёт оплога, но наверное тоже, почему нет. В stats всё напишут.
Max
не совсем проблему решаю пытаюсь просветиться с помощью коллективного разума :)
yopp
В show dbs; по-моему storage size показывается, а это сколько реально места в дисковом хранилище выделено (именно что выделено, а не используется, там же CoW, страницы могут быть использованы повторно)
Max
про CoW - шикарная идея, спасибо я все-таки про сжатие думал.
Max
надо почитать, на что capped на коллекцию работает реальные данные или дисковые данные. ушел читать. спасибо всем откликнувшимся!
yopp
Открой ты stats и там всё напишут.
yopp
Там есть и storage size и data size и три мешка метрик WT, включая free pages
yopp
Capped ограничивает data size, afair
yopp
Так что если настроено 50 гб, а реально занято 25 это значит что оно в два раза сжалось. Не факт что оно будет так всегда, этож оплог. Нальют слабо сжимаемых данных — отрастёт.
Max
Спасибо! а про "открой stats" - это, простите за лоу вопрос, вкуда смотреть?
yopp
db.getCollection(name).stats()
Max
Спасибо! направления ясно, ушёл ковырять
yopp
Или просто db.<name>.stats()
yopp
Но в оплоге точка, не выйдет так.
Cap
Мне нужна онлайн копия бд.(на случай отказа ssd) Можно это сделать через репликацию?
Cap
Пишу в primary оно пишется еще и в secondary правильно?
Cap
Через replica set
Cap
Делаю все по инструкции. Главный (первый) сервер стал primary Присоединил второй пустой. Теперь первый стал secondary а второй startup. Что делать?
Dmitry
Приоритеты ?
yopp
Т.е. ноды не могут решить кто главный.
Nick
там гдето был пунктик про нечетное число нод в репликасете
Cap
разобрался заработало но как только включаю authorization: enabled то реплики не могут авторизоваться
Cap
нужно делать Internal Authentication ? через keyFile: ?
yopp
Внимательно прочитай весь раздел по аутентификации в документации. Там очень подробно написано.
Petro
Ребята, есть массив root, это массив объектов, мне нужно найти позицию объекта в массиве у которого _id="12345"
CC-BY-SA-4.0/Docker-ce30.0
Ок
Nick
@dd_bb подскажи по такой ситуации: создаю шард коллекцию, создаю индексы, заливаю в коллекцию доки около 500 тыщ, по collname.stats() размер индексов условно 50Мб. Т.к. коллекция тестовая делаю ребилд индексов и получаю условно 20Мб. Собственно вопрос, а можнга сама умеет как-то сжимать индексы если все становится плохо? Ну например я залью не 500к а 500 мультов. Хочется понять какой размер индексов меня ожидает и сколько оперативы нужно
Nick
Собственно считай сам ответил про делает она сама чтонить или нет: Normally, MongoDB compacts indexes during routine updates. Вопрос только про эффект от автоматического сжатия будет сопоставим с ребилдом в плане используемого еста?
yopp
т.е. если у тебя 500к документов и 20Мб это 20*1024*1024/500000 = 42 байта
Nick
собственно так и думал делать, но вот это изменение в размере после реиндексации немного сбило с толку
yopp
лучше считать по верхней границе
Nick
просто считать по плохому сценарию где было 50М или уже после компакта
yopp
по плохому, да
yopp
better be safe than sorry
Nick
ну да здравый смысл он такой)
Nick
еще я там где вычитал что монга могет редкоиспользуемые части индекса убирать из памяти и работать с тем что осталось. это в реальности работает?
yopp
я рекомендую не воспринимать рекомендации монги слишком буквально
yopp
там есть ряд рекомендаций которые являются, скажем так, скорее обязательными, а ряд, которые являются решением проблем, которые могут и не возникнуть
yopp
короч, не стоит заниматься предварительной оптимизацией
yopp
т.е просто через find не получится
yopp
Если это нужно для обновления, то есть $: https://docs.mongodb.com/manual/reference/operator/update/positional/
Vyacheslav
Здравствуйте! Есть такой вопрос Имеется MongoDB 3.0.7, в ней имеется бд размером 10 ГБ, одна коллекция весит 6.5 ГБ (bson) Соответственно, запросы идут медленно к данной базе Можете подсказать, в какую сторону можно оптимизировать Я так понимаю, нужно смотреть в сторону GridFS, но не пойму, как преобразовать обычный bson 6.5 ГБ в gridFS
yopp
Привет. Нет, не нужно смотреть в gridfs. Это решение для хранение файлов в монге. В любом случае оно в самой монге будет храниться как bson. Нужно изучить запросы (см explain) и создать поддерживающие индексы.
Vyacheslav
понял, спасибо а можете подсказать по поводу оперативки, диска, сколько его нужно для нормальной работы с коллекциями такого размера сейчас на сервер 5 ГБ оперативы при размере бд 10 ГБ и еще вопрос по поводу engine - стоит ли смотреть в сторону WiredTiger или MMAP тоже норм?
yopp
Даже нужно смотреть в сторону wiredtiger. Смотреть надо на размер индексов
yopp
Памяти должно хватать на индексы + часто используемые данные
Vyacheslav
ну и по поводу миграции на новые версии, есть ли у кого опыт насколько я понимаю нужно мигрироваться 3.0 -> 3.2 -> 3.4 есть ли какие-то подводные камни?
yopp
Можно сделать дамп и обновиться сразу до 3.4
yopp
Залив его в 3.4 в смысле
Vyacheslav
ок, понял а есть несовместимости в bson-формате между вервиями?
Vyacheslav
или впринципе не должны быть
yopp
Скажем что нет. Bson отдельный стандарт, последнее что там появилось — decimal128
yopp
Это кажется в районе 3.4 и случилось. Или 3.2
Vyacheslav
ок, понял, спасибо
Cap
А что за колекции по 6гб, что там?
Cap
Зависит от того что это за данные, по ним нужно искать? или можно сохранить как большой бинарный кусок
Vyacheslav
5 млн записей, нужна пагинация с фильтрами
« Rev
@mongodb_ru   101
Fwd »