как проще всего заресторить из этого файла базу?

ты имешь ввиду только одну базу?

привет! я уже разобрался с этим форматом)

спасибо

общее правило: как бекапили, так и ресторим

в смысле набор опций

да, так и получилось)

Всем привет. Кто нибудь сталкивался с подобным: http://stackoverflow.com/questions/41328480/mongodb-command-compact-is-not-working

Всем привет. Кто нибудь сталкивался с подобным: http://stackoverflow.com/questions/41328480/mongodb-command-compact-is-not-working

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

но вообще покажи полную стату по коллекции, stats("indexDetails"). если у тебя WT то надо посмотреть есть ли свободные страницы. если есть, то repair должен по идее работать, но никто никогда этого не гарантировал

afair оно вообще должно это делать: перезаливать коллекцию по сути

ну и да, версию монги ты нигде не указал

shame on you

но вообще покажи полную стату по коллекции, stats("indexDetails"). если у тебя WT то надо посмотреть есть ли свободные страницы. если есть, то repair должен по идее работать, но никто никогда этого не гарантировал

https://gist.github.com/krabradosty/37730bb3ca00cced9225087e92b5c2af

интересно

shame on you

db version v3.2.9

попробуй сделать дамп с коллекции и посмотреть сколько весит дамп

Сейсчас не имею возможности. За идею спасибо.

ещё можно попробовать обновит ьмонгу

последняя стабильная 3.2.12

можешь глянуть в ченджлоге, может быть уже даже нашли и починили

Какие недостатки и подводные камни при использовании MongoDB, с которыми вы столкнулись ?

Какие недостатки и подводные камни при использовании MongoDB, с которыми вы столкнулись ?

зачем тебе?

Чтоб понять откуда ждать беды)

Какие недостатки и подводные камни при использовании MongoDB, с которыми вы столкнулись ?

много хейтеров

Это я уже заметил) У меня сетевая игра, мобильная, пошаговая сессионка, база на монгодб

Позволила более удобно организовать хранение данных, dto объекты мапятся в базу напрямую со всеми вложенными структурами

Чтоб понять откуда ждать беды)

откуда не жди, привалит оттуда, откуда не ждал

Предупреждён значит вооружён

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

Можно генерировать его явно при вставке

И отлавливать кей дупликейшн

в разных статьях говорится что вариантов ключа так много что коллизия настолько маловероятна что кей дупликейшн практически исключен. теоретическое 6*10^57 выглядит убедительно... а что вы думаете?

после mysql и autoincrement непривычно

И отлавливать кей дупликейшн

Вы вставляете больше 2^24/сек?

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

ну это конечно! спасибо!

Вы вставляете больше 2^24/сек?

Мы генерим свои айдишники

Для некоторых сущностей

UUID?

Нет.

Как id амазоновских сущностей

Никогда не работал с амазоном

в разных статьях говорится что вариантов ключа так много что коллизия настолько маловероятна что кей дупликейшн практически исключен. теоретическое 6*10^57 выглядит убедительно... а что вы думаете?

Мы думаем что на _id и так unique есть, так что даже если ты выиграешь в коллизионную лотерею, нет повода для беспокойства. Кроме вложенных документов, но там тоже можно сделать свой уникальный индекс. А все другие способы проверки уникальности без linearizable смысла не имеют.

☝️

Начал задумывать о шардинге и словил такую мысль прошу поправить, если где-то ошибся: если у меня по некоторым шардинг ключам будет намного больше документов чем по другим и когда-нибудь при росте бд в одном из чанков будут только доки конкретного ключа то: 1. остальные чанки будут уплотнены, т.е. содержать доки по нескольким шард ключам 2. собственно размер чанка ограничивает суммарный размер доков по одному шард ключу (в пределе 1Гб) и если планируется хранить больше для одного шард ключа, то нужно придумывать другой

везде ошибся

чанки по гигабайту не надо делать

индекс который собирает много документов в одном ключе тоже не надо делать

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

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

шардинг тебе зачем нужен?

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

просто хранить?

у данных локализация частоты использования есть какая-то?

что храним?

ну еще как обычно читать, определнный нефиксированный объем свежих данных подвержен апдейтам (теоретически подвержены апдейтам и старые данные), впринципе возможны мапредьюсы. храним по факту плоский док без вложений полей на 20-30

физический смысл в чём?

падает ли актуальность со временем?

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

только вот по данным котоыре мне сообщили ориентировочно вполне реально заиметь прирост в 3Тб в месяц через палгода-год

Зачем разбивать, если это в шарде можно сделать?

каким образом?

Композитный ключ и префикс из даты

Будет небольшой гемор если надо будет скейлить запись в ширину

Дальше накладываешь zone range и тегируешь шарды

Можно ещё меня нанять

ценник я помню)

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

Там много подводных камней. Это будет требовать некоторой ручной работы с чанками. Это усложнит всякие штуки типа «хочу ледигагу (user_id: 42666) повесить на отдельный шард»

вот поэтому и надо подумать

С такими вводными вариантов не очень много

и я бы ещё подумал какие требования к надёжности хранения таких объёмов

потому что бекпы на таких масштабах — крайне занимательная история

мне вот что интересно: как нода определяет размер чанка, чтоб решить что его надо бить?

понятно что есть dataSize, но он банально суммирует размер документов, читая их

но я на 99% уверен, не читая исходники, что нода так не делает на каждую запись

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

от drop() это не поможет особо :)

и от прочих неприятностей

по этому я и спросил про «требования к надёжности».

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

в логах все ок. Просто останваливаются записи и все

версия 3.2

OOM ?

что это?