+по если тебе надо делать skip с большим количеством объектов, то это будет медленно, если не делать через find({_id>val})

поменяешь ид на свои, не будет работать

есть список поездок - айдишник нужно отображать юзеру в истории поездок. могут быть проблемы/вопросы - он тогда называет айдишник админу по телефону - и тот с админки ()самописной - делает над сущностью операции

не используйте для этого _id

заведите отдельное поле, пишите туда какойнибудь цифровой код

то есть +1 поля в коллекции с индексом

ок, спасибо, согласен

@yurii_chikhrai что не так?

ок, спасибо, согласен

более того, не обязательно чтоб этот код бы уникальным :)

более того, не обязательно чтоб этот код бы уникальным :)

обязательно

зачем?

зачем?

ну что бы однозначно идентифицировать сущность не использую других полей

@yurii_chikhrai что не так?

а монга у тебя какая?

зачем?

или я не прав?

а монга у тебя какая?

3.2.19

3.2.19

а работаешь по этой документации, верно?

ну что бы однозначно идентифицировать сущность не использую других полей

зачем? :)

@dd_bb обнови в пине версию монги 4.0.3

а работаешь по этой документации, верно?

Понял. Спасибо.

зачем? :)

для серча

а работаешь по этой документации, верно?

это для 3.6, в 3.2 другой синтаксис

3.2.19

точнее там нет возможности передать таймзону

Stable: 4.0.3 (Oct 9, 2018) Bugfix: 3.6.8 (Sep 19, 2018), Legacy: 3.4.17 (Sep 7, 2018) MongoDB quick overview/production notes: https://www.percona.com/live/e17/sites/default/files/slides/Running%20MongoDB%20in%20Production%20-%20FileId%20-%20115299.pdf 4.0.3: https://docs.mongodb.com/manual/release-notes/4.0/#oct-9-2018 3.6.8: https://docs.mongodb.com/manual/release-notes/3.6/#sep-19-2018 3.4.17: https://docs.mongodb.com/manual/release-notes/3.4/#sep-7-2018 End of life: 3.2.21 (Sep 2018 / Sep 2018), 3.0.15 (May 2015 / Feb 2018)

точнее там нет возможности передать таймзону

Уже понял.

А что может быть плохого, если с 3.2 обновиться до 3.6?

А что может быть плохого, если с 3.2 обновиться до 3.6?

посмотри мануал по миграции, там есть нюанс с конфигом, а так разницы не заметишь

посмотри мануал по миграции, там есть нюанс с конфигом, а так разницы не заметишь

Спасибо, Юра!

Спасибо, Юра!

https://docs.mongodb.com/manual/release-notes/3.6-upgrade-standalone/ вот, надо featureCompatibilityVersion обновить

для серча

в целом, эти все номера — дурацкая затея

в целом, эти все номера — дурацкая затея

почему? как правильно?

бизнес логику я описал выше - вполне адекватная

правильно не требовать от пользователя тренировать память :)

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

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

состояние когда нода выпала за оплог разрешается с помощью inital sync. это просто копирование данных и последующее накатывание на них оплога

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

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

устройства чего?

устройства чего?

Общения праймари и секондари, и какие RPC между ними ходят

https://github.com/mongodb/mongo/wiki/Replication-Internals

нет никакого rpc

есть дубовый wire protocol

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

вам это зачем вообще?

в 99.9% случаев это не стоит читать вообще :)

монга по сути делает mongorestore из соседней ноды, это всё что стоит об этом знать

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

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

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

вам это зачем вообще?

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

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

репликацию оплога?

репликацию оплога?

Не, внутренней структуры данных. Я почти сделал Raft, но мне не хотелось бы хранить весь журнал, чтобы при подключении нод его на них реплицировать. Мне стало интересно, как это сделано в MongoDB, но в документации не нашел. Не додумался на Github зайти Да и в целом интересно, как оно там все внутри работает. Благодаря вам, узнал немного нового.

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

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

Микросервисная архитектура подразумевает, что один сервис, одна БД. Все доступы по API. Можете сделать один инстанс (или реплику), и много БД внутри

это я понял, но не понял что имеется в виду под БД - инстанс монги, или БД?

Здравствуйте. Использую Mongoose. Мне нужно найти все документы с определенным кошельком компании, и изменить его. Я сейчас попробовал вот такую функцию. await this.updateMany({ company_wallet: wallet_to_change }, { company_wallet: company_wallet.toLowerCase(), $push: { company_wallets: company_wallet.toLowerCase() } }, { new: true }) Но кажется updateMany не подходит, он не изменил документы. Какой метод мне следует использовать для массового обновления документов?

сейчас так и есть - на каждый сервис идет отдельный монго контейнер, но не ту мач ли это?

сейчас так и есть - на каждый сервис идет отдельный монго контейнер, но не ту мач ли это?

Можно сделать один инстанс (или репликасет) на все.

Не, внутренней структуры данных. Я почти сделал Raft, но мне не хотелось бы хранить весь журнал, чтобы при подключении нод его на них реплицировать. Мне стало интересно, как это сделано в MongoDB, но в документации не нашел. Не додумался на Github зайти Да и в целом интересно, как оно там все внутри работает. Благодаря вам, узнал немного нового.

