yopp
О, привет.
yopp
Afair пугают правильно.
yopp
Можно посмотреть на client sessions из 3.6, возможно с ними получится сделать что ты хочешь.
yopp
Точно в nodejs и c драйверах уже впилено. В руби пару недель назад только куски в транке были
yopp
А зачем тебе это?
Yura
Мультиплексированная передача запросов/ответов намного выгоднее использования тучи коннектов с отдельным раундтрипом на каждый реквест. На том же сайте редиса есть сравнение, показывающие выигрыш при пайплайне в пять-семь раз. Это довольно естественно, учитывая, сколько сисколов нужно в том и другом случае. А учитывая последний подарок от интел... проблема становится еще актуальнее.
Yura
Руби драйвер для eventmachine всю жизнь посылал запросы мультиплексированно через один коннект. И если есть уверенность, что запросы все быстрые, это выигрышная стратегия. Но если один запрос затормозит весь хвост, будет не приятно :-(
yopp
Смотри, с позиции драйвера нет «запросов». Есть дубовый wire протокол (по сути реализует логические фреймы) в котором payload — bson документы. Формат документов описывается поддерживаемыми командами.
yopp
Раньше там были разные типы фреймов, но их всех свели к одному M_MSG
yopp
Я сейчас могу врать, но насколько я помню сам протокол — request / response. Из-за этого например Bulk запрос это по сути один сгруппированный запрос и на него будет один ответ.
yopp
С этим связанны сложности с отслеживанием статуса конкретного запроса из bulk
yopp
Но мои знания актуальны на 2.8 – 3.0, там в последнее время кучу всего перепилили
yopp
Я не уверен что мультиплексирование возможно. Если на одно соединение можно открыть несколько сессий, то да. Если нет, то скорее всего архитектура под это не заточена.
yopp
Ты можешь почитать спеки
yopp
The OP_MSG message is essentially a request-response protocol, one message per turn. However, setting the moreToCome flag indicates to the recipient that the sender is not ready to give up his turn and will send another message.
yopp
https://github.com/mongodb/specifications/blob/master/source/message/OP_MSG.rst
yopp
https://docs.mongodb.com/ecosystem/drivers/specs/ от сюда можно начинать обзор
yopp
Можешь ещё в жире поискать
yopp
Можешь написать Emily, которая руби драйвер пилит
yopp
В твиттере @EmStoflo
Yura
Я уже успел попробовать em-mongo драйвер. Он старенький, но еще работает. И корректно мультиплексирует. И монга корректно отрабатывает. Но если с одного коннекта запросы обрабатываются строго по очереди, это резко уменьшает полезность мультиплексирования. Товарищ говорит, что эксперимент с killOp подтверждает, что это так, т.к. killOp посланный в тот же коннект не убивает запрос. Про OP_MSG я успел почитать до того, как сюда писать. Если приглядитесь, хедер фрейма остается прежним, а requestid и responsefor живёт именно в заголовке фрейма, и от типа фрейма не зависит. Т.е. "новый" протокол имеет те же возможности мультиплексирования, что и "старый" (т.к. это по сути тот же протокол).
Старый
Можешь написать Emily, которая руби драйвер пилит
у рубистов популярно монгу вместо редиса юзать
yopp
у рубистов популярно монгу вместо редиса юзать
Это на основании чего такое заявление?
yopp
Но в целом это всё просто проверить. Нужно порезать в докере ресурсы, в первую очередь io и симулировать медленные и быстрые запросы.
Yura
Послал пять запросов. Он их все одним writev в сокет плюнкл.
Yura
Ответы пришли корректно тем колбэкам, что их ожидали.
Старый
Это на основании чего такое заявление?
просто работал с 8 командами рубистов
Старый
чтот им редис всем не нравится, монгу говорят вместо него
Старый
сочетание правда mongo+postgre интересное
yopp
просто работал с 8 командами рубистов
Рубисты которых я консультировал используют монгу по назначению. ¯\_(ツ)_/¯
Старый
Рубисты которых я консультировал используют монгу по назначению. ¯\_(ツ)_/¯
ну. если тебе нужен редис который будет в 4 разных дц, выбор ток на монге 😂
yopp
Слабоумие и отвага
Sergey
ну. если тебе нужен редис который будет в 4 разных дц, выбор ток на монге 😂
Смотря какие задачи. Под локальный кеш редис явно быстрее.
Sergey
Но вообще, живые рубисты. 😱
yopp
Денег зарабатывают, а чо.
Sergey
Да хз, последний живой рубист, которого я знал, давно пишет на JS.
yopp
Плохой рубист значит
yopp
Вон, @funny_falcon так вообще у нас кучу полезностей в руби накомитил
Старый
так и ксс можно в отдельный язык сделать
Sergey
так и ксс можно в отдельный язык сделать
И btrfs в разряд стабильных, ага
tenni
хрыч и тут троллит
Junusali
Если я правильно понял, то так: collection.find({}, 'city') Такой запрос вернёт все города, которые есть в БД
нето что я хочу. Там пользователь может нажать кнопку все города а может нажать на один город. У меня в фильтре много параметров. И тут мне надо будет делать if else conditions. Если "всe" то в фильтр не вклчаем параметр города если один город "Chicago" то включаем параметр города. А я не хочу убирать этот параметр. Пусть он всегда будет стоять. Просто надо будет менять значение в зависимости от города. Типа collection.find({'city':'all'}) collection.find({'city':'Chicago'})
Nick
Просто не передавай параметры, find({})
Alexander
подскажите, плз, есть модель, содержащая поля field1 и date { "field1": "One", "date": "some date1" }, { "field1": "Two", "date": "some date2" }, { "field1": "Three", "date": "some dat3" }, { "field1": "Four", "date": "some date4" } как можно обновить поле date у нескольких записей, если есть массив типа [ {"field1": "One", "date": "new date"}, {"field1": "Three", "date": "one more date"} ] Поле field1 проиндексировано.
Alexander
а вот так должно работать? Model.updateMany({}, { $set: { date: new Date() } });
Alexander
Никак. Делать несколько запросов
а как обновить updatedAt ? пробую так, но не работает )) Source.updateMany({}, { $currentDate: { lastModified: true } }, { multi: true }); $set какой-нибудь обязательно делать?
Zloy-Dobry
Multi в апдейте зачем?
yopp
Как это никак
Во так — никак. Установить в два разных документа разные значения в одном апдейте нельзя
Zloy-Dobry
yopp
В оригинальном вопросе два документа и две даты.
yopp
Но вообще да, нужно указать $set
Alexander
А можно поинтересоваться как вы получаете события так, что вам требуется одновременно менять два не связанных поля? Или вы пытаетесь оптимизировать?
читаю rss из нескольких источников в разных часовых поясах. надо обновить запись каждого источника с указанием последнего pubDate из rss. field1 - uid источника. Второй массив, это массив обновленных rss
Alexander
Но, перечитав ТЗ, склоняюсь к тому, что проще завести одну запить с UTC и ее апдейтить при каждом дергании rss
Nick
Если хотите делать один большой запрос, то можете посмотреть в сторону bulkWrite https://docs.mongodb.com/manual/reference/method/db.collection.bulkWrite/
Zloy-Dobry
Нагрузочка подрастет и не упадет, например.
Zloy-Dobry
Гуглит
Анатолий
Нагрузочка подрастет и не упадет, например.
Один коннект с 5 запросами и нагрузочка подрастет, а 5 коннектов с 5 запросами не подрастет?
Zloy-Dobry
А зачем тебе в каждый запрос - коннект?
Igor
Всем привет
Анатолий
А зачем тебе в каждый запрос - коннект?
я не так выразился, но думаю ты понял что я имею ввиду
Zloy-Dobry
Нет не понял.
Igor
кто может носом тыкнуть как вернуть значения из findOne в переменную чтобы дальше работать с ней
yopp
Напримеп чем больно?
единственное чем больно — ошибок запросов не будет видно
Val
Охайо, немного оффтопа - есть чатик по nodejs/express?
Анатолий
https://t.me/nodejs_ru - чистая нода есть