очень не популярный в ноде подход

на всяких уроках)

плохие уроки - учат плохому (

flash из рельс наверное, но подход старомоден, да

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

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

rabbitmq

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

rabbitmq

Я же написал мне нужна структура данных, а не брокер сообщений.

Здесь не нужно ничего готового, просто напиши что тебе нужно

Строк 20 займет, примерно

Я же написал мне нужна структура данных, а не брокер сообщений.

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

Если ж не - то и правда сам напиши. Что там ее писать

Не понял, а что все свою структуру очереди всегда пишут сами или как ?

Почему нет?

че там писать то? засунул-высунул

Введи в нпм queue и найди подходящий

Всем привет Подскажите как можно сделать Битовую маску из диапазона дат например 20.08.17 - 29.08.17 сделать в маску а потом при сравнении 21.08.17 - 26.08.17 === true

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

а причем тут битовые маски?

ну думаю както через них реализовать

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

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

трудно жить без интервалов

вообще в этой задаче у тебя есть min, max и ты сравниваешь просто вхождение этот интервал другого интервала

зачем тут маски

О_о

нет не подходит

у меня база большая

сколько элементов?

вобщем это бронирование квартиры

//битовые маски точно левые тут

есть комнаты у них есть отдельно даты когда они могут быть бронированны

у меня база большая

и что? btree вроде не отменили еще.

вот например 25 - 28,28 -30 а человек выбрал с 25 по 30 и должно найти эту комнату

ну пока 1 миллион записей комнат но в дальнейшем будет рости

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

да

и это отдельная коллекция с интервалами

попробуй кешировать, лол

что именно кешировать ?

запросы типа from - to на поиск комнат

так в том то и дело такое не находит тогда

вот например 25 - 28,28 -30 а человек выбрал с 25 по 30 и должно найти эту комнату

вот это

вот это

в примере не рванный интервал

что довольно странно

ну да пока такое не находит но должно

так как люди хотят в разные даты разные цены ставить

ну так сделай его непрерывным

битмаски это хорошо на короткий срок, а лукапы на отдаленное будущее нужно отдельно смотреть

так как люди хотят в разные даты разные цены ставить

вот это дело третье

и с битмасками хорошо редиска как раз работает

да как хранить их уже проблема вторая

мне бы как бы сделать само решение )

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

причем здесь вообще битмаски?

а их удобно сравнивать

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

новое слово в алгоритмах

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

да тут должен быть стандартный композитный btree index

т.е. например по 60 дней

и обычный запрос

index(from, to) запрос from <= query_from AND to >= query_to делов-то

ну может и так

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

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

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

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

угу

точнее ему под бронирования нужно отдельный релейшен делать

что думаете если 25-28,28-30 записать в бд комнату 25-30 и делать уже выборку тут

как вобще mongo хорошо относится к сравнениями с датами

а где хранить пересекающие границы отрезки?

так как и храню в отдельной коллекции

как вобще mongo хорошо относится к сравнениями с датами

по сути хранится таймштамп

mongoose хранит date не timestamp

лутше сделать number?

а, там монго )

всмысле монга хранит как число подобно таймштампу

как вобще mongo хорошо относится к сравнениями с датами

да оно и так по сути timestamp

>Internally, Date objects are stored as a 64 bit integer representing the number of milliseconds since the Unix epoch (Jan 1, 1970), which results in a representable date range of about 290 millions years into the past and future.