кто сталкивался с таким.
Есть условно два типа процессов, A и B. Процесс A время от времени вычитывает коллекцию полностью, процесс B читает и апдейтит один и только один конкретный док (какой именно - зависит от того, с какими параметрами запущен), апдейтит чаще, чем читает. Процессов типа B намного больше, чем процессов типа A, где-то 10х, всего процессов в разные моменты может быть около 700+.
Верно ли, что в такой ситуации можно ожидать, что операция вычитки всей коллекции будет тормозиться об множество операций записи в коллекцию и, условно, висеть в очереди монги, пока не выполнятся все поступившие ранее запросы на запись? Есть ли в монге какие-то встроенные средства дать больший приоритет вычитке? Сама коллекция небольшая, где-то 10 мб, вычитка производится довольно быстро. Буду благодарен за линки на доку, где что-нибудь подобное описано, читал вот это https://www.mongodb.com/docs/v4.4/faq/concurrency/, но подходящих ответов не нашел.
Вам надо почитать про readConcern и writeConcern. В общем случает чтение не лочит.
Гляну, благодарю.
Также есть возможность сделать реплику и туда слать запросы на чтение, но в вашем случае это смысла не имеет, т.к. данных мало и запросов на чтение много меньше запросов обновления данных.
Т.е. если читать из secondary, а писать в primary - теоретически это могло бы снизить задержку, если бы коллекция была больше, например?
Да, так обычно делают, если надо например под жирную аналитику только ресурсы на чтение выделить. Или профиль 80-90% запросов на чтение и праймари не вывозит их
Наш юзкейс - это скорее что-то ближе к персистентному кэшу, вероятно не подойдет, да :(
Обсуждают сегодня