Офигенно, уже 428 ГБ занимает база. Чем дальше тем страшнее

А драйв на скок

Движок хранилища и алгоритм сжатия одинаковый с источником?

Понятно, у меня теперь другая трабла, посущественнее, названия коллекций в лимит уперлись Collection name must be between 1 and 57 bytes Неужели придется переименовывать все коллекции больше 57 байт?

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

облако, documentdb

А из архивированного дампа монги можно извлечь файлы в json? В доке не вижу такой возомжности

Друзья, привет. В выводе rs.status() поле lastHeartbeat с актуальной датой свидетельствует о том, что узел в порядке и доступен?

Да, но руками

Ха, уже наткнулся на первый камень в виде невозможности шринкануть коллекцию Feature not supported: compact

Привет, народ! Поднимаю монгу в докер-контейнере, указываю кейфайл, а он говорит, что bad file. В атрибутах mongod root 1024. В чем может быть проблема?

Как выглядит ошибка полностью?

Какой имейдж монги используешь? latest?

Ну и /data/keyfile.txt в контейнер кладешь, ведь?

Нужно убедиться, что: 1. в /data/ лежит keyfile.txt (запусти /bin/sh, например). 2. У keyfile проставлены корректные права.

-v /mnt:/data должно хватить. В любом случае тебе нужно зайти внутрь контейнера. Примерно так: docker run -v /mnt:/data/mnt -it mongo:4.2.1-bionic /bin/sh Затем перейди в /data/mnt и посмотри, что там лежит твой keyfile с нужными правами Потом перепиши путь в конфиге с /data/keyfile.txt на /data/mnt/keyfile.txt и запускай монгу

Привет. 1) Можно ли из апликухи создать view в монге (db.createView())? Спринг дата, монго драйвер 3.8 (мб mongotemplate умеет) И если да, то как правильно это делать? Если более развернуто - а вообще норм идея реализовать софт делит через вьюху, в которой записи ток с deleted:false (чтобы не кастомизироаать запросы - спрингдата даёт из коробки)? Индексы там от родной коллекции судя по доке. Или же это плохая идея? (And why) 2) тоже спринг дата и монго. Есть set<optionsDocument> в документе userDocument. Если вешать (юзать) @DBRef до поры до времени все ок, пока не захочется сделать аггрегацию по содержимому optionsDocument... Да и умные люди пишут что надо юзать мануал референс (т.к. есть рестрикшнв по дбреф)? Как это реализовывать? Делать set<objectId> и все методы спринг даты (find/findall)вручную переписывать на аггрегации? Или можно просто тоже аноташку навесить? А норм будет оставить set<optionsDocument> и хранить там сразу все данные (ембед реф это называется вроде или как..) ПЛЮС в отдельной коллекции ТОЖЕ хранить optionsDocument (в примерах доки такой вариант не рассматривался) и если optionsDocument изменится - у всех юзеров его тоже менять (1 option это по сути список прав с именем, который может меняться, я полагаю меняться будет редко, добавляться чаще, но последнее нас не аффектит), а при создании/изменении юзера чекать по айди все ли поля совпадают с option в юзере и в своей коллекции (поля у опшн всего два-имя и список прав). Сори если несу дичь парни, но от помощи не откажусь :3

Блин, файл на месте. А права какие должны быть? Извини, если туплю, я с линуксом не так давно знаком)

Покажи ls -la

UserDocument: id: ObjectId.. roles: Set<RoleDocument> RoleDocument: id: ObjectId.. rights: Set<String>

Реализуете ролевой контроль доступа?) Пару недель назад точно такую же систему пилил, правда использовал не spring, а mongoose, так как пишу на ноде. Я в поле role вписывал ObjectID документа роли, которой обладает пользователь. При запросе делал $lookup (populate для mongoose), что, насколько я понимаю, является аналогом JOIN-а для реляционных бд. Все запросы идут очень быстро, ведь для ObjectID делается индекс по умолчанию.

Да, но каждый запрос надо будет писать с кастомным $lookup итд. да?

Нужно правильно организовать связь user-role roles: Set<DBRef> (у меня в коде Set<RoleDocument>) roles: Set<ObjectId> roles: Set<RoleDocument> 1) C первым все ок. Мой драйвер успешно тащил при findAll все что нужно + я слыхал там даже lazy есть теперь у DBref Но мне понадобилось (задача Х) отфильтровать findAll users по rights, которые в роли. Как я понял с DBRef это не сделать (по крайней мере малой кровью). 2) С Set<ObjectId> (manual reference) я наколбасил такую штуку db.ucars_user.aggregate([{ "$lookup": { "from": "role", "localField": "rolez", "foreignField": "_id", "as": "rolezz" } }, {"$project": {"rolezz": 1}},{ "$match": {"rolezz": { "$elemMatch": { "name": { "$eq": "role3"}}}}}]) И она делает то что мне надо - (задача Х) (ну в запросе названия role rolezz в зав-ти от названий коллекций и поля у юзера) И это работает. Но при findAll users мне придется как-то доставать для каждого юзера роли (с Set<ObjectId> ходить за реальными ролями). Это тоже аггрегацией решается наверно. То есть мне придется пистаь кастомный запрос findAll, а до этого все из коробочки делалось springData (ну тоже с lookup) Не хочется писать слишком мнго кастомных запросов 3) И что я решил сделать, не знаю верно ли это Сделать в users целый Set<RoleDocument> То есть хранить и айдишник и Set<String> (rights) Но при этом все равно иметь отдельную коллекцию RoleDocument (для своих целей) Минус в том, что при edit RoleDocument элементов придется проходиться по коллекции users (allusers) и там менять RoleDocument чтобы они соответствовали тем, что в коллекции RoleDocument. То есть если было UserDoc: id: 1 roles: { Role1: {right1,right2} } RoleDoc: id: 1 rights: {right1, right2} И мы решили сделать RoleDoc: id: 1 rights: {right1} Придется пройтись по всем юзерам и вручную у них roles: { Role1: {right1,right2} } >>> roles: { Role1: {right1} } И при вставке нового юзера проверять что rights: Set<String> с id=Y тоже соответствует Set<String> в коллекции RoleDocument с id=Y. Таким образом мне не придется имплементить заного findAll/find итд для юзера, чтобы он $lookup зависимость... Так как updateRole операция редкая, а при вставке юзера проверить соответствие не оч трудно, вроде норм? или лажа все равно и надо брать пункт 2 с lookup на каждый чих?))))