Гигабит NoSQL/RDBMS с ссылочной целостностью (удалить каскад)?

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

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

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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

Карта/Уменьшить - в двух вариантах: распределенная ориентированная на запись (думаю, MongoDB) и ориентированная на столбцы (думаю, Кассандра). Масштабы действительно очень хорошо, но у вас не будет синтаксиса SQL-типа; присоединяется; и соответствие вашей архитектуры вашим конкретным типам запросов имеет решающее значение. В вашем случае вы сосредотачиваетесь на сущности и их атрибутах, а не на отношениях между самими объектами, поэтому я, вероятно, рассмотрю распределенное хранилище, ориентированное на запись; но только если бы я ожидал, что вам придется масштабироваться за пределы одного node - они действительно очень хорошо выглядят.
Хранилище документов - технически в двух вариантах, но одна из них - распределенная ориентированная на запись карта/сокращение хранилища данных, рассмотренная выше. Другой - инвертированный индекс (подумайте, Lucene/Solr). НЕ Пренебрегайте силой инвертированного индекса; они могут устранить неприлично сложные предикаты записи удивительно быстро. То, что они не могут сделать, - это хорошо справиться с запросами, которые включают корреляцию или большие реляционные объединения. Тем не менее, вы будете поражены невероятной гибкостью, дает вам достаточно сложные предикаты.
Графический магазин - приходят в нескольких вариантах: первый - это крупномасштабное специализированное хранилище ключей (думаю, DBM/TokyoTyrant); второй - кортеж (подумайте, Neo4j); третья база данных RDF (подумайте, кунжут/мулгара). У меня есть мягкое пятно для RDF, помогло развить мулгару, поэтому я не самый объективный комментатор. Тем не менее, если ваши ограничения масштабируемости позволят вам использовать RDF-хранилище, я нахожу бесценное определение, разрешенное денотационной семантикой RDF (редкое среди опций хранилища noSQL).

Ответ 3

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

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

Ответ 4

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

Ответ 5

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