
yopp
23.11.2016
09:06:51
в смысле, в wt такого же нет уже
в mmap да, было дело

Nick
23.11.2016
09:22:54
кстати а ктонибудь использует монгу в докере? интересует как она переживает перезапуск контейнера

Google

yopp
23.11.2016
09:29:29
причём тут монга ваще
если у тебя с хоста в монгу смонтирован раздел, то пускай контейнер сколько хочешь

Nick
23.11.2016
09:30:08
там же часть в памяти, а докер любит убивать процессы без предупреждений
тем более прочитал, что монга работает через смаплленные в память файлы. Вот инетересно как они переживают. Хотя может чего не знаю

yopp
23.11.2016
09:49:22
читай лучше
первый, очевидно, использовал mmap
потому что «убить процесс» можно сильно по разному
от этого будет зависеть то, что случится дальше, и это касается вообще любой субд
плюс «докер любит убивать процессы без предупреждений». Докер сам по себе ничего не любит
докеру вообще насрать что там внутри контейнера происходит
если кто-то не скажет докеру остановить контейнер, он самостоятельно тушить его не будет

Google

yopp
23.11.2016
09:54:52
«кто-то» может быть системой орекстрации или мясная прокладка
ну и ещё операционная система

ptchol
23.11.2016
10:42:25

Pavel
26.11.2016
20:51:03
доброй ночи!
будет круто, если кто-нибудь из питерских пройдет опрос по поводу вашей работы в качестве IT-спецов. Провожу исследование)
https://docs.google.com/forms/d/e/1FAIpQLSeoG6ByaJD1Q4RqOESUoOP6qDggjukoQ3wokPaXJSlqCt09IQ/viewform

Dmitry
26.11.2016
20:57:43
@lig11 дай прав?

Serge
27.11.2016
12:38:57

Nadya
28.11.2016
09:21:12
Добрый день! Господа, простите за оффтоп, есть вакансия для специалистов по mongoDB, в Санкт-Петербурге. Если вы в поиске, или просто захотите узнать подробности, прошу пишите в лс. P.S. Linux на уровне advanced.

Pavel
28.11.2016
14:35:04
насколько тяжелая операция реконнекта в монге? слышал, что в sql это одна из самых тяжелых операций для бд, в монге это так же?

yopp
28.11.2016
14:54:14
Транзакций то нет

Pavel
28.11.2016
14:55:40

Sergey
28.11.2016
14:56:21
так транзакция не на соединение же создается

Egor
28.11.2016
17:06:19
Кстати, кому интересно, подписывайтесь на группу о MySQL : @mysql_ru

yopp
28.11.2016
17:10:00
Но я не уверен совершенно.
Как и не уверен что это для любых sql баз является проблемой.

Serge
28.11.2016
17:52:42

Nadya
28.11.2016
19:30:14

Igor
28.11.2016
22:00:53
сначала специалист по монге, теперь девопс

Egor
28.11.2016
22:14:41
А потом окажется, что она никакая не Надя, а самый обычный Игорь

Google

Serge
29.11.2016
05:59:08

Nadya
29.11.2016
08:01:29

Danil
29.11.2016
08:10:53
"скорее всего" носит вероятностную оценку, т.о. получается что Надя, не совсем уверена в том, что она Надя.

yopp
29.11.2016
08:20:17
Квантовые эффекты, не обращай внимания.

Aleksandr
29.11.2016
09:53:52
Надя, не стоит вскрывать эту тему. Вы молодые, шутливые, вам все легко. Это не то. Это не Чикатило и даже не архивы спецслужб. Сюда лучше не лезть. Серьезно, любой из вас будет жалеть. Лучше закройте тему и забудьте что тут писалось. Я вполне понимаю что данным сообщением вызову дополнительный интерес, но хочу сразу предостеречь пытливых - стоп. Остальные просто не найдут.

Serge
29.11.2016
09:58:19
А если там нет, то зачем оно тут?


