Поддерживает ли OrientDB эффективные вычисления connected components?Как вычислить связанные компоненты в OrientDB
У меня нет опыта работы с базами данных графов. Моя наивная интуиция заключается в том, что эта операция должна быть достаточно эффективной.
Если это эффективно поддерживается, как бы выглядел запрос, чтобы найти все подключенные компоненты?
У меня был свой же вопрос, но я, наконец, в конечном итоге написание запроса OSQL для вычисления компонент связности в графе, здесь my solution
Ниже приведена выдержка из OrientDB website. Я выделил несколько соответствующих частей.
OrientDB может вставлять документы, подобные любой другой базе данных документов, но также поддерживает отношения. Он не использует дорогостоящий JOIN. Вместо этого OrientDB использует сверхбыстрые, постоянные указатели между записями, взятыми из мира базы данных графа. Вы можете перемещать части или целые деревья и диаграммы записей всего за несколько миллисекунд.
На этой иллюстрации показано, как исходный документ был , который был разделен на два документа, связанных с использованием идентификатора записи клиента № 8: 124 для подключения заказа к документу клиента. Ссылки можно рассматривать как как указатели в памяти, но упорные на диске.
[надрез]
Оснащено документа и реляционных СУБД, тем больше данных вы , тем медленнее база данных будет. Соединения имеют тяжелую продолжительность работы . Вместо этого OrientDB обрабатывает отношения как физические ссылки на записи , назначенные только один раз, когда ребро создается O (1). Сравните это в СУБД, которая «вычисляет» отношения каждый раз вы запрашиваете базу данных O (LogN). С OrientDB скорость перемещения не равна , что зависит от размера базы данных. Он всегда постоянный, будь то один номер или 100 миллиардов записей. Это критическое значение в возрасте от Данные!
И вот пример запроса, взятого из tutorial document, который получит всех друзей человека, которого называют Luca.
SELECT EXPAND(BOTH('Friend')) FROM Person WHERE name = 'Luca'