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

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

что в 99% случаев приведёт к пиздецу неизвестной продолжительности

хорошо. звучит убедительно.

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

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

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

что такое роллинг индекс?

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

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

background займёт дольше

потому что там алгоритм другой

я перефразирую: так сделали чтоб народ не стрелял себе в коленку

(хотя я всё ещё не понимаю почему у курсоров по-умолчанию таймаута нет)

https://github.com/mongodb/mongo/blob/584ca76de9ee66b3e11987e640f5317ae40975e4/src/mongo/db/index_builder.h#L46

если ещё проще: создание индекса ебически дорогая операция с точки зрения cpu и io. ты должен думать головой перед тем как строить индекс, иначе ты почти гарантированно наебнёшь кластер

https://github.com/mongodb/mongo/blob/584ca76de9ee66b3e11987e640f5317ae40975e4/src/mongo/db/index_builder.h#L46

м?

https://github.com/mongodb/mongo/blob/72408d7f852058088e1446f77cbea06c029df133/src/mongo/db/catalog/index_create.h#L71

as there is no concurrency benefit to building a subset of * indexes in the background, but there is a performance benefit to building all in the * foreground. */

but there is a performance benefit to building all in the foreground.

ну

но

foreground 2017-04-02T13:13:23.421+0300 using default 'dump' directory 2017-04-02T14:18:49.055+0300 done background 2017-04-02T14:20:47.295+0300 using default 'dump' directory 2017-04-02T15:13:51.539+0300 done

второе получено из первого путем for f in *.json.gz; do cp "$f" "$f~" && gzip -cd "$f~" | sed 's/"background":false/"background":true/g' | gzip > "$f" done

это всё конечно замечательно. но какую проблему ты пытаешься решить?

лишь понять зачем так

because reasons

так себе ответ

я тебе выше уже аргументы дал

да дал. и комменты в коде говорят что нет бенефита.

на незагруженной базе, коненчо разница будет на уровне статистической прогрешности. bg будет немного медленее fg (там иначе данные из хранилища достаются)

но я от чегото вижу этот бенефит

потому что твой тест говно :)

даже не спорю

это очередная попытка урановых коней в ртути топить

мой тест говно и я не против.

но в где он гавно не понятно

аргументы про управляемость нагрузки понятны.

потому что условия и методология тестирования не определены, датасет неизвестен

а самое главное: я всё ещё не понимаю зачем ты топишь за bg индексы

потому что в практике bg индексы работают до момента пока у нас датасет вместе с индексами в память влазит

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

но если у тебя есть шарженная коллекция, на пару террабайт, надо быть экстремалом чтоб сделать индекс с bg

вообще в жирном шарженом кластере с индексами всё очень печально, долго и муторно

потому что в практике bg индексы работают до момента пока у нас датасет вместе с индексами в память влазит

есть что почитать ?

что почитать-то?

про влазят в память

откуда такое ограничение

из фон неймановской архитектуры, блин

строительство индекса == прочитай весь датасет

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

парни из монги тоже рекомендуют роллинг https://docs.mongodb.com/manual/tutorial/build-indexes-on-replica-sets/#index-building-replica-sets

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

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

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

это логично.

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

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

да, это все надо сделать на ноде которая * предварительно была выведена из сета * перезапущена, тоесть лучшее что у нее есть это page cache * не имеет другой нагрузки кроме построения индекса.

да

тоесть рид на весь сторадж нам _гарантирован_

в этом случае доступные ресурсы будут потрачены наиболее эффективным образом

так как мы контролируем выведение, мы знаем об влияние наших действий на кластер

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

ок. @dd_bb спасибо.

это. я никак не могу решить на чём делать клиента для эспортера

пайтон

или гошка

у него те-же проблемы с портабельностью что и у руби

го — пиздец

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

не, не взлетит

чой то ?

надо бинарник

ну вот докер это и есть бинарник, пакетный менеджер

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

ой, а сейчас нельзя да ?

черт :(

а под портабельностью ты наверное имеешь в виду для арма да ?

или соляра ?

я имею ввиду self-contained binary, который не требует ничего не целевой системе

тогда гошка

скачал и сказал ./mybin