Все четенько, на 101 и тестирую

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

По конструкции все окей ? Я уже дня три их перебираю, на 101 все четко, в find - все четко. А в агрегации - первое совпадение только. Хотя влаг g установлен

пример на https://play.db-ai.dev/ соорудите

Всем привет, есть схема продукта, у некоторых товаров есть скидочная цена(priceDiscount), как сделать так,чтобы когда происходило фильтрация, и если у продукта есть скидочная цена, то фильтровал именно по этой цене, а если нет, то по обычной ?

в агрегации?

кажется есть параметр exists

так ?

запусти, и узнаем верно или нет)

Всем привет 🙌🏻 Очень нужна помощь в восстановлении репликасета 🙏🏻 Коротко: 3 ноды, каждая в докер контейнере на разных нодах. 5ТБ данных - Одна давно отвалилась, недавно запустили resync с праймари, сейчас она в Startup2 статусе - Вторая отвалилась пару дней назад. Уходит в постоянных рестарт из-за duplicate key в config.transactions коллекции. За пятницу-субботу не получилось ее восстановить - 3я нода отвалилась сегодня утром. Был oom, после поднятия она ушла в recovery. Судя по логам, recovery прошел, но монга не стартует, последние логи ниже Может кто-то сталкивался с такой ситуацией как с 3й нодой? Можно ли ее как-то завести? Если вдруг у кого-то есть возможность подключиться онлайн, было бы идеально 🙏🏻 {"t":{"$date":"2023-12-10T12:09:22.843+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1702210162:843722][1:0x7fd27e380140], file:sizeStorer.wt, txn-recover: [WT_VERB_RECOVERY_PROGRESS] Recovering log 399667 through 399670"}} {"t":{"$date":"2023-12-10T12:09:22.849+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1702210162:849166][1:0x7fd27e380140], file:sizeStorer.wt, txn-recover: [WT_VERB_RECOVERY_PROGRESS] Recovering log 399668 through 399670"}} {"t":{"$date":"2023-12-10T12:09:22.855+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1702210162:855014][1:0x7fd27e380140], file:sizeStorer.wt, txn-recover: [WT_VERB_RECOVERY_PROGRESS] Recovering log 399669 through 399670"}} {"t":{"$date":"2023-12-10T12:09:22.902+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1702210162:902348][1:0x7fd27e380140], file:sizeStorer.wt, txn-recover: [WT_VERB_RECOVERY_PROGRESS] Recovering log 399670 through 399670"}} {"t":{"$date":"2023-12-10T12:09:22.935+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1702210162:935922][1:0x7fd27e380140], file:sizeStorer.wt, txn-recover: [WT_VERB_RECOVERY | WT_VERB_RECOVERY_PROGRESS] Set global recovery timestamp: (1701980628, 569)"}} {"t":{"$date":"2023-12-10T12:09:22.935+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1702210162:935981][1:0x7fd27e380140], file:sizeStorer.wt, txn-recover: [WT_VERB_RECOVERY | WT_VERB_RECOVERY_PROGRESS] Set global oldest timestamp: (1701980628, 569)"}}

