а что является источником событий?

а что является источником событий?

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

по емейлу? хех

могли и смсками

;)

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

устройства ваши или третей стороны?

и всетаки напишите что потом с этими данными делается?

может и не нужно ничего агрегировать

устройства ваши или третей стороны?

не наши

пиплометры какиенибудь?

они данные отправляют пачками или когда событие происходит?

может и не нужно ничего агрегировать

данные выводятся на графике. если ничего не агрегировать, а н-р просто, если одно из значений отсутствует подставлять его по какому-то правилу самостоятельно(например +-10 сек), но это получатся разные отрезки, если разница между концом и началом на самом деле больше 10 сек. Хотя если учесть в каком виде приходят данные, то возможно я к этому и приду))

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

либо додумывайте, но это ужасная идея

лучше на графике показать что есть «дырка»

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

а вообще, проанализируйте данные

электронная почта это совсем плохо, потому что она совсем никаких гарантий не даёт, но вероятно есть какое-то практическое окно, в которое данные укладываются

почтовый сервер тоже не ваш?

электронная почта это совсем плохо, потому что она совсем никаких гарантий не даёт, но вероятно есть какое-то практическое окно, в которое данные укладываются

да, вероятно конечно что задержек слишком больших не будет. Но это не гарантия. События перед попаданием в БД еще проходят через брокер сообщений, и там уже организуются в пачки. Возможно стоит обратить на это место внимание, и консистентность поддерживать на этом уровне. Но опять же email никуда не уходит, а именно он тут кажется самим больным местом. Буду исследовать дальше.

@dd_bb @yatoba спасибо

изучите заголовки писем, возможно там есть какие-то отметки которые можно как счётчик использовать

Подскажите, что оптимальней использовать монго или другую базу для хранения вершин древовидного графа one to many, храню каждую вершину как json

Подскажите, что оптимальней использовать монго или другую базу для хранения вершин древовидного графа one to many, храню каждую вершину как json

Смотря что планируется с этим потом делать. И какие объемы данных планируется хранить. А так вроде бы в задаче нет ничего такого для чего нужен NoSQL

Смотря что планируется с этим потом делать. И какие объемы данных планируется хранить. А так вроде бы в задаче нет ничего такого для чего нужен NoSQL

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

Куча селектов

Как мне кажется проще и быстрей будет на обычном SQL. Две таблички - одну для хранения информации об узлах. А вторую для организации связи между узлами. Задача классическая и вроде бы все подводные камни известны.

Как мне кажется проще и быстрей будет на обычном SQL. Две таблички - одну для хранения информации об узлах. А вторую для организации связи между узлами. Задача классическая и вроде бы все подводные камни известны.

Json разве не легче? Что быстрее извлечение 1 документа из монго или селект с джойном?) Или может селект с жсоном, но sql

Json разве не легче? Что быстрее извлечение 1 документа из монго или селект с джойном?) Или может селект с жсоном, но sql

Ну если только все дерево "запихнуть" в один документ. Но точно так же можно JSON записать и в любую SQL БД - все равно одна запись. Или вообще в файл на диске. И в мемкеше каком-нибудь держать.

Ну если только все дерево "запихнуть" в один документ. Но точно так же можно JSON записать и в любую SQL БД - все равно одна запись. Или вообще в файл на диске. И в мемкеше каком-нибудь держать.

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

Ну и отталкиваться надо от задачи. Если например нужно будет узлы вставлять внутрь дерева - то это переписывание всего документа (кстати даже при обычном добавлении узла в листам дерева). В SQL - это пара insert и один-два update на "легких" записях.

По-хорошему они только внизу апдейтятся

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

Ну значит в монго это будет один документ на один узел. Единственный плюс - в узле можно хранить список id его "деток". Но их придется доставать отдельным запросом. Либо что-то городить с рекурсией внтури монго. В SQL дерево достается одним запросом к базе (особенно если немного денормализовать данные).

