Поступила интересная фраза, не используйте монгу, где не надо, тогда где её использовать?

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

Предела практически нет, как и у коллекции Вот здесь все лимиты https://docs.mongodb.com/manual/reference/limits/

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

Поступила интересная фраза, не используйте монгу, где не надо, тогда где её использовать?

Так очевидно же: где надо! :))

Предела практически нет, как и у коллекции Вот здесь все лимиты https://docs.mongodb.com/manual/reference/limits/

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

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

тут всегда так

Не разу не встречал в программировании, ответ на какой-то вопрос: "Не юзайте", он встречается там, где лень отвечать

Не разу не встречал в программировании, ответ на какой-то вопрос: "Не юзайте", он встречается там, где лень отвечать

с почином

с почином

Да не, почина не случилось

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

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

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

Какой негатив, вместо того чтобы сказать: такое не юзал, не знаю, говорят не юзайте где не надо

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

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

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

Отлично. По-экспериментируйте, потом поделитесь результатом. Все станем умнее :)

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

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

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

Спасибо

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

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

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

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

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

это когда ты умный и делать вот как ты пишешь

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

я рад что есть люди которые это понимают

жаль не все)

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

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

Тогда у вас обратная задача: добавить ноды к этой "новой" :)

вообще, через дамп/рестор легко можно смёрджить данные

Но рестор данных заниет больше суток, и нужно будет как-то досинкивать данные

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

Нет, нельзя.

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

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

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

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

Если у вас ещё нет продукта с клиентами, то эти три пункта не для вас :)

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

Не думайте о масштабировании, не думайте об оптимизации

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

Понял, спасибо

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

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

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

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

Нет

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

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

Один параметр — лучшее что вы можете получить

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

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

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

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

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

Вы симптоматику собираетесь лечить. Если у вас дрожжат руки, то multu-tenancy это дрожжание не решит.

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

Подойдите к проблеме аналитически. Чётко сформулируйте какой результат вы хотите получить. Сформулируйте критерии оценки, с баллами. Составьте список возможных решений, подкорректируйте критерии, оцените. И уже на основе анализа делайте выбор

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

Для себя пишу, стоимость не важна, главное правильность и удобство использования. Вы же с телефоном пади с iphone или чем-то похожим ходите, а не с simens a35

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

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

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

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

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

Вы сюда пришли за мнением. Моё мнение, основанное на практическом опыте, как своих продуктов, так и чужих — вы выбираете неэффективное решение своей проблемы. «Стоимость не важна», «для себя пишу» случается от несформулированных целей. «Правильно» вообще не существует. Бывает градация эффективности решения

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

Multi-tenancy не имеет отношения к технологии. Это _архитектура_ решения

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

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

Понял, думаю)

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

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

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

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

Да, вы правильно поняли. Change stream работает через oplog.

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

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

Да, я развернул standalone с репликой

Это уже не standalone.

По мануалу делал

https://docs.mongodb.com/manual/tutorial/convert-standalone-to-replica-set/

Ну да, это уже реплика получается

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

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

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

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

ERROR: S client not available

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

благодарю, нашел

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

Просто через запятую перечислите все поля.

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

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

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

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

Нет, __v

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

Как я понял, это количество редактирование (как мне ответили), но не знаю как его удалить, и вообще нужно ли оно, или оставить для put запросов

Нет, __v

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

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

?

Больше шансов , что люди ответят)

Спасибо за ответ :)

Нет, __v

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

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

Спасибо

поспешил http://mongoosejs.com/docs/guide.html#versionKey

всетаки версия самого дока, а не схемы

Парни, а можно через батник индекс создать?

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

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

"прописать соединение" ? Поясните

Ну для выполнения команду создания индекса, нужно же законектиться

Можно это через батник сделать все?

да можно, нужно просто передать монгошелу js скрипт с командами

зачем батник? что может быть проще: db.createIndex({"key": 1}) ?

ОО можно небольшой пример?

https://docs.mongodb.com/manual/tutorial/write-scripts-for-the-mongo-shell/

Задача такая через Бат скрипт

ничего не мешает это делать в батнике

Спасибо

в общем случае подготавливаете js скрипт, а в батнике уже его скармливаете монгошелу с параметрами подклчюения к бд

Парни, если установлен mongoCompass, то можно через piweshell команды отправлять на удалённую бд?

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

Вам для мониторинга или shell? Или вы про вызовы из приложения?

Парни, если установлен mongoCompass, то можно через piweshell команды отправлять на удалённую бд?

Одно с другим не связано. В компасе вы можете работать с вашей БД. Из powershell вы можете подключиться к БД и выполнять любые команды.