Всем привет 🙌🏻 Очень нужна помощь в восстановлении репликасета 🙏🏻 Коротко: 3 ноды, каждая в докер контейнере на разных нодах. 5ТБ данных - Одна давно отвалилась, недавно запустили resync с праймари, сейчас она в Startup2 статусе - Вторая отвалилась пару дней назад. Уходит в постоянных рестарт из-за duplicate key в config.transactions коллекции. За пятницу-субботу не получилось ее восстановить - 3я нода отвалилась сегодня утром. Был oom, после поднятия она ушла в recovery. Судя по логам, recovery прошел, но монга не стартует, последние логи ниже Может кто-то сталкивался с такой ситуацией как с 3й нодой? Можно ли ее как-то завести? Если вдруг у кого-то есть возможность подключиться онлайн, было бы идеально 🙏🏻 {"t":{"$date":"2023-12-10T12:09:22.843+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1702210162:843722][1:0x7fd27e380140], file:sizeStorer.wt, txn-recover: [WT_VERB_RECOVERY_PROGRESS] Recovering log 399667 through 399670"}} {"t":{"$date":"2023-12-10T12:09:22.849+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1702210162:849166][1:0x7fd27e380140], file:sizeStorer.wt, txn-recover: [WT_VERB_RECOVERY_PROGRESS] Recovering log 399668 through 399670"}} {"t":{"$date":"2023-12-10T12:09:22.855+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1702210162:855014][1:0x7fd27e380140], file:sizeStorer.wt, txn-recover: [WT_VERB_RECOVERY_PROGRESS] Recovering log 399669 through 399670"}} {"t":{"$date":"2023-12-10T12:09:22.902+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1702210162:902348][1:0x7fd27e380140], file:sizeStorer.wt, txn-recover: [WT_VERB_RECOVERY_PROGRESS] Recovering log 399670 through 399670"}} {"t":{"$date":"2023-12-10T12:09:22.935+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1702210162:935922][1:0x7fd27e380140], file:sizeStorer.wt, txn-recover: [WT_VERB_RECOVERY | WT_VERB_RECOVERY_PROGRESS] Set global recovery timestamp: (1701980628, 569)"}} {"t":{"$date":"2023-12-10T12:09:22.935+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1702210162:935981][1:0x7fd27e380140], file:sizeStorer.wt, txn-recover: [WT_VERB_RECOVERY | WT_VERB_RECOVERY_PROGRESS] Set global oldest timestamp: (1701980628, 569)"}}

У меня есть model1 c key1 и model2 с key2. Я хочу найти все models1, у которых key1 равен key2 из model2 и добавить еще простую фильтрацию для model2. Подскажите, это возможно сделать одним запросом? Я только через aggregate думаю

Добрый день. Подскажите, хочу собрать кластер replica set режима из 4 узлов. при инициализации пишет: errmsg command replsetinitiate requires authentication mongo db. Что необходимо сделать, чтобы собрать, указать явно db.auth("username", "password") ?

Всем привет! Не врублюсь, как правильно написать model.aggregate функцию так, чтобы искало по route, а мерджило по id=_id. Помогите 🙂 Collection A { id: ‘my_id’, route: ‘my_route’ } Collection B { _id: ‘my_id’, field1, field2, ..., fieldN }

У меня есть model1 c key1 и model2 с key2. Я хочу найти все models1, у которых key1 равен key2 из model2 и добавить еще простую фильтрацию для model2. Подскажите, это возможно сделать одним запросом? Я только через aggregate думаю

а как пробовали7

включи в настройках монги authentication

Ребят, почему коллекция не загружается ?

так все время

можно поподробнее о ситуации как задеплоина база, какие примерно данные и как по ping до серверу

с другогт браузера зашел, загрузилось)

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

агрегации работают медленнее, если требуется поиск только в 1 коллекции и он укладывается в рамки .find() при условии, конечно, что поиск осуществляется по индексу

Нет, агрегации не работают медленее find.

тестировал на практике, разница в скорости примерно на 70%. при skip до около 300 итераций при skip более 1000-2000 разница сокращается и .find() замедляется, но по прежнему быстрее, примерно на 30% и уже более 10000 когда, существенное время тратится на IOBytes transport latency, тогда время становится одинаковым. количество тестирований 10000 тысяч в 1 круге, среднее время за 20 кругов при разных условиях загрузки ЦП каждые 5 кругов для усреднения времени. а вопрос возник у меня такой, прежде чем проводить эти тесты и удостовериться, что .find() работает быстрее: когда аггрегация возвращает результат после 1 пинка .next(), в то время как find только курсор, который потом ещё нужно пинать постоянно (итерировать) вплоть до StopIteration error - аггрегация должно однозначно работать быстрее, так как транспорт ввода/вывода проводится 1 раз (на самом деле 2, на формирование команды и пинок CommandCursor-a). к тому же, возникала ещё 1 проблема - что драйвер pymongo был спроектирован разными людьми с разными стандартами в голове ответов, видимо... по этому при итерировании через list() StopIteration исключение не вызывается и пришлось придумать дополнительно, как его получать. на счёт второго, исключение очень просто получить: достаточно получить от драйвера курсор, а потом его 1 раз пнуть. если при .find().skip().limit() исключение не получено, то делаем вот так: cursor = connect.get_collection().find().skip().limit() [cursor.next() + list(cursor)] если cursor.next() не возвращает исключение, значит итерирование с помощью list() и последующее сложение списков будет успешным.

