Просто потому что так устроена вычислительная архитектура

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

Сможете конечно, даже с mmapv1 могли

хорошо, надо значит пробовать

ботами я все равно проверю,

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

Но нужно понимать что если под «работать» вы подразумеваете ситуации, когда у вас коллекция и индексы больше чем доступная память и одновременно частый паттерн это проехать всю коллекцию, это будет достаточно неээфективно, так как кэш не будет стабилизироваться и как следствие вы будете ещё и disk io bound из-за постоянного чтения в кеш с диска

но это не только монги касается, это для всех хранилищ так

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

по этому первый вопрос: есть ли у вас сейчас уже такая нагрузка?

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

если у вас «репликация уперлась в ипосы», вероятнее всего у вас был ресурсный дисбаланс, что частая ошибка

standby capcity кластера должен быть эквивалентен active capacity кластера

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

nvme рейд имеет очень мало практического смысла, так как параллелизация nvme практически не даёт никакого прироста производительности, а избыточность на уровне дисоковй системы в монге так-же редко помогает уменьшить RTO, так как уровень деградации производительности рейда в режиме восстановление целостности практически всегда на уровне критического отказа и не позволяет обслуживать клиентов. Так что быстрее просто заменить диски и восстановить ноду из бэкапа и вернуть её в кластер

у вас иопсов не хватало на праймари, я так понимаю?

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

это была не монга, а постгрес, насчет перехода на монгу я как раз думаю

а зачем вам монга?

потому что нравится как там сделаны из коробки репликасеты, шарды и роутеры, а теперь появились еще и транзакции и евенты. Выглядит красивее, проще и дешевле. Мы когда-то давно пытались делать проект на монге, но ад гонок и костыли с дфухфазными коммитами немного достали, в результате монга была заброшена, и база переведена в пг.

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

Например монга не поддрживает блокировки, если у вас есть транзакции требующие блокировок, вам будет _очень_ трудно

иопсов не хватало на секондари, такая особенность работы с wal, я так и не понял в чем фишка, но nvme справляется, и ладно. Насчет блокировок да, конечно, надо все проанализировать. Система большая, но не сложная.

Например монга не поддрживает блокировки, если у вас есть транзакции требующие блокировок, вам будет _очень_ трудно

монга не умеет ставить транзакции в очередь?

То что вы называете событиями, событиями не является. Это change notification, а не очереди. Там нет никаких инстурментов для реализации полноценных очередей с гарантиями

печаль

Очереди можно реализовать мимо change stream, но это другая история уже

события - это события на апдейт данных, как notify триггеры в пг. Если это будет работать, этого достаточно. А вот отсутствие блокировок и очередей транзакций... Даже не знаю, а как поступают когда надо запустить следующую транзакцию только после завершения другой?

монга не умеет ставить транзакции в очередь?

Не понимаю что вы имеете ввиду. Если у вас несколько транзакций, которые одновременно меняют одни и те-же документы, то успешно завершится только одна транзакция, остальные получат write conflict и вам его разрешать

Не понимаю что вы имеете ввиду. Если у вас несколько транзакций, которые одновременно меняют одни и те-же документы, то успешно завершится только одна транзакция, остальные получат write conflict и вам его разрешать

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

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

Производительность меньшая из ваших проблем :)

если бы у нас не было проблем, за что бы платили деньги?))

ладно, спасибо за консультацию, яснее стало

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

динамические имена ключей — антипаттерн

индекса по именам ключей в монге нет

есть wildcard index, но я не уверен что он умеет именно по именам ключй искать

там наверно массив субдокументов имеется в виду ? нет?

нет, не массив, с массивами все понятно

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

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

да, да, я понял.

кто либо встречался с такими ошибками?

а ключей много их количество ограничено?? или они генерируются?

а ключей много их количество ограничено?? или они генерируются?

это абсолютно не важно

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

это железное правило дизайна схем в монге: никогда* не использовать динамические ключ

(* — кроме ряда очень редких случаев)

это абсолютно не важно

ну почему же, можно же сделать ```nested: { key1: ... etc },

это железное правило дизайна схем в монге: никогда* не использовать динамические ключ

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

ну почему же, можно же сделать ```nested: { key1: ... etc },

нет

итем более если ключей 10

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

это можно

я ещё раз повторю: если ключ _динамический_, то это очень плохо

с появлением AF в 4.2 в update, смысла практичесеи не осталось

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

именно. динамический ключ делает схему динамической

а это боль и страдание

понятно, значит надо хватать за руку при попытке так сделать )

да, а полиморфизм это не плохо

главное чтоб он явный был :)

т.е. было поле явно идентифицирующее схему структуры

я ещё раз повторю: если ключ _динамический_, то это очень плохо

что то я не понимаю, если ключи у нас заранее известны и их мало то мочему не сделать нестед-объект в модели?

потому что это создаёт проблемы во всём

и скорее всего это признак архитектурной проблемы

да, а полиморфизм это не плохо

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

зависит от того что с ними будет

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

а если по ним надо искать, то могут быть нюансы

но вообще, explicit всегда побеждает implicit

если у вас случайные документы и у них нет идентификатора типа, то это в принципе проблема, не только в монге :)

У меня одного атлас не дает залогиниться?

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

здравствуйте помогите отфильровать данные с столбцов

я получаю слово которе вводится в инпуте , осталось отфильтровать в бд по фио

я получаю слово которе вводится в инпуте , осталось отфильтровать в бд по фио

поиск по части слова?

или по полному совпадению?

поиск по части слова?

да

тогда так: https://docs.mongodb.com/manual/reference/operator/query/regex/