скорости чего? монга из кеша будет стрелять не сильно медленее редиса :)
Так в этом и проблема
Sergey️
Sergey️
У монги кэш такой, что показывает outdated инфу)
yopp
что?
yopp
вы сейчас несёте чушь
Sergey️
Объект А - вставил через скрипт 1
Объект Б - нашел и обновил объект А через скрипт 2
Объект А - поиск по id через скрипт 1
Sergey️
Возможно кэшится в каких-то разных пулах
Sergey️
Решил редисом :))
yopp
начините вот отсюда https://docs.mongodb.com/manual/core/read-isolation-consistency-recency/
Sergey️
Ну мне что, делать нечего
Sergey️
:)
yopp
вы не очень разобрались в проблеме, выбрали другую технологию которая случайным образом несколько иначе решает вашу проблему и вам повезло получить то поведение, которое вы хотели (на самом деле скорее нет) и теперь рассказываете небылицы про хранилище
yopp
проблема изоляции актуальна для любого хранилища которое поддерживает concurrency
Sergey️
Sergey️
На самом деле, я просто не желаю пердолиться
Bro
я юзаю инмемори сторадж монгу для совсем временных данных
Andrey
гайз какой бест практис для кейса: фильтруем, возвращаем часть данных (skip, limit) и возвращаем общее кол-во по фильтру?
глянул доку по count там говорят что в 4+ драйверы деприкейтят этот метод
Bro
count после скипа или лимита плохо работает вроде
Mikhail
всем привет!
подскажите, как составить запрос к бд, чтобы получить документы, у вложенных объектов которых задано определнное поле (а не весь объект)?
скажем вот такие два элемента:
{
name: 'alice',
card: {
type: false,
code: 8475748,
}
}
{
name: 'bob',
card: {
type: true,
code: 8475748,
}
}
И нужно составить запрос с условием, что card.type === true (а code неизвестен)
Nick
так и пишите
Nick
{card.type:true}
Mikhail
find: { card: { type: true } } не работает, так как не задан code
Mikhail
аа, card.type
Lev
Господа, пишу bulk-ами в монгу очень много данных длительное время, через часов 10 перестают писаться данные в 2 самые нагруженные коллекции, когда в другие две пишутся, при этом нет ошибок ни со стороны драйвера для go, так и в логах самой монги. Не знаете что это может быть?
Lev
Нет идей в чем может быть проблема?
yopp
Попробуйте без bulk
yopp
Он вам скорее всего и не нужен, если у вас документы не по 100 байт
Lev
В одной коллекции средний размер документа 6.3 KB
yopp
Тогда от bulkWrite совсем мало толка, а вот с обработкой ошибок сложнее. Вставляйте по одному и проверяйте результат операции.
yopp
Я буду всю следующую неделю в Москве. Давайте митап устроим, я расскажу коротко как монга внутри устроена.
yopp
Площадка только нужна
Lev
Тогда от bulkWrite совсем мало толка, а вот с обработкой ошибок сложнее. Вставляйте по одному и проверяйте результат операции.
Тогда сразу монга офигевает, постоянные io timeout-ы
yopp
Ну вот вы и нашли проблему :)
yopp
Искать в какие ресурсы упирается монга
yopp
Какие данные это подтверждают?
Lev
Какие данные это подтверждают?
Оба процессора особо не напрягаются, ссдшники бывает на пару секунд загружаются на 100 процентов, но большую часть времени процентов на 15, оперативы должно хватать более чем, то что пишет в монгу и сама монга на одном серваке пашут, так что это и не сеть
yopp
Оба процессора особо не напрягаются, ссдшники бывает на пару секунд загружаются на 100 процентов, но большую часть времени процентов на 15, оперативы должно хватать более чем, то что пишет в монгу и сама монга на одном серваке пашут, так что это и не сеть
Это в момент отказа? io timeout кто получает? Вы пишите в несколько потоков? Вы уверены что вы на каждую вставку не открываете новое соединение?
Чем больше у вас будет количественных данных в момент отказа, и меньше «должно», тем понятнее будет где затык.
Alexander
Alexander
Implicit session: session { "id" : UUID("94465bd6-c05f-443c-9570-5060d1d0961f") }
проапгрейдил контейнер 3.6.3 до 4.0.6, появилась такая хрень. кто-нибудь знает, что с ней делать?
yopp
https://github.com/mongodb/specifications/blob/master/source/sessions/driver-sessions.rst#explicit-vs-implicit-sessions
Alexander
Alexander
Погоди, чот не догнал.
`MongoDB shell version v4.0.6
connecting to: mongodb://127.0.0.1:27017/xxxxxxx?gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("94465bd6-c05f-443c-9570-5060d1d0961f") }
MongoDB server version: 4.0.6`
о каком драйвере речь?
yopp
Lev
Это в момент отказа? io timeout кто получает? Вы пишите в несколько потоков? Вы уверены что вы на каждую вставку не открываете новое соединение?
Чем больше у вас будет количественных данных в момент отказа, и меньше «должно», тем понятнее будет где затык.
Нет, это не в момент отказа, а в процессе нормальной работы. go mongo driver. Да, в очень много потоков. Не уверен, но когда писал по одному, имел одну сессию и нигде не делал ни ее копии ничего подобного.
Что самое смешное, в момент отказа вообще ничего аномального не наблюдается.
Alexander
коннект тоже, вроде, ничего особенного не несет
#!/usr/bin/env bash
cont=$(docker ps -q --filter "name=xxxxxx_mongo_1")
docker exec -e COLUMNS="`tput cols`" -e LINES="`tput lines`" -it $cont \
bash -c "stty cols `tput cols`; stty rows `tput lines`; mongo xxxxxxx"
yopp
Нет, это не в момент отказа, а в процессе нормальной работы. go mongo driver. Да, в очень много потоков. Не уверен, но когда писал по одному, имел одну сессию и нигде не делал ни ее копии ничего подобного.
Что самое смешное, в момент отказа вообще ничего аномального не наблюдается.
Если вы пишите в очень много потоков, то io timeout может быть связан с тем что приложению не хватает дескрипторов.
Если проблема есть, но у вы не видите ничего анормального, то значит вы не туда смотрите :)
yopp
Но я в го плохо разбираюсь. Возможно у вас драйвер пытается открывать много соединений. Вы чем метрики собираете?
Lev
Lev
Если вы пишите в очень много потоков, то io timeout может быть связан с тем что приложению не хватает дескрипторов.
Если проблема есть, но у вы не видите ничего анормального, то значит вы не туда смотрите :)
Вполне возможно что смотрю не туда, на что надо смотреть?)
yopp
Не понял про дескрипторы немного.
*nix идеология — все файл. Процессы, потоки, соединения, устройства и т.д. Создание нового ресурса означает выделение под него файлового дескриптора. Операционная система использует систему квот. По-умолчанию у пользователя не очень большая квота, по-моему 1024 штуки (см ulimit -n). Т.е. один пользователь сумарно может использовать не больше этого числа.
Открывая соединения или создавая «зеленые» потоки, вы используете дескрипторы. Если одновременно открыть 1023 соединения, то 1024 уже не откроется. Не помню точно какое поведение по умолчанию, по-моему ошибка too many files. Timeout может быть следствием того, что на той стороне уперлись в лимиты. Впрочем к монги в стандартных пакетах эти лимиты отключены. Так что вероятно это не ваш случай. Плюс я вспомнил что в го своя атмосфера с параллелизмом.
Возможно у вас утекают активные соединения из пула или их числа банально не хватает для того числа параллельных «потоков» которые вы открываете.
yopp
Это может объяснять почему никаких других симптомов нет
yopp
У вас возникает борьба за ресурсы, которая заканчивается дедлоком
yopp
Я не знаю что такое PoolLimit
λ
Vladyslav
"keks" - возможно этот ключ массив?
Vladyslav
$elemMatch не обязательно, просто ‘keks.status’ тоже отработает)
Vladyslav
отработал бы если б keks был списком)
Pavel
но в этой ситуации что можно сделать?
Vladyslav
как минимум взять все и потом мапнуть)
Vladyslav
через aggregate надо доку смотреть, возможно
Vladyslav
я про findAll
Vladyslav
а потом просто на уровне аппликейшена отфильтровать
Pavel
оу, не хочется в приложении это делать
yopp
Поменяйте на массив: keks: [{n: k1, v:1}...]
Vladyslav
миграция лол