aggregate, $group

спс

Наверное. Хотя, как поставлен вопрос, так и получен ответ, тамщемта. Возможно стоит воспользоваться $match в том же aggregate

Да ну опять же.

Модно зато

Ну да ладно, продолжайти

если делать db.coll.find({customid: 1408}).sort({member.timestamp: 1, client.date: 1}); то сначала выводяться все отсортированные документы с member.timestamp , а потом client.date отсортированные а надо чтобы они вместе сортировались ))

А что если у элемента две даты, то как сортировка будет? Если извращаться, то смотри в сторону pipeline, а на деле неправильно хранишь данные, вот и задача дурацкая

А что если у элемента две даты, то как сортировка будет? Если извращаться, то смотри в сторону pipeline, а на деле неправильно хранишь данные, вот и задача дурацкая

две даты не может быть но спасибо за ответ

если делать db.coll.find({customid: 1408}).sort({member.timestamp: 1, client.date: 1}); то сначала выводяться все отсортированные документы с member.timestamp , а потом client.date отсортированные а надо чтобы они вместе сортировались ))

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

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

понятно спасибо за ответ, буду делать как Вы и сказали " ...оба поля мапить в новое..."

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

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

и еще я вижу у вас две разные сущности в одной коллекции, если допустимо, то общее нужно вынести на врехний уровень документа и добавить флаг client/member, позволит строить нормальные индексы

согласен, спасибо за помощь!надо будет както изменить данные которые уже есть...

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

https://twitter.com/lig1/status/953965736002834432

https://twitter.com/lig1/status/953965736002834432

тока не баньте;) сорри, если не в тему

коллеги, а не подскажете, можно ли питоновским скриптом вытащить db.getReplicationInfo()? pymongo вообще позволяет это?

коллеги, а не подскажете, можно ли питоновским скриптом вытащить db.getReplicationInfo()? pymongo вообще позволяет это?

http://api.mongodb.com/python/current/api/pymongo/database.html#pymongo.database.Database.command подойдет?

http://api.mongodb.com/python/current/api/pymongo/database.html#pymongo.database.Database.command подойдет?

хм, насколько я понял это просто вызов команды монги из питона. Поясню ситуацию, у меня есть 3 кластера, в каждом 10-12 репликасетов, в каждом репликасете 4 ноды (3+архивная, с отставанием на час). Время от времени случаются ситуации, когда из за интенсивной записи, архивные ноды отваливаются в recovering, потому как не хватает размера оплога. на наиболее критичных репликасетах мы выкрутили оплог до максимума, что в общем то исправило ситуацию. К остальному хозяйству, я хочу прикрутить мониторящий скрипт, который покажет размер оплога, время на которое его хватает, для каждой из нод кластера.

хм, насколько я понял это просто вызов команды монги из питона. Поясню ситуацию, у меня есть 3 кластера, в каждом 10-12 репликасетов, в каждом репликасете 4 ноды (3+архивная, с отставанием на час). Время от времени случаются ситуации, когда из за интенсивной записи, архивные ноды отваливаются в recovering, потому как не хватает размера оплога. на наиболее критичных репликасетах мы выкрутили оплог до максимума, что в общем то исправило ситуацию. К остальному хозяйству, я хочу прикрутить мониторящий скрипт, который покажет размер оплога, время на которое его хватает, для каждой из нод кластера.

вопрос был "как дернуть db.getReplicationInfo()". это команда. её можно дернуть с помощью метода command класса Database а вот мониторить монгу у нас туту есть специально обученные товарищи;) @dd_bb

Ребят, привет. Я фронтендер, в серверной разработке новичок. В чём вопрос: Есть костяк сайта, сервер на node.js, фронт на vue.js, бд монго. Локально CRUD в монго работает, на удалённом сервере (у меня linode 1gb) появляется ошибка: "net::ERR_CONNECTION_REFUSED" Как настроить права доступа для приложения? Ubuntu 16.04 Прокси nginx

вопрос был "как дернуть db.getReplicationInfo()". это команда. её можно дернуть с помощью метода command класса Database а вот мониторить монгу у нас туту есть специально обученные товарищи;) @dd_bb

это не команда, это метод в js для шелла

коллеги, а не подскажете, можно ли питоновским скриптом вытащить db.getReplicationInfo()? pymongo вообще позволяет это?

это можно посчитать руками

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

не надо думать

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

просто убрав скобки

но так да, логика верная

https://github.com/db-ai/mongo_collection_exporter/blob/master/app/models/exporter/collector/op_log.rb

а зачем оно надо?

Ребят, привет. Я фронтендер, в серверной разработке новичок. В чём вопрос: Есть костяк сайта, сервер на node.js, фронт на vue.js, бд монго. Локально CRUD в монго работает, на удалённом сервере (у меня linode 1gb) появляется ошибка: "net::ERR_CONNECTION_REFUSED" Как настроить права доступа для приложения? Ubuntu 16.04 Прокси nginx

продуктивнее всего в @ru_devops спросить

а зачем оно надо?

