Тема: Устройство rdf хранилища

Есть такой вопрос, все ли rdf хранилища в основе своей строятся на реляционных БД? Если да, то во всех них задача в основном сводится к трансляции SPARQL в SQL запросы. Так ли это?
Если же не все так организованы, то можно ли примеры?
И еще вопрос, какова плотность хранения. Другими словами где найти информацию о том, сколько байт тратится на хранение к примеру одной тройки в среднем.

2

Re: Устройство rdf хранилища

DenisKoronchik пишет:

Есть такой вопрос, все ли rdf хранилища в основе своей строятся на реляционных БД? Если да, то во всех них задача в основном сводится к трансляции SPARQL в SQL запросы. Так ли это?

Нет.

DenisKoronchik пишет:

Если же не все так организованы, то можно ли примеры?

Ну я один из разработчиков Stardog. Ничего реляционного там не было с первого дня. + тот же AllegroGraph и другие.

DenisKoronchik пишет:

И еще вопрос, какова плотность хранения. Другими словами где найти информацию о том, сколько байт тратится на хранение к примеру одной тройки в среднем.

Вопрос особого смысла не имеет. СУБД сильно различаются по числу и типу индексов, наличию-отсутствию mapping dictionary и алгоритмам компрессии. Детали я раскрывать не могу, но в зависимости от датасета плотность хранения в том же Stardog может отличаться в десятки раз. Сам по себе этот параметр неинтересен, интересны конечные параметры: скорость bulk loading (включая индексацию), ответов на запросы и апдейты.

Re: Устройство rdf хранилища

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

4

Re: Устройство rdf хранилища

Пользователю важно чтобы СУБД была быстрой и надежной. Какого размера понадобятся диски для БД - вопрос десятый (и копеечный). Разумеется опосредованно эти параметры связаны (т.к. IO желательно уменьшать), но на практике эта связь весьма слабая.

Плотность не может не зависеть от информации. Для сведения: литералы в некоторых био датасетах (например, UniProt) превышают 16кб.

5

Re: Устройство rdf хранилища

DenisKoronchik пишет:

сколько байт тратится на хранение к примеру одной тройки в среднем.

Мы для крупных хранилищ стараемся укладываться в 6--7 байт на квад, не считая словаря литералов, где всё зависит от средней длины литерала.

Re: Устройство rdf хранилища

iv_an_ru пишет:
DenisKoronchik пишет:

сколько байт тратится на хранение к примеру одной тройки в среднем.

Мы для крупных хранилищ стараемся укладываться в 6--7 байт на квад, не считая словаря литералов, где всё зависит от средней длины литерала.

6-7 байт это круто. У нас на тройку уходит 156 байт, но элементы не дублируются.
Скажем если элемент X был в тройке:
X y Z
и в тройке
X y U
и так далее, то в памяти он сидит лишь один раз.
Получается чем больше в памяти дуг, тем меньше байт тратится на тройку.

7

Re: Устройство rdf хранилища

DenisKoronchik пишет:

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

А сколько памяти в вашей схеме будет уходить, если хранить квады, а не тройки?

Re: Устройство rdf хранилища

iv_an_ru пишет:
DenisKoronchik пишет:

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

А сколько памяти в вашей схеме будет уходить, если хранить квады, а не тройки?

Да нет у нас как понятия тройки. Я просто пытаюсь как-то проводить аналогии с RDF, хотя мы можем хранить и RDF.
У нас чистая сеть (граф) при хранении, а не реляционная БД. Соответственно, чтобы к примеру найти простой запрос по выходящим дугам, нам надо найти элемент и разок пробежаться по списку выходящих дуг.
Но смысл квадов и зачем они нужны мне по прежнему не понятен.

Отредактировано DenisKoronchik (2012-12-12 11:48:26)

9

Re: Устройство rdf хранилища

Чтобы хранить контексты триплетов (aka named graphs). Классический use case - provenance data.

10

Re: Устройство rdf хранилища

PavelK пишет:

Чтобы хранить контексты триплетов (aka named graphs). Классический use case - provenance data.

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

11

Re: Устройство rdf хранилища

DenisKoronchik пишет:
PavelK пишет:

Чтобы хранить контексты триплетов (aka named graphs). Классический use case - provenance data.

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

Если у вас можно сделать ссылку на дугу, то да. Но тогда у вас хранилище не для RDF, а для модели в духе "мира кубиков" Уинстона, и разумно использовать его именно как в мире кубика --- "за те же деньги" функциональность богаче получится.

12

Re: Устройство rdf хранилища

iv_an_ru пишет:

Если у вас можно сделать ссылку на дугу, то да. Но тогда у вас хранилище не для RDF, а для модели в духе "мира кубиков" Уинстона, и разумно использовать его именно как в мире кубика --- "за те же деньги" функциональность богаче получится.

Да и в RDF можно, через реификацию. Только не нужно. А сравнивать его систему с graph DB (тем же neo4j) я автору уже предлагал, из того что он пишет складывается ощущение, что это им ближе чем триплсторы.

13

Re: Устройство rdf хранилища

да у нас можно дуги в дуги... спасибо за информацию... вообще можем хранить и триплеты, и навернуть sparql, это же частный вид по сути.