последний элемент можно взять через использование отрицательного индекса

-1 == последний элемент

либо вам необходимо отказаться от _id, либо использовать https://docs.mongodb.com/manual/tutorial/update-documents-with-aggregation-pipeline/ и вручную проверять есть ли такой элемент в массиве и добавлять по необходимости

^

используйте update pipeline

но из history я должен брать по ид

по какому из двух?

con_id

если вам поле _id (не con_id) не нужно, то в этом случае найдите откуда оно у вас возникает и отключите это поведение

в этом случае $addToSet будет работать

либо как я выше писал, напишите ручную проверку используя update pipeline

_id эту надо отключить ?

да

как могу отключить ?

они у вас разные, по этому $addToSet добавляет новый элемент массива

здесь я помочь не смогу, скорее всего это ваш драйвер/odm добавляет

возможно на уровне вашего odm есть возможность правильно задать embedded realtions со свойством уникальности

сделал так когда из массива чтота меняю дубликат идёт если не меняю то дубликат не идёт

con_id удалил

Лично я делаю не через апдейт. Я приравниваю к переменной какой-то найденную через findOne часть, меняю нужный элемент в той переменной и сохраняю её в базу

const referDB = await User.findOne({ID: refer}).exec() referDB.refNum = referDB.refNum + 1 referDB.save()

const user = await User.findOne({ID: msg.chat.id}).exec() .then( () => {bot.sendMessage(msg.chat.id, "+++")} ) .catch( (err) => {console.log(err)}) bot.sendMessage(msg.chat.id, user.name)

Здравствуйте, такая проблема, +++ он выводит, но на user.name даёт ошибку: 2021-03-14T10:47:59.867231+00:00 app[worker.1]: (node:4) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'name' of undefined На моём компе если сервер загружаю всё ок, на heroku ошибка

updateOne может возвращать данные, которые были записаны?

Всем привет! В MongoDB записали ip адреса в формата: xxx.xx.xx.x Построили по этому полу индекс: db.users.createIndex({ip_address: ‘’text’’}). Пробуем искать по этому полю: coll.find({"$text": {"$search": f'"{ip}"'}}, {"_id": 0}) - и время поиска очень большое, то есть индексы не работают, почему?

Всем привет. Из GridFS удаляю файлы. Нужно место на диске освободить. Но оно не освобождается. Вызов compact не помогает. Версия 3.6. Есть мысли почему? В доке написано что после compact должно место освободиться.

Всем привет! В MongoDB записали ip адреса в формата: xxx.xx.xx.x Построили по этому полу индекс: db.users.createIndex({ip_address: ‘’text’’}). Пробуем искать по этому полю: coll.find({"$text": {"$search": f'"{ip}"'}}, {"_id": 0}) - и время поиска очень большое, то есть индексы не работают, почему?

Неправильно

Если у вас ipv4 - пишите int-ами

И с местом чуть сэкономите

И поиск прозрачней

И индекс по целом

Или пишите и строкой и целым представлением. Индекс по целому

По целому ищите а выдавайте строкой

И под подсетям (маскам) проще искать тогда и вообще лучше на мой взгляд

Неправильно

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

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

:) спросите админа yopp. я так понимаю, текстовый индекс тут не так работает(вообще не работает). Для сравнения, постройте просто индекс по полю, будет искать быстрее, но тогда неудобно искать по маскам сетей.

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

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

похоже? https://docs.mongodb.com/manual/reference/method/cursor.hint/#cursor.hint

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

просто индекс по ключу...но смысла в вашем случае по при ipv4 - нет. Простой индекс по целому ip - решит многие вопросы

я в одном проекте видел, как человек складывал ip строками, а поиск по подсетям решал через формирование в коде списка из строк из этой подсети, и потом искал по монге через in....с целыми же у вас 3 варианта, непосредственно поиск по значению, или по подсетем через gte, lte

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

(поиск по подсетям не нужен, ip адреса ищутся буквально)

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

опять же нет, тогда вам необходимо в коде, чекать - ipv4(ipv6) или другое - иное в поле "host"

и чекать не через regex, а через ipaddress(python3) def check_ip(ip_str: str) -> bool: """ Проверка строки на ip адрес :param ip_str: :return: """ try: ip_address(ip_str) return True except BaseException: return False

