Потому что в противном случае ODM - это только лишняя головная боль, а не вешь, призванная облегчать работу с данными.
кроме конкуренции у людей еще бывает болит голова о производительности, но это не твой случай
eshch
Sergey
но интересно как
Sergey
кроме конкуренции у людей еще бывает болит голова о производительности, но это не твой случай
There are only two hard problems in distributed systems:
2. Exactly-once delivery
1. Guaranteed order of messages
2. Exactly-once delivery
(c)
Viktor
В монгоиде оптимистичная блокировка тривиально реализуется.
Так она в любом вменяемом драйвере легко реализуется
Sergey
в драйвере - да
Viktor
Я поэтому и не понимаю проблемы топик стартера
Viktor
Нигде же не написано, что ODM кому-то что-то должен
Sergey
но в драйвере ты запросы руками пишешь
eshch
There are only two hard problems in distributed systems:
2. Exactly-once delivery
1. Guaranteed order of messages
2. Exactly-once delivery
(c)
ну так ты их решаешь через то что стоишь в один поток. и говоришь, что таким образом подумал о многопоточности.
yopp
но в драйвере ты запросы руками пишешь
а что, монгус этот не умеет query с трансформациями выплёвывать?
Sergey
а что, монгус этот не умеет query с трансформациями выплёвывать?
что такое query с трансформациями?
Sergey
про монгус я хз, это ж ты его используешь вроде
yopp
я?
yopp
нет :)
Sergey
а
Sergey
mongoid
Sergey
перепутал
yopp
у меня от js зубы болят, я больше по рубям упарывался
Sergey
ну так ты их решаешь через то что стоишь в один поток. и говоришь, что таким образом подумал о многопоточности.
у меня optimistic locking сейчас применяется, в общем-то параллельная запись в один документ в моём случае - довольно редкий кейс, но не учитывать его всё равно нельзя
Viktor
у меня optimistic locking сейчас применяется, в общем-то параллельная запись в один документ в моём случае - довольно редкий кейс, но не учитывать его всё равно нельзя
Напиши один раз расширение для драйвера/одм и пользуй везде, где надо
Eugene [MSK+3]
Всем привет, подскажите пожалуйста.
Вопрос заключается в обновлении документов с уникальными ключами (по ним идет поиск). Возможно ли составить один запрос в БД, чтобы обновить сразу несколько таких документов.
К примеру, у меня есть документы с уникальными ключами: "первый", "второй", "третий", "etc"...
Мне необходимо за один запрос обновить документы с ключами "первый" и "третий", причем каждому документу я хочу задать свое значение. Или как такого рода изменения вносятся в mongoDB? Не буду же я отправлять тысячу запросов на обновление каждого отдельного документа. Или буду? :(
yopp
Буду, да
yopp
Как иначе
eshch
не ну там есть предложения в доке монги как сделать транзакцию своими руками
yopp
Не про транзакцию вопрос
eshch
ну если сразу - это не атомарность, то там есть же балк врайт
yopp
Всем привет, подскажите пожалуйста.
Вопрос заключается в обновлении документов с уникальными ключами (по ним идет поиск). Возможно ли составить один запрос в БД, чтобы обновить сразу несколько таких документов.
К примеру, у меня есть документы с уникальными ключами: "первый", "второй", "третий", "etc"...
Мне необходимо за один запрос обновить документы с ключами "первый" и "третий", причем каждому документу я хочу задать свое значение. Или как такого рода изменения вносятся в mongoDB? Не буду же я отправлять тысячу запросов на обновление каждого отдельного документа. Или буду? :(
Так или иначе, даже когда обновляется много документов через один update запрос, они все обновляются по одному.
yopp
Если хочется экономить на round trip, то как сказали выше — bulk
Eugene [MSK+3]
Спасибо за ответы, я расстроен :(
😊
yopp
Чем?
yopp
не ну там есть предложения в доке монги как сделать транзакцию своими руками
Делать транзакции в монге кажется хорошей идей до первой попытки их реально сделать.
yopp
После первой попытки быстро просветляешься и начинаешь мыслить категориями без транзакций
yopp
Например индемпотентными операциями
Eugene [MSK+3]
Я новичок в области бд, пока не понимаю о чем ты говоришь)
Буду читать, спасибо
yopp
А я завтра опять в питере
yopp
Буду после 16:00 или может даже раньше свободен
yopp
Отчаливаю в 23 из Пулково, так что гдет в 21 с московской буду стартовать
eshch
Я новичок в области бд, пока не понимаю о чем ты говоришь)
Буду читать, спасибо
новичка все должно тока радовать
Anonymous
Насколько быстро Mongo работает с геокоординатами? Может быть, индексировать лучше в эластике?
yopp
Насколько быстро Mongo работает с геокоординатами? Может быть, индексировать лучше в эластике?
Лучший способ понять — протестировать на вашем датасете.
Alexander
а для YMaps как лучше хранить данные в монге, просто массивом координат или же есть извращенные методы? )
yopp
@freeseacher @dezconnect пипец у вас тут погодка!
Alex
Опять Питер ?
Alex
Ну не май месяц
Alex
:)
Старый
Alex
Не
Alex
Обычно еще капает
Alex
:)
yopp
Лучше бы капало
Alex
Ледяные дожди явление так себе
Alex
Пусть лучше так :)
Danil
yopp
Можем часов в 7 где-то в районе московской посидеть
Alex
Хм
Alex
Я в 7 на московских воротах освобожусь
Alex
Подходит
SvPupok
коллеги,а как можно определить средний размер ключа шардирования?
eshch
пройтись агрегацией и посчитать?
SvPupok
не уверен что это сработает корректно в шардированной коллекции.
eshch
а ты попробуй пока
SvPupok
An existing collection can only be sharded if its size does not exceed specific limits. These limits can be estimated based on the average size of all shard key values, and the configured chunk size.
SvPupok
а вообще, интересен размер коллекции в пределах одной шарды, я пока не могу найти каких то лимитов.
Nick
это говорит о том, что прежде чем начинать шардирвоать нужно проанализировать свой ключ шардирвоания, а не постфактум после настроенного шардирвоания
Nick
а вообще, интересен размер коллекции в пределах одной шарды, я пока не могу найти каких то лимитов.
Размер коллекции по шардам можно глянуть
db.getCollection('XXXX').getShardDistribution()
Nick
там же будет информация о среднемразмере чанка на каждом шарде
SvPupok
это говорит о том, что прежде чем начинать шардирвоать нужно проанализировать свой ключ шардирвоания, а не постфактум после настроенного шардирвоания
я полностью согласен. у меня пока операция шардирования только предстоит. поэтому я хочу провести предварительный анализ.
yopp
Какой размер коллекции?
SvPupok
Размер коллекции по шардам можно глянуть
db.getCollection('XXXX').getShardDistribution()
это тоже понятно, официальная документация говорит, что после успешной операции шардирования, у коллекции нет верхнего предела по размеру. Меня интересует, есть ли лимит по обьему в пределах одной шарды.
yopp
yopp
870 Гб
Проблема может возникнуть если у вас ключи будут в среднем ближе к 1024 байтам. Но этого можно избежать подняв размер чанка до 256 мб
Nick
разве 1024? A shard key cannot exceed 512 bytes.
yopp
И вернув его на 64 после завершения первоначального шаржированная
yopp
Это я с index key size перепутал значит
yopp
Ну тогда вообще проблем нет