Только надо учитывать что это будет не быстро. А балансировка потом может вообще занять пару надель

870 Гб

Если посмотришь на таблицу с лимитами размеров https://docs.mongodb.com/manual/reference/limits/#Sharding-Existing-Collection-Data-Size , то там смотришь что при максимально допустимом ключе в 512 байт и дефолтном размере чанка в 64Мб вкладываешься в лимит в 1Тб

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

Единственно советую перечитать раз 10 пункт перед выбором ключа: https://docs.mongodb.com/manual/reference/limits/#Maximum-Number-of-Documents-Per-Chunk-to-Migrate Если будет плохо выбран ключ шардирваония, то есть вероятность получить дикие перекосы по распределению места. Если же в одном чанке будет данных больше лимита и ключ шардирования не позволит разбить чанк (называется jumbo) , то данный чанк не сможет мигрировать на дургие ноды

ничего не напутал?

Вот кстати, роль ключа и его поведение — самое плохо документированное место в монге

Надо вебинар замутить про шардинг

Вот кстати, роль ключа и его поведение — самое плохо документированное место в монге

согласен

Вот кстати, роль ключа и его поведение — самое плохо документированное место в монге

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

Только надо учитывать что это будет не быстро. А балансировка потом может вообще занять пару надель

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

Интересно, стало ли лучше в 3.6 с балансировкой

Балансировка в один поток это страшно вообще

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

На мой взгляд не про ключи надо говорить, а про шардинг.

сейчас еще проблема возникла, есть коллекция размером в 4.5 Тб, шардирование по составному ключу, кластер из 7-ми шард, на 2х шардах размер коллекции превышает 1Тб, и суммарный размер индексов скоро достигнет размера ОЗУ. Планирую пока добавить дополнительные шарды, и переписать условия распределения чанков. в смысле переделать диапазоны.

Про общую архитектуру, чтоб понимать как вообще это работать и что это не так страшно как кажется. И что это не серебряная пуля.

На мой взгляд не про ключи надо говорить, а про шардинг.

Ты имеешь ввиду про инфраструктурные вопросы?

ага, понял

сейчас еще проблема возникла, есть коллекция размером в 4.5 Тб, шардирование по составному ключу, кластер из 7-ми шард, на 2х шардах размер коллекции превышает 1Тб, и суммарный размер индексов скоро достигнет размера ОЗУ. Планирую пока добавить дополнительные шарды, и переписать условия распределения чанков. в смысле переделать диапазоны.

а что делается с этой коллекцией? там данные просто лежат или часто запрашиваются? или может вообще агрегаты какие строятся?

а что делается с этой коллекцией? там данные просто лежат или часто запрашиваются? или может вообще агрегаты какие строятся?

и пишутся и запрашиваются.

а интенсивность? интерсно узнать какого рода задачи решаются с помощью монги

а интенсивность? интерсно узнать какого рода задачи решаются с помощью монги

хм. прирост данных составил порядка 1 ТБ за последние 50 дней.

а общая задача в чем заклчюается

хранение и аналих входящей документации

хм. прирост данных составил порядка 1 ТБ за последние 50 дней.

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

росло бы, но в другом холодном и темном месте

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

А так же данные еще и обновляются

после какого-то момента нет

и после этого их надо лить в другое место

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

агрегации используют

агрегации используют

ага

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

ну и как оно шаволется хоть? нет желания чтото с этим сделать, сменить монгу на чтото еще?

ну и как оно шаволется хоть? нет желания чтото с этим сделать, сменить монгу на чтото еще?

огромное))))))))

)))

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

да и щас мало кто задумывается бгг

ну и как оно шаволется хоть? нет желания чтото с этим сделать, сменить монгу на чтото еще?

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

да и щас мало кто задумывается бгг

кроме нас, как дба. потому как нам же это все и править)))))

ой не рассказывай

мы давно обсуждаем эту тему

Это еще просто не все в дискуссии)))))))

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

@nonamenix @SerhioRamas а вы как?

@lig11 и ты тоже!

@nonamenix @SerhioRamas а вы как?

предновогодние релизы )

Экстремалы

Есть немного

Привет. Подскажите, плз... Есть, скажем, операции, по которым выяснить IP источника. В CurOp() виден только ip mongos ну и ConnID, который в mongos.log никак не присутствует. И как тогда его искать?)

Давайте реванш за прошлый. А то пока Москва ведёт со счётом 1:0 😂

Привет. Подскажите, плз... Есть, скажем, операции, по которым выяснить IP источника. В CurOp() виден только ip mongos ну и ConnID, который в mongos.log никак не присутствует. И как тогда его искать?)

Источника с чьей точки зрения?

клиента, который соединяется с Mongos

В лог монгоса пишутся факты открытия соединений в принципе?

да. но те, connID там не присутствуют

Значит соединение открыто раньше

Не может одно писаться, а другое нет

Поищите в ротейтнутых логах

а в какой момент запись попадает в лог? в момент соединения или когда запрос завершился?

Да по-моему в момент когда соединение акцептнулось вообще

connid в логах монгоса не совпадает с currentOp

connid в логах монгоса не совпадает с currentOp

вот очень похоже на это...

Есть шанс что там connId самого монгоса

Можно грепнуть лог монгод на этот предмет

была похожая задача, отследить ip клиента, с нехорошими запросами, в логах конкретного Mongod и в currentOp регистриркется только connid с монгоса

там я вижу только ip mongos

Но вообще можно в комментарии в драйвере класть всё что угодно

там я вижу только ip mongos

А, ну тогда всё верно

Запрос то от монгоса в ноду приходит.

Но вообще можно в комментарии в драйвере класть всё что угодно

мы так и вышли из ситуации

Но вообще можно в комментарии в драйвере класть всё что угодно

внезапно те, кто делает клиентские запросы этого не знали. Теперь вот и ищу их))

Ну поправьте клиента

И сразу видно станет

@dd_bb тебя там где искать то на московоской ?

@dd_bb тебя там где искать то на московоской ?

Я пока вообще в Бакунине

Я освободился полчаса назад

ну еще 2 часа

или может таки на бакунине и того ?

Да. А что там на московской есть? Дикенз?

Ну поправьте клиента

найти сначала их нужно. их много... но спасибо, прояснилось немного

В смысле на московском

Да. А что там на московской есть? Дикенз?

не в курсе