@MongoDBRussian

Страница 27 из 342
yopp
13.09.2016
15:39:19
как там монга чанки получает это второй вопрос

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

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

ptchol
13.09.2016
15:39:51
ты попездываеш ьи не хочешь слушать )

Google
ptchol
13.09.2016
15:40:02
если у нас распредление данных будет не равномерное

а 75\20\5

yopp
13.09.2016
15:40:20
...

ptchol
13.09.2016
15:40:22
мы получим неравномерное распредление

так ?

yopp
13.09.2016
15:40:46
берёшь три ноды для 75, две для 20 и одну для 5

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

да.

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

yopp
13.09.2016
15:41:14
нет

ptchol
13.09.2016
15:41:19
да

Dmitry
13.09.2016
15:41:24
ты попездываеш ьи не хочешь слушать )
эм, что за треш по отношению к человеку, который пытается вас бесплатно консалтить?

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

Google
ptchol
13.09.2016
15:41:49
у нас традиции и мы их поддерживаем

Dmitry
13.09.2016
15:42:01
ок, ок.

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

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

yopp
13.09.2016
15:42:32
вся твоя ручная балансировка будет заключатся в назначении ноде тега

ptchol
13.09.2016
15:42:38
а не просто вкидыват ьих в общий шард кластер

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

yopp
13.09.2016
15:42:55
если у тебя три ноды с одним тегом, то у тебя данные будут размазываться по этим трём нодам

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

Serge
13.09.2016
15:43:19
ну да, но все равно ручная ))
Есть мнение, что это очень легко автоматизировать

Serge
13.09.2016
15:44:07
Можно даже на уровне DNS, discovery и апи какого-нибудь openstack

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

yopp
13.09.2016
15:44:41
эм

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

Serge
13.09.2016
15:45:10
причём тут днс ваще?
Чтобы тэги расставлять

ptchol
13.09.2016
15:45:18
Называй как угодно. Тебе ехать или шашечки?
мне чтобы из люка высунутся и кричать "вууууууу"

yopp
13.09.2016
15:45:45
главное чтоб трубой по еблу не заехало

Google
ptchol
13.09.2016
15:45:52
я просто удостоверится на самом деле хотел чт оя все правильно понимаю, и будет дисбаланс

Serge
13.09.2016
15:45:53
Ну, в общем, шардинг и добавляй ноды куда надо

ptchol
13.09.2016
15:46:08
да, так и собираемся

ptchol
13.09.2016
15:46:48
скорее всего тогда эффективность ниже будет

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

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

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

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

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

Serge
13.09.2016
15:48:28
Госпади

Гугли mongodb sharding node explosion

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

ptchol
13.09.2016
15:49:39
=)

Serge
13.09.2016
15:49:41
Типа aaa, потом aab...

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

yopp
13.09.2016
15:55:26
надо начинать с проблемы, почему документы устроены так, что индекс получается бесполезным

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

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

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

Serge
13.09.2016
16:01:02
Один из подходов, помогающих оптимизировать работу с базой.

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

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

ptchol
13.09.2016
16:09:14
вложенные документы могут существенно уменьшить размеры индекса, повысив локализацию и снизив нагрузку на монгу
вложенные документы являются проблемой, потому что в данной задаче самый удобный вариант максимально плоские данные

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

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

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

ptchol
13.09.2016
16:56:58
да мы вроде разобрались

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

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

Alex
13.09.2016
17:05:50
жаль тут лайки нельзя ставить =)

ptchol
19.09.2016
13:37:15
http://www.east5th.co/blog/2016/09/05/querying-non-existent-mongodb-fields/

ptchol
23.09.2016
14:11:49
да да да )

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

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

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

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

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

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

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

Dmitry
25.09.2016
15:20:30
Просто в примерах везде mongoid

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

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

Dmitry
25.09.2016
15:21:29
А как ты вычитаешь если скажем прав нет?

ptchol
25.09.2016
15:21:58
А как ты вычитаешь если скажем прав нет?
у вас же API будет ходить в одну коллекцию

Serge
25.09.2016
15:22:07
А как ты вычитаешь если скажем прав нет?
Ну, некоторые, не хотят, чтобы можно было последовательно все картинки, например, перебрать, без просмотра рекламы

Dmitry
25.09.2016
15:22:07
Да

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

Serge
25.09.2016
15:23:55
Какой-то еще один генерить индентификатор?
Можно и генерить. И никто не мешает его пихать прямо в _id, вместо дефолтного

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

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

Страница 27 из 342