так как там разные уровни консистентности

и писать при шардировании

Репликация != шардирование

с реплик можно читать

^

с реплик можно читать

При соблюдении рад условий, это пограничный кейс. Реплики не являются механизмом масштабирования

Репликации не добавляет ёмкости в кластер

итог простой реплики - отказоустойчивость шарды - производительность верно?

тип того

Шарды да, механизм увеличения ёмкости. Но цена решения x3 сразу, плюс увеличение затрат на содержание.

в какой0то момент в репликах ты можешь читать с них

Скорее всего атлас будет дешевле

в какой0то момент в репликах ты можешь читать с них

Блин. НЕТ

но тогда будет эвентуал конситенси

нет

Шарды да, механизм увеличения ёмкости. Но цена решения x3 сразу, плюс увеличение затрат на содержание.

шарды без реплик не очень юзать я так понимаю

нет

что нет?

шарды без реплик не очень юзать я так понимаю

Реплики это строительный блок шардов

Лучше не читать из secondary так как есть вероятность что они не успеют реплицировать данные из primary

что нет?

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

Лучше не читать из secondary так как есть вероятность что они не успеют реплицировать данные из primary

Нет

Лучше не читать из secondary так как есть вероятность что они не успеют реплицировать данные из primary

во во тоже так думал

Есть read concern :majority

платите latency за консистесни

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

ну тут да. но тем самым разгрузишь мастер

тут по ситуации. конечно

Это логическое заблуждение

данных много летит решение не сидеть на одном сервере (выросли) вообщем только шарды с репликами(

я пока начитался запутался уже

Если на мастер льётся 40 мегабайт данных в секунду, то вы сколько не добавляйте реплик, на них на все эти 40 мегабайт будут реплицироваться

типа такой схемки должно быть в итоге верно @dd_bb ?

Если эти 40 мегабайт выбирают весь доступный IO, то чтение с реплик ни чем не поможет, потому что на репликах тоже не будет IO capacity из-за оплога

Реплики НЕ механизм масштабирования.

примерно

арбитры не нужны

с появлением :majority арбитры это устаревшее решение

Config Server тоже не один, а 3 минимум

арбитры не нужны

вот так и не понял (а сам не проверял еще) кто-то говорил без арбитров так себе жить, переключение медленное а ну в случае шардов наверное да, без реплик можно шард: - primary - secondary

вот так и не понял (а сам не проверял еще) кто-то говорил без арбитров так себе жить, переключение медленное а ну в случае шардов наверное да, без реплик можно шард: - primary - secondary

это неверная информация

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

а значит если вы используете read concern :majoriy то арбитры не добавляют отказоустойчивости, потому что :majority при отказе одной ноды не будет иметь кворума для выполнения запроса

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

для меня сложно(

@dd_bb в моем случае (да у и всех также видимо) шард 1: - prim - sec шард 2: - prim - sec

нет

реплики из 3 нод с данными

Config Sever Replica Set: 3 ноды Shard 1: 3 ноды Shard 2: 3 ноды Mongos: 3 ноды

итого 12 нод

Умножить на $15k в год за Enterprise лицензию, чтоб получить Ops Manager, через который делать бэкапы и ещё железо для хранения бэкапов

Запись не масштабируется это и так ясно, но чтение вполне можно масштабировать, за счет жонглирования консистентностью

Config Sever Replica Set: 3 ноды Shard 1: 3 ноды Shard 2: 3 ноды Mongos: 3 ноды

или доступностью

Запись не масштабируется это и так ясно, но чтение вполне можно масштабировать, за счет жонглирования консистентностью

Нет

поясни

Если эти 40 мегабайт выбирают весь доступный IO, то чтение с реплик ни чем не поможет, потому что на репликах тоже не будет IO capacity из-за оплога

^

ты все еще можешь контролировать скорость репликации

нет, не можешь

кроме того помимо запросов на изменение

есть запросы на чтение

которые тоже нагружают сервер

и вот их можно масштабировать

да нет же

почему нет?

почему нельзя сделать вместо 3х запросов на мастер

ты все еще можешь контролировать скорость репликации

the most inaccurate thing i’ve ever heard

3 запроса на метрики

на реплики

Config Sever Replica Set: 3 ноды Shard 1: 3 ноды Shard 2: 3 ноды Mongos: 3 ноды

есть примеры настройки такого монстра?

запросы на чтение

есть примеры настройки такого монстра?

https://docs.mongodb.com/manual/sharding/

Доброго дня. Как добавить в $project произвольное поле? const entries = await Subscription .aggregate([ { $match: { timestamp: parseInt(req.params.timestamp, 10) } }, { $group: { _id: null, sum: { $sum: "$price" } } }, { $project: { _id: false, sum: true } }, { $limit: parseInt(req.params.limit, 10) } ]) Хотел бы получать в ответ объект с полем timestamp и его значением parseInt(req.params.timestamp, 10).

просто иначе я не вижу смысла делать causal consistency для монги

но ее же сделали

запросы на чтение

вы почему-то считаете что io на запись и на чтение это изолоированное io

что ложно

стоп

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

я говорю что у мастера ограниченное IO

которое тратится и на чтение и на запись

вот IO на чтение можно масштабировать на реплики

Если эти 40 мегабайт выбирают весь доступный IO, то чтение с реплик ни чем не поможет, потому что на репликах тоже не будет IO capacity из-за оплога

^

т е запросы на чтение

реплицируются?