Это будут последние строчки в файле. У вас же не работает процесс mongodb, следовательно лог не пополняется.

Всем привет! Подскажите, какую структуру ФИО сделать, когда у меня может быть несколько вариантов фамилии, имён и отчеств. Сейчас так: [{ фам.: "Иванов", имя: ["Василий", "Васелий"] }, { фам.: ["Петров", "Питров"], имя.: ["Георгий", "Жора"] }] В принципе сама структура меня устраивает, но проблема возникает, когда я делаю составные индексы. Из-за массивов они не делаются

А в чём ваша цель?

Не искать по возможным вариантам а самые ближайшие возможные по ключу

Эммм, у вас слишком много перечеслений может быть в одну коллекцию. Потому что у вас очень много возможных изменений за время может произойти. Может обратить внимание на способ поиска чем на изменение базы? Там n-грамный анализ, метод расстояние Левенштейна

Тут 2 варианта, но в зависимости от задач их число растёт. Принцип как в подборе подходящего слова при ошибке(Т9)

По последнему предложению сможете найти минимум 4 (не считая ранжирования)

Посмотрел про эти методы. Пропишу, что понял, вдруг не понял) 1. структуру базы не меняем 2. в коде используем метод n-грамный анализ или расстояние Левенштейна 3. поиск будет возвращать похожие результаты (что для меня очень хорошо) 4. Такой подход должен ускорить запросы. Сейчас у меня в базе 24 млн документов.

Имеется два одинаковых по железу сервера. БД лежат на XFS. Я думал можно остановить mongodb, скопировать все файлы с одного сервака на другой и там безболезненно поднять. Но походу это не работает - mongo не поднимается. Это я криворукий или действительно так нельзя? Если второе, то как можно? mongodump/restore очень долго перестраивает индексы. 😔

Добрый день, подскажите https://www.geeksforgeeks.org/how-to-perform-query-optimization-in-mongodb/#:~:text=Use%20%24in%20and%20%24nin%20Carefully%3A%20These%20operators%20can%20be%20slow%20for%20large%20arrays.%20Instead%2C%20use%20multiple%20%24or%20conditions%20if%20possible Вот тут написано, что следует избегать оператора $in если в массиве много элементов, и заменить его на $or. А о каком колличестве идет речь? Например 100 это много или мало? Или как в моем случае 600 - это еще сносно или стоит переписывать?

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

Добрый день, подскажите https://www.geeksforgeeks.org/how-to-perform-query-optimization-in-mongodb/#:~:text=Use%20%24in%20and%20%24nin%20Carefully%3A%20These%20operators%20can%20be%20slow%20for%20large%20arrays.%20Instead%2C%20use%20multiple%20%24or%20conditions%20if%20possible Вот тут написано, что следует избегать оператора $in если в массиве много элементов, и заменить его на $or. А о каком колличестве идет речь? Например 100 это много или мало? Или как в моем случае 600 - это еще сносно или стоит переписывать?

У меня есть запросы в которых в $in по несколько тысяч айдишников. Мы не пробовали делать иначе, но проблем с производительностью такого решения не замечаем. Как будто всё работает без проблем.

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

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

Просто может быть вам повезло и у вас мощное железо:)

Возможно. Это всё, что я могу тут сказать. Мы просто не задумывались, что тут может быть какая-то проблема.

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

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

Ненавижу роботов. В основном за то, что они умнее, быстрее и сильнее меня. Но и тут примерно тот же ответ. Только не говорите мне, что реально придётся костылить...

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

Нужно городить инфраструктуру для постоянного обновления образа, его развертывания и публикации для гарантии предоставления максимально свежих утилит стабильных версий... Что-то не то. Я привык на чужом горбу в опен-сурсе выезжать и истерить в issue, как и 99.9% участников GitHub...

Нужно городить инфраструктуру для постоянного обновления образа, его развертывания и публикации для гарантии предоставления максимально свежих утилит стабильных версий... Что-то не то. Я привык на чужом горбу в опен-сурсе выезжать и истерить в issue, как и 99.9% участников GitHub...

что там в тулах надо нового? они и старые работают замечательно

Они не существуют в вакууме, к сожалению. СУБД MongoDB постоянно обновляется (в облаке Atlas, где я хостюсь нахаляву - люблю бесплатновое), мне постоянно приходится обновлять бекенд, чтобы угнаться за обновлениями каждые полгода. Уверен, тулзы в какой-то момент устареют настолько, что не переварят новую версию Монги. Поэтому прошу именно чего-то такого, что всегда будет устанавливать свежак - выбора нет, экосистема диктует правила. А вообще, Монго - редиски, могли бы и подсобить с автоматизированной установкой...

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

Эх. То ли я пакет не тот к Nest прикрутил, то ли сам Nest как-то жёстко чекает версию Монги... В общем, наелся, три раза обновлял его за два года. За это время монга скакнула с 6 до 8 версии, и каждый раз при очередной мажорке начинался секс, причём я всегда был снизу

Эх. Сдаюсь. Решил было сделать бекап на основе mongodump/mongorestore. А что? База 14 мегов занимает. Для этого мне нужен способ воспроизводимой установки mongodb-database-tools на Ubuntu. В macOS есть такая штука: brew install mongodb-database-tools А в Linux её нет. Надо качать tatar'ы с уникальными именами, а как их узнавать программно - загадка. Парсить HTML ради этого или городить иные подобные костыли я не готов. Потом ещё и бинарники оттуда вилкой выковыривать и в /usr/share/bin/ пихать. Ну, ладно, Ansible всё стерпит. Так что вопрос всё ещё актуален. Каким образом вы получаете гарантированно свежие mongodb-database-tools на свой Linux хост воспроизводимым автоматизированным неинтерактивным и желательно девственным способом?

