1

Тема: Graffiti, Samizdat

Дмитрий, на ruby on rails будет работать ваше хранилище RDF? http://semanticfuture.net/index.php?title=Graffiti В смысле можно ли библиотеку подключить к рельсам?

Re: Graffiti, Samizdat

Подключить можно к любой Ruby-программе, в том числе и к Rails, но специальной интеграции с Rails на уровне DSL (специального языка), как например в ActiveRDF, пока нет. Поскольку в Graffiti пока нет поддержки SPARQL, а есть только Squish, то и выступать в качестве источника для ActiveRDF, который поддерживает только SPARQL, Graffiti тоже пока не может.

С другой стороны, поскольку API у Graffiti прост до неприличия и практически один в один повторяет интерфейс DBI, сделать интеграцию с Rails по образу и подобию ActiveRecord и ActiveRDF не должно составлять особого труда для человека, хорошо знакомого с рельсами.

Thumbs up −1 Thumbs down

3

Re: Graffiti, Samizdat

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

4

Re: Graffiti, Samizdat

Я в рельсах ни бум-бум, но в чём выигрыш от Graffiti по сравнению с простой отправкой sparql-запроса по odbc/udbc/jdbc/iodbc и т.п.? Недостаток очевиден --- при переводе в SQL не используются многие фенечки удалённой базы.

Re: Graffiti, Samizdat

Shcherbak пишет:

Graffiti получается более быстрой альтернативой ActiveRDF, правильно?
или в чем основные фичи вашей разработки?

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

iv_an_ru пишет:

в чём выигрыш от Graffiti по сравнению с простой отправкой sparql-запроса по odbc/udbc/jdbc/iodbc и т.п.?

Выигрыш в том, что получающая сторона не обязана понимать Sparql, годится любая SQL-система.

iv_an_ru пишет:

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

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

Thumbs up Thumbs down

6

Re: Graffiti, Samizdat

Ага, то есть RDB2RDF есть. Тогда согласен, получается конкурент D2RQ.
Не пробовали гонять BSBM ( http://www4.wiwiss.fu-berlin.de/bizer/B … Benchmark/ ) ?

Re: Graffiti, Samizdat

конкурент D2RQ

Совершенно верно, причём вполне зрелый конкурент -- Samizdat появился на год раньше D2RQ :)

Не пробовали гонять BSBM

Гонял, результаты очень неплохие -- на машине, аналогичной используемой в официальных тестах BSBM, но только в с двумя ядрами и 2 Гб ОЗУ вместо 8 Гб, на 25 млн. триплетов вышло 18735 QMpH на полной серии запросов. На 100 млн. триплетов вышло всего 2246 QMpH, но тут наверное разница в объёме ОЗУ слишком сильно сказывается. Многопоточные тесты не гонял -- на двухъядерном процессоре это не имеет особого смысла.

В ближайшие дни собираюсь выложить больше подробностей в Wiki.

Thumbs up +1 Thumbs down

8

Re: Graffiti, Samizdat

18735 QMpH на полной серии запросов --- вероятно поверх MySQL с реляционной схемой?

9

Re: Graffiti, Samizdat

Прочитал статью, идея очень понравилась. Берём готовую LAMP систему, втыкаем в неё небольшую детальку и получаем возможность расширения в сторону семвеба.

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

Re: Graffiti, Samizdat

Спасибо на добром слове!

Специфика использования Samizdat/Graffiti до последнего времени была такова, что потребление системных ресурсов и время отклика системы были важнее масшабируемости -- движок ставился в основном на минимальных VPS-хостингах и имел дело с небольшими базами данных, самая большая база, используемая в production -- порядка 150 тыс. триплетов. Так что позиционирование движка именно такое -- семантизация небольших LAMP-систем.

Да, тестировал с реляционной схемой, только поверх PostgreSQL, а не MySQL. На чистых триплетах не пробовал, надо будет как-нибудь погонять, сравнить, насколько использование реляционной схемы влияет на производительность...

Thumbs up Thumbs down

Re: Graffiti, Samizdat

Добавил подробностей в Wiki-страницу Graffiti, в том числе и подробное описание теста BSBM, со ссылкой на использованные скрипты.

Thumbs up Thumbs down

12

Re: Graffiti, Samizdat

Отлично, Дмитрий. Скажите, вы планируете добавить поддержку SPARQL в обозримом будущем?
Или что нам ждать в следующей версии Graffiti?

Все таки хотелось бы иметь полноценную SPARQL-точку доступа )

Re: Graffiti, Samizdat

Согласен, поддержка SPARQL -- первая крупная "фича", которую я собираюсь добавить. Параллельно собираюсь сделать более модульный и гибкий логический вывод, потому что на втором месте -- полная поддержка RDFS и OWL.

Как скоро получится это сделать -- не знаю, пока могу только сказать, что это будет раньше, если найдутся желающие поучаствовать или профинансировать разработку ;-)

Thumbs up Thumbs down

14

Re: Graffiti, Samizdat

То есть речь идет по сути о создании OWL - резонера (подсистемы логического вывода) на Ruby? что то типа FACT++ только на руби?

Re: Graffiti, Samizdat

Большая часть логического вывода, который уже есть в Graffiti -- rdfs:subClassOf и owl:TransitiveProperty -- реализована на уровне хранимых процедур СУБД, я собираюсь и дальше действовать в этом направлении, так что скорее речь идёт о создании резонера в основном на PL/SQL, с элементами верхнего уровня и интеграционным интерфейсом на Ruby.

