Как база данных Graph достигает гибкой схемы? - PullRequest
Новая
       61

Как база данных Graph достигает гибкой схемы?

0 голосов
/ 10 декабря 2018

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

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

Может кто-то пролить больше света на это?Спасибо.

Редактировать: Дать пример, чтобы сделать его более понятным: 

Take for example a User table:

  FirstName|LastName|email|Facebook|Twitter|Linkedin|

Теперь, некоторые пользователи могут иметь FB, а не Twitter и Linkedin или наоборот,Может быть, у них есть несколько идентификаторов электронной почты?Как вы это представляете? 

Graph DB: 
Vertices for User, FB_Link, Twitter_Link, Email. 
Edges (from User) to FB, Edge to Twitter, Edge to Linkedin, Edge to Email (x 2 times) etc.



Json/DocumentDB: 
  {
  ID:
  FirstName:
  LastName:
  FB:
  }
  {
  ID:
  FirstName:
  LastName:
  Twitter:
  Linkedin:
  }

  Notice that the documents can have different attributes.

Прав ли я в приведенной выше интерпретации гибкости схемы?Есть что-то еще?

1 Ответ

0 голосов
/ 13 декабря 2018

Статья в Википедии более упрощена с помощью утверждения:

позволяет пользователю вставлять новые данные в существующий график без потери функциональности приложения

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

Краткое примечание

SQL - этопостроен на реляционной модели 1016 *, которая обеспечивает строгие проверки согласованности между записями данных.Это достигается путем принудительной блокировки структурных изменений.Графовые базы данных построены на модели графа свойств , и это не приводит к таким реляционным ограничениям.Что означает отсутствие замков (в большинстве случаев).Он применяет пары «ключ-значение» только в конструкциях, называемых вершинами, соединенными вместе ребрами

. С этим обсужденным битовым контекстом давайте поговорим о вашем основном вопросе:

Как достигается гибкая схема

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

Как это делается практически, хотя варьируется от графа дБ до графа дб.На данный момент в поле отсутствует стандартизация.Например,

  • JanusGraph работает на разных БД NoSql, таких как хранилище широких столбцов и хранилище документов.
  • OrientDB используетхранилище документов json.
  • RedisGraph использует хранилище ключей в памяти.
  • Neo4j использует собственную модель данных, которая мне не знакомас.

Обратите внимание , как все вышеперечисленное использует базы данных NoSQL в качестве основы.Вот как достигается гибкая схема.Все эти графические базы данных просто хранят данные вне реляционных БД / таблиц, где существуют правила «нет».Хранилища документов и хороший пример json.

Если вам интересна примерная реализация модели графа свойств, вы можете проверить модель Neo4j или JanusGraphs 'Docs или общее сравнение их модель

...