The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

На конференции Google I/O представлена открытая графо-ориентированная СУБД Cayley

27.06.2014 22:22

На конференции Google I/O анонсирована новая СУБД Cayley, ориентированная на хранение связанных друг с другом данных, образующих граф (семантический web, социальные сети и т.п). Основная особенность графо-ориентированной СУБД - возможность указания связей (между записями), которые будут учтены при построении запросов.

Код написан на языке Go и распространяется под лицензией Apache. Система является модульной и может использовать разные бэкенды для низкоуровневого хранения и организации обработки запросов. Например, доступны бэкенды для хранения в оперативной памяти, LevelDB и MongoDB. Для выборки связанной информации поддерживается использование Javascript-объекта graph и упрощённый вариант языка MQL (Metaweb Query Language), применяемого в базе структурированных знаний Freebase.

Cayley может использоваться как обособленная СУБД, обрабатывающая запросы по HTTP с использованием RESTful API, REPL или встроенного web-интерфейса, предоставляющего инструменты для редактирования и визуализации данных. Также поддерживается режим связывания с программами, при котором Cayley выступает в роли разделяемой библиотеки. Стратегия обхода графа заимствована из проекта graphd, при этом использование эффективных средств распараллеливания обработки данных, предоставляемых языком Go, позволило обеспечить в Cayley достаточно высокий уровень производительности.

Для экспериментов с Cayley при помощи Google App Engine запущен демонстрационный интерфейс, позволяющий формировать запросы к базе из 30 тысяч фильмов, содержащей сведения об актёрах, ролях и режиссёрах.

