yopp
Теперь представь, что в системе с точным времени сделан выбор в сторону A, иначе просто смысла система не имеет
yopp
Надо уже собраться с силами (или забухать с математиками) и нормально доказать CAP.
tenni
или просто привести аналогию с сетями
Sergey
Viktor
Я не знаю всех специфик монги в плане времени, делал только синхронизацию апликейшен нод, там разница около 100мсек максимум была
Viktor
Потому что было критическим иметь "одинаковое" время на серверах
yopp
yopp
tenni
он хорошо исследует, топчик
P&P
tenni
человек наверное чатиком ошибся и забыл удалить свой бред =\
yopp
Ладно, шутка про время не прошла.
Для получений лага надо знать значение верха оплога у мастера. Это сетевая немоментальная операция. Пока мы это значение по сети получали, оно на нагружённой системе уже изменилось и более того, в локальный оплог уже что-то реплицировалось.
Мы получили значение верха X, тогда как локально у нас уже X+1
yopp
Доберусь до ноута, посмотрю исходник. Скорее всего если там поменять местами выбор таймштампов, не будет больше отрицательных значений.
Viktor
yopp
Чукча читатель.
Viktor
я бы посмотрел как сделана синхронизация времени там
yopp
Там нет синхронизации времени лайк вообще
yopp
Время локальное
Viktor
тьфу, Ntp же отдельная штука, затупил
yopp
Но можно поменять таймштампы и гордо назваться контрибьютором!
yopp
мои глаза: https://github.com/mongodb/mongo/blob/009fdc7dfcc0197632cef5e3fdc250fdba68f7a5/src/mongo/shell/db.js#L1139
yopp
(на самом деле можно просто модуль взять)
yopp
кстати, отрицательное значение ещё может быть потому, что мастера нет, а на текущей ноде самый свежий оплог из всех других
yopp
// no primary, find the most recent op among all members
yopp
но конечно делать локальную переменную внутри метода, а потом внутри скоупа метода делать ещё методы, которые используют локальную перменную из вышестоящего скоупа — мудачество
yopp
https://github.com/mongodb/mongo/commit/40708e54a41f833933d748383d563cf7c9092744#diff-64a2d155839cfac6cad947271e07f2e3
yopp
https://github.com/dannenberg плохой человек!
P&P
коллеги, чем в монго регулируется максимальное кол-во ресурсов (незнаю как корректно назвать) per client? вообще есть такое или один клиент может затролить базу запросами?
Anonymous
yopp
yopp
Можно только права почикать
CC-BY-SA-4.0/Docker-ce30.0
Сигруппами может что подрулить?
P&P
Timur
Всем привет, столкнулся с проблемой: есть документ с вложенными документами. Вложенные документы – объекты в массиве родительского документа. Можно ли как-то с помощью findOneAndUpdate, зная _id вложенного документа, обновить у него (вложенного) несколько полей за один запрос?
yopp
Timur
@dd_bb спасибо! Вот ссылка, если кому интересено: https://docs.mongodb.com/v3.4/reference/operator/update/positional/
yopp
https://docs.mongodb.com/manual/reference/operator/update-array/
yopp
тудаже
Anatoliy Skuratov
Всем привет
Anatoliy Skuratov
Возможно ли в монге сделать следующеe: У меня есть колекция в каждом документе есть массив, число элементов в массиве разное. Можно ли сделать такой запрос, который выдернит столько документов, чтобы общее число элементов в массивах было неменьше N
Viktor
Anatoliy Skuratov
Спасибо, сейчас гляну)
Sergey
Sergey
Можно без aggregation
yopp
yopp
А, сорян не увидел что «не меньше». Тогда да,проверять наличие N элемента.
yopp
Сеты это что? Массивы?
Timur
да, но значения не могут повторяться
Timur
в пределах этого сета
yopp
uniq в пределах массива через индекс добиться нельзя, единственный вариант $addToSet. Делать индекс по массиву никто не запрещает. Число ключей в индексе будет эквивалентно сумарному числу значений во всех масивах
P&P
кстати, обнаружил такую вещь, если к MongoDB обращаться в огромном кол-ве паралельных запросов из приложухи к какой то коллекции, то монго (видимо) думает, что данная коллекция весьма популярна и ... начинает активно её кэшить, т.е. флудинг монго улучшает темпы скачки данных из неё (у меня задача - максимально быстро качнуть из монги некий набор данных ).
P&P
Может ли кто то подтвердить гипотезу?
Max
Может не монга думает, а операционка и ее дисковый кеш?
Daniel
у монги и свой кеш есть
Daniel
особенно он актуален, если не весь индекс влез в память
Daniel
(ии я путаю, и у монги индекс всегда в памяти?)
Max
А если индекс больше Памяти?
Sergey
не стоит вскрывать эту тему
John
John
You gonna have a bad time
Max
На диск вылезет
Он там изначально лежит :)
Речь была про кеш, а точнее - скорость доступа к частозапрашиваемым данным
John
yopp
кстати, обнаружил такую вещь, если к MongoDB обращаться в огромном кол-ве паралельных запросов из приложухи к какой то коллекции, то монго (видимо) думает, что данная коллекция весьма популярна и ... начинает активно её кэшить, т.е. флудинг монго улучшает темпы скачки данных из неё (у меня задача - максимально быстро качнуть из монги некий набор данных ).
У WT есть свой кеш, который может использоваться для хранения страниц с данными об индексах или о непосредственно bson. Те страницы которые используются чаще, будут оставаться в кеше. В этом кеше страницы хранятся без компрессии, так как кеш долен оспечеивать минимальное время доступа для очень горячих данных.
Компрессия (если включена) происходит в момент когда WT сбрасывает страницы из кеша на диск. Но так как в современных ОС есть ещё и дисковый кеш, под который обычно выделяется вся «свободная» память, то дисковый кеш можно рассматривать как второй уровень кеширования, но уже с компрессированными данными.
yopp
Монга старается приоритезировать индексы над данными, но если индекс весь не влазит, но запросы к индексу ездят по примерно одном путям в дереве, то в кеше будет только активные старинцы индекса.
Но любой проезд по другому пути в дереве приведёт к тому, что за страицами хранящими нужную ветвь в дереве придётся несколько раз сходить на диск. А это делает индекс бесполезным.
yopp
Чтоб понимать почему ходить на диск плохо, есть вот такая отличная картинка про время доступа к различным ресурсам
yopp
Sergey
какая-то ужасно ненаглядная попытка визуализировать это: https://gist.githubusercontent.com/jboner/2841832/raw/latency.txt
yopp
ты не поверишь, там даже ссылка внизу на этот гист
yopp
про ненаглядность согласен
yopp
но по крайней мере общий масштаб понятнет
Max
в гисте даже ссылка на эту "ужасно ненаглядную попытку" :)
Вообще круто, спасибо за расшаривание
Sergey
это надо было линейно рисовать, потому что из-за двухмерности теряется реальный масштаб
yopp
линейно?
Viktor
на одной оси, видимо
yopp
Stable: 3.4.7 (Aug 8, 2017), Bugfix: 3.2.16 (Jul 27, 2017)
3.4.7: https://docs.mongodb.com/manual/release-notes/3.4/#aug-8-2017
3.2.16: https://docs.mongodb.com/manual/release-notes/3.2/#jul-27-2017
Пришло время обновляться до 3.4.1+: https://aphyr.com/posts/338-jepsen-mongodb-3-4-0-rc3