Во вторых, что вот этот консоль выводит? console.log(product1Arrays[3]);

Т.к. возможно у тебя в будущем будет миллион продуктов

А как лучше сделать?

$project

А можно пример пожалуйста?

Пример №1: find().projection({ path: 1 }) либо find().project({ path: 1 }) Пример №2: find({}, { path: 1 }) Документация: 1. https://www.mongodb.com/docs/manual/tutorial/project-fields-from-query-results/ 2. https://www.mongodb.com/docs/manual/reference/operator/aggregation/project/

Пример №1: find().projection({ path: 1 }) либо find().project({ path: 1 }) Пример №2: find({}, { path: 1 }) Документация: 1. https://www.mongodb.com/docs/manual/tutorial/project-fields-from-query-results/ 2. https://www.mongodb.com/docs/manual/reference/operator/aggregation/project/

А он сможет возвращать по type если нашел совпадения product1: [{"id":"1bf27371-138a-4a5d-8233-08b386495a0a","name":"Молоко","sum":30,"type":"milk","typ":"buy","kol":1}]

А он сможет возвращать по type если нашел совпадения product1: [{"id":"1bf27371-138a-4a5d-8233-08b386495a0a","name":"Молоко","sum":30,"type":"milk","typ":"buy","kol":1}]

Если вам нужны только документы, где type === milk, то find({type: milk})

Возвращает пустой массив, ходя в базе оно есть

Можете показать полный документ?

Можете показать полный документ?

Вопрос про индексацию, например, документы сейчас имеют такой вид: {x: 'a', y: 'b', z:'c'} где, a,b,c - это по сути, split строки, a-b-c. Однако, регулярно, приходят строки со значениями(и это нормально), где префикса a - нет, то есть строки вида b-c. Тогда документы сохраняются в виде, {'y:' 'b', 'z':'c'}. Так как поиск предусматривается и по полной форме {x: 'a', 'y:' 'b', 'z':'c'}, и по частичной. { 'y:' 'b', 'z':'c'}. То построен индекс {y:1, z:1, x:1}, такой порядок, ввиду того, что y более уникален, чем z. Так вот, так как индекс сразу по 3 полям, то в поиске(агрегации), когда ищут данные по b-c (то есть на вход дают только значения для y,z), я использую для поля x такое добавление в match: '$or': [{'x': {'$exists': false}}, {'x': {'$exists': true}}] И вот думаю, если для случаев когда приходит документ без префикса, в короткой форме, может быть всё таки лучше сохранять документ в "полной" форме, а в значение этого "префикса" назначать, на пример, -1 - (такого точно не может прийти во входных данных). То есть документы примут вид для таких случаев: {x: -1, y: 'b', z:'c'}. И вот вопрос, у меня получится что в поле может быть как "целое" -1, так и строка, при полной форме входной строки. Или всё такие сохранять в x -1 как строку? И при поиска. когда на вход подадут только y и z в match будет такое: '$or': [{'x': -1}, {'x': {'$ne':-1}}] И вопросы такие Будет ли такое эффективней чем exists, Нормально ли смешивать два типа, в одних документах целое, в других строка, в контексте построения индекса. По размеру документа, для целого монга сразу будет занимать сколько то байт, а для строки, будет увеличиваться документ на 2 сколько байт, если будет только '-1'. Потому как такое изменение повлечет и увеличение документов, и увеличение индекса. Документов, 40 млрд, и на таком количестве разница в байтах, будет видна.

не очень понятно зачем надо добавлять условия вида '$or': [{'x': {'$exists': false}}, {'x': {'$exists': true}}] т.к. они всегда истинны и имеют смысл разве что для полей посреди составного индекса, чтобы попытаться триггернуть covered выборку. Будет ли эффективнее замена экзист - да, т.к. надо монга дополнительно читает документ с диска чтобы проверить этот факт если это не sparse индекс (https://www.mongodb.com/docs/manual/reference/operator/query/exists/#use-a-sparse-index-to-improve--exists-performance) По размеру числа почти всегда дадут меньший размер индекса по сравнению со строками и соответственно снизят требования к памяти и как следствие нагрузку на систему изза объемов гоняемых данных между диском и оперативой. Однако в вашем случае где есть всегда выборка по y+z и иногда к ним добавляется еще x, мне например видится вариант строки вида "y-z:x" которая покрывает все указанные выборки (дефис и двоеточие тут символы разделители). Возможнос такой индекс даст больший импакт чем суррогат из трех интовых полей

Строка из значений полей

строка из значений, значения всегда вида a-b-c (поля x, y, z), и это всегда строки, но, бывают, что нет a, и приходит строка b-c. Так удобней индекс строить по 3 полям, составной, но в документе, когда a не приходит, соответственнно нет поля x. Но оно участвует в индексе, потому его решил указывают, при поиске.

Если я правильно помню, то хватит записывать null как значение и явно в запросе указывать a: null. Монга может индексировать поля с разными типами, проблем с этим не будет :)

