Всем привет. подскажите, можно ли создать юзера в монге только с одним action: update ?

Можно, но могут быть проблемы

понял ) тогда пожалуй не буду этим заниматься )

Всем привет. подскажите, можно ли создать юзера в монге только с одним action: update ?

Вроде пишут, что можно: https://docs.mongodb.com/manual/reference/privilege-actions/#security-user-actions @dd_bb а какого рода проблемы могут возникнуть?

Драйвера могут при подключении выполнять какие-то команды

Драйвера могут при подключении выполнять какие-то команды

а, ясн...

понял ) тогда пожалуй не буду этим заниматься )

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

ну вообще планируется ссшится на хост, и делать mongo

Методом проб и ошибок за пару часов можно найти комбинацию прав, которой хватит

Ни у кого не завалялось какого-нибудь чтива про опыт использования монги на больших кластерах (суммарным объемом от 10ТБ данных)?

А что вас интересует?

Ни у кого не завалялось какого-нибудь чтива про опыт использования монги на больших кластерах (суммарным объемом от 10ТБ данных)?

Извините, нет. Лично я не дорос ещё :)

А что вас интересует?

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

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

Главная проблема: ОЧЕНЬ сложно бэкапить 1) Балансировкой рулить никак нельзя, можно либо руками таскать чанки, либо дать шедулеру окно. 2) Не делать аналитические фуллсканы, а делать прогессивные отчёты. Если нужна настоящая горячяя аналитки, монга не лучший выбор. Но с помощью шардинга и достаточного capacity на шарде, это вполне реально 3) AF отличная штука. Про временные данные данные не понял. В шарде «паралеллизация» будет зависеть от запроса 4) map/reduce лучше избегать 5) ;)

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

ну, 10+ТБ особо и некуда бэкапить, это можно только реплицировать. Вот с АФ я столкнулся с некторыми проблемами (даже без клстера). Например, когда делаешь лукап, такое ощущение, что он делает подзапрос под каждый документ стейджа. Более разумным повоедением было бы собрать все значения localField каждому документу, одним запросом выгрузить все необходимые данные из from коллекции и уже в памяти смержить исходные документы с новыми. Или делать это хотя бы чанками, если весь стейдж не помещается в памяти. Как это на кластере будет, я вообще не представляю. Да, я обеспечу, что все данные будут в пределах одного шарда, соглашусь на временные коллеции для стейджей, но кто и как потом эти временные коллекции будет собирать и делать по ним тот же $out. В общем, есть сомнения, насколько это все быстро может работать

репликация != резервное копирование.

ну и опять же, сложные аналитические запросы очень хорошо ложатся на колонучную модель, т.к. выгружаются только ключевые столбцы данных и по ним делаются рассчеты, а потом собираются полные данные. В АФ есть $project , но судя по модели АФ, когда каждый стейдж -- это независимая копия коллекции данных, все будет только хуже, если сначала ограничить по $project, а потом еще раз собрать данные

если вам нужен $lookup, вам не нужна монга

в общем, мужики сомневаются, что бигдата на монге взлетит)

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

out в map/reduce в кластере будет больной темой

ну, по обычные офлайн запросы аналитиков: найти группу людей, которые за предыдущие 3 месяца заходили на страницу Х, после этого купили не менее 8 товаров категории У, после чего пропали на 9 или более часов, но потом вернулись и кликнули на рекламу Z. Все это с гистограммой по версии браузера и был ли дождь в это время за окном

я не знаю как в последних версиях, но из-за того, что под out делается временная коллекция, кластер на время создания коллекции может стоять в локе. это _очень_ больно

я не знаю как в последних версиях, но из-за того, что под out делается временная коллекция, кластер на время создания коллекции может стоять в локе. это _очень_ больно

ужас )

я понял, зря я на монгу в этом плане хоть как-то смотрел ))

спасибо

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

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

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

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

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

ну вы не видите, а я вижу :)

вы хотите реляционную базу в документном хранилище

так не бывает

точнее бывает, но тогда оно работает так, как работает сейчас

я вообще считаю что $lookup они сделали зря

монговцы молодцы. они реализовали все фичи, которые покрыли их модель данных, которая по их мнению покрывает 80% проблем. и теперь решают оставшиеся 20% проблем, типа accidental relations и транзакционность

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

но нет, это будет ОЧЕНЬ МЕДЛЕННО

и это пограничные кейсы

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

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

на лукап есть одно очень большое ограничение: Performs a left outer join to an unsharded collection in the same database и т.к. вторая таблица не может быть шардированная то все будет оченьпечально

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