Ну значит в монго это будет один документ на один узел. Единственный плюс - в узле можно хранить список id его "деток". Но их придется доставать отдельным запросом. Либо что-то городить с рекурсией внтури монго. В SQL дерево достается одним запросом к базе (особенно если немного денормализовать данные).

Как именно в sql? Там ведь дочерних может быть и 10 и 20 и 1 и 2)

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

Наверное добавить таблицу с индексами и соединить one to many с этой же, но там есть вес у каждого соединяющего вектора типа

Как именно в sql? Там ведь дочерних может быть и 10 и 20 и 1 и 2)

Ну это уже не для этого чата вопрос. Но в том же PostgreSQL есть такой тип как jsonb - для работы с json. Есть тип "массив". Если у вас идет упрощение, что добавляем записи с низу, то например делаем для узла поле "уровень" - т.е. корень это 0 и дальше оно увеличивается. Дальше в каждом узле храним массив id его дочерних элементов и массив с id-шниками пути от корня до этого элемента.

В этом случае одним запросом вытаскиваются все элементы у которых в "пути" есть id элемента от которого нужно рисовать дерева. Сортировка по уровню дает возможность начинать с верхних узлов. И по детям можно отрисовывать в виде рекурсии. Или же формировать данные для отрисовки.

В этом случае одним запросом вытаскиваются все элементы у которых в "пути" есть id элемента от которого нужно рисовать дерева. Сортировка по уровню дает возможность начинать с верхних узлов. И по детям можно отрисовывать в виде рекурсии. Или же формировать данные для отрисовки.

Неплохая мысль... Я думала изначально рекурсию, но извлекать тоже хотела рекурсивно. Но это куча селектов, это ничего страшного? В принципе в интерфейсе там анимация отрисовки и оно точно не фатально, но хочется оптимально)

Неплохая мысль... Я думала изначально рекурсию, но извлекать тоже хотела рекурсивно. Но это куча селектов, это ничего страшного? В принципе в интерфейсе там анимация отрисовки и оно точно не фатально, но хочется оптимально)

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

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

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

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

сейчас это уже както реализовано? или пока на стадии планирваония

сейчас это уже както реализовано? или пока на стадии планирваония

Нет, надо хотя-бы выбрать хранилище, думала каждый граф документом хранить, это и подтолкнуло к монго

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

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

Дерево просто

С одной вершины начинается

изучите варианты https://docs.mongodb.com/manual/applications/data-models-tree-structures/

Но эта вершина может быть любой

критерий только как вы будете выборки делать. как определяется какой из узлов надо доставть?

критерий только как вы будете выборки делать. как определяется какой из узлов надо доставть?

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

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

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

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

как происходит добавлени/удаление узлов?

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

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

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

объем?

объем?

Небольшой, можно задать максимум уровней и максимум в ширь, гиганское что-то не нужно, точнее хранить можно но это отрисовывать никому не надо, нужна читабельность. По-этому уровней штук ну 50 максимум. В ширь тоже 50, но это лютейшие цифры, как правило 10 уровней и где-то 3-10 в ширь. В принципе они могут быть большими. Но точно не гигабайты данных на 1 граф. Хранить бы хотелось большой, но выводить с лимитами

В общем, большой, но не огромный на гигабайты

Пару тысяч связей

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

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

Выводится не всё, но хранится всё должно, да

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

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

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

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

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

Посмотрю, я в монго слабо очень пока-что

ничего сложного, m.path реализуется впринципе на любой бд

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

если сформируются более четкие требования то можете еще глянуть на https://docs.mongodb.com/manual/reference/operator/aggregation/graphLookup/

ничего сложного, m.path реализуется впринципе на любой бд

Тогда попробую в mysql в json хранить или jsonb. Но при редактировании там с памятью беда будет) когда добавление новых вершин и тд.

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

ваши данные плоские

данные в узлах

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

Кстати, да но тогда надо отдельно таблицу связей

необязательно

А как тогда? Там же one to many

id,path,dateTime,v1,v2,v3,v4

Path хм

выборки по path like '%SOME_NAME%'

тоже самое будет и в монге