надо баннер сделать: leave cacheSizeGb alone
может сделать некий FAQ по частым вопросам и запиннить его в шапке чата?)
Slava
Veaceslav
Добрый день еще раз. Ребят, можете чутка помочь сделать пойск ? Делаю вроде все как в доках, вот только не получаю я index.
Veaceslav
И не могу искать по мену потом …
Veaceslav
Использую я GraphQL и mongoose. Для теста поставил в resolver вот такой код:
this.model.createIndex({ name: "text"});
Veaceslav
После этого глянул в MongoDB Compass но там нету индекса, только _id.
Veaceslav
Помогите плиз чутка. Спасибо заранее
Veaceslav
Получилось. Нужно было сказать в model что name: {text: true}
Sergey
Добрый день, кто то сталкивался с такой ситуацией, когда нужно агрегировать данные из двух баз данных?
Sergey
у меня есть два подключения к двум базам данных
Sergey
и нужно через lookup их связать
Sergey
или есть другое какоето решение?
yopp
никак
Nick
У нас было 2 пакетика травы, 75 ампул мескалина, .....
Nick
нормально никак
Nick
но я такой сранью занимался
Nick
это больно и сложно отлаживается
Nick
и вся логика в приложухе
Sergey
ок, спасибо
rdcm
всем привет
есть такой кейс, время от времени участники реплика сета голосуют между собой, и выбирают нового мастера
на это время бэк теряет хранилище и запросы отваливаются по таймауту
вопросов два
1) на сколько это валидное поведение для реплика сета? (по мне валидно, но в друг я что-то упускаю)
2) какие возможны варианты по улучшению доступности на время голосвания участников реплика сета?
Nick
*шутка про Венесуэлу
yopp
в целом, нет, это не нормальное поведение
yopp
голосование происходит когда по мнению кластера поменялась топология. такое может происходить если у вас праймари перестаёт подавать признаки жизни и отвечать на heartbeats
yopp
ну или если топология реально меняется. например у вас «мерацет» нода, которой приоритет позволяет стать праймари
rdcm
Трудно точно сказать почему, думается из-за сетевых проблем, теряют друг друга. Нод 3 штуки.
rdcm
голосование происходит когда по мнению кластера поменялась топология. такое может происходить если у вас праймари перестаёт подавать признаки жизни и отвечать на heartbeats
Праймари точно менялся, раза 3 за последний месяц. Попробую поизучать метри которые есть в атласе. Но в целом никакой уникальной активности по коннектам или количеству операций не было.
yopp
устраняйте сетевые проблемы
yopp
выбор нового праймари это всегда даунтайм
yopp
пишите в поддержку
yopp
но я почти уверен что это не в атласе дело, а в вашем приложении
yopp
80% что это праймари просто не справляется с нагрузкой
rdcm
Количество crud операций и коннектов, более чем приемлемое.
rdcm
60 коннектов для репликасета это много?
yopp
количество операций != результат операций
yopp
вы не туда смотрите
rdcm
Сетевой трафик смотреть?
yopp
положить ноду можно буквально двумя запросами
yopp
например сделать find({}) по 5Тб коллекции два раза
Edouard
Может быть каждая = COLLSCAN :)
yopp
смотреть надо на nsreturned, на сколько было прочитано в кеш, из кеша, сколько было сброшено на диск
rdcm
Таких запросов нет. Всё по индексам. На collscan есть алерт. И когда ручками ищешь, что-то он стабильно срабатывает.
yopp
каких запросов нет?
yopp
ну вы или на своём настаивайте, или слушайте что вам советуют
rdcm
На полное сканирование коллекций.
yopp
если хотите себя послушать, я вам ничем не могу помочь
yopp
rdcm
Это был ответ на Edouard Ispravnikov:
Может быть каждая = COLLSCAN :)
yopp
collscan это тоже фиговая метрика
yopp
потому что можно полностью сканировать индекс
yopp
монга при всей своей офигенности, имеет совершено паршивое observability
rdcm
смотреть надо на nsreturned, на сколько было прочитано в кеш, из кеша, сколько было сброшено на диск
Сейчас в дороге, вечером гляну.
AstraSerg
это больно и сложно отлаживается
Зависит от языка приложения. Питонячий pandos дает отличные возможности https://pandas.pydata.org/pandas-docs/stable/merging.html
rdcm
потому что можно полностью сканировать индекс
А название в логах у такой операции как будет выглядеть?
Nick
Зависит от языка приложения. Питонячий pandos дает отличные возможности https://pandas.pydata.org/pandas-docs/stable/merging.html
а он умеет данные подгружать пачками и при необходимости обогащать?
AstraSerg
а он умеет данные подгружать пачками и при необходимости обогащать?
Это не объект оригинального вопроса, но можно погуглить.
yopp
А название в логах у такой операции как будет выглядеть?
эм. это может делать любая операция которая делать read, а это всё, кроме вставки
Andrey
Алексей, а есть на примете что-нибудь для докера чтобы метрики в прометеус закидывать, какой нибудь экспортер?
AstraSerg
Алексей, а есть на примете что-нибудь для докера чтобы метрики в прометеус закидывать, какой нибудь экспортер?
Docker возвращает метрики в прометеус-френдли формате https://docs.docker.com/config/thirdparty/prometheus/
Denys
всем привет. подскажите плз, если у меня в моделе через populate линкую с другими моделями, как я могу узнать, какие поля я линкую?
rdcm
эм. это может делать любая операция которая делать read, а это всё, кроме вставки
Если речь про селективность и индексе на поле например с параметром false, то такого нет. Поиск по _id, уникальный индекс на email, там с селективностью всё ок)
Andrey
Andrey
да это понятно что есть и не один, какой советуешь?
AstraSerg
А ну это на вкус и цвет....
AstraSerg
Вот пример https://github.com/percona/mongodb_exporter
yopp
Если речь про селективность и индексе на поле например с параметром false, то такого нет. Поиск по _id, уникальный индекс на email, там с селективностью всё ок)
вы это на основании каких данных утверждаете?
yopp
я не верю людям, я верю цифрам
yopp
не бывает так чтоб что-то прилегало просто так
yopp
принцип причинности он непоколебим
yopp
вы можете не видеть причины, но она всё равно будет.
yopp
фраза «у нас всё нормально» это и есть корень того, почему обычно причину не видят
yopp
если бы у вас было всё нормально, у вас бы не разъезжались ноды
yopp
про прилегающий от нагрузки праймари это _одна_ из гипотез
yopp
исходя из принципа поппера, нужно составить такой эксперимет, который позволил бы подвергнуть гипотезу опровержению
yopp
нагрузка одна из самых вероятных причин. значит нужно собрать достаточно _объективных_ данных, чтоб опровергнуть эту гипотезу и перейти к следующей
yopp
фраза «у нас такого нет» это петрик
yopp
а вот когда вы начнёте говорить «у нас чтение в кеш не привышает XМбит/с, запись на диск из кеша X’Мбит/с, iops больше Z, CPU load меньше Y, количество возвращаемых документов +/- медианное значение», тогда вы начнёте использовать научный метод
rdcm
вы это на основании каких данных утверждаете?
Даже не знаю, до построения индексов была целая пачка запросов возвращающих, более 100к документов, их больше нет. Хорошо знаю кодовую базу и да там нет запросов с плохой селективностью) В целом это не противоречит тому, что есть проблема, но она точно не в индексах)
yopp
вы опять себя убеждаете