да есть проблема, у меня нет подходящего поля, которое было бы не монотонное

а что за данные?

агрегаты по докам, у доков есть id источника, нужно считать параметры по содержимому дков и делат ьпочасовые агрегаты, а по часовым суточные

причем треубется хранение

т.к. эти даныне отсылаются в некий сервис, и нужно фиксирвоать факт доставки илбо ошибки и перепосылать

короч, нужно гдето хранить состояние, вот и пришлось заюзать монгу, т.к. доки и так монге хранятся

в результате у меня у агрегата составной id : {docId,year,month,day,hour, type}

у type 10 занчений фиксированных, так что я первоначально сделал шард индекс над hashed _id_docIDd

ужас какой

я бы пересмотрел логику

думаю этим и займусь.

хранить данные надо так, как ты их потом достаёшь

т.е. идти от запросов

Люди а киньте ссыль на русскую книжку по сабжу плз, начальный уровень.

http://www.pvsm.ru/download/mongodb-ru.pdf

http://www.pvsm.ru/download/mongodb-ru.pdf

Огромное спасибо.

резисты должны помогать друг другу (:

Latest: 3.4.3 (Mar 28, 2017), Stable: 3.2.12 (Feb 1, 2017) 3.4.3: https://docs.mongodb.com/manual/release-notes/3.4/#mar-28-2017 3.2.12: https://docs.mongodb.com/manual/release-notes/3.2/#feb-1-2017 Пришло время обновлятся до 3.4.1+: https://aphyr.com/posts/338-jepsen-mongodb-3-4-0-rc3

Это, никто не хочет написать нативный монговский драйвер для crystal?

Есть возможность изучить новый язык и глубоко изучить протокол монги. Там ничего в целом сложного, но куча мороки

Не биндинги, имено нативный

Я даже готов проспонсировать!

Можно вообще взять и попробовать рубишную версию портировать.

По-моему кроме тебя на Crystal никто не пишет

нормально ли делить один replica set между разными микросервисами?

У кого нет звонков в ТГ?

не тематичненко. велкам с таким вопросами на талк каналы. благо они есть на любой вкус.

возможно ктото вкурсе но при апдейте одного поля в документе перезаписывается весь док? а при добавлении длинного поля? и где грань, если она есть

возможно ктото вкурсе но при апдейте одного поля в документе перезаписывается весь док? а при добавлении длинного поля? и где грань, если она есть

Зачем тебе это?

понять на сколько дорого обновление полей

понять на сколько дорого обновление полей

зачем?

возможно ктото вкурсе но при апдейте одного поля в документе перезаписывается весь док? а при добавлении длинного поля? и где грань, если она есть

Там по-моему аппендится новая версия поля. Не ?

ну интересно мне понять какого рода работа происходит на уровне хранения документа, происходит ли перед этим полная вычитка документа, его изменение, и сохранение измененной верси

Там по-моему аппендится новая версия поля. Не ?

хотелось бы линк на доку, а то чтот не нашел

ну интересно мне понять какого рода работа происходит на уровне хранения документа, происходит ли перед этим полная вычитка документа, его изменение, и сохранение измененной верси

зачем?

это детали реализации хранилища. их как минимум два

тогда WT, причина в попытках меньше жрать диска

ну вот что мешало с этого и начать-то?

только сейчас мне не от чего оттталкиваться

последняя вещь от которой надо отталкивать — реализация хранения

для этог ои нужно хотя бы понять как идет работа с документом на низком уровне

оно тебе не надо, ты спать плохо будешь

не нужно

ты уже знаешь что именно упирается в диск?

я знаю, что выжираю диск, а производительность недостаточно большая

при использовании индексов

как ты это выяснил?

почкему у тебя индексы на диске?

индексы в памяти, но они не помогают, т.к. у меня обновление данных это 25% запросов по куче документов за раз, 25% обновлений по id, гдето 10% инсертов, остальное агрегация на мапредьсах. и все это задыхается на 2 шардах над двумя 10ми рейдами

и мне нужно понять какого рода операции делаются во время апдейтов

ибо это считай 80% моих запросов с учетом мержа от мап редьюса

ох

природа данных документная, поэтому не реляционки

ты сейчас пытаешься диагностировать простуду через колоноскопию

возможно, но это не отменяет факта, что я до сих пор не знаю как происходит апдейт документа

я на 97% уверен что тебе надо не в кишках ковырятся, а взять в руки explain и настроить нормальный монтиоринг, чтоб понять _что именно_ и _когда_ и _как_ выжирает диск

тебе не надо этого знать

сейчас у тебя недостаточно улик, чтоб точно сказать что является причиной

эксплейн мне говорит что норм индексы юзаются

окей, у тебя slowquery анализируется?

что он тебе говорит?

«это задыхается на 2 шардах». как именно задыхается?

«выжирает диск»: тикетов нормальное количество или не хватает? из чего рейд? чего не хватает чтения или записи?

да, анализируются, сейчас ничего не пишет

какой трешхолд стоит?

100мс дефолтный

что знаичит «задыхается»?

задыхается - это субъективно через nmon 100% busy рейт

👍

«выжирает диск»: тикетов нормальное количество или не хватает? из чего рейд? чего не хватает чтения или записи?

Тикеты вроде тока для ссд актуальны не ?

тикеты это система ограничения количества одновременных запросов к хранилищу

оно актуально для любого типа хранилища

На тему апдейта по-моему он инплейс апдейт делает с новой версией поля. Для того и пэддмнг фактор задирали. Или у меня инсульт

нет padding в wt

и никогда не было

оно актуально для любого типа хранилища

Обычные диски раньше дохнут чем дефолтные значения. Не ?

padding нужен был для того чтоб монга не искала куда записать документ, когда после обновления он стал больше чем был. и это было в mmapv1

т.е. это запас по размеру

монга не kv сторадж, документ, я напоминаю, это просто блоб bson

You do not have to worry about document movement, padding etc. with WiredTiger. New writes initially get written to files in unused regions and then incorporated in with the rest of the data in the background later. WiredTiger, during an update, will actually write a new version of documents rather than overriding existing data the way a mmapv1 does in many cases. (Check the video from MongodDB free online courses)