Aleksandr
29.11.2016
10:05:17
А если там нет, то зачем оно тут?
Написал hello world и калькулятор, — вот и молодец. На этом стоп. Не стоит вскрывать эти конпеляторы и гитхабы. Это тебе не колидоры вычистлительных центров НАСА, даже не датацентры ГУГОЛ, не уютненькие офисы ФЕЙСБУКА. В сферу IT лучше не лезть. Серьезно, любой из вас будет жалеть. Лучше закройте Хабрахабр и забудьте, что тут писалось. Это все вранье, чтобы привлечь как можно больше новых макак на рабочие места и создать демпинг зарплат. Я вполне понимаю, что данным сообщением вызову дополнительный интерес у воротил из Cisco, SAP и IBM, но хочу сразу предостеречь пытливых — стоп. Зарплаты у IT-шников очень унылые. Остальным их просто не дают.

Nick
29.11.2016
10:45:54

yopp
29.11.2016
10:46:23
Мы это уже проходили, нет официальной ссылочки.
Можно посмотреть на развитие MR и на развитие AF, для того чтоб сделать выводы о том, какой из двух инструментов разивается, а какой нет.

Nick
29.11.2016
10:49:19
спасибо за ответ

[Anonymous]
29.11.2016
17:03:44
Ух.
Сегодня же вышла MongoDB 3.4!

yopp
29.11.2016
17:10:03
Разве?

Sergey
29.11.2016
17:10:57
да
https://docs.mongodb.com/master/release-notes/3.4/
Released Nov 29, 2016
ну... подождём пару патчей и можно щупать =)

yopp
29.11.2016
22:10:20
Бля.

Google

yopp
29.11.2016
22:10:25
Печаль.
Я чот думал они в декабре выпустят. Придётся изучать сейчас. :(

Sergey
29.11.2016
22:14:53
Они там новый курс запилили в юниверсити
M034

[Anonymous]
30.11.2016
00:35:34
Обновил один из серверов (который сейчас на standalone, т.е. наименее рискованно) до 3.4. Всё ОК ?
Да и быстрее стало работать, но возможно, это плацебо.

yopp
30.11.2016
15:05:06

[Anonymous]
01.12.2016
02:13:46
Оказалось, не плацебо, по замерам есть прирост производительности в районе 10-15%. Это касается больших агрегаций.

Алексей
02.12.2016
05:34:18
господа а где mongoreplay брать ?
билдить короче.
https://github.com/mongodb/mongo-tools
build.sh
с 3,2 выглядит будто работает

Sergey
02.12.2016
07:38:41
Ого, монговские тулзы на Golang написаны. Тогда понятно, почему они так плохо с ipv6 работают
И что этот стикер значит в данном контексте?

Nikolay добряш
02.12.2016
09:51:01
Но только в данном контексте не более

yopp
02.12.2016
11:18:58

Sergey
02.12.2016
11:29:44
А кто как консистентность данных в условиях отстутсвия транзакции обеспечивает?
Ну то есть вот я прочиал из базы некоторые данные (один документ), изменил их и хочу записать обратно, но при этом их кто-то еще параллельно мог изменить.
В голову приходит два варианта:
1. В update в условии класть полностью весь документ (или часть, которая может быть изменена параллельным запросом)
2. Хранить в отдельном поле update счётчик в виде инкремента/даты/objid и при update указывать его в условии (и обновлять, соответственно)
3. ... ?
речь про один документ, конечно же, не про несколько

Google

yopp
02.12.2016
11:32:26
Второе называется optimistic locking.
Зависит от требований к данным.
Первое не эффективно.

Sergey
02.12.2016
11:33:19
первое дорого слишком, это понятно

yopp
02.12.2016
11:34:12
Надо начать с вопроса почему так случилось и что мы будем делать если документ обновили.

Sergey
02.12.2016
11:34:31
выдавать ошибку или ретраить этот вопрос уже бекенд будет разруливать

yopp
02.12.2016
11:34:40
(Так случилось что нам нужно знать что документ не менялся)

Sergey
02.12.2016
11:36:02
потому что мы живём в многопоточном мире)
в идеале - всё должно обновляться атомарным апдейтом, но вот обновить два разных элемента в массиве им уже не получится
условно
{
_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 в массиве, не трогая остальные
за то время пока мы считали данные, изменили в памяти и пытаемся записать их обратно кто-то другой мог содержимое массива изменить

GNU/Docker
02.12.2016
11:47:49
with lock

Sergey
02.12.2016
12:01:15