4.2.3

Тогда что-то в таком духе https://t.me/MongoDBRussian/62029

Тогда что-то в таком духе https://t.me/MongoDBRussian/62029

Нет, нельзя. Но это очень быстро

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

Сомневаюсь что вы эту итерацию вообще заметите на фоне всего остального :) Даже если там будет несколько тысяч элементов Индексы работают как работали. Update Pipeline выполняется только для каждого попавшего в условие документа. Т.е это исключительно стадия трансформации

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

Один раз при запуске инстанса приложения

Один раз при запуске инстанса приложения

Драйвер сам закроет соединения когда процесс будет завершён

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

А где вы смотрите на примеры?

А где вы смотрите на примеры?

Сомневаюсь что вы эту итерацию вообще заметите на фоне всего остального :) Даже если там будет несколько тысяч элементов Индексы работают как работали. Update Pipeline выполняется только для каждого попавшего в условие документа. Т.е это исключительно стадия трансформации

а еще вопрос про конкуретные обновления, не будет ли с ними проблем ?

Хороший вопрос. Не уверен что не будет. Можно для надежности использовать optimistic lock и делать retry

Я почитал про WiredTiger как дефолтный движок монго, у него под капотом mvcc, он по дефолту использует оптимистик лок на уровне целого документа и ретрай при конфликтах Так что проблем вроде как быть не должно)

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

Ну так себе аргумент про то, что не стоит на него полагаться С таким успехом можно свою бд писать)

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

Добрый день. Есть в монге возможность установить действие по умолчанию при конфликте уникального поля? Типа ON CONFLICT в pgsql

А можно как то из кода узнать хост и порт монги, MongoDB shell version v4.0.6 connecting to: mongodb://127.0.0.1:27017/?gssapiServiceName=mongodb 2020-04-09T16:25:09.839+0000 E QUERY [js] Error: couldn't connect to server 127.0.0.1:27017, connection attempt failed: SocketException: Error connecting to 127.0.0.1:27017 :: caused by :: Connection refused : connect@src/mongo/shell/mongo.js:343:13 не могу внутри докера залезть в монгу. Но из кода работает

Нет

Нет

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

Зависит от версии монги

Если это 3.6 и выше и вы внутри сессии вставляете бати, то если я не ошибаюсь, вам по каждой ошибке вернётся по документу. Но я не уверен что весь батч выполнится

т.е., мне надо deleteMany сначала, а потом insertMany ? не очень оптимально выглядит (

т.е., мне надо deleteMany сначала, а потом insertMany ? не очень оптимально выглядит (

А зачем батчи? Нельзя по одному доку это делать игнорировать дубликаты? Или еужно перезаписывать на новое?

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

Общий эксепшн 11000 выскакивает

Точно внутри сессии вставляете?

А какой у вас кейс?

А откуда конфликты?

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

Я так понимаю что у вас задача синхронизации внешнего источника с коллекцией в монге, при сохранении целостности представления для клиентов. Фундаментально есть два варианта: merge и replace Merge самый вычислительно сложный и требует много чтения, но не требует много записи и бесплатен с точки зрения потребления результата. Так или иначе это две тяжелые операции: вычисление дельты, обновление состояния и какой-то механизм разрешения конфликтов. Есть разные подходы к реализации, в том числе ваш, через уникальное поле и нарушение констрейна по уникальности. Replace самый дешёвый по вычислениям, но будет требовать или много записи или чуть меньеше записи, но немного стоить при потреблении результата синхронизации. Его можно реализовать или через очистку коллекции, или через вставку в новую коллекцию или через вставку в существующую коллекцию. Я не вижу смысла сразу удалять документы, по этому остаётся два варианта: 1) вставлять все данные из источника в новую коллекцию. Выделить коллекцию с фиксированным именем для хранения названия коллекции с данными последней выгрузки и использовать имя этой коллекции на стороне клиента для выборки. Минус такого подхода что имя коллекции будет не фиксированое, придётся постоянно следить за индексам. Плюс: он ничего кроме обновления имени коллекции не требует. 2) вставлять данные из источника в существующую коллекцию, с предыдущим результатам выгрузок. Для того чтоб избежать конфликтах при вставке, в документ добавляется новое поле с «версией выгрузки». Это поле добавляется как префикс ко всем индексам в коллекции. По завершению выгрузки, значение новой версии записывается в отдельную коллекцию. Клиенты при чтении из коллекции должны указывать какую версию они используют. Минусы: отдельное поле, без использования которого в запросе можно получить документы из других версий; дополнительное поле в индексе.

Тут вопрос какой capacity у вас больше: read на вычисление дельт или write на версионирование

Выбор максимальной версии дорогая операция

Размер коллекции в худшем случае вырастет в два раза

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

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

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

Ну перезаписывать данные было бы не обязательно. Существует же какая то сортировка по умолчанию? Может по _id? И быть может её можно изменить? Не переписывая данные. И тогда, без указания сортировки в запросе, данные считывались бы сортированными по "изменённому" умолчанию. И при добавлении новой записи включать её в индекс.

Есть индекс по умолчанию по _id

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

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

бывают коллекции без этого поля ) сам видел, если память не изменяет

Дело в том, что код я могу вообще не писать. Софт позволяет "кубиками"оперировать. И есть вариант кубика типа "получить все записи коллекции". Там нет возможности сортировку указать. Вот и считывается коллекция в том порядке в котором записывалась. А хотелось бы этот порядок изменить, чтобы не сортировать клиентом.