Зачем? У него полностью однородная информация, разложенная по папкам на диске. Он путает сам себя в понятиях.

не логично. Что, если мне нужно удалить источник из компании?

Зачем? У него полностью однородная информация, разложенная по папкам на диске. Он путает сам себя в понятиях.

не логично. Что, если мне нужно удалить источник из компании?

У вас логика вся - одна - найти петю или васю по принадлежности к ООО Метеорит или АО Гамбит

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

знаем, умеем практикуем) Поверхостно. Не было нужды в организации подобной структуры

С этим справится grep, sed и awk хоть с миллионом баз и компаний в текстовиках на диске.

Ну а как в Json перегонять будешь-то...

Да, тут согласен. Но для меня важно в какой базе я нашёл петю

Вся прелесть носкулей в схемалэс. Для такой логики не имеет практического смысла разбиение по таблицам (коллекциям). Только для себя, если вы хотите в гуи клиентах щёлкать по билдеру запроса на коллекциях с именем тех компаний.

Вся прелесть носкулей в схемалэс. Для такой логики не имеет практического смысла разбиение по таблицам (коллекциям). Только для себя, если вы хотите в гуи клиентах щёлкать по билдеру запроса на коллекциях с именем тех компаний.

Предполагается адская сложность с ремувом условно вида: db.companies.remove({ cmp_name: mb.regex.startsWith("Google") }) ❓

Предполагается адская сложность с ремувом условно вида: db.companies.remove({ cmp_name: mb.regex.startsWith("Google") }) ❓

Меня интересует как их логично записать в монгу? Монга / Мои данные ------------------------------ База данных = компания коллекция = база данных документ = инфа о пользоватле

собственно то, о чём я и писал изначально

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

имеешь в виду сбить коллекции в одну?

ты думаешь как сделать так чтобы было понятно в какой папке найдено

ну сделай поля соотвествующие. просто подумай на какие вешать индекс а на какие нет

если мне понадобиться изменить название базы? придеться бегать по всем документам в коллекции и менять поле database

Это вообще какая-то печаль. Вам NoSQL СУБД и вообще СУБД не нужна, если вы собираетесь в неё вставлять полностью одинаковые и обезличенные в плане отсутствия любой уникальности записи для того, чтобы было легко их удалять и понимать к чему они относятся только по названию коллекции или таблицы. Это не имеет ничего общего с административным подходом и не отличается ничем от файлов на диске, принадлежащих какой-то папке.

если мне понадобиться изменить название базы? придеться бегать по всем документам в коллекции и менять поле database

Второе - это вопрос или утверждение?

А что предполагается переименовать коллекцию и всего делов?

🤣 развлекайтесь, я посёль себе

У меня на компьютере есть много папок с названиями компаний в которых хранится много баз данных пользователей. Базы данных пользоватлей могут содержать в себе как 100 записей так и 100 млн. Если мне нужно что-то найти - открывается отдельно база и выполняется поиск. Да, это пиздец. Но, как уже есть. Я хочу добавить все эти данные в монгу для того, чтобы мне было легко искать по всем базам нужные мне данные. Как мне логически организовать своё хранилище данных в монге?

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

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

всё вышеперечисленной. Возможен даже фазинг

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

Спасибо. Атлас не подходит так как нужно развернуть локально. Идея была в том чтобы сделать монгу как базу для хранения. А поиск уже осуществлять в elastic

В эластике также все хранится

сейчас крутится в еластике. Свыше 500 индексов уже. Но смущает использование еластики для хранения и поиска

Ну эластик итак будет хранить чтоб поиск работал. Смысла удваивать косты на сопровождение еще одного инструмента и усложнять код работой со второй бд нет

да, получается нужен ещё и конектор...

нужно ведь как-то синхронизировать данные.... нужно подумать...

Не могу понять чем вам мало эластика, что хотите еще и в монгу загнать данные. Какие задачи вы на нем не можете решить?

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

Данные по разным компаниям имеют одинаковую структуру?

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

Но вы же приводите к единому неймингу полей?

Конечно. Это да

Все в один индекс наливаете, и добавляете поле органиция и допом любые другие. И все это давно удобно

Всем привет! есть коллекция на 600 000 записей , делаем простой find без фильтра через монгус с использованием lean, запрос виснет на 40-50 секунд. В чем может быть проблема, уже запарился искать. или это нормально что нелья такое количество выгрузить?

есть индексы?

есть индексы?

Что проще сделать? Переименовать коллекцию или значение ключа в десятках миллионов документов?

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

Если да, то методом проб и ошибок наш поиск очень замедлился, когда индекс перевесил 10гб. Как показала практика. Физический размер индекса играет роль. А у нас есть базы по 60 млн. документов. И нам пришлось их делить на индексы поменьше. Получается 1 база имела 3 индекса, к примеру

не каждый. Но этому есть место быть)

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

да, но опять таки если индекс не поместиться в оперативную память это печально) хах)

Индекс и не должен храниться в оперативке