прикольно

потому что для сборки метрик с хоста всегда есть --privileged или --device

а для выгребания метрик из контейнеров три ведра решений

/me

Упс, тыкнулось случайно, извиняйте

Как можно ускорить update_one? Работает намного медленнее, чем insert_many(ordered=False)

Всего около 100 итераций в секунду с обновлением

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

Однажды получилось ускорить этот процесс до 7000 итераций в секунду, но я не знаю что сделал тогда. Монга как-то разогрелась.

Как можно ускорить update_one? Работает намного медленнее, чем insert_many(ordered=False)

Бампер вопрос, тоже интересно

а зачем отказываться от insert_many?

а, update_one лол

Потому что обновление и вставка две разные операции)

ну bulk_operations

там вроде копит по 1к операций и выполняет за раз

у меня upsert ы так работают

Насколько я помню, у меня просто тогда было 1 итерация за 10 секунд

Как раз по 1000

initialize_unordered_bulk_op

у тебя на чем код?

А вот unordered не делал вроде

если питон то вот initialize_unordered_bulk_op

У меня pymongo

и туда пишешь что хочешь, хочешь апдейты, хочет что угодно

ну вот

как раз оттуда

у меня тоже )

http://api.mongodb.com/python/current/examples/bulk.html

Но почему тогда он как-то сам мог разогнаться?) Я замечаю, что монга требует разогрева, первая операция всегда дольше последующих

Хотя занимает 50% озу для кэша

к примеру bulk = db.test.initialize_unordered_bulk_op() bulk.find({'_id': 4}).upsert().update({'$inc': {'j': 1}}) потом после того как накопил сколько нужно операций >>> try: ... bulk.execute() ... except BulkWriteError as bwe: ... pprint(bwe.details)

Но почему тогда он как-то сам мог разогнаться?) Я замечаю, что монга требует разогрева, первая операция всегда дольше последующих

хз, я не делал особых замеров, по докам если хочешь ускорить кучу операций - делай unordered bulk operations :)

Но insert_many на bulk работает

по поводу скорости наверняка прогревается

но все-равно unordered bulk будет быстрее имхо

я так понял оно все кеширует в памяти, потом по 1к скармливает монге и та уже как-то параллельно пишет, сама разбирается как ей лучше

@dd_bb подскажи пожалуйста, а если у меня будет 2 secondary ноды, и я укажу приоритет на чтение с secondary - оно будет напрягать ноды равномерно?

От клиента зависит

update конечно медленнее чем insert.

Для update сначала find надо сделать

Ну да, кстати, индексы же ускорят этот процесс

Другое дело, что конкретно я в query писал _id, а такой индекс по дефолту есть

И кстати, как обновлять индексы на WiredTiger? Слышал что раньше на mmap он сам обновлял. Сейчас нужно RebaseIndexes или что-то такое?

эм

ускоряют, но не исключают. операция чтения — дорогая операция в любом случае. вставка существенно дешевле. индексы автоматически обновляются вместе с данными, иначе в них никакого смысла нет. ничего для этого делать не надо

Почему чтение дороже вставки?

Запись на диск всегда дороже чтения с него, разве нет?

Нет

поиск же

Почему?

Во-первых, запись в монгу нельзя сравнивать с сырым дисковым io

Как и чтение.

За счёт wired Tiger?

Это гораздо более сложный и затратный процесс, который в себя включает огромное число операций.

Есть что читнуть по теме

?

Исходники монги?

strace?

Доку по архитектуре wt?

Во-вторых, чтение в монге это сложная операция, так как она происходит в несколько стадий. В лучшем случае это index fetch и document fetch.

В случае с записью в лучшем случае это index fetch (_id duplicate check) + index insert + document insert.

Если брать холодный сторадж, то запись будет быстрее, так как она не требует поиска данных.

В общем случае в вакууме. В реальности всё гораздо сложнее, так как есть множество уровней кешировния.

А простые операции чтения или обновления документов, где всё ограничивается index fetch крайне редкое явление.

Но в среднем когда мы вставляем документ, необходимо сделать fetch и несколько update в индексы и один insert в document storage. Что будет сильно проще чем update, в котором обычно есть условия.

А это уже многоуровневая операция, обычно со сканированием индексов. А это уже другие порядки

Но вообще, исходя из постановки, задача выглядит как предварительная оптимизация. Смысла мерять сколько можно вставить документов в монгу из вашего драйвера — нет.

Где хранится индекс на шардированной коллекции, если в нем нет префикса из шард ключа?

В шарде индексы всегда хранятся на самом шарде.

@dd_bb развернутый ответ, спасибо

Так что ответ: на самом шарде.

Эм, при записи всё равно будет fsync делаться, почему она бустрее чтения должна быть?

Разница межу использованием запроса с указанием shard key и без, только в том, что в первом случае планировщик исходя из данных о диапазонов шард-ключей будет знать на какой конкретный шард отправить запрос. В случае если ключа нет, запрос будет отправлен на все шарды

Эм, при записи всё равно будет fsync делаться, почему она бустрее чтения должна быть?

С чего вдруг

Ок, спасибо. Про сами запросы итак понятно

Шард это просто кусок коллекции.

С чего вдруг

Ну ок, только при "j: true"

хотя, я бы не рискнул писать без этой опции

Я бы вообще предложил не обсуждать что быстрее или медленнее в отрыве от конкретного кейса и конкретных данных.

Потому что ответ: ¯\_(ツ)_/¯ или как повезёт