Хотя на первый взгляд идея иметь модульный резонер, целиком написанный на Ruby, может показаться заманчивой, на деле это было бы крайне неэффективно -- мало того, что пришлось бы тянуть из базы для обработки средствами Ruby чуть не весь набор данных, так ещё и Ruby как язык совершенно не приспособлен для тяжёлых вычислений и больших объёмов данных. Гораздо проще и эффективнее работать с данными непосредственно в базе, посмотрите например на мою реализацию транзитивных предикатов и представьте, как бы вы это делали на Ruby.

Thumbs up Thumbs down

16

Re: Graffiti, Samizdat

можно ли использовать graffiti с mysql или только на постгрес?

не понятно, при чем здесь PL/SQL?  в постгрес же pg/sql?

Re: Graffiti, Samizdat

Graffiti работает с PostgreSQL, MySQL и SQLite. PL/pgSQL -- это частный случай PL/SQL, реализованный в PostgreSQL, те же хранимые процедуры с небольшими изменениями легко переносятся на MySQL (начиная с версии 5) и SQLite (начиная с версии 3).

На самом деле адаптация Graffiti под любую реляционную СУБД, поддерживающую стандарт SQL, транзакции и хранимые процедуры, собственно в этом и заключается -- адаптации хранимых процедур под особенности синтаксиса, поддерживаемого новой базой. Ну и потребуется драйвер Ruby/DBI, вышеупомянутые три СУБД -- все, для которых есть стабильные драйвера, совместимые с Ruby/DBI v0.4+. Хотя я подумываю о переходе с Ruby/DBI на библиотеку Sequel, насчитывающую 11 драйверов вместо 3, и поддерживающую кое-какие другие фишки, например connection pooling.

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

Thumbs up +2 Thumbs down

18

Re: Graffiti, Samizdat

следующие версии   graffiti будут совместимы с graffiti 1/0?
вопрос в чем, если на основе текущей версии графити сделать проект, то при появлении новой версии с поддержкой sparql будет ли возможен переход на новую версию... или проект переписывать прийдется с нуля

Re: Graffiti, Samizdat

Будут, в худшем случае отделаетесь мелкими правками.

Я уже писал выше -- при добавлении поддержки SPARQL я собираюсь оставить и Squish тоже. А внешний API у Graffiti настолько прост, что там менять особо нечего. Если будет замена Ruby/DBI на Sequel, достаточно будет в одном месте поменять код подключения к СУБД. Если будут изменения на уровне структуры базы (как минимум поменяются хранимые процедуры) -- в релиз будут включены инструкции и скрипты для апгрейда. Посмотрите Release Notes предыдущих версий Samizdat на http://samizdat.nongnu.org/ как пример того, как я собираюсь обходиться с изменениями базы данных и конфигурационных файлов.

Thumbs up +1 Thumbs down

20

Re: Graffiti, Samizdat

Здравствуйте. Не подкинете ссылку на дамп реальной базы.
а то рельсов я не знаю, ставить и разбираться времени нет, а разобраться со схемой работы хочется:)

и еще возник вопрос - у вас данные по триплетам из базы забираются для таблиц и триплетов вместе с выводом одним  sql запросом? или все-таки идет несколько запросов с промежуточными корректировками ( забрали из ресурсов с триплетами, определили необходимые таблицы - забрали и т.д.)?

Thumbs up Thumbs down

Re: Graffiti, Samizdat

Вот например скрипт генерации базы Samizdat:

http://git.savannah.gnu.org/cgit/samizd … -pgsql.sql

Рельсов знать не надо, только просто Ruby.

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

Thumbs up −1 Thumbs down

22

Re: Graffiti, Samizdat

спасибо, правда про руби я имел ввиду что я ни с руби ни с рор никогда не сталкивался:)

Thumbs up Thumbs down

23

Re: Graffiti, Samizdat

DmitryBorodaenko пишет:

Graffiti работает с PostgreSQL, MySQL и SQLite. PL/pgSQL -- это частный случай PL/SQL, реализованный в PostgreSQL, те же хранимые процедуры с небольшими изменениями легко переносятся на MySQL (начиная с версии 5) и SQLite (начиная с версии 3).

Дмитрий, а хотите презентовать Graffity здесь - http://www.semantic-web-journal.net/con … nd-systems ? И сроки нормальные - до 31 июля, и очень симпатичный процесс отбора - все рецензенты будут отписываться в тамошнем блоге. А мы пингбэк сделаем. Если нужна помощь - поможем smile

Thumbs up Thumbs down

24

Re: Graffiti, Samizdat

KeNGa пишет:

Дмитрий, а хотите презентовать Graffity здесь - http://www.semantic-web-journal.net/con … nd-systems ? И сроки нормальные - до 31 июля, и очень симпатичный процесс отбора - все рецензенты будут отписываться в тамошнем блоге. А мы пингбэк сделаем. Если нужна помощь - поможем smile

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

С другой стороны, публикация в таком сборнике --- это такой флажок, "программирую не только за деньги, со мной можно расплачиваться индексом цитирования". Поэтому мне директор писать туда запретил smile

Re: Graffiti, Samizdat

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

Интересный подход к индексу цитирования smile

Thumbs up +2 Thumbs down