например, у нас есть 1 млрд записей с составным индексом: "ar.bt.err", где фильтруемое поле "err", количество операций увеличивается кратно вложенности: 1 * 3 = 3 млрд, если не использовать .skip() или .limit() курсор будет идти именно 3 млрд раз если бы индекс был просто "err", то естественно было бы 1 * 1 = 1 млрд.

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

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

У вас ssr или фронт генерит разметку?

Ну на счет сложности я бы тут усомнился. Возьмем облако тегов, там есть теги на русском а есть на английском, и получается что нужен будет вместо простой выборке по массиву, выбирать из массивов объектов с фильтрацией по языку. Плюс если одновременно с документом работают разные контенщики каждый своего языка… Я бы взвесил, вынести по коллекциям языковым идея тоже жизнеспособна

У вас ssr или фронт генерит разметку?

Это в теории! На практике бизнес сразу придумает кейс, когда придётся агрегировать с двух баз, например: нет описание на китайском выводи на английском😀 и сложи в один селект

Ребят, почему по дефолту mongodb создает базу с названием test? И как ее изменить?

Ребят, почему по дефолту mongodb создает базу с названием test? И как ее изменить?

Не удалось правильно до конца распарсить строку подключения либо имя не было передано, поэтому используется значение по умолчанию

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

В документации не могу найти информацию о размерах типов данных. Примерно понятно, что Int32 занимает 32 бита и т.п., тем не менее, хотелось бы иметь возможность определить или оценить размер документа до вставки в коллекцию. Может кто ссылкой помочь?

Object.bsonsize(db.test.findOne({type:"auto"}))

По факту то да, есть возможность проверить. Мне бы хотелось в принципе при проектировании размер прикинуть, основываясь на типах свойств.

По факту то да, есть возможность проверить. Мне бы хотелось в принципе при проектировании размер прикинуть, основываясь на типах свойств.

Типа такого вы хотите https://stackoverflow.com/questions/1248302/how-to-get-the-size-of-a-javascript-object ?

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

Это как запасной вариант рассматривается )

вопрос: что за юзкейс: 1) ожидаете мега большие обьекты? - GridFS API можна сразу смотреть 2) просто проверка - нету смысла ничего делать

Например, место на диске оценить

Например, место на диске оценить

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

Так и понял, что только эмпирическим путём можно выяснить.

В документации не могу найти информацию о размерах типов данных. Примерно понятно, что Int32 занимает 32 бита и т.п., тем не менее, хотелось бы иметь возможность определить или оценить размер документа до вставки в коллекцию. Может кто ссылкой помочь?

Всем привет. Нужен совет и мнение экспертов по монге. У нас дилема. Хранить документы с отсутсвующими полями у которых нет значений, или с пустыми значениями (сервис на Go), типа пустые строки, false, 0 и т.п. Коллегу смущает что при поиске придётся везде передавать запросы типа: field: null, тогда как field: "" более удобен и очевиден. Какой минус в том чтоб хранить поля с такими значениями, кроме не значительного увеличения размера базы?

пустые строки, false, 0 - если не ошибаюсь, просто не запишутся в бд

Ого. При этом будет информация о поле?

поля не будет в монго

Мы сравнили документы, у нас получилась разница в ~400 байтов, но это получается что просто добавилась информация о полях?

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

@Waldes7 вы бы как поступили на нашем месте? Передавали бы пустые значения или вообще не передавали бы поля.

в монго?

Да

со стороны кода хорошо иметь что-то, потому что это, все же, описание какой-то логики: obj.Property = false и тд но стоит помнить что false, null и тд не будут присутствовать уже в монго

В случае Go поле всегда будет false.

в большинстве языков bool по дефолту false

А мы сможем в монге искать отсутствующие bool поля по запросу вида field: false?

А мы сможем в монге искать отсутствующие bool поля по запросу вида field: false?

Привет У меня есть массив тегов, по которому я хочу искать объекты У моего объекта есть филд массив, допустим tags Если этот филд имеет хотя бы один тег из моего массива, по которому я ищу, я хочу вернуть этот документ Я сначала подумал про оператор $or, но не нашел такого в списке операторов для поиска по филду массиву Не подскажите кверю?

Привет всем, подскажите, я могу _id изменить на свое название?

А мы сможем в монге искать отсутствующие bool поля по запросу вида field: false?

Привет У меня есть массив тегов, по которому я хочу искать объекты У моего объекта есть филд массив, допустим tags Если этот филд имеет хотя бы один тег из моего массива, по которому я ищу, я хочу вернуть этот документ Я сначала подумал про оператор $or, но не нашел такого в списке операторов для поиска по филду массиву Не подскажите кверю?

$in оператор

зачем вам пустые поля?

даже если филд, по которому ищу — массив?