тестировал на практике, разница в скорости примерно на 70%. при skip до около 300 итераций при skip более 1000-2000 разница сокращается и .find() замедляется, но по прежнему быстрее, примерно на 30% и уже более 10000 когда, существенное время тратится на IOBytes transport latency, тогда время становится одинаковым. количество тестирований 10000 тысяч в 1 круге, среднее время за 20 кругов при разных условиях загрузки ЦП каждые 5 кругов для усреднения времени. а вопрос возник у меня такой, прежде чем проводить эти тесты и удостовериться, что .find() работает быстрее: когда аггрегация возвращает результат после 1 пинка .next(), в то время как find только курсор, который потом ещё нужно пинать постоянно (итерировать) вплоть до StopIteration error - аггрегация должно однозначно работать быстрее, так как транспорт ввода/вывода проводится 1 раз (на самом деле 2, на формирование команды и пинок CommandCursor-a). к тому же, возникала ещё 1 проблема - что драйвер pymongo был спроектирован разными людьми с разными стандартами в голове ответов, видимо... по этому при итерировании через list() StopIteration исключение не вызывается и пришлось придумать дополнительно, как его получать. на счёт второго, исключение очень просто получить: достаточно получить от драйвера курсор, а потом его 1 раз пнуть. если при .find().skip().limit() исключение не получено, то делаем вот так: cursor = connect.get_collection().find().skip().limit() [cursor.next() + list(cursor)] если cursor.next() не возвращает исключение, значит итерирование с помощью list() и последующее сложение списков будет успешным.

Подскажите, можно ли получить функционал Транзакций при одной ноде Монги без replica set?

Режим репликасет не обязательно требует наличия больше одной ноды. Так что да можно

Тогда вопрос. Использовал Docker для запуска Реплики в виде 1-ой ноды, но после перезапуска базы пропадали, хотя volumes примонтирован с базой, а так же нельзя было приконектиться, писало что не primary инстанс. Можете поделиться верным конфигом запуска через Docker???

https://www.mongodb.com/compatibility/deploying-a-mongodb-cluster-with-docker все тоже что и описано, только для одного инстанса

эм, пункт 2 инструкции гласит "Start three instances of MongoDB."

Существуют ли имеджи контейнеров mongos?

Если про роутер, mongos, он есть внутри контейнера с монгой

А спасибо

Хорошая работа по тестированию драйвера для питона, сходите ишью напишите, может доработают

Вообще не факт :), я постоянно использую pymongo и aiomotor - не очень понял принцип тестирования.

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

сортировку добавить

Только удобней из docker-compose и в command указать mongos, конфиг для него если надо, через внешний volume

Это больше вопрос к докерам и Линукс но возможно вы решали похожую проблему

а в чем проблема?

Ну хочу сказать контейнеру что пользователь монго должен иметь другие параметры uid и gid когда записывает данные в деректорию

Ну хочу сказать контейнеру что пользователь монго должен иметь другие параметры uid и gid когда записывает данные в деректорию

а зачем

У нас почти все опирационные системы имеют фиксированные uid и gid у определённых стандартных пользователей установки( postgres -125 mongo -115 ) и становится запарным при переносе через nfs изменять постоянно имена пользователей обратно к стандарту

Только сделать свой Dockerfile с и установить свой uid/guid, так как 999 захардкожено: https://github.com/docker-library/mongo/blob/5aa0c74848845f365789290d494a047f4db16426/7.0/Dockerfile#L11 Либо у себя сменить на 999

Привет. Что можно почитать про оптимизацию чтения из монги. Пишет быстро, с чтением начинает есть ресурсы.

какие ресурсы? память?

Стоит основной сервер и несколько реплик ЦП грузит такого типа запрос. Коллекция под несколько кк записей. Событий на удаление и добавление 1-2к rps.