Проверьте логин, пароль, строку коннекта, если в пароле есть @ то его надо urlencode

If the username or password includes the at sign @, colon :, slash /, or the percent sign % characters, use percent encoding.

пароль = password

Попробуйте другой authMechanism, в какой-то 4.х по дефолту SCRAM-SHA-256 стали делать https://docs.mongodb.com/manual/reference/connection-string

похоже что https://github.com/docker-library/mongo/blob/master/4.2/docker-entrypoint.sh не создает пользователя указанного в MONGO_INITDB_ROOT_USERNAME, MONGO_INITDB_ROOT_PASSWORD самостоятельно, нужно видимо подложить ему js файл с db.createUser

Ребят, нужен совет. Есть схема, что-то типа [ { "name": "Ivan", "payments": [{"date": new Date("2019-01-01"), "details": [{"payment_system": "A", "spent": 95}, {"payment_system": "B", "spent": 123}]}, {"date": new Date("2019-01-03"), "details": [{"payment_system": "A", "spent": 123}, {"payment_system": "B", "spent": 11}]}]}, { "name": "Mark", "payments": [{"date": new Date("2019-01-01"), "details": [{"payment_system": "D", "spent": 456}, {"payment_system": "B", "spent": 123}]}, {"date": new Date("2019-01-02"), "details": [{"payment_system": "A", "spent": 123}, {"payment_system": "C", "spent": 4}]}]} ] Нужно найти всех пользователей, которые потратили, например, в системах C и A больше 100 за промежуток времени, и обновить им поле, например filter_1: true. Это реализуемо при текущей схеме в MongoDB? Пользователей достаточно много, пару миллионов.

Если условме С + А > 100, то будет дорого. Если условие в система С > 100 и в системе А > 100, то compound индекс по {date, details.payment_system, details.spent}

Здравствуйте, такой вопрос, есть таблица логов просмтров постов, доросла уже до 50млн записей, основные данные которые из нее достаются - это данные в рендже (начало года - текущее время). Стоит ли за архивировать таблицу и в текущей оставить только актуальные данные?

Здравствуйте, такой вопрос, есть таблица логов просмтров постов, доросла уже до 50млн записей, основные данные которые из нее достаются - это данные в рендже (начало года - текущее время). Стоит ли за архивировать таблицу и в текущей оставить только актуальные данные?

а что вас не устраивает сейчас?

Ищу ментора по MongoDB, не могу сам разобратся...

а что вас не устраивает сейчас?

Не будут ли запросы в эту таблицу в работать медленее от того что там 50млн записей?

Не будут ли запросы в эту таблицу в работать медленее от того что там 50млн записей?

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

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

Спасибо

вообще не понятно что там у вас

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

можно их в нем же и хранить

если это неудобно, то можно отдельно

если Максим не имеет ввиду сущности "товар" и хранить настройки в каждом из них. это смертеподобно

ну вдруг товаров 200 и у каждого свои настройки

вполне себе тема

если так то да, тема

ниче не ясно из проблемы)

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

а на самом деле все то же самое - разложил все аккуратно и храниш

как бы и да и нет, дата моделинг лучше все же заново изучить)

а так хранилка как хранилка

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

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

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

ну уж точно не пишу вопросы в телеграм :)

Ребят как лучше сделать в монго Есть таблица например с названием и еще какими-то параметрами Ну и массив строк этой таблицы { name, params, rows:[{},{}...] } Вопрос в том в массиве лучше хранить сами объекты строк или ток ссылку на строку в другой коллекции?

Хранение 1 ко многим или многие ко многим?

сколько строк всего этих?

сколько строк всего этих?

Строк много

Хранение 1 ко многим или многие ко многим?

1 таблица много строк

Хранение 1 ко многим или многие ко многим?

Ну конкретную строку ссылка ток в одной таблице

Строк много

много - понятие субъективное, в том числе монга это тоже по-своему понимает

так что нужны цыфры

в частности, есть ограничение на размер документа

т.е. массив из миллиарда строк не впихнешь в документ

тогда точно отдельная таблица

Ну ладно допустим на 1 таблицу 200+- строк Ну и таблиц 200 и будет становиться больше

а если из сто штук то уже можно думать удобно это вам или нет

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

Ну у меня вопрос как лучше удобнее Может оптимизированее сделать

200+- рекомендовал бы хранить embedded, если не планируется использовать сущность "строка" отдельно от аггрегата

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

Всем, привет! Есть вот такой набор данных. [ { "a": 1, "arr": [{b: 1, c: 100}, {b: 2, c: 200}, {b: 3, c: 300}], }, { "a": 2, "arr": [{b: 2, c: 100}, {b: 3, c: 100}, {b: 4, c: 200}], }, { "a": 3, "arr": [{b: 3, c: 150}, {b: 4, c: 250}, {b: 1, c: 500}], }, { "a": 4, "arr": [{b: 2, c: 100}, {b: 5, c: 200}, {b: 1, c: 300}], }, ] Подскажите, как выбрать все документы, которые в arr имеют b = 2 и с < 150, но такие, чтобы не было b = 5 Или такую фильтрацию уже нужно на стороне ЯП делать?

Всем, привет! Есть вот такой набор данных. [ { "a": 1, "arr": [{b: 1, c: 100}, {b: 2, c: 200}, {b: 3, c: 300}], }, { "a": 2, "arr": [{b: 2, c: 100}, {b: 3, c: 100}, {b: 4, c: 200}], }, { "a": 3, "arr": [{b: 3, c: 150}, {b: 4, c: 250}, {b: 1, c: 500}], }, { "a": 4, "arr": [{b: 2, c: 100}, {b: 5, c: 200}, {b: 1, c: 300}], }, ] Подскажите, как выбрать все документы, которые в arr имеют b = 2 и с < 150, но такие, чтобы не было b = 5 Или такую фильтрацию уже нужно на стороне ЯП делать?