Ну просто интенсивность записи в шардированный кластер видимо настолько велика, что у нас пару раз была ситуация, когда оплога в 10 гигов, в репликасетах кластера хватало всего на 5-10 минут. Из за этого отваливались бэкапные ноды, которые по задумке архитектора должны были отставать на час от мастеров. Поэтому я для собственного удобства понимания картины происходящего с кластером, пытаюсь скриптами вытащить данные по состоянию репликасетов.

разверни mongo_collection_exporter

prometheus + grafrana + экспортер

там даже готовые дешборды есть,

но вообще надо просто увеличить размер оплога

Не поверишь, так и делаю.

а зачем бекапные ноды отстают?

вы же знаете что ваши бекапы сломанные, если это в шардед кластере?

Sharding In sharded clusters, delayed members have limited utility when the balancer is enabled. Because delayed members replicate chunk migrations with a delay, the state of delayed members in a sharded cluster are not useful for recovering to a previous state of the sharded cluster if any migrations occur during the delay window.

https://docs.mongodb.com/manual/core/replica-set-delayed-member/#sharding

мин, ща за нормальную клаву пересяду.

а зачем бекапные ноды отстают?

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

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

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

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

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

вообще бекапить шардед кластер сложновато

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

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

по плейбуку из доки, с маркерами?

не запись, путаюсь в терминах, репликация.

если это не по плейбуку сделано, то надо изучить плейбук и переделать как там написано

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

убеждаться что балансер и выключен и не активен

если это не по плейбуку сделано, то надо изучить плейбук и переделать как там написано

а не трудно ссылку кинуть на плейбук?

под большой нагрузкой выключение балансера != завершению работы балансера

https://docs.mongodb.com/manual/tutorial/backup-sharded-cluster-with-filesystem-snapshots/

И да, вот это: IMPORTANT To capture a point-in-time backup from a sharded cluster you must stop all writes to the cluster. On a running production system, you can only capture an approximation of point-in-time snapshot.

Всё ещё актуально

И да, вот это: IMPORTANT To capture a point-in-time backup from a sharded cluster you must stop all writes to the cluster. On a running production system, you can only capture an approximation of point-in-time snapshot.

блин, нереально. нам никто не даст остановить запись

ну вот тогда надо сделать risk assesment вашего бекапа

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

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

а что у вас там с такими размерами, что оплога хватает на 5-10 минут?

gridfs?

или что-то с высокой частотой обновления?

RTB там какой

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

Т.е. вам нужно было cow сделать, а вы решили бэкапам отставание добавить, светлая идея.

Т.е. вам нужно было cow сделать, а вы решили бэкапам отставание добавить, светлая идея.

Даже если не хочется cow, можно сделать soft delete и отложенный hard delete.

Даже если не хочется cow, можно сделать soft delete и отложенный hard delete.

Бизнес задачи лучше решать приложением, а не инфраструктурой.

блин, нереально. нам никто не даст остановить запись

а я говорил что надо делать the world для бэкапа

stop the world

В каком городе вам было бы удобнее всего посетить MongoDB митап? Москве – 19 ??????? 28% Санкт-Петербург – 16 ?????? 24% Всё это далеко от меня – 12 ???? 18% Киев – 6 ?? 9% Владивосток – 4 ? 6% Ростов-на-Дону – 4 ? 6% Екатеринбург – 3 ? 4% Минск – 3 ? 4% Воронеж – 1 ▫️ 1% Астана ▫️ 0% ? 68 people voted so far.

В каком городе вам было бы удобнее всего посетить MongoDB митап? Москве – 19 ??????? 28% Санкт-Петербург – 16 ?????? 24% Всё это далеко от меня – 12 ???? 18% Киев – 6 ?? 9% Владивосток – 4 ? 6% Ростов-на-Дону – 4 ? 6% Екатеринбург – 3 ? 4% Минск – 3 ? 4% Воронеж – 1 ▫️ 1% Астана ▫️ 0% ? 68 people voted so far.

Пятничный опрос про встречу в реале

продуктивнее всего в @ru_devops спросить

Спасибо)

парни, а в mongoose можно в схеме определить тип массив и чтобы допустимые значения были ограничены данными из массива?

о! или валидатор проще прикрутить?

У меня очень интересный вопрос. Как Монго воспринимает пустую строку в отношении занятого места? Что "экономнее" хранить, пустую строку типа '' или null ?

Этот вопрос родился когда я увидел что база в SQL занимает 130 кб, а в Монго 6 мегабайт. Пустые строки есть и их прилично, вот и подумал

NULL - 1 байт "" = 2 байта

NULL - 1 байт "" = 2 байта

но не может же быть такая разница. Одни и теже данные в MySql занимают в разы меньше

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GSQL_langelements_null

Since a NULL truly has no value, appending a blank to it creates a string of length 1. But an empty string does have a character value, so appending a blank to it creates a string of length 2

Кто сталкивался. Почему может JSON приходить в противоположной очерености ?.

Да, но всегда возвращало одинаково и теперь поменялось. Что может быть причиной ?.

python?

Node

Пробывал в разных браузерах и разных JSON formator extension

Эм.