Еще из вариантов, если нет сортировок и вы не делаете выборок по префиксу, то положить a в суффикс индекса, раз это опциональное поле

так и делаю, самое последнее поле со значением а в индексе. Про "поля с разными типами, проблем с этим не будет :)" - тут скорее от меня еще скрытый подвопрос :) что больше будет занимать место, замена отсутствующего поля на что-типа '~' - строкой, или -1 - которое будет как int32 - то есть + 4 байта?

Если хотите covered queries в этом случае действительно лучше поле со специальным значением. Меньше всего по спецификации занимают $minKey/$maxKey, они как и null «immediate values», без аргументов,: т.е 0 байт оверхеда https://bsonspec.org/spec.html Ну и такие значения точно пересекаться не будут с другими и при сортировке точно будут или в конце или в начале :)

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

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

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

Помню кто-то спрашивал про таймеры в монге... А есть только таймеры, или можно задавать какие-то свои правила. Например, у меня есть тудуха, и я хочу при выполнении задачи на сайте или в приложении автоматически перемещать задачу из тудухи в выполненное...

можно использовать встроенный интерпретатор javascript и создать нужную функцию

Я имею ввиду другое. В монге есть что-то, что бы чекало при каждом запросе выполнена задача или нет?

Ээ, за шо удалили эпилепсию? 😁

не бан и то хорошо)

Всем привет! Есть ли в монго treshold чтобы база не переполнилась на 100%, чтобы при 95% заполнение он перешел на режим read-only

добрый день! наблюдаем по нашим оценкам весьма долгий фетч. база около 1.4 млрд документов. средний размер документа около 300кб . запрос отдает около 1 млн результатов. выполняется на nvme - 1 мин 50 сек, из оперативки - 1 мин 10 сек. при этом свыше 90% времени - фетч. это адекватное время для монги или же нет? если нет то в чём может быть проблема?

как замеряете? и все с одной ноды выбирается или из шардированного кластера?

добрый день! наблюдаем по нашим оценкам весьма долгий фетч. база около 1.4 млрд документов. средний размер документа около 300кб . запрос отдает около 1 млн результатов. выполняется на nvme - 1 мин 50 сек, из оперативки - 1 мин 10 сек. при этом свыше 90% времени - фетч. это адекватное время для монги или же нет? если нет то в чём может быть проблема?

если средний размер действительно 300кб, то 1 млн доков - это 300 Гб, за 2 минуты это достаточно быстро

прошу прощения, ошибся. 300 байт конечно

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

большое спасибо за ответы! уже натолкнули на некоторые мысли, надо их проверить)

вообще не нормально тянуть 1кк доков из бд, поэтому даже хз нормальное ли это время

Ну почему, выгрузка данных в другие «системы»

вообще не нормально тянуть 1кк доков из бд, поэтому даже хз нормальное ли это время

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

Я пришёл к выводу, что я сам себе дал нереальные ограничения для теста Нужно понимать, что в реальном юзкейсе 1000 человек одномоментно не постучится на роут, а даже если такой волшебный кейс случится, то это не постоянная нагрузка, и такую ситуацию, пусть и с задержкой, сервер разрулит Тем более в продашкне будет развёрнуто несколько копий ноды + nginx в качестве балансировщика, и у каждой копии будет свой коннекшн к бд Я бы не советовал сильно увеличивать пулсайз, умные ребята из других чатов сказали, что так лучше не делать и может быть плохо) Если один конкретный маршрут делает тяжелые запросы, можешь реализовать несколько коннекшнов и на конкретные тяжелые запросы использовать отдельный коннекшн, чтобы лёгкие запросы не вставали в очередь за тяжёлыми

Всем привет, уже мучаюсь 2 часа и не могу реализовать следующую логику: Хочу чтобы в mongoDb добавлялась запись и через 15 секунд удалялась, добавляю следующие индексы "expireAt": 1 и expireAfterSeconds: 0 , далее указываю дату в формате mongo с типом Date, где указываю точное время после которого должна удаляться запись, а она не удаляется, кто-нибудь реализовывал подобное ? Буду очень признателен за ответ

а через пару минут удаляется?

нет, я просто не знаю, что делаю не так именно

какого типа поле?

Date

тогда остается таймзона

просто надо сверить какое на серваке и в поле с учетом перевода в utc. Для эксперимента можешь добавить док у которого время текущее плюс 3 часа и посмотреть удалится или нет

Привет, всем!! Может кто подсказать? Вопрос на скрине

https://www.mongodb.com/docs/manual/reference/operator/aggregation/regexMatch/

Всем привет, подскажите пожалуйста как выставить дату и время в котором должна работать БД ?