yopp
Т.е. планировщик не сможет заранее оптимизировать диапазон просматриваемых ключей, потому что из запроса это сделать невозможно. А значит планировщик просто будет перебирать все данные в индексе. Там скоре всего в executionStats будут большие циферки в totalKeysExamined.
yopp
Это лучше чем collscan, но тоже плохо.
Maksim
а тут вопросы, связанные с mongoose задавать можно?
Canyon
Всем привет
Подскажите утилитку для графического моделирования коллекций и связей по полям между ними. Желательно так что можно было показывать менеджерам и начальству :-)
Naniwa
может это подойдет https://robomongo.org/
SvPupok
Коллеги, а есть какой нить вменяемый гуй, кроме 3t studio, а то они с последним обновлением совсем скурвились.
Igor
Коллеги, а есть какой нить вменяемый гуй, кроме 3t studio, а то они с последним обновлением совсем скурвились.
вот тож интересно. Чет прям няшного гуя не изобрели пока что
SvPupok
Меня просто совсем выморозила блокировка списка сессий, и возможность пользоваться только тремя коннектами в фряшной версии. Я попробовал mongobuster но он мне не очень понравился, так как все таки web-овый клиент
Ilya
Ребята, а если надо вставлять документы пачками, но в коллекции могут уже эти данные быть, и во вставляемых данных нет параметра _id из монги, но есть другая уникальная пара параметров.
То правильно ли я понимаю что правильнее сначала грохнуть существующие которые отфильтровать по этим уникальным свойствам - а потом производить вставку?
Igor
Ребята, а если надо вставлять документы пачками, но в коллекции могут уже эти данные быть, и во вставляемых данных нет параметра _id из монги, но есть другая уникальная пара параметров.
То правильно ли я понимаю что правильнее сначала грохнуть существующие которые отфильтровать по этим уникальным свойствам - а потом производить вставку?
По сути да. Но если вставляемые данные идентичны с имеющимися, то накой вставлять по новой?
Ilya
ну там может быть новые документы, а в старых могут быть изменения, и надо как бы синхронизировать монгу с этим
Igor
ну там может быть новые документы, а в старых могут быть изменения, и надо как бы синхронизировать монгу с этим
Если у тебя есть свой UID то по нему FindOneAndRemove
Igor
Igor
ну там может быть новые документы, а в старых могут быть изменения, и надо как бы синхронизировать монгу с этим
В update вроде точные поля нужно называть какие нужно обновить. Но надо доку поднять. Могу ошибаться и можно по UID твоему найти и все update нуть сразу
Ilya
ну если для каждого документа далать отдельный запрос это долго, надо массовые операции, допустим грохнуть массово и массово вставить - так будет быстро
yopp
Ребята, а если надо вставлять документы пачками, но в коллекции могут уже эти данные быть, и во вставляемых данных нет параметра _id из монги, но есть другая уникальная пара параметров.
То правильно ли я понимаю что правильнее сначала грохнуть существующие которые отфильтровать по этим уникальным свойствам - а потом производить вставку?
Нужно определиться со стратегией в случае дублирования данных.
yopp
Igor
ну если для каждого документа далать отдельный запрос это долго, надо массовые операции, допустим грохнуть массово и массово вставить - так будет быстро
Чтобы массово грохнуть, тебе нужно обойти свой массив, отобрать все UID которые будешь грохать, найти их в базе, грохнуть и заливать новый данные. И чет я вижу гавнокод в своих мыслях. Имхо так делать - не бэст практикс
Ilya
ну а делать по каждому документу файнд и потом апсерт - это типа лучше?
yopp
ну а делать по каждому документу файнд и потом апсерт - это типа лучше?
Вам в итоге что с дублирующимеся документами сделать надо?
Ilya
должен остаться тот который в новом списке
Ilya
монговский должен будет перезаписаться
yopp
Т.е. конфликт автоматически разрешается в пользу новых данных?
Ilya
ага
Ilya
я больше склоняюсь к bulk_write в котором много запросов upsert
yopp
Проблема с удалением перед вставкой — отсутсвие данных.
yopp
Документы в монге обновляются?
yopp
И о каком количестве мы говорим?
Ilya
на данный момент доступ к документам в монге есть, но изменения которые в них внесены не критичны если будут перезаписаны.
количесвто несколько тысяч, меньше ста
Igor
на данный момент доступ к документам в монге есть, но изменения которые в них внесены не критичны если будут перезаписаны.
количесвто несколько тысяч, меньше ста
Эта процедура обновления, постоянная или единовременная. Я конечно тот еще гавнокодер, но пока я вижу лишь процедуру перезаписи для каждого документа. Не могу найти как монго может сразу массив данных отфильтровать и перезаписать в 2 запроса
yopp
никак не может
Ilya
ну поэтому я тут и спрашиваю)
в итоге то через Bulk Write можно сделать хотя бы по 100 update с установленным upser=true?
yopp
Я бы не стал делать bulk write
Ilya
о_О
Ilya
что в нем плохого?
yopp
Поступите проще: создайте uniqe compound индекс на поля которые уникальны
Ilya
он и так создан
yopp
и дальше просто сделайте пачку upsert, последовательно обрабатывая ошибки, если возникли
Ilya
блин ну это же неправильно
Ilya
зачем столько времени тратить на сеть?
yopp
с bulkwrite будет невозможно определить конечное состояние если случилась ошибка при вставке
yopp
зачем столько времени тратить на сеть?
зачем столько времени тратить на разработку, если для тысячи документов мы говорим о максимум 500мс задержки?
yopp
ну пусть даже секунда
Ilya
в общем как то получается что решение в лоб лучше всех остальных - странно
yopp
Make it work, make it right, make it fast (если дожили)
yopp
что странного?
Ilya
ну наверно в монго так принято - я просто еще не привык)
yopp
Bulk операции в монге это исключительно экономия на wire transfer
Igor
в общем как то получается что решение в лоб лучше всех остальных - странно
твой объем данных непостоянен ведь? раз, ну два раза такой сделаешь в месяц, никто не умрет
Ilya
да, норм все - это реально редкая операция будет
Igor
да, норм все - это реально редкая операция будет
Чисто подведя итог, потрачено более часа на планировку запроса который выполнился бы за пару минут еще вчера)
Max
Bulk операции в монге это исключительно экономия на wire transfer
У нас тут не так давно на такой инсерт переключились, по 100 записей за раз на данный момент.
суммарная скорость вставки стала быстрее... может быть не на порядок, но раз в 5 точно.
проверяли по скорости рассасывания данных из очередей.
Все внутри локалки, на wire transfer не оч похоже.
Узким местом был (и есть) диск, на котором индексы.
Max
так что в определенных кейсах это приносит хороший профит.
yopp
У нас тут не так давно на такой инсерт переключились, по 100 записей за раз на данный момент.
суммарная скорость вставки стала быстрее... может быть не на порядок, но раз в 5 точно.
проверяли по скорости рассасывания данных из очередей.
Все внутри локалки, на wire transfer не оч похоже.
Узким местом был (и есть) диск, на котором индексы.
Из-за того что в локальной сети задержки в основном обусловленны не физической передачей данных, а их обработкой в процессе передачи, вам только кажется что в локальной сети нет задержек. Но в локальной сети действуют те-же самые законы физики что и везде :)
Быстрее света информацию не передать. За 1 миллисекунду свет может преодолеть всего ~300км метров, а за 1 микросекунду соотвественно всего 300 метров, а за 1 наносекунду всего 30 сантиметров. Или ~4 нс на каждый метр. И это только время необходимое на физическую передачу сигнала в одну сторону.
Дальше у нас есть 7 слоёв OSI модели, каждый из которых вносит свои задержки. Например в L1 популярен Ethernet. В этом протоколе есть пауза между передачей пакетов. Длинна паузы 96 «битовых пульсов». «Битовый пульс» считается как (1 / скорость интерфейса). Т.е. для 10E это ~0.1мс, а для 1000E ~1нс.
Т.е. мы ещё даже не начинали считать сколько времени устройствам нужно на обработку и уже получили 5 нс задержки на каждый метр.
Вместе с задержкой на обработку, без специальных оптимизаций и использования специального оборудования, задержка в одну сторону будет измерятятся в сотнях микросекунд. Даже loopback интерфейс, который по сути не взаимодействует с сетевым оборудованием, даёт задержки в десятки микросекунд.
Теперь посчитаем очень упрощённо.
Так как монга предпологает последовательное исполнение команд, ей нужно отправить запрос и дождаться ответа от сервера. Чем меньше размер запроса и меньше работы делает монга, тем заметнее становятся задержки. Предположим что мы можем передать запрос, со всеми задержками, за 500мкс, а монга может выполнить 50 тыс условных документов в секунду, что даёт нам 2мкс на вставку вместе со всеми обрабтками
Последовательная вставка: 500мкс (запрос) + 2 (обработка) + 500мкс (ответ) = 1002мкс на документ. Или 998 документа в секунду.
Bulk вставка 1000 документов: 500мкс * 1000 (передача) + 2 мкс * 1000 (обработка) + 500мкс (ответ) = 502500 мкс. 503 мкс на документ или 1988 документа в секунду.
Что примерно в два раза быстрее. В реальности эффект может быть как больше, так и меньше. Это будет зависеть от того, где дальше расположенно следующее бутылочное горлышко.
yopp
Никаких других оптимизаций в Bulk, насколько мне известно, нет. Все остальные эффекты могут быть связаны с уменьшением интервала между запросами.
Max
Из-за того что в локальной сети задержки в основном обусловленны не физической передачей данных, а их обработкой в процессе передачи, вам только кажется что в локальной сети нет задержек. Но в локальной сети действуют те-же самые законы физики что и везде :)
Быстрее света информацию не передать. За 1 миллисекунду свет может преодолеть всего ~300км метров, а за 1 микросекунду соотвественно всего 300 метров, а за 1 наносекунду всего 30 сантиметров. Или ~4 нс на каждый метр. И это только время необходимое на физическую передачу сигнала в одну сторону.
Дальше у нас есть 7 слоёв OSI модели, каждый из которых вносит свои задержки. Например в L1 популярен Ethernet. В этом протоколе есть пауза между передачей пакетов. Длинна паузы 96 «битовых пульсов». «Битовый пульс» считается как (1 / скорость интерфейса). Т.е. для 10E это ~0.1мс, а для 1000E ~1нс.
Т.е. мы ещё даже не начинали считать сколько времени устройствам нужно на обработку и уже получили 5 нс задержки на каждый метр.
Вместе с задержкой на обработку, без специальных оптимизаций и использования специального оборудования, задержка в одну сторону будет измерятятся в сотнях микросекунд. Даже loopback интерфейс, который по сути не взаимодействует с сетевым оборудованием, даёт задержки в десятки микросекунд.
Теперь посчитаем очень упрощённо.
Так как монга предпологает последовательное исполнение команд, ей нужно отправить запрос и дождаться ответа от сервера. Чем меньше размер запроса и меньше работы делает монга, тем заметнее становятся задержки. Предположим что мы можем передать запрос, со всеми задержками, за 500мкс, а монга может выполнить 50 тыс условных документов в секунду, что даёт нам 2мкс на вставку вместе со всеми обрабтками
Последовательная вставка: 500мкс (запрос) + 2 (обработка) + 500мкс (ответ) = 1002мкс на документ. Или 998 документа в секунду.
Bulk вставка 1000 документов: 500мкс * 1000 (передача) + 2 мкс * 1000 (обработка) + 500мкс (ответ) = 502500 мкс. 503 мкс на документ или 1988 документа в секунду.
Что примерно в два раза быстрее. В реальности эффект может быть как больше, так и меньше. Это будет зависеть от того, где дальше расположенно следующее бутылочное горлышко.
спасибо за ликбез, я в теме, но сам люблю так же рассказывать своим и пояснять, почему вставка данных из азии в штаты (речь не про этот кейс) не может быть быстрой, законы физики не отменить :)
Лично я (лично я) нашел объяснение ускорению балк инсёрта не из-за уменьшения кол-ва пакетов туда-сюда и суммарному времени раундтрипа пакетов, а из-за паттерна записи данных на диск.
то есть, если мне надо обновить 1 байт инфы, то файловая система все равно перезапишет блок информации на диске (512 байт)
Если балк инсёрт - то мы за одну запись на диск делаем вставку 100 документов.
Ну и так как у нас там диск дико нагружен - это даёт профит.
Повторю - тесты не ставил, глубоко не вникал.
проверили балки - в нашем случае сильно помогло.
Объяснение этому придумал вот такое.
кажется логичным.
Max
а в остальном полностью согласен.
Спасибо ещё раз за уделённое время на столь обстоятельный ответ :)
yopp
спасибо за ликбез, я в теме, но сам люблю так же рассказывать своим и пояснять, почему вставка данных из азии в штаты (речь не про этот кейс) не может быть быстрой, законы физики не отменить :)
Лично я (лично я) нашел объяснение ускорению балк инсёрта не из-за уменьшения кол-ва пакетов туда-сюда и суммарному времени раундтрипа пакетов, а из-за паттерна записи данных на диск.
то есть, если мне надо обновить 1 байт инфы, то файловая система все равно перезапишет блок информации на диске (512 байт)
Если балк инсёрт - то мы за одну запись на диск делаем вставку 100 документов.
Ну и так как у нас там диск дико нагружен - это даёт профит.
Повторю - тесты не ставил, глубоко не вникал.
проверили балки - в нашем случае сильно помогло.
Объяснение этому придумал вот такое.
кажется логичным.
Когда вы делаете вставку 100 документов через bulk они один фиг вставляются последовательно
yopp
Это совершенно никак не отличается от 100 запросов подряд, кроме тайминга
Max
но у монги есть же время, по которому оно делает флаш на диск.
в доке прям описывают
и если мы в это время подготавливаем большее количество документов, то нагрузка на диск должна быть ниже
Max
» кроме тайминга
Именно
yopp
Что такое «нагрузка на диск»?
yopp
И почему она должна стать ниже? :)
Max
количество обращений к underlying disk, по сути - сколько раз надо перезаписать блок файловой системы для сохранения инфы.
записать 100 раз по одному байту будет медленнее, чем записать 100 байт за 1 раз
по сути сейчас коряво описываю момент записи в память с последующим flush на диск.
и на моей нагрузке это заметно.
Но, повторю, я легко могу ошибаться и профит достигнут совершенно за счёт других вещей.
но я тогда не знаю за счет каких.
yopp
Если бы всё так просто было
Yury
Привет друзья! А какой самый лучший (не сильно нагружающий сервак и быстрый) способ получить список имен всех филдов коллекции?
yopp
Между программой и непосредственно дисковым хранилищем сейчас расположено с несколько десятоков слоёв абстракции, но что ещё важнее, ещё и куча кешей. В связи с чем нет прямой корреляции между запросом программы и реальной дисковой операцией.
yopp
Сравнение про 100 раз совсем не применимо к этому случаю
Max
yopp
Оно вообще мало применимо к реальной жизни.
Max
у меня не 100 раз, а гдето 5
когда тестировали балк на тестовом стенде - получили порядка 20% профита, но на тестовом стенде данных совсем мало.
а вот на проде выстрелило
yopp
Я про «100 раз по 1 байту быстрее 1 раза по 100».
yopp
Монга не оперирует байтами.
yopp
Монга оперирует более выскоуровнеными структурами. Хранилища оперируют в основном страницами, которые имеют более-менее прямое отображение на страницы памяти.
yopp
Тот-же wiredtiger это copy-on-write хранилище. А это значит что любая запись делается копированием текущей страницы, обновлением данных и потом изменением указателей со старой страницы, на новую.
Nick
Привет друзья! А какой самый лучший (не сильно нагружающий сервак и быстрый) способ получить список имен всех филдов коллекции?
Наверное, взять первые 1-5-10-100 доков и выбрать у них множество ключей, соответвенно быстро, но не абсолютно все поля будут
yopp
а больше нет никаких вариантов :)