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

Когда начинать юзать шардинг написано здесь, например: https://docs.mongodb.com/manual/sharding/ Что случиться раньше подсказать вам не сможет никто, всё сильно зависит от индивидуальных задач. > .... лень отвечать да, таоке бывает достаточно часто. С ленью обычно борятся мотивацией, деньгами или другими плюшками. Но гашение негатива явно в них не входит, извините :)

Когда начинать юзать шардинг написано здесь, например: https://docs.mongodb.com/manual/sharding/ Что случиться раньше подсказать вам не сможет никто, всё сильно зависит от индивидуальных задач. > .... лень отвечать да, таоке бывает достаточно часто. С ленью обычно борятся мотивацией, деньгами или другими плюшками. Но гашение негатива явно в них не входит, извините :)

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

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

Из личного опыта - знаиматься шардирвоанием нужно как только вы привысили прирост примерно 50-100Гб в месяц и рост прироста продолжается и у вас даже есть еще свободных 4Тб места. В этом слчае у вас будет время изменить структуру бд, доработать приложения, закупить железо и все потестировать, а после еще и перелить данные в новый кластер.

а как на счет вообще советов по шардированию ну вроде того что мол ПОДУМОЙ. потом поздно будет. взад уже не расшардируешь 😄

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

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

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

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

Переключение между базами достаточно дорогая операция. Задержки которые вы видите, это время наобходимое на «холодное» переключение. После того как необходимые данные попадут в кеш, переключение будет быстрее. Multi-tenancy — гигантское усложнение архитектуры, потому что это по сути шардинг. В монге multi-tenancy имеет смысл рассматривать: 1) для безопасности/изоляции данных, когда вы инструментами субд хотите ограничить доступ к данным 2) для масштабирования, когда у каждого потребителя своя копия инфраструктуры 3) для «BYOI/BYOC», когда потребитель может использовать ваш продукт на своей/арендованной инфраструктуре.

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

Всем привет. Кто знает, есть ли возможность сделать .watch на standalone монгодб?

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

Из ваших рассуждений я могу сделать вывод, что вы не пытаетесь решить реальную проблему. Не идите этим путём :)

user_id ко всем данным

«Не удобно» это вообще убыточное мышление. Вы хотите на порядок увеличить стоимость разработки решения, снизить скорость, добавить огромную операционную сложность, просто потому что вам «не удобно»

Вы зря начинаете защищаться

Вы зря начинаете защищаться

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

Хотите изучить монгу, сделайте user_id и разберитесь с шардингом

ребят, кто-то может показать пример с проверкой на существование документа сразу с несколькими полями? Использую java driver. Написал таким образом: https://ghostbin.com/paste/c8qrw но может кто посоветует лучше подход или что почитать? Буду благодарен за наводку.

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

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

Так сделайте find и проверьте, вернулось ли что.

я вызвал find в своем примере на одно поле, а как на несколько?

https://docs.mongodb.com/manual/tutorial/query-documents/#specify-and-conditions

я вызвал find в своем примере на одно поле, а как на несколько?

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

поле называется не _id случайно?

поле называется не _id случайно?

Нет, __v

Да это шутка :) Я не в курсе mongoose-а просто

Нет, __v

это версия модели/схемы

Ну т.е прописать соединение а потом выполнить команду создания индекса?