А лучше сделать так: const date = Date.now - SOME_INTERVAL; model.find({ScannedOn: {$lte: date}}) И не хранить интервалы в базе, а оставить как есть дату последнего сканирования

Это хорошо, когда интервалы везде одинаковые

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

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

Это вполне себе нормально.

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

Бизнес так хочет™

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

особенно если ресурс может отвечать 429

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

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

Ребята, мне нужно бэкенд собрать с авторизацией

Что заюзать для авторизации?

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

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

Токен хранить в localStorage, а в монге хранить email и hashPassword

Что заюзать для авторизации?

Если самому не хочется писать, заюзай Firebase

На клиенте можешь получать jwt, будь это js, ios, android

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

юзеры будут в firebase храниться

https://www.rdegges.com/2018/please-stop-using-local-storage/

в firebase можно хранить другие данные, кроме пользователей?

что про это скажете?

в firebase можно хранить другие данные, кроме пользователей?

firebase database, там лимит

ну на своём бэке можешь хранить

firebase database это уже замена бэку

с базой данных и авторизацией

кому в личку могу побомбить сообщениями? с меня пиво рублей на 500

могу тебе кинуть просто чисто мой бекенд там все это есть

даже один протектед роут

вау, спасибо, посмотрю

👍

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

хочу понять, что быстрее 1) поиск ключевого слова в одном большом елемнте коллекции 2) поиск ключевого слова среди 1000чи елементов колекции

это как считать весь файл а потом парсить или считывать построчно и парсить

Пока непонятно. Что значит считывание последовательно одного элемента? Он полностью грузится. Как его одного последовательно грузить? Если надо вывести только некоторые поля элемента - да, возможно.

хочу понять, что быстрее 1) поиск ключевого слова в одном большом елемнте коллекции 2) поиск ключевого слова среди 1000чи елементов колекции

А пример данных можно?

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

А пример данных можно?

нелья) и они тут не причем я про алгоритм работы

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

индекс исключен из уравнения

хорошо скажу проще я хочу считать первый символ из елемента коллекции размером в 1TB

Так по определению 1000 элементов будет дольше искать, чем 1

что он сделает?

Так по определению 1000 элементов будет дольше искать, чем 1

те 1 елемент размером 1TB быстрее чем 1000 елементов (в сумме 1TB)

Так понимаю: цель - хранить файлы (видео) в коллекции? Бинарники

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

Проще в ней хранить ссылки на файлы, а сами файлы в какой-нибудь распределенной glusterfs

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

блииин я не про как хранить а про то как он читает это всё

но выше изложенная инфа тоже интересна

блииин я не про как хранить а про то как он читает это всё

Ну так я ещё раз спрашиваю, ты хочешь вытянуть потоком бинарный файл или просто какое-то поле? Потому что бд не выдает элемент коллекции потоком. Он выдает его полностью. Но можно поля обрезать и вытянуть только нужные.

Ну так я ещё раз спрашиваю, ты хочешь вытянуть потоком бинарный файл или просто какое-то поле? Потому что бд не выдает элемент коллекции потоком. Он выдает его полностью. Но можно поля обрезать и вытянуть только нужные.

Во! Тоесть если я захочу спарсить то что находится в начале - он сначала загрузит ВСЮ страницу в оперативу и а только потом будет парсить... Поле это ключ? т.е {key : val}

Нет, бинарники хранить не думаю

Во! Тоесть если я захочу спарсить то что находится в начале - он сначала загрузит ВСЮ страницу в оперативу и а только потом будет парсить... Поле это ключ? т.е {key : val}

Да, поле=ключ. Да, а может и сразу из памяти возьмёт. Он хорошо кэшит данные в память.

А грузить данные потоком (ну то есть получить первый символ, потом второй и т.д.) он может, но вроде только бинарные.

Понятно. Интересно мнение: что лучше 1)большой json 2) разбитый на елементы коллекции json со ссылками друг на друга

Понятно. Интересно мнение: что лучше 1)большой json 2) разбитый на елементы коллекции json со ссылками друг на друга

Это только от будущих запросов зависит.

К примеру большой mind map

Бд не для высокой нагрузки от большого кол-ва юзеров

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

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

Понял, минимизация запросов

Ну типа здесь рулят антипаттерны реляционщины )) сплошная денормализация

Если планируется считывать конкретное поле(типо многоразовое), то, мне: 1) Считать его из большого json? 2) вынести в отдельный елемент коллекции и оставить ссылку на него в большом?

Типо это поле может быть самостоятельной единицей и часть большого json

Если планируется считывать конкретное поле(типо многоразовое), то, мне: 1) Считать его из большого json? 2) вынести в отдельный елемент коллекции и оставить ссылку на него в большом?

Можно сделать "проекцию", где можешь указать, какие поля нужны. Аналог select col from table

Я правильно понял?

Можно сделать "проекцию", где можешь указать, какие поля нужны. Аналог select col from table

Не совсем тот случай)

Тут скорей вложенность

Как папка внутри папки

Типо твой пример для 2d а у меня 3d

Или ты имеешь ввиду, что у тебя есть коллекция условных яблок и есть коллекция корзин и тебе надо, чтобы в корзине был список (list) каких то определенных яблок

Нее, корзины с яблоками в одном елементе коллекции

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

И она в той куче

🤪

О, придумал

На самом деле лучше показать пример )) пускай из корзин и яблок )

Есть два mind mapa (2 елемента коллекции, сама коллекция одна)

И у них есть общие поля

Так