Всем привет! mongodump'нул БД. Создал контейнер с новым, совершенно пустым экземпляром Монги: services: mongodb: image: mongo container_name: test_mongodb environment: - PUID=1000 - PGID=1000 volumes: - ./database:/data/db ports: - 27020:27017 restart: unless-stopped Запускаю mongorestore командой: mongorestore --uri="mongodb://localhost:27020/?authSource=admin" .\path\to\backup Но он не понял, как. Так и написал. И я не понял, как. Тоже написал сюда. Вот логи: 2025-02-03T00:08:05.914+0500 preparing collections to restore from 2025-02-03T00:08:05.935+0500 don't know what to do with file "path\to\backup\mydatabase\contracts.bson", skipping... 2025-02-03T00:08:05.935+0500 don't know what to do with file "path\to\backup\mydatabase\contracts.metadata.json", skipping... 2025-02-03T00:08:05.935+0500 don't know what to do with file "path\to\backup\mydatabase\creatives.bson", skipping... 2025-02-03T00:08:05.935+0500 don't know what to do with file "path\to\backup\mydatabase\creatives.metadata.json", skipping... 2025-02-03T00:08:05.936+0500 don't know what to do with file "path\to\backup\mydatabase\invoices.bson", skipping... 2025-02-03T00:08:05.936+0500 don't know what to do with file "path\to\backup\mydatabase\invoices.metadata.json", skipping... 2025-02-03T00:08:05.936+0500 don't know what to do with file "path\to\backup\mydatabase\medias.bson", skipping... 2025-02-03T00:08:05.936+0500 don't know what to do with file "path\to\backup\mydatabase\medias.metadata.json", skipping... 2025-02-03T00:08:05.936+0500 don't know what to do with file "path\to\backup\mydatabase\persons.bson", skipping... 2025-02-03T00:08:05.936+0500 don't know what to do with file "path\to\backup\mydatabase\persons.metadata.json", skipping... 2025-02-03T00:08:05.936+0500 don't know what to do with file "path\to\backup\mydatabase\user-frontend-configs.bson", skipping... 2025-02-03T00:08:05.936+0500 don't know what to do with file "path\to\backup\mydatabase\user-frontend-configs.metadata.json", skipping... 2025-02-03T00:08:05.936+0500 0 document(s) restored successfully. 0 document(s) failed to restore.

https://www.mongodb.com/community/forums/t/mongorestore-error-dont-know-what-to-do-with-file-bjson-and-json/147404/2 ?

Прочитал. Это не помогло. Я про флаг -d. А вот создание папки с любым именем и засовывание туда всего бекапа помогло. Правда, возникает вопрос - а почему тогда такой важный параметр, как имя базы, определяется именем какого-то там папки? Впрочем, бекапы работают, я в этом убедился.

Всем привет. Есть довольно наверное типичная задача. Пользователь загружает ексель файл, и на каждую строку нужно создать сущность в бд. Такж ще еще 1 сущность общую. И по 1 сущности на каждую 1000 строк. Но файл может быть например 100к строк. Итого 101001 сущность. И мне это нужно в транзакции, потому что если хоть одно что то я не могу сохранить, то все остальные данные нельзя сохранять. Во первых сейчас транзакция занимает 25 сек, при лимите а 30. Ну это еще поднять можно. Но у коллеги локально упало и сказало, что мало памяти. Да и вообще читал, что транакции больше 1к не рекоммендуется делать. Как тогда? Очереди? Или флажки какие то?

Всем привет. Есть довольно наверное типичная задача. Пользователь загружает ексель файл, и на каждую строку нужно создать сущность в бд. Такж ще еще 1 сущность общую. И по 1 сущности на каждую 1000 строк. Но файл может быть например 100к строк. Итого 101001 сущность. И мне это нужно в транзакции, потому что если хоть одно что то я не могу сохранить, то все остальные данные нельзя сохранять. Во первых сейчас транзакция занимает 25 сек, при лимите а 30. Ну это еще поднять можно. Но у коллеги локально упало и сказало, что мало памяти. Да и вообще читал, что транакции больше 1к не рекоммендуется делать. Как тогда? Очереди? Или флажки какие то?

Ну была бы не папка, а огромный файл который хранит все пути к коллекциям и мета инфе + название бд Так это та же самая папка только оверинженерная

Что упало по памяти?

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

Если явно не стмртанули транзакцию то и коммит делать не надо

Привет, монга жрет 24 гига оперативки на сервере Идет активная запись и чтение в коллекции на скрине. Как видно коллекции большие. 24 гига для работы с такими коллекциями это вообще норм или где-то есть проблемы?

Добрый день, пытаюсь подключится к WSL к локально установленной монге, но выдает ECONNREFUSED 127.0.0.1:27017, в Компасе же по mongodb://127.0.0.1:27017 корректно подключается

То это объем данных для хранения индексации

Кстати интересно, что он очень похож на RAM по объему 🤔

Привет, монга жрет 24 гига оперативки на сервере Идет активная запись и чтение в коллекции на скрине. Как видно коллекции большие. 24 гига для работы с такими коллекциями это вообще норм или где-то есть проблемы?

у монги же вроде Memory mapped files ? типа будет показывать оперативку, равную размеру базы. или уже изменилась ситуация?

у монги же вроде Memory mapped files ? типа будет показывать оперативку, равную размеру базы. или уже изменилась ситуация?

В монге mm уже тыщу лет не используется, все через wiredrtiger

Привет, монга жрет 24 гига оперативки на сервере Идет активная запись и чтение в коллекции на скрине. Как видно коллекции большие. 24 гига для работы с такими коллекциями это вообще норм или где-то есть проблемы?

ну это если монгу вовремя обновлять

Ну в 2025 сидеть на 3 версии такое себе)