а тут вопросы, связанные с mongoose задавать можно?

Всем привет Подскажите утилитку для графического моделирования коллекций и связей по полям между ними. Желательно так что можно было показывать менеджерам и начальству :-)

может это подойдет https://robomongo.org/

Коллеги, а есть какой нить вменяемый гуй, кроме 3t studio, а то они с последним обновлением совсем скурвились.

Коллеги, а есть какой нить вменяемый гуй, кроме 3t studio, а то они с последним обновлением совсем скурвились.

вот тож интересно. Чет прям няшного гуя не изобрели пока что

Меня просто совсем выморозила блокировка списка сессий, и возможность пользоваться только тремя коннектами в фряшной версии. Я попробовал mongobuster но он мне не очень понравился, так как все таки web-овый клиент

Ребята, а если надо вставлять документы пачками, но в коллекции могут уже эти данные быть, и во вставляемых данных нет параметра _id из монги, но есть другая уникальная пара параметров. То правильно ли я понимаю что правильнее сначала грохнуть существующие которые отфильтровать по этим уникальным свойствам - а потом производить вставку?

Ребята, а если надо вставлять документы пачками, но в коллекции могут уже эти данные быть, и во вставляемых данных нет параметра _id из монги, но есть другая уникальная пара параметров. То правильно ли я понимаю что правильнее сначала грохнуть существующие которые отфильтровать по этим уникальным свойствам - а потом производить вставку?

По сути да. Но если вставляемые данные идентичны с имеющимися, то накой вставлять по новой?

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

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

Если у тебя есть свой UID то по нему FindOneAndRemove

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

Хотя тут можно и Update

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

В update вроде точные поля нужно называть какие нужно обновить. Но надо доку поднять. Могу ошибаться и можно по UID твоему найти и все update нуть сразу

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

Ребята, а если надо вставлять документы пачками, но в коллекции могут уже эти данные быть, и во вставляемых данных нет параметра _id из монги, но есть другая уникальная пара параметров. То правильно ли я понимаю что правильнее сначала грохнуть существующие которые отфильтровать по этим уникальным свойствам - а потом производить вставку?

Нужно определиться со стратегией в случае дублирования данных.

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

Мне кажется вы заблуждаетесь.

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

Чтобы массово грохнуть, тебе нужно обойти свой массив, отобрать все UID которые будешь грохать, найти их в базе, грохнуть и заливать новый данные. И чет я вижу гавнокод в своих мыслях. Имхо так делать - не бэст практикс

ну а делать по каждому документу файнд и потом апсерт - это типа лучше?

ну а делать по каждому документу файнд и потом апсерт - это типа лучше?

Вам в итоге что с дублирующимеся документами сделать надо?

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

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

Т.е. конфликт автоматически разрешается в пользу новых данных?

ага

я больше склоняюсь к bulk_write в котором много запросов upsert

Проблема с удалением перед вставкой — отсутсвие данных.

Документы в монге обновляются?

И о каком количестве мы говорим?

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

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

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

никак не может

ну поэтому я тут и спрашиваю) в итоге то через Bulk Write можно сделать хотя бы по 100 update с установленным upser=true?

Я бы не стал делать bulk write

ну поэтому я тут и спрашиваю) в итоге то через Bulk Write можно сделать хотя бы по 100 update с установленным upser=true?

нинада

о_О

что в нем плохого?

Поступите проще: создайте uniqe compound индекс на поля которые уникальны

он и так создан

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

блин ну это же неправильно

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

??

зачем столько времени тратить на сеть?

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

зачем столько времени тратить на сеть?

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

ну пусть даже секунда

в общем как то получается что решение в лоб лучше всех остальных - странно

Make it work, make it right, make it fast (если дожили)

что странного?

ну наверно в монго так принято - я просто еще не привык)

Bulk операции в монге это исключительно экономия на wire transfer

в общем как то получается что решение в лоб лучше всех остальных - странно

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

да, норм все - это реально редкая операция будет

да, норм все - это реально редкая операция будет

Чисто подведя итог, потрачено более часа на планировку запроса который выполнился бы за пару минут еще вчера)

Bulk операции в монге это исключительно экономия на wire transfer

У нас тут не так давно на такой инсерт переключились, по 100 записей за раз на данный момент. суммарная скорость вставки стала быстрее... может быть не на порядок, но раз в 5 точно. проверяли по скорости рассасывания данных из очередей. Все внутри локалки, на wire transfer не оч похоже. Узким местом был (и есть) диск, на котором индексы.

так что в определенных кейсах это приносит хороший профит.

