хорошие ODM, например mongoid в рубях, сам умеет делать дельту документа и сводить дельту к атомарной операции
главное не делать удаление и модификацию одновременно
eshch
eshch
потому что одм не разделяет это на два запроса, а монга ругается
eshch
монгоид в частности
Sergey
в мысле что не целиком обновлять документ, а только изменившиеся поля
Optimistic locking не умеет?
Ilya
я работаю с монгой из Python и пока только начинаю
Ilya
.
Sergey
Можно одно поле
yopp
ну вот, берёшь дельту и её с оптимизмом адпейтишь
Sergey
ну вот, берёшь дельту и её с оптимизмом адпейтишь
А за это время кто-то параллельным запросом эти данные поменял
yopp
и оптимизм нам помог получить modified: 0
yopp
а мы со своей стороны или retry сделали и перечитали документ
yopp
но это не к odm уже вопрос
Sergey
а в чем проблема?
Банальная проблема многопоточного доступа к данным, которая почти ставит крест на любых ODM.
eshch
ой божечки
eshch
уж прям таки ставит
eshch
надо просто другие структуры данных и алгоритмы применять
eshch
всем нравится работать в полном асиде, вот тока медленно
yopp
Банальная проблема многопоточного доступа к данным, которая почти ставит крест на любых ODM.
это настолько абстрактная постановка проблемы, что в таком виде всё что угодно на всё что угодно крест ставит
Sergey
Ну я имею в виду глобальный лок на документ, а не на всю базу как в mmapv1
Sergey
а что это решит?
Есть два запроса:
1. Прочитать данные.
2. Изменить
3. Записать дифф.
Они приходят одновременно.
Sergey
Какой будет результат?
eshch
а че лок сделает? глобал лок в бд или в приложении?
Sergey
В зависимости от того какой лок.
Если optimistic, то не даст второму потоку записать данные после того, как они были изменены первым.
Если полный (pessimistic), то второй поток будет ждать чтобы прочитать данные, пока кто-то еще с ними работает. По второму принципу GIL работает во многих ЯП
Sergey
беглое гугление говорит, что из ODM для монги это поддерживает только Doctrine
yopp
Потому что монга не даёт для этого инструментов
yopp
В 3.6 в теории можно сделать на change stream, но это будет очень сложно.
Sergey
Потому что монга не даёт для этого инструментов
ну да, мир же однопоточный, никто не может прийти и попробовать поменять тот же документ, пока ты с ним работаешь
yopp
Sergey
let doc = yield Model.findById(id);
doc.prop = 123;
doc.val += 5;
yield doc.save();
пример прост до безумия
https://github.com/Automattic/mongoose/issues/4004
(из твоего лубимого mongoose)
eshch
В зависимости от того какой лок.
Если optimistic, то не даст второму потоку записать данные после того, как они были изменены первым.
Если полный (pessimistic), то второй поток будет ждать чтобы прочитать данные, пока кто-то еще с ними работает. По второму принципу GIL работает во многих ЯП
в первом случае тебе надо разруливать подобную ситуацию либо фэйлить запрос. во втором - это несколько запросов, как минимум на взятие лока. собственно так работают всякие реляционки. если оч хочется жить по второму сценарию, кто мешает? вот тока не все хотят
eshch
ну да, мир же однопоточный, никто не может прийти и попробовать поменять тот же документ, пока ты с ним работаешь
так это как раз у тебя мир однопоточный и что делать с многопоточностью тебе думать не хочется. пусть субд/орм разбираются.
yopp
Sergey
так это как раз у тебя мир однопоточный и что делать с многопоточностью тебе думать не хочется. пусть субд/орм разбираются.
я-то какраз подумал и выкинул ODM вообще)
Sergey
потому что он только ограничения привносит в этом случае
eshch
конечно ограничения. приходитя самому заморачивать с параллельностью.
yopp
Я тебя перестал понимать
yopp
Ты жалуешься что в монге сделали выбор в пользу того, что консистентность при многопоточность это твоя главная боль?
yopp
Или что?
Sergey
конечно ограничения. приходитя самому заморачивать с параллельностью.
А с ней в любом случае придётся заморачиваться, "Потому что монга не даёт для этого инструментов" (c) @dd_bb
eshch
и?
yopp
Тебе даны атомарные операции для этого.
Sergey
Ты жалуешься что в монге сделали выбор в пользу того, что консистентность при многопоточность это твоя главная боль?
я жалуюсь, что делают ODM к монге, которые должны упрощать работу с базой, а на практике они только усложнают её, потому что корраптят данные. А если ты начинаешь писать свою реализацию блокировок, то упираешься в кучу ограничений ODM.
Sergey
И еще, они любят делать десяток запросов на простые операции, которые ты рыками уместишь в один.
То есть прощайте атомарные операции.
Sergey
Тебе даны атомарные операции для этого.
Для примера с
- Прочитать
- Изменить в памяти
- Записать
нельзя сделать атомарную операцию. Кроме простого инкремента, который умеет монга
yopp
У меня богатый опыт с монгоидом, других одм я не видел, но там это элементарно решается
yopp
Для примера с
- Прочитать
- Изменить в памяти
- Записать
нельзя сделать атомарную операцию. Кроме простого инкремента, который умеет монга
Так эта проблема вообще решается только двумя способами
yopp
В любом хранилище
eshch
eshch
тебе что ли монгу дали чтоб ты там постгрес свой сделал?
eshch
бред
eshch
данные надо организовывать по-другому
eshch
и не для всех кейсов ее использовать
Sergey
давайте запретим update вообще
Sergey
и проблем не будет)
Sergey
только создание документа целиком и чтение
Sergey
один раз записал и читай сколько хочешь
Sergey
из этого предложения
Alexander
для слабосвязанных данных
Sergey
один документ
Sergey
ни с чем не связанный
обновляется поле
Viktor
Я так и не понял, в чем проблема топик стартера? Что save заменяет документ, чем ломает консистентность при параллельном доступе?
Sergey
Я так и не понял, в чем проблема топик стартера? Что save заменяет документ, чем ломает консистентность при параллельном доступе?
не обязательно заменяет, но не учитывает то, что в то же время этот документ мог быть изменён кем-то, потому что между чтением и записью проходит довольно много времени по меркам БД.
yopp
eshch
то есть монга подходит только для логов, я так понимаю?
один из кейсов. еще есть кейсы когда с локами долго, при том что гонок мало и это терпимо. или когда просто допустимо чтоб апдейты гнались.
Viktor
не обязательно заменяет, но не учитывает то, что в то же время этот документ мог быть изменён кем-то, потому что между чтением и записью проходит довольно много времени по меркам БД.
По-моему правильно делает, что не учитывает ничего
Sergey
Почему оно должно это делать? >]
Потому что в противном случае ODM - это только лишняя головная боль, а не вешь, призванная облегчать работу с данными.
yopp
В монгоиде оптимистичная блокировка тривиально реализуется.
yopp
Это же OSS. Fork you
Sergey
ну монгоид я не видел