Отмечается, что Cayley не является проектом компании Google, но развивается при её поддержке. Проект создан Бараком Миченером (Barak Michener), инженером из Google, который под впечатлением от Freebase и Knowledge Graph загорелся идеей предоставить разработчикам открытый инструмент для формирования похожих баз знаний.



  1. Главная ссылка к новости (http://google-opensource.blogs...)
  2. OpenNews: Компания Google представила исходные тексты системы обработки данных Refine 2.0
  3. OpenNews: Новая версия NoSQL базы данных OrientDB 1.3
  4. OpenNews: Релиз СУБД Neo4j 1.3, ориентированной на хранение графов
  5. OpenNews: Релиз документо-ориентированной СУБД MongoDB 2.6
  6. OpenNews: Компания Google открыла исходные тексты БД LevelDB
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/40098-graph
Ключевые слова: graph, cayley, google
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (18) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, umbr (ok), 00:15, 28/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Оно "TinkerPop Blueprints" поддерживает?
     
  • 1.3, бедный буратино (ok), 05:55, 28/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    крутенько. а она маленькая и быстренькая? на небольшое количество данных и без хранения в памяти - оно, того, пойдёт?
     
  • 1.4, iZEN (ok), 10:34, 28/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ух, крутота!
     
  • 1.5, Аноним (-), 12:20, 28/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Я извиняюсь, чем это отличается принципиально от реляционных БД? Что, не умеем строить эффективные табличные модели и хорошие быстрые запросы - а лучше напишем собственную волшебную пулю? Одну из множества, причем? NIH свербит и чешется?!
     
     
  • 2.6, iZEN (ok), 12:46, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Я извиняюсь, чем это отличается принципиально от реляционных БД? Что, не умеем
    > строить эффективные табличные модели и хорошие быстрые запросы - а лучше
    > напишем собственную волшебную пулю? Одну из множества, причем? NIH свербит и
    > чешется?!

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

     
     
  • 3.22, Аннушкапролиламасло (?), 09:24, 02/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    LDAP изобрели?
     
  • 2.8, бедный буратино (ok), 14:15, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    а чё это мы реляционными базами пользуемся? что, не умеем эффективно самим структуры данных делать, грузить, обрабатывать, а лучше напишем mysql какой-нибудь, да ещё и с сэкюэльчиком (тьфу, смотреть тошно)?  NIH свербит и чешется?!
     
  • 2.9, Аноним (-), 15:11, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    уверен, в реляционных БД ты не разбираешься. как и в чем-либо вообще
     
  • 2.12, Michael Shigorin (ok), 20:26, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Я извиняюсь, чем это отличается принципиально от реляционных БД?

    Если бы Вы когда-нибудь что-нибудь делали на РСУБД, то уже один шаблон "а вот этот атрибут у нас определяет семантику вот того атрибута" навёл бы на смутные подозрения, выливающиеся в буйный восторг при знакомстве с иерархическими БД, например.

    Идите-ка и учитесь, а не пишите глупости.

     
     
  • 3.15, rob pike (?), 11:05, 29/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Вы бы поосторожней.
    При знакомстве с иерархическими БД юного сторонника прогрессивных NoSQL может ведь и удар хватить, если он случайно датами их расцвета поинересуется.
     
  • 3.17, open_balex (ok), 09:25, 30/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Никого же не удивляет как это оперативка хранит в себе деревья, если это плоское адресное пространство от 0 до ххх. Так и реляционной моделью вполне себе можно представить что угодно. Парентные отношения есть, многие ко многим связи тоже реализовать не проблема. Да, таблицы иной раз будут плохо нормализованы, но это не повод говорить о резких преимуществах "сетевых" моделях СУБД. Истории их действительно много лет, но толком не "взлетели". Может, когда  CPU/APU/GPU будут уметь в "железе" что то делать с рекурсией и графами, тогда реляция и станет мовитоном. А так - нашлепали таблиц, "обвесили" кодом PL/SQL со всякими connect by (тут по в кусу)  и имеете граф-ориентированную БД.
     
  • 3.18, vlikhachev (ok), 09:41, 30/06/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Я извиняюсь, чем это отличается принципиально от реляционных БД?
    > Если бы Вы когда-нибудь что-нибудь делали на РСУБД, то уже один шаблон
    > "а вот этот атрибут у нас определяет семантику вот того атрибута"
    > навёл бы на смутные подозрения, выливающиеся в буйный восторг при знакомстве
    > с иерархическими БД, например.
    > Идите-ка и учитесь, а не пишите глупости.

    Хммм... Проблема иерархических БД - работать с ними могут только РАЗУМНЫЕ пользователи, а их количество стремится к нулю в каждой отдельно взятой организации. Или выполнение рекомендации Oracle - директор по структуре БД предприятия наряду с коммерческим, финансовым и т.д.

    Работали в свое время с НИКОЙ - передовой российской разработкой иерархической БД, зарплату для завода на 5000 человек сделали, под DOS.
    НИКА считала 15-20 минут, фокса - 8-10 часов.
    НО через год после конца сопровождения они так базу "расширили и дополнили", что считать на НИКЕ вообще перестало. А поскольку 1С тогда не было, на РСУБД этот подвиг (невозможность расчета) повторить не смогли...

     

  • 1.11, Аноним (-), 18:15, 28/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А кто-нибудь попробуйте "распутать" таблицу ссылающуюся саму на себя глубиной так в 500 записей. В цирке смеяться не будет. Как пример таблица людей и их родственные связи. ;-)
     
     
  • 2.13, Andrey Mitrofanov (?), 20:33, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А кто-нибудь попробуйте "распутать" таблицу ссылающуюся саму на себя глубиной так в
    > 500 записей. В цирке смеяться не будет. Как пример таблица людей
    > и их родственные связи. ;-)

    Ну, да, ну рекурсивный SQL запрос. Но никак не ужос-ужос-ужос. //Гордый участник Фестиваля специалистов!

     
     
  • 3.14, Grammar_Nazi (?), 09:28, 29/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    SQL-запрос
     
  • 3.19, vlikhachev (ok), 09:45, 30/06/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> А кто-нибудь попробуйте "распутать" таблицу ссылающуюся саму на себя глубиной так в
    >> 500 записей. В цирке смеяться не будет. Как пример таблица людей
    >> и их родственные связи. ;-)
    > Ну, да, ну рекурсивный SQL запрос. Но никак не ужос-ужос-ужос. //Гордый участник
    > Фестиваля специалистов!

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

     
     
  • 4.20, Andrey Mitrofanov (?), 10:34, 30/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Так рано или поздно юзер таких данных навводит, что Ваша рекурсия уйдет
    > в переполнение стека и крах всей системы либо в невозможность выполнения
    > запроса...

    Моя не уйдёт. YMMV.

     

  • 1.21, 1 (??), 11:12, 30/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    О как ! Реинкарнация CODASYL ?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру