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

Не, шардирование это не совсем то что мне нужно. Я бы хотел иметь что-то что item.date > today - 10days где-то на горяченьком ssd, а всё остальное в hdd где-то далеко А под инкрементными бэкапами, я имею в виду те бэкапы, которые не перезаписывают целый файл с бэкапом с нуля, а лишь дописывают в файл то, что изменилось

Не, шардирование это не совсем то что мне нужно. Я бы хотел иметь что-то что item.date > today - 10days где-то на горяченьком ssd, а всё остальное в hdd где-то далеко А под инкрементными бэкапами, я имею в виду те бэкапы, которые не перезаписывают целый файл с бэкапом с нуля, а лишь дописывают в файл то, что изменилось

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

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

Вижу знакомые хотелки постгресовода)) В том виде в котором вы ожидаете - нет. Но можно использовать шардирование.

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

https://ru.stackoverflow.com/questions/1482853/%d0%92%d1%8b%d1%82%d0%b0%d1%89%d0%b8%d1%82%d1%8c-%d0%b2%d1%81%d0%b5-%d0%b4%d0%be%d0%ba%d1%83%d0%bc%d0%b5%d0%bd%d1%82%d1%8b-%d0%b8%d0%b7-%d0%ba%d0%be%d0%bb%d0%bb%d0%b5%d0%ba%d1%86%d0%b8%d0%b8-%d0%ba%d1%80%d0%be%d0%bc%d0%b5-%d0%be%d0%b4%d0%bd%d0%be%d0%b3%d0%be-%d0%ba%d0%be%d0%bd%d0%ba%d1%80%d0%b5%d1%82%d0%bd%d0%be%d0%b3%d0%be

$ne

как конкретно запрос оформить в таком случае?

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

У вас слегка не понятный вопрос. Опишите его по другому либо больше инфы/примеров дайте

ну просто надо вытащить вообще все что лежит в коллекции (кроме _id: '63aeb61c8181fc4cab6f7fff')

.find({}, {_id: 0})

не работает - такой же результ как и в посте

.find().projection({_id: 0})

console.log(databasesAndCollections.find().projection({_id: 0})); ^ TypeError: databasesAndCollections.find(...).projection is not a function at getDatabasesAndCollections (E:\Progi3\Trading-tester-vanilla-node\models\currencyModel.js:28:46) at processTicksAndRejections (node:internal/process/task_queues:96:5) Process finished with exit code 1

console.log(databasesAndCollections.find().projection({_id: 0})); ^ TypeError: databasesAndCollections.find(...).projection is not a function at getDatabasesAndCollections (E:\Progi3\Trading-tester-vanilla-node\models\currencyModel.js:28:46) at processTicksAndRejections (node:internal/process/task_queues:96:5) Process finished with exit code 1

.find({}, { projection: { _id: 0 } })

как и в первом варианте результат

E:\Downloads\Node\proga\node.exe E:\Progi3\Trading-tester-vanilla-node\models\currencyModel.js FindCursor { _events: [Object: null prototype] {}, _eventsCount: 0, _maxListeners: undefined, [Symbol(kCapture)]: false, [Symbol(topology)]: Topology { _events: [Object: null prototype] { open: [Function], connectionPoolCreated: [Function (anonymous)], connectionPoolClosed: [Function (anonymous)], connectionCreated: [Function (anonymous)], connectionReady: [Function (anonymous)], connectionClosed: [Function (anonymous)], connectionCheckOutStarted: [Function (anonymous)], connectionCheckOutFailed: [Function (anonymous)], connectionCheckedOut: [Function (anonymous)], connectionCheckedIn: [Function (anonymous)], connectionPoolCleared: [Function (anonymous)], commandStarted: [Function (anonymous)], commandSucceeded: [Function (anonymous)], commandFailed: [Function (anonymous)], serverOpening: [Function (anonymous)], serverClosed: [Function (anonymous)], serverDescriptionChanged: [Function (anonymous)], topologyOpening: [Function (anonymous)], topologyClosed: [Function (anonymous)], topologyDescriptionChanged: [Function (anonymous)], error: [Function (anonymous)], timeout: [Function (anonymous)], close: [Function (anonymous)], serverHeartbeatStarted: [Function (anonymous)], serverHeartbeatSucceeded: [Function (anonymous)], serverHeartbeatFailed: [Function (anonymous)] }, _eventsCount: 26, _maxListeners: undefined, bson: [Object: null prototype] { serialize: [Function: serialize], deserialize: [Function: deserialize] }, s: { id: 0, options: [Object: null prototype], seedlist: [Array], state: 'connecting', description: [TopologyDescription], serverSelectionTimeoutMS: 30000, heartbeatFrequencyMS: 10000, minHeartbeatFrequencyMS: 500, servers: [Map], sessionPool: [ServerSessionPool], sessions: Set(0) {}, credentials: undefined, clusterTime: undefined, connectionTimers: Set(0) {}, detectShardedTopology: [Function: detectShardedTopology], detectSrvRecords: [Function: detectSrvRecords] }, [Symbol(kCapture)]: false, [Symbol(waitQueue)]: Denque { _head: 1, _tail: 2, _capacity: undefined, _capacityMask: 3, _list: [Array] } }, [Symbol(namespace)]: MongoDBNamespace { db: 'startInitialization', collection: 'databases&Collections' }, [Symbol(documents)]: [], [Symbol(initialized)]: false, [Symbol(closed)]: false, [Symbol(killed)]: false, [Symbol(options)]: { readPreference: ReadPreference { mode: 'primary', tags: undefined, hedge: undefined, maxStalenessSeconds: undefined, minWireVersion: undefined }, fieldsAsRaw: {}, promoteValues: true, promoteBuffers: false, promoteLongs: true, serializeFunctions: false, ignoreUndefined: false, bsonRegExp: false, raw: false, enableUtf8Validation: true }, [Symbol(filter)]: {}, [Symbol(builtOptions)]: { projection: { _id: 0 }, raw: false, promoteLongs: true, promoteValues: true, promoteBuffers: false, ignoreUndefined: false, bsonRegExp: false, serializeFunctions: false, fieldsAsRaw: {}, enableUtf8Validation: true, readPreference: ReadPreference { mode: 'primary', tags: undefined, hedge: undefined, maxStalenessSeconds: undefined, minWireVersion: undefined } } }

await надо и toArray

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

я не смогу добавить больше 100 элементов в массив?

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

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

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

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

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

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

да вообще не парься тогда, я думал как у меня от 50кк до 150кк обновлений 1 раз в полдня

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

извините, которую?

Кто может подсказать, как корректно проапдейдить нужный survey? Пробовал такой вариант await Post.findByIdAndUpdate(postId, { [`survey[${optionIndex}].voters`]: { $push: userId } }); - не работает

Кто может подсказать, как корректно проапдейдить нужный survey? Пробовал такой вариант await Post.findByIdAndUpdate(postId, { [`survey[${optionIndex}].voters`]: { $push: userId } }); - не работает

В вашем случае вы находите $$ROOT документ, а вам надо сначала найти $$ROOT, а потом уже в нем искать через $elementMatch нужный в массиве и уже туда делать push

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

А причем тут агрегация?

Это работает в обычном find

Тогда не понимаю, зачем нужен елемМатч, у меня есть айди документа, есть индекс конкретного элемента массива survey, но пуш туда не работает(вероятно я неправильный синтаксис использую)

Если вы не хотите использовать $elementMatch, то вот решение .findOneAndUpdate({ _id: new ObjectId('63b42ade113ad025eceefdee')}, { $push: { [`survey.${id}.voters`]: 'c-7' } })