Вы меня не поняли немного, я использую промисы и генераторы нативные, у меня проблемка так как приложение работает ни как сервер, а как приложение которое обслуживает базу данных, работает с api других систем, запускает множество процессов, типа взять с одной коллекции данные обработать, перенести в другую, получить данные с api сервиса. Мне надо как то организовать запуск этих процессов(модулей/функций) и контролировать их. Сами процессы(модули) уже сделаны, надо как то организовать их запуск, прерывание, контроль.
Да мне нужно знать сколько 8 и другие, которые в основной запрос не вошли и узнать сколько раз повторяются. Могу по другому логику представит, юзер запрашивает, покажите мне документы с свойствами 1,5,9,30,99, приложение показывает, но так же приложение должно предложить еще свойства, по которым он еще глубже может сузить выбору документов. Я смог алгоритм представить в таком виде, берем то что спрашивает юзер, показываем, заодно считает совпадения свойств в тех документах, которые показали (не берем те свойства по которым спрашивали, так их и так уже показали), за счёт анализа повторения, дабы предложить, только то что может еще сузить, а не показать пустой результат. Конечно, можно попробовать обработать все пачку в самом приложение (nodejs), но если вдруг выборка будет в 30 000 -40000 документов, то боюсь будут большие проблемы. База справиться лучше, как я думаю.
db.collect.find({"properties": {$all:[1,3,5, 100]}}), но мне 1,3,5,100 не интересны, так как если придет ответ, есть что показать, мне интересны 4,6,7,8,8...99 если они есть в массиве в properties, то узнать сколько они раз повторяются в данной выборке.
Вся фишка что в вашем примере мне количество повторений 1,2,3 не нужно, нужные остальные свойства, если оно сколько кто повторяется. forEach вы почему имеете виду пройтись?) я пока не представляю как массив в group представить)
Ну типо того, каждый документ содержит различные properties записанные в виде цифр в массивы в поле properties. Само количество properties в принципе не важно, но я думаю не более 100 их будет. Каждый документ может хранить разное количество свойств. Я начал копать в строну агрегации, типа делаем math и указываем какие цифры должны быть ($all) в массиве в поле properties, а дальше уже как то надо посчитать их совпадения во всех документах, которые получаем при условие math. Можно конечно пойти другим путем, хранить свойства не массиве в одном field, а хранить каждое свойство в отдельном field, при такой схеме тоже не придумал как посчитать совпадения( Да и увеличивать документ не хотелось бы в размерах.
Если имеете виду перебирать всю базу по свойствам и хранить количество документов в которых встречается, то такой метод увы не подойдет. Такой вот запрос
db.collect.find({"properties": {$all:[1,2,3]}})
создаст уникальное количество документов, в котором уже надо считать повторения.
Да штука однозначно мощней получиться, но в итоге найденные объекты с характеристиками надо еще в каком то виде нормальном хранить. Приводить слова в какой то единый формат, к примеру все глаголы привести к первой форме "work вместо worked" и т.д. Надо подумать над нормализацией данных.
Я правильно понимаю, вы имеете виду вытянуть данные с текста используя к примеру wordpos, к примеру вытягиваем существительные, и потом бегая по дереву пытаемся найти его характеристики, на основе типов речи?
Ну у меня английские тексты (классику тоже не планирую), русский даже страшно представить как разбирать) А у меня именно задача и стоит, по словарям определять те или иные моменты текста. Плюс тексты буду узкой тематики, под них словарь не очень сложно составить. Общие темы в планах разбирать нет. Поищу про данный тип деревьев (может расширю свою задачу для полного автомата), правда загуглил, не нашел пока ничего по данному типу деревьев.
xmoonlight: У меня будет поиск по вхождения:
1. Красный - уточнение, дом - объект, нашли слово дом сместились левее нашли форму слова красный, межу словом красный и дом
нет, существительного или местоимения, которые могли бы забрать утверждение, соответственно true.
2. Свой дом - по принципу из 1 пункта вернется true.
3. Тут вероятней всего запрос будет такой: объект ежик, уточнений большой. Нашли ежик, погуляли влево и вправо, не нашли слово большой, вернули false.
4. поиск будет, объект: дом, уточнений: тесный, по принципу из 1 пункта вернет true.
5. Действия я пока не рассматриваю. Только объекты и их характеристики. Хотя по принципу можно так же:
объект: ежик уточнение: прыгать. Находим ежик, потом словоформу "прыгать", изучаем отрезок между объектом и уточнением,
понимаем что там нет типа речи, который мог бы забрать на себя уточнение, соответственно алгоритм вернет true.
Итого мой примерный словарь для анализа статей про ежиков будет такой:
{
объект: дом,
уточнение: красный
}
{
объект: дом,
уточнение: свой
}
{
объект: ежик,
уточнение: большой
}
{
объект: ежик,
уточнение: прыгать
}
Еще можно расширить уточнения, на более абстрактный уровень
{
объект: ежик,
уточнение: прыгать, летать, бегать
}
Ну типо когда нужно определить обладает ли ежик супер силами)))))
Если одно из уточнений найдется, то ежик необычный))))
Я думаю можно конечно, за счёт анализа типов речи вычеслять объекты и их свойства без словарей,
но система рухнет, если текст вдруг будет сленговый, или еще какой нестандартный.
Доработал мысль о анализе растекание влево и в право, если контекст нашли левее, конткекст по сути это почти всегда прилагательное, причастие - то что описывает объект (объект всегда существительное). Получается нашли объект растеклись левее на заданный диапазон, нашли контекст и от точки контекста идём в строну объекта, и смотрим попадется ли нам тот тип речи, которые может взять на себя контекст. Если нашелся, то навряд ли это контекст. Вроде должно сработать, поправьте если видите недочеты)
незнаю меня наоборот утомляет рутинные задачи, больше захватывает делать что то сложное, хотя весь мой кодинг, это пока больше хобби чем работа, работа в другой сфере) но тоже it.
https://github.com/neopunisher/pos-js -хотя вот либа, определяет тип речи порядок слов можно сохранить нужный. Замерил скорость, 375 слов обработало за 0.484 мс, это здорово)
Да это самое вкусное, но в принципе и увлекательно занятие, в таких задача и проявляется вся крутость от занятия кодингом) В этой схеме я пока остановился на вопросе, как определить тип речи у слова. И еще внес правку что растекаться надо как влево так и в право. По принципу "green ball" и "ball is green" - два варианта допустимы.
Вообще пока представил себе такой метод. Заносим весь текст в массив по словам, потом каждую единицу массива разбираем к какой речи она относиться.
Для простого поиска слова, используя стемминг смотрим если ли данное слово в последовательность если есть значит ок.
Если слова требует какого контекста, к примеру что ежик был зеленый, значит основной объект это ежик, находим его в последовательности(стемминг), потом смешаемся левее и смотрим какие там единицы слов с типами речи.
Получается что если нашли слово "ежик" смешаемся левее к примеру на 10 слов, находим слово зеленый, то нам нужно оценить какие типы речи находятся между контекстом "зеленый" и "ежик", если вдруг находим после слова зеленый существительное, значит потерян контекст поиска, и вхождение не найдено. Пока мозг взрывает, оценка этого промежутка между контекстом и объектом, по каким правилам понимать, что контекст не относиться или относиться к объекту.