#graph #neo4j #graph-databases
#График #neo4j #базы данных графиков
Вопрос:
У меня есть приложение, которое хранит информацию об отношениях в таблице MySQL (contact_id, other_contact_id, strength, recorded_at). Это нормально, если все, что мне нужно сделать, это показать, с кем связаны контакты, или даже сгенерировать список общих контактов для двух контактов.
Но теперь мне нужно сгенерировать статистику типа: «каково было общее количество двухсторонних подключений силой 3 или выше в январе 2011 года» или (при условии, что каждый контакт является частью группы) «какая группа имеет наибольшее количество подключений к другим группам» и т.д.
Я быстро обнаружил, что SQL для генерации этих статистических данных очень быстро стал громоздким.
Итак, я написал скрипт, который для любой заданной даты будет генерировать график в памяти. Затем я мог бы запускать любую статистику, которую я хотел, для этого графика. Намного проще для понимания и, в целом, намного производительнее — за исключением части генерации графика.
Моей следующей мыслью было кэшировать эти графики, чтобы я мог обращаться к ним всякий раз, когда мне нужно было запустить новую статистику (или сгенерировать более поздний график: например, для сегодняшнего графика я беру вчерашний график и применяю все изменения, которые произошли со вчерашнего дня). Я попробовал memcached, который отлично работал, пока графики не выросли более чем на 1 МБ.
Итак, теперь я подумываю об использовании базы данных графиков, такой как Neo4J.
Единственная проблема в том, что у меня нет только одного графика. Или я делаю, но это тот, который меняется со временем, и мне нужно иметь возможность запрашивать его с разным исходным временем.
Итак, могу ли я:
- хранить несколько графиков в Neo4J и повторно проверять / взаимодействовать с ними по отдельности? затем я бы создал и сохранил отдельные социальные графики для каждой даты.
или
- добавьте допустимые временные метки для каждого ребра и соответствующим образом отфильтруйте график: поэтому, если бы мне нужен был график для «1 мая», я бы следил только за самым новым ребром между двумя нулевыми значениями, которое было создано до «1 мая» (и если бы все ребра были созданы после 1 мая, тогда эти узлы не были бы соединены).
Я довольно новичок в графических базах данных, поэтому буду признателен за любую помощь / указатели / подсказки.
Комментарии:
1. после некоторого чтения мне интересно, являются ли ссылочные узлы ключевыми? я мог бы создать опорный узел для каждого дня, а затем построить график этого дня на основе его опорного узла…
2. Привет, я думаю, что здесь может помочь использование узлов exntry для графиков и, возможно, индексирование их с помощью некоторого свойства, чтобы вы могли находить их не только по ссылочному узлу, но и с помощью поиска по индексу. Даст ли индексация определенных свойств «метаданных» ваших входных узлов подграфа правильные отправные точки?
Ответ №1:
Прямо сейчас вы можете хранить только одну базу данных графиков в одном экземпляре Neo4j, но эта база данных graphdb может содержать столько различных вложенных графиков, сколько вам захочется. Вам нужно помнить об этом только при выполнении глобальных операций (например, индексных запросов), но там вы можете выполнять составные запросы, которые также включают свойства с меткой времени, чтобы ограничить результаты.
Один из способов сделать это, как вы сказали, добавив временную информацию к ребрам для представления структуры графика на заданную дату, вы можете затем просмотреть структуру графика назад.
Ссылочный узел имеет другое значение в Neo4j.
Ежедневное использование узлов категории (и их связывание, а также агрегирование для временных интервалов более высокого уровня) — это более графический способ категоризации узлов, чем индексированные свойства. (Фактически это встроенные индексы, которые вы можете легко включить в свои обходы и графические запросы).
Вам не нужно дублировать узлы, если вас интересуют только разные временные структуры. Если ваши узлы также отличаются (например, изменяются свойства, вы можете либо дублировать их, и таким образом эффективно создавать разные подграфы), либо создать связанный список узлов истории на каждом узле, которые содержат только изменения (или полный снимок в зависимости от ваших требований).
Ваш домен очень подходит для базы данных graph. Если у вас есть более подробные вопросы, не стесняйтесь присоединиться к списку рассылки Neo4j.
Комментарии:
1. Ссылка на список рассылки недоступна
Ответ №2:
Не самое простое решение (я предполагаю, что вы работаете только с одной машиной), но если вы действительно хотите разделить свои графики, вам нужно только помнить, что график — это каталог.
Затем вы можете создать класс динамического загрузчика, который использует путь к нужной вам базе данных, загрузить его в память для запроса и закрыть после получения ответа. Вы также можете настроить прокси-сервер и отправить своему загрузчику 2 параметра: ваш запрос (который, я полагаю, в данном случае является запросом cypher) и путь к базе данных, к которой вы хотите запросить.
Этого недостаточно, если вам нужно ответить на множество запросов в реальном времени. Но если это просто для хранения и выполнения некоторой аналитики по наборам данных, это может определенно удовлетворить ваши потребности.
Комментарии:
1. можете ли вы пролить некоторый свет на то, как динамически ссылаться на путь к базе данных graph в запросе cypher. Заранее спасибо…
Ответ №3:
Это старый вопрос, но, начиная с Neo4j 4.x, поддерживается многопользовательская аренда, и на одном сервере Neo4j могут быть разные базы данных (с различными разрешениями RBAC).