примерно наверно так чекать

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

"в качестве быстрого решения попробую на поле ip_address навесить обычный индекс" - будет быстрее.

"в качестве быстрого решения попробую на поле ip_address навесить обычный индекс" - будет быстрее.

👍

Всем привет! В MongoDB записали ip адреса в формата: xxx.xx.xx.x Построили по этому полу индекс: db.users.createIndex({ip_address: ‘’text’’}). Пробуем искать по этому полю: coll.find({"$text": {"$search": f'"{ip}"'}}, {"_id": 0}) - и время поиска очень большое, то есть индексы не работают, почему?

Для прямых совпадений необходим обычный индекс. Текстовый индекс применяется для поиска с учетом морфологии

Всем привет. Из GridFS удаляю файлы. Нужно место на диске освободить. Но оно не освобождается. Вызов compact не помогает. Версия 3.6. Есть мысли почему? В доке написано что после compact должно место освободиться.

А какой у вас storage engine используется?

А какой у вас storage engine используется?

WiredTiger.

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

Он работает, но все знает пунктуации в текстовом индексе рассматриваются как разделители. В вашем случае адрес интерпретируется как 4 поисковых токена. Тоже самое с содержимым индекса.

WiredTiger.

А в stats, в wiredTiger.block manager какие значения?

Вы вызываете compact на коллекции с чанками ?

Он работает, но все знает пунктуации в текстовом индексе рассматриваются как разделители. В вашем случае адрес интерпретируется как 4 поисковых токена. Тоже самое с содержимым индекса.

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

Не использовать text индекс

У него другая задача: поиск по содержимому текстов с учетом морфологии. Ваша задача это сравнение строк

Возможно в самом начале (когда я записывал данные в mongo) нужно было заменять точки на другой символ? В БД также записаны доменные имена, по которым мне абсолютно точно нужен полнотекстовый поиск, как быть с точками в таком случае?

Возможно в самом начале (когда я записывал данные в mongo) нужно было заменять точки на другой символ? В БД также записаны доменные имена, по которым мне абсолютно точно нужен полнотекстовый поиск, как быть с точками в таком случае?

С большой долей вероятности он вам точно не нужен :)

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

Его придумали как поиск именно по текстам. Для других целей он абсолютно не подходит из-за своей внутренней реализации

С большой долей вероятности он вам точно не нужен :)

Хорошо, допустим в mongo записаны домены: google.ru google.com. Мне нужно найти все домены содержащие google. Как осуществить поиск такого рода без полнотекстового индекса?

Поиск по префиксу

/\Agoogle/

Этот тип поиска требует построение какого индекса по полю с доменами ?

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

Этот тип поиска требует построение какого индекса по полю с доменами ?

обычный индекс

Понял, значит мы стреляли из пушки по комарам, верно?

Понял, значит мы стреляли из пушки по комарам, верно?

просто тот кто писал в монгу, не обладал достаточным опытом

Понял, значит мы стреляли из пушки по комарам, верно?

Скорее старым мушкетом :)

Поиск по префиксу

а что если в поле с доменами встречается такое: "0.145.227.35.bc.googleusercontent.com’’ - тут поиск с префексом справится?

а что если в поле с доменами встречается такое: "0.145.227.35.bc.googleusercontent.com’’ - тут поиск с префексом справится?

Если искать вхождение google, то нет. И текстовый индекс тоже, там нет поиска по префиксам

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

Скорее старым мушкетом :)

Возможно можно утверждать что если у вас много текстовых сообщений и вы хотите искать среди них подстроки, то используйте elasticsearch но не mongo?

Возможно можно утверждать что если у вас много текстовых сообщений и вы хотите искать среди них подстроки, то используйте elasticsearch но не mongo?

странные вы вопросы задаете

странные вы вопросы задаете

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

Возможно можно утверждать что если у вас много текстовых сообщений и вы хотите искать среди них подстроки, то используйте elasticsearch но не mongo?

В целом да, в монге инструментов для сложного поиска по содержимому строк нет

Текстовый индекс это скорее про «быстро сделать хоть какой-то поиск который ищет по словам»

Если задача сложнее чем запросы по целым словам с not/or/and, то не подходит

Ключевое слово тут «целое слово» :)