powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Программирование [игнор отключен] [закрыт для гостей] / SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
3 сообщений из 53, страница 3 из 3
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39770667
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ролг Хупинmaytonпропущено...

Возможно ты не понимаешь как работает поиск в графах.

Для того чтобы он работал быстро. Вершина должна содержать в себе список инцедентрых ребер.

Если ребра "физически" хранятся в разных местах таблицы в БД. То на сборку путей будет потрачено
большое число IOPS.

Возможно ты и понимаешь, я не в курсе, допустим.

"Вершина должна содержать в себе список инцедентрых ребер."

Нет, это не обязательно, в базах есть еще и индексы.
Индексы не решают всех проблем. К примеру кластеризация данных вокруг поисковых ключей.
Это немаловажно когда у тебя таблица перевалила за 10-100 Гб.

Как работает Нептун с большим объемом - пока я не знаю. Судя по конфигурации он - In-Memory
но это коробочное решение для поиска в графах. А если есть заказ на такие решения
то очевидно что преимущества Нептуна должны быть.

По поводу хранения графовых данных в реляционках. Apache Jena содержит в себе адаптеры
для этого (SDB). И я их собираюсь подвергнуть бенчарку. Технически - я знаю как. Единсвенное
что я пока не определеилися это какую взять базу знаний. И какие к ней писать запросы.

Типичный запрос к такой базе может выглядеть как - найти всех людей (Persons) которые
связывают тебя с Королевой Англии. (К примеру).
...
Рейтинг: 0 / 0
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39770796
Ролг Хупин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonРолг Хупинпропущено...


Возможно ты и понимаешь, я не в курсе, допустим.

"Вершина должна содержать в себе список инцедентрых ребер."

Нет, это не обязательно, в базах есть еще и индексы.
Индексы не решают всех проблем. К примеру кластеризация данных вокруг поисковых ключей.
Это немаловажно когда у тебя таблица перевалила за 10-100 Гб.

Как работает Нептун с большим объемом - пока я не знаю. Судя по конфигурации он - In-Memory
но это коробочное решение для поиска в графах. А если есть заказ на такие решения
то очевидно что преимущества Нептуна должны быть.

По поводу хранения графовых данных в реляционках. Apache Jena содержит в себе адаптеры
для этого (SDB). И я их собираюсь подвергнуть бенчарку. Технически - я знаю как. Единсвенное
что я пока не определеилися это какую взять базу знаний. И какие к ней писать запросы.

Типичный запрос к такой базе может выглядеть как - найти всех людей (Persons) которые
связывают тебя с Королевой Англии. (К примеру).


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

Я не в курсе как устроено все внутри OrientDB, но там утверждается, что база и реляционная, и графовая
...
Рейтинг: 0 / 0
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39770807
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
По тестам будет отдельный топик. Если у меня руки дойдут.
...
Рейтинг: 0 / 0
3 сообщений из 53, страница 3 из 3
Форумы / Программирование [игнор отключен] [закрыт для гостей] / SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]