Anonymous
Обновил один из серверов (который сейчас на standalone, т.е. наименее рискованно) до 3.4. Всё ОК 👌
Anonymous
Да и быстрее стало работать, но возможно, это плацебо.
Anonymous
Оказалось, не плацебо, по замерам есть прирост производительности в районе 10-15%. Это касается больших агрегаций.
Aleksey
господа а где mongoreplay брать ?
Aleksey
билдить короче.
https://github.com/mongodb/mongo-tools
Aleksey
build.sh
Aleksey
с 3,2 выглядит будто работает
Sergey
Ого, монговские тулзы на Golang написаны. Тогда понятно, почему они так плохо с ipv6 работают
Nikolay
Sergey
И что этот стикер значит в данном контексте?
Nikolay
И что этот стикер значит в данном контексте?
Что я промазал и вместо него хотел отправить из говна и палок
Nikolay
Но только в данном контексте не более
Sergey
А кто как консистентность данных в условиях отстутсвия транзакции обеспечивает?
Ну то есть вот я прочиал из базы некоторые данные (один документ), изменил их и хочу записать обратно, но при этом их кто-то еще параллельно мог изменить.
В голову приходит два варианта:
1. В update в условии класть полностью весь документ (или часть, которая может быть изменена параллельным запросом)
2. Хранить в отдельном поле update счётчик в виде инкремента/даты/objid и при update указывать его в условии (и обновлять, соответственно)
3. ... ?
Sergey
речь про один документ, конечно же, не про несколько
yopp
Второе называется optimistic locking.
yopp
Зависит от требований к данным.
yopp
Первое не эффективно.
Sergey
первое дорого слишком, это понятно
yopp
Надо начать с вопроса почему так случилось и что мы будем делать если документ обновили.
Sergey
выдавать ошибку или ретраить этот вопрос уже бекенд будет разруливать
yopp
(Так случилось что нам нужно знать что документ не менялся)
Sergey
потому что мы живём в многопоточном мире)
в идеале - всё должно обновляться атомарным апдейтом, но вот обновить два разных элемента в массиве им уже не получится
Sergey
условно
{
_id: ...,
some_data: ...,
[
{'id': 1, 'value': null, 'other_value': 5},
{'id': 2, 'value': null, 'other_value': 6},
{'id': 3, 'value': null, 'other_value': 7},
{'id': 4, 'value': null, 'other_value': 8},
]
}
прислали patch и надо обновить только поле value в массиве, не трогая остальные
Sergey
за то время пока мы считали данные, изменили в памяти и пытаемся записать их обратно кто-то другой мог содержимое массива изменить
CC-BY-SA-4.0/Docker-ce30.0
with lock
Sergey
Второе называется optimistic locking.
Ага, оно.
Другой вопрос: в монге же нет способов работать с ними из коробки, только вручную логику разруливать?
Denis
а они же в 3.4 сделали опцию linearizability
Denis
или я плохо читал то что выше ?
Sergey
я 3.4 ещё не щупал
Sergey
и это вроде про read concern
Denis
ну да.
Sergey
а блокировки могут быть нужны даже вообще на одной ноде без реплик
Sergey
(хотя если мы читаем со слейвов и пишем в мастер - они нужны чаще)
Denis
тоесть ты про ту ситуацию когда у тебя одно обновление приехало позже другого но в реальнйо ижзни они случились раньше ?
Sergey
вот я, кстати, не уверен, что монга может оплог воспроизводить не подряд
Sergey
но вопрос быдл вообще о другом
Sergey
мы
1. читаем данные
2. изменяем их
3. пишем в базу
и последнее должно произойти только если кто-то параллельно не успел эти данные изменить
Sergey
optimisting locking - самый очевидный вариант
yopp
если тебе условно надо обновить элемент массива с id: 2 и там поставить value в новое значение, то в чём проблема?
yopp
атомарно это делается
Sergey
надо обновить 4 элемента
yopp
и 4 элемента можно обновить
Sergey
как?
yopp
somedata.$.value
Sergey
для каждого id разный value
yopp
блин
yopp
ты можешь внятно задачу сформулировать?
yopp
блин
yopp
прислали patch и надо обновить только поле value в массиве, не трогая остальные
yopp
все value?
yopp
или какие value?
Sergey
апдейт, допустим
[
{'id': 1, 'value':7},
{'id': 2, 'value':8},
{'id': 3, 'value':9},
{'id': 4, 'value':10},
]
yopp
гхм. и в чём проблема?
Sergey
ну либо я пропускаю какой-то очевидный вариант, либо это сделать нельзя в одном update
Sergey
да, порядок элементов в апдейте может не совпадать с тем, что в базе
yopp
ах.
Sergey
и вообще, пользователь может прислать какой-нибудь мусор вместо id, которого нет в исходном документе
yopp
ну это в query разрешается
Sergey
последнее - да
но вот с $ я что-то не видел в доке варианта с обновлением нескольких полей: https://docs.mongodb.com/v3.2/reference/operator/update/positional/#up._S_
yopp
да-да, яж сказал «ах»
yopp
задача изначально была поставлена невнятно. а вот когда ты показал что ты хочешь внутри массива изменить несколько разных элементов и поставить им разные значения, задача стала понятна.
Sergey
изначально идея была класть это в embedded с id - ключ, но тогда по этому полю не работает, например, $unwind
Sergey
задача изначально была поставлена невнятно. а вот когда ты показал что ты хочешь внутри массива изменить несколько разных элементов и поставить им разные значения, задача стала понятна.
ну я изначально вообще не хотел задачи касаться
yopp
эм
Sergey
вопрос-то был про locking
yopp
яж тебе ответил: когда ты хочешь блокировки в монге, сначала надо понять как ты докатился до такой жизни
Sergey
на самом деле, это просто перестраховка, поэтому и optimistic, а не pessimistic )
yopp
да какая разница, любая блокировка в субд которая не поддерживает блокировки, должна вызывать вопрос
yopp
я твою проблему понял, сходу пока ничего в голову не пришло, но мне кажется можно найти решение без блокировки
yopp
но я пока не уверен как
yopp
подумаю
Sergey
там будет 1 rpd (request per day 😊) на запись, но если вдруг будет идея как обойти - буду благодарен
yopp
пфф. да, оптимитичная блокировка тебя спасёт
yopp
правда у меня сразу возникает вопрос зачем тогда поддокументы
yopp
но ладно!