смотри elemMatch

Спасибо 👍 буду думать

смотри elemMatch

с помощью elemMatch я могу выбрать по первому условию... но вот исключить b = 5 не получается

Такой вариант выбирает как надо, но я не понимаю как исключить те элементы, которые содержат {b: 5} find( { "arr": { $elemMatch: { b: { $eq: 2 }, c: { $lt: 150 } } } } )

$ne?

Такой вариант выбирает как надо, но я не понимаю как исключить те элементы, которые содержат {b: 5} find( { "arr": { $elemMatch: { b: { $eq: 2 }, c: { $lt: 150 } } } } )

find( { $and: [ { 'arr': { $elemMatch: { b: {$eq: 2}, c: {$lt: 150} } } }, {'arr.b': {$ne: 5}} ] } )

find( { $and: [ { 'arr': { $elemMatch: { b: {$eq: 2}, c: {$lt: 150} } } }, {'arr.b': {$ne: 5}} ] } )

спасибо! я всё крутил крутил и никак не получалось заставить работать...

Доброе утро, ищу ментора по mongoDB, js. 800 руб/ч

РБК пиарит монгу)

Новая утечка персональных данных – в Сети в открытом доступе оказалась база клиентов кредитного брокера «Альфа-Кредит» (компания указывает, что не связана с Альфа-банком). В базе более 44 тыс. записей с именами, телефонами, адресами проживания и электронной почтой. Они были в системе управления баз данных MongoDB с открытым кодом. Эту базу 31 января проиндексировал поисковик, из-за чего получить информацию о человеке из этой базы стало возможным через поисковую выдачу.

опять 27017 не закрыли?

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

хд

из соседнего чата, ссылку не буду давать

Привет Есть ли смысл кешировать данные если я использую монгу которая запущенна локально (т.е. обращаюсь к ней как к localhost)? По сути в таком случае она уже используется как кеш?

Привет Есть ли смысл кешировать данные если я использую монгу которая запущенна локально (т.е. обращаюсь к ней как к localhost)? По сути в таком случае она уже используется как кеш?

Нет

Нет

Это ответ на первый вопрос?

Вообще, чем использование того же редиса лучше чем {}?) redis.put(key, value) redis.get(key) vs cache[key] = value cache[key] Всегда мучил этот вопрос

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

А в случае обращения к редису нужно сходить к нему по сети (пусть и на локальный хост), он там выполнит какие то свои внутренние операции, достанет данные и вернёт их вам опять же по сети

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

Доброго времени суток, Подскажите, пожалуйста, есть ReplicaSet из 3-х серверов, MongoDB 4.2. Разработчик дропнул тестовую базу, нужно восстановить. Есть резервная копия VM, я ее (ВМ) сейчас восстановлю. А как быть с базой? Просто заархивировать директорию с базой с восстановленного сервера, перенести на Прод сервер, переместить все файлы в тот же каталог с базой (с заменой файлов), сделать перезапуск монго (но там тогда будут выборы Primary / Secondary). Или нужно сделать Mongoexport, и потом на Прод сервере Mongoimport? Размер базы 60 ГБ

Доброго времени суток, Подскажите, пожалуйста, есть ReplicaSet из 3-х серверов, MongoDB 4.2. Разработчик дропнул тестовую базу, нужно восстановить. Есть резервная копия VM, я ее (ВМ) сейчас восстановлю. А как быть с базой? Просто заархивировать директорию с базой с восстановленного сервера, перенести на Прод сервер, переместить все файлы в тот же каталог с базой (с заменой файлов), сделать перезапуск монго (но там тогда будут выборы Primary / Secondary). Или нужно сделать Mongoexport, и потом на Прод сервере Mongoimport? Размер базы 60 ГБ

Второе, но вместо mongoexport/import используйте mongodump/restore

я бы лучше второе, надёжнее

Спасибо 😊

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

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

Число?)

Число?)

int32?

BSON Date is a 64-bit integer that represents the number of milliseconds since the Unix epoch (Jan 1, 1970).

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

BSON UTC Datetime (x09) и есть время в миллисекундах since epoch

Это ответ на первый вопрос?

На второй, но я могу ошибаться

Здравствуйте Ребят, подскажите, нормально ли хранить такую структуру данных ? [ { "id": i, "test_field": 1, "my_nested_filed1": [ { "dateN": "date", "my_nested_field2": [ { "f1": "f1", "fN": "fN", }, ... ] И другой вопрос. Мне нужно обновить test_field, где сумма f1 > 100 в my_nested_field2 и где date в my_nested_filed1 between X и Y. Запрос на выборку через aggregate работает супер быстро, а вот на апдейт работает 2 минуты на 1кк таких записей. Как можно ускорить ?

Здравствуйте Ребят, подскажите, нормально ли хранить такую структуру данных ? [ { "id": i, "test_field": 1, "my_nested_filed1": [ { "dateN": "date", "my_nested_field2": [ { "f1": "f1", "fN": "fN", }, ... ] И другой вопрос. Мне нужно обновить test_field, где сумма f1 > 100 в my_nested_field2 и где date в my_nested_filed1 between X и Y. Запрос на выборку через aggregate работает супер быстро, а вот на апдейт работает 2 минуты на 1кк таких записей. Как можно ускорить ?

начните с explain

и если я правильно понял что вы хотите обновить 1кк записей - то конечно же это будет долго - ресурсы диска не бесконечны