Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 38
Еще SWRL ;) хотя там все достаточно просто
Каких пять?
Подлежащее-сказуемое-дополнение… а где тогда обстоятельства с определениями?! Я серьезно. Чем добавлять конкретные сказуемые, лучше бы добили «естественность» модели.
Нет там никаких сказуемых. Есть объект-свойство-значение. Этими триплетами можно описать всё, что угодно.
В обычных языках обстоятельства и определения тоже не обязательны. Ни в одном из случаев. «Маша села в машину. Эта машина отражается красным цветом.»… Все только за счет подлежащих, сказуемых и дополнений, или, будь по Вашему, за счет связок объект-свойство-значение. Но в реальности мы просто скажем «Маша села в красную машину». Применяем определение. Тоже самое с обстоятельствами.
В этом и претензия к RDF. Эта штука действительно то необходимое, что нужно для описания чего угодно. Но в реальности, как и в случае с языками, нужно не минимальное, а удобное. Ученым это не надо, а всем остальным надо.
Что интересно, сообщество SemanticWeb, не смотря на свою академическую природу, таки пытается сделать RDF чем-то удобным. Думаю, так появился RDFS — попытка реализовать обстоятельства. Аналогично туда попали именованные графы — шаг в сторону реализации определений. Но это все костыли. Прилепляются сбоку и соответствующим образом воспринимаются.
RDF — хорош как идея, но кажется эту идею нужно переписывать с нуля.
В этом и претензия к RDF. Эта штука действительно то необходимое, что нужно для описания чего угодно. Но в реальности, как и в случае с языками, нужно не минимальное, а удобное. Ученым это не надо, а всем остальным надо.
Что интересно, сообщество SemanticWeb, не смотря на свою академическую природу, таки пытается сделать RDF чем-то удобным. Думаю, так появился RDFS — попытка реализовать обстоятельства. Аналогично туда попали именованные графы — шаг в сторону реализации определений. Но это все костыли. Прилепляются сбоку и соответствующим образом воспринимаются.
RDF — хорош как идея, но кажется эту идею нужно переписывать с нуля.
Думаю, так появился RDFS — попытка реализовать обстоятельства.
Я не понял при чём тут обстоятельства. RDFS — просто набор терминов для описания схем через RDF. Как и любой другой набор терминов любой другой предметной области.
Аналогично туда попали именованные графы — шаг в сторону реализации определений.
Это скорее шаг к децентрализации, чтобы понятно было где лежат те или иные триплеты.
Думается автор заглавного коммента имел ввиду, что среди терминов RDFS главным был rdf:type который цепляет экземпляры к классам. Отсюда, если в подлежащем трипла оказывается какой-то из классифицированных экземпляров, то соответствующий класс становится там обстоятельством. А по поводу именованных графов общепринято мнение, что это способ учесть контексты предложений, чем в языке часто занимаются определения.
На самом деле, не столь уж и важно верны ли эти догадки насчет нововведений RDF. Основной посыл другой: модель изначально не пыталась реализовать что-то вроде определений и обстоятельств, чем обрекла себя на статус академической игрушки.
Есть планы сие исправить.
На самом деле, не столь уж и важно верны ли эти догадки насчет нововведений RDF. Основной посыл другой: модель изначально не пыталась реализовать что-то вроде определений и обстоятельств, чем обрекла себя на статус академической игрушки.
Есть планы сие исправить.
RDF не про любые выражения, а про описание мира. Соответственно там нет и не нужно много чего из естественных языков. В частности, там нет "подлежащих", "сказуемых" и тп. Есть объекты и их свойства. Да, свойства могут быть записаны как глаголы, существительные и даже целыми предложениями. В RDFS решили использовать короткое type, вместо isTypeOf. Это не потому, что тут требуется "обстоятельство", а просто всё это подражание естественному языку тут не нужно.
Ок. Возможно такая критика RDF не обоснована и модель жизнеспособна для своих, в том числе бизнес-целей. Надо признать, впечатляет и то как активно энтузиасты продвигают RDF-СУБД наподобие GraphDB. Плюс, конечно нужно вспомнить, что «графовая семья» включает в себя не только RDF, но и LPG — моделью данных Neo4j. У второй тоже своя востребованная на рынке правда. Просто очень надеюсь, что в семье найдется место и для чего-то нового.
Есть ещё атомарные базы данных, такие как Datomic. Она, кстати, ближе графовым, хотя язык запросов очень похож на реляционный.
Какой-то устаревший пост. На RDF уже давно все забили, ибо это сложный XML. SPARQL стандартизирован, но это не даёт какого-либо толчка популярности графовых субд. Кромето SPARQL есть Gremlin и тот же SQL с графовыми расширениями. Ну и OrientDB не плохо поддерживает кластеризацию.
http://arangodb.com/ кстати очень приятная штука, а главное графы умеет.
Вот если бы кто-то прикрутил к монге SPARQL движок, то мне бы больше ничего бы не надо было. Никаких там хадупов-шмадупов
У Neo4j есть шикарный язык запросов под названием Cypher.
Может кто-нибудь что-нибудь сказать про эту БД: Titan (http://thinkaurelius.github.io/titan/)
Как альтернатива базам данных SQL где-то с начала 2000-х развивается направление NoSQL. В эту категорию объединяют все подряд – от иерархических и сетевых БД
Berkeley DB — 1986
IMS — 1968
Все было с точностью до наоборот, сперва были иерархические и сетевые БД, а потом появились реляционные.
Весьма и весьма неоднозначная статья: вроде и есть полезное, а вроде и уйма пробелов. Производительность графовых БД для отдельных случаев даже лучше чем у релационных, так как поиск вершины на другом конце ребра это операция O(1), что значительно лучше чем поиск по FK. Да и насчет деления NoSQL: та же OrientDB является мультипрадигмной: хочешь Graph — без проблем, хочешь документную БД — элементарно, хочешь реляционную — тоже здесь (правда SQL далек от SQL92), ну а так же Key-Value. А если к этому добавить обертку типа Orienteer, то и бэкэенд для мобильного приложения или сайта без единого кода готов.
Я это к тому, что реляционные БД уходят на второй план так как не могут предоставить разработчикам «полный стэк» в сравнении с NoSQL разработками.
Я это к тому, что реляционные БД уходят на второй план так как не могут предоставить разработчикам «полный стэк» в сравнении с NoSQL разработками.
Поиск по FK это отнюдь не поиск вершины на другом конце ребра, это же поиск всех данных, связанных с той вершиной.
Не совсем так… Представьте, что вы делаете блог: у вас есть «таблица» с POSTS и COMMENTS. В реляционной БД у вас будет колонка COMMENTS.POST_ID ссылающаеся на соответствующий пост в POSTS. А в графовой БД у вас будет ребро связывающее комментарий и родительский пост. Ну так вот: в реляционной БД вам придется «перебрать» все посты (пусть даже если и по индексу) чтобы найти нужный с нужным POST_ID для данного комментария, а в графовой достаточно взять вершину на другом конце нужного ребра.
Также как и в реляционной — по индексам. Индекс может быть как автоматическим по комбинации класс+список_полей, так и ручным, когда создаются перелинкованные узлы вида «год», «месяц», «день», «час» и комментарий линкуется к часу.
В наличие прямых связей между сущностями. В полиморфности этих связей. Например, заменяем «комментарий за последний час» на «новые посты, видео, и комментарии (к постам и видео) за последний час» — в реляционной субд для этого потребуется 3 запроса по трём отдельным индексам с последующей сортировкой по времени, в графовой достаточно одного запроса по общему суперклассу и выдача будет уже отсортирована. А если к комментариям нужно вытянуть ещё и посты/видео к которым они даны и комментарии, на которые они являются ответами, то это совсем печально в реляционной субд. С графовой достаточно указать fetchplan и получить все связанные данные.
А вы исходные коды хабрахабра видели? На сколько экранов там запросы? Сколько человекомесяцев убито на реализацию и оптимизацию знаете? Сколько серверов всё это обслуживает в курсе? Как он периодически по ночам закрывается «на переучёт» не замечали? У меня лента (http://habrahabr.ru/feed/) формируется 600мс (при этом на ней почти ничего не меняется и часть данных подгружается асинхронно) — это быстро?
так как поиск вершины на другом конце ребра это операция O(1), что значительно лучше чем поиск по FK.
Поиск не по FK и не по графу, а по индексу (если он определён, конечно, для FK), т.е. по структуре данных. Индексов существует великое множество, и для всех их различная сложность поиска и обновления. Ты, говоря об FK, какой индекс имеешь ввиду?
Графовые СУБД (триплсторы) потому не особо взлетели, что там нет практически никаких заходов на оптимизацию, отличающихся от возможностей реляционные БД. А заходы реляционных применимы чрезвычайно ограниченно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Графовые базы данных: святой Грааль для разработчиков?