рафт это же механизм консенсуса, а не репликации

рафт это же механизм консенсуса, а не репликации

Консенсус предполагает реплкацию журнала действий внутри автомата. То есть по сути есть состояние, мы реплицируем действия на Folower'ов, они меняют состояние внутри себя также, как и Leader

Можно сделать один инстанс (или репликасет) на все.

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

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

Разложить приложение по куче контейнеров сложнее. Монга может даже не жить в контейнерах

Консенсус предполагает реплкацию журнала действий внутри автомата. То есть по сути есть состояние, мы реплицируем действия на Folower'ов, они меняют состояние внутри себя также, как и Leader

вот честно, я бы монгу взял

рафт это же механизм консенсуса, а не репликации

Там несколько частей: Leader Election, Log replication, и safety

потому что делать свою репликацию, это путь вникуда. оно конечно прикольно, но сделать это надёжным это сотни человеколет

а нафига нужна репликация, которая ненадёжная

либо любую другую подходящую базу или зукипера или что-то ещё, что работает

либо любую другую подходящую базу или зукипера или что-то ещё, что работает

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

сейчас так и есть - на каждый сервис идет отдельный монго контейнер, но не ту мач ли это?

задайте себе вопрос - возможна ли такая ситуация, что конкретно одна база, среди 10 на инстансе требует обновления БД, а остальыне не допускают даунтайма. Если такое может произойти - вам на каждуй микросервис - свой инстанс монги

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

эти мегабайты не просто так есть

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

на уровне токомавка

задайте себе вопрос - возможна ли такая ситуация, что конкретно одна база, среди 10 на инстансе требует обновления БД, а остальыне не допускают даунтайма. Если такое может произойти - вам на каждуй микросервис - свой инстанс монги

да, такое возможно. а как лучше деплоить такое количество инстансов тогда, какой best practice? если еще и реплику на особоважные делать - это же крышеснос будет

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

Тем интереснее попрактиковаться в ее решении. Это же спортивный интерес скорее.

да, такое возможно. а как лучше деплоить такое количество инстансов тогда, какой best practice? если еще и реплику на особоважные делать - это же крышеснос будет

если это дял вас сложно - то тогда пилите монолит

если это дял вас сложно - то тогда пилите монолит

для монолита уже поздно, все готово)

Тем интереснее попрактиковаться в ее решении. Это же спортивный интерес скорее.

если это какое-то продуктивное решение, этого не стоит делать. примерно как свою криптографию

для монолита уже поздно, все готово)

вообще деплой и все остальное это нужно у народа спрашивать, тут я особо не помогу

если это какое-то продуктивное решение, этого не стоит делать. примерно как свою криптографию

Да так-то да. Можно взять Consul, у него реализованный Raft с репликацией журнала из коробки

вообще деплой и все остальное это нужно у народа спрашивать, тут я особо не помогу

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

Да так-то да. Можно взять Consul, у него реализованный Raft с репликацией журнала из коробки

вот как раз тоже консул собираюсь использовать

Да так-то да. Можно взять Consul, у него реализованный Raft с репликацией журнала из коробки

а, точно, там же целая плеяда распределенных k/v

вот как раз тоже консул собираюсь использовать

Это я не вам писал, но похвально =)

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

Попробуйте на «бумаге» схематично изобразить. Выберите сервисы для которых может быть одна монга, выберете те, для которых нужна разная. Когда разобьете на категории, станет проще. Можно UML Deploy диаграммой изобразить, я обычно с этого начинаю в таких «затупах»

Попробуйте на «бумаге» схематично изобразить. Выберите сервисы для которых может быть одна монга, выберете те, для которых нужна разная. Когда разобьете на категории, станет проще. Можно UML Deploy диаграммой изобразить, я обычно с этого начинаю в таких «затупах»

Спасибо, попробую!

Спасибо, попробую!

Можете в чат к девопсерам сходить @ru_devops и @devops_ru, это скорее задача из их области

Можете в чат к девопсерам сходить @ru_devops и @devops_ru, это скорее задача из их области

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

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

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

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

Ценное наставление, спасибо! Да, в любом случае ошибки будут, надо рисковать)

db.getCollection('payments').aggregate([ { "$match": {status: 'paid'} }, { "$group": { "_id": null, "total": {"$sum": ["$amount", "$credentials.WMI_COMMISSION_AMOUNT"]} } } ]) Как вывести общую сумму оплат с вычетом комиссии, которая находится в credentials.WMI_COMMISSION_AMOUNT? При таком запросе ошибка: Error: Assert: command failed: { "ok" : 0, "errmsg" : "aggregating group operators are unary ($sum)", "code" : 15953 } : aggregate failed

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

какой лучше всео подойдет?

какой лучше всео подойдет?

А какая разница?

хороший ответ

Дебиан убунту центось

Разницы нету

Разницы нету

спасиб

Убунту проще всего лтс

ну я думаю 18,04 ставить

Хороший выбор