если диапазон поделился до «кванта», дальше его уже не поделить. потому что даже если диапазон будет 2.2 -> 2.3 ключ в документе всё равно 2 :)

документов много?

и какие тогда современные методы борьбы с jumbo? Собственно основная проблема - это неравная балансировка. Мне пока только приходит в голову ставить на шард ограничение по месту и вручную вытаскивать другие чанки на другие шарды....

документов много?

10 млрд

пару тб?

9тб

печальненько

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

пришло время планировать смену шард ключа, потому что 9тб будет легче перелить чем 11 и уж тем-более чем 20

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

ето будет нетривиально, да

простой, но долгий вариант: добавить ко всем документам значение convertShardKeyToHashed

сложный, но побыстрее: взять снепшот, взять утилиту wt, пройтись по всему индексу составив heatmap ключей (значение — количество ключей в индексе), найти самые толстые и по ссылке на документ посмотреть какие id туда попадают

сделать выборку документов по этому id и посчитать размер jumbo чанка

простой, но долгий вариант: добавить ко всем документам значение convertShardKeyToHashed

да...тоже такая идея посещала. Перевести все известные id в hash этой функции, потом по соответствию искать эти диапазоны

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

ещё аналитический вариант: в софте считать heatmap

т.е. завести где-то счётчик id -> число документов

можно попробовать запустить агрегацию на все 9тб :)

не обязательно на самом деле на все 9

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

можно попробовать запустить агрегацию на все 9тб :)

базка приляжет боюсь я тогда

т.е. известно где находится jumbo chunk, весь шард не надо сканировать

т.е. известно где находится jumbo chunk, весь шард не надо сканировать

их там 3к

3к шардов?

или 3к jumbo chunk?

Jumbo чанков

есть конечно ещё вариант: медленно увеличивать размер чанка :)

и смортреть как уменьшается число jumbo

а вот вопрос касательно этого. Надо их апдейтить, чтоб снять флаг? или балансировщик сам снимет?

а вот хз

гдето была инструкция по борьбе с jumbo

https://docs.mongodb.com/manual/tutorial/clear-jumbo-flag/#update-chunks-collection

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

а каой сейчас размер чанка?

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

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

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

это был сарказм же )

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

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

db > collection > document

а каой сейчас размер чанка?

был 128. недавно поднял до 256

db > collection > document

что?

что?

Да ты правильно понимаешь

Только так или иначе работает по другому

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

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

закрывать фаерволом

При правильной настройке ничего не взломают

При правильной настройке ничего не взломают

скажи это zero-day

он сказал что ни фаервол ни пароли не спасут и что

скажи это zero-day

а что за zero-day

он вообще говорит пробрасывай ssh

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

Ссш тоже взломают когда-то если ещё не взломали

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

а он говорит что это херово так как им неудобно

вообще ктото тут слегка занимается вопросами безопасности баз данных (монго )

есть какой то минимальный набор требований для минимизации рисков

Выдать можно каждому личный аккаунт и настроить какие права он будет иметь. Например, только на чтение или чтение + запись

Выдать можно каждому личный аккаунт и настроить какие права он будет иметь. Например, только на чтение или чтение + запись

это понятно на чтение я оставлю

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

а что за zero-day

Атака такая

вот есть приложение а у него хранятся ключи доступа

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

Ссш тоже взломают когда-то если ещё не взломали

ssh легко и эффективно защищается fail2ban-ом

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

Вопрос зашёл в тему защиты ОС, это уже не совсем по адресу)

ну если остановится на базе данных

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

Базу можно повесить слушать на какой-то порт и все будут через этот порт к ней подключаться и входить под своими логином/паролем. А доступ к самому серверу нужно полностью ограничить от третьих лиц

микс теории и практики

просто программист из visa пришел и там вот имел частую походу практику такую

Ну вообще те же mlab.com и mongodb atlas открывают внешний доступ к бд, поскольку они так делают, я думаю, это безопасно. Но опять же взломать можно практически всё) Если нужно только чтение с базы, возможно, стоит глянуть в сторону обёртки какой-то над базой данных, в виде АПИ например. В таком случае базу можно сделать полностью локальной.

«абсолютной безопасности» не бывает, разговоры про «безопасность» имеют смысл только в контексте конкретной модели угроз

если модели угроз нет, говорить смысла нет.

если модели угроз нет, говорить смысла нет.

а что такое модель угроз , как ее составить

https://en.wikipedia.org/wiki/Threat_model

Гайз подскажите , снял дамп с монги версии 3.3 накатил его на реплика сет монги версии 4.0.1 , в итоге проверяю count у коллекции и он отличается , на старой и новой монги . при этом на новой , куда не кто не пишет , он больше , это нормально ?))

Здравствуйте. Тоже вопрос про дамп. mongodump пишет Failed: error writing data for collection collname to disk: error reading collection: Failed to parse: { ... что это может быть?

Ну вообще те же mlab.com и mongodb atlas открывают внешний доступ к бд, поскольку они так делают, я думаю, это безопасно. Но опять же взломать можно практически всё) Если нужно только чтение с базы, возможно, стоит глянуть в сторону обёртки какой-то над базой данных, в виде АПИ например. В таком случае базу можно сделать полностью локальной.

В Атласе как раз есть фаервол:

Гайз подскажите , снял дамп с монги версии 3.3 накатил его на реплика сет монги версии 4.0.1 , в итоге проверяю count у коллекции и он отличается , на старой и новой монги . при этом на новой , куда не кто не пишет , он больше , это нормально ?))

Ошибок не было? Может в логах что?

Здравствуйте. Тоже вопрос про дамп. mongodump пишет Failed: error writing data for collection collname to disk: error reading collection: Failed to parse: { ... что это может быть?

кажется нашёл причину. https://dba.stackexchange.com/questions/215534/mongodump-unrecognized-field-snapshot разные версии удаленной базы и моего локального mongodump

Ошибок не было? Может в логах что?

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

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

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

Для надёжности проверьте не только количество, но ещё сексумму какую-нибудь проверьте

Для надёжности проверьте не только количество, но ещё сексумму какую-нибудь проверьте

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

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

Да, уж, как-то странно...

Разве RethinkDB не умер?

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

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

Не, он же вроде под апач ушёл. Говорили, типа это кладбище, но он живет, вроде.

тьфу, это не бот

?