вливаете их в одну ноду и всё

была такая идея... работает?

рекомендую сразу купить поддержку

пользуем стоковую MongoDB Community, я админ. Озадачился консистентными бэкапами шардированной монги. Есть утилита от Percona https://github.com/Percona-Lab/mongodb_consistent_backup. Она бэкапит шарды консистентно и архивирует каждый дамп шарда отдельно.

Буду пробывать запихать дампы последовательно в монгу... спасибо

а, это

но 'mongodump' is the default (and currently only) backup method. Other methods coming soon!

это не официальная ихняя утилита... поэтому поддерживается не очень(. Но Ops Manager отдельно не продаётся(

а у вас какой объём данных в шарде?

боль, печаль

конечно не продаётся :)

а у вас какой объём данных в шарде?

немного, в количестве документов не скажу, не под рукой. но по объёму 3 шарда по 10-13 Гб под БД занятого пространства.

а, ну тогда наслаждайтесь пока это работает :)

13 гигов не очень долго дампятся

будет больше, будет Enterprise я думаю)

вероятно первое время дешевле будет mongo cloud backup

но я не знаю, умеют ли они шарды нормально бэкапить

энтерпрайз на 3 шарда это минмум 12 лицензий. это уже 78 тыщ в год

энтерпрайз на 3 шарда это минмум 12 лицензий. это уже 78 тыщ в год

$? 😳

да

6500$ в месяц при стоимости бэкапов 2.5$/Gb/mo будет выгоднее как минимум до 2.6Тб

учитывая что для ops manager всё равно нужна будет инфраструктура, пологаю цифру можно на 1.5 умножить

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

For sharded clusters, the backup agent pauses the balancer every six hours and inserts a token across all shards and config servers. MMS is always watching for those tokens. When MMS sees the token, it knows that it’s time to cut a consistent snapshot of the sharded system. The oplogs are applied to all replica sets in the cluster until the point in which the token was inserted, providing a consistent snapshot across the cluster.

вон, для одного проекта эстимейт очень даже неплохой MONTHLY TOTAL* $2,801

будем знать. спасибо!

появилась такая проблема, использую реплика сет (1+1), база данных >2Tb. Есть 3 (микро)сервиса на одном апдейты точены на других 2х чтение в основном. И как подключаешь 3ий в работу так скорость запросов к монге падает (аггрегации нет). Какие есть варианты для разгона?

шардинг может попробовать?

вероятно горячие данные перестают влазить в память и начинается cache trashing

при коннекте поставил опцию чтобы чтение SecondaryPrefered

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

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

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

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

растут да

около 1000 запросов в сек на запись и 400 на чтение пишет

ну тогда пересматривайте свой бюджет на содержание монги)

да там не много

большая часть бюджета в серверах с GPU

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

а скорее даже в три

вообщем наверное попробуем докинуть памяти до 512Gb

на каждую коробку

потом будет очень больно шардировать

да там данные такие

я сторонник концепции mongodb as near perfect "middle storage"

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

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

и проблем)

например с шардингом очень легко сделать multi-tier хранилища

берём стойку набитую винтами и получаем архив

который можно жевать, что самое главное

не очень быстро, но можно

с зонированием очень много всего можно сделать

я не очень разделяю концепцию когда начинают накручивать хранилища

использовать разные бд?

да

понятно что есть разные задачи

но очень часто хранилища плодят без необходимости

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

мне наоборот удобнее с json хранилищем

из-за задачи

причем намного удобнее

я еще и редис юзаю 😄

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

проблема в том, что когда сырые данные приходят (с сенсоров то-се) часто непонятно как их раскидать в 3NF форму в реляционной бд это надо несколько таблиц, какие нибудь сложные операции апдейта данных по нескольким таблицам. в монге проще с этим - записал все в один документ и все.

да, подход «запишем и потом разберёмся» является как сильной, так и слабой стороной документных хранилищ

табличные хранилища переоценены

так-же как поддержка целостности связей

Редис в каждый дом))

редис всё-же не очень далеко ушел от мемкеша

это конечно хорошое key/value хранилище, но монга сильно мощнее

и её точно так-же можно использовать как k/v хранилище

и её точно так-же можно использовать как k/v хранилище

Не

да

Скорости

монга и есть key/value хранилище на стероидах

скорости чего? монга из кеша будет стрелять не сильно медленее редиса :)

монга и есть key/value хранилище на стероидах

Можно данные таблиц в оператие хранить разве?

в монге

в enterprise есть in-memory