Гибрид NoSQL / RDBMS со ссылочной целостностью (удалить каскад)? - PullRequest
18 голосов
/ 02 августа 2010

Существует ли база данных, которая дает вам преимущество ссылочной целостности и возможности использовать язык запросов SQL для запросов, но также позволяет свободно определять сущности в отношении их атрибутов данных, а также отношений между ними?

например. возьмите модель типа RBAC, где у вас есть разрешения, пользователи, группы пользователей и роли. Сложная / гибкая модель может иметь следующие правила:

  • Роли могут иметь одно или несколько разрешений, а разрешение может принадлежать одной или нескольким ролям
  • Пользователи могут иметь одно или несколько разрешений, а разрешение может принадлежать одному или нескольким пользователям
  • Группы пользователей могут иметь одно или несколько разрешений, а разрешение может принадлежать одной или нескольким группам пользователей
  • Пользователи могут иметь одну или несколько ролей, а роль может принадлежать одному или нескольким пользователям
  • Группы пользователей могут иметь одну или несколько ролей, а роль может принадлежать одной или нескольким группам пользователей
  • Роли могут иметь одну или несколько ролей, а роль может принадлежать одной или нескольким ролям

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

Вышесказанное может быть достигнуто в некоторой степени в СУБД путем создания таблицы для хранения сущностей и другой таблицы для хранения связей и т. Д., Но это чрезмерно усложняет SQL, необходимый для выполнения простых запросов, и может также влиять на производительность.

Ответы [ 5 ]

13 голосов
/ 02 августа 2010

Большинство баз данных NoSQL созданы для очень хорошего масштабирования.Это делается за счет согласованности, частью которой является ссылочная целостность.Поэтому большинство NoSQL не поддерживает никаких типов реляционных ограничений.

Существует один тип базы данных NoSQL, который поддерживает отношения.На самом деле он разработан специально для отношений: графовая база данных .Графовые базы данных хранят узлы и явные отношения (ребра) между этими узлами.Как узлы, так и ребра могут содержать данные в форме пар ключ / значение без привязки к предварительно определенной схеме.

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

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

9 голосов
/ 04 августа 2010

Учитывая требования, которые вы указываете в своем вопросе, графическая база данных, вероятно, является тем, что вы ищете, но есть и другие варианты.Как сказал @Niels van der Rest, очень трудно согласовать два ограничения: «нет априорной схемы» и «ссылочная целостность».Возможно, вам удастся найти базу данных на основе тематической карты, которая могла бы это сделать, но я не знаком с конкретными реализациями, поэтому не могу сказать наверняка.

Если вы решите, что действительно не можете это сделатьбез ссылочной целостности, я боюсь, что вы, вероятно, застряли с RDBMS.Есть некоторые приемы, которые вы можете использовать, чтобы избежать некоторых проблем, которые вы ожидаете, я расскажу о паре в https://stackoverflow.com/questions/3395606...,, которая может дать вам некоторые идеи.Тем не менее, для такого рода модели данных, требующей динамической постприорной схемы с элементами мета-схемы, СУБД всегда будет неудобной.

Если вы готовы отказаться от ссылочной целостности, то вы все равноесть три подхода к рассмотрению.

  1. Map / Reduce - в двух вариантах: распределенный, ориентированный на запись (думаю, MongoDB), и ориентированный на столбцы (думаю, Cassandra).Очень хорошо масштабируется, но у вас не будет SQL-подобного синтаксиса;присоединяется сосать;и соответствие вашей архитектуры вашим конкретным типам запросов имеет решающее значение.В вашем случае вы сосредотачиваетесь на сущностях и их атрибутах, а не на отношениях между самими сущностями, поэтому я, вероятно, рассмотрю распределенное хранилище, ориентированное на записи;но только если я ожидал, что нужно масштабировать дальше одного узла - они действительно очень хорошо масштабируются.

  2. Хранение документов - технически в двух вариантах, но один из них - распределенная запись-ориентированная карта / уменьшение хранилища данных, рассмотренное выше.Другой - это перевернутый индекс (думаю, Lucene / Solr).НЕ пренебрегайте силой инвертированного индекса;они могут невероятно быстро разрешать непристойно сложные записи предикатов.То, что они не могут сделать, это хорошо обрабатывать запросы, которые включают корреляцию или большие реляционные объединения.Тем не менее, вы будете поражены невероятной гибкостью, которую дают вам достаточно сложные предикаты записей.

  3. Graph-store - есть несколько вариантов, во-первых, это крупномасштабный, специальныйхранилище ключей-значений (думаю, DBM / TokyoTyrant);вторая - это пространство кортежей (думаю, Neo4j);третья - база данных RDF (подумайте, Сезам / Мулгара).У меня есть слабость к RDF, так как я помогал развивать мулгару, поэтому я не самый объективный комментатор.Тем не менее, если ваши ограничения масштабируемости позволят вам использовать RDF-хранилище, я считаю вывод, разрешенный денотационной семантикой RDF (редким среди параметров хранилища данных noSQL), неоценимым.

7 голосов
/ 12 августа 2010

Некоторые решения NoSQL поддерживают безопасность и SQL. Одним из них является OrientDB. Система безопасности (вполне) хорошо объяснена здесь .

Кроме того, поддерживает SQL.

2 голосов
/ 04 августа 2010

Существует язык Gremlin , поддерживаемый графической базой данных Neo4j . Что касается вашего примера, взгляните на В списках управления доступом перечислены базы данных графиков и здесь . Есть также веб-инструмент, в том числе REST API для Neo4j и консоль Gremlin, см. neo4j / webadmin .

0 голосов
/ 04 августа 2010

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

...