На конференции Google I/O анонсирована (http://google-opensource.blogspot.ru/2014/06/cayley-graphs-i... новая БД Cayley (https://github.com/google/cayley), ориентированная на хранение связанных друг с другом данных, образующих граф (семантический web, социальные сети и т.п). Основная особенность графо-ориентированной БД (http://ru.wikipedia.org/wiki/%D0%91%D0%B... заключается в том, что кроме записей, определяется и связь между ними, которая учитывается при построении запросов.
Код написан на языке Go и распространяется (https://github.com/google/cayley) под лицензией Apache. Система является модульной и может использовать разные бэкенды для низкоуровневого хранения и организации обработки запросов. Например, доступны бэкенды для хранения в оперативной памяти, LevelDB (http://code.google.com/p/leveldb/) и MongoDB (http://www.mongodb.org/). Для выборки связанной информации поддерживается использование Javascript-объекта graph и упрощённый вариант языка MQL (Metaweb Query Language), применяемого в базе структурированных знаний Freebase.
Cayley может использоваться как обособленная БД, обрабатывающая запросы по HTTP с использованием RESTful API, REPL или встроенного web-интерфейса, предоставляющего инструменты для редактирования и визуализации данных. Также поддерживается режим связывания с программами, при котором Cayley выступает в роли разделяемой библиотеки. Стратегия обхода графа заимствована из проекта graphd (http://dl.acm.org/citation.cfm?id=1807283), при этом использование предоставляемых языком Go эффективных средств распараллеливания обработки данных позволило обеспечить в Cayley достаточно высокий уровень производительности.
Для экспериментов с Cayley при помощи Google App Engine запущен демонстрационный интерфейс (http://cayley-graph.appspot.com/), который позволяет формировать запросы к базе из 30 тысяч фильмов, содержащей сведения об актёрах, ролях и режиссёрах.<center><img src="http://www.opennet.me/opennews/pics_base/0_1403894771.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></center>
Отмечается, что Cayley не является проектом Google, но развивается при поддержке данной компании. Проект создан Бараком Миченером (Barak Michener), инженером из Google, который под впечатлением от Freebase (http://freebase.com) и Knowledge Graph (http://www.google.com/insidesearch/features/search/knowledge... загорелся идеей предоставить разработчикам открытый инструмент для формирования похожих баз знаний.<center><iframe width="640" height="360" src="//www.youtube.com/embed/0oOwrBEeQss?rel=0" frameborder="0" allowfullscreen></iframe></center>
URL: http://google-opensource.blogspot.ru/2014/06/cayley-graphs-i...
Новость: http://www.opennet.me/opennews/art.shtml?num=40098
Оно "TinkerPop Blueprints" поддерживает?
крутенько. а она маленькая и быстренькая? на небольшое количество данных и без хранения в памяти - оно, того, пойдёт?
Ух, крутота!
Я извиняюсь, чем это отличается принципиально от реляционных БД? Что, не умеем строить эффективные табличные модели и хорошие быстрые запросы - а лучше напишем собственную волшебную пулю? Одну из множества, причем? NIH свербит и чешется?!
> Я извиняюсь, чем это отличается принципиально от реляционных БД? Что, не умеем
> строить эффективные табличные модели и хорошие быстрые запросы - а лучше
> напишем собственную волшебную пулю? Одну из множества, причем? NIH свербит и
> чешется?!Я так понял, что в этой БД каждая запись может содержать различное количество полей, каждое из которых может иметь отношение к полю какой-либо другой записи. В классических реляционных СУБД с этим туго — записи имеют, как правило, фиксированный набор полей и объединяются в таблицы.
LDAP изобрели?
а чё это мы реляционными базами пользуемся? что, не умеем эффективно самим структуры данных делать, грузить, обрабатывать, а лучше напишем mysql какой-нибудь, да ещё и с сэкюэльчиком (тьфу, смотреть тошно)? NIH свербит и чешется?!
уверен, в реляционных БД ты не разбираешься. как и в чем-либо вообще
> Я извиняюсь, чем это отличается принципиально от реляционных БД?Если бы Вы когда-нибудь что-нибудь делали на РСУБД, то уже один шаблон "а вот этот атрибут у нас определяет семантику вот того атрибута" навёл бы на смутные подозрения, выливающиеся в буйный восторг при знакомстве с иерархическими БД, например.
Идите-ка и учитесь, а не пишите глупости.
Вы бы поосторожней.
При знакомстве с иерархическими БД юного сторонника прогрессивных NoSQL может ведь и удар хватить, если он случайно датами их расцвета поинересуется.
Никого же не удивляет как это оперативка хранит в себе деревья, если это плоское адресное пространство от 0 до ххх. Так и реляционной моделью вполне себе можно представить что угодно. Парентные отношения есть, многие ко многим связи тоже реализовать не проблема. Да, таблицы иной раз будут плохо нормализованы, но это не повод говорить о резких преимуществах "сетевых" моделях СУБД. Истории их действительно много лет, но толком не "взлетели". Может, когда CPU/APU/GPU будут уметь в "железе" что то делать с рекурсией и графами, тогда реляция и станет мовитоном. А так - нашлепали таблиц, "обвесили" кодом PL/SQL со всякими connect by (тут по в кусу) и имеете граф-ориентированную БД.
>> Я извиняюсь, чем это отличается принципиально от реляционных БД?
> Если бы Вы когда-нибудь что-нибудь делали на РСУБД, то уже один шаблон
> "а вот этот атрибут у нас определяет семантику вот того атрибута"
> навёл бы на смутные подозрения, выливающиеся в буйный восторг при знакомстве
> с иерархическими БД, например.
> Идите-ка и учитесь, а не пишите глупости.Хммм... Проблема иерархических БД - работать с ними могут только РАЗУМНЫЕ пользователи, а их количество стремится к нулю в каждой отдельно взятой организации. Или выполнение рекомендации Oracle - директор по структуре БД предприятия наряду с коммерческим, финансовым и т.д.
Работали в свое время с НИКОЙ - передовой российской разработкой иерархической БД, зарплату для завода на 5000 человек сделали, под DOS.
НИКА считала 15-20 минут, фокса - 8-10 часов.
НО через год после конца сопровождения они так базу "расширили и дополнили", что считать на НИКЕ вообще перестало. А поскольку 1С тогда не было, на РСУБД этот подвиг (невозможность расчета) повторить не смогли...
А кто-нибудь попробуйте "распутать" таблицу ссылающуюся саму на себя глубиной так в 500 записей. В цирке смеяться не будет. Как пример таблица людей и их родственные связи. ;-)
> А кто-нибудь попробуйте "распутать" таблицу ссылающуюся саму на себя глубиной так в
> 500 записей. В цирке смеяться не будет. Как пример таблица людей
> и их родственные связи. ;-)Ну, да, ну рекурсивный SQL запрос. Но никак не ужос-ужос-ужос. //Гордый участник Фестиваля специалистов!
SQL-запрос
>> А кто-нибудь попробуйте "распутать" таблицу ссылающуюся саму на себя глубиной так в
>> 500 записей. В цирке смеяться не будет. Как пример таблица людей
>> и их родственные связи. ;-)
> Ну, да, ну рекурсивный SQL запрос. Но никак не ужос-ужос-ужос. //Гордый участник
> Фестиваля специалистов!Так рано или поздно юзер таких данных навводит, что Ваша рекурсия уйдет в переполнение стека и крах всей системы либо в невозможность выполнения запроса...
> Так рано или поздно юзер таких данных навводит, что Ваша рекурсия уйдет
> в переполнение стека и крах всей системы либо в невозможность выполнения
> запроса...Моя не уйдёт. YMMV.
О как ! Реинкарнация CODASYL ?
