у тебя любая выбока в которой не известен точно шард-ключ будет броадкастится на весь кластер

Угу

и это убивает весь смысл шардинга

И это сильно будет медленно по сравнению с одной нодой?

это работает для всяких приблуд типа gridfs и прочих

И это сильно будет медленно по сравнению с одной нодой?

я не знаю что такое «медленно» или «быстро» :)

Ок. Запросы будут быстрее или медленнее выполнятся при использовании hashed и __id чем если бы они работали на одной ноде?

И на сколько быстрее/медленнее? Хотя бы примерно на глаз :)

потому что правильный вопрос: для данных X, испольуемых через выборки Z и Y, как изменится производительность при изменении топологии с Foo на Bar

И на сколько быстрее/медленнее? Хотя бы примерно на глаз :)

¯\_(ツ)_/¯

Я тут думал за часик все поменяю и буду на коне. А тут такие философские вопросы :)

Кстати купили iops

1000

Мало:)

По цене как ещё один сервак :)

это от того что почти все думают про данные самым неэффективным образом

В общем ты считаешь что лучше реплика с чтением с secondary?

В принципе если использовать ephemeral...

Возникает вопрос насколько это хреново если бутнуть потом этот сервер

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

Насколько быстро реплика поднимется...

тебе нужна скорее всего hidden реплика, с которой ты будешь делать дампы/выборки в целевую систему

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

Ну смотри, я начинаю экспорт, secondary начинает прогибаться под нагрузкой...запросы начнут идти на primary?

если ты сделаешь readPrefrence: secondary — нет

Ну тогда у меня просто зависает secondary и на этом все...

хм

небось запросы без maxTimeMs, да?

Там вроде была опция другая по запросам, типа где меньше latency

небось запросы без maxTimeMs, да?

Ну у меня есть курсоры которые должны час висеть...

у них таймаут в час установлен?

Нет

или в полтора?

Я выключил вообще

:)

вобщем твоя проблема не в монге, а в том как у вас устроен экспорт

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

ну вот надо смотреть почему полтора часа

60 гигабайт за полтора часа — очень долго

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

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

11.3777777778 мегабайт в секунду

ммм

я очень люблю эту цифру

это что?

это ~100мбит

которые очень часто говорят о том, что клиент где-то ударился головой в сетевой интерфейс :)

ты к тому что я тупо сделал? :)

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

точнее не в дисковом io, а в сетевом

не ну EBS же по сети :)

сейчас у нас с4.xlarge

не думаю что у ebs полоса 100 мегабит

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

750

на EBS

судя по документации

для начала нужно убедиться что у тебя есть объективная картина происходящего на ноде

как на уровне ос, так и на уровне монги

я рекомендую prometheus + grafana

и туда https://github.com/y8/mongo_collection_exporter

с ноды собирать максимум метрик

там вроде клаудвотч экспортер есть

ок, поработаю над этим

а для начала есть какие-то простые утилиты чтобы собрать это все?

ну типа atop/htop?

толку от этого нет

нужно в динамике смотреть корреляции

в духе: в монге упали qps, в это же время полка после пика в сетевом io

хм, ну статистика по EBS у меня есть в принципе с AWS

но это не ОС конечно

нужно не только EBS, нужно видеть утилизацию основных ресурсов

по монге ясно...что-то надо прикрутить

CPU, RAM + RAM IO, DISK + DISK IO, NET + NET IO

а есть что-нибудь готовое по мониторингу с docker-compose например?

прометей и графана точно поднимаются из докера

а хотя да, как же засунуть в докер если оно мониторит систему...

а, хм

нормально засунуть