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

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

а это делается в три настройки

ты попездываеш ьи не хочешь слушать )

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

а 75\20\5

...

мы получим неравномерное распредление

так ?

берёшь три ноды для 75, две для 20 и одну для 5

к примеру ключ шардирования имеет 3 уникальных значения.

да.

я про это и говорю, по факту это балансирование руками

нет

да

ты попездываеш ьи не хочешь слушать )

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

мы с ним всегда так общаемся не парьтесь )

у нас традиции и мы их поддерживаем

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

Митя, не лезь, интересно же:)

ок, ок.

да, не парьтесь, это у нас такая прелюдия :)

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

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

а не просто вкидыват ьих в общий шард кластер

ну да, но все равно ручная ))

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

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

ну да, но все равно ручная ))

Есть мнение, что это очень легко автоматизировать

Есть мнение, что это очень легко автоматизировать

да вы что ! ) неверится прям )

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

ну для меня даже это ручная )

Можно даже на уровне DNS, discovery и апи какого-нибудь openstack

ну для меня даже это ручная )

Называй как угодно. Тебе ехать или шашечки?

эм

причём тут днс ваще?

причём тут днс ваще?

Чтобы тэги расставлять

Называй как угодно. Тебе ехать или шашечки?

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

главное чтоб трубой по еблу не заехало

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

Ну, в общем, шардинг и добавляй ноды куда надо

да, так и собираемся

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

Можно и без него, если хочется

скорее всего тогда эффективность ниже будет

Я вот, думаю, что можно и простым путем пойти, тупо включив ключ этого чанка в ключ шардинга

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

на самом деле пример с неравномерным распредление надуманный, это просто для удостоверения понимания

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

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

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

это кстати идея.

Госпади

Гугли mongodb sharding node explosion

В ключ надо ещё префикс версии ключа вставлять вначале

=)

Типа aaa, потом aab...

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

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

потому что шардинг это не решение проблемы, а закапывание её под ковёр

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

например мы перешли от модели 1 документ = 1 событие, на локализацию событий по определённому критерию в одном документе. если до этого размер индекса был одного порядка что и размер данных, то теперь у нас индексы это примерно 10% от данных

например мы перешли от модели 1 документ = 1 событие, на локализацию событий по определённому критерию в одном документе. если до этого размер индекса был одного порядка что и размер данных, то теперь у нас индексы это примерно 10% от данных

И это называется bucketing

Один из подходов, помогающих оптимизировать работу с базой.

Обратная сторона - может выбираться больше данных, хуже параллелится map/reduce

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

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

он не бесполезный

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

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

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

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

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

да мы вроде разобрались

я просто спрашивал про то правильно ли я понимаю, что при шардировании tag aware будет неравномерное распредление.

а вы не дали мне досказат ьи начали умничать

жаль тут лайки нельзя ставить =)

http://www.east5th.co/blog/2016/09/05/querying-non-existent-mongodb-fields/

http://www.east5th.co/blog/2016/09/05/querying-non-existent-mongodb-fields/

Meteor...

да да да )

радуют каждый раз

с другой стороны полезно типа вывляют "узкие места в доках"

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

Может кто-нить ченить по этому поводу подсказать: express+mongodb

Если я сделал REST и обращаюсь к определённому ресурсу, как мне лучше сделать?

Какой-то еще один генерить индентификатор?

Мы тогда так и не выяснили модель угроз. :)

Просто в примерах везде mongoid

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

это может являтся угрозой для кого то, а для кого то нет

А как ты вычитаешь если скажем прав нет?

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

Эээ. Ну, это на монге потруднее угадать

А как ты вычитаешь если скажем прав нет?

у вас же API будет ходить в одну коллекцию

А как ты вычитаешь если скажем прав нет?

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

Да

Эээ. Ну, это на монге потруднее угадать

у нас был кейс, когда мы хранили некий контент пользователей типа id фоток таким образом, и к нам просто в одни момент пришли с полным перебором. брали id + 1 запрос к api оттуда если объект есть получали ссылку на имидж, а потом шли на сторадж и тащили оттуда все )

Какой-то еще один генерить индентификатор?

Можно и генерить. И никто не мешает его пихать прямо в _id, вместо дефолтного

у нас был кейс, когда мы хранили некий контент пользователей типа id фоток таким образом, и к нам просто в одни момент пришли с полным перебором. брали id + 1 запрос к api оттуда если объект есть получали ссылку на имидж, а потом шли на сторадж и тащили оттуда все )

С полным перебором могут всегда прийти, хоть sha256 подбирать) в любом случае, от перебора надо защиту делать

у нас был кейс, когда мы хранили некий контент пользователей типа id фоток таким образом, и к нам просто в одни момент пришли с полным перебором. брали id + 1 запрос к api оттуда если объект есть получали ссылку на имидж, а потом шли на сторадж и тащили оттуда все )

Вот о чем я и говорю. Id тут не причем, если права не проверяются. Security by obscurity...

Вот о чем я и говорю. Id тут не причем, если права не проверяются. Security by obscurity...

да, конечно.

если у вас в API реализована проверка на права доступа к объектам тем или иным, то да, пофигу id там или нет

Понял....да это серьёзно. В моем приложении планируется что пользоваться им будут люди но чаще извне доступа не будет. Авторизация будет по логину и паролю