с бигдатой всё сложно не у монги, а у тех кто пытается со своим уставом идти в монгу

вот вы пытаетесь

вы хотите реляционную колоночную модель в документном хранилище :)

и если вы это сделаете так, вам будет _очень_ больно

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

не думайте что вы меня задели

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

монга, как и любое другое документное хранилище, требует изменения мышления

вы представьте что монга это multikey-value хранилище, с нативной поддержкой BSON

редис на стероидах

на лукап есть одно очень большое ограничение: Performs a left outer join to an unsharded collection in the same database и т.к. вторая таблица не может быть шардированная то все будет оченьпечально

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

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

но видимо совсем ошибся

я поэтому и написал, чтоб о таком даже и не думалось)

монга, как и любое другое документное хранилище, требует изменения мышления

ну вот я это часто слышу, кстати. Но не могу понять, что это значит. Ну да, удобно строить иерарческие деревься, а потом копипасть поддеревья в другие документы по необходимости. И вопрос согласованности уже переносить в код. Но по факту, документы в монге дополнять нельзя, т.к. будет постоянная реаллокация + есть ограничения на максимальный объем одного документа. Можно только атомарные операции, которые не меняют размер документа. То есть все равно надо расти по количеству документов. Соответственно, данные тоже надо собирать. Раньше собриали подзапросами на уровне приложения, теперь лукапом. А в чем еще изменение сознания?

(я согласен, что могу многого не понимать в философии монги, не надо меня ругать, пожалуйста)

> Но по факту, документы в монге дополнять нельзя Это _очень_ устаревшая инфа

это справедливо для MMAPv1, который к счастью уже deprecated

О_о . WiredTiger без реаллокаций дополняет документы?

это copyonwrite

да и в mmapv1 это тоже решалось

это очень опасно, делать выводы о неэффективности внутреннего устройства храналище, не имя достаточного представления как оно работает. «реалокация» это выдуманная проблема

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

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

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

Compas https://www.mongodb.com/products/compass полуонлайн :) На электроне сделан. Подойдет?

Ребят, есть вопрос про репликасет: Когда я создаю репликасет, все настройки пользователей и доступов локальных нод слетают, что, наверно, логично. Но у меня остаются какое-то, пусть и не продолжитьельное, время висеть открытые наружу доступы без пароля в т. ч. и на Primary. Какая вероятность, что какой-нибудь краулер за время накатывая ролей и пользователей найдет Primary и наделает делов?

Ребят а ктото пользуется mongo compass там есть возоможность сырой запрос вставить и выполнить?

а то эти агрегации через pipeline

Ребят, есть вопрос про репликасет: Когда я создаю репликасет, все настройки пользователей и доступов локальных нод слетают, что, наверно, логично. Но у меня остаются какое-то, пусть и не продолжитьельное, время висеть открытые наружу доступы без пароля в т. ч. и на Primary. Какая вероятность, что какой-нибудь краулер за время накатывая ролей и пользователей найдет Primary и наделает делов?

Не исключено, хотя и маловероятно. Лучше закрыться. Может фаерволом?

Ребят а ктото пользуется mongo compass там есть возоможность сырой запрос вставить и выполнить?

Вот что есть

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

В studio 3t вроде хороший помощник по агрегациям есть. Но лучше изучить и руками писать, имхо.

Ребят, есть вопрос про репликасет: Когда я создаю репликасет, все настройки пользователей и доступов локальных нод слетают, что, наверно, логично. Но у меня остаются какое-то, пусть и не продолжитьельное, время висеть открытые наружу доступы без пароля в т. ч. и на Primary. Какая вероятность, что какой-нибудь краулер за время накатывая ролей и пользователей найдет Primary и наделает делов?

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

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

Спасибо, да я думаю через iptables закрою все

Ребят, есть вопрос про репликасет: Когда я создаю репликасет, все настройки пользователей и доступов локальных нод слетают, что, наверно, логично. Но у меня остаются какое-то, пусть и не продолжитьельное, время висеть открытые наружу доступы без пароля в т. ч. и на Primary. Какая вероятность, что какой-нибудь краулер за время накатывая ролей и пользователей найдет Primary и наделает делов?

Для настройки перед вводом в эксплуатацию поможет bind на loopback интерфейсе.

Привет. Посоветуйте, как лучше решить: есть коллекция документов, полей по 25. Нужно сделать часть полей мультиязычными. Как переделать схему лучше: itemOfCollection.ru.field или item.field.ru или collection_ru/collection_en ? процент переводимых полей около 30. также перевода у поля может временно не быть, и тогда нужно будет отдавать дефолтный. Как правильнее всё это организовать?