У нас тут не так давно на такой инсерт переключились, по 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 документа в секунду. Что примерно в два раза быстрее. В реальности эффект может быть как больше, так и меньше. Это будет зависеть от того, где дальше расположенно следующее бутылочное горлышко.

Никаких других оптимизаций в Bulk, насколько мне известно, нет. Все остальные эффекты могут быть связаны с уменьшением интервала между запросами.

Из-за того что в локальной сети задержки в основном обусловленны не физической передачей данных, а их обработкой в процессе передачи, вам только кажется что в локальной сети нет задержек. Но в локальной сети действуют те-же самые законы физики что и везде :) Быстрее света информацию не передать. За 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 документов. Ну и так как у нас там диск дико нагружен - это даёт профит. Повторю - тесты не ставил, глубоко не вникал. проверили балки - в нашем случае сильно помогло. Объяснение этому придумал вот такое. кажется логичным.

а в остальном полностью согласен. Спасибо ещё раз за уделённое время на столь обстоятельный ответ :)

спасибо за ликбез, я в теме, но сам люблю так же рассказывать своим и пояснять, почему вставка данных из азии в штаты (речь не про этот кейс) не может быть быстрой, законы физики не отменить :) Лично я (лично я) нашел объяснение ускорению балк инсёрта не из-за уменьшения кол-ва пакетов туда-сюда и суммарному времени раундтрипа пакетов, а из-за паттерна записи данных на диск. то есть, если мне надо обновить 1 байт инфы, то файловая система все равно перезапишет блок информации на диске (512 байт) Если балк инсёрт - то мы за одну запись на диск делаем вставку 100 документов. Ну и так как у нас там диск дико нагружен - это даёт профит. Повторю - тесты не ставил, глубоко не вникал. проверили балки - в нашем случае сильно помогло. Объяснение этому придумал вот такое. кажется логичным.

Когда вы делаете вставку 100 документов через bulk они один фиг вставляются последовательно

Это совершенно никак не отличается от 100 запросов подряд, кроме тайминга

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

» кроме тайминга Именно

Что такое «нагрузка на диск»?

И почему она должна стать ниже? :)

количество обращений к underlying disk, по сути - сколько раз надо перезаписать блок файловой системы для сохранения инфы. записать 100 раз по одному байту будет медленнее, чем записать 100 байт за 1 раз по сути сейчас коряво описываю момент записи в память с последующим flush на диск. и на моей нагрузке это заметно. Но, повторю, я легко могу ошибаться и профит достигнут совершенно за счёт других вещей. но я тогда не знаю за счет каких.

Если бы всё так просто было

Привет друзья! А какой самый лучший (не сильно нагружающий сервак и быстрый) способ получить список имен всех филдов коллекции?

Если бы всё так просто было

Мы тут MongoLime обновили наконец-то ?

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

Сравнение про 100 раз совсем не применимо к этому случаю

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

и опять со всем согласен но красивее идеи у меня нет :)

Оно вообще мало применимо к реальной жизни.

у меня не 100 раз, а гдето 5 когда тестировали балк на тестовом стенде - получили порядка 20% профита, но на тестовом стенде данных совсем мало. а вот на проде выстрелило

Я про «100 раз по 1 байту быстрее 1 раза по 100».

Монга не оперирует байтами.

Монга оперирует более выскоуровнеными структурами. Хранилища оперируют в основном страницами, которые имеют более-менее прямое отображение на страницы памяти.

Тот-же wiredtiger это copy-on-write хранилище. А это значит что любая запись делается копированием текущей страницы, обновлением данных и потом изменением указателей со старой страницы, на новую.

Привет друзья! А какой самый лучший (не сильно нагружающий сервак и быстрый) способ получить список имен всех филдов коллекции?

Наверное, взять первые 1-5-10-100 доков и выбрать у них множество ключей, соответвенно быстро, но не абсолютно все поля будут

а больше нет никаких вариантов :)

ну только если все документы перебрать

даже в компассе все эти смешные графики построены на семплах

Да, сейчас мы делаем map-reduce по всей коллекции, клиенты говорят что у них крашится сервак :-) Надо реально подхачить тут это дело. В 90% случаев всех все устроит.

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

А чо они так умеют?)

но это уже вручную юзером должно указываться

Ааа

Да, сейчас мы делаем map-reduce по всей коллекции, клиенты говорят что у них крашится сервак :-) Надо реально подхачить тут это дело. В 90% случаев всех все устроит.

лучший способ — не делать этого

совсем

Не, не прокатит

прокатит

прокатит

А, я про то что схем у нас нет :-) а с выборкой нескольких доков ваще норм должно все быть :-)

